미첼 하시모토 인터뷰: Ghostty, Zig, 오픈소스 유지보수

• Mitchell Hashimoto는 Vagrant, Terraform, Vault 이후 Ghostty와 Vouch를 만들며, 터미널·Zig·오픈소스 유지보수·제품 품질에 대한 자신의 기준을 정리함
• Ghostty는 GPU 프로그래밍, 데스크톱/단일 노드 시스템 프로그래밍, Zig를 익히려는 개인 프로젝트에서 출발했고, 빠르고 기능이 풍부한 네이티브 크로스플랫폼 터미널을 목표로 발전함
• 터미널은 브라우저처럼 모든 기능을 품기보다 텍스트 기반 앱의 구성 가능성, 자동화, 명확한 보안 모델을 살려야 하며 PTY의 비구조적 바이트 스트림은 한계로 남아 있음
• 오픈소스 유지보수자는 사용자에게 의무를 지지 않지만, 좋은 소프트웨어를 만들려면 개별 요청을 그대로 받기보다 여러 문제를 하나의 일관된 기능으로 풀어야 한다고 봄
• Zig의 큰 변경은 다운스트림에 부담을 주지만 API와 컴파일 도구 품질을 높이고 있으며, AI는 대규모 변경의 반복 작업을 줄여 하위 호환성 부담을 낮출 수 있다고 평가함

Ghostty가 시작된 이유

• Mitchell Hashimoto는 Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint를 만든 뒤 현재 Ghostty와 Vouch를 만들고 있음
• Ghostty는 약 15년 동안 CLI 애플리케이션을 만들었지만 터미널 에뮬레이터가 어떻게 동작하는지 제대로 이해하지 못했다는 문제의식에서 출발함
• Hashicorp를 떠난 뒤 다시 다루고 싶었던 영역은 세 가지였음
  • AI 이전 맥락의 GPU 프로그래밍
  • 분산 시스템과 다른 데스크톱/단일 노드 시스템 프로그래밍
  • Zig 사용
• 초기 목표는 vim과 컴파일러를 실행하고, Ghostty가 자기 자신을 빌드할 수 있게 만든 뒤 버리는 것이었음
• 터미널 생태계를 더 살펴보면서 빠르고 기능이 풍부하며 네이티브 크로스플랫폼인 도구가 부족하다고 판단함
• Discord의 친구들에게 공유한 뒤 매일 쓰는 사용자가 생겼고, Ghostty Discord는 원래 친구 그룹 채팅방을 전용 공간으로 바꾼 것임
• 공개적 인지도가 과도한 관심을 만들 수 있다고 봐서 오랫동안 비공개 베타로 운영함

터미널은 어디까지 확장돼야 하나

• Hashimoto는 터미널을 무작정 거대한 애플리케이션 플랫폼으로 밀어붙이는 방향에는 반대함
• 터미널은 브라우저나 과거 Java 런타임처럼 영상·마이크 접근, 반응형 레이아웃까지 품을 수도 있지만, 브라우저·데스크톱·텍스트 기반 고정폭 그리드 앱은 각자 잘하는 일이 다르다고 봄
• 텍스트 기반 애플리케이션은 빠르게 구현되고 상호작용이 쉬우며, 보안 모델이 명확해야 함
• 터미널 기반 앱의 강점은 구성 가능성에 있음
  • TUI는 그 성격이 덜하지만, 대부분의 CLI 도구는 stdin/stdout을 넘어 함수처럼 사용할 수 있는 메커니즘을 갖고 있음
  • UNIX의 “한 가지 일을 잘하라” 철학이 그 극단에 있음
  • Neovim과 AI 도구는 점점 더 많은 명령줄 플래그를 제공함
• 더 나은 터미널 애플리케이션은 더 나은 자동화와 스크립트 가능성으로 이어짐
• PTY의 인밴드 신호, 즉 이스케이프 시퀀스를 포함한 비구조적 바이트 스트림은 큰 문제로 남아 있음
• Nushell 생태계는 별도 계층에서 이를 고치려 하지만, Hashimoto는 더 근본적인 개선이 필요하다고 봄
• Microsoft 생태계를 싫어하는 사람도 많지만, PowerShell은 구조화된 데이터 측면에서 많은 것을 제대로 하고 있다고 평가함

비레거시 터미널 API 구상

