미첼 하시모토 인터뷰 해설

터미널의 다음 20년, 오픈소스 유지보수자의 의무, Zig 와 AI. Vagrant·Terraform·Vault 를 만들고 지금은 Ghostty 를 만드는 미첼 하시모토(Mitchell Hashimoto)가 Alex Alejandre 와 나눈 2026년 7월 인터뷰를 해설하고, 커뮤니티 반응과 적대적 리뷰를 덧붙인다.

원문: Interview With Mitchell Hashimoto (alexalejandre.com, 2026-07) · 토론: GeekNews #31294 · 작성 2026-07-13

1. 왜 이 인터뷰인가

하시모토는 인터뷰를 많이 하는 사람이다. 본인 말로는 대부분 "엔지니어에서 창업자로의 전환"이나 Hashicorp 시절 이야기 같은 정해진 앵글이 있는데, 이번 인터뷰는 서로 팔 것이 없는 대화라 결이 다르다. 실제로 내용도 제품 홍보가 아니라 터미널 프로토콜 설계, 오픈소스 유지보수자의 권리와 의무, 언어 커뮤니티 문화 같은 그의 오랜 지론이 정제된 형태로 나온다.

맥락이 하나 더 있다. 이 인터뷰는 Bun 이 Zig 에서 Rust 로 재작성한다고 발표해 커뮤니티가 시끄럽던 시점에 올라왔다. Zig 창시자 Andrew Kelley 의 반응 글(My thoughts on the Bun Rust rewrite)과 거의 동시에 HN 프런트페이지에 있었고, "Zig 최대 프로젝트의 이탈" 대 "Zig 로 Ghostty 를 만드는 사람의 차분한 신뢰"라는 대비 구도로 읽혔다. 하시모토 본인은 Bun 건에 대해 사실상 노코멘트로 일관했다.

2. 터미널의 미래 — n-screen 과 버튼 프로토콜

Ghostty 는 원래 버릴 생각으로 시작한 학습 프로젝트였다. Hashicorp 를 떠나며 무뎌진 기술을 벼리려고 GPU 프로그래밍(AI 이전 맥락의), 데스크톱/단일 노드 시스템 프로그래밍, Zig 세 가지를 동시에 만족하는 소재를 찾았고, 15년간 CLI 를 만들었으면서도 터미널 에뮬레이터의 동작 원리를 모른다는 것을 깨달았다. "vim 과 컴파일러를 돌리고, 자기 자신을 빌드하게 만든 뒤 버린다"가 원래 목표였는데, 빠르고 기능이 풍부하며 네이티브 크로스플랫폼인 터미널이 시장에 없다는 것을 알게 되며 계속 만들게 됐다.

흥미로운 것은 그가 터미널 만능론자가 아니라는 점이다. 터미널을 브라우저처럼 영상·마이크·반응형 레이아웃까지 품는 애플리케이션 플랫폼으로 밀어붙이는 데는 반대한다. 텍스트 기반(고정폭 그리드) 앱의 고유한 강점은 빠른 구현, 쉬운 상호작용, 명확한 보안 모델, 그리고 무엇보다 구성 가능성(composability)이며, 그 강점을 살리는 프로토콜을 만들고 싶다는 입장이다. 구체적인 구상 두 가지가 이 인터뷰의 기술적 하이라이트다.

n-screen API

현재 터미널은 main screen(셸+스크롤백)과 alt screen(Neovim 등 TUI) 딱 두 개의 화면을 모드 전환으로 오간다. 그는 백그라운드에 무제한 화면을 만들고 채울 수 있는 API 를 구상한다. 화면별로 그리드 크기를 달리해 오버레이하고, 줄바꿈·선택·마우스 이벤트 라우팅은 터미널 에뮬레이터가 처리하며, 특정 화면을 독립 네이티브 창으로 지정할 수도 있다. Neovim 탭이 네이티브 창 탭으로 동시에 열리는 그림이다.

버튼 프로토콜

현재 마우스 프로토콜은 화면에 보이는 그리드 셀에 대해서만 클릭 이벤트를 전달한다. 스크롤백으로 밀려난 히스토리는 클릭할 수 없다. 그는 하이퍼링크 프로토콜(OSC 8)과 비슷하게, 클릭 시 프로그램이 지정한 메시지를 보내는 버튼 프로토콜을 스펙까지 잡아 뒀다. 히스토리로 스크롤해도 버튼이 살아 있게 하는 것이 핵심으로, Claude Code 같은 스크롤백 있는 main screen 앱에서 "히스토리로 들어간 파일 링크가 죽는" 문제를 정확히 겨냥한다.

