Split View: 터미널로 돌아온 창업자: Hashimoto의 Ghostty, Zig라는 베팅, 그리고 "의무 없는" 오픈소스
터미널로 돌아온 창업자: Hashimoto의 Ghostty, Zig라는 베팅, 그리고 "의무 없는" 오픈소스
- 들어가며 — 성공한 창업자가 다시 밑바닥으로
- 왜 터미널이었나 — 무뎌진 감각을 다시 세우기
- Zig라는 베팅과 그 대가
- 의무 없는 오픈소스 — 원칙과 특권 사이
- 마무리 — 터미널, 가장 보이지 않는 도구
- 참고 자료
들어가며 — 성공한 창업자가 다시 밑바닥으로
Mitchell Hashimoto는 긴 설명이 필요 없는 이름이다. Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint — 지난 10여 년의 인프라 도구 상당수가 그의 손에서 나왔고, 그는 HashiCorp를 공동 창업했다. 그런 사람이 지금 무엇을 하고 있느냐면, 터미널 에뮬레이터를 만든다. 그것도 아직 1.0도 나오지 않은 Zig라는 언어로. 최근 공개된 한 인터뷰(alexalejandre.com)에서 그는 이 선택의 이유를 꽤 솔직하게 풀어놓았다.
이 글은 그 인터뷰를 근거로 세 가지를 짚는다. 성공한 창업자가 왜 다시 밑바닥 코드로 돌아갔는가, Zig라는 베팅의 실제 대가는 무엇인가, 그리고 그가 오픈소스 유지보수에 대해 내놓는 단호한 — 어떤 사람에게는 불편할 — 입장이다. 끝에서는 이 블로그가 얼마 전 다룬 "좋은 도구는 보이지 않는다"라는 주제와 터미널을 겹쳐 본다. 터미널만큼 보이지 않는 도구도 드물기 때문이다.
왜 터미널이었나 — 무뎌진 감각을 다시 세우기
그의 동기는 야망보다 호기심에 가깝다. 그는 방치해서 무뎌져 있던 기술 감각을 다시 세우고 싶었다고 말한다. 구체적으로는 세 영역이었다. AI 이전 방식의 GPU 프로그래밍, 데스크톱과 단일 노드 시스템 프로그래밍, 그리고 Zig 학습. 터미널 에뮬레이터는 이 셋을 한꺼번에 건드릴 수 있는 프로젝트였다.
인상적인 고백이 하나 있다. 15년 동안 CLI 도구를 만들어 왔으면서도, 정작 터미널이 내부에서 어떻게 동작하는지는 몰랐다는 것이다. Ghostty의 처음 목표는 거창하지 않았다. 그의 표현대로 "스스로를 빌드하게 한 뒤, 버리는(have it build itself, then throw it away)" 실험이었다 — vim과 컴파일러를 그 안에서 돌려 보는 정도. 그런데 디스코드에서 친구들에게 보여 주자 실제로 계속 쓰겠다는 사람이 나왔고, 그는 오랜 비공개 베타를 거쳐 이 버릴 물건을 진짜 프로젝트로 키웠다.
여기서 정직하게 짚어야 할 대목이 있다. 이건 누구나 할 수 있는 선택이 아니다. 돈이 되지 않는 저수준 오픈소스에 몇 년을 쏟는 일은, 이미 재정적 자유를 얻은 사람에게 훨씬 쉽다. 그는 지금 생후 6주 된 아기를 돌보며 하루 세 시간 남짓만 컴퓨터 앞에 앉는다고 말한다. 그 여유가 뒤에서 이야기할 "의무 없음" 철학의 배경이라는 점은, 그의 주장을 공정하게 읽으려면 함께 놓아야 한다.
Zig라는 베팅과 그 대가
Zig는 아직 1.0 이전이다. 이 말은 근사하게 들리지만 실무에서는 곧 파괴적 변경을 뜻한다. 그는 0.15가 "출력 인터페이스, 그리고 무언가를 출력하는 모든 것(the writer interface and thus anything printing anything)"을 바꿨다고 말한다. 즉 인쇄 계열을 쓰는 코드가 사실상 전부 흔들린 것이다. 흥미로운 건 그가 이걸 불평이 아니라 칭찬으로 말한다는 점이다 — 새 API가 훨씬 낫다는 것이다.
그의 Zig 옹호는 안정성이 아니라 방향성에 대한 신뢰다. Zig의 BDFL인 Andrew Kelley가 필요하다고 판단한 변경을 물러서지 않고 밀어붙이는 태도를 그는 좋아한다. 컴파일 속도에 대한 집착도 그렇다. 그의 표현으로는 libghostty 전체를 "즉시" 빌드할 수 있는데도 Andrew는 "그 밀리초조차 너무 느리다고 여긴다"는 것이다. 언어가 기능을 더하기만 하는 게 아니라 컴파일 속도를 위해 기능을 덜어내기도 한다는 점을, 그는 미덕으로 본다.
Rust에 대한 그의 태도는 그래서 예상 가능하다. 그는 Rust 문화를 좋아하지 않는다고 말하고, "나는 축구도 안 좋아한다(I also don't like soccer)"고 덧붙인다. 취향에는 이유가 필요 없다는 의도된 가벼움이다. 그가 Zig에 던지는 가장 다정한 말은 "당당하게 이상하다(unapologetically weird)"는 것이다. 그는 언어마다 다른 언어엔 있는 기능이 결여돼 있다는 사실을 오히려 반긴다 — 그런 제약이 창의성과 문화를 낳는다는 것이다.
내 평가를 붙이자면 이건 진짜 베팅이다. 초창기 Go를 일찍 채택했던 그의 이력을 생각하면 패턴의 반복인데, 1.0 이전 언어를 고르는 대가는 실재한다. 매 릴리스가 마이그레이션 숙제를 안긴다. 그는 그 숙제를 "좋은 변화"라 부르지만, 그것도 결국 그가 감당하기로 선택한 유지보수 세금이다.
의무 없는 오픈소스 — 원칙과 특권 사이
이 인터뷰에서 가장 논쟁적인 부분은 유지보수에 관한 대목이고, 그의 입장은 단호하다. 오픈소스 유지보수자는 사용자에게 어떤 의무도 없다는 것이다. 근거는 라이선스 그 자체다 — "오픈소스 라이선스의 첫 줄은 '있는 그대로, 무보증(as is, no warranty)'"이며, 그게 계약이라는 것이다. 더 나은 보장을 원하면 돈을 내고 소프트웨어를 사라고 그는 말한다. 벤더-고객 관계가 생겨야 비로소 무언가를 요구할 자격이 생긴다는 것이다.
그가 이 원칙을 방어용으로만 쓰는 건 아니다. 방향성을 지키는 도구로도 쓴다. 매일 사용자 이슈만 들여다봤다면 "안정적이지만 정체된(stable, stagnant)" 소프트웨어가 됐을 거라고 그는 말한다. 실제로 그는 사용자들이 개별적으로 올린 서너 개의 기능 요청을, 하나의 더 나은 기능으로 한꺼번에 닫아 버린 적이 있다고 한다. 각자의 요구를 그대로 구현하는 대신, 그 요구들을 관통하는 단일 설계를 택한 것이다.
포크에 대한 그의 생각도 뿌리가 같다. 그는 "개인용이든 유지되는 것이든 훨씬 더 많은 포크가 있어야 한다"고 늘 믿어 왔다고 말한다. 이게 말뿐이 아닌 이유는 아키텍처에 있다. Ghostty는 터미널 전체를 libghostty라는 라이브러리로 감싸고, 그 위에 앱을 올린다. 라이브러리로 깨끗이 분리돼 있으면, 사용자는 상류에 진정하는 대신 자기 방식대로 감싸거나 포크할 수 있다. "의무 없음"이 무책임으로 굴러떨어지지 않으려면, 사용자에게 스스로 해결할 표면을 내줘야 한다 — 라이브러리 우선 설계가 바로 그 표면이다.
그럼에도 나는 여기에 단서를 붙이고 싶다. "의무 없음"은 원칙적으로 옳지만, 그것을 편하게 말할 수 있는 위치는 균등하지 않다. Ghostty처럼 이미 사랑받는 프로젝트를, 생계를 걸지 않아도 되는 유지보수자가 만들 때 이 문장은 해방이다. 하지만 회사가 의존하는 라이브러리를 홀로 떠안은 채 번아웃과 죄책감 사이에 낀 유지보수자에게, 같은 문장은 도달하기 어려운 이상에 가깝다. 그의 원칙은 건강하다. 다만 그 원칙을 살아 낼 여유까지 균등하게 배분돼 있지는 않다.
마무리 — 터미널, 가장 보이지 않는 도구
터미널은 도구 중의 도구다. 잘 만든 터미널은 하루 종일 눈앞에 떠 있으면서도 의식되지 않는다. 얼마 전 이 블로그에서 gingerBill의 "좋은 도구는 보이지 않는다"를 다뤘는데(그 글), 터미널만큼 그 주장에 잘 들어맞는 대상도 드물다. Hashimoto의 Ghostty 철학도 결이 비슷하다. 그는 기능이 많은 것과 비대한 것을 구분한다 — 쓰지 않는 기능은 디스크와 메모리를 조금 차지할 뿐 실행되지 않으니, 그의 표현으로는 "공짜 기능(a free feature)"이다. 그리고 그는 터미널 기반 애플리케이션이 조합(composition)에 유리하다는 점을, 즉 더 나은 터미널이 더 나은 자동화와 스크립트화로 이어진다는 점을 강조한다.
성공한 창업자가 다시 밑바닥으로 내려간 이야기에서 내가 가져가는 건 결론이 아니라 태도다. 그는 15년을 그 위에서 만들고도 몰랐던 것을 인정했고, 안정성 대신 방향성에 베팅했으며, 유지보수의 부담에 대해 듣기 좋은 말 대신 자기 원칙을 말했다. 그 원칙에 전부 동의할 필요는 없다. 다만 무엇을 만들고 무엇을 감당하기로 했는지를 이렇게 분명히 말하는 사람은 드물고, 그 명료함 자체가 배울 점이다.
참고 자료
The founder who went back to the terminal: Hashimoto on Ghostty, Zig, and open source with "no obligation"
- Introduction — a successful founder back at the metal
- Why a terminal — sharpening skills gone dull
- The Zig bet and what it costs
- Open source with no obligation — principle and privilege
- Closing — the terminal, the most invisible tool
- References
Introduction — a successful founder back at the metal
Mitchell Hashimoto needs little introduction. Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint — a large slice of the last decade's infrastructure tooling came from him, and he cofounded HashiCorp. So what is he doing now? Building a terminal emulator, in Zig, a language that has not yet reached 1.0. In a recent interview (on alexalejandre.com) he lays out why, and he is unusually candid about it.
This piece, grounded in that interview, looks at three things: why a successful founder went back to low-level code, what the Zig bet actually costs, and the blunt — for some readers, uncomfortable — position he takes on open-source maintenance. At the end I hold his work up against a theme this blog covered recently: that good tools are invisible, and a terminal is about as invisible as tools get.
Why a terminal — sharpening skills gone dull
His motivation reads more like curiosity than ambition. He wanted to sharpen technical skills that had, in his telling, grown dull from neglect — specifically in three areas: pre-AI GPU programming, desktop and single-node systems programming, and learning Zig. A terminal emulator happened to touch all three at once.
There is a striking admission here: after fifteen years building CLIs, he did not actually understand how a terminal emulator worked. Ghostty started small. His plan, in his words, was to "have it build itself, then throw it away" — an experiment to run vim and a compiler inside. Then he showed friends on Discord, some of them actually wanted to keep using it, and a long private beta turned the throwaway into a real project.
Honesty requires a caveat here: this is not a choice everyone can make. Pouring years into low-level open source that earns nothing is far easier once you already have financial freedom. He mentions working only about three hours a day right now, with a six-week-old at home. That freedom is the backdrop to the "no obligation" philosophy discussed below, and it belongs in any fair reading of his stance.
The Zig bet and what it costs
Zig is pre-1.0. That sounds exciting; in practice it means breaking changes. He notes that 0.15 changed "the writer interface and thus anything printing anything" — meaning essentially every code path that prints got disrupted. The telling part is that he frames this as praise, not complaint: the new API, he says, is simply much better.
His case for Zig is about direction, not stability. He likes that Andrew Kelley, Zig's BDFL, "isn't backing down from changes he feels are necessary." The obsession with compile speed is part of the appeal: he can build all of libghostty effectively instantly, and by his account "Andrew still thinks these milliseconds are too slow." A language that removes features to compile faster, rather than only adding them, is to him a feature in itself.
His stance on Rust follows from that. He says he does not like the Rust culture, adding, "I also don't like soccer" — a deliberately flip way of saying a preference needs no justification. His warmest words for Zig are that he respects it for being "unapologetically weird." He likes that languages lack features other languages have, because, he says, "these constraints breed creativity and culture."
My own read: this is a genuine bet, and it echoes his early adoption of Go. Choosing a pre-1.0 language has real costs — every release hands you migration homework. He calls that homework a good thing, but it is still a maintenance tax he has chosen to pay.
Open source with no obligation — principle and privilege
The most contentious part of the interview is about maintenance, and his position is blunt: an open-source maintainer owes users nothing. The grounding is the license itself — "The first line in OS licenses is 'as is, no warranty'," and that, he says, is the agreement. Want stronger guarantees? Pay for software. Only a vendor-customer relationship, in his framing, entitles you to make demands; open source does not.
He does not use this only defensively. It is also a tool for protecting vision. If he only ever worked through user issues, he says, "you'd get stable, stagnant software." He once closed three or four separate feature requests at once, because a single better-designed feature could solve all of them — choosing one coherent design over implementing each user's ask literally.
His view on forks has the same root. He says he has "always believed there should be way more forks, both personal and maintained ones." What makes this more than a slogan is the architecture: Ghostty wraps the whole terminal as a library, libghostty, with the app on top. When a project is cleanly a library, users can wrap or fork it their own way instead of petitioning upstream. For "no obligation" not to curdle into indifference, you have to hand users a surface to help themselves — library-first design is that surface.
Still, I would add a caveat. "No obligation" is right in principle, but the position from which you can say it comfortably is not evenly distributed. For a beloved project like Ghostty, maintained by someone who does not need the income, the sentence is liberating. For a maintainer shouldering a library some company depends on, caught between burnout and guilt, the same sentence is closer to an ideal they cannot reach. His principle is sound; the freedom to live by it is not equally shared.
Closing — the terminal, the most invisible tool
A terminal is a tool among tools. A good one sits in front of you all day and never asks to be noticed. This blog recently covered gingerBill's "Good Tools Are Invisible" (that piece), and few things fit the argument better than a terminal. Hashimoto's design philosophy rhymes with it. He separates feature-rich from bloated: a feature you never use only costs a little disk and RAM and never runs — in his words, "a free feature." And he stresses that terminal applications compose well, so that better terminals lead to better automation and scriptability.
What I take from a successful founder going back to the metal is the posture, not the conclusions. He admitted he did not understand something after building on top of it for fifteen years; he bet on direction over stability; and on the burden of maintenance he stated a principle rather than something merely pleasant to hear. You need not agree with all of it. But few people say this plainly what they are building and what they have signed up to carry, and that clarity is the part worth keeping.