고스트티 만든 미첼 하시모토가 말하는 터미널, 지그, 오픈소스의 진짜 문제

고스트티는 ‘터미널이 궁금해서’ 시작한 프로젝트였음

• 미첼 하시모토는 바그란트(Vagrant), 패커(Packer), 컨설(Consul), 테라폼(Terraform), 볼트(Vault), 노매드(Nomad)를 만든 그 사람임

  • 지금은 터미널 에뮬레이터 고스트티(Ghostty)와 바우치(Vouch)를 만들고 있음
  • 이번 인터뷰는 창업담이나 제품 홍보보다, 터미널·지그·오픈소스 철학 쪽으로 깊게 들어감

• 고스트티의 출발점은 “터미널 에뮬레이터가 실제로 어떻게 돌아가는지 모르겠다”는 호기심이었음

  • 하시모토는 약 15년 동안 CLI 앱을 만들었지만, 정작 터미널 내부 구조는 제대로 몰랐다고 함
  • 해시코프를 떠난 뒤 기술 감각을 다시 날카롭게 만들고 싶었고, 목표가 세 가지였음
  • AI 이전식 GPU 프로그래밍, 데스크톱·단일 노드 시스템 프로그래밍, 그리고 지그(Zig)를 제대로 써보는 것

• 원래는 빔과 컴파일러가 돌아가고, 자기 자신을 빌드할 수 있는 터미널을 만든 뒤 버릴 생각이었다는 게 재밌는 포인트임

  • 그런데 막상 파보니 “빠르고, 기능 많고, 네이티브로 크로스플랫폼인 터미널”이 딱히 없다고 느꼈음
  • 친구 몇 명에게 디스코드로 공유했더니 실제로 매일 쓰기 시작했고, 그 친구방이 고스트티 디스코드로 바뀜
  • 본인 이름값 때문에 과도한 관심이 붙을까 봐 오랫동안 비공개 베타로 굴렸다고 함

터미널을 브라우저처럼 만들자는 얘기는 아님

• 하시모토는 터미널을 끝까지 밀어붙여서 모든 앱 플랫폼을 대체하자는 쪽은 아님

  • 브라우저는 브라우저대로 잘하는 게 있고, 데스크톱 앱은 데스크톱 앱대로 잘하는 게 있다고 봄
  • 터미널의 강점은 모노스페이스 그리드 기반 텍스트 앱이 빠르게 만들기 쉽고, 상호작용이 단순하고, 보안 모델이 비교적 명확하다는 점임

• 진짜 관심사는 터미널 앱의 조합성(composition)과 자동화 가능성을 더 키우는 쪽임

  • CLI 도구는 표준 입력·출력뿐 아니라 다양한 플래그와 인터페이스로 함수처럼 조합되기 쉬움
  • 네오빔(Neovim)이나 AI 코딩 도구들도 점점 더 많은 커맨드라인 옵션을 제공하고 있음
  • 더 나은 터미널 앱 생태계는 곧 더 나은 자동화와 스크립팅 생태계라는 주장임

• 그래서 그는 “새 터미널 API”를 만들 때 기존 앱 플랫폼의 수십 년짜리 선례를 먼저 보겠다고 함
  • 웹은 DOM과 자바스크립트 API가 있고, 애플 쪽은 앱킷(AppKit)·코코아(Cocoa)·스위프트UI(SwiftUI)가 있음
  • 윈도우에는 윈32(Win32)와 윈UI(WinUI), 리눅스에는 GTK와 Qt가 있음
  • 예를 들어 클립보드가 텍스트뿐 아니라 이미지와 여러 MIME 타입을 다뤄야 한다면, 각 플랫폼의 클립보드 설계를 먼저 조사해야지 터미널 진영만의 감으로 새로 만들 필요는 없다는 태도임

그가 생각하는 새 터미널 프로토콜 두 가지

• 첫 번째는 “n-screen API”임

  • 지금 터미널에는 사실상 메인 화면과 대체 화면(alt screen) 두 개만 있음
  • 셸은 메인 화면에서 스크롤백을 쓰고, 네오빔이나 대부분의 TUI는 대체 화면으로 전체 화면을 가져가는 식임
  • 하시모토는 무제한에 가까운 여러 화면을 백그라운드에 만들고, 서로 다른 그리드 크기로 오버레이하고, 터미널 에뮬레이터가 줄바꿈·선택·마우스 이벤트 라우팅을 처리하는 구조를 상상함