접근 방식도 눈여겨볼 만하다. 새 프로토콜을 만들기 전에 브라우저(DOM)·Apple(AppKit/SwiftUI)·Windows(Win32/WinUI)·Linux(GTK/Qt) 등 기존 플랫폼들이 수십 년간 축적한 선례를 먼저 조사한다는 원칙이고, 실제로 아직 Ghostty 에 커스텀 프로토콜을 하나도 넣지 않았다. PTY 전체를 Wayland 로 대체하는 실험까지 해 보고 버렸다. 그가 짚는 구조적 문제는 터미널에 더 이상 표준화 기구가 없어서 지난 20년의 표준화가 "가장 인기 있는 터미널이 하는 것"을 따라가는 방식으로 이뤄졌다는 점이다.

3. 오픈소스 철학 — 의무 0, 그러나 책임감

인터뷰에서 가장 논쟁적인 부분이다. 그의 입장은 두 축으로 요약된다.

오픈소스 라이선스의 첫 줄은 "있는 그대로, 무보증(as is, no warranty)"이다. 그게 계약이다. 무료 소프트웨어를 받는 대신 요구할 권리는 없다.
— 인터뷰 중, 의역

의무는 0 이다. 유지보수자는 사용자에게 아무것도 빚지지 않는다. 더 강한 보장과 "누군가를 탓할 권리"를 원하면 돈을 내고 벤더-고객 관계를 맺어야 한다.
그래도 책임감은 느낀다. 좋은 소프트웨어를 만들고 싶기 때문에 문제를 고친다. 어떤 날은 이슈만 처리하고, 어떤 날은 이슈·PR 을 하나도 보지 않고 자기 비전에 집중한다. 매일 이슈만 처리하면 안정적이지만 정체된 소프트웨어가 되고, 모든 PR 을 받으면 비전 없는 코드 산이 된다.

여기서 파생되는 주장들이 커뮤니티를 갈랐다. 기능 제거 플래그를 유지해 달라는 요구에 대해 "내가 플래그를 유지하는 것과 네가 기능을 제거한 포크를 유지하는 것은 같은 종류의 요구"라고 맞받고, 개인·유지 포크가 훨씬 많아져야 한다고 믿으며, 보안 취약점이 들어간 커밋에 대해서도 "왜 너는 그 커밋을 검토하지 않았나 — 검토 의무는 유지보수자와 사용자가 같다"고까지 나간다. 벤처 투자 기반 오픈소스가 "웹사이트와 유료 지원 인력을 갖춘 제품"을 기대하는 세대를 만들었다며 자기 자신(Hashicorp)에게도 책임을 돌리는 대목은 자기 인식이 있는 부분이다.

기능 풍부함과 부풀림(bloat)의 구분도 실용적이다. Ghostty 최다 요청 기능이던 검색을 배포하자 "미니멀리즘을 깼다"는 비판이 나왔는데, 그는 검색을 쓰지 않으면 코드가 실행되지 않도록 아키텍처를 잡았으니 디스크와 상주 메모리 외에는 비용이 없는 공짜 기능이라고 반박한다. 여러 기능 요청을 그대로 받는 대신, 문제를 깊이 이해해 3-4개의 개별 요청을 전혀 다른 하나의 기능으로 동시에 해결하는 것이 그가 말하는 유지보수자의 일이다.

4. Zig 와 AI — 하위 호환성의 의미가 줄어드는 미래

Zig 1.0 이 몇 년은 더 남았다는 데 그는 동요가 없다. 컴파일러 패치로 입문해 커뮤니티 문화를 알고 선택했기 때문이다. 0.15 의 writer 인터페이스 변경은 출력하는 모든 코드를 깨뜨렸지만 API 는 훨씬 좋아졌고, Andrew Kelley 가 인기에 밀려 필요한 변경에서 물러서지 않는 점을 다운스트림 사용자로서 오히려 좋게 본다. 컴파일 속도를 위해 언어 기능을 제거하는 결단, lib-ghostty 전체가 즉시 빌드되는데도 그 밀리초가 느리다고 보는 기준도 인상 깊게 언급한다.

