요약
Ghostty 1.4가 메모리 사용을 크게 줄이고 Kitty 그래픽 애니메이션을 지원합니다.
터미널 에뮬레이터 Ghostty가 약 7개월 만에 1.4.0을 내놓았습니다. 기여자 172명이 커밋 2,889개를 보탰고, 성능과 메모리, 보안을 주로 다듬었습니다.
왜 중요한가
- 탭을 많이 띄워 둬도 메모리 부담이 줄고, 기본 스크롤백(지나간 출력 기록) 한도는 10MB에서 50MB로 늘었습니다.
- 윈도용 GUI 계획은 접었고, 윈도 지원은 libghostty를 쓰는 다른 프로젝트에 맡기기로 했습니다.
- 리눅스판이 GTK 4.18과 libadwaita 1.7을 요구해 Ubuntu 24.04 LTS에서는 새 버전을 쓸 수 없습니다.
핵심 내용
- 쓰지 않는 스크롤백을 압축해 일반 텍스트 기준 메모리를 70~90% 줄였습니다.
- Kitty가 아닌 터미널 가운데 처음으로 Kitty 그래픽의 애니메이션과 상대 배치를 지원합니다.
- 보안 권고 10건을 고쳤고, 붙여넣기 보호 우회와 악성 Kitty 그래픽 명령 문제 등이 포함됩니다.
- 파서는 ASCII 기준 초당 128MB에서 725MB로 빨라졌고, 맥 입출력 처리량도 25~55% 늘었습니다.
- 새
ghostty +ssh명령은 원격 서버에 Ghostty용 터미널 정보(terminfo)를 깔아 주는 ssh 대체 명령입니다.
HN 반응
- Ghostty를 만든 미첼 하시모토는 libghostty가 젯브레인스 IDE 터미널에 쓰이고 Neovim 코어 교체도 논의 중이라며, 몇 달 안에 1.0을 내겠다고 밝혔습니다.
- Konsole로 충분하다는 의견에는 libghostty로 새 터미널을 만드는 KDE 개발자가 Konsole이 낡은 툴킷에 묶여 있다고 답했습니다.
이 글은 Ghostty GUI 릴리스 노트지만, Ghostty 1.3 이후 libghostty에서 이룬 진전을 잠깐 짚고 넘어가고 싶습니다.
다시 설명드리면, libghostty는 핵심 터미널 에뮬레이션과 렌더 상태 등을 제공하는, 이식성이 높고 임베드할 수 있는 라이브러리입니다. 저는 언제나 무료이고 품질 좋고 가벼우며 재사용할 수 있는 터미널 에뮬레이션 코어가 어떤 GUI 애플리케이션 하나보다 개발자 세계에 더 큰 도움이 된다고 생각했습니다. 그리고 실제로 그렇게 되고 있습니다!
이것이 Ghostty 프로젝트의 진짜 목적이었고, 지금도 그렇습니다(Ghostty에 관한 첫 발표에서도 이렇게 말했습니다!). Ghostty GUI는 libghostty를 위한 그럴싸한 기술 데모일 뿐이라고 농담처럼 여러 번 말하기도 했습니다. 하지만 그건 공정하지 않은 말입니다. GUI도 훌륭하고, 거기에 매달리는 정말 재능 있는 분들이 있으니까요.
프로젝트를 시작한 뒤로 Ghostty는 늘 "왜 지금 터미널 에뮬레이터를 새로 만드는지 이해가 안 된다"는 말을 들었습니다. 그 답이 바로 libghostty입니다. 정말 독보적이고, 뭔가 특별한 일을 가능하게 하고 있습니다(제 생각엔요!).
지난 6개월 동안 libghostty에서 이룬 주요 성과입니다(아래 내용은 하나도 6개월 전에는 사실이 아니었습니다).
libghostty는 Ghostty 핵심 기능의 거의 100%를 다룹니다(크기와 안전성을 위해 컴파일 플래그로 이 기능들을 뺄 수도 있습니다): https://libghostty.tip.ghostty.org/
libghostty는 이제 Apple(macOS, iOS, visionOS), Windows(MSVC와 GNU), Linux, FreeBSD, Android, WebAssembly, 그리고 freestanding(OS 없이 하드웨어에서 직접 실행)용으로 빌드되며 CI에서 테스트됩니다.
libghostty에는 C, Zig, Go, Swift, Python, Rust, .NET 등 인기 있는 프로그래밍 언어 거의 전부의 바인딩이 있습니다.
위와 같은 이식성을 위해 libghostty의 메모리 요구량을 크게 줄였습니다. 아직 할 일이 남았지만, 빈 터미널 하나가 쓰는 메모리가 이미 90% 줄었습니다. 대규모로는 코어 4개와 RAM 8GB인 리눅스 서버에서 입출력이 실제로 오가는 터미널 1만 개를 돌려 입증했습니다.
libghostty는 모든 JetBrains IDE의 터미널을 구동하며, 활성 사용자가 1,250만 명이 넘습니다. https://blog.jetbrains.com/platform/2026/10/jetbrains-terminal-now-uses-ghostty/
libghostty는 Herdr, cmux 등 벤처 투자를 받은 "에이전틱" 터미널과 에디터 열풍 뒤에서 가장 많이 쓰이는 코어입니다.
libghostty를 Neovim의 터미널 코어로 대체하는 안이 논의 중이며 구두로 수락된 상태입니다: https://github.com/neovim/neovim/pull/39773 (아직 할 일이 남아 있습니다)
libghostty는 이맥스용으로 아주 인기 있고 강력한 터미널 에뮬레이터(Ghostel)를 구동합니다: https://github.com/dakra/ghostel
Antithesis는 libghostty의 속도를 이용해 인기 터미널 프로그램을 퍼징하고 있고, 이 덕분에 tmux, btop, 셸, 다른 터미널 에뮬레이터 같은 프로그램의 업스트림에 수백 건의 버그 수정이 직접 전달됐습니다. :)
그 밖에도 많습니다: https://github.com/Uzaaft/awesome-libghostty
libghostty는 "밀물이 들어오면 모든 배가 떠오른다"는 말을 정말로 실현하고 있습니다. 더 많이 쓰일수록 Ghostty 자체도 더 빠르고 안정적으로 발전하고, 다른 모든 프로젝트도 마찬가지가 됩니다. 또한 현대적인 터미널 에뮬레이션을 가장 넓은 범위에 전달하는 수단이기도 합니다.
앞으로 몇 달 안에 libghostty 1.0을 태그하고, 그 시점에 ABI 안정성을 선언할 계획입니다!
블로그 글마다 "이런 말 하기 지치지만, 이 글은 LLM이 아니라 제가 썼습니다"라고 여러 번 쓰셨잖아요. 그래서 말씀드리는데, 저는 한 글자도 빼놓지 않고 읽었어요. :D 별 내용 없는 댓글이지만 꼭 말씀드리고 싶었어요.
사람이 쓴 글이면 긴 글도 얼마나 쉽게 읽히는지, 우리는 거의 잊고 있었죠. 읽기 좋았어요(정성이 들어갔다는 게 느껴져서이기도 하고요).
요즘 AI 이전에 나온 약학 교과서를 읽고 있는데, 여러 개정판을 거치며 사람이 다듬어 온 글을 따라가는 게 이렇게 편한가 싶었습니다. AI의 도움을 받은 평범한 글보다 교과서가 훨씬 읽기 쉽다는 걸 깨달았을 때, 우리가 정말 끝장났다는 걸 알았습니다(적어도 AI와 글쓰기라는 이번 장에서는요).
AI 쓰레기 대재앙 시대에 질이 나빠진 약학 교과서를 예로 들어 주실 수 있나요? 특히 심한 대목을 공유해 주시면 인터넷 보너스 포인트를 드리겠습니다!
AI가 쓴 약학 교과서를 읽었다고 한 게 아니에요. AI가 쓴 글보다 읽기 쉬운 글의 비교 대상으로 약학 교과서(아마 읽기 무거운 책이겠죠)를 들었을 뿐이에요.
약학 교과서 읽는다고 다들 알아줬으면 했던 거죠, 뻔하잖아요. 아마 허세일 거예요.
네, 저도 약학 얘기는 어쩌면 과시용일 수 있다고 생각했어요. 그래도 여기 HN 관례대로 글쓴이에게 의심의 이익을 주려고요.
맞습니다. 저는 앞으로도 제 글을 계속 손으로 직접 쓸 겁니다.
제 영어가 완전히 관용적이지 않아도, 문장 구성이 전부 "교과서대로" 정확하지 않아도 상관없습니다. 저는 글을 쓰고 싶고, 제 글을 읽는 사람이 이 글이 저만의 생각과 퇴고에서 나왔다는 걸 알아줬으면 합니다.
"사람이 쓴 글이면 긴 글도 얼마나 쉽게 읽히는지, 우리는 거의 잊고 있었죠."
음, 그건 쓴 사람에 따라 다르다고 생각해요.
지칠 때가 내가 살아 있다는 걸 아는 때죠.
와, 멋진 말이네요.
제가 아는 말도 하나 있어요.
"슬플 때면 이렇게 되새긴다. 내가 슬픔을 느끼는 건 기쁨을 누리고 느낄 자격을 얻기 위해서라고."
제 말은 아니고, 서양에서 루미로 알려진 마울라위의 시구를 바꿔 쓴 거예요.
여담인데, 예전에 어떤 사람이 꽤 깊이 있는 말을 인용하면서 출처가 루미라고 했는데, "음, 루미가 할 법한 말이 아닌데, 내가 교양이 부족한 건가" 싶었어요.
알고 보니 「케이팝 데몬 헌터스」에 나오는 루미의 말을 인용한 거였고, 저는 정말 교양이 부족했던 거죠.
하하. 그럼 저도 케이팝 루미는 교양이 없는 셈 치세요... 댓글 보기 전까지 몰랐어요.
제가 말한 건 جلال الدین محمد بلخی رومی, 그러니까 수피 성자예요.
저는 KDE 프로젝트 소속이고, 언젠가 우리 유지보수 부담을 덜어 주길 바라며 libghostty-vt 기반의 새 프런트엔드를 만들고 있습니다.
꽤 매끄러운 경험이었고, 이 라이브러리에 계속 큰 기대를 걸고 있습니다. 표준을 성공적으로 세우고 계신 것 같습니다. 1.4.0 출시를 진심으로 축하드립니다!
오오오, 이게 Konsole이나 konsolepart에 들어가게 되나요? 아니면 새 앱으로 나오나요?
새 앱으로 나올 겁니다. 다만 konsolepart를 그대로 대체할 수 있게 해 주고, Qt Quick 기반 앱에 임베드할 수 있는 QML 모듈 API도 갖추고 있어서 Konsole이 지금 비워 둔 빈자리를 메워 줍니다. 기본 터미널로 Konsole을 대체할 수 있을 만큼 준비되려면 시간이 좀 걸릴 거예요. 이런 논의는 원래 시간이 걸리고 커뮤니티가 함께 거치는 과정이기도 하고요.
Konsole이 훌륭하긴 하지만(효율적이고 기능도 풍부하죠) 나이가 느껴지고, 위젯이 좀 비대하고 설정 체계도 다루기 불편합니다. 그래서 저는 몇 년 전 neovim으로 넘어갈 때 Kitty로 갈아탔고 그 뒤로 돌아본 적이 없습니다.
KDE 프로젝트가 터미널 애플리케이션을 현대에 맞게 다시 생각해 볼 좋은 기회로 보입니다. 텍스트 기반 설정이 생기면 정말 좋겠지만, KDE Frameworks 등에 어떻게 맞출지는 잘 모르겠습니다.
konsolerc가 텍스트 기반이라는 건 알고 계시죠?
작업해 주셔서 감사합니다. 예전에 neovim 코어 작업을 하면서 libvterm과 터미널 에뮬레이션 전반의 예외 상황을 점점 더 많이 다루게 됐을 때, 저도 "이런 건 표준이 될 만한 라이브러리가 하나 있어야 해"라고 똑같이 생각했습니다. 하지만 그건 6, 7년 전(2019년) 일이고, 그 사이 엔지니어링과 무관한 일이 많이 터져서 의욕이 꺾여 추진하지 못했습니다.
가끔 TUI 문제에 부딪힐 때마다 "이제 정말 내가 만들어 볼까" 싶었습니다. 특히 tmux를 통째로 대체하고 싶을 때 그랬죠. 하지만 터미널에는 짜증 나는 문제가 길게 꼬리를 문다는 걸 경험으로 알고 있었고, 보기보다 시간이 훨씬 많이 드는 일이라 결국 또 손대지 않았습니다.
모든 배를 떠오르게 하는 좋은 작업에 감사드립니다 :)
저는 가능하면 터미널 에뮬레이션에서 GUI로 옮겨 가는 편이고(arcan에서 영감을 받은 커스텀 원격 프로토콜을 쓰고 있어요), 그래도 TUI는 한동안 계속 쓸모가 있을 겁니다. 마침 제 supervisor에서 GUI가 없는 프로그램용 대체 TUI/pty 연결에 쓸 좋은 터미널 에뮬레이션 라이브러리가 필요했는데, libghostty를 써 볼게요.
Ghostty를 써 봤는데 아주 좋지만, Kitty에서 Ghostty로 못 넘어가게 붙잡는 기능이 Kitty의 hints 모드1 하나입니다. Ghosstty-org/ghostty Discussions2에도 이 기능이나 비슷한 기능에 관한 논의가 꽤 있고, 저는 그걸 지켜보고 있습니다. 대부분 ghostty-org/ghostty/discussions/23943를 참조하고 있고요. 이제 Ghostty가 Kitty 그래픽 지원을 마쳤으니 다음은 hints일지도 모르겠네요.
포크를 만들면 Claude가 아마 한 번에 만들어 줄 겁니다. Mitchell은 바이브 코딩한 PR은 받지 않겠지만, 개인용이라면 상관없죠.
저는 Ghostty에 Tmux 컨트롤 모드(꽤 방대한 기능입니다) https://github.com/tmux/tmux/wiki/Control-Mode 를 추가했고, 그 버전을 매일 씁니다: https://github.com/eliasfloreteng/ghostty-tmux
hints 모드를 어떻게 지금까지 몰랐죠? 대단하네요. 알려 주셔서 감사합니다. 이제 새 단축키를 외우러 가야겠어요.
이 단축키는 제 터미널 에뮬레이터에 꼭 훔쳐 와야겠어요! 비슷한 기능을 원했는데 어떤 단축키를 써야 할지 몰랐거든요.
궁금해서 여쭤보는데, Kitty가 잘 맞으시면 Ghostty로 바꿀 이유가 뭔가요? 저는 Kitty를 써 본 적이 없는데, 꽤 고급 기능이 많아 보여서 이제 써 보고 싶어졌어요.
저는 윗분은 아니지만 Kitty를 쓰다가 Ghostty로 넘어왔습니다. Kitty에는 훌륭한 기능이 있었고(예: 현재 터미널 내용을 텍스트 에디터로 불러오는 단축키), 논란의 여지가 있는 점(예: Kitty의 스크립트 언어가 Python이라 탭을 취향대로 설정하려면 Python을 써야 했습니다)도 있었고, 거슬리는 점(Kitty의 Debian 패키지에서 여러 번 크래시가 났는데, 나중에는 안정되긴 했습니다)도 있었습니다.
저한테 가장 큰 고통은 폰트 렌더링이었습니다. 어떤 화면에서든 통하는 이식 가능한 설정을 찾지 못했어요. 더 심한 건, 어떤 픽셀 밀도에서는 무슨 설정을 해도 결과가 끔찍했다는 겁니다. 글자를 읽을 수 있게 해 주는 레거시 모드가 있었던 것 같기도 한데, 그 모드는 그 모드대로 문제가 있었습니다.
저는 Ghostty, Kitty, Wezterm 같은 것들이 왜 필요한지 아직도 모르겠어요...
제 컴퓨터에서는 Konsole이 그 어떤 것보다 훨씬 빠르고, 현대 터미널 에뮬레이터라면 기대할 만한 기능도 다 갖췄거든요.
리눅스로 넘어와 iTerm2를 못 쓰게 된 뒤로 아쉬운 기능은 tmux -CC 통합 하나뿐인데, 저것들 중에 지원하는 게 하나도 없네요.
오해는 마세요. 깎아내리려는 게 아니에요. 저것들이 무엇을 가져다주는지 정말 이해하고 싶어요.
KDE 쪽 사람입니다.
Konsole은 훌륭하고 아주 성숙한 터미널 에뮬레이터이지만, 나이를 드러내는 실제 공백이 있습니다.
KDE 소프트웨어 대부분이 기반으로 삼는 Qt 툴킷은 어느 시점에 Qt Quick이라는, 툴킷 안의 차세대 툴킷을 도입했고, 우리 신규 앱 대부분이 이걸로 만들어집니다. 그런데 라이브러리 형태의 Konsole은 구세대 툴킷을 쓰는 앱에만 임베드할 수 있습니다. 이게 몇몇 작업에는 진짜 걸림돌입니다.
구세대 툴킷은 보통 렌더링에 Vulkan이나 OpenGL을 쓰지 않아서(새 툴킷은 둘 다 지원합니다), Konsole의 터미널 렌더러도 쓰지 않습니다. 실사용 성능은 충분히 괜찮다고 할 수 있지만, 성능과 배터리 수명 면에서 얻을 수 있는 이득을 꽤 놓치고 있습니다.
libghostty는 Kitty 프로토콜 같은 최신 기능 지원 범위도 다소 넓습니다. 물론 sixel 같은 오래된 기능 지원은 Konsole이 확실히 앞서지만요.
접근성 지원이 있어야 할 수준에 못 미치는 것처럼, 기술 자체에 내재한 문제는 아닌 다른 단점도 있습니다.
그리고 대부분의 배포판에서 기본 UI는 괜찮지만, (이상하게 많은) 설정 대화상자에는 거미줄과 스페이스바 히팅(spacebar heating)이 숨어 있습니다. 지금 기준으로는 우리 HIG와 비교해도 좀 낡았고요.
그러니까 이런 프로젝트들도 충분히 존재 이유가 있고, 특히 좋은 것을 독차지하지 않고 좋은 라이브러리로 내놓는다면 더욱 그렇습니다.
Konsole을 만들어 주셔서 감사합니다. 저는 매일 쓰는데 KDE 6.8에서 잘 돌아갑니다. 스크롤백을 무제한으로 쓰고 있어요. 몇 주 지나면 RAM을 15GB씩 쓰는 대신 디스크에 덤프해 뒀다가 필요할 때 불러오는 무제한 스크롤백이 있으면 좋겠습니다. 그리고 C-S-F를 눌러도 멈추지 않으면 좋겠고요... 가끔 tmux와 에이전트랑 같이 씁니다.
제가 알기로는 Konsole 설정에 그 옵션이 있지 않나요?