• 새 터미널 API를 생각할 때 Hashimoto는 브라우저, Emacs, Apple, Microsoft, Android, 게임 콘솔 같은 거대한 애플리케이션 플랫폼의 프레임워크를 참고함
• 웹의 DOM과 JS API, Apple의 AppKit·Cocoa·SwiftUI, Windows의 Win32·WinUI, Linux의 GTK·Qt처럼 이미 축적된 선례를 먼저 조사해야 한다고 봄
• 클립보드 접근만 해도 역사적 터미널 프로토콜은 텍스트 중심이지만, 데스크톱은 이미지와 여러 MIME 타입을 오래전부터 다뤄왔기 때문에 각 플랫폼의 클립보드 문서를 봐야 함
• 아직 Ghostty에 커스텀 프로토콜을 도입하지는 않았음

• n-screen API

  • 현재 터미널에는 보통 main screen과 alt screen 두 가지가 있음
  • main screen은 셸과 스크롤백에 가깝고, alternate screen은 Neovim과 대부분의 TUI에 가까움
  • 이 구조는 둘 중 하나의 모드를 켜거나 끄는 방식이며, 보통 전체 화면을 차지하고 스크롤백을 잃음
  • Hashimoto는 무제한 화면을 백그라운드에 만들고 채울 수 있는 n-screen API를 구상함
  • 화면별 그리드 크기를 다르게 두고 오버레이할 수 있으며, 터미널 에뮬레이터가 줄바꿈·선택·마우스 이벤트 라우팅을 처리할 수 있음
  • 특정 화면을 독립 창으로 지정하면 터미널 에뮬레이터가 그리드 밖에 렌더링할 수도 있음
  • 예시로 Neovim 탭을 네이티브 창 탭처럼 동시에 열 수 있는 형태를 들었음

• 버튼 프로토콜

  • 현재 마우스 프로토콜은 사용자가 현재 화면의 그리드 셀을 클릭했을 때만 이벤트를 받을 수 있음
  • 스크롤백에 들어간 히스토리 항목에는 클릭 이벤트를 받을 수 없음
  • 터미널은 현재 하이퍼링크 프로토콜인 OSC 8을 지원함
  • Hashimoto는 OSC 8과 비슷하게 클릭 시 프로그램으로 지정한 메시지를 보내는 버튼 프로토콜을 구상함
  • 예를 들어 open_profile ID를 가진 버튼은 사용자가 히스토리로 스크롤해도 등록된 상태로 남을 수 있음
  • 이 기능은 스크롤백이 있는 main screen 애플리케이션에 영향을 주며, Claude Code 같은 main screen 앱에서 파일 열기나 앱 내부 링크가 히스토리로 들어가면 작동하지 않는 문제와 연결됨

표준 부재와 오픈소스 유지보수

• Hashimoto는 PTY 프로토콜 전체를 Wayland로 바꾸는 실험을 했지만 버렸음
• 터미널은 창과 창 위젯을 관리하는 윈도잉 서버처럼 볼 수 있고, Wayland는 로컬 데스크톱과 창 렌더링 문제를 해결하는 좋은 프로토콜이라고 봄
• 터미널의 문제 중 하나는 더 이상 표준화 기구가 없다는 점임
• 오래된 명세는 남아 있지만, 지난 20년 동안의 표준화는 가장 인기 있는 터미널이 무엇을 하느냐를 기준으로 이뤄졌음
• 결과적으로 여러 기능이 뒤섞였고, 취향 있는 비전을 밀어붙이는 주체는 없다고 봄
• 앞으로의 경로는 확정하지 않았으며, 터미널이 아닌 새로운 텍스트 기반 애플리케이션 공간을 만들고 레거시 앱을 위한 터미널 번역 계층을 얹는 방향도 가능하다고 봄

• 사용자 요구와 큰 비전 사이의 균형

  • Hashimoto는 오픈소스 유지보수자가 사용자에게 의무가 0이라고 공개적으로 말해 왔음
  • 오픈소스 라이선스의 첫 줄은 “as is, no warranty”이고, 사용자는 무료 소프트웨어를 받는 대신 요구할 권리를 갖지 않는다는 입장임
  • 동시에 좋은 소프트웨어를 만들고 싶기 때문에 문제를 고치고 소프트웨어를 더 낫게 만들 책임감은 느낀다고 함
  • 어떤 날은 이슈를 보며 다른 사람의 문제를 고치고, 어떤 날은 이슈·토론·PR을 보지 않고 자신이 원하는 것에 집중함
  • 매일 사용자 이슈만 처리하면 안정적이지만 정체된 소프트웨어가 되고, 모든 PR을 받으면 변하긴 해도 비전이 사라진다고 봄
  • 대부분의 기여는 특정한 개인 문제를 긁어주는 수준이고, 이를 모두 받으면 코드가 산처럼 쌓인다고 말함
  • 반대로 문제를 깊이 이해하면 여러 기능 요청을 하나의 우아한 시스템으로 동시에 해결할 수 있음
  • 기능 설계 영상에서는 3~4개의 개별 기능 요청을 닫고, 이들과 다른 하나의 기능으로 동시에 해결한 사례를 들었음

