네이티브의 반격인가, 값비싼 베팅인가: Hashimoto의 Ghostty와 Zig
네이티브의 반격인가, 값비싼 베팅인가: Hashimoto의 Ghostty와 Zig
Hashimoto가 HashiCorp를 떠나 Zig로 터미널을 만든 선택은, 네이티브 성능과 장인적 도구가 웹기술 범람 속에서 여전히 우위인가라는 질문에 대한 답인가 — 아니면 pre-1.0 언어에 건 값비싼 베팅인가.
도입
지난 10여 년간 데스크톱 애플리케이션의 지배적 배포 형식은 웹기술이었다. Slack, Discord, VS Code, Notion, 초기 버전의 수많은 터미널 래퍼가 Electron 위에 얹혔고, 그 이유는 명료했다. 한 번 작성한 HTML/CSS/JS를 세 플랫폼에 그대로 올릴 수 있고, 웹 개발자 풀이 곧 데스크톱 개발자 풀이 되며, Chromium이 렌더링과 폰트와 접근성을 대신 처리해준다. 대가는 메모리 수백 MB와 입력 지연, 그리고 “어느 OS에서도 조금씩 이질적인” 룩앤필이었지만, 그 대가는 대체로 감내할 만한 것으로 여겨졌다.
터미널 에뮬레이터는 이 흐름 속에서 흥미로운 예외 지대였다. 개발자가 하루 종일 손을 얹는 가장 기초적인 도구이면서, 동시에 지연과 스루풋에 가장 민감한 도구다. 로그 파일이 초당 수만 줄 쏟아질 때 프레임이 무너지는가, 키를 눌러 화면에 글자가 나타나기까지 몇 밀리초가 걸리는가는 웹 기반 터미널이 좀처럼 이기기 어려운 지점이었다. 그리고 2026년 7월 10일(KST), Hacker News 최상단에는 이 예외 지대의 상징이 된 프로젝트에 관한 인터뷰가 올랐다. HashiCorp 창업자 Mitchell Hashimoto와 그의 터미널 에뮬레이터 Ghostty, 그리고 그것을 지탱하는 pre-1.0 언어 Zig에 관한 대화였다(377 points, 226 comments).
이 글이 던지는 질문은 하나로 압축된다. HashiCorp라는 성공한 인프라 회사를 떠난 인물이, 아직 1.0에 도달하지 못한 언어로, 세 플랫폼 각각에 네이티브 GUI를 따로 써가며 터미널을 만든 선택은 무엇을 증명하는가. 그것은 네이티브 성능과 장인적 도구가 웹기술의 범람 속에서 여전히 우위라는 논증인가, 아니면 불안정한 언어 기반 위에 상당한 유지보수 부채를 쌓아 올린 값비싼 베팅인가. 본고는 이 두 해석이 사실은 배타적이지 않다는 것, 그리고 그 트레이드오프의 구조가 도구 제작 일반에 시사하는 바를 정리한다.
현상: Ghostty와 인터뷰 요지
Ghostty는 “빠르고(fast), 기능이 풍부하며(feature-rich), 네이티브(native)“라는 세 축을 동시에 만족시키는 것을 목표로 내건 터미널 에뮬레이터다. 대부분의 프로젝트가 이 셋 중 둘을 고르고 하나를 포기하는 것과 달리, Ghostty의 명시적 설계 원칙은 셋 다 경쟁력 있게 유지하는 것이다. 2024년 12월 1.0을 배포했고, 코어는 Zig로 작성되었으며 MIT 라이선스로 공개되어 있다. GUI는 플랫폼마다 다르게 구현된다. macOS에서는 Swift로 AppKit과 SwiftUI를 쓰고, Linux에서는 Zig로 GTK4의 C API를 직접 호출한다. 렌더링은 GPU에서 이루어진다. macOS는 Metal, Linux는 OpenGL을 백엔드로 삼아 매 프레임 화면 전체를 GPU에서 그린다. 탭, 분할, 오류 메시지 같은 UI 요소는 커스텀 텍스트 위젯이 아니라 각 플랫폼의 네이티브 컴포넌트가 담당한다.
이 구조는 Electron 계열 터미널(예: Hyper)이나 VS Code 내장 터미널(Electron 안에서 xterm.js가 도는)과 정면으로 대비된다. Ghostty는 Alacritty, kitty, WezTerm과 함께 “네이티브 GPU 가속” 진영에 속하되, 그중에서도 GUI 셸까지 각 OS의 네이티브 툴킷으로 밀어붙인다는 점에서 더 극단적이다. Alacritty가 크로스플랫폼 GPU 렌더링에 집중하며 의도적으로 미니멀한 것과 달리, Ghostty는 코어의 크로스플랫폼성과 GUI의 완전한 네이티브성을 동시에 취한다.
인터뷰에서 Hashimoto가 밝힌 제작 동기는 제품 전략이 아니라 개인적 갈증에 가깝다. 그는 15년간 CLI 애플리케이션을 만들어 왔지만, 방치로 무뎌진 기술 근육을 다시 벼리고 싶었다고 말한다. 구체적으로 세 영역을 지목한다. 첫째, (AI 이전 의미의) GPU 프로그래밍. 둘째, 분산 시스템이 아니라 단일 노드의 캐시 지역성과 벡터 연산에 집중하는 데스크톱 시스템 프로그래밍. 셋째, Zig를 익히는 것. 흥미로운 자기 고백은, 평생 CLI를 다뤄왔음에도 정작 터미널 에뮬레이터가 내부적으로 어떻게 동작하는지 몰랐다는 점이다. 그래서 그가 세운 최초의 목표는 소박했다. “그 안에서 vim과 컴파일러를 돌리고, 그것으로 자기 자신을 빌드한 뒤, 던져버리는 것.” 던져버리려던 습작이 릴리스로 이어진 것은, 생태계를 둘러본 뒤 “빠르고, 기능이 풍부하며, 네이티브하게 크로스플랫폼인” 선택지가 존재하지 않는다는 것을 확인했기 때문이고, 초기 비공개 베타 사용자들이 공개를 요청했기 때문이다.
Zig 선택 역시 전략적 계산이라기보다 의도된 학습이었다. 그는 “Zig를 갖고 놀고 싶었다”고 말하며, 컴파일러에 패치를 보내며 언어에 익숙해졌고 커뮤니티의 문화와 철학을 잘 알게 되었다고 덧붙인다. pre-1.0의 불안정성에 대해서는 “내가 무엇에 서명했는지 알고 있었다(I knew what I signed up for)“고 잘라 말하며, 언어의 BDFL이 필요하다고 판단한 변경을 물러서지 않고 밀어붙이는 태도를 오히려 존중한다고 밝힌다.
기능과 비대함(bloat)을 구분하는 관점도 특징적이다. 그는 터미널을 극단적인 애플리케이션 플랫폼으로 밀어붙이는 데 반대하면서도, 기능이 많은 것 자체를 비대함으로 보지 않는다. 예컨대 검색 기능은 “디스크 공간을 차지하고 RAM에 로드되지만 아무것도 실행되지 않는다. 쓰지 않는다면 그것은 공짜 기능”이라는 것이다.
HN의 반응은 대체로 호의적이되 균질하지 않았다. 사용 경험의 스펙트럼이 그대로 드러났다. 한 사용자(adrian_b)는 “수십 년간 수많은 비디오 터미널 에뮬레이터를 써왔지만, Ghostty가 내가 써본 최고의 비디오 터미널 에뮬레이터라고 본다”고 단언했고, 또 다른 사용자(flohofwoe)는 “출시 이후 macOS에서 Ghostty를 쓰고 있는데 아직 버그를 하나도 못 만났다. iTerm2는 시간이 지나며 너무 뚱뚱하고 느려졌다”고 적었다. 반면 부정적 경험도 그대로 노출됐다. 한 사용자(sethammons)는 “Mac에서 Ghostty가 매일 크래시 리포트 없이 죽었는데, 늘 Claude 세션 도중이었고, 크래시 뒤엔 세션을 잃었다”고 토로했다. 같은 소프트웨어를 두고 “버그 제로”와 “매일 크래시”가 공존한다는 사실 자체가, 야심 찬 네이티브 프로젝트의 성숙도가 아직 균일하지 않음을 시사한다.
심층: Zig 선택의 기술적 트레이드오프와 네이티브 vs Electron
Zig가 Ghostty 같은 프로젝트에 매력적인 이유는 세 가지 축으로 정리된다. 첫째는 comptime이다. Zig에는 매크로도, 별도의 메타프로그래밍 언어도, 애너테이션 기반 제네릭도 없다. 대신 컴파일 타임에 일반 Zig 코드를 실행할 수 있고, 타입 자체가 값으로 취급된다. 제네릭 자료구조는 “타입을 인자로 받아 타입을 반환하는 함수”로 표현되며, 터미널의 셀 그리드나 파서 상태 기계처럼 성능이 중요한 자료구조를 런타임 비용 없이 특수화할 수 있다. 매크로의 표현력을 취하면서도 별도 언어를 배우지 않아도 되는 것이 comptime의 핵심 이점이다.
둘째는 C 상호운용성이다. Zig는 C 헤더를 @cImport로 직접 읽어 바인딩을 자동 생성하고, 별도의 FFI 글루 레이어 없이 C 함수를 호출한다. Ghostty의 Linux GUI가 GTK4를 다루는 방식이 바로 이것이다. GTK는 방대한 C 라이브러리이고, Ghostty는 래퍼 생태계를 거치지 않고 그 C API를 그대로 호출한다. 나아가 Zig 컴파일러는 그 자체로 유능한 C/C++ 컴파일러이자 크로스 컴파일러여서, 시스템 라이브러리와의 접점이 많은 터미널 같은 프로그램에서 빌드 파이프라인을 단순하게 만든다.
셋째는 메모리와 제어 흐름의 명시성이다. Zig에는 숨은 할당이 없다. 힙 할당이 필요한 표준 라이브러리 함수는 명시적으로 Allocator를 인자로 받으며, 따라서 어디서 메모리가 잡히는지가 코드에 드러난다. 숨은 제어 흐름도 없다(연산자 오버로딩, 예외를 통한 비명시적 점프가 없다). 매 프레임 화면 전체를 다시 그리는 렌더러처럼 할당 패턴과 지연을 손끝으로 통제해야 하는 코드에서, 이 명시성은 곧 예측 가능성이다.
그러나 같은 특성의 이면이 리스크다. Zig는 아직 1.0이 아니고, 언어 자체가 파괴적으로 변한다. 인터뷰에서 Hashimoto는 0.15가 상당한 릴리스였다고 말한다. writer 인터페이스가 바뀌면서 “무언가를 출력하는 코드 전부”가 영향을 받았다는 것이다. 그럼에도 그는 “API가 정말로 훨씬 나아졌다”며 변경을 옹호한다. 더 무거운 변화는 아직 오지 않았다. “I/O 변경이 우리가 해온 일 중 가장 어려운 축에 속할 것으로 예상하지만, 아직 시작조차 안 했다”는 그의 말은, 언어 근간의 비동기/IO 모델이 재편될 때 대규모 애플리케이션이 치를 마이그레이션 비용을 암시한다. 그가 추정하는 1.0은 여전히 “수년 뒤”다. 즉 Ghostty는 발밑의 언어가 계속 움직이는 상태에서 프로덕션 소프트웨어를 유지하는 셈이다. 표준 라이브러리는 얇고, 패키지 생태계는 어리며, 컴파일러 버그와 마주칠 확률도 성숙 언어보다 높다.
이 지점에서 Rust와의 대비가 불가피하다. Rust는 이미 1.0을 지났고, 소유권과 대여 검사기가 메모리 안전을 컴파일 타임에 강제하며, 거대한 크레이트 생태계와 성숙한 도구 체인을 갖췄다. 네이티브 GPU 터미널의 대표주자 중 하나인 Alacritty가 Rust로 쓰였다는 사실은 우연이 아니다. 안정성과 안전성만 놓고 보면 Rust가 보수적으로 더 안전한 선택이다. 그럼에도 Hashimoto는 Zig를 골랐고, 인터뷰에서 그는 Rust 커뮤니티의 문화가 자신과 맞지 않는다는 취지의 발언을 남긴다. 이는 언어 선택이 순수하게 기술 사양의 함수가 아니라, 개발자가 매일 머무를 문화적·미학적 공간의 함수라는 점을 드러낸다. HN의 한 논평(pron)은 이를 냉소적으로 요약했다. “2026년이고, 코딩에서 이제 중요한 유일한 것은 취향(taste)이다.” 반은 조롱이지만 반은 정확하다. 언어 성숙도라는 객관 지표가 엇비슷해지는 지점을 넘어서면, 남는 결정 변수는 제작자가 어떤 세계에서 일하고 싶은가로 수렴한다.
네이티브 대 Electron의 축은 또 다른 트레이드오프를 품는다. Electron 모델의 본질은 “한 번 써서 세 곳에 배포”다. Ghostty의 모델은 정반대다. “코어는 크로스플랫폼으로, GUI는 타협 없이 네이티브로.” 그 대가로 Ghostty는 GUI를 사실상 두 번 이상 쓴다. macOS를 위한 Swift/AppKit/SwiftUI 코드와 Linux를 위한 GTK4 코드가 별도로 존재한다. 이는 명백한 중복이고 유지보수 표면적의 증가다. 얻는 것은, 각 OS에서 이질감 없는 창 관리·탭·단축키·접근성과, Chromium 프로세스가 없는 메모리 발자국, 그리고 매 프레임 GPU 렌더링이 주는 낮은 지연이다. 크로스플랫폼 균일성과 네이티브 통합은 여기서 정확히 상충한다. 하나를 얻으려면 다른 하나의 비용을 치러야 한다. Ghostty의 판단은, 하루 종일 손을 얹는 도구에서는 네이티브 통합과 지연이 균일성보다 값어치가 크다는 쪽이다. 이 판단이 옳은지는 도구의 성격에 달려 있다. 지연 민감도가 낮고 사용 빈도가 낮은 앱이라면 정반대 결론이 합리적이다.
전망·실무 시사점
첫째, 이 사건은 개발자 도구에서 진행 중인 “네이티브 회귀”의 한 데이터 포인트다. Ghostty만이 아니다. 에디터에서는 Zed가 Rust로 GPU 가속 네이티브 UI를 밀고 있고, 런타임에서는 Bun이 Zig로 Node의 대안을 노린다. 데이터베이스에서는 TigerBeetle이 Zig로 결정론적 성능을 판다. 공통점은, 지연과 스루풋과 자원 사용이 사용자 경험의 1차 변수인 영역에서 웹기술 레이어를 걷어내려는 흐름이다. 다만 이를 “웹기술의 패퇴”로 읽는 것은 과장이다. Electron은 여전히 폼 중심·문서 중심·업데이트 빈번한 앱에서 압도적으로 합리적이다. 네이티브 회귀는 전면전이 아니라, 지연 민감 도구라는 특정 전선에서의 국지적 탈환에 가깝다.
둘째, Zig를 프로덕션에 채택하려는 팀에게 Ghostty의 사례는 양면적 교훈이다. 긍정적으로는, 대규모의 진지한 애플리케이션이 Zig로 출하 가능하다는 존재 증명이다. C 상호운용성 덕분에 기존 C 자산 위에 점진적으로 얹을 수 있고, comptime은 매크로 없이도 강력한 특수화를 제공한다. 부정적으로는, 언어가 파괴적으로 변하는 동안 그 위에서 프로덕트를 유지하는 비용을 각오해야 한다. 0.15의 writer 변경이나 예정된 I/O 재편처럼, 언어 릴리스마다 코드베이스를 훑는 마이그레이션이 발생한다. 채용 풀도 얕다. 따라서 Zig 채택은 “언어가 성숙할 것”이라는 베팅이며, 그 베팅의 성패는 팀이 마이그레이션 부채를 감당할 여력과, 스스로 컴파일러/툴링 이슈를 파고들 역량에 달려 있다. Hashimoto가 컴파일러에 패치를 보낼 수준이었다는 점은, 이 리스크를 감당한 사람의 프로필을 시사한다. 그런 여력이 없는 팀에게는 같은 선택이 훨씬 더 비싸다.
셋째, 도구 자체를 도입하려는 실무자에게는 안정성 프로파일이 균일하지 않다는 점을 유념할 만하다. 앞서 인용한 “버그 제로”와 “매일 크래시”의 공존이 그 증거다. macOS의 성숙도와 Linux/GTK 경로의 성숙도가 다를 수 있고, 특정 워크플로(예: 장시간 실행되는 에이전트 세션) 아래에서 드러나는 문제가 있을 수 있다. 도입 시에는 자신의 핵심 워크플로에서 며칠간 상주시켜 보는 검증이 현실적이다.
넷째, 인터뷰가 드러낸 오픈소스 관점은 협업 모델에 대한 시사점을 담는다. Hashimoto는 오픈소스가 “공유를 포함하지만, 본질은 자유와 권리”라고 말하며, 벤처 투자로 다듬어진 “고도로 세련되고 자금이 투입된, 관점이 뚜렷한 프로젝트”를 기대하는 태도를 생태계의 예외로 규정한다. 사용자가 기능 제거를 요구하며 “그걸 유지보수하라”고 하기보다 스스로 포크하는 편이 낫다는 입장이다. 인터뷰의 논지를 빌리면, 플래그로 특정 기능을 끄도록 유지보수하라는 요구에 대해 그는 그 기능을 제거한 포크를 유지보수하라고 되받을 수 있다는 것이다. 이는 관리자와 사용자 사이의 기대 계약을 재조정하려는 시도다. 무상 유지보수자에게 상용 제품 수준의 대응을 요구하는 관행에 대한 반론이며, 소규모 팀이 야심 찬 오픈소스를 지속 가능하게 운영하려면 “권리로서의 포크”를 정상 규범으로 되돌려야 한다는 주장이다.
마지막으로, AI 시대의 장인적 제작 방식에 대한 관점도 실무적이다. 그는 AI 도구로 거친 코드를 생성해 방향을 시험하고, 방향이 검증되면 조심스럽게 다시 짓는 방식을 취한다고 밝힌다(최근 아버지가 되어 가용 시간이 제한된 사정도 언급된다). 이는 “AI로 초안, 인간이 정본”이라는 절충으로, 자동 생성과 장인적 통제를 대립이 아니라 파이프라인의 두 단계로 배치한다. HN의 한 논평(tecoholic)은 이런 태도에 반색했다. “이런 것들을 읽는 게 정말 기쁘다. 자기가 하는 일을 깊이 생각하고 아끼는 사람들이 실용적인 결정을 내린다.” 성능과 제어를 강박적으로 추구하면서도 도구 채택에는 실용적인 이 균형이, Ghostty라는 프로젝트의 성격을 압축한다.
결론
리드 질문으로 돌아가자. Hashimoto의 선택은 네이티브의 우위를 증명하는 논증인가, 아니면 pre-1.0 언어에 건 값비싼 베팅인가. 정직한 답은 “둘 다”이며, 둘이 배타적이지 않다는 것이 핵심이다.
네이티브의 우위는, 적어도 터미널이라는 특정 도구에서는 실질적이다. 지연과 스루풋이 경험의 1차 변수이고 하루 종일 상주하는 도구에서, 매 프레임 GPU 렌더링과 네이티브 UI 통합이 주는 이득은 크로스플랫폼 균일성의 편의를 상회한다. 이 판단은 취향이 아니라 도구의 물리적 성격에서 도출된다. 그러나 그 우위는 공짜가 아니다. GUI를 플랫폼마다 따로 쓰는 중복, 발밑에서 계속 움직이는 pre-1.0 언어, 릴리스마다 반복되는 마이그레이션, 얕은 생태계와 채용 풀이라는 비용이 그 밑에 깔려 있다. 이것이 “값비싼 베팅”의 실체다.
두 해석이 화해하는 지점은, 이 프로젝트에서 비용이 곧 목적이었다는 데 있다. Hashimoto는 무뎌진 기술을 벼리려고 Ghostty를 시작했고, GPU 프로그래밍과 단일 노드 시스템 프로그래밍과 Zig 학습이 목표였다. 즉 값비싼 경로를 택한 이유의 일부는 그 경로 자체가 배움이었기 때문이다. “던져버릴 습작”으로 출발한 프로젝트가 1.0에 이른 서사는, 제품 최적화가 아니라 장인적 동기가 앞선 사례임을 말해준다. 순수하게 사업적 합리성만 따진다면 성숙한 Rust나 크로스플랫폼 웹기술이 더 안전했을 것이다. 그가 그 길을 가지 않은 것은, 도구를 만드는 일에서 무엇을 어떻게 만드는가의 과정 자체가 결과만큼 중요하다는 가치 판단이 있었기 때문이다.
정리하면 트레이드오프의 구조는 이렇다. Zig의 힘(comptime·C 상호운용·명시적 제어)은 pre-1.0의 불안정성과 생태계 리스크와 맞바꾼 것이고, 플랫폼별 네이티브 UI의 통합감은 크로스플랫폼 균일성과 유지보수 중복과 맞바꾼 것이며, 장인적 성능과 제어는 출하 속도와 맞바꾼 것이다. Ghostty는 이 세 저울에서 모두 “제어와 네이티브와 장인성” 쪽으로 기울인 극단적 사례다. 그 극단이 정당화되는지는 도구의 성격과 제작자의 여력에 달려 있으며, 모든 프로젝트가 흉내 낼 규범은 아니다. 그러나 웹기술이 기본값이 된 시대에, 지연 민감 도구라는 전선에서 네이티브와 장인성을 향한 값비싼 선택이 여전히 성립하고 심지어 환대받는다는 사실 자체가, 이 인터뷰가 남긴 가장 분명한 데이터 포인트다.
출처: