Ghostling & libghostty

개요

Ghostling은 libghostty C API를 활용한 최소 기능(Minimum Viable) 터미널 에뮬레이터 데모. 단일 C 파일 + Raylib로 작성되어 libghostty-vt 라이브러리의 활용 가능성을 보여줌. 핵심 메시지: 터미널 코어와 GUI/렌더러 분리 — libghostty가 정확한 VT 에뮬레이션만 담당하고, 렌더링·윈도우는 사용자가 자유롭게 선택.

GitHub: https://github.com/ghostty-org/ghostling
부모 프로젝트: Ghostty (Mitchell Hashimoto의 GPU 가속 터미널)
배경 글: https://mitchellh.com/writing/coming-soon-libghostty
언어: C (단일 파일), 빌드: CMake + Zig 0.15.x

등장 배경

Ghostty = GPU 가속 모던 터미널 (Zig + Metal/OpenGL)
  ↓ 핵심 코어를 라이브러리로 추출
libghostty-vt = VT 시퀀스 파싱·터미널 상태 관리만
  ↓ 활용 예시
Ghostling = "이렇게 다른 GUI에 끼워 넣을 수 있다" 데모

Mitchell Hashimoto의 설명 기준으로 libghostty의 출발점은 단순한 “Ghostty 코어 분리”가 아니라, 여러 앱이 터미널 에뮬레이션을 매번 ad-hoc으로 다시 구현하는 문제를 해결하려는 시도입니다. 대부분의 앱에게 터미널 에뮬레이션은 핵심 비즈니스가 아니지만, 실제 구현 난이도는 매우 높아 불완전성, 예외 처리 누락, 성능 저하가 반복됩니다.

왜 필요한가

현재 흔한 문제

IDE, 대시보드, 빌드 로그 뷰어, 원격 도구가 각자 터미널 파서를 따로 구현
ANSI 정도만 단순 파싱하다가 복잡한 스타일 시퀀스, RGB 표기, 줄바꿈, 커서 상태에서 깨짐
GitHub Actions, Vercel 빌드 로그 같은 “스타일 텍스트 출력”도 사실상 터미널 시퀀스 해석 문제를 품고 있음
Jediterm 계열처럼 일부 시퀀스 호환성 이슈가 누적되는 사례가 존재

핵심은: 터미널 프로토콜은 겉보기보다 훨씬 복잡하고, 재사용 가능한 검증된 코어가 필요하다는 점입니다.

libghostty란?

구조

libghostty (C/Zig API 제공)
  └─ libghostty-vt
        - VT 시퀀스 파싱 (ANSI escape codes)
        - 커서 위치, 스타일, 스크롤백
        - 의존성 없음 (zero-dep)
        - SIMD 최적화 파싱
        - 고급 유니코드 지원
        - 효율적 메모리 사용
        - 광범위한 테스트

설계 목표

모든 앱에 임베드 가능한 터미널 코어
최소 의존성과 높은 이식성
최종적으로는 크로스 플랫폼 C API 중심
Ghostty 앱보다 더 넓은 환경으로 확장
- macOS
- Linux (x86_64, aarch64)
- 향후 Windows, 임베디드, WASM

기술적 강점

Ghostty에서 수년간 검증된 코어 재사용
SIMD 최적화 파싱
강한 Unicode 지원
정교한 메모리 구조
광범위한 프로토콜 호환성
- Kitty Graphics
- Tmux Control Mode
- 다양한 ANSI/VT escape sequence

즉, libghostty-vt는 “간단한 ANSI 색상 파서”가 아니라 정확한 VT 상태 머신을 외부 라이브러리로 노출하는 작업에 가깝습니다.

포함하지 않는 것 (의도적)

렌더링 (GPU/CPU 모두)
윈도우 관리
탭, 다중 윈도우, 분할 화면
세션 관리, 설정 파일
GUI, 검색 UI

→ 사용자가 직접 구현 또는 다른 라이브러리와 결합

libghostty-vt 현황

현재 상태

첫 번째 공개 컴포넌트는 libghostty-vt
Zig API는 테스트 가능
C API는 설계 진행 중
Ghostty macOS 앱 내부에도 C API가 있지만, 외부 공개용으로는 적합하지 않아 새로운 공개 API를 별도 설계 중
프로젝트 단계는 알파

공개 방향

1. libghostty-vt 공개
   - 파싱
   - 상태 유지
   - zero dependency API
 
2. 이후 모듈 확장
   - 입력 처리
   - GPU 렌더링
   - UI 프레임워크 연동

Mitchell 기준으로 목표는 6개월 내 첫 태그 릴리즈였고, 초기 단계에서 바인딩 작성자와 임베더들의 피드백을 적극 받는 방향입니다.

Ghostling의 위치

완전한 일상용 터미널 ❌
최소 실행 가능 데모 ✅
libghostty-vt API의 사용법 예시 ✅
다양한 렌더러와 결합 가능성 입증 ✅

핵심 특징

단일 C 파일
Raylib (2D 그래픽)로 렌더링
단일 스레드 동작
GPU 직접 렌더링 ❌ → 2D 그래픽 사용

지원 기능

✅ 구현됨

카테고리	기능
레이아웃	텍스트 리플로우 + 창 크기 조정
색상	24비트 컬러, 256색 팔레트
스타일	볼드, 이탤릭, 역상
유니코드	다중 코드포인트 그래핌 처리 (셰이핑·레이아웃은 없음)
수정키	Shift, Ctrl, Alt, Super
키보드	Kitty Keyboard Protocol
마우스 추적	X10, normal, button, any-event
마우스 리포팅	SGR, URxvt, UTF8, X10 포맷
스크롤	휠 + 드래그 스크롤바
포커스	CSI I / CSI O 리포팅