• 이게 되면 네오빔 탭이 터미널 안의 가짜 탭이 아니라 네이티브 창 탭처럼 열리는 그림도 가능해짐

  • 단순한 편의 기능이 아니라, 텍스트 앱이 화면을 다루는 기본 모델 자체를 바꾸는 레이어에 가까움
  • 터미널이 모든 앱을 흉내 내는 게 아니라, 텍스트 앱에 맞는 더 좋은 창 관리 모델을 주자는 쪽임

• 두 번째는 버튼 프로토콜임

  • 지금 터미널에는 마우스 프로토콜이 있지만, 현재 화면에 보이는 그리드 셀 클릭 정도만 다루는 한계가 있음
  • 스크롤백으로 밀려난 기록에서는 앱 내부 링크나 파일 열기 같은 상호작용이 사라져버림
  • 하시모토는 OSC 8 하이퍼링크처럼, 특정 텍스트를 클릭하면 프로그램에 지정된 메시지를 보내는 버튼 모델을 생각하고 있음

sequenceDiagram
    participant 사용자
    participant 터미널
    participant 셸앱
    participant 스크롤백
    사용자->>터미널: 출력 기록에서 버튼 클릭
    터미널->>스크롤백: 클릭 대상과 등록된 메시지 확인
    스크롤백-->>터미널: open_profile 같은 동작 식별자 반환
    터미널->>셸앱: 지정된 메시지 전달
    셸앱-->>사용자: 파일 열기나 앱 내부 동작 실행

오픈소스에 대한 입장은 꽤 매움

• 하시모토는 오픈소스 유지보수자가 사용자에게 의무를 진다는 생각에 매우 비판적임

  • 오픈소스 라이선스의 첫 줄은 보통 “있는 그대로, 보증 없음”이라는 점을 강조함
  • 공짜 소프트웨어를 받았다고 해서 유지보수자에게 요구할 권리가 생기는 건 아니라는 입장임

• 그렇다고 문제를 안 고치겠다는 뜻은 아님

  • 좋은 소프트웨어를 만들고 싶기 때문에 버그를 고치고 개선하려는 책임감은 느낀다고 함
  • 다만 어떤 날은 이슈만 처리하고, 어떤 날은 아무 이슈도 안 읽고 본인이 원하는 큰 방향을 밀어붙인다고 함
  • 사용자 요청만 매일 처리하면 안정적이지만 정체된 소프트웨어가 되고, PR을 다 받아주면 방향 없는 코드 산이 된다는 얘기임

• 고스트티의 검색 기능 논쟁도 그 철학을 잘 보여줌

  • 검색은 가장 많이 요청된 기능 중 하나였고 이미 출시됐음
  • 누군가는 이 기능이 미니멀리즘을 깨는 bloating이라고 비판했지만, 하시모토는 고스트티를 애초에 “기능 많은 터미널”로 소개한다고 반박함
  • 다만 안 쓰는 기능 때문에 런타임 비용을 내게 하지는 않도록 설계했다고 함. 디스크와 메모리에는 올라가도 실행 경로에는 들어가지 않는 식임

• 그는 개인 포크와 유지되는 포크가 훨씬 많아져야 한다고 봄
  • 벤처 투자 기반 오픈소스가 늘면서, polished 웹사이트와 유료 지원팀이 붙은 “제품형 오픈소스”를 기본값처럼 기대하는 세대가 생겼다고 진단함
  • 하지만 오픈소스의 핵심은 안정성 보장이나 유지보수 의무가 아니라, OSI 승인 라이선스가 보장하는 자유와 권리라고 봄
  • 더 강한 보증과 책임 소재를 원하면 돈을 내고 벤더-고객 관계를 맺어야 한다는 말도 나옴

지그의 불안정성, AI, 그리고 호환성의 미래

• 하시모토는 지그가 아직 1.0이 아니어도 괜찮다는 쪽임

  • 그는 지그에 컴파일러 패치를 하면서 들어왔고, 커뮤니티 문화와 철학을 알고 선택했기 때문임
  • 지그의 BDFL인 앤드루가 필요하다고 믿는 변경을 인기와 무관하게 밀어붙이는 점도 다운스트림 사용자 입장에서 좋게 본다고 함

