Ghostty를 만든 미첼 하시모토가 말한 터미널, Zig, 오픈소스

터미널은 브라우저가 아니에요, Ghostty를 만든 미첼 하시모토의 기준

AI 뉴스 썸네일

Vagrant, Terraform, Vault를 만든 미첼 하시모토가 Ghostty와 Zig, 오픈소스 유지보수에 대해 길게 이야기했어요. 새 터미널 기능 하나를 어떻게 넣을지보다 더 흥미로운 대목은 따로 있어요. 좋은 도구를 만들려면 사용자 요청을 그대로 쌓기보다, 어떤 문제들이 같은 뿌리에서 나왔는지 살펴보자는 태도예요.

728x90

핵심 요약

구분	핵심	왜 볼 만한가요
개발자 도구	Ghostty는 빠른 네이티브 크로스플랫폼 터미널을 목표로 커졌어요	터미널을 단순한 셸 창이 아니라 앱 실행 환경으로 보는 논의가 다시 살아나고 있어요
시스템 설계	하시모토는 터미널이 브라우저처럼 모든 기능을 품는 방향에는 선을 그어요	텍스트 기반 도구의 장점은 자동화, 조합 가능성, 명확한 보안 모델에 있어요
오픈소스	유지보수자는 모든 요청을 받아야 하는 사람이 아니라고 봐요	기능 풍부함과 코드 부풀림을 가르는 기준이 제품 품질과 직접 이어져요
Zig와 AI	큰 언어 변경은 부담이지만, 반복 수정은 AI가 어느 정도 줄일 수 있다고 봐요	하위 호환성과 개발 도구의 역할을 다시 생각하게 해요

1. Ghostty는 빠른 터미널보다 넓은 질문을 던져요

Ghostty는 하시모토가 GPU 프로그래밍, 데스크톱 시스템 프로그래밍, Zig를 다시 배우려고 시작한 개인 프로젝트였어요. 처음에는 Vim과 컴파일러를 돌리고, Ghostty가 자기 자신을 빌드하면 버릴 생각이었다고 해요. 그런데 터미널 생태계를 보면서 빠르고 기능이 풍부하며 네이티브 앱처럼 동작하는 크로스플랫폼 터미널이 부족하다고 느꼈고, 친구들이 매일 쓰기 시작하면서 프로젝트가 커졌어요. 1

이 인터뷰에서 중요한 건 “터미널을 더 강하게 밀어붙이자”라는 단순한 구호가 아니에요. 하시모토는 터미널이 브라우저처럼 영상, 마이크, 반응형 레이아웃까지 모두 품는 방향에는 조심스러워해요. 브라우저, 데스크톱 앱, 텍스트 기반 고정폭 앱은 각자 잘하는 일이 달라요. 터미널 기반 앱의 강점은 빠른 구현, 자동화, 조합 가능성, 비교적 분명한 보안 모델에 있어요. 2

그가 특히 문제로 보는 부분은 PTY의 비구조적 바이트 스트림이에요. 지금의 터미널은 이스케이프 시퀀스를 섞은 인밴드 신호에 많이 기대요. 그래서 구조화된 데이터와 상호작용을 다루기 어렵고, 스크롤백으로 넘어간 화면 요소를 다시 클릭하거나 앱 내부 이벤트로 연결하는 일도 매끄럽지 않아요. PowerShell이나 Nushell이 거론되는 이유도 여기에 있어요. 셸과 터미널이 문자열만 흘려보내는 모델에서 벗어나면, 개발자 도구가 더 조합하기 쉬운 형태로 바뀔 수 있어요.

새 터미널 API 논의가 개발자 도구 흐름과 맞닿아 있어요

하시모토는 n-screen API와 버튼 프로토콜 같은 아이디어를 꺼내요. 현재 터미널은 보통 셸과 스크롤백을 다루는 main screen, Neovim 같은 TUI가 쓰는 alternate screen 정도로 나뉘어요. 그는 여러 화면을 백그라운드에 만들고, 크기가 다른 그리드를 겹치고, 터미널 에뮬레이터가 줄바꿈과 선택, 마우스 이벤트를 처리하는 모델을 상상해요. Neovim 탭을 네이티브 창 탭처럼 여는 예시도 나와요.

버튼 프로토콜은 Claude Code 같은 main screen 앱과도 연결돼요. 지금은 화면에 남아 있는 셀을 클릭할 때만 이벤트를 받기 쉬워요. 출력이 스크롤백으로 밀려나면 파일 열기나 앱 내부 링크 같은 상호작용이 끊겨요. 터미널이 텍스트 로그와 앱 UI 사이 어딘가에 머무는 한계가 여기서 보여요. 개발자용 에이전트, 접근성, 자동화 도구가 늘수록 이런 논의는 더 자주 나올 수 있어요.