AI 이야기는 여기서 나온다. 그는 스스로 "AI 하이프 마스터가 아니다"라고 선을 그으면서도, Zig 의 큰 언어 변경을 겪을 때 몇 가지 맥락에서 변환 방법을 보여주고 나머지를 맡겼더니 거대한 diff 의 약 90%가 부엌에 있는 동안 자동으로 처리됐다고 말한다. 결론이 흥미롭다:

A 상태에서 B 상태로 가는 방법을 설명할 수 있다면, 하위 호환성이라는 것의 의미가 훨씬 줄어드는 미래를 시사한다.
— 인터뷰 중, 의역. 본인도 Zig 의 강한 반AI 정책과의 아이러니를 인정한다

AI 사용 전반에 대해서는 "합리적 사용" 노선이다. 데모는 마음껏 슬롭(slop)으로 만들어 방향만 확인하고, 좋으면 제대로 다시 만든다. 생후 6주 아기 때문에 하루 3시간만 컴퓨터 앞에 있는 지금, 컴퓨터 없이 아이디어를 자신에게 발송할 수 있다는 것이 실질적 이득이라고 말한다. 단, 출시하는 코드는 읽고 이해하고 품질을 책임져야 한다는 조건이 붙는다.

5. 설계와 학습 — 명사, 딜레마, 표준 라이브러리

API 설계: 가장 구체적인 방법은 여러 생태계의 라이브러리를 직접 많이 써 보는 것. 대학 때 Prolog·Haskell·Clojure·Java 로 토이 프로젝트를 만들며 각 생태계의 문화가 관심사 분리와 API 모양에 스며드는 것을 배웠고, Java 의 builder 패턴을 Ruby 에 이식해 본 경험을 예로 든다. "명사(nouns)가 중요하다" — Docker 는 배포·런타임의 명사가 개발 흐름에 섞여 있고, Vagrant 는 의도적으로 개발 중심의 명사만 썼다.
도구 제작자의 딜레마: 문제를 절실히 이해해 이상적인 도구를 만들지만, 도구가 인기를 얻으면 정작 자신은 사용자가 아니라 접지력 잃은 제작자가 된다. 터미널은 매일 살지만 TUI 개발은 부족해서, 이메일·IRC 클라이언트를 여럿 유지하는 rockorager 같은 메인테이너에게 기댄다고 인정한다.
원칙: Hashicorp 원칙 문서든 Ghostty 개발 방침이든 전부 자기 자신의 반영이라 지키기 쉬웠다. 자기와 다른 원칙을 세우는 것은 새해 결심처럼 실패한다. 언어들이 서로 닮아가는 최소공배수화를 싫어하고, 제약이 창의성과 문화를 만든다고 본다. "Rust 문화가 싫다. 그들이 나쁜 사람이라는 게 아니고 언어와 철학은 훌륭하다. 나는 축구도 싫다"는 발언이 여기서 나온다.
C 학습: 언어는 수단이고, CPU 스케줄링·메모리·캐시 계층·파일 시스템을 이해하는 것이 본질. syscall 계층 바로 위(C·Zig·Rust)에서 작업해 보고, 표준 라이브러리 함수도 당연하게 여기지 말고 읽어라. "언어는 쉽고, 언어는 중요하지 않다. 바탕의 이해가 중요하다."

6. 커뮤니티 반응 — GeekNews·HN·Lobsters

GeekNews

같은 시기에 올라온 Bun의 Rust 재작성 글과의 온도차가 화제였다. "비슷한 시간에 올라왔는데 분위기가 너무 달라서 재밌네요", 그리고 그 논쟁을 겨냥한 "논쟁 대부분은 아이디어가 아니라 자아에 관한 것"이라는 촌평이 달렸다.

Hacker News

