▲

libghostty가 온다

 (mitchellh.com)
3P by GN⁺ 3일전 | ★ favorite | 댓글 3개
  • libghostty는 어떤 애플리케이션에서도 사용 가능한 임베디드 터미널 에뮬레이터 라이브러리로 개발 진행 중임
  • 첫 번째 구성 요소인 libghostty-vt는 파싱과 상태 유지에 최적화된, 의존성 없는 API임
  • 터미널 에뮬레이션의 복잡성과 반복 구현 문제를 해결하기 위해 등장, 크로스 플랫폼 및 높은 이식성 추구임
  • 향후 키보드 입력 처리, GPU 렌더링, 다양한 프레임워크 연동 등 추가 라이브러리 확장 계획임
  • 현재 Zig API는 테스트 가능, C API도 곧 공개 예정으로 사용자 피드백을 적극 청취함

소개 및 libghostty 개발 배경

  • libghostty는 모든 애플리케이션에서 최신의 빠르고 완벽한 터미널 에뮬레이터 기능을 임베드할 수 있도록 설계된 라이브러리 프로젝트임
  • 현재 수많은 프로그램들이 고유한 방식의 터미널 에뮬레이터를 직접 구현하거나, 매우 제한적인 형태의 터미널 기능만을 별도로 제작하는 실정임
  • 이렇게 개별적으로 개발되는 터미널 에뮬레이션 구현체들은 ad-hoc, 1회성 코드베이스가 많으며 예외 처리와 복잡성을 충분히 다루지 못해 불완전성, 버그, 성능 저하 문제를 자주 겪음
  • 대부분 개발자의 입장에서 터미널 에뮬레이션 구현은 핵심 비즈니스가 아니므로, 공통적이고 재사용성 높은 솔루션에 대한 요구가 존재함
  • libghostty는 최소 의존성으로 설계된 크로스 플랫폼 C API를 제공하며, 이를 통해 다양한 애플리케이션에서 안정적이고 빠른 터미널 에뮬레이션 기능을 활용 가능함

libghostty-vt: 첫 번째 라이브러리의 시작

  • libghostty-vt는 의존성이 전혀 없는 (libc조차 불필요) 라이브러리로, 터미널 시퀀스 파싱과 커서 위치, 스타일, 줄 바꿈 등 터미널 상태 유지 기능의 API를 제공함
  • 이러한 터미널 시퀀스 파싱은 터미널 에뮬레이터의 핵심 기능일 뿐만 아니라, 단순한 스타일 출력이 요구되는 사이트(GitHub Actions, Vercel 빌드 로그 등)에도 반드시 필요한 역할임
  • 터미널 프로토콜 파싱은 표면적으로 단순해보이지만 구현 난이도는 매우 높으며, 실제로 Jediterm 등 여러 구현체가 일부 시퀀스 처리에 문제를 보이는 사례가 있음
  • 일부 개발자는 ANSI 시퀀스만 간단히 파싱하는 방식에 머무르나, 복잡한 스타일 처리(다양한 RGB 표기법 등)와 완전한 호환성 요구로 인해 정교한 파서가 필수임
  • libghostty-vt는 Ghostty의 검증된 코어에서 추출되어, SIMD 최적화 파싱, 뛰어난 Unicode 지원, 고도화된 메모리 구조, 광범위한 프로토콜 호환성(Kitty Graphics, Tmux Control Mode 등) 을 갖춤
  • 단일 파일의 제로-의존성 C API로 제공되어 모든 범용 언어 및 환경에 쉽게 임베드할 수 있고, macOS, Linux(x86_64, aarch64)를 우선 지원하며 점차 Windows, 임베디드, WASM 등으로 확장할 계획임
  • Ghostty GUI보다 더 포괄적인 대상 지원이 가능함

장기적으로 확장될 libghostty

  • libghostty-vt 이후로는 입력 처리(키보드 인코딩 등), GPU 렌더링(OpenGL, Metal) , GTK 위젯 및 Swift 프레임워크 등 추가 기능을 제공하는 라이브러리군이 연이어 출시될 예정임
  • 이러한 기능적 확장들은 모듈별로 구성되어, 의존성 및 코드 사이즈, 유지보수 복잡성을 최소화함

