Ghostty가 iTerm2보다 3배 빠르다 — 병목은 에이전트가 아니다

여러 코딩 에이전트를 동시에 굴리다 보면 불편한 사실이 드러납니다. 터미널 자체가 지연 시간 예산의 일부가 된다는 점입니다. 어떤 에뮬레이터가 에이전트 조종석으로 더 나은지 따지기 전에, 먼저 더 좁고 측정 가능한 질문부터 정리하는 편이 좋습니다. Ghostty는 실제로 iTerm2보다 빠른가, 빠르다면 얼마나 빠른가?

Ghostty가 iTerm2보다 앞서는 지점

Ghostty는 순수 텍스트 처리량에서 iTerm2보다 빠르며, 에이전트가 출력을 계속 스트리밍하는 상황에서는 그 차이가 체감될 만큼 큽니다. Mitchell Hashimoto의 2024년 2월 개발 로그는 time cat japanese-bible.txt(5.4 MB, 10회 평균)를 실행해 Ghostty 73 ms, iTerm2 3.4.23 470 ms를 측정했습니다. 해당 단일 일반 텍스트 IO 경로에서는 대략 6배 차이입니다 . 2026년 2월의 더 현실적인 커뮤니티 테스트, 즉 100 MB 로그를 tail하는 테스트에서는 Ghostty가 iTerm2 시간의 약 3분의 1 수준으로 나왔고, 현재 대부분의 리뷰어가 헤드라인으로 인용하는 수치도 이 약 3배입니다 .

빠른 답: 100 MB 로그 tail 테스트에서 Ghostty는 일반 텍스트 출력을 iTerm2보다 대략 3배 빠르게 렌더링합니다. 키 입력 지연은 약 1.2 ms로 iTerm2의 약 4.1 ms보다 낮고, 유휴 RAM도 약 45 MB로 120 MB보다 적습니다. 속도 차이는 실제입니다. 하지만 에이전트 감독의 병목은 여기가 아닙니다.

2026년 리뷰 블로그들도 다른 지표에서 같은 방향을 보고합니다. 키 입력 지연은 약 1.2 ms 대 iTerm2 약 4.1 ms, 시작 시간은 70 ms 미만 대 300 ms 이상, 유휴 메모리는 약 45 MB 대 120–185 MB, 스크롤은 60 fps 제한 대비 최대 144 fps로 나타났으며, Apple M 시리즈 실리콘에서는 격차가 더 벌어집니다 .

이는 설정 조정이 아니라 아키텍처의 차이입니다. Ghostty는 Metal(macOS) 또는 OpenGL(Linux)로 렌더링하고, 각 터미널에 전용 읽기, 쓰기, 렌더링 스레드를 부여하며, macOS에서는 네이티브 Swift/AppKit GUI와 함께 공유 Zig 라이브러리인 libghostty로 제공됩니다 . Ghostty의 README는 이를 단순하게 설명합니다.

"Ghostty and Alacritty are usually within a few percent of each other, but both are something like 100x faster than Terminal.app and iTerm," — Ghostty 프로젝트 README (source: ghostty-org/ghostty).

다만 단일 숫자에 지나치게 의미를 부여하기 전 한 가지 주의할 점이 있습니다. 2024년 개발 로그는 명시적으로 "contrived" 일반 텍스트 IO 테스트이고, 2026년 수치들은 1차 공식 측정이나 독립 통제 벤치마크가 아니라 커뮤니티 측정값입니다 . 방향성, 즉 Ghostty가 더 빠르고 가볍다는 점은 신뢰하되, 정확한 배수는 근사치로 보는 편이 맞습니다.

에뮬레이터 IO로는 해결되지 않는 pane 난립 문제

순수 처리량은 출력을 더 빨리 읽게 해줍니다. 하지만 어떤 에이전트에 주의를 기울여야 하는지는 알려주지 못합니다. 이것이 seed video가 짚는 핵심 한계입니다. 에이전트가 들어 있는 tmux panes 8개를 병렬로 돌리면, 사용자가 곧 대시보드가 됩니다. 막혔는지, 입력을 기다리는지, 이미 끝났는지 확인하려고 창을 하나씩 훑어야 합니다. 더 빠른 렌더러는 그 pane들을 더 부드럽게 다시 그려줄 뿐, 세션 상태를 전역으로 보여주는 화면은 여전히 없습니다.

