# 2025년 터미널 에뮬레이터 현황: 방랑하는 챔피언들 > Clean Markdown view of GeekNews topic #24130. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24130](https://news.hada.io/topic?id=24130) - GeekNews Markdown: [https://news.hada.io/topic/24130.md](https://news.hada.io/topic/24130.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-11-04T10:03:33+09:00 - Updated: 2025-11-04T10:03:33+09:00 - Original source: [jeffquast.com](https://www.jeffquast.com/post/state-of-terminal-emulation-2025/) - Points: 14 - Comments: 15 ## Summary 터미널의 본질적 한계였던 **유니코드 문자 폭 문제**를 정면으로 다룬 2025년 평가에서, 새로 등장한 **Zig 기반 Ghostty**가 정확도 100점으로 1위를 차지했습니다. **Kitty** 역시 자체 **텍스트 셀 분할 알고리즘**을 공개하며 표준화 논의에 불을 붙였고, 두 프로젝트 모두 **Variation Selector 15**까지 완벽히 처리해 사실상 차세대 터미널의 기준을 제시합니다. Ghostty가 Windows를 지원안하는게 참 아쉽네요. 물론 지원관련해서 작업중이라는 깃헙이슈는 2023년부터 있긴 한데, 아직 구현은 요원합니다. ## Topic Body - **Unicode 지원 정확도**와 **성능**을 기준으로 주요 터미널 에뮬레이터를 비교한 2025년 평가 결과 제시 - **Ghostty**는 Zig로 새로 개발된 터미널로, 가장 높은 점수를 기록하며 **정확한 유니코드 처리**를 구현 - **Kitty**는 Ghostty와 유사한 수준의 점수를 얻었으며, **텍스트 분할 알고리듬**을 공개해 표준화에 기여 - 다수의 터미널이 **성능 저하**와 **DEC Private Mode 지원 불일치** 문제를 보였고, 특히 VTE 기반 터미널은 개선 없음 - **가변 폭 텍스트 프로토콜**의 등장으로, 단일 폭 셀 한계를 넘어 다양한 언어의 **가독성 향상 가능성** 제시 - **Errant Champions (방랑하는 챔피언들)** : Ghosty와 Kitty처럼 고전적인 규격에 안주하지 않고, 터미널의 글자폭·렌더링·유니코드 문제를 근본적으로 다시 설계한 도전자들 --- ### ucs-detect 도구와 테스트 개요 - 2023년 발표된 [**Unicode 지원 비교 실험**](https://www.jeffquast.com/post/ucs-detect-test-results/)의 후속 연구로, [`ucs-detect`](https://ucs-detect.readthedocs.io/intro.html#ucs-detect) 도구가 **DEC Private Modes**, **sixel 그래픽**, **픽셀 크기**, **소프트웨어 버전** 감지 기능을 추가 - 이 도구는 커서 위치 제어 시퀀스를 전송하고, 터미널의 응답을 **Python wcwidth** 결과와 비교해 불일치 기록 - 테스트는 각 터미널의 **문자 폭 계산 정확도**를 검증하며, 결과는 Unicode 지원 품질을 수치화 ### 문자 폭 문제 (The Width Problem) - 터미널은 **고정 폭 격자** 내에서 다양한 Unicode 문자를 표시해야 하는 구조적 한계 존재 - **결합 문자**, **이모지 시퀀스**, **Zero-width joiner** 등으로 인해 문자 폭 예측이 자주 실패 - 이러한 오차는 **커서 위치 오류**와 **출력 손상**을 유발하며, 입력 위치까지 왜곡 - 테스트 결과는 이러한 문제를 가장 적게 일으키는 터미널을 식별 ### Ghostty: 새로운 강자 - **Ghostty**는 2025년 공개된 새로운 터미널로, **Zig 언어로 처음부터 개발** - 철저한 **Unicode 지원 구현**으로 정확도가 가장 높으며, 테스트에서 최고 점수 기록 - 개발자 Mitchell Hashimoto는 2023년 [**Grapheme Clusters and Terminal Emulators**](https://mitchellh.com/writing/grapheme-clusters-in-terminals) 글을 통해 기본 원리를 연구 - 새로 발표된 **libghostty**는 기존 **libvte**를 대체할 수 있는 대안으로, 향후 터미널 생태계에 **강력한 Unicode 기반**을 제공할 가능성 있음 ### Kitty: 또 다른 챔피언 - **Kitty**는 Ghostty와 거의 동일한 점수를 기록했으며, **텍스트 셀 분할 알고리듬**을 공개 - 이 알고리듬은 **Python wcwidth 사양**과 일치하며, Unicode 표준 해석에 기반 - 두 터미널만이 **Variation Selector 15**를 올바르게 지원 - 이 기능은 실용성은 낮지만, Python wcwidth의 향후 표준 반영 예정 ### 터미널 에뮬레이터 Unicode 성능 비교 요약 - **1위 Ghostty**, **2위 Foot**, **3위 Kitty**가 상위권을 차지함 - 세 터미널 모두 **Unicode 처리 정확도(WIDE/LANG/ZJW/VS16)** 항목에서 최고 점수 기록 - **Ghostty**는 **모든 항목 100점**으로 종합 점수 100점, DEC Modes도 *enabled* - **Kitty**는 성능(Elapsed time 1748s)이 다소 느리지만 정확도 최고 수준 - **VTE 기반 터미널(GNOME Terminal, Terminator, LXTerminal 등)** 은 하위권 유지 - 모두 **Final Scaled Score 5점 이하**, 테스트 시간 8000~18000초로 매우 느림 - 2023년과 동일하게 개선 없음 - **성능(Elapsed time)** 측면에서 **Foot, WezTerm, tmux, Konsole** 등이 빠름 (100초 미만) - **iTerm2, Extraterm**은 CPU 점유율 높아 매우 느린 편 (4000초 이상) - **Sixel 그래픽 지원**은 상위권에서도 일부만 제공 - **Ghostty, Kitty, Konsole, contour**는 지원 - **GNOME Terminal, VTE 계열**은 대부분 미지원 - **Variation Selector 15(VS15)** 를 올바르게 지원하는 터미널은 **Ghostty와 Kitty 단 두 개** - Unicode 처리 완성도 면에서 사실상 두 프로젝트가 독보적임 ### 성능 분석 (The Long Road) - 다수의 터미널이 **매우 느린 성능**을 보여, 테스트 완료에 수 시간이 소요 - **iTerm2**와 **Extraterm**은 CPU를 과도하게 사용하며, 테스트 시간을 단축해야 했음 - **GNOME Terminal**과 **VTE 기반 터미널**은 CPU 사용률은 낮지만 5시간 이상 소요 - **Python wcwidth**는 고수준 언어임에도 대부분의 터미널과 속도를 맞춤 - 성능 최적화를 위해 **비트 벡터**, **블룸 필터**, **LRU 캐시** 등을 실험했으나, **이진 탐색 + LRU 캐시** 조합이 가장 효율적 - LRU 캐시는 반복되는 문자 집합을 처리할 때 효과적 - **C 모듈** 도입도 고려했으나, 현재 Python 구현으로도 충분한 성능 확보 ### 특이 사례와 문제점 (Tilting at Edges) - **Terminology**는 실행마다 결과가 달라, 내부 상태 손상 가능성 존재 - **iTerm2**는 모든 DEC Private Mode를 “지원하지만 비활성화” 상태로 보고 - **Konsole**은 질의에는 응답하지 않지만 일부 모드는 활성화 시 지원 - **Contour**는 잘못된 모드 번호로 응답해 “지원 없음”으로 표시되었으며, 2024년 12월 릴리스에서 **ESC 키 설정 오류** 발생 - **VTE/7600** 기반 터미널은 2023년과 동일한 낮은 점수 유지 - **libvte 프로젝트**의 Unicode 개선 논의는 비판을 받았으나, **Emoji 시퀀스 지원 이슈**가 2026년 개선 신호로 평가 ### Mode 2027 관련 - **Mode 2027**은 터미널의 Unicode 지원 여부를 단순히 “지원/비지원”으로 구분하지만, 세부 기능 수준은 알 수 없음 - 실제로는 **ucs-detect**처럼 개별 기능과 코드포인트를 직접 테스트하는 방식이 더 정확 ### 고정 폭을 넘어서 (Beyond Fixed Widths) - 고정 폭 셀 구조는 많은 언어의 **가독성 저하**를 초래 - **텍스트 크기 조절 프로토콜(text sizing protocol)** 은 이를 해결할 새로운 접근 - **Kitty**의 Kovid Goyal은 “마크다운 파일의 제목을 크게 보고 싶다”는 예시로 설명 - 이 기능은 **접근성 향상**과 **복잡한 문자 스크립트의 가독성 개선** 가능성 제시 - 예시로 **Contour**와 **Kate 에디터**의 Khün 언어 표시 비교에서, 가변 폭 렌더링이 더 명확한 결과 제공 - 글꼴 엔진이 셀 단위 제약 없이 텍스트를 렌더링할 수 있도록 하는 **가변 폭 모드**가 향후 발전 방향으로 제시됨 - **텍스트 크기 프로토콜**의 도입은 이러한 문제 해결의 진전으로 평가됨 ## Comments ### Comment 46150 - Author: sleepyeye - Created: 2025-11-10T21:35:29+09:00 - Points: 1 wezterm 추천드립니다 ### Comment 45961 - Author: kaorw - Created: 2025-11-06T10:26:28+09:00 - Points: 1 xshell, iterm2 쓰고 있습니다.. 다른것도 한번 써봐야겠네요 ### Comment 45891 - Author: hwhang0917 - Created: 2025-11-05T10:03:17+09:00 - Points: 1 맥, 리눅스에서는 ghostty를 많이 썼는데, windows에서는 wezterm이 제일 좋은거 같습니다. ### Comment 45883 - Author: botplaysdice - Created: 2025-11-05T09:14:07+09:00 - Points: 1 윈도우 유저로써 cygwin terminal (mintty) + mosh로 완전히 정착했습니다. 뭐 그냥 부족한건 없는듯. ### Comment 45869 - Author: savvykang - Created: 2025-11-04T20:57:27+09:00 - Points: 1 그냥 윈도우 터미널 씁니다 ### Comment 45867 - Author: ceruns - Created: 2025-11-04T19:01:52+09:00 - Points: 1 항상 Gnome terminal로 돌아오던데... ### Comment 45866 - Author: sddsdd94 - Created: 2025-11-04T17:00:20+09:00 - Points: 1 Ghostty나 Kitty가 Windows도 지원하면 참 좋을 것 같습니다. ㅠ config만 잘 만진다면 WezTerm도 꽤 괜찮았습니다. (Windows 지원) https://news.hada.io/topic?id=9270 ### Comment 45862 - Author: coderred - Created: 2025-11-04T16:22:28+09:00 - Points: 1 tabby는 비주류인가봐요.. ghostty 한번 써봐야겠네요 ### Comment 45864 - Author: coderred - Created: 2025-11-04T16:23:00+09:00 - Points: 1 - Parent comment: 45862 - Depth: 1 아. ghostty는 윈도우용이 없군요; ### Comment 45853 - Author: barca105 - Created: 2025-11-04T13:31:43+09:00 - Points: 1 LLM CLI 프로그램때문에 터미널에서도 영어권 외 다양한 언어들이 터미널에서 쓸일이 많아질텐데 그런 관점에서 터미널 에뮬레이터의 유니코드 지원은 정말 중요한 것 같아요 ### Comment 45849 - Author: t7vonn - Created: 2025-11-04T11:51:02+09:00 - Points: 1 ghostty 에서 cmd+f 기능만 들어오면 완벽할 것 같습니다. 없으니 은근 불편하네요 그리고 split 해둔 상태에서 이걸 어떻게 별도 window로 분리하는지 모르겠네요. 혹시 아시는 분 있을까요? ㅜ ### Comment 45848 - Author: jjpark78 - Created: 2025-11-04T11:40:36+09:00 - Points: 1 alacritty 무시하지마~~~ ### Comment 45844 - Author: neo - Created: 2025-11-04T10:03:33+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45799478) - 회사 일 때문에 처음으로 **Windows Terminal**을 써봤음 평생 Linux에서 개발만 하다가 써보니 Ctrl+C, Ctrl+V가 너무 **똑똑하게 작동함** 선택 영역이 없을 때는 프로세스 중단, 선택이 있을 때는 복사로 동작하고, 붙여넣기도 그냥 Ctrl+V로 됨. 정말 편리함 - Linux(특히 Wayland)에서는 아예 Ctrl+C 없이도 복사가 가능함 텍스트를 선택만 하면 복사되고, 다른 창에서 **가운데 마우스 버튼**으로 붙여넣을 수 있음 이걸 **Primary Selection**이라 부르며, 일반 클립보드(Ctrl+C/V)와는 별개로 작동함. 개인적으로 이 방식이 더 편리함 - 흥미로운 점은, 우리가 흔히 “터미널 에뮬레이터”라고 부르는 프로그램들이 실제로는 **터미널을 완전히 에뮬레이션하지 않음** 하지만 이제는 가능함. [MAME으로 VT102를 실제로 에뮬레이션하는 방법](https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME.html)을 참고하면 됨 WSL에서도 동작하며, `socat`과 `mame`을 연결해 진짜 하드웨어 터미널처럼 쓸 수 있음 예전에 VT220용으로 마우스 제어나 붙여넣기 기능을 추가한 **고수준 VT220 에뮬레이터**를 만들어보고 싶었는데, 이 글을 보고 다시 생각남 - KDE의 **Konsole**이 높은 순위에 오른 게 반가움 수십 년 된 터미널인데도 최신 터미널들과 **성능 면에서 대등하게 경쟁**하고 있음 - KDE 환경에서는 기본으로 제공되는 Konsole을 그냥 쓰면 됨 커스터마이징이 자유롭고 속도도 충분히 빠름 Dolphin에서 마우스 오른쪽 클릭으로 바로 현재 폴더에서 Konsole을 열 수 있는 점이 특히 좋음 **무한 스크롤백** 기능도 유용함. 오래된 로그가 파일로 자동 교체되어 버려지지 않음 Ctrl+Shift+X로 전체 초기화 단축키를 설정해두고 자주 사용함 - 관련 자료로는 - [VTTEST](https://invisible-island.net/vttest/vttest.html): VT100~VT520 터미널 기능 테스트용 - [Markus Kuhn의 UTF-8 테스트 파일](https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt)도 참고할 만함 - 목록에 **DECterm**이 빠져 있음 [DECterm 개요 문서](https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/usr/lib/X11/help/dxterm/Overview)를 보면 알 수 있듯, X Window System에서 최고의 **VT220 에뮬레이션**을 제공했음 VT100의 “double wide”나 “double high, double wide” 문자 모드를 지원하는 터미널은 거의 없음. 그 거대한 글자들이 꽤 재미있었음 - **xterm**은 해당 모드를 지원함. 예전에 이와 관련해 **이모지 지원**에 대한 글을 올린 적 있음: [Can your terminal do emojis?](https://dgl.cx/2025/06/can-your-terminal-do-emojis) - 이상하게도 **Windows Terminal**은 DECDHL을 지원하지만, Linux 쪽에서는 거의 지원하지 않음 - 한동안 **Alacritty**를 잘 써왔는데, 최근에 **Ghostty**를 써보고 깜짝 놀람 여러 컴퓨터에서 일할 때 유용한 **내장 테마 선택기**가 있어서 매우 편리함 전반적으로 Alacritty보다 더 나은 대안처럼 보임. 개발자들이 정말 잘 만든 듯함 - Ghostty에서 유일하게 아쉬운 점은 **스크롤백 검색** 기능이 아직 없다는 것임 tmux로 흉내낼 수는 있지만 완전히 같지는 않음 - Alacritty는 2017년부터 **글자 합자(ligature)** 지원 이슈가 열려 있는데 아직 구현되지 않음 Ghostty에 Windows 지원만 추가되면 완벽할 듯함 - 내장 테마 선택기는 당연한 기능이라고 생각했는데, 의외로 그렇지 않았음 - 터미널이 특정 **문자 리스트의 폰트 지원 여부를 질의**할 수 있으면 좋겠음 이렇게 하면 TUI 프로그램이 최신 유니코드나 **Private Use 문자(예: powerline, font-awesome 아이콘)** 를 쓸 때, 지원되지 않는 경우 자동으로 대체 문자를 표시할 수 있을 것임 - **Windows Terminal**에 대한 언급이 적은 게 아쉬움 Linux 쪽 생태계가 더 풍부하긴 하지만, 지금은 WT가 여러 Linux 터미널보다 훨씬 상위권임 10년 전에는 상상도 못 했을 일임 - 테스트 결과에서 Windows Terminal(“terminal.exe”로 표기됨)은 **4위**에 올랐음 참고로 가끔 [이 영상](https://www.youtube.com/watch?v=8gw0rXPMMPE)을 다시 보는데, 개발자 이름이 숨겨진 **이스터에그**가 있어서 좋아함 - Windows를 떠난 뒤 가장 그리운 게 바로 이 터미널임 탭, 테마, 창 이름 변경이 훌륭하고, 각 창의 용도를 한눈에 파악할 수 있음 - 개인적으로도 가장 좋아하는 터미널임. 지금은 macOS에서 Ghostty를 쓰고 있지만, WT만큼은 아님 - **Foot** 터미널도 훌륭함 Wayland 전용이지만 **가볍고 빠르게 실행**됨. 리소스 사용량도 적음 - 나도 현재 Foot을 주력으로 사용 중임 Ghostty도 좋았지만, 빈 터미널 하나 띄우는 데 **메모리 사용량이 10배 이상** 차이남 - macOS 기본 터미널은 이번 결과에서 **29위**였음 - 하루 종일 macOS Terminal.app을 쓰지만, “더 나은 터미널이 필요하다”는 생각을 해본 적이 없음 - 사실 Apple은 90년대 후반 NeXT에서 물려받은 이후 **거의 업데이트를 안 함** 그래도 최근 버전(macOS 26)에서는 Powerline과 24비트 컬러를 지원함 - 참고로 Windows 기본 터미널은 4위였음 - 순위 산정에 내가 원치 않는 **부가 요소들**이 반영된 것 같음 ### Comment 45875 - Author: ndrgrd - Created: 2025-11-04T22:13:03+09:00 - Points: 2 Kitty가 기능은 좋은데 메인테이너가 한심한 인간이라 Ghostty라는 대안이 생긴 것이 기쁘네요. ### Comment 45868 - Author: say8425 - Created: 2025-11-04T19:31:55+09:00 - Points: 2 결국 iTerm2 로 돌아옴