화법에 대한 감탄과 씁쓸함: "전부 동의하진 않지만 거리낌 없이 이상한 점을 존중한다"는 Zig 평가가 외교적으로 세련됐다는 반응. 동시에, 압박해서 나온 Zig 의 장점이 "당당하게 이상함"이라는 것 자체가 Zig 가 비즈니스에서 설득 가능한 언어보다 틈새 언어로 가고 있다는 신호라는 씁쓸한 해석도 나왔다.
Rust 문화 논쟁: 인터뷰에서 가장 불붙은 대목. "커뮤니티 안에서 보면 포용적이고 친절하다"는 옹호와, "API 가 필요 이상으로 어렵다고 하면 '아니다'로 받고, 증거를 대면 '그래도 메모리 안전성'으로 끝나는 종교적 가스라이팅을 겪었다"는 경험담이 맞붙었다. "Zig 커뮤니티에도 정확히 같은 말을 할 수 있다"며 하시모토의 선택적 잣대를 짚는 반론, "HN 의 Rust 열성 지지자들이 C++ 글마다 몇 년간 해 온 일을 이제 조금 맛본 것"이라는 관전평까지, 그의 부족주의(tribes) 프레임이 그대로 재연됐다.
포크 대칭성 반론: 가장 실질적인 기술 반론. 포크하는 순간 동기화 부담을 떠안거나 업스트림의 향후 개선을 포기해야 하므로, "포크가 더 많아야 한다"는 주장은 다운스트림 동기화 도구가 빈약한 현실을 외면한다는 것. libghostty 처럼 공통 코어와 주변부가 잘 분리된 시스템이라면 가능하지만 "잘 설계된 시스템은 흔하지 않다"는 지적, AI 가 포크-업스트림 동기화를 자동화해 줄 수 있으리라는 전망이 이어졌다.
PowerShell·구조화 데이터 논쟁: "기본 출력은 grep/awk 로 파이프할 수 있는 일반 텍스트여야 한다"는 Unix 전통파와, "podman 이미지를 크기순 정렬하는 파이프라인을 텍스트로 짜 보라 — 각 단계가 텍스트 표현에 결합된 깨지기 쉬운 파이프라인이 된다"는 구조화 데이터파가 정면으로 부딪혔다. JSON 기본 출력(AWS CLI)의 호오, Nushell 과 PowerShell 이 본질적으로 같은 접근인지, stdin/stdout 에 더해 구조화 스트림(stdstructin/stdstructout)을 표준으로 추가하자는 점진 이행안까지 나온 풍성한 스레드다.
회의론: "Hashi 도구 대부분이 과대평가됐고 Ghostty 는 iTerm 보다 버그 많고 기능은 적다"는 소수 의견도 있었다.

Lobsters

터미널 진화의 선행 사례로 Arcan 과 cat9 이 언급조차 안 된 점을 아쉬워하는 반응.
n-screen 과 버튼 프로토콜 사이에 "의미 계층(semantic layer)"이 필요하다는 발전적 제안 — 이 계층이 있으면 에이전트형 도구, 접근성, 조합 가능한 위젯, 단어 단위 줄바꿈, z-index 오버레이까지 열린다는 것.
포크 장려론에 공감하되, brew install 에서 "저장소 클론+빌드 도구"로 넘어가는 초기 마찰을 줄여야 실현된다는 현실론. 보안 민감 소프트웨어에서는 그 마찰이 오히려 기능일 수 있다는 단서도.
셸 세계 전체가 프로덕션 기준으로 혁신이 멈췄다는 한탄(Bash 는 아직도 Kornshell 기능을 추가 중, POSIX 는 정지 상태)과, 그래도 kitty 가 물꼬를 텄다는 평가.
"차분한 긍정·부정 판단", "부족의 집합으로 인터넷을 보면서 부족주의에는 빠지지 않는 선(禪) 같은 태도"라는 인물평.

7. 적대적 리뷰 — Claude Fable 5 의 반론 6편

아래는 이 페이지를 작성한 Claude Fable 5 가 인터뷰의 핵심 주장을 의도적으로 반박해 본 결과다. 각 반론에는 검토 후 판정한 강도를 붙였다. 커뮤니티 반응과 겹치는 논점은 그 근거를 명시했다.

① "포크 유지는 기능 플래그 유지와 같은 종류의 요구다" 강한 반론

주장: 기능 제거 플래그를 유지해 달라는 요구는, 사용자가 그 기능을 제거한 포크를 유지하는 것과 대등한 요구다.