오픈소스 유지보수는 고객지원과 달라요

인터뷰에서 가장 날카로운 부분은 오픈소스 유지보수에 대한 이야기예요. 하시모토는 오픈소스 유지보수자가 사용자에게 의무를 지지 않는다고 말해 왔어요. 무료 소프트웨어를 받는 대신 사용자는 사용, 수정, 포크할 권리를 얻어요. 안정성 보장이나 유지보수 요구권은 그 권리에 포함되지 않는다는 입장이에요. 2

그렇다고 사용자 문제를 무시한다는 뜻은 아니에요. 그는 좋은 소프트웨어를 만들고 싶어서 문제를 고치려는 책임감은 느낀다고 해요. 다만 모든 이슈와 PR을 그대로 받아들이면 비전이 사라지고, 특정 사용자 한 명의 문제를 긁어주는 코드가 계속 쌓인다고 봐요. 여러 기능 요청을 깊게 들여다본 뒤, 하나의 기능으로 동시에 풀 수 있는지 보는 쪽을 더 중요하게 여겨요.

Ghostty의 검색 기능 논쟁도 같은 맥락이에요. 어떤 사용자는 검색 기능이 미니멀리즘을 해친다고 봤지만, 하시모토는 Ghostty를 기능이 풍부한 터미널로 설명해요. 대신 쓰지 않는 기능이 실행 비용을 만들지 않게 설계하는 게 중요하다고 봐요. 기능이 많다는 것과 코드가 부풀어 사용자를 방해하는 것은 다른 문제라는 이야기예요.

Zig의 변화와 AI 코딩은 하위 호환성 논의를 흔들어요

하시모토는 Zig가 아직 큰 변경을 감수하는 언어라는 점을 알고 선택했다고 말해요. Zig 0.15의 writer 인터페이스 변경처럼 출력 코드 대부분에 영향을 주는 변화도 있었지만, API 자체는 더 좋아졌다고 봐요. 컴파일 도구와 속도에 집중하는 Zig의 방향도 좋게 평가해요.

흥미로운 대목은 AI예요. 그는 스스로 AI 과열론자는 아니라고 선을 그으면서도, 언어 변경으로 생기는 반복 수정에는 AI가 도움이 된다고 봐요. A 상태에서 B 상태로 바꾸는 예시를 여러 맥락에서 보여주면, 큰 diff의 상당 부분을 자동으로 처리할 수 있었다고 말해요. 이 관점에서는 하위 호환성이 지금보다 덜 절대적인 가치가 될 수도 있어요. 물론 출시할 코드는 사람이 읽고 이해해야 한다는 조건을 함께 붙여요.

왜 중요한가요

이 인터뷰는 Ghostty 소개 글보다 개발자 도구를 만드는 태도에 가까워요. 터미널을 더 화려하게 만들자는 말보다, 텍스트 기반 도구가 잘하는 영역을 지키면서 어떤 구조를 새로 넣을지 고민하는 방식이 눈에 띄어요. 개발팀이 CLI, TUI, 에이전트형 도구를 만들 때도 같은 질문을 하게 돼요. 이 기능이 사용자의 요청 하나를 닫는 데서 끝나는지, 아니면 여러 문제를 더 단순한 시스템으로 묶는지 봐야 해요. 2

오픈소스 이야기도 현실적이에요. 인기 있는 프로젝트일수록 사용자는 제품 수준의 지원을 기대하지만, 유지보수자는 모든 요청을 받아야 하는 고객지원 조직이 아니에요. 대신 프로젝트가 어떤 원칙을 갖고 기능을 고르는지, 사용하지 않는 기능의 비용을 어떻게 낮추는지, 포크와 권리를 어떻게 받아들이는지가 품질을 가르는 기준이 돼요. 1

Zig와 AI 코딩에 대한 부분은 개발 도구의 다음 과제를 보여줘요. 빠르게 바뀌는 언어와 프레임워크를 쓰면서도 코드를 이해하고 책임져야 해요. 반복 수정은 도구가 줄여 줄 수 있지만, 무엇을 합칠지, 무엇을 거절할지, 어떤 API가 오래 버틸지는 여전히 사람이 판단해야 해요. 2

참고 자료

1. 미첼 하시모토 인터뷰: Ghostty, Zig, 오픈소스 유지보수 — GeekNews
2. Interview With Mitchell Hashimoto — Alex Alejandre