• 기능 풍부함과 부풀림의 구분

  • Ghostty에서 가장 많이 요청된 기능 중 하나였던 검색은 구현되어 배포됨
  • 일부 사용자는 검색이 Ghostty의 미니멀리즘을 깨고 부풀렸다고 비판했지만, Hashimoto는 Ghostty를 기능 풍부한 터미널로 홍보한다고 답함
  • 그는 기능 풍부함과 부풀림을 구분함
  • 검색 기능은 디스크 공간과 RAM 로딩은 차지하지만, 사용하지 않으면 아무 코드도 실행되지 않도록 설계됐음
  • 따라서 사용하지 않는 사용자에게는 실행 비용이 없는 기능이라고 봄
  • Ghostty는 사용자의 필요에 맞게 꾸밀 수 있고, 기본 상태로도 동작하며, 필요하거나 검색하기 전까지 기능을 숨기는 터미널을 지향함
  • 기능 제거 플래그를 유지해 달라는 요구에는, 유지보수자가 그 플래그를 관리하는 것과 사용자가 기능을 제거한 포크를 유지하는 것이 같은 종류의 요구라고 봄

오픈소스의 권리, Zig의 변화, API 품질

• Hashimoto는 개인 포크와 유지되는 포크가 훨씬 많아져야 한다고 믿음
• 벤처 투자 기반 오픈소스는 웹사이트, 유료 지원 인력, Slack·Discord 지원을 갖춘 잘 다듬어진 프로젝트를 기대하는 세대를 만들었다고 봄
• 하지만 오픈소스의 핵심은 제품 보장이 아니라 자유와 권리임
  • 원하는 대로 사용
  • 수정
  • 포크
• 안정성이나 유지보수 의무는 그런 권리에 포함되지 않음
• 보안 취약점이 들어간 커밋을 유지보수자 탓으로만 돌릴 수 없고, 사용자가 그 커밋을 검토하지 않은 책임도 있다고 말함
• 더 강한 보장과 누군가를 탓할 권리를 원하면 소프트웨어 비용을 지불해 벤더-고객 관계를 맺어야 한다는 입장임
• 개인 프로젝트에서는 자신이 겪지 않는 버그를 고치는 PR도 병합하지 않을 수 있음
  • 병합은 그 코드를 영원히 유지하겠다는 약속이기 때문임

• Zig에 대한 태도

  • Hashimoto는 Zig를 선택할 때 무엇을 감수하는지 알고 있었고, 컴파일러 패치를 하며 커뮤니티와 문화, 철학을 이해하게 됐음
  • 아직 시작하지 않은 I/O 변경은 Zig에서 가장 어려운 작업 중 하나가 될 것으로 예상함
  • Zig의 인기가 올라가고 있지만 Andrew는 필요하다고 느끼는 변경에서 물러서지 않으며, Hashimoto는 다운스트림 사용자로서 그 점을 좋게 봄
  • Zig 0.15는 writer 인터페이스를 바꿔 출력하는 거의 모든 코드에 영향을 줬지만, API 자체는 훨씬 좋아졌다고 평가함
  • Zig는 컴파일 도구에 집중하고 있고, 컴파일 속도를 높이기 위해 언어 기능을 제거하기도 했음
  • lib-ghostty 전체 터미널을 즉시 빌드할 수 있지만, Andrew는 그 밀리초 단위 시간도 너무 느리다고 본다고 함
  • Zig 1.0은 언젠가 도달하겠지만 아직 몇 년은 남았다고 봄
  • AI는 언어 변경으로 생기는 다운스트림 고통을 줄일 수 있음
  • 다양한 맥락에서 변경 방법을 보여준 뒤 나머지를 적용하게 했을 때, 큰 diff의 약 90%가 자동으로 처리됐다고 함
  • A 상태에서 B 상태로 가는 방법을 설명할 수 있다면, 하위 호환성의 의미가 줄어드는 미래를 시사한다고 봄
  • Zig의 강한 반AI 정책과는 아이러니하지만, AI는 변경이 다운스트림 사용자에게 주는 고통을 둔화시킨다고 봄