• 지그 0.15의 writer 인터페이스 변경은 꽤 큰 사건으로 언급됨

  • “뭔가를 출력하는 거의 모든 코드”에 영향을 주는 변경이었다고 함
  • 그래도 새 API가 훨씬 낫다고 평가함
  • 지그 팀은 컴파일 속도를 위해 언어 기능을 제거하기도 하는데, 하시모토는 이걸 거의 충격적으로 좋게 보는 쪽임

• AI가 언어 변경의 고통을 줄인다는 관찰도 흥미로움

  • 그는 AI 과대광고를 하는 사람이 아니라고 선을 긋지만, 패턴 매칭과 패턴 채우기에는 신경망이 아주 강하다고 봄
  • 지그 변경처럼 “상태 A에서 상태 B로 어떻게 옮기는지” 몇 가지 예시를 보여주면, 큰 diff의 90%를 자동으로 처리할 수 있었다고 함
  • 본인은 부엌에 있는 동안 AI가 대부분을 처리했다는 식으로 설명함

• 이 말은 백워드 호환성(backward compatibility)의 의미가 바뀔 수 있다는 주장으로 이어짐

  • 예전에는 API 변경이 곧 다운스트림 전체의 고통이었음
  • 그런데 마이그레이션 방법을 명확히 설명할 수 있고 AI가 반복 작업을 처리한다면, 깨지는 변경의 비용이 전보다 낮아질 수 있음
  • 아이러니하게도 지그는 강한 반AI 정책을 갖고 있는데, 하시모토는 AI가 지그식 변화의 통증을 줄여준다고 봄

좋은 API 설계는 ‘많이 써본 감각’에서 나온다는 얘기

• 라이브러리와 API 설계에 대해 그는 거창한 방법론보다 다양한 생태계를 많이 써본 경험을 강조함

  • 프로로그(Prolog), 하스켈(Haskell), 클로저(Clojure), 자바(Java) 같은 언어로 장난감 프로젝트를 만들며 배운 게 많았다고 함
  • 각 생태계에는 인간 문화가 있고, 그 문화가 관심사의 분리 방식과 API 모양에 스며든다고 봄
  • 예를 들어 자바에서 흔한 빌더 패턴을 루비에 가져와보니 꽤 괜찮았다는 식임

• 그는 “명사(nouns)가 중요하다”고도 말함

  • 바그란트가 개발 환경에만 집중한 건 의도적인 설계였다고 함
  • 설정, CLI, 개념 모델이 모두 개발 중심 명사로 돌아가게 만든 것이 장점이었다는 얘기임
  • 도커(Docker)는 배포와 런타임 쪽 명사가 너무 많이 섞여 인간의 개발 흐름을 건드린다고 봤다는 맥락도 나옴

• 도구 제작자의 딜레마도 인정함

  • 어떤 문제를 절실히 느껴 이상적인 도구를 만들었는데, 그 도구가 인기를 얻으면 어느 순간 사용자가 아니라 도구 제작자로 멀어진다는 문제임
  • 터미널은 매일 쓰지만 TUI 개발자로서 충분히 dogfooding하고 있지는 않다고 말함
  • 대신 이메일·IRC 클라이언트와 터미널 스펙을 만드는 다른 유지보수자들에게 많이 기대고 있다고 함

큰 회사, AI 코드, 그리고 “좋은 제품”의 기준

• 하시모토는 오늘날 기술 스택에 대해 “괜찮긴 한데 너무 복잡하다”는 쪽임

  • 프론트엔드, 타입스크립트, 리액트 타입 생태계에는 좋은 점이 많지만 추상화 레이어가 너무 불명확하고 churn이 심하다고 봄
  • HTTP/1에서 HTTP/2, HTTP/3로 가는 변화도 복잡도가 비선형적으로 커졌다고 느낌
  • 업계 전체가 “짧은 편지를 쓸 시간이 없어서 긴 편지를 썼다”는 상태에 가깝고, AI가 그 속도를 더 올리고 있다고 봄