현업 글들은 이제 이 스택을 네 개의 층으로 설명합니다. 에뮬레이터(Ghostty, iTerm2, Alacritty), 멀티플렉서(tmux, Zellij), 오케스트레이터(cmux, Conductor, Superset), 셸 래퍼(source)입니다. Ghostty가 이기는 에뮬레이터 IO는 첫 번째 층에만 해당합니다. 조율은 두 층 위에서 일어납니다.

Anthropic은 이 작업의 일부를 CLI 안으로 옮겼습니다. Claude Code Agent View는 2026년 5월 11일 출시된 Research Preview로 v2.1.139+가 필요하며 , claude agents로 상태 화면을 엽니다. 행에는 needs-input, working, done 상태가 표시되고, /bg는 세션을 백그라운드로 보냅니다. Claude만 쓰는 환경에서는 터미널의 조율 역할이 줄어듭니다. 하지만 Codex, Aider, Gemini CLI가 섞인 플릿에는 도움이 되지 않으며, 그런 경우에는 여전히 오케스트레이터가 필요합니다.

그리고 확장에는 렌더러가 건드릴 수 없는 비용이 따릅니다. 속도 제한은 세션별로 적용되므로, Claude Code 에이전트 10개를 병렬로 돌리면 할당량을 대략 10배 빠르게 소모합니다 . fan-out의 진짜 한계는 밀리초가 아니라 할당량입니다.

두 가지 조종석 구성: Ghostty는 cmux, iTerm2는 tmux CC

어느 에뮬레이터든 에이전트 조종석으로 만들려면 조율 계층을 더해야 하는데, 두 생태계는 정반대 경로를 택합니다. Ghostty는 렌더러를 내장한 새 앱 cmux로 가고, iTerm2는 수년 전부터 제공해 온 컨트롤 모드 통합인 tmux -CC로 갑니다. 둘 다 병렬 세션을 네이티브 패널처럼 보이게 합니다. 차이는 성숙도와 확장 범위입니다.

cmux(manaflow-ai/cmux)는 libghostty 위에 출시된 첫 앱으로, 앱이 웹 뷰에 WebKit을 쓰는 방식처럼 Ghostty의 GPU 렌더링을 내장합니다 . 2026년 1월 출시됐고 2026년 7월 19일 v0.64.20에 도달했습니다 . CLI와 소켓 API로 워크스페이스를 만들고, 패널을 나누고, 키 입력을 보내며, 내장 브라우저까지 제어할 수 있어 각 하위 에이전트, 즉 Claude Code, Codex, Aider, Goose가 묻혀 있는 tmux 창이 아니라 각각 보이는 네이티브 패널에서 실행됩니다 .

cmux가 반드시 필요한 것은 아닙니다. Ghostty 1.3.0(2026년 3월 9일)은 창, 탭, 분할을 제어하고, 명령을 브로드캐스트하며, 작업 디렉터리 기준으로 터미널로 이동할 수 있는 AppleScript 자동화 프리뷰를 추가했습니다 . notify-on-command-finish 옵션은 설정 가능한 유휴 임계값 이후 실행됩니다. 릴리스 노트 예시는 30초를 사용하며, OSC 133 셸 통합이 활성화되어 있으면 폴링 없이 완료된 세션을 표시합니다 .

iTerm2의 경로는 tmux 세션을 네이티브 창과 탭으로 매핑하는 tmux -CC입니다. iTerm2를 종료하거나 SSH 연결이 끊겨도 세션은 살아 있고 tmux -CC attach로 다시 열 수 있으며, 네이티브 닫기, 분할, 크기 조정 동작은 곧바로 tmux로 전달됩니다 . 셸 통합은 마크, 명령 상태, "Alert on next mark"를 추가합니다. 둘을 함께 쓰려면 ITERM_ENABLE_SHELL_INTEGRATION_WITH_TMUX=1이 필요합니다 . Ghostty 1.3.0 노트는 VT 계층의 tmux 컨트롤 모드 파싱이 들어갔지만 아직 "GUI에 연결되지 않았다"고 확인합니다 . 그래서 컨트롤 모드 멀티플렉싱에서는 2026년 중반 기준 iTerm2가 여전히 더 성숙한 선택지입니다.