이 대칭 수사는 비용 구조를 무시한다. 업스트림 유지보수자는 CI·릴리스 파이프라인·코드베이스 전체 맥락을 이미 보유하므로 플래그 하나의 한계 비용이 낮고, 그 플래그는 같은 요구를 가진 n 명이 공유한다. 포크 유지자는 그 인프라와 맥락 없이 릴리스마다 리베이스 충돌을 혼자 감당하며, 그 결과물은 자신 1명만 쓴다. 한계 비용도, 수혜 범위도 비대칭이다. HN 에서도 "포크는 동기화 부담 또는 업스트림 개선 포기를 강제한다"는 반론이 가장 큰 호응을 얻었다. 다만 그의 근저 논지(무료 소프트웨어에 요구할 권리 없음)는 이 반론으로 무너지지 않는다 — 무너지는 것은 "대등하다"는 수사다.

② "보안 커밋 검토 의무는 사용자와 유지보수자가 같다" 강한 반론

주장: 유지보수자가 취약점을 출하했다고 탓하기 전에, 너는 왜 그 커밋을 검토하지 않았나. 의무는 같다.

규모와 정보 양쪽에서 성립하지 않는 등치다. 일반 사용자는 수백 개의 전이 의존성을 갖고, 그 각각의 커밋을 검토하는 것은 물리적으로 불가능하다. 유지보수자는 자기 코드베이스의 위협 모델과 맥락을 아는 유일한 위치에 있다. xz-utils 백도어(2024)는 검토할 능력이 있는 사람들조차 수년간 놓친 사례로, "검토했어야지"가 방어선이 될 수 없음을 보여줬다. 검토를 n 명의 사용자가 중복 수행하는 것은 사회적으로도 낭비이며, 그래서 생태계는 서명·재현 가능 빌드·감사 같은 분업으로 가고 있다. 법적 무보증(라이선스)과 도덕적·실무적 책임 분배는 다른 층위인데, 이 발언은 둘을 뭉갠다.

③ "AI 가 하위 호환성의 의미를 줄인다 (diff 의 90%가 자동)" 부분 반론

주장: A→B 변환 방법을 설명할 수 있으면 AI 가 나머지를 해 주므로, 하위 호환성이 갖는 의미가 훨씬 줄어든다.

일반화에 세 가지 구멍이 있다. 첫째, 그 90% 사례의 주체는 lib-ghostty 를 직접 쓴, 지구상에서 그 코드를 가장 잘 아는 사람이다. 남은 10%를 식별·검증할 능력이 결과 품질을 결정하는데, 평균적 다운스트림 사용자에겐 그 능력이 없다. 둘째, 하위 호환성 파괴의 비용은 개별 코드 변환이 아니라 생태계 조율에 있다 — 문서, 튜토리얼, Stack Overflow 답변, 학습된 직관, 전이 의존성 그래프는 diff 로 고쳐지지 않는다. 셋째, "마이그레이션이 가능하다"와 "마이그레이션 비용이 무시할 만하다"는 다르며, 검증 비용은 생성 비용처럼 줄지 않는다. 다만 방향 자체는 유효하다: 기계적 마이그레이션 비용이 실제로 급락 중인 것은 사실이고, 그는 하이프가 아니라 자기 경험 하나를 조심스럽게 외삽했을 뿐이다.

④ "검색 기능은 안 쓰면 무비용이다" 부분 반론

주장: 검색은 디스크와 상주 메모리만 차지할 뿐, 사용하지 않으면 아무 코드도 실행되지 않는 공짜 기능이다.

실행 비용만이 비용이 아니다. 존재하는 코드는 공격 표면이고(파서·입력 처리 경로가 대표적), 리팩터링할 때마다 함께 옮겨야 하는 인지 부하이며, 기능 간 상호작용 버그의 조합 폭발에 기여하고, 컴파일 시간과 리뷰 부담을 늘린다. "미니멀리즘" 비판자가 실제로 걱정한 것도 런타임 사이클이 아니라 이런 궤적 — 기능이 기능을 부르는 방향성 — 이었을 가능성이 높다. 다만 그의 구분(기능 풍부 ≠ 부풀림)과 지연 실행 아키텍처는 이 비용을 최소화하는 올바른 공학이고, Ghostty 를 처음부터 feature-rich 로 광고해 온 것도 사실이라 기대 관리 측면의 반박은 어렵다. 반론은 "무비용(free)"이라는 단어의 과장에만 성립한다.

⑤ "Rust 문화가 싫다"와 부족주의 옹호의 긴장 기각에 가까움