• 라이브러리와 API 설계

  • 좋은 라이브러리 설계를 위한 가장 구체적인 방법은 여러 커뮤니티의 많은 라이브러리를 직접 써보는 것임
  • 실제 업무에서 쓰지 않을 프로그래밍 언어를 배우듯 다양한 생태계의 라이브러리를 쓰면 관점이 넓어짐
  • 대학 시절 Prolog, Haskell, Clojure, Java로 장난감 제품을 만들며 각 생태계의 빌드 시스템, 사용성, 라이브러리, 웹 프레임워크, 웹 서버, 앱 서버를 배웠음
  • 각 생태계의 문화는 라이브러리와 프레임워크의 관심사 분리와 API 모양에 스며든다고 봄
  • Java에서 오래 쓰인 builder 패턴을 Ruby에서 시도해 보고 괜찮다고 느낀 경험을 개념 이식의 예로 들었음
  • Docker는 배포·런타임 측면의 많은 요소가 개발 흐름에 섞인다고 봤고, Vagrant는 개발에 직접 초점을 맞춘 명사와 CLI, 설정을 의도적으로 사용했다고 말함

• 도구 제작자의 딜레마와 기술 스택

  • Hashimoto는 자신이 평생 도구 제작자였고, 도구 제작자의 딜레마를 믿는다고 말함
  • 어떤 문제를 절실히 이해해 이상적인 도구를 만들지만, 그 도구가 인기를 얻으면 실제 사용자가 아니라 접지력을 잃은 도구 제작자가 되는 문제가 반복될 수 있음
  • 터미널 자체는 매일 쓰지만 TUI 개발은 충분히 하지 못하고 있으며, 여러 이메일·IRC 클라이언트를 유지하고 명세도 작성한 rockorager 같은 유지보수자에게 의존하고 있음
  • 현재 기술 스택에 대해서는 “괜찮다”는 정도의 태도임
  • 프런트엔드, TypeScript, React 타입 커뮤니티에는 좋은 점이 많지만, 변화가 너무 많고 복잡성이 높으며 추상화 계층이 명확하지 않다고 봄
  • HTTP/1에서 HTTP/2와 HTTP/3로 가는 변화처럼 여러 영역에서 복잡성이 비선형적으로 증가했다고 말함
  • 업계가 너무 빠르게 움직이며 더 단순할 수 있었던 것을 복잡하게 만들고 있고, AI와 관련 도구가 이를 가속한다고 봄

원칙, 문화, 품질, 학습

• Hashicorp 원칙 문서나 Ghostty 개발 방식은 모두 Hashimoto 개인의 반영이었기 때문에 매일 실천하기 쉬웠다고 함
• 자신과 다른 원칙을 세우면 새해 결심처럼 실제 행동으로 옮기기 어렵다고 봄
• Ghostty는 크로스플랫폼 코어와 네이티브 GUI를 함께 중시함
  • 코어는 크로스플랫폼
  • GUI는 크로스플랫폼을 고집하지 않고 플랫폼별 네이티브 방식을 선호
• 오픈소스 프로젝트와 인터넷은 서로 다른 부족들의 모음이어야 한다고 봄
• 프로그래밍 언어들이 모두가 원하는 기능을 갖춘 최소공배수식 존재가 되는 것을 싫어하며, 제약이 창의성과 문화를 만든다고 말함
• Rust의 언어와 철학은 좋지만 Rust 문화는 좋아하지 않는다고 말했고, 이것이 Rust 커뮤니티 사람들이 나쁘다는 뜻은 아니라고 구분함
• Zig는 기술, 커뮤니티 관리, 자금 조달, PR, 블로그 포스트, 말하는 방식까지 뚜렷하고 양극화된 입장을 갖고 있으며, Hashimoto는 그 이상함을 존중해 계속 재정적으로 후원하고 사용한다고 함
• 품질 있게 빠르게 출시하려면 특정 고객 문제가 아니라 사용자가 그 문제에 도달한 맥락과 상류 문제까지 이해해야 함
• 기업 규모에서 이를 해결하는 방법은 모르지만, 자신은 자신이 만드는 소프트웨어의 큰 사용자로서 판단한다고 말함
• AI는 데모나 방향성 확인에는 거칠게 써도 되지만, 출시할 코드는 읽고 이해한 뒤 품질 있게 내야 한다고 봄
• C를 배우는 문제에서는 언어 자체보다 컴퓨터가 어떻게 동작하는지 이해하는 것이 더 중요함
  • CPU 스케줄링, 메모리, 캐시 계층, 파일 시스템, 디스크와 파일 접근을 이해해야 함
  • C, Zig, Rust처럼 syscall 계층 바로 위에서 작업하면 무슨 일이 일어나는지 이해하기 쉬움
  • Python, JavaScript, Ruby의 파일 열기 API는 많은 세부를 추상화함
  • 표준 라이브러리 함수도 당연하게 여기지 말고, 누군가가 쓴 코드이므로 직접 읽고 어떻게 동작하는지 파고들어야 한다고 조언함