이 글은 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에서는 실제 GTK 창과 위젯을 사용하는 GTK로 GUI 경험을 제공합니다.

오류 메시지 같은 기능도 특수한 터미널 뷰로 구현하지 않고, 실제로 진짜 네이티브 UI 컴포넌트를 사용합니다. 요점은, 터미널 화면과 핵심 로직은 크로스 플랫폼이지만, 사용자 상호작용은 운영체제별로 진정한 네이티브 경험을 위해 목적에 맞게 제작되었다는 것입니다.

기술 스택과 프로젝트 자체에 대해 아주 간단히 개요를 살펴보겠습니다.

먼저 프로젝트에 대해 말씀드리겠습니다. 현재 프로젝트는 소스 접근이 가능한 클로즈 베타 단계에 있습니다. 클로즈 베타를 하는 이유는 이것이 개인 프로젝트이고 제 자신이 감당할 수 없을 정도로 일이 몰리는 것을 원치 않기 때문입니다. 클로즈 베타를 하면 사람들을 천천히 초대하고, 문제를 해결한 뒤, 다시 반복할 수 있습니다.

프로젝트가 최종적으로 공개되면 무료 오픈소스로 제공될 것이며, 라이선스는 아마도 GPL이 될 가능성이 높습니다. “아마도”라고 말하는 이유는 테스터들의 의견을 환영하기 때문입니다. 현재 활발히 논의 중인 주제 중 하나는 MIT 같은 더 관대한 라이선스를 선택하는 것입니다.

오늘 바로 가입할 수 있는 공개 Discord가 있습니다. 저는 그 Discord에서 베타 테스터를 모집합니다. 그리고 개인 블로그에 가끔 개발 일지를 작성합니다.

기술적인 측면에서는 이 발표에서 대부분을 자세히 다룰 예정이므로 여기서는 많은 시간을 쓰지 않겠습니다. Zig로 작성되었고, 네이티브 부분은 진짜 네이티브이며(즉, macOS에서는 AppKit), 이벤트 루프 같은 의존성도 상당 부분 직접 작성했다는 점만 알아두시면 됩니다.

자, 그럼 당연한 질문부터 시작해 보겠습니다: 왜 Zig일까요?

간단히 말하면, 저는 커뮤니티와 언어, 그리고 빌드 시스템을 좋아합니다. 언어와 빌드 시스템의 기능이 이 터미널 프로젝트에 아주 잘 맞다고 생각하며, 이 발표는 바로 그 점을 조명하는 데 중점을 두고 있습니다.

원하는 대로 추측하셔도 됩니다만, 저는 이 질문 자체를 그다지 좋아하지 않고 굳이 답하고 싶지도 않습니다. 저는 Zig를 선택했고, Zig가 좋습니다. 넘어가죠.

서브시스템별 코드 아키텍처 개요입니다. Ghostty 내부의 주요 서브시스템들과 그 설명입니다. 다음 슬라이드에서 시각적인 다이어그램을 보여드리겠습니다…

이것들을 종합한 런타임 아키텍처입니다. 이 다이어그램의 모든 것은 100% Zig이며, macOS의 “apprt”만 일부 Swift로 되어 있습니다.

기본적인 아이디어는 다음과 같습니다:

1. 앱이 실행되면 진입점은 “apprt”에 있습니다.
2. Apprt는 하나 이상의 “surface”를 생성하는 역할을 합니다. Surface는 하나의 대화형 터미널을 나타내는 모든 것입니다. Apprt는 이를 창, 탭, 분할 등 어디에 두든 선택할 수 있습니다. 코어 입장에서는 어디에 두든 상관없습니다!
3. 각 surface는 IO 스레드와 렌더러 스레드를 시작합니다.
4. IO 스레드는 pty 파일 디스크립터를 생성하고 설정된 명령(보통 셸)을 실행합니다. IO 스레드는 pty를 읽고 쓰는 작업, 이스케이프 시퀀스 같은 터미널 이벤트 처리 등을 담당합니다.
5. 렌더러 스레드는 터미널 상태를 변환해 일정한 프레임으로 픽셀을 그립니다. 렌더러는 폰트 셰이핑과 렌더링도 담당합니다.

터미널 에뮬레이터에 대해 아무리 신나 있더라도, 여기는 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가 지원하는 다양한 “mode”를 어떻게 정의하는지 보여줍니다. mode는 실행 중인 프로그램이 조회하고 설정할 수 있는 터미널 모드로, 터미널 에뮬레이터의 동작을 바꿉니다. 이러한 mode는 수백 개에 이릅니다.

이 예에서도 비공개 entries 데이터 테이블이라는 표준 패턴을 사용합니다. 이 테이블을 처리하는 방법 중 하나는 @Type 빌트인을 사용해 모든 키를 완전한 enum으로 바꾸는 것입니다.

enum을 미리 정의하지 않는 이유는 각 엔트리와 연관된 추가 데이터를 함께 묶어두어 편집과 참조를 쉽게 하고 싶기 때문입니다. 이 경우 각 mode는 값을 가지고 있습니다.

이것은 FontIndex 구조체의 생성 과정을 보여줍니다. 이 구조체는 Ghostty에서 특정 폰트를 참조하는 데 사용됩니다. 상위 비트는 스타일(일반, 볼드, 이탤릭 등)을 나타내는 데 쓰고, 하위 비트는 배열에 대한 인덱스를 나타내는 데 사용합니다.

스타일에 필요한 비트 수를 파악하면 인덱스에 필요한 정확한 비트 수를 결정할 수 있습니다.

스타일을 더 추가해 비트가 늘어나면, 인덱스로 표현할 수 있는 폰트 수가 제한됩니다.

참고: 이는 특정 크기를 확보하고 있음을 보장하는 테스트와 함께 제공되므로, 혹시 Style의 비트 크기를 늘리게 되더라도 매우 의식적으로 결정하게 됩니다.

다음으로는 Ghostty가 Swift와 어떻게 통합되었는지 이야기하겠습니다. 사실 이는 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 커뮤니티를 키우고 론칭하는 일까지 스스로에게 과도한 압박을 주고 싶지 않기 때문입니다.

어떤 부모님들은 갓난아기가 집에 있는데 어떻게 발표를 새로 쓰고, 발표하고, 이 글을 작성할 시간이 있었냐고 물으셨습니다. 이 발표와 이 글(여기 같은 일부 메모 제외)은 아기가 태어나기 전에 작성했습니다. 발표 자체는 수유 사이에 끼워 넣는 것이 그리 어렵지 않았습니다. 그리고 네, 피곤합니다. 😊

❤️

• https://discord.gg/ghostty
• https://mitchellh.com/ghostty