요약
Libghostty 1.0이 나와 터미널 에뮬레이션 C 라이브러리의 API와 ABI가 안정화됐습니다.
Ghostty를 만든 미첼 하시모토가 Ghostty의 핵심을 떼어 낸 라이브러리 libghostty-vt의 1.0 출시를 알렸습니다. 1년 남짓 전에는 C API도 없이 Ghostty만 쓰던 라이브러리였습니다. 이제는 Ghostty 앱보다 훨씬 많은 사람이 이 라이브러리로 만든 터미널을 쓴다고 했습니다.
왜 중요한가
- 터미널이나 코딩 도구를 만드는 쪽이 에뮬레이터를 새로 짜지 않고 검증된 엔진을 가져다 쓸 수 있습니다.
- ABI(컴파일된 프로그램과 라이브러리가 맞물리는 이진 규약)를 고정해, 라이브러리를 올려도 기존 프로그램이 깨지지 않게 약속했습니다.
- 한 프로젝트에서 보고된 버그 수정과 새 기능이 이 엔진을 쓰는 모든 프로젝트에 함께 돌아갑니다.
핵심 내용
- 제트브레인스 IDE의 터미널이 이미 libghostty로 돌아가고, Neovim도 libvterm을 이것으로 바꾸는 PR을 승인했습니다.
- 모든 객체를 불투명 핸들로 다뤄, 새 헤더를 옛 라이브러리와 쓰면 충돌 대신
GHOSTTY_UNSUPPORTED를 돌려줍니다. - CI에서 libabigail로 변경마다 ABI 호환성을 검사하고, ELF 플랫폼에서는 모든 심벌에 버전을 붙였습니다.
- MIT 라이선스이고 실행에는 libc만 필요하며, 리눅스·macOS·윈도·안드로이드·WebAssembly를 CI에서 테스트합니다.
- 스레드를 만들지 않아 4코어·8GB 리눅스 서버에서 셸이 붙은 터미널 1만 개를 띄웠다고 했습니다.
HN 반응
- 하시모토의 새 터미널 Rex를 두고, Ghostty가 유료 제품의 기본판으로 밀려날까 걱정하는 목소리와 Rex는 계속 무료라고 밝혔다는 반박이 맞섰습니다.
- C 라이브러리를 설계하는 이용자들은 ABI 설계의 꼼꼼함을 높이 사고, 구조체 맨 앞에 크기를 넣는 기법 같은 사례를 덧붙였습니다.
미첼이 자기 경쟁 제품인 Rex를 슬쩍 끼워 넣을 수도 있었을 텐데 참았네요. 존경합니다.
저는 Rex가 마음에 들어서 쓰기 시작했는데, 지금은 Ghostty를 대체하고 있어요. 그래서 좀 헷갈리는데, Rex가 Ghostty를 대체하려는 건가요? 아직 둘을 언제 각각 써야 할지 모르겠어요.
제가 알기로는 그가 Ghostty는 libghostty의 기술 시연품 같은 거라고 했어요.
꽤 괜찮은 시연품이죠
이런. 이 중 일부가 Ghostty에도 들어오길 바랐는데요. 특히 ssh 세션 기능이요. Wezterm에는 있거든요. 저는 Ghostty가 더 좋은데, 유료 제품의 라이트 버전이 되어 버린다면 좀 별로네요.
지금까지는 Rex에 요금을 받을 생각이 없다고 밝혔습니다.
제 짐작에는 Ghostty와 Rex의 관계가 Chromium과 Google Chrome의 관계와 비슷할 것 같아요(부정적인 뜻은 전혀 없어요, 저는 Rex를 아주 만족스럽게 쓰고 있거든요!). Ghostty는 libghostty의 기술 시연품 같은 면도 있고, 기본적이지만 기능은 충실한 오픈소스 터미널 에뮬레이터이기도 하죠. 그러면 Rex는 언젠가 유료 제품이 되고, 그 위에 서버, 에이전트 연동, 영구 세션 관리 같은 기능을 얹겠죠. 2년 전에 터미널에 돈을 낼 준비가 됐냐고, 젯브레인스 구독을 끊을 수 있냐고 물었다면 웃어넘겼을 거예요. 그런데 지금은 슈퍼로지컬이 유료 요금제를 발표하면 진지하게 낼 준비가 되어 있어요.
끝내주네요!
대체 왜 그런 걸 돈 내고 쓴다는 거예요? 시비 거는 건 아니고, 그 가치 제안이 뭔지 정말 이해가 안 가서요.
개발 경험(DX)이 더 좋고 본인에게 가치가 있다면, 왜 돈을 안 내겠어요?
B2C에서든 B2B에서든 '삶을 편하게 해 주는' 도구 시장은 꽤 크잖아요
그렇게 큰 시장은 아닐 수도 있지만 어떻게 될지는 모르죠
결국 가격만큼의 가치를 경쟁 제품(무료거나 더 쌀 수 있는)보다 충분히 주느냐의 문제예요. 100달러짜리 문제를 해결해 주는 10달러짜리 위젯을 팔면서 "가치가 이렇게나 큰데" 왜 아무도 안 사냐고 의아해할 수 있지만, 1달러짜리 위젯이 똑같이 잘 해결해 주기 때문일 수 있죠.
참고로 일부러 일반적인 예를 든 거예요. 저는 Ghostty를 쓰고 있고 Rex는 아직 안 써 봐서, 경쟁 제품 대비 얼마나 가치가 있는지는 전혀 모르거든요.
맞아요, 그건 그래요. 그래도 개발 도구 같은 건 괜찮다 싶으면 10달러쯤은 쉽게 내놓는 경우가 많다고 봐요
'더 저렴한 대안' 문제는 인체공학 쪽에서는 덜 중요하다고 생각해요. 개발자들이 작업 흐름을 매끄럽게 하려고 온갖 화려한 분리형 키보드 같은 걸 사잖아요. 그러니 이 제품에도 사람들이 선뜻 돈을 내더라도 놀랍지 않을 것 같아요
관건은 이게 실제로 뜰지, 사람들이 정말 좋아할 만한 작업 흐름을 제공하거나 거기에 들어맞을지 같은 거겠죠. 지나치게 주관이 강하거나 딱히 혁신적이지 않다면 사람들이 왜 "갈아타겠어요".
그냥 제 생각이에요.
맞아요, 인체공학은 가치의 큰 부분이죠. 실제 문제를 해결해 주니까요.
기업이 규정 준수(컴플라이언스) 때문에 돈을 내는 것들이 많습니다.
제가 꽤 확실하게 기억하기로는 그가 Rex는 계속 무료로 남는다고 했어요.
그렇긴 한데, 슈퍼로지컬은 회사잖아요. 언젠가는 분명 상용 제품을 만들 거예요. 그게 어떤 식으로든 Rex와 관련되지 않는다면 오히려 놀랄 것 같아요.
Google Chrome도 무료인 걸로 아는데요 ;)
그리고 저도 Chrome이 구글의 직접적인 수익원이 아니라는 건 마찬가지로 확신해요.
그가 그렇게 했더라도 저는 기뻤을 거예요. 어쩌면 Rex를 공개하는 일정이 좀 뒤로 잡혀 있는지도 모르죠.
며칠 전에 Rex가 어디까지 왔나 들여다봤는데, 아직 리눅스 베타는 없는 것 같더라고요(맥OS 사용자한테는 있고요).
그래도 한번 써 보고 싶긴 한데, 지금까지는 이런 종류의 도구에 별로 관심이 가지 않았어요.
서버는 리눅스용 베타가 나와 있는데 프런트엔드는 아직이에요. 그래서 macOS(나 iOS)에서 원격 리눅스 머신에 접속할 수 있어요.
저는 지금 Zig로 제 프로젝트(인터프리터)를 만들고 있는데, 마침 그 C 인터페이스를 설계하는 중입니다. 객체를 불투명 핸들로 둔다거나 enum을 키로 쓰는 getter와 setter를 쓴다는 언급을 보니, 제 현재 API가 얼마나 투박한지 새삼 느꼈습니다. 호출하는 쪽에 세부 사항을 너무 많이 노출하고 있거든요.
특히 눈길을 끈 건 이 문장이었습니다. "그래서 처음부터 제가 즐겨 썼던 C 라이브러리들에서 영감을 얻어, 앞으로의 추가를 허용하는 강력하고 안정적인 ABI를 갖도록 API를 설계했습니다." 이런 사례로 좋은 게 뭐가 있을까요? 잘 설계된 C 라이브러리를 접해 본 경험이 부족해서 무엇을 봐야 할지 감이 잘 안 옵니다.
제게 떠오르는 예로는 libopus가 있습니다: https://github.com/xiph/opus
확장이 필요할 수 있는 구조체가 있다면 "버전 관리 구조체"를 쓸 수 있습니다. 흔한 기법은 구조체 크기를 첫 필드로 넣는 것입니다. 구조체 크기는
offsetof(mystruct, lastmember) + sizeof(lastmember)로 설정하고, 구조체를 받는 쪽은 이 값으로 멤버가 존재하는지 확인할 수 있습니다. ARA API가 좋은 예입니다: https://github.com/Celemony/ARA_API/blob/65ec5c43b943a48cb5446f448a0492db6af8534b/ARAInterface.h#L510버전과 크기를 처음 두 필드로 두면 사실상 하위 호환성과 상위 호환성은 확보한 셈입니다. 호출하는 쪽은 구조체 크기를 요청해 버퍼를 할당하고 필요한 부분만 읽어 낼 수 있습니다. 또 지원하는 버전을 구체적으로 확인해서 더 새로운 버전은 무시할 수도 있고요.
새 필드를 구조체 끝에만 덧붙이면 더 도움이 됩니다.
멤버에 접근하기만 한다면 버전은 필요 없습니다. 구조체를 받는 쪽이 어떤 멤버가 있는지 확인하고, 자기가 모르는 추가 멤버는 무시하면 됩니다. 그게 하위 호환성이자 상위 호환성입니다.
버전은 일부 멤버의 의미가 버전마다 바뀔 때 쓸모가 있을 수 있습니다. 하지만 그러면 미래 버전에서 만든 구조체는 쓸 수 없게 됩니다. 어떤 변경이 있었는지 알 길이 없으니까요.
개인적으로는 버전 또는 크기 중 하나만 쓰는 경우는 봤어도 둘 다 쓰는 경우는 못 봤습니다. 혹시 예가 있나요?
사실 이건 필수입니다. 기존 멤버를 바꾸거나 순서를 바꾸면 ABI가 깨지니까요. 버전마다 전용 구조체를 따로 두는 경우는 예외입니다. (COM 같은 API에서 흔히 쓰는 방식인데, 인터페이스를 확장할 때 새 인터페이스를 추가합니다. 클라이언트는 자기가 아는 가장 최신 인터페이스를 질의하고, 지원하지 않으면 그 이전 인터페이스를 시도하는 식으로 성공할 때까지 내려갑니다.)
제 일이 이런 걸 고민해야 하는 일입니다(정확히는 최종 결정은 더 경력 많은 분들이 내리지만, 저도 그 내용은 이해해야 하거든요). 안정적인 C ABI를 만들려고 이 정도 엄밀함을 쏟았다는 게 정말 대단합니다. 저희가 내부적으로 갖고 있는 체크리스트 항목을 거의 다(그 이상까지!) 건드리고 있어요.
hpy를 한번 보세요. 파이썬 C 확장을 위한 더 나은 API를 명시적으로 설계하는 프로젝트입니다. https://hpyproject.org/
오, 한번 볼게요. 바로 적용할 만한 내용이네요!
Libghostty는 아주 멋진 프로젝트이고, 이번 릴리스도 기대됩니다. 이 일을 앞장서 이끈 mitchellh와 프로젝트에 기여해 온 모든 분께 박수를 보냅니다. 저는 지금 Ghostty를 주 터미널 에뮬레이터로 쓰고 있고, 몇 달 전에는 libghostty를 안드로이드 프로젝트에 써 보는 실험도 했습니다. 시간이 나면 언젠가 다시 돌아가서 이어 갈 계획이라, 저도 이 작업의 덕을 보고 있는 셈입니다.