← today i learned

Ghostty vs Windows Terminal

아직 공식 대결이 성립하지 않는 비교. 공식 Ghostty 는 2026년 7월 현재 Windows 에 없다. 그래서 이 비교는 세 층위로 나눠야 정직하다 — 설계 철학의 비교, 지금 Windows 에서의 현실(Windows Terminal vs 비공식 포트 winghostty), 그리고 공식 Ghostty 가 Windows 에 오는 경로.

미첼 하시모토 인터뷰 해설의 부록(경쟁 터미널 대비 Ghostty 강점)에서 이어지는 별개 페이지 · 작성 2026-07-13

1. 전제 — 왜 이 비교는 비대칭인가

iTerm2·kitty·Alacritty 와의 비교(이전 페이지 부록)는 같은 플랫폼에서 둘 다 설치해 나란히 돌려 본 사용자들의 후기가 근거였다. Ghostty vs Windows Terminal 은 그게 안 된다. 공식 Ghostty 의 지원 플랫폼은 macOS 와 Linux 뿐이고, Windows 지원은 공식 discussion 기준 "계획은 있으나 타임라인 없음" 상태다. 하시모토가 지금 집중하는 것은 libghostty(터미널 코어의 라이브러리화)이고, Windows 는 그 라이브러리의 확장 타겟으로 명시돼 있다.

반대 방향도 비대칭이다. Windows Terminal 은 Windows 전용이라 macOS·Linux 사용자에게는 애초에 선택지가 아니다. 즉 두 프로젝트는 오늘 기준 겹치는 시장이 없다. 그런데도 이 비교가 의미 있는 이유는 두 가지다. 첫째, 두 프로젝트는 "터미널을 어떻게 만들어야 하는가"에 대해 흥미롭게 수렴하고 흥미롭게 갈라진다. 둘째, libghostty 가 진행되고 비공식 포트가 이미 돌아가는 지금, 이 대결은 몇 년 안에 실제로 성립할 가능성이 높다.

2. 프로필 한눈 비교

3. Windows Terminal — Windows 의 "네이티브" 는 이쪽이다

하시모토의 Ghostty 원칙은 "코어는 크로스플랫폼, GUI 는 비타협적 네이티브"다. 이 잣대를 Windows 에 적용하면 통과하는 것은 현재 Windows Terminal 쪽이라는 점이 이 비교의 첫 번째 아이러니다. Windows Terminal 은 Windows 의 UI 스택(XAML/WinUI)으로 만들어졌고, PowerShell·cmd·WSL·Azure Cloud Shell 을 프로파일로 통합한다. kitty 나 Alacritty 가 macOS 에서 받는 "이질적인 창" 비판을 Windows Terminal 은 자기 플랫폼에서 받지 않는다.

"기본 터미널" 의 정확한 범위

"Windows 의 기본 터미널"이라는 표현은 조건 없이 쓰면 틀린다. cmd 와 PowerShell 은 셸이고, 그 셸을 창에 그려 주는 앱이 터미널인데, Windows 의 역대 기본 터미널은 그 회색 창 — conhost.exe(콘솔 호스트)였다. Windows Terminal 은 2019년 스토어 앱으로 출발한 별도 프로젝트다. 전환점은 Windows 11 22H2(2022년 10월 업데이트)로, 이때부터 기본 터미널 애플리케이션이 conhost 에서 Windows Terminal 로 바뀌어 .cmd 더블클릭·Win+X·시작 메뉴의 PowerShell 이 전부 Windows Terminal 탭으로 열린다.

단서가 셋 붙는다. Windows 10 에서는 여전히 conhost 가 기본이고 Windows Terminal 은 스토어에서 따로 설치해야 한다. Windows 11 에서도 설정으로 기본 터미널을 conhost 로 되돌릴 수 있다. 그리고 conhost 는 사라진 게 아니라 아래 5장의 ConPTY 배관이 되어 모든 세션의 물밑에서 계속 돈다. 요약하면 "Windows 11 22H2 이후의 기본 터미널 앱"이 정확한 표현이다.

WSL·PowerShell 통합의 실체

"통합"이라는 말이 실제로 가리키는 동작은 이런 것들이다:

• 동적 프로파일 — 설치된 셸 환경(PowerShell 7, WSL 의 각 배포판, Azure Cloud Shell)을 자동 감지해 새 탭 드롭다운에 프로파일로 등록한다. Ubuntu 배포판을 설치하면 아무 설정 없이 다음 실행부터 Ubuntu 탭이 생긴다.
• 프로파일 단위 설정 — 셸마다 시작 디렉터리·배색·폰트·아이콘을 따로 가진다. WSL 프로파일의 시작 경로를 \\wsl$ 경유의 리눅스 홈 디렉터리로 잡는 식으로, Windows/리눅스 경계를 넘는 설정이 자연스럽다.
• OS 진입점 — 탐색기 우클릭 "터미널에서 열기", Win+X 메뉴, 탭·분할 구성까지 지정할 수 있는 wt CLI 인자가 전부 Windows Terminal 로 이어진다.
• 셸 통합 시퀀스 — 셸이 프롬프트 위치를 알려 주면(OSC 133 계열) 명령 단위로 스크롤을 점프하고 출력 블록을 통째로 선택할 수 있다. PowerShell 과의 연동이 대표 사례고, 탭 복제 시 현재 작업 디렉터리가 유지되는 것도 셸이 경로를 알려 주는 같은 계열의 시퀀스 덕이다.

요컨대 여러 셸이 공존하는 OS 에서 셸들을 묶는 허브가 이 통합의 정체다. 단일 셸 문화에 가까운 macOS·Linux 를 타겟으로 하는 Ghostty 에는 애초에 이만한 프로파일 개념이 필요하지 않았고, 이 차이가 6장의 설정 철학 차이로 이어진다.

최근 기능 흐름

기능 면에서도 정체된 프로젝트가 아니다. 최근 흐름만 짚으면:

• Sixel 인라인 이미지 — 1.22 프리뷰에서 커뮤니티 기여(j4james)로 구현됐다. WinGet 이 콘솔 안에 앱 아이콘을 그리는 식의 활용이 시작됐다.
• OSC 52(클립보드)·정규식 검색·quake 모드·탭 분리(tearout) 등 서드파티 터미널의 대표 기능들을 꾸준히 흡수하고 있다.
• 콘솔 엔진 자체의 재건 — 2026년 3월 Windows 11 업데이트에서 conhost 계층까지 재구축해 일부 시나리오 스크롤 성능 최대 10배, sixel·정규식 검색이 구식 콘솔에도 내려갔다.

마지막 항목이 구조적으로 중요하다. Windows Terminal 팀은 터미널 앱 하나가 아니라 ConPTY(의사 콘솔) 인프라의 관리자다. Windows 에서 돌아가는 모든 서드파티 터미널 — Alacritty 든 WezTerm 이든, 미래의 Ghostty 든 — 이 이 팀이 만드는 배관 위에서 돌아간다.

4. Ghostty 가 Windows 에 없는 이유, 그리고 오는 경로

Ghostty 의 Windows 부재는 기술적 불가능이 아니라 우선순위다. 하시모토는 2025년 9월 libghostty 계획에서 초기 타겟을 macOS·Linux 로 잡되 "Windows, 임베디드, WASM 웹"으로 확장하겠다고 명시했다. 코어(VT 파서·화면 상태·렌더링)를 C ABI 라이브러리로 분리하고, 그 위에 플랫폼별 GUI(현재 Swift·GTK)를 얹는 구조이므로, Windows 판은 "코어 이식 + Win32/WinUI 프론트엔드 신작"이라는 큰 작업이 된다. 비타협적 네이티브 원칙을 Windows 에서도 지키려면 Electron 식 지름길이 없기 때문이다.

그 공백을 커뮤니티가 먼저 메웠다:

• winghostty — 2026년 4월 시작된 비공식 포크. Ghostty 의 터미널 코어(VT 파서·스크롤백)를 그대로 쓰고 Zig 로 짠 네이티브 Win32 런타임을 얹었다. WGL 경유 OpenGL 4.3 렌더링, 네이티브 탭바·모니터별 DPI·IME·WSL 인식 셸 선택까지 갖췄고 x64/ARM64 인스톨러로 배포된다(2026-07-11 기준 1.3.117). 업스트림을 git remote 로 추적하며 충돌 시 Windows 동작을 우선한다.
• ghostty-windows — DirectWrite 폰트 백엔드를 쓰는 또 다른 커뮤니티 x64 빌드.

단, 이들은 공식 프로젝트가 아니다. 단일 메인테이너 의존, 업스트림과의 지속 동기화 부담(이전 페이지에서 다룬 포크 대칭성 반론의 실물 사례다), 보안 업데이트 보증 없음이라는 전형적 포크 리스크를 안고 있다. 흥미롭게도 하시모토의 "개인·유지 포크가 훨씬 많아져야 한다"는 지론이 실제로 작동한 사례이기도 하다 — libghostty 방향의 코어/셸 분리가 이런 포크를 가능하게 했다.

5. 성능과 레이턴시 — ConPTY 라는 공통 천장