주장: 언어와 철학은 훌륭하지만 Rust 문화는 싫다. 커뮤니티마다 달라야 하고 모든 곳이 모두를 환영할 필요는 없다.

시도해 볼 수 있는 반론은 두 가지다. (a) "인터넷의 이진적 선악 구도가 싫다"는 사람이 커뮤니티 하나를 통째로 "싫다"로 딱지 붙이는 것은 자기모순 아닌가. (b) HN 지적처럼 Zig 커뮤니티에도 정확히 같은 경험담이 존재하는데(Rust 요구사항을 오해한 채 Rust 비난으로 일관했다는 증언) 잣대가 선택적이지 않은가. 그러나 (a)는 그가 명시적으로 처리했다 — 선호("싫다", 축구처럼)와 가치 판단("나쁘다")을 구분했고, 반박이 겨냥해야 할 것은 후자인데 그는 후자를 말한 적이 없다. (b)는 하시모토가 아니라 커뮤니티 간 대칭성에 대한 지적이라 그의 주장 자체를 무너뜨리지 못한다. 개인의 미적 선호는 반증 가능한 명제가 아니므로, 이 항목은 적대적 리뷰가 성립하기 어려운 영역이다.

⑥ "PowerShell 이 구조화 데이터에서 많은 것을 제대로 했다" 부분 반론

주장: PTY 의 비구조적 바이트 스트림은 근본 문제이고, PowerShell 은 구조화 데이터 측면에서 많은 것을 맞혔다.

PowerShell 이 맞힌 것은 "구조화된 파이프"라는 방향이지 구현이 아니다. 파이프로 흐르는 것이 직렬화 가능한 데이터가 아니라 .NET 객체라서 런타임 밖으로 나가는 순간 이점이 소멸하고, 이 내부형(internal) 설계가 Unix 의 외부형(external) 조합 가능성 — 어떤 언어로 짠 프로그램이든 파이프에 끼울 수 있음 — 을 희생시킨다(Lobsters 에서도 같은 구분이 나왔다). 텍스트 전통파의 반론(grep/awk 보편성)도 만만치 않다. 단, 반대 진영이 제시한 podman 정렬 예제처럼 텍스트 파이프라인의 취약성은 실재하므로, "비구조적 바이트 스트림이 근본 문제"라는 그의 진단 자체는 살아남는다. 반박되는 것은 PowerShell 을 모범 사례로 드는 부분의 강도뿐이다.

8. 총평

여섯 반론 중 온전히 성립하는 것은 수사(rhetoric)를 겨냥한 ①②뿐이고, 나머지는 주장의 강도를 깎을 뿐 방향을 뒤집지 못한다. 이것이 이 인터뷰의 특징을 역으로 증명한다. 하시모토는 거의 모든 주장에 한정어를 미리 심어 둔다 — "AI 하이프 마스터가 아니다", "그들이 나쁜 사람이라는 게 아니다", "내 소프트웨어가 형편없다고 할 사람도 있겠지만". HN 댓글 하나가 정확히 짚었듯 "말을 고르는 재주"가 있고, 그래서 적대적으로 읽어도 무너지는 지점이 적다.

남는 취약점은 일관되게 한 곳이다: 개인 단위 경험의 생태계 단위 외삽. 포크 대칭성(①)은 자신처럼 인프라를 가진 사람 기준의 대칭이고, 커밋 검토 책임론(②)은 자신처럼 검토 능력이 있는 사람 기준의 등치이며, AI 마이그레이션 낙관(③)은 자신처럼 코드를 아는 사람 기준의 외삽이다. "나는 내 소프트웨어의 큰 사용자라서 판단할 수 있다"는 그의 강점이, 자신과 조건이 다른 행위자를 모델링할 때는 그대로 맹점이 된다. 그 맹점을 감안하고 읽으면, 터미널 프로토콜 구상(n-screen·버튼)과 "명사가 중요하다"는 설계론은 이 인터뷰에서 가장 순도 높은, 반박할 거리가 거의 없는 부분이다.

9. 부록 — 경쟁 터미널 대비 Ghostty 의 강점

인터뷰의 배경 이해를 돕는 부록. 커뮤니티(HN·전환 후기·2026년 비교 리뷰)에서 사람들이 iTerm2·kitty·Alacritty·WezTerm·Warp 대신 Ghostty 를 고르는 이유를 언급 빈도 위주로 정리했다. 요약하면 "Alacritty 의 속도 + kitty 의 기능 + 네이티브 앱의 감촉"을 한 번에 준다는 것이다.