주의할 지점: 찢김 현상, OSC 9;4 keepalive, iTerm2의 tmux 우위

Ghostty의 속도에는 여러 에이전트를 맡기기 전에 알아둘 만한 대가가 있습니다. 자체 동기화 출력 문서는 Claude Code를 동기화 출력 프로토콜 없이 넓은 영역을 다시 그리는 CLI로 명시합니다. 빠른 렌더러는 CLI가 해당 프로토콜을 채택하기 전까지 깜빡임이나 화면 찢김을 드러낼 수 있습니다 . 아티팩트가 보이면 임시 방편으로 세션별 동기화 출력을 켜세요.

버전도 중요합니다. Ghostty 1.3.0(2026년 3월 9일)은 Claude Code 출력 패턴이 대규모로 발생시킨 주요 메모리 누수를 수정했습니다 . 이전 빌드에서 벤치마크했다면 메모리 사용량에 대해 결론을 내리기 전에 업그레이드해야 합니다.

분할 패널별 진행률 막대는 조건부로 동작합니다. Ghostty는 ConEmu OSC 9;4 진행률을 5개 상태에 걸친 0~100 정수로 렌더링하지만, 이 프로토콜에는 약 15초의 하드코딩된 stale 타임아웃이 있습니다 . 내보내는 CLI가 keepalive 업데이트를 보내야 막대가 멈추지 않습니다. 그리고 이는 에이전트가 실제로 진행 이벤트를 내보낼 때만 도움이 되는데, 대부분의 코딩 에이전트는 아직 그렇게 하지 않습니다.

iTerm2 쪽에서는 셸 통합이 기본적으로 tmux와 함께 동작하지 않습니다. ITERM_ENABLE_SHELL_INTEGRATION_WITH_TMUX=1을 설정해야 하며, 그 경우에도 일반 tmux UI가 아니라 tmux -CC에서만 동작합니다 . 이 플래그가 없으면 표준 멀티플렉스 보기에서 마크와 "Alert on next mark"를 사용할 수 없습니다. 바로 감독자가 가장 필요로 하는 위치인데도 말입니다.

다음 선택지: Ghostty 1.3, Warp, cmux

병목에 맞는 계층을 고르세요. Apple silicon에서 순수 IO 처리량이 중요하다면 Ghostty 1.3.1 (2026년 3월 13일)이 현재 릴리스입니다. Claude Code 출력 패턴이 유발한 메모리 누수를 고친 1.3.0 수정만으로도 어떤 1.2.x 설치본에서든 업그레이드할 이유가 충분합니다 . 구독 없이 터미널 안에서 LLM 명령 생성을 원한다면 Warp는 2026년 4월 AGPL-3.0으로 다시 라이선스를 바꿨고, 이제 내장 AI 플러그인을 갖춘 "Agentic Development Environment"로 자신을 포지셔닝합니다 .

한 저장소에서 여러 하위 에이전트를 조율하려면 Ghostty 경로에는 cmux(libghostty 임베딩, 소켓 API)를 더하고 , iTerm2 경로에는 tmux -CC를 더한 뒤 Claude 전용 세션 가시성을 위해 Claude Code Agent View를 그 위에 얹으면 됩니다 . Windows 사용자는 기다리는 편이 좋습니다. Ghostty의 Windows 지원은 2026년 중반 현재 계획 단계에 머물러 아직 출시되지 않았고, cmux의 커뮤니티 포트인 wmux도 진행 중입니다. 둘 다 프로덕션 준비가 끝나지 않았습니다 . 결론은 이렇습니다. 속도는 기본 조건입니다. 먼저 오케스트레이션 계층을 고르고, 에뮬레이터는 그 계층을 받쳐 주게 하세요.

자주 묻는 질문

Ghostty가 정말 iTerm2보다 3배 빠른가요?