macOS·Linux 에서 Ghostty 의 강점 중 하나는 체감 성능이다(시작 100ms 미만, 로그 폭주에도 여유). 그러나 이 강점을 Windows 로 그대로 들고 올 수 있다고 가정하면 안 된다. Windows 에서는 모든 서드파티 터미널이 ConPTY 라는 변환 계층을 거친다.

ConPTY 란 무엇인가

Unix 계열에서 PTY(의사 터미널)는 커널이 제공하는 원시 부품이다. 터미널과 셸 사이에 양방향 바이트 스트림 하나가 있고 그 위로 VT 이스케이프 시퀀스가 흐르는 게 전부라서, 터미널 에뮬레이터는 그 스트림만 해석하면 된다. Windows 는 사정이 다르다. 40년 치 콘솔 프로그램들이 바이트 스트림이 아니라 Console API — WriteConsole 같은 함수 호출 — 로 화면을 그려 왔다. 서드파티 터미널이 이 앱들을 품으려면 함수 호출의 결과를 가로챌 방법이 필요한데, 공식 방법이 없던 시절에는 화면 밖에 콘솔을 숨겨 두고 그 버퍼를 긁어 오는 해킹(winpty)이 유일한 길이었다.

ConPTY(의사 콘솔 API)는 2018년 Windows 10 1809 에서 그 해킹을 OS 공식 기능으로 승격시킨 것이다. 콘솔 앱과 터미널 사이에 conhost 인스턴스가 번역기로 끼어들어, 앱의 Console API 호출을 VT 시퀀스로, 터미널이 보낸 입력을 콘솔 입력 이벤트로 양방향 변환한다. 덕분에 터미널 개발자는 Unix 에서처럼 바이트 스트림만 다루면 되고 — Alacritty·WezTerm 의 Windows 지원도, winghostty 가 Ghostty 코어를 거의 그대로 들고 올 수 있었던 것도 이 API 가 있어서다. 대가는 구조적이다. 세션마다 번역 프로세스가 하나 더 끼고, 버퍼링과 청크 단위 전달이 레이턴시를 더하며, 숨은 콘솔 창이 포커스를 훔치는 류의 오랜 버그도 있다. 2026년 3월의 콘솔 엔진 재건은 바로 이 계층의 성능 개선이다.

이 구조의 실측 근거로 자주 인용되는 것이 Chad Austin 의 키 입력 레이턴시 측정(2024-02, 120Hz 카메라 실측)이다:

주목할 것은 순위표의 꼭대기다. GPU 가속 신형 터미널들이 아니라 구식 conhost 가 가장 빨랐다. macOS 에서 "iTerm2 는 느리고 Ghostty 는 빠르다"로 요약되던 구도가 Windows 에서는 성립하지 않는다는 뜻이다 — 여기서는 GPU 가속 자체가 승부를 결정하지 못하고, ConPTY 왕복과 합성 파이프라인이 병목을 지배한다. 미래의 공식 Ghostty 도 이 천장 아래에서 시작한다.

PuTTY 는 이 지도의 어디에 있나

Windows 터미널 이야기에서 빠지지 않는 PuTTY(1999)는 위 두 앱과 계보가 다르다. 로컬 셸을 품는 터미널이 아니라 SSH·telnet·시리얼용 원격 접속 클라이언트로, 접속하는 순간 PTY 는 원격 리눅스 서버의 커널에 만들어진다. 즉 SSH 세션은 로컬 ConPTY 를 아예 거치지 않는다 — 위 다이어그램의 오른쪽 우회로다. 레이턴시 표 공동 1위인 MinTTY 가 PuTTY 의 터미널 구현에서 갈라져 나온 코드라는 점도 우연이 아니다. GPU 가속 없는 구식 렌더링이 최신 GPU 터미널보다 빨랐던 이유는 그림 실력이 아니라 파이프라인이 짧기 때문이다.

다만 PuTTY 조차 로컬 셸을 품는 순간에는 ConPTY 아래로 들어온다. 0.77 부터 제공되는 pterm.exe(cmd 등 Windows 콘솔 앱용 PuTTY 창)가 정확히 ConPTY 위에서 돈다 — 로컬 셸을 다루는 한 누구도 이 계층을 피할 수 없다는 또 하나의 증거다. 한편 Windows 10 부터 OpenSSH 클라이언트(ssh.exe)가 기본 탑재되면서 "Windows Terminal + ssh" 조합이 PuTTY 의 전통적 역할을 잠식하는 중이라, 원격 접속 위주 사용자에게는 그 전환이 Ghostty vs Windows Terminal 보다 훨씬 현실적인 선택 문제다.

6. 철학 비교 — 수렴하는 원칙, 갈라지는 거버넌스

