토크: Ghostty 소개와 유용한 Zig 패턴들
이 글은 Zig Showtime에서 진행한 토크를 글로 옮긴 것입니다. 영상으로 보시려면 YouTube에서 확인하실 수 있습니다: Zig Showtime: Ghostty. 영상 마지막에는 Q&A 세션이 포함되어 있지만 이 글에는 담지 않았습니다.
안녕하세요! 오늘 Ghostty에 대해 이야기하게 되어 기쁩니다. Ghostty는 Zig로 처음부터 새로 만든 터미널 에뮬레이터입니다.
참고: 이 글을 쓰는 시점에 Ghostty는 아직 공개되어 있지 않습니다. 이 토크에서 여러 번 언급하지만, 처음부터 오해가 없도록 미리 말씀드립니다. Ghostty는 무료 오픈 소스로 2024년 중 공개될 예정입니다. 현재는 소스 접근이 가능한 클로즈드 베타 프로그램을 운영 중입니다. 이 내용은 토크 곳곳에서 다룹니다.
제 이름은 Mitchell입니다! 저는 그야말로 코딩을 정말, 정말, 정말 좋아하는 사람 중 한 명입니다.
과거에 꽤 알려진 소프트웨어 프로젝트들을 몇 개 시작했습니다. 들어보셨을 수도, 아닐 수도 있겠죠: Vagrant, Terraform, Vault 등입니다. 다만 그 프로젝트들에는 수년째 참여하지 않고 있습니다.
저는 또 항상 사이드 프로젝트를 하나씩은 하고 있는 사람입니다. 언제나 그렇습니다. 10년쯤 전에는 Hearthstone 로그 분석 및 리플레이 소프트웨어를 만들어 프로 e스포츠 팀에 판매하기도 했고, 몇 년 전에는 메일 서버를 처음부터 직접 만들어 제 도메인들의 메일을 운영하기도 했습니다. 그리고 이제는, 터미널 에뮬레이터를 만들게 됐네요.
이 슬라이드는 저녁 식사 시간쯤 만들었는데 너무 배가 고파서 그냥 제가 먹는 사진들을 잔뜩 넣어봤습니다. 특별히 음식에 열정이 있는 건 아닙니다. 그냥 지금 이 순간 배가 고플 뿐이죠. 그리고 방을 하나로 묶어 주는 테마 요소가 있으면 좋잖아요.
하지만 이 토크의 주제는 Ghostty입니다! 터미널 에뮬레이터 말이죠!
본격적으로 들어가기 전에 Ghostty가 어떻게 생겼는지 보여드리겠습니다! 이 스크린샷 하나만 봐도 Ghostty가 얼마나 기능이 풍부한지 알 수 있습니다!
Ghostty는 macOS와 Linux용 네이티브 앱입니다. 분할 화면을 지원하고, 트루 컬러를 지원하며, vim도 문제없이 돌아가고, 여러 폰트 스타일(볼드, 이탤릭 등)을 지원하고, Kitty 그래픽스 프로토콜도 지원합니다. 그 외에도 더 많은 기능이 있습니다. 이건 이 스크린샷에서 보이는 것만 말씀드린 겁니다!
터미널 에뮬레이터가 무엇인지 모르신다면, 아마 이미 사용해 보셨을 겁니다. 여기에 몇 가지 예가 있습니다. 그 외에도 수십, 수백 개가 더 있습니다.
그렇게나 많은데 왜 또 하나를 만들까요?
근본적으로 보면, 제가 본 오늘날 터미널 에뮬레이터의 현실은 이렇습니다. 빠른 터미널, 기능이 풍부한 터미널, 네이티브한 터미널이 있습니다. 이 중 최대 두 가지만 가질 수 있습니다.
Ghostty는 이 모든 속성을 지향하며, 제 생각에는 이미 달성했다고 봅니다.
빠르고, 기능이 풍부하고, 네이티브한 느낌은 서로 배타적이지 않습니다.
Ghostty는 오늘날 기준으로도 충분히 잘하고 있어 표에서 초록색 체크를 받을 자격이 있다고 생각하며, 앞으로 더 개선할 여지도 많습니다.
또, 경고 표시를 짚고 넘어가자면, 제가 생각하는 네이티브 플랫폼 경험의 기준은 앱이 해당 플랫폼을 위해 특별히 만들어진 네이티브 앱처럼 느껴지고 동작하는 것입니다. 이 기준이 무리하다고 생각하지 않습니다. 예를 들어 Alacritty는 새 창을 열 때마다 새 프로세스를 만들기 때문에 다소 네이티브하지 않다고 볼 수 있고, Kitty는 탭에 네이티브 위젯이 아닌 것을 사용하므로 다소 네이티브하지 않다고 볼 수 있습니다. 그 외에도 각각에 대해 더 많은 예가 있습니다.
그래서 “기반” 수준에서 제가 하려는 것은 이렇습니다: Alacritty 수준의 속도, Kitty 수준의 풍부한 기능, iTerm(macOS용) 수준의 네이티브 통합을 갖추는 것입니다.
하지만 저는 더 나아가고 싶습니다. 터미널이 GUI 애플리케이션 개발을 위한 현대적인 플랫폼으로서의 브라우저와 유사하게, 텍스트 애플리케이션 개발을 위한 현대적인 플랫폼이 되길 바랍니다(좋든 싫든).
브라우저는 매년 수십 개(수백 개?)의 새로운 기능을 내놓습니다. 빠르게 혁신하고 애플리케이션 개발자들을 설레게 하죠. 조금 과할 수도 있지만, 터미널도 지금보다 더 빠르게 혁신할 수 있다고 생각합니다.
몇 가지 예를 들면 다음과 같습니다:
- 진행률 표시줄! 왜 우리는 매번 진행률 표시줄을(대부분 형편없이) 다시 그리고 있는 걸까요?
- 드래그 앤 드롭으로 에디터 등 애플리케이션이 더 네이티브하게 동작하도록.
- 탭/분할 제어로 멀티플렉서가 최신 터미널 에뮬레이터의 성능과 기능을 활용할 수 있도록.
- 마우스 제스처로 TUI가 플릭, 멀티터치, 관성 등에 반응할 수 있도록.
- 보안 기능: 터미널 이스케이프 시퀀스는 오늘날 매우 위험한 영역입니다. 이에 대해서는 다른 기회에 더 이야기하겠습니다. 더 잘할 수 있습니다.
- 그 외에도 더 많은 것들!
Ghostty는 빠를까요? 어떻게 알 수 있을까요? 터미널 에뮬레이터를 벤치마크하는 방법은 많지만, 이 토크에서 그 부분에 많은 시간을 할애하고 싶지는 않습니다. 말씀드리고 싶은 요점은 Ghostty는 “빠르다”는 것입니다. “가장 빠르다”고 주장하려는 건 아닙니다.
여기서는 Ghostty에서 FPS를 기록하는 DOOM 불 애니메이션을 실행하는 모습을 보여드립니다. 워낙 많은 셀을 변경하고 스크롤백도 수행하기 때문에 좋은 스트레스 테스트가 됩니다.
Ghostty는 약 480~500 FPS를 유지하며 애니메이션이 매우, 매우 부드럽게 재생되는 것을 볼 수 있습니다. 비교를 위해 공식 macOS Terminal.app(훌륭한 커뮤니티 프로젝트를 깎아내리지 않기 위해 선택했습니다)은 10 FPS 미만으로 매우 끊깁니다. Alacritty나 Kitty 같은 “빠른” 터미널 에뮬레이터를 사용하면 Ghostty와 비슷한 수치가 나옵니다.
요점은 Ghostty가 가장 빠르다고 말하려는 게 아니라, “빠른” 범주에 속한다는 것이며, 그래서 제 표의 초록색 체크는 타당하다고 생각합니다.
직접 터미널에서 시도해 보세요: https://github.com/const-void/DOOM-fire-zig/
글 형식에 대한 참고: 슬라이드 이미지는 이미지이므로 영상이 표시되지 않습니다. Ghostty는 링크된 프로그램을 대략 480~500 FPS로 실행합니다.
Ghostty는 기능이 풍부할까요? 이를 정량화할 방법은 모르겠지만, 여기 우리가 지원하는 기능들의 정성적인 목록이 있습니다. 그중 다수는 비교적 보기 드문 기능들입니다.
macOS에서는 메인 GUI 경험이 AppKit과 SwiftUI를 사용해 Swift로 작성되었습니다. 탭은 네이티브 탭이고, 분할은 네이티브 UI 컴포넌트이며, 다중 창도 예상대로 동작합니다. Linux에서는 GUI 경험이 GTK를 사용하며 실제 GTK 창과 다른 위젯들을 사용합니다.
오류 메시지 같은 기능은 전용 터미널 뷰로 구현하지 않고, 실제로 네이티브 UI 컴포넌트를 사용합니다. 요점은 터미널 표면과 핵심 로직은 크로스 플랫폼이지만, 사용자 상호작용은 진정한 네이티브 경험을 위해 각 운영체제별로 목적에 맞게 제작되었다는 것입니다.
기술 스택과 프로젝트 자체에 대해 아주 빠르게 개요를 살펴보겠습니다.
먼저 프로젝트입니다. 현재 프로젝트는 소스 접근이 가능한 클로즈드 베타 단계에 있습니다. 클로즈드 베타를 진행하는 이유는 이 프로젝트가 개인 프로젝트이며 제 자신을 과부하시키고 싶지 않기 때문입니다. 클로즈드 베타를 통해 천천히 사람들을 초대하고, 문제를 수정하고, 반복할 수 있습니다.
프로젝트가 최종적으로 공개되면 무료 오픈 소스로, 아마도 GPL 라이선스로 제공될 예정입니다. “아마도”라고 말하는 이유는 테스터들의 의견을 환영하기 때문입니다. 현재 활발히 논의 중인 부분 중 하나는 MIT 같은 더 허용적인 라이선스를 선택하는 것입니다.
지금 참여할 수 있는 공개 Discord가 있습니다. 저는 그 Discord에서 베타 테스터를 모집합니다. 그리고 제 개인 블로그에 가끔 개발 일지를 올립니다.
기술적인 측면에서는 이 토크에서 대부분을 자세히 다룰 예정이므로 여기서는 많은 시간을 쓰지 않겠습니다. Zig로 작성되었고, 네이티브 부분은 진짜 네이티브(즉 macOS에서는 AppKit)이며, 이벤트 루프 같은 자체 의존성도 많이 작성했다는 것만 알아두시면 됩니다.
자, 그럼 가장 당연한 질문부터 시작해 보겠습니다: 왜 Zig일까요?
간단히 말하면 커뮤니티, 언어, 빌드 시스템이 마음에 들기 때문입니다. 언어와 빌드 시스템의 기능이 이 터미널 프로젝트에 매우 잘 맞으며, 이 토크는 그 점을 강조하기 위해 마련되었습니다.
원하는 대로 추측하세요. 저는 이 질문에 관심도 없고 답하고 싶지도 않습니다. 저는 Zig를 선택했고, Zig가 좋고, 넘어가죠.
서브시스템별 코드 아키텍처 개요입니다. Ghostty 내부의 주요 서브시스템과 그 설명입니다. 다음 슬라이드에서 시각적인 다이어그램을 보여드리겠습니다...
이것들을 조합한 런타임 아키텍처입니다. 이 다이어그램의 모든 것은 macOS의 “apprt”를 제외하고 100% Zig이며, apprt는 일부 Swift로 되어 있습니다.
기본적인 아이디어는 다음과 같습니다:
- 앱이 실행되면 진입점은 “apprt”에 있습니다.
- Apprt는 하나 이상의 “surface”를 생성하는 역할을 합니다. surface는 하나의 대화형 터미널을 나타내는 모든 것입니다. Apprt는 이를 창, 탭, 분할 등 어디에 넣을지 선택할 수 있습니다. 코어 입장에서는 상관없습니다!
- 각 surface는 IO 스레드와 렌더러 스레드를 시작합니다.
- IO 스레드는 pty 파일 디스크립터를 생성하고 설정된 명령(보통 셸)을 실행합니다. IO 스레드는 pty 읽기/쓰기, 이스케이프 시퀀스 같은 터미널 이벤트 처리 등을 담당합니다.
- 렌더러 스레드는 터미널 상태를 변환해 일정한 프레임레이트로 픽셀을 그립니다. 렌더러는 폰트 셰이핑과 렌더링도 담당합니다.
터미널 에뮬레이터에 대해 아무리 신나 있더라도, 여기는 Zig Showtime이므로 이 토크의 초점은 Ghostty에서 사용하는 Zig 패턴 이야기로 옮겨갈 것입니다.
이 패턴들은 특별한 순서 없이 소개됩니다.
온라인 독자를 위한 참고: 이 섹션의 대부분은 실제 Ghostty 소스 코드 안에서(당연히 Ghostty 터미널 안에서) 해당 패턴들을 탭을 넘겨가며 보여주는 방식으로 진행했습니다. 이 슬라이드 부분으로 영상을 빨리 감으면 시청할 수 있습니다.
첫 번째는 comptime 인터페이스입니다!
comptime 인터페이스란 컴파일 타임에 알려진 정보에 따라 구현이 달라지는 값입니다.
여기에 보이는 소스 코드는 Ghostty에서 직접 발췌한 실제 예제입니다. 여기에 보이는 예시는 빌드 옵션에 따라 달라지는 “font face”의 정의입니다. 특정 빌드 타임 설정에서는 CoreText를, 다른 설정에서는 FreeType을 사용하고, 웹 기반 Canvas 구현도 지원한다는 것을 볼 수 있습니다!
하단 패널은 인터페이스가 사용되는 모습을 보여줍니다. 이 인터페이스를 사용하는 코드는 어떻게 동작하는지 신경 쓸 필요가 없습니다. 정의된 인터페이스가 있고 그것을 호출하거나 사용하면 됩니다.
comptime 인터페이스는 Ghostty가 플랫폼별 기능을 구현하는 주요 방식이며 폰트, 렌더러, 앱 런타임 등에서 사용됩니다.
주요 이점은 절대 런타임에 바뀌지 않는 구현에 대해 런타임 오버헤드 없이 구현을 교체할 수 있다는 점입니다. 모든 필드 접근과 함수 디스패치는 컴파일 타임에 결정됩니다.
Zig 컴파일러의 특징 중 하나는 실제로 참조된 코드만 분석한다는 점입니다. 이는 버그가 아니라 기능입니다. 보이지 않게 만들기 위해 지저분한 #ifdef 스타일 가드가 없어도 상황에 따른 코드가 존재할 수 있게 해주기 때문입니다.
단점은 comptime 인터페이스의 경우 모든 빌드 옵션을 테스트해야 한다는 점이며, 그렇지 않으면 빌드 실패를 일으키기가 매우 쉽습니다.
Ghostty는 CI에서 모든 빌드 옵션을 테스트합니다.
앞서 보여드린 것과 같은 슬라이드입니다. 이 기능들과 패턴들이 무엇을 가능하게 하는지 보여드리기 위해 다시 보여드립니다.
동일한 서브시스템들에 대해 오늘날 존재하는 구현과 앞으로 가능한 구현을 정리한 것입니다. 이러한 대체 구현들의 거의 대부분은 comptime 인터페이스입니다.
다음은 또 다른 comptime 이야기입니다. 이번에는 데이터 테이블입니다.
이것은 데이터 테이블의 예시입니다. 여기서는 Kitty Keyboard Protocol에 대한 입력 인코딩 정보를 보고 있습니다.
RawEntry 튜플 형태는 실제 사용에는 그다지 좋지 않지만, 테이블을 쉽게 구성하기에는 매우 편리합니다. 이 둘 모두 pub이 아닌 것에 주목하세요. 이 파일 외부에서 사용되도록 의도된 것이 아닙니다.
이 비공개 엔트리들을 이용해 이후 가공을 진행합니다...
comptime을 이용해 원시 엔트리를 가공할 수 있습니다. 여기서는 원시 엔트리 튜플을 런타임에 더 친화적인 구조체로 변환하고 있습니다.
변환 과정은 모두 컴파일 타임에 일어나므로 런타임 비용이 없습니다. 게다가 원시 엔트리는 런타임 코드에서 전혀 사용되지 않으므로 최종 빌드 바이너리에서 공간을 차지하지 않습니다.
이 경우 변환은 대부분 단순한 데이터 변환이지만, 더 멋진 일도 할 수 있습니다...
여기는 플랫폼별 키 코드 테이블의 예시입니다. 원시 데이터에는 각 플랫폼(Mac, Windows, xkb를 통한 Linux, 심지어 USB 코드)별 키 코드가 들어 있습니다. 하지만 런타임에서는 빌드 중인 플랫폼에 대해서만 entries로 변환합니다.
이렇게 하면 구조체가 더 간결해지고, 최종 바이너리가 더 작아지며, 런타임에 조건부 조회를 할 필요가 없습니다.
이를 더 확장할 수도 있습니다. 여기서는 주어진 모드에서 주어진 키 입력에 대해 터미널이 실행 중인 프로그램에 보내야 할 이스케이프 시퀀스를 정의하는 데이터 테이블의 예시입니다.
이 중 많은 것들이 뚜렷하고 반복적인 패턴을 따릅니다. 일일이 손으로 입력하는 대신, comptime에 실행되는 함수를 작성해 데이터를 프로그래밍 방식으로 생성할 수 있습니다.
많은 프로젝트에서는 종종 셸, Python 또는 기타 스크립트로 데이터를 생성합니다. Zig에서는 이 모든 것을 comptime으로 할 수 있습니다.
참고: pcStyle 함수 본문을 감싸는 comptime {} 래퍼는 이 함수가 절대 런타임에 호출될 수 없도록 보장하는 트릭입니다.
다음으로는 comptime 데이터 테이블을 기반으로 comptime 타입 생성에 대해 이야기하겠습니다.
@Type 빌트인에 대한 30초 튜토리얼부터 시작해 보겠습니다. 많은 분들이 이 존재를 모릅니다. @Type 빌트인을 사용하면 comptime에 타입을 생성할 수 있습니다. 엄청나게 강력하지만 엄청나게 무섭기도 합니다.
조심하세요! 이것은 의미가 있는 상황에 사용을 제한하고 싶은 기능입니다. “완전한 메타프로그래밍”으로 빠지지 않도록 주의해야 합니다. 가독성을 해치고 컴파일 속도를 늦추기 때문입니다.
이 예시는 Ghostty가 지원하는 다양한 “모드”를 어떻게 정의하는지 보여줍니다. 모드란 실행 중인 프로그램이 조회하고 설정할 수 있는 터미널 모드로, 터미널 에뮬레이터의 동작을 바꾸는 것입니다. 수백 개의 모드가 있습니다.
이 예시에서는 비공개 entries 데이터 테이블이라는 표준 패턴이 있습니다. 이 테이블을 가공하는 방법 중 하나는 @Type 빌트인을 사용해 모든 키를 완전한 enum으로 바꾸는 것입니다.
enum을 미리 정의하지 않는 이유는 각 엔트리와 연관된 추가 데이터가 있어 편집과 참조의 편의를 위해 함께 묶어두고 싶기 때문입니다. 이 경우 각 모드는 값을 가지고 있습니다.
이것은 FontIndex 구조체의 생성을 보여줍니다. 이 구조체는 Ghostty에서 특정 폰트를 참조하는 데 사용됩니다. 상위 비트는 스타일(regular, bold, italic 등)을 나타내고 하위 비트는 배열의 인덱스를 나타내는 데 사용합니다.
스타일에 필요한 비트 수를 파악함으로써 인덱스에 필요한 정확한 비트 수를 결정할 수 있습니다.
더 많은 스타일을 추가해 더 많은 비트가 필요해지면, 인덱스로 표현할 수 있는 폰트 수가 제한됩니다.
참고: 이는 특정 크기를 사용할 수 있도록 보장하는 테스트와 짝을 이루므로, Style의 비트 크기를 늘릴 때는 매우 신중하게 결정하게 됩니다.
다음으로는 Ghostty가 Swift와 어떻게 통합되었는지 이야기하겠습니다. 사실 이는 C API를 호출할 수 있는 어떤 언어에도 적용되는 더 일반적인 해결책입니다.
우리가 직면한 문제는 현대적인 macOS 개발이 사실상 Swift를 요구한다는 점입니다. 물론 Objective-C로도 괜찮은 애플리케이션을 만들 수 있지만, Apple이 새롭게 내놓는 멋진 기능과 프레임워크는 모두 Swift 전용이며, ObjC의 미래는 사실상 정해져 있습니다.
Linux에서는 Zig가 그냥 GTK C API를 사용합니다. Zig가 C API를 호출할 수 있다는 것은 잘 알려져 있습니다. 문제는 Swift(맥 앱용)가 C API를 내보낼 수 없고, macOS 애플리케이션은 main을 소유하길 기대한다는 점입니다.
하지만... Swift는 C를 호출할 수 있습니다. 그리고 Zig는 C API를 내보낼 수 있습니다.
그래서 결국 Ghostty를 임베디드 C API로도 패키징했습니다. 이를 정적 라이브러리로 컴파일해 Swift 기반 macOS 앱이 의존하게 하고, Swift가 해당 라이브러리를 호출하도록 했습니다.
그리고 여기 예를 들어 Swift가 Ghostty 설정을 초기화하는 모습이 있습니다.
이렇게 하면 Linux나 다른 미래 플랫폼과의 이식성을 희생하지 않으면서도 매우 네이티브한 macOS 경험을 가질 수 있습니다.
하지만 더 멋진 점은 Zig가(특히 Zig 빌드 시스템이) 프로그램을 exe와 lib 모두로 컴파일할 수 있도록 만드는 것을 얼마나 쉽게 해주었는가 하는 점입니다.
향후에는 C lib 아티팩트를 공식 아티팩트로 지원해 누구나 자신의 애플리케이션에 완전히 동작하고, 기능이 풍부하며, 빠르고 현대적인 터미널을 임베드할 수 있도록 할 계획입니다.
하지만 지금은 아직 공개되지 않았으며 macOS 애플리케이션에만 사용됩니다.
이것으로 Ghostty에서 사용하는 주요 패턴들을 둘러보았습니다. 더 많은 것들이 있지만 한 번의 토크에서는 이 정도가 적당하다고 생각합니다. 그중 일부 패턴은 그 자체로 하나의 토크가 될 수 있을 겁니다...
이 토크의 마지막은 Ghostty에 대해 조금 더 이야기하며 마무리하겠습니다!
그럼 프로젝트의 다음 단계는 무엇일까요?
터미널 에뮬레이션 기능은 꽤 완성도가 높습니다. Ghostty와 호환되지 않거나 잘못 렌더링되는 프로그램을 찾기는 극히 드뭅니다. 그런 것들이 발견되면 최우선 버그로 처리됩니다. 수십 명의 테스터가 전문적인 업무에 Ghostty를 하루 종일 사용하고 있으며, 안정적으로 동작합니다.
현재 초점은 주로 네이티브 플랫폼 경험에 맞춰져 있으며, 앱이 해당 플랫폼에 더욱 목적에 맞게 만들어진 것처럼 느껴지도록 하는 데 있습니다. 예를 들어 macOS에서는 파일 기반 설정만이 아니라 GUI 설정 창을 작업 중입니다. 또한 Apple 기기 간 iCloud 설정 동기화(자신의 데이터를 직접 소유) 같은 작업도 하고 있습니다.
그 외에도 더 많은 것들이 있습니다...
Ghostty는 빠르지만 여전히 개선할 여지가 많습니다. 우리가 이미 알고 있는 자잘한 성능 개선 포인트가 아직 많이 남아 있는데, Ghostty가 이미 꽤 빠르다는 점을 생각하면 기대가 됩니다.
추가로 VT 스트림 파서와 핸들러를 퍼즈하고 싶습니다. 퍼징을 조금 해봤는데 몇 가지 버그를 찾았으니, 분명 더 많은 버그가 숨어 있을 겁니다.
시작 시간, 입력 지연 등 전혀 측정해 보지 않은 성능 영역도 다양합니다. 이러한 코드 경로가 느려지지 않도록 노력해 왔지만, 측정해 보면 분명 큰 개선점을 찾을 수 있을 겁니다.
Ghostty의 현재 메모리 사용량은 그다지 좋지 않습니다. 끔찍한 수준은 아니지만 좋다고 하기도 어렵습니다. CPU와 렌더러 성능이 뛰어나도록 하는 데 많은 시간과 노력을 쏟았지만, 메모리 사용량에는 다소 소홀했습니다. 쉬운 개선점도 있습니다. 예를 들어 현재는 전체 스크롤백 버퍼를 미리 할당하는데, 이는 몇 메가바이트에 해당합니다. 이를 동적으로 할당하도록 만드는 것은 꽤 쉬울 겁니다.
활발한 베타 프로그램을 운영 중입니다. 프로그램에 참여하려면 Discord에 가입해야 합니다.
우리의 프로세스는 안정성을 중심으로 합니다. 일정 수의 테스터를 초대하고, 남아 있는 모든 이슈가 해결될 때까지 다음 물결의 초대를 진행하지 않습니다. 여기서 “이슈”란 버그나 중요한 누락 기능을 의미합니다. 모든 기능 요청을 다 만들지는 않습니다.
Ghostty는 내년(2024년) 중 언젠가 공개될 예정입니다. 그 전까지 베타 프로그램을 잠재적으로 수백 명 규모로 계속 확장할 계획입니다.
처음 공개되는 버전은 1.0이 될 것이고, 아무리 늦어도 1.0 릴리스 후보가 될 것입니다. 이처럼 철저한 테스트 프로그램의 목표는 처음부터 안정적이고 기능이 풍부한 프로젝트로 출범하는 것입니다.
앞서 말씀드렸지만 Ghostty는 FOSS가 될 것이며 라이선스는 아마도 GPL이 될 것입니다. “아마도”라고 하는 이유는 테스터들의 의견이 여전히 반영되기 때문이지만, 현재 계획은 GPL입니다. 다른 많은 터미널들도 GPL입니다. 특히 libghostty와 GPL에 대한 우려가 있어 활발히 논의 중인 영역입니다.
안정적인 소프트웨어를 갖고 싶은 것 외에도, 지연의 한 가지 이유는 출산을 몇 주 앞두고 있다는 점입니다 갓 태어난 아기가 있다는 점입니다. 매우, 매우 바빠질 것을 알기에 본격적인 OSS 커뮤니티를 만들고 출범시키는 데 스스로에게 과도한 압박을 주고 싶지 않습니다.
어떤 부모님들은 갓 태어난 아기가 집에 있는데 어떻게 새 토크를 쓰고, 발표하고, 이 글을 만들 시간이 있었냐고 물으시더군요. 이 토크와 이 글은(이 메모 같은 일부를 제외하고) 아기가 태어나기 전에 작성했습니다. 토크 발표 자체는 수유 사이에 끼워 넣는 게 그리 어렵지 않았습니다. 그리고 네, 피곤합니다. 😊
❤️