일반 텍스트 IO 처리량만 놓고 보면 그렇습니다. 다만 단서가 있습니다. Mitchell Hashimoto가 5.4MB 텍스트 파일 읽기로 측정한 벤치마크에서는 Ghostty가 73ms, iTerm2가 470ms로 약 6배 차이가 났습니다 . 2026년 2월 커뮤니티의 100MB 로그 tail 테스트에서는 Ghostty가 iTerm2의 약 3분의 1 시간으로 측정됐고, 여기서 흔히 말하는 약 3배라는 수치가 나왔습니다 . 둘 다 하드웨어와 버전에 따라 달라지는 방향성 벤치마크이지 통제된 제3자 테스트 하네스는 아니므로, 빠르다는 방향은 신뢰하되 특정 배수는 대략적인 값으로 보는 편이 좋습니다.

Ghostty로 바꾸면 멀티 에이전트 환경이 체감될 만큼 빨라질까요?

단일 세션에서 빽빽한 로그 출력을 렌더링하는 경우에는 그렇습니다. Ghostty의 GPU 가속 파이프라인은 대량 텍스트 스트림을 iTerm2보다 더 빠르게 처리하고 유휴 메모리도 더 적게 씁니다 . 하지만 핵심 감독 문제, 즉 병렬 세션 8개 중 지금 어느 세션에 주의를 줘야 하는지 아는 문제에는 그렇지 않습니다. 그 제약은 IO 처리량이 아니라 에뮬레이터 위의 조율 계층에 있습니다. 더 빠른 렌더러는 막힌 에이전트의 프롬프트를 더 선명하게 그려줄 뿐, 그 에이전트가 막혔다는 사실을 알려주지는 않습니다.

libghostty는 무엇이고 cmux는 어떻게 사용하나요?

libghostty는 Ghostty의 공유 Zig 렌더링 라이브러리로, macOS 네이티브 Swift/AppKit GUI와 분리되어 있습니다. 그래서 다른 애플리케이션이 렌더러를 다시 구현하지 않고도 Ghostty의 터미널 엔진을 내장할 수 있습니다. cmux는 이를 제품에 탑재한 첫 앱으로, 앱이 웹뷰용 WebKit을 내장하듯 libghostty의 GPU 가속 렌더링을 내장합니다 . 그 결과 cmux는 조율에 초점을 둔 호스트 앱 안에 네이티브 GPU 렌더링 터미널 패널을 제공하며, 서브에이전트를 수동으로 오가야 하는 tmux 창이 아니라 눈에 보이는 패널로 바꿔줍니다.

Ghostty는 iTerm2처럼 tmux control mode를 지원하나요?

2026년 기준으로는 아직 아닙니다. Ghostty 1.3.0(2026년 3월 9일)은 VT 계층에서 tmux control mode 파싱을 크게 늘렸지만, 릴리스 노트에는 아직 "not hooked up to the GUI yet"이라고 명시되어 있습니다 . iTerm2의 tmux -CC 통합, 즉 tmux 세션을 네이티브 탭으로 매핑하고 앱 재시작이나 SSH 연결 끊김 뒤에도 유지하는 기능은, 다중화된 에이전트 감독에서 Ghostty보다 iTerm2가 가진 가장 구체적인 실무상 장점으로 남아 있습니다.

Claude Code Agent View가 터미널 멀티플렉서를 대체하나요?

Claude만 쓰는 워크플로에서는 일부 그렇습니다. 2026년 5월 11일 도입되고 Claude Code v2.1.139 이상이 필요한 Claude Code Agent View는 claude agents로 열 수 있으며, 어떤 세션이 입력을 기다리는지, 작업 중인지, 완료됐는지를 보여줍니다. 또한 터미널을 열어두지 않아도 세션이 계속 실행되도록 백그라운드 attach/detach를 제공합니다 . 다만 Aider, Codex, Goose 또는 다른 CLI에는 도움이 되지 않고, 패널 단위 출력 가시성도 제공하지 않습니다. 따라서 터미널의 역할을 줄여줄 뿐, 에뮬레이터나 멀티플렉서를 완전히 없애지는 않습니다.

이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.

구독하기