수렴: 네이티브 GUI 와 "기능 풍부 ≠ 부풀림"

두 프로젝트는 서로 독립적으로 같은 결론에 도달했다. 플랫폼 고유 UI 스택을 쓰고(AppKit/GTK ↔ XAML/WinUI), GPU 가속 렌더러를 직접 만들고(Metal/OpenGL ↔ AtlasEngine), 기능을 많이 넣되 기본 경험을 어지럽히지 않는다. 하시모토가 인터뷰에서 말한 "새 프로토콜을 만들기 전에 Win32·WinUI 같은 기존 플랫폼 선례를 조사한다"는 원칙까지 포함하면, 그가 Windows Terminal 의 접근을 부정할 이유는 별로 없다.

갈라짐 1: 설정 철학

Ghostty 는 제로 컨피그가 목표다 — 설정 파일 없이도 완성돼 있어야 하고, 설정은 평평한 텍스트다. Windows Terminal 은 GUI 설정 화면과 settings.json 의 이중 구조로, 프로파일(셸별 설정 묶음)이라는 추가 개념이 있다. Windows 의 현실(PowerShell·cmd·여러 WSL 배포판이 공존)에는 프로파일 모델이 맞지만, "깔고 바로 끝"이라는 Ghostty 식 감촉과는 거리가 있다.

갈라짐 2: 그래픽 프로토콜의 진영

Ghostty 는 Kitty 그래픽 프로토콜(현대 서드파티 터미널 진영의 사실상 표준)을, Windows Terminal 은 Sixel(1980년대 DEC 유래의 구 표준)을 택했다. 인터뷰에서 하시모토가 짚은 "터미널에 표준화 기구가 없어서 가장 인기 있는 터미널을 따라가는 방식으로 표준화된다"는 문제의 실례다 — 양쪽 다 자기 생태계에서 가장 인기 있는 쪽을 따라갔고, 결과적으로 진영이 갈렸다.

갈라짐 3: 거버넌스

가장 근본적인 차이다. Ghostty 는 "의무 0, 그러나 책임감" 을 말하는 개인 유지보수자의 프로젝트고, Windows Terminal 은 이슈 트래커·로드맵·보안 패치 의무를 지는 Microsoft 제품이다(코드는 MIT 오픈소스이며 sixel 처럼 굵직한 기능이 커뮤니티에서 오기도 한다). 어느 쪽이 좋은가는 사용자가 무엇을 원하느냐에 달렸다 — 벤더에게 책임을 물을 권리가 필요한 조직이라면 후자가 정답이고, 하시모토식으로 말하면 그 권리는 원래 돈(또는 플랫폼 종속)을 내고 사는 것이다.

7. 총평 — 오늘 무엇을 쓸까

• Windows 에서 오늘 고른다면: Windows Terminal 이 합리적 기본값이다. Windows 11 에서의 기본 터미널 지위(3장), 자동 업데이트, WSL·PowerShell 허브 역할, 그리고 빠르게 좁혀지는 성능 격차까지, 서드파티로 갈아탈 유인이 예전보다 약해졌다. Ghostty 의 감촉이 궁금하면 winghostty 를 시험해 볼 수 있지만, 비공식 포크의 리스크(단일 메인테이너·보증 없음)를 이해하고 쓰는 실험으로 접근해야 한다. 원격 서버 접속이 주 용도라면 PuTTY 에서 "Windows Terminal + 기본 탑재 ssh" 로의 전환(5장)이 먼저 검토할 문제다.
• macOS·Linux 사용자에게: 이 비교는 선택 문제가 아니다. 다만 Windows Terminal 팀의 ConPTY·conhost 개선은 WSL 을 쓰는 순간 간접적으로 체감된다.
• 진짜 대결은 아직: libghostty 가 Windows 타겟을 완성하고 공식 Win32 프론트엔드가 나오는 시점 — 그때의 관전 포인트는 렌더러 성능이 아니라 ConPTY 천장 아래에서 Ghostty 의 강점(제로 컨피그·기본값의 완성도)이 얼마나 살아남는가, 그리고 OS 기본 앱을 이길 만큼의 차별화가 남는가다. iTerm2 를 이기는 것과 OS 기본 터미널을 이기는 것은 난도가 다른 게임이다.

소스: Ghostty Windows Support discussion · libghostty Is Coming (mitchellh.com, 2025-09) · winghostty · ghostty-windows · Windows Terminal Preview 1.22 · Windows 11 console upgrade (2026-03) · Terminal Latency on Windows (Chad Austin, 2024-02) · WT as your Default (devblogs) · Introducing ConPTY (devblogs, 2018) · PuTTY Change Log · 배경: 미첼 하시모토 인터뷰 해설