#1. 개발 배경

#Ghostty를 쓰다가, 더 작은 걸 만들고 싶어졌다

Maru는 2026년 6월 3일에 시작한 macOS 우선 네이티브 터미널이다. 저장소에 남아 있는 첫 문서 terminal-strategy.md의 첫 줄이 출발점을 그대로 적어 두고 있다.

배경: Ghostty를 참고하면서, 더 작고 커스텀하기 쉬운 macOS 우선 네이티브 터미널을 만든다.

목표는 처음부터 짧게 정리돼 있었다.

Ghostty = 고품질, 고기능 네이티브 터미널
Maru    = 더 작고 단순한 네이티브 셸 + 쉬운 커스텀

구체적으로는 이런 것들이다.

• 기본기가 좋은 터미널
• 작고 빠른 네이티브 앱
• cmux 정도의 단순한 탭 경험
• 설정과 키바인딩 커스텀이 쉬운 구조
• 나중에 WASM 플러그인으로 확장 가능한 구조
• macOS 우선, 코어는 장기적으로 Windows·Linux·WebGPU를 고려한 구조

#"처음부터 하지 않을 것"을 먼저 적었다

Maru의 첫 문서에서 눈에 띄는 건 목표 목록보다 비목표 목록이다. 시작하는 날에 하지 않을 것부터 못박아 뒀다.

• tmux 호환 대체물(tmux window/pane UI·prefix/command mode·설정 언어)
• IDE형 워크스페이스 제품
• Warp식 command block UI
• AI 터미널
• 클라우드/계정 기반 제품
• 플러그인 플랫폼 우선 제품
• 첫 버전부터 완전한 크로스 플랫폼 앱

이 목록은 이후 두 달 반 동안 실제로 여러 번 인용됐다. 앱 종료 뒤에도 PTY를 살려 두는 세션 호스트를 만들 때도, 그것이 "tmux 호환 대체물을 만드는 일이 아니다"라는 문장을 계약 문서에 다시 적으며 경계를 지켰다.

#clean-room 원칙

Maru는 외부 터미널 소스를 복사하지 않고 공개 명세를 기준으로 독립 구현한다. 여기서 clean-room은 "공개 명세 기반 독립 재구현"을 뜻하고, Ghostty 같은 프로젝트는 레퍼런스와 오라클로만 쓴다.

레퍼런스를 쓰는 방식:

• 구조 레퍼런스
• 테스트 전략 참고
• 동작 비교 오라클
• 성능·UX 기준점

쓰지 않는 것:

• Ghostty 소스 vendoring
• libghostty-vt 런타임 의존
• Ghostty 타입을 Maru public API에 노출

VT 파서와 화면 상태를 직접 구현한다는 뜻이라 초반 비용이 크지만, 이 결정 덕분에 이후 모바일·Windows로 코어를 옮길 때 잘라낼 의존성이 없었다.

#석 달 남짓 뒤

2026년 9월 26일 확인한 공개 main 기준으로 저장소는 이렇게 자랐다.

터미널로 시작했지만 지금은 파일 탐색기, 소스 컨트롤 도크, 네이티브 편집기와 diff·병합·LSP, 인앱 브라우저, 에이전트 제어 프로토콜과 활동 뷰, 앱을 종료해도 살아남는 세션 호스트, 자체 SSH 클라이언트와 원격 저장소·파일 트리·에이전트 상태까지 들어 있다. 9월 마지막 주에는 미저장 문서와 턴 목록의 복원, 재부팅 뒤 로컬 에이전트 대화를 원래 칸에서 다시 여는 경로도 더했다(3-8). "IDE형 워크스페이스 제품은 만들지 않는다"는 첫 비목표와 지금의 모습 사이의 간격은, 개발 과정 각 편에서 그때그때 어떤 근거로 경계를 다시 그었는지 따라가면 보인다.