libghostty-vt 개발 현황

  • Zig 모듈로 libghostty-vt를 외부에 노출하는 PR(풀 리퀘스트) 가 최근 머지되었으며, Zig 개발자는 바로 사용 가능함
  • C API는 정의 작업이 진행 중이며, 곧 테스트용으로 제공될 예정임(코어 로직은 이미 수년간 Ghostty에서 사용된 검증된 소스임)
  • Ghostty macOS 앱에서도 내부용 C API를 사용하지만, 현재의 내부용 헤더는 외부 공개 및 일반 사용에는 적합하지 않으므로 완전히 새로운 C API를 설계 중임
  • libghostty는 Ghostty 애플리케이션과 별도로 버전 관리를 하며, 현재 알파 단계로 빠른 도입과 언어 바인딩 개발자 참여를 기대함
  • 6개월 내에 태그가 부여된 최초 릴리즈를 목표로 하고 있음

사용자 피드백 요청

  • 현재 API 설계 단계이므로, 실제 사용자의 의견과 피드백이 매우 중요한 시점임
  • Ghostty 외에도 다양한 커뮤니티 구성원이 libghostty 기반 프로젝트를 개발 중이며, 더 많은 사용자가 참여하길 희망함
  • 프로젝트 활용 아이디어나 요구가 있다면 Ghostty Discord 또는 이메일을 통해 개발자와 직접 소통 가능함
  • libghostty는 현재 알파 버전으로, API는 아직 안정적이지 않으나, 코어 로직은 실전에서 검증된 높은 안정성을 보장함

미래 전망 및 영향

  • Ghostty 애플리케이션의 안정성 달성을 바탕으로, 이제 libghostty라는 더 큰 목표를 향해 나아갈 수 있게 됨
  • libghostty가 다양한 애플리케이션에서 널리 사용된다면, Ghostty 단일 앱 이상으로 더 큰 생태계 파급력과 영향 마련 가능함
  • libghostty의 활용이 늘어나면 Ghostty 본체 역시 더욱 풍부한 기능과 안정성을 확보할 수 있음
  • Ghostty 및 libghostty는 상호 보완 형태로 발전하며, 개발자와 사용자 모두에게 이익을 제공할 전망임
▲
yshrust 3일전  [-]

