Ghostty GTK 애플리케이션을 다시 작성함

8 hours ago 2

서론

Ghostty는 macOS, Linux, FreeBSD를 지원하는 크로스플랫폼 터미널 에뮬레이터임
각 플랫폼별로 네이티브 GUI 프레임워크를 사용하여 차별점을 가짐
- macOS: Swift 및 Xcode 기반 대용량 어플리케이션
- Linux 및 BSD: GTK 기반 애플리케이션, X11/Wayland 등 직접 통합
- 공통 코어는 Zig로 작성되며 C ABI 호환 API를 제공함
기존 구조에서 GTK 애플리케이션을 다시 작성한 이유는 원문 PR 참고 가능
본 글에서는 GObject 타입 시스템과의 연동 그리고 Valgrind로 검증한 메모리 이슈에 중점적으로 다룸

GTK를 사용하는 경우 기본적으로 GObject 타입 시스템과 인터페이스해야 하는 구조임
과거에는 GObject 시스템을 회피하며 레퍼런스 카운팅이 없는 Zig 객체와 GObject 객체의 생명주기를 직접 맞추려 했으나, 반복적으로 메모리 해제가 제대로 되지 않는 문제 발생
- 예: Zig 측 메모리는 해제됐지만 GTK 측 메모리는 아직 살아있거나 반대 상황 반복
이런 접근은 올바름 문제뿐만 아니라 GTK 고유 기능(이벤트 신호, 속성 바인딩, 액션) 사용이 어렵게 만듦
구체적 예로 설정(config) 구조체의 리로드 시 연결된 모든 GUI 요소가 일관되게 업데이트되어야 했는데, 이 과정이 복잡하고 오류가 잦았음
- 현재는 Zig Config 구조체를 감싸는 레퍼런스 카운팅된 GhosttyConfig GObject로 관리, 속성 변경 통지로 애플리케이션 전체에 자연스럽게 변화가 전파됨
커스텀 GObject 위젯 생성도 쉬워져 Blueprint 등의 현대적 GTK UI 기술 사용이 가능
- 최근에는 Blueprint 도입으로 GTK 타이틀바 탭, 애니메이션 벨 테두리 등 새로운 기능 도입이 쉬워짐

개발 과정 전체에서 Valgrind로 메모리 누수, 정의되지 않은 메모리 접근 등 문제를 체계적으로 검증
GTK 애플리케이션의 Valgrind 검사는 까다롭고, 대용량의 suppression 파일 필요 (80%는 GTK 자체, 나머지는 3rd party 라이브러리 및 GPU 드라이버)
반복적 검사로 몇몇 경우에만 발생하는 복잡한 메모리 버그를 사전에 발견 가능
- 예: GObject WeakRef를 제대로 초기화하지 않으면 대상 객체가 나중에 해제될 때 정의되지 않은 메모리 접근이 발생, Valgrind로 사전 포착
실제 경험상, Zig 코드베이스 내부 이슈는 총 2건(누수 1, 정의되지 않은 접근 1) 에 불과했으며, 그마저도 3rd party C API 연동 과정에서 발생
- Zig의 디버그용 할당자 및 Valgrind 통합 기능도 실효성 입증
기타 발견된 메모리 이슈는 대부분 C API 경계, GObject 시스템의 복잡한 생명주기 관리에서 비롯
- 결론적으로 복잡한 라이브러리의 C API를 안전하게 사용하려면 Valgrind와 같은 도구 필요
Zig의 메모리 안전성 보조 기능은 이론적 논의뿐 아니라 실증적 프로젝트 경험으로도 효과를 확인

이번이 Ghostty GUI 부분을 다섯 번째로 처음부터 다시 만든 경험
- GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK(절차적), Linux GTK+GObject 타입 시스템 순
반복적 재작성 과정에서 매번 새로운 교훈과 기술적 성장을 얻음
- 이번 경험을 macOS 프로젝트에도 일부 적용할 계획
Ghostty GTK 시스템 유지보수팀의 적극적인 협업도 강조
새로 다시 작성된 Ghostty GTK 애플리케이션이 이제 소스 빌드의 디폴트가 되었으며, 1.2 정식 릴리스에 적용될 예정임