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

 (alexalejandre.com)
9P by GN⁺ | ★ favorite | 댓글 2개
  • 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는 많은 세부를 추상화함
    • 표준 라이브러리 함수도 당연하게 여기지 말고, 누군가가 쓴 코드이므로 직접 읽고 어떻게 동작하는지 파고들어야 한다고 조언함

함께 보면 좋은 글 β

unsure4000   [-]

비슷한 시간에 올라왔는데 분위기가 너무 달라서 재밌네요 ㅋㅋㅋㅋㅋ
Bun의 Rust 재작성에 대한 제 생각

답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 멋진 인터뷰였고, 가장 좋았던 문장은 “전부 동의하지는 않지만, 당당하게 이상한 모습을 정말 존중한다”였음
    이런 태도가 더 많아졌으면 함

  • 선행 사례와 터미널의 진화를 이야기한다면 Arcan과 cat9도 최소한 언급해야 할 듯함
    https://arcan-fe.com/2022/04/…

  • “PowerShell은 구조화된 데이터를 잘 다룬다”는 대목에서 Jörg W Mittag의 이 답변이 떠올랐음
    타입이 있는 인자를 쓰면 파싱은 전부 PowerShell이 처리함
    Neovim 탭이 네이티브 창 탭으로 동시에 열리는 상상도 정말 멋짐
    C, Zig, Rust처럼 시스템 호출 계층 바로 위에서 작업하면 무슨 일이 벌어지는지 이해하는 데 큰 도움이 됨
    기계와 프로그래머 사이의 추상화를 벗겨내 기반층에 닿는 과정은 재미있고, 문제의 본질에 더 가까워지게 해줌
    표준 라이브러리는 보통 이식성을 목표로 하다 보니 운영체제 기능의 최소공통분모를 담게 되는데, 플랫폼을 최대한 활용할 수 있을 때 프로그래밍이 훨씬 더 즐거워짐
    표준 라이브러리 함수도 누군가가 쓴 코드이니 당연하게 여기지 말고 읽어보라는 태도에는 큰 존중이 감
    Ghostty의 후원 프로그램도 더 알고 싶음. 비영리로 법인화된 것 같은데, 얼마나 성공적이고 자립 가능한지 궁금함

  • Windows의 PowerShell은 이 정의에 따르면 완전히 내부형이라는 장점이 있지만, .NET 프레임워크 위에 구축되어 거의 모든 Windows API에 접근하고 상호운용할 수 있어서 실제로는 크게 제한되지 않음
    UNIX는 설계상 외부형이고, Nushell의 구조화된 답은 이해하기로는 엄격히 내부형이라 확장성이 떨어짐
    Oils는 외부 구조화 상호운용을 위해 json 또는 자체 확장인 json8에 베팅하지만, 둘 다 PowerShell에 비하면 꽤 제한적으로 느껴짐
    모두 stdout으로 msgpack 같은 것만 보내기로 합의하고 모든 터미널을 msgpack 뷰어로 만들면 어떨까 싶음. libc에 파이프 직렬화/역직렬화를 넣자는 청원이라도 해야 할 듯함
    터미널 표준화 기구가 사라진 것뿐 아니라, 셸 세계도 프로덕션 기준으로는 거의 혁신이 없었음
    Bash는 아직도 Kornshell에 이미 있던 기능을 추가하고 있고, Unix 셸에는 없애는 법을 아무도 모르는 함정이 너무 많으며, POSIX는 거의 움직이지 않음
    Oils나 Nushell이 주요 배포판에 채택되어 이 영역의 혁신이 좋은 일이라는 걸 사람들이 깨닫는 꿈을 아직도 붙잡고 있음
    그래도 kitty가 터미널 영역에서 확실히 물꼬를 텄고, 조율은 부족해도 혁신이 일어나는 단계까지는 온 듯함

  • Mitchell의 차분한 긍정·부정 판단을 크게 존중하게 됨
    훌륭한 터미널을 만들고 터미널 인터페이스를 좋아하지만, 터미널이 모든 것을 하거나 극단으로 밀어붙이는 데는 동의하지 않음
    프로그래밍 언어와 커뮤니티를 깊이 신경 쓰고 각 언어가 고유한 모습을 갖길 바라지만, 언어는 결국 목적을 위한 수단이고 밑바탕의 이해가 더 중요하다는 점도 알고 있음
    Rust 커뮤니티를 개인적으로 싫어한다는 점은 인정하면서도 다르게 느끼는 사람을 깎아내리지 않음
    인터넷을 여러 부족의 집합으로 보지만 부족주의나 “유일한 참 부족” 찾기에 빠지지 않는, 꽤 선(禪) 같은 태도가 인상적임

  • 더 많은 개인용·유지보수 포크가 있어야 한다는 생각에는 공감하지만, 어떻게 장려할지는 잘 모르겠음
    권리의식 스펙트럼의 낮은 쪽에서는 유료 지원 계약 같은 기업용 요소에는 관심 없고, 좋아하는 패키지 관리자에서 그대로 설치할 수 있는 편의성만 원할 수도 있음
    brew install이나 apt install에서 복제한 저장소와 빌드 도구를 다루는 단계로 넘어가는 초기 마찰을 어떻게든 줄여야 함
    더 빠른 컴파일러가 도움이 될 수 있음
    다만 보안에 민감한 소프트웨어에서는 사용자가 너무 많은 변경을 하지 않는 편이 이익일 수 있어서, 그 마찰 자체가 기능일 때도 있음

  • n-screen과 버튼 명세 사이의 중간쯤 되는 무언가가 현대 UI에 필요하다는 데 강하게 동의함
    어쩌면 의미 계층이라고 부르면 충분할지도 모름
    이 계층이 있으면 에이전트형 도구나 메인 화면 도구, 접근성, 조합 가능한 위젯과 컨트롤 같은 것들이 가능해짐
    n-screen과 버튼은 결국 얼마나 많은 내용을 표현하느냐의 좌우 경계처럼 보임
    이상적으로는 이 의미 계층이 다중 커서, 문자 단위 줄바꿈이 아닌 단어 단위 줄바꿈, 오버레이(z-index, 셀 블렌딩 등) 같은 것도 가져와야 함

답변달기