• 품질 있게 빨리 ship하려면 제품에 대한 더 큰 이해가 필요하다고 함

  • 특정 사용자 문제가 보인다고 그 문제만 고치면 안 되고, 왜 사용자가 거기까지 오게 됐는지 상위 맥락을 봐야 한다는 얘기임
  • 회사 규모가 커질수록 이걸 잘 못한다고 보고, 본인은 자기 소프트웨어의 강한 사용자이기 때문에 판단할 수 있다고 함
  • 고객과 너무 멀어지면 “스펙 완료”나 “체크박스 처리”만 남고, 결과물이 좋은지 나쁜지 판단하기 어려워진다는 지적임

• AI 코드는 데모와 탐색에는 적극적으로 쓰지만, 그대로 ship하지는 않는다고 선을 그음

  • 그는 AI로 만든 데모 코드를 “완전 쓰레기”라고 표현하면서도, 방향이 유용한지 빠르게 확인하는 용도로는 강력하다고 봄
  • 현재 6주 된 아기가 있어 하루 컴퓨터 시간이 3시간 정도라, 시간 절약 효과가 실제로 크다고 함
  • 단 최종적으로 ship하는 코드는 읽고 이해해야 하며, 사용자가 즐겁게 쓸 수 있게 만드는 책임은 여전히 사람에게 있다고 못 박음

C를 배워야 하나, 바로 지그를 배워야 하나

• 그의 답은 “언어보다 컴퓨터가 어떻게 동작하는지 배우라”에 가까움

  • C를 많이 쓴 건 대학에서 파일 시스템과 운영체제를 배우던 시기였고, C는 저수준 시스템과 접촉하기 위한 수단이었다고 함
  • CPU 스케줄링, 메모리, 캐시 계층, 파일 시스템, 디스크와 파일 접근 같은 기본기를 이해하는 게 더 중요하다고 봄
  • C든 지그든 러스트든 syscall 레이어 바로 위에서 작업해보면 무슨 일이 벌어지는지 훨씬 잘 보인다는 얘기임

• 고수준 언어의 표준 라이브러리를 뜯어보라는 조언도 나옴

  • 파이썬, 자바스크립트, 루비의 파일 열기 API는 많은 걸 감춰줌
  • 표준 라이브러리 함수도 결국 누군가가 쓴 코드고, 직접 읽으면 언어보다 아래의 시스템 감각을 배울 수 있음
  • 결론은 꽤 단순함. 언어는 쉽고, 언어 자체보다 밑바닥 이해가 중요하다는 것임

기술 맥락

• 고스트티의 기술적 선택은 “크로스플랫폼 코어 + 플랫폼별 네이티브 GUI”에 가까워요. 왜냐하면 터미널 에뮬레이터는 렌더링과 프로토콜 처리는 공유할 수 있지만, 창 관리나 입력 처리 같은 데스크톱 경험은 운영체제마다 기대치가 다르거든요.

• PTY를 그대로 두고 기능만 덧붙이는 방식에는 한계가 있어요. 지금 구조는 escape sequence가 섞인 바이트 스트림이라서, 버튼·클립보드·여러 화면 같은 기능을 넣을 때 앱 플랫폼처럼 타입 있는 API로 다루기 어렵기 때문이에요.

• n-screen API 아이디어가 중요한 이유는 터미널의 “화면은 두 개뿐”이라는 전제를 깨기 때문이에요. 셸의 스크롤백과 네오빔 같은 전체 화면 앱 사이에서 매번 모드를 갈아타는 대신, 여러 화면을 만들고 겹치고 이벤트를 라우팅할 수 있으면 TUI 앱 설계가 꽤 달라질 수 있어요.

• 지그의 잦은 변경을 받아들이는 태도도 단순한 취향이 아니에요. 컴파일 속도, API 단순성, 언어 철학을 위해 호환성을 희생하는 선택인데, 하시모토는 AI가 반복적인 마이그레이션 비용을 줄이면 이런 선택의 부담이 낮아질 수 있다고 보는 거예요.

• 오픈소스 유지보수 철학도 기술 의사결정과 연결돼요. 모든 PR을 받아주면 기능은 늘지만 구조가 무너질 수 있고, 모든 이슈를 따라가면 제품은 안정적이지만 정체될 수 있거든요. 그래서 그는 적은 수의 잘 조합되는 기능으로 여러 요구를 함께 해결하는 쪽을 더 높게 쳐요.