- 
Unicode 지원 정확도와 성능을 기준으로 주요 터미널 에뮬레이터를 비교한 2025년 평가 결과 제시
 
- 
Ghostty는 Zig로 새로 개발된 터미널로, 가장 높은 점수를 기록하며 정확한 유니코드 처리를 구현
 
- 
Kitty는 Ghostty와 유사한 수준의 점수를 얻었으며, 텍스트 분할 알고리듬을 공개해 표준화에 기여
 
- 다수의 터미널이 성능 저하와 DEC Private Mode 지원 불일치 문제를 보였고, 특히 VTE 기반 터미널은 개선 없음
 
- 
가변 폭 텍스트 프로토콜의 등장으로, 단일 폭 셀 한계를 넘어 다양한 언어의 가독성 향상 가능성 제시
 
- 
Errant Champions (방랑하는 챔피언들) : Ghosty와 Kitty처럼 고전적인 규격에 안주하지 않고, 터미널의 글자폭·렌더링·유니코드 문제를 근본적으로 다시 설계한 도전자들
 
ucs-detect 도구와 테스트 개요
- 2023년 발표된 Unicode 지원 비교 실험의 후속 연구로, 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 글을 통해 기본 원리를 연구
 
- 새로 발표된 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 언어 표시 비교에서, 가변 폭 렌더링이 더 명확한 결과 제공
 
- 글꼴 엔진이 셀 단위 제약 없이 텍스트를 렌더링할 수 있도록 하는 가변 폭 모드가 향후 발전 방향으로 제시됨
 
- 
텍스트 크기 프로토콜의 도입은 이러한 문제 해결의 진전으로 평가됨