안정적인 C ABI, 폭넓은 이식성, 패키징 및 라이선싱을 갖춘 libghostty-vt 1.0의 출시와 그 의미를 소개합니다.
libghostty-vt 1.0이 출시되었습니다. libghostty는 Ghostty의 핵심에서 직접 추출한, 이식성이 높고 고성능인 터미널 에뮬레이션용 C 라이브러리입니다. 1.0 출시는 라이브러리 자체와 C ABI가 이제 안정적이라는 뜻입니다.
1년 조금 전, 저는 libghostty가 출시될 예정입니다라고 썼습니다. 당시에는 Zig 모듈이 막 병합되었고 C API는 존재하지 않았으며, Ghostty 외에는 아무도 이를 사용하지 않았습니다. 오늘날 C API는 완전한 터미널 에뮬레이터이며, 무료 및 상용을 아우르는 수백 개 제품에서 수백만 명을 위해 프로덕션 환경에서 실행되고 있고, 실질적이며 강제되는 ABI 안정성 정책도 갖추었습니다.
이 글에서는 여기까지 어떻게 왔는지와 1.0이 실제로 무엇을 의미하는지 이야기합니다.1
2022년에 Ghostty 프로젝트를 시작한 이래로 가장 자주 받은 질문은 “왜인가요?”였습니다. 저는 이미 libghostty가 출시될 예정입니다 글에서 이에 답했으니, 원하시면 읽어 보세요. 오늘은 libghostty가 이미 만들어 낸 폭넓은 업계 영향을 보여 주는 방식으로 이 질문에 답하고 싶습니다. 이것이 libghostty의 존재 가치를 강력하게 입증한다고 믿습니다.
1년 전, 저는 터미널 에뮬레이션을 제대로 구현하기가 왜 어려운지를 보여 주는 예로 JetBrains IDE의 터미널 에뮬레이터인 JediTerm의 버그를 들었습니다. 1년이 지난 지금, JetBrains IDE의 터미널은 libghostty에서 실행됩니다. 이제 모든 IntelliJ, PyCharm, GoLand 등의 사용자는 libghostty 기반 터미널을 사용합니다. JetBrains의 보고서에 따르면 이는 활성 사용자 1,250만 명 이상입니다.
Neovim에는 libvterm을 libghostty-vt로 교체하는 승인된 풀 리퀘스트가 있습니다. 무엇보다도 크기 조정 시 스크롤백을 리플로우하는 문제에 관한 10년 된 이슈를 해결합니다. 유지 관리자들은 배포판에서 의존성을 별도로 패키징할 수 있도록 태그된 릴리스를 기다린 뒤 병합하려 하고 있으며, 오늘의 릴리스가 이를 가능하게 할 것입니다.
KDE 개발자들은 이를 기반으로 구축한 Konsole 대체품을 실험하고 있습니다. Vercel의 Turborepo는 TUI에서 작업 출력을 렌더링하기 위해 이를 사용합니다. devenv는 셸을 구동하는 데 사용합니다. Antithesis는 이를 이용해 TUI 프로그램을 퍼징했고 btop 등을 비롯한 실제 버그를 찾아냈습니다. Ghostel은 이를 Emacs에 도입합니다. ghostty-web은 Xterm.js 호환 API를 갖춘 WASM 빌드입니다. OrbStack 같은 상용 제품도 이를 내장합니다. 또한 herdr, cmux 같은 새로운 터미널과 “에이전틱” 코딩 도구의 물결 전체가 또 다른 에뮬레이터를 새로 작성하는 대신 이를 기반으로 구축되었습니다.
Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java 등을 위한 커뮤니티 바인딩이 있으며, awesome-libghostty 목록은 100개가 훨씬 넘는 프로젝트를 추적합니다.
오늘날 libghostty 기반 터미널을 사용하는 사람은 Ghostty 애플리케이션을 사용하는 사람보다 매우 큰 폭으로 많습니다. 또한 libghostty는 “그저” 터미널 에뮬레이터인 것보다 훨씬 더 큰 영향을 미치고 있습니다.2
1.0은 libghostty-vt가 시맨틱 버전 관리를 따르고 엄격한 ABI 호환성을 보장한다는 뜻입니다. 따라서 여러 배포판과 운영 체제의 패키저는 libghostty-vt를 안심하고 패키징할 수 있고, 프로그램 개발자는 이를 동적으로 링크해도 된다는 확신을 가질 수 있습니다.
유용한 기능을 제공하는 것을 넘어, 저는 ABI 안정성이 고품질이며 오래 지속되는 C 라이브러리의 특징이라고 믿습니다. 그래서 처음부터 함께 작업하기 즐거웠던 C 라이브러리에서 영감을 얻어, 향후 추가 기능을 허용하는 강력하고 안정적인 ABI를 갖도록 API를 설계했습니다.
모든 객체는 불투명 핸들입니다. 읽거나 쓸 수 있는 수백 개의 값은 열거형 키를 사용하는 소수의 게터와 세터를 거치므로 새 심볼을 도입하지 않고도 새 값을 쉽게 추가할 수 있습니다. 더 새로운 헤더로 빌드한 프로그램을 이전 libghostty에 링크하면 충돌이나 정의되지 않은 동작 대신 GHOSTTY_UNSUPPORTED 결과를 받습니다. 불투명하지 않은 소수의 구조체는 나중에 필드를 덧붙일 수 있도록 크기를 담거나, 예약된 패딩을 포함합니다. 열거형은 C 표준이 허용하는 한 모든 컴파일러에서 int로 고정됩니다.
CI가 ABI 정책을 강제합니다. 모든 변경 사항은 Linux에서 커밋된 기준선과 비교해 libabigail로 검사하고, macOS와 WebAssembly에서는 기준 타입 매니페스트와 비교해 검사합니다.
ELF 플랫폼에서는 내보내는 모든 심볼에도 버전이 지정되므로, 동적 로더가 나중에 불가해한 방식으로 실패하는 대신 이름을 기준으로 맞지 않는 라이브러리의 로드를 거부합니다.
ABI 안정성에 더해 1.0 릴리스는 모든 주요 운영 체제와 배포판이 표준 공식 도구를 통해 libghostty-vt를 패키징할 수 있도록 적절한 빌드 도구, 타르볼, 의존성 라이선스 매니페스트, 문서 등을 제공합니다.
Libghostty는 애플리케이션인 Ghostty와 별도의 릴리스 주기를 가집니다. 또한 libghostty에 필요한 파일과 의존성만 담은 자체 타르볼을 제공하므로 크기가 더 작고 라이선스 검증과 호환성 확인도 더 단순합니다.
각 릴리스는 서명된 소스 타르볼과 함께, Zig 자체 캐시 레이아웃의 모든 Zig 패키지를 담은 동반 의존성 타르볼을 공개합니다. 따라서 배포판은 완전히 오프라인으로 라이브러리를 빌드할 수 있습니다. 빌드는 올바른 SONAME, 헤더, pkg-config 파일, CMake 패키지 구성과 함께 공유 및 정적 라이브러리를 설치하며, --prefix, DESTDIR, lib64를 준수합니다. 디버그 정보는 기본적으로 유지되므로 배포판에서 이를 분리할 수 있습니다. 이 모든 내용은 타르볼에 포함된 PACKAGING-LIBGHOSTTY.md에 문서화되어 있습니다.
libghostty-vt는 MIT 라이선스로 제공됩니다. 런타임에는 libc 외에 아무것도 필요하지 않으며, 원하지 않는다면 libc 없이도 완전히 프리스탠딩으로 빌드할 수 있습니다.3
라이브러리는 허용적 라이선스의 소수 의존성을 컴파일에 포함합니다. SIMD를 위한 simdutf와 Google Highway, 자소 데이터용 소형 유니코드 테이블, Kitty 그래픽 프로토콜의 이미지 디코딩용 Wuffs입니다. simdutf와 Highway는 모두 libc++ 없이 빌드되므로 C++ 표준 라이브러리 의존성이 없습니다.
의존성 트리 어디에도 카피레프트 코드는 없습니다. 모든 의존성은 버전, SPDX 라이선스, 해시와 함께 기계가 읽을 수 있는 매니페스트에 나열되어 있으며, 특히 배포판이 번들 라이브러리 메타데이터를 더 쉽게 채울 수 있도록 하기 위함입니다.
배포판이 시스템 simdutf 또는 Highway를 동적으로 링크하고자 한다면 이를 위한 빌드 플래그가 있습니다.
libghostty-vt는 이식성이 매우 높습니다. 아래 표는 CI에서 빌드하고 테스트하는 모든 플랫폼과 아키텍처를 보여 줍니다. 테스트에는 전체 단위 테스트와 모든 예제 실행이 포함됩니다.
| 플랫폼 | 아키텍처 |
|---|---|
| Linux (glibc, musl) | x86_64, aarch64 |
| macOS 13+ | x86_64, aarch64 |
| iOS 13+ | aarch64 |
| FreeBSD | x86_64, aarch64 |
| Windows | x86_64 |
| Android | aarch64, x86_64, arm |
| WebAssembly | wasm32 (프리스탠딩) |
CI에서 빌드하지만 테스트는 실행하지 않는 두 번째 플랫폼 집합도 있습니다. 이 시스템들은 모두 알려진 사용자가 있지만, 자동 테스트를 위한 환경은 아직 구성하지 않았습니다.
| 플랫폼 | 아키텍처 |
|---|---|
| 베어 메탈 | riscv32, thumb |
| WebAssembly (WASI) | wasm32 |
| Windows | arm64 |
| illumos | x86_64 |
| 32비트 x86 | x86 |
테스트 대상 플랫폼은 각각 기대하는 아티팩트를 받습니다.
@rpath 설치 이름과 호환성 버전을 갖춘 dylib, 그리고 macOS, iOS, iOS 시뮬레이터를 포괄하며 Xcode 또는 Swift Package Manager에 바로 넣을 수 있는 XCFramework를 받습니다..pdb가 있는 DLL, 임포트 라이브러리, 정적 라이브러리를 받습니다. 라이브러리는 GNU ABI로 빌드되지만, MSVC 프로그램은 임포트 라이브러리를 통해 링크하며 CI에서 이를 검증합니다.GHOSTTY_UNSUPPORTED를 반환하므로 코드를 변경할 필요가 없습니다.4이식성은 단지 빌드하고 실행할 수 있는 능력만을 뜻하지 않습니다. 다양한 리소스 환경에서 작업할 수 있는 능력과 리소스 사용량 또한 포함합니다.
리소스 사용량 측면에서 라이브러리는 스레드를 전혀 만들지 않고, 사용자 지정 가능한 할당자를 통해서만 할당하며, 연산량과 메모리를 최소한으로 사용합니다. 저는 4코어와 8 GB RAM을 갖춘 Linux 서버에서, 각각 출력을 생성하는 라이브 셸을 실행하는 활성 터미널 10,000개를 구동했습니다. 이 테스트에서는 bash가 libghostty-vt보다 훨씬 많은 RAM을 사용해 8 GB 예산에 들어가지 않았기 때문에 dash를 사용해야 했습니다.
Libghostty 1.0은 중요한 이정표입니다.
이제 약 1,500줄의 C로 2025년에 존재했던 거의 모든 터미널, 그리고 2026년 현재 대부분의 터미널보다 기능이 많고 성능이 뛰어난 터미널을 만들 수 있습니다.5 풍부한 언어 바인딩 생태계 덕분에 모든 주요 프로그래밍 언어로 이를 할 수 있습니다. 이것을 무료로 얻습니다. 거의 아무 노력 없이요. 그냥 하면 됩니다.
libghostty-vt는 범용 라이브러리이므로, 임베더가 선택의 여유를 누릴 수 있도록 존재하는 터미널 프로토콜을 가능한 한 많이 구현하면서 안정성에 집중할 것입니다. 물론 이를 활성화하거나 비활성화할 수 있는 선택지도 제공할 것입니다.
어떤 libghostty-vt 임베더가 보고하는 버그든 생태계의 다른 모든 구성원을 더 낫게 만듭니다. libghostty-vt에 제공하는 모든 기능은 모두에게 빠르고 안전하게 उपलब्ध해집니다. 터미널은 파편화를 줄이며 더 빠르게 발전할 수 있습니다.
API가 아직 실험 단계였을 때 라이브러리에 기여하고, 바인딩을 작성하고, 버그를 보고하고, 그 위에 무언가를 출시한 모든 분께 감사드립니다. 모든 오픈 소스와 마찬가지로, 이것은 큰 커뮤니티가 함께한 작업이었습니다.
문서, 예제, 다운로드는 lib.ghostty.org에서 확인할 수 있습니다.
부! 👻
늘 그렇듯 매 글마다 이 말을 해야 한다는 점이 싫지만, 이 글은 AI의 도움 없이 완전히 손으로 작성했음을 밝히고 싶습니다. ↩
대부분의 사용자가 사용량을 보고하지 않기 때문에 수치는 대략적이지만, JetBrains만 해도 반복 활성 사용자 1,250만 명을 보고하며, 이는 목록에 있는 다른 모든 것을 세기 전의 수치입니다. ↩
원문에서는 “libc조차 없습니다!”라고 썼습니다. 기본 빌드는 libc를 링크하는데, SIMD 경로가 이를 사용하고 기본 할당자가 malloc이기 때문입니다. SIMD를 끄면 라이브러리는 프리스탠딩이 되며, 베어 메탈 RISC-V와 ARM 대상에서 실행되는 방식이 바로 이것입니다. ↩
기능 플래그는 WASM 전용이 아니며 모든 대상에서 작동합니다. 임베디드 장치 같은 용도에도 유용할 가능성이 높습니다. ↩
여기서 “기능”은 이해하는 터미널 프로토콜과 시퀀스의 집합을 의미하며, “성능”은 libghostty-vt가 제공하는 부분이므로 파싱 처리량과 메모리 사용량을 의미합니다. ↩