1.0 부터 쓰고 있는데 스크롤과 검색이 없는거 외엔 만족합니다 ㅎㅎ iterm 쓰고 있었는데 정착했네요.

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 이 사람은 회사 창업, 상장, 수십억 매각까지 모두 해낸 뒤에도 다시 코딩 세계로 돌아가는 모습이 정말 전설 같음

    • Hashimoto는 정말 천재임을 넘어, 시스템과 인터페이스를 극도로 모듈화하고 얽힘을 최소화하는 비범한 추상화 능력이 가장 감탄스럽다고 생각함 Rich Hickey가 주장한 Simple Made Easy 철학을 그대로 실천하는 사람처럼 느껴짐 그의 소프트웨어는 올바르게 동작할 수밖에 없는 구조로 설계된 느낌임 그리고 Ghostty를 처음 써봤는데, iTerm2랑 Zsh/Powerlevel10k 테마에서 항상 약간의 렌더링 딜레이가 있었는데 ghostty에선 거의 즉각적으로 반응됨

    • 진짜 부럽기도 하고, 동시에 꿈과 같은 삶 같음 부를 얻고 나서 오직 프로젝트 그 자체를 위해서 창작활동을 이어가는 것, 돈을 위해서 품질에서 양보하지 않아도 되는 상황임 Knuth의 오래된 명언이 생각남

      수천 명의 컴퓨터 과학자들이 자기 하고 싶은 걸 자유롭게 하게 하는 게 학문의 진보를 이끈다

      확실히 사랑을 담아 만든 프로젝트들이 점점 더 큰 성공을 거두는 중임 돈에 집착하지 않으면 더 좋은 결과를 만들어낼 수 있음을 보여주고 있음 한편으론 이런 삶을 누리려면 어느 정도의 자본이 선행되어야 한다는 점에서 우리 사회 구조, 경제 전반을 되돌아보게 됨 Knuth 말처럼 시간만 좀 더 주어진다면, 모두가 더 좋은 결과를 만들 수 있을텐데 늘 급하게 하다 보면 많은 걸 희생하게 됨 그리고 그의 또 다른 명언처럼

      모든 걸 최적화하려다 보면 결코 행복할 수 없다

      이쯤에서 질문을 하게 됨, 우리는 정말 문제를 잘 해결하고 삶을 쉽게 만드는 사람들에게 합당한 보상을 주고 있는지 아니면 무의미한 게임 점수만 올리고 있는 건지 전설을 많이 만드는 방법은 뭘까? 이사회에 품질의 가치를 설명해야만 하는 부담 없이, Mitchell처럼 열정을 따라 살아갈 수 있는 사회는 어떻게 만들 수 있을지 고민임

    • 실제로 본 적 있음, 정말 푸근하고 좋은 사람이었음 Hashicorp 창업 전에 Kiip에 있을 때 콘퍼런스에서 점심을 함께했는데, Mitchell은 진짜 해커였음 컴퓨팅에 관한 모든 걸 진심으로 사랑한다는 게 느껴졌음 특히 분산 시스템 콘퍼런스에서 아주 깊게 몰두하더라 무슨 일을 해도 반드시 성공할 거라 확신이 들었음 Ghostty를 발견하고 쓴 이후로 만족하면서 계속 사용 중임

    • 그리고 이 사람은 tty 소프트웨어 개발에까지 몰두하고 있음, Unix 기술 스택 중에서도 정말 덕심 가득한 영역임

    • ghostty를 매일 쓰고 있었는데 만든 사람이 Mitchell Hashimoto인 줄 지금 알게 됨, 정말 멋진 경험임

  • Ghostty가 진짜 멋짐, 진정한 오미플랫폼(omni-platform) 터미널 에뮬레이터가 모바일까지 확장될 수 있다는 게 기대됨 Ghostty가 Zig로 만들어졌다는 것도 신기함 내가 평소 쓰는 첫 Zig 기반 프로그램임, 저장소 구조가 Golang 스타일이랑 똑같아서 재미있게 느껴짐 https://github.com/ghostty-org/ghostty

    • (Go 레이아웃 같지 않음) 오히려 그게 좋은 점임, go의 pkg/ src/ 등 디렉터리 구조는 그다지 좋은 구조가 아님

  • Ghostty를 정말 좋아하고 싶은데 아쉬운 점들이 있음

    • ⌘F로 찾기 지원이 아직 없음
    • 이전 출력이나 특정 문자열을 오직 키보드로만 선택/복사하는 방법이 없음
    • ⌘. 키로 CTRL-C 전송이 안 됨 (맥 사용자라면 기대하는 기능임)
    • 폰트 렌더링이 아직 Terminal.app 만큼 매끄럽지 않음, font-thicken-strength로 조절해봤지만 100% 같진 않음 Metal 렌더 특성 때문에 불가능하거나 매우 어려운 것 같음, 하루 종일 텍스트만 보는 입장에서는 굉장히 중요한 부분임
    • ⌘.을 누르면 CTRL-C가 전송되는 설정은 가능함 
      keybind = "cmd+.=text:\x03"
      관련 논의 : https://news.ycombinator.com/item?id=42889411
    • 곧 지원될 예정임 : https://ghostty.org/docs/install/release-notes/1-2-0#roadmap
    • 스크롤백 검색은 1.3 버전에 들어갈 예정이지만 약 6개월은 더 걸릴 것 같음 Ghostty도 최근 빠르게 발전 중이니 1.2 릴리즈 노트도 참고해볼 만함
    • 포인트가 널뛰는 걸 보니 내가 쓴 글이 오해를 낳은 것 같음, 사실 크로스 플랫폼에 각 벤더별로 네이티브 GUI를 구현하는 개념은 너무 멋짐 실제로 이 프로젝트가 존재해서 굉장히 기쁘게 생각함, 다만 개인적으로 아직 완벽하진 않은 것 같음, 그래도 기대하며 지켜보고 있음
    • 두 번째 지적(키보드로 이전 출력 선택)이 WezTerm을 계속 쓰는 주된 이유임

  • Mitchell이 개발자 경험에 쏟는 열정과 디테일은 정말 대단함 2011년 산타모니카에서 처음 Vagrant를 썼을 때의 감동이 생생함 iTerm2를 절대 대체할 생각이 없었는데 Ghostty를 접하고 바로 반해버렸음

  • ghostty를 요즘 매일 사용 중임 최근에 갈아탔음 macOS에서 caps lock을 cmd로 매핑해두니 cmd+c도 잘 작동함 기본 설정이 똑똑하게 잘 돼 있고, 커스터마이즈도 쉽지 않은 것 빼곤 다 만족스러움 Gruvbox light 테마도 보기 참 좋음 Zig로 작성된 거 자체도 너무 멋져서, Zig가 실사용에 충분히 준비된 언어인지 궁금할 때 ghostty가 그 답이 될 것임 다시 다른 단말기로 되돌아갈 일은 없어 보임, 진짜로 만족스러운 경험임 참고: ghostty에 aerospace까지 조합하면 맥에서 키보드만으로 거의 완벽한 환경이 완성됨

    • 왜 ghostty를 써야 하는지 알려줄 수 있는지 궁금함 (Terminal.app을 메인으로 쓰는 입장에서)
    • Clickhouse, Bun도 엄청난 프로젝트임

  • 내 에어맥에서 ghostty를 사용 중인데, 형이 코딩하다가 물려준 맥임 ghostty가 정말 좋아서 진심으로 고마움 작은 부분일지 몰라도 libc 의존성이 없는 게 왠지 모르게 꽤 소중하다고 느껴짐

  • visidata의 빈도 분석 히스토그램이 제대로 렌더링되지 않고, 일부는 네모로 잘 나오지만 나머지는 다이아몬드 물음표로 떴음, 이 문제 때문에 아직 iTerm을 못 떠나고 있음 어떤 키워드로 검색해야 할지도 잘 모르겠어서 해결이 어려웠음

    • 메인 폰트와 백업 폰트에 해당 코드포인트가 빠진 것일 수도 있음 ghostty 사용자라면 iTerm2에서 어떤 폰트로 해당 글리프가 보이는지 체크해보고, ghostty에서 맞는 설정이 있는지 찾아보길 권장함

  • Ghostty의 텍스트 리플로우(특히 스크롤백 포함)가 Neovim 기반 터미널에서도 해결될 수 있길 바라며 계속 주목하고 있음 Ghostty가 터미널 환경에 새로운 혁신을 불어넣는 게 너무 반가움 https://github.com/neovim/neovim/issues/33155

    • 본인이 neovim 터미널 파워유저인지 궁금함 예전에 tmux가 neovim을 구동하던 흐름에서 neovim이 직접 터미널을 관리하게 하고 싶어서 워크플로우를 바꿔보려 했었음 파일을 한 버퍼에만 열 수 있으니 편할 것 같았음 파일을 어느 pane에서 열다 보면 이미 다른 neovim 인스턴스에서 열려있던 경우가 많았기에 시도했던 변화였음 테스트 중에 libghostty로 바꿔서 해결될 만한 리플로우 문제는 특별히 느끼진 못했고 오히려 패러다임 적응이 더 어려웠음 neovim 내장 터미널에 푹 빠져 있는 사람으로서, 그리고 libghostty 적용이 어떤 점을 개선할 수 있을지 경험담을 듣고 싶음

  • ghostty를 정말 쓰고 싶은데 cmd+f 지원이 없어 아직 시도하지 못하는 중임, 하지만 이 프로젝트의 발전이 매우 기대됨

    • 로드맵에 포함돼 있음
      https://ghostty.org/docs/install/release-notes/1-2-0#roadmap
    • cmd+shift+f 같은 키를 통해 전체 버퍼를 기본 텍스트 에디터로 열어 검색하는 방식이 가능함, 많은 사람들이 이 방법으로 버틸 수 있었고 본인도 마찬가지였음, 기본 내장 스크롤백 검색이 들어올 때까지 충분히 실용적인 대안임
    • 왜 이 기능이 초반에 추가되지 않았는지 궁금함, 터미널에서 히스토리 검색이 필수인데 무슨 복잡한 이유라도 있었는지? 사실 Mitchell 본인도 2년 전에 직접 이슈를 열었었음
      https://github.com/ghostty-org/ghostty/issues/189
    • 많은 사람들이 cmd+f 같은 히스토리 검색이 없어서 불만을 토로하지만, 본인은 가능함에도 한 번도 써본 적이 없음 시도하는 워크플로우가 어떤 것인지 설명해줄 수 있다면 좋겠음, 혹시 내가 뭔가 큰 걸 놓치고 있는지 궁금함
    • tmux를 안에 띄우고 cmd+f를 copy-mode + /로 매핑하는 방법도 있음
답변달기