⏳ 예정 (libghostty-vt에 미구현)

Kitty Graphics Protocol (이미지 출력)
OSC 클립보드 지원
OSC 타이틀 설정

장기 확장 계획 (libghostty 계열)

키보드 입력 처리 라이브러리
- 키보드 인코딩
- 플랫폼별 입력 차이 흡수
GPU 렌더링 라이브러리
- OpenGL
- Metal
프레임워크 연동
- GTK 위젯
- Swift 프레임워크

의도는 “거대한 단일 SDK”가 아니라, 모듈별 분리로 의존성과 코드 크기를 통제하는 것입니다.

❌ 미지원

Windows 지원 (libghostty-vt에서 가능하지만 Ghostling 미구현)
일상 사용을 위한 GUI 기능 일체

빌드 방법

사전 요구사항

CMake 3.19+
C 컴파일러
Zig 0.15.x (PATH에 등록)
Raylib (없으면 CMake FetchContent로 자동 다운로드)

기본 빌드

cmake -B build -G Ninja
cmake --build build
./build/ghostling

Release 빌드 (권장)

cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build

→ 디버그 빌드는 안전성 검사로 매우 느림 (벤치마크 부적합)

재빌드

cmake --build build   # 초기 설정 후엔 이것만

의의: “코어 vs 셸” 분리

전통적 터미널:
  GUI + 렌더러 + VT 에뮬레이션 = 한 덩어리
  → 다른 환경에서 재사용 어려움

libghostty 모델:
  VT 에뮬레이션 (코어) + GUI/렌더러 (별도)
  → 어떤 GUI든 정확한 터미널 통합 가능

활용 가능 시나리오:

IDE 내장 터미널
게임 콘솔 UI
임베디드 디바이스
WASM 기반 웹 터미널
커스텀 데스크탑 앱
원격 데스크탑 클라이언트

다른 언어 지원

libghostty-vt = C API 제공 (zero 의존성)
  ↓
대부분 언어에서 얇은 바인딩만으로 사용 가능

공식: C, Zig
커뮤니티 기대: Rust, Python, Go, JS 등

WASM 환경에서도 독립 동작 가능 → 브라우저 터미널 구현 가능

이 방향이 중요한 이유:

C ABI가 안정되면 언어 바인딩 작성 난이도가 크게 낮아짐
특정 GUI 툴킷에 종속되지 않음
Ghostty 앱과 별개로 더 큰 임베디드 터미널 생태계를 만들 수 있음

렌더러 자유도

libghostty는 렌더링에 대한 제약 없음:

렌더러	사용 가능 여부
Metal (macOS)	✅ Ghostty 본체가 사용
OpenGL	✅ Ghostty 본체가 사용
WebGPU	✅
Vulkan	✅
Raylib (2D)	✅ Ghostling 데모가 사용
DirectX	✅
Canvas 2D	✅ (WASM)
터미널 ASCII만	✅ (이론상)

→ “VT 정확성 + 렌더러 자유” = 매우 유연

비교: 다른 임베드 터미널 라이브러리

라이브러리	언어	특징
libghostty ⭐	C/Zig	Ghostty 코어 추출, 정확성·성능
vte (GNOME)	C	GNOME Terminal 코어
libtsm	C	임베디드 터미널 (Wayland 등)
xterm.js	TS	브라우저용 (VS Code, Hyper, Theia 사용)
alacritty_terminal	Rust	Alacritty 백엔드 (별도 crate)
wezterm-term	Rust	WezTerm 백엔드

→ libghostty의 차별점: C API + zero deps + Ghostty 검증

Ghostly 본체와의 관계

Ghostty (완성된 터미널 앱)
  ├── GUI (macOS Cocoa, GTK)
  ├── GPU 렌더러 (Metal, OpenGL)
  ├── 설정 시스템
  ├── 탭/분할창
  └── libghostty-vt (코어)
                ↑
                └── Ghostling이 이것만 사용

Terminal에서 다룬 Ghostty는 완성된 터미널 앱, libghostty/Ghostling은 그 코어를 외부에서 활용하는 케이스.

평가

장점

VT 정확성 (Ghostty 검증 코드)
zero deps (C API)
렌더러 자유
WASM 가능
광범위한 프로토콜 지원 (Kitty Keyboard, 다양한 마우스 포맷)
재사용 가능한 공통 코어
- 앱마다 터미널 파서를 다시 짤 필요를 줄임

한계

libghostty-vt 자체가 아직 일부 기능 미공개 (Kitty Graphics, OSC)
Ghostling은 “데모 수준”이지 일상 사용 ❌
Windows 미지원 (Ghostling)
Zig 빌드 도구 필요
API 안정화 전
- 아직 알파 단계라 외부 임베더는 변경 가능성을 감수해야 함

활용 시나리오 (가상)

아이디어 1: IDE 내장 터미널
  - VS Code 같은 에디터에 정확한 VT 에뮬레이션 통합

아이디어 2: 임베디드 디바이스
  - 라즈베리파이·산업용 단말기

아이디어 3: 원격 데스크탑
  - 정확한 SSH 터미널 미리보기

아이디어 4: 교육/디버깅
  - VT 시퀀스 학습 도구

아이디어 5: 게임 내 콘솔
  - 게임에서 정식 터미널 UI 제공

미래 전망

Ghostty는 완성형 터미널 앱
libghostty는 그 코어를 외부 생태계용 라이브러리로 확장
libghostty 채택이 늘수록:
- 외부 앱은 더 정확한 터미널 기능을 얻고
- Ghostty 본체도 더 많은 검증과 피드백을 흡수하게 됨

즉, 둘은 경쟁 관계가 아니라 상호 강화 구조에 가깝습니다.

Bigstones

Explorer