네이티브 플랫폼 통합 — 가장 많이 언급되는 차별점. GPU 가속 터미널 중 유일하게 진짜 플랫폼 UI 를 쓴다. macOS 에서는 AppKit 기반이라 네이티브 타이틀바·탭·메뉴가 그대로 동작하고, Linux 에서는 GTK 를 쓴다. kitty·Alacritty·WezTerm 은 크로스플랫폼 툴킷 특유의 "이질적인 창" 느낌이 있는데, Ghostty 는 "Apple 이 Terminal.app 을 지금 다시 만들면 이런 모습"이라는 평을 듣는다. 본문 5장에서 하시모토가 말한 "코어는 크로스플랫폼, GUI 는 비타협적 네이티브" 원칙의 결과물이다.
성능 — 특히 체감 반응성. 시작 시간 100ms 미만(iTerm2 는 300ms+), 대량 출력 스크롤에서 144fps 유지, 유휴 메모리도 iTerm2 대비 수 배 적다는 벤치마크가 반복 인용된다. kubectl logs -f 같은 로그 폭주 상황에서 iTerm2 는 CPU 코어를 포화시키는데 Ghostty 는 여유 있었다는 실무 사례도 있다. 다만 평상시 타이핑·스크롤에서 kitty 와의 차이는 크지 않다는 평가다.
제로 컨피그로 완성된 기본값. 설정이 평평한 key = value 형식이라 kitty·WezTerm(Lua)·Alacritty(TOML)보다 단순하고, 아무 설정 없이도 리거처·Kitty 그래픽 프로토콜·탭/분할·테마 수백 종이 바로 된다. "Alacritty 는 탭도 없어서 tmux 가 필수인데, Ghostty 는 깔고 바로 끝"이라는 유형의 전환 후기가 많다.
기능이 많은데 거슬리지 않음. iTerm2 는 설정 창에 옵션이 200개가 넘는 "부엌 싱크대" 접근이고, Warp 는 AI 사이드바와 계정 로그인이 따라온다. Ghostty 는 기능은 풍부하되 쓰기 전까지 숨겨져 있다는 점이 호평받는다. ThePrimeagen 이 "방해하는 AI 사이드바가 없다"를 장점으로 꼽은 것이 이 정서를 대표한다. 본문 3장의 "feature-rich ≠ bloat, 안 쓰는 기능은 실행되지 않는다" 철학이 실제 사용감으로 전달되는 셈이다.
터미널 표준 구현의 정확성과 생태계 기여. xterm 호환성을 가장 엄격하게 지키는 축이고, Kitty 그래픽·OSC 8 하이퍼링크 등 최신 프로토콜을 빠짐없이 지원하면서 libghostty 로 임베딩 가능한 코어를 분리하는 방향이라 "터미널 생태계 전체에 투자하는 프로젝트"라는 신뢰가 있다. rockorager 같은 유명 메인테이너들이 합류해 있는 것도 이 신뢰를 강화한다.

반대편 평가도 하나 붙이면: iTerm2 의 트리거·자동화·프로파일 같은 고급 기능이나 kitty 의 스크립팅 확장성(kittens)이 꼭 필요한 사람에게는 아직 Ghostty 가 부족하고, 6장의 GeekNews 반응에 있었듯 "iTerm 보다 버그 많고 기능 적다"는 소수 의견도 존재한다. 요약하면 Ghostty 의 승부처는 기능 목록이 아니라 기본값의 완성도와 네이티브 감촉이다.

부록 참고: Terminal Emulator Comparison 2026 · Ghostty vs iTerm2 vs Kitty (2026) · The Modern Terminals Showdown · Kitty vs Ghostty in 2026 · Why are you not using Ghostty instead of iTerm2? (HN) · Migrating from iTerm2 to Ghostty

소스: 인터뷰 원문 · GeekNews 토론(HN·Lobsters 의견 번역 포함) · 인용은 모두 의역이며 원문 뉘앙스는 원문 링크에서 확인. 적대적 리뷰 섹션은 Claude Fable 5 의 생성 결과로, 사실 검증이 아니라 논증 스트레스 테스트다.