Ghostty 1.4 출시, 보안 수정 10건부터 확인

effidev·2026년 10월 28일

맥이나 리눅스에서 터미널 앱을 쓰는 사람이라면, 2026년 10월 27일에 나온 Ghostty 1.4.0에서 가장 먼저 볼 곳은 속도 표가 아니라 보안 목록이다.

같은 날 앱 쪽 보안 권고가 10건 한꺼번에 공개됐다. 영향 버전은 전부 1.3.1 이하이고, 고친 버전은 1.4.0 하나뿐이다. 걸리는 조건도 거창하지 않다. 복사한 글을 붙여넣을 때, 링크를 Cmd+클릭할 때, 내용을 모르는 저장소 폴더에 cd로 들어갈 때가 그렇다. 클로드 코드 같은 명령줄 에이전트를 돌리느라 남의 저장소를 자주 받아 오는 사람에게는 남 일이 아니다.

이 글은 터미널 앱을 막 쓰기 시작한 사람도 읽을 수 있게 썼다. 터미널 에뮬레이터, 스크롤백, 이스케이프 시퀀스 같은 말은 나올 때마다 한 줄로 풀었다. 근거는 세 곳이다. ghostty.org의 1.4.0 릴리스 노트, GitHub 저장소의 보안 권고 목록(오늘 직접 조회), 발표 당일 해커뉴스 댓글이다.

Ghostty 앱은 릴리스 노트가 macOS용과 리눅스·FreeBSD용(GTK)만 다룬다. 윈도우 PC에서 글을 쓴 이 사이트는 설치해 돌려 보지 못했다. 직접 한 것은 보안 권고 조회와 숫자 계산이고, 속도와 메모리 수치는 전부 만든 팀이 적은 값이다.

터미널 에뮬레이터가 뭐고, 왜 업데이트가 보안 얘기가 되나

터미널 에뮬레이터는 검은 창에 명령을 쳐 넣는 앱이다. 맥의 터미널, iTerm2, Kitty, Ghostty가 모두 여기에 든다. 이 앱은 키보드로 친 글자를 셸(명령을 알아듣는 프로그램)에 넘기고, 셸이 돌려준 글자를 화면에 그린다.

문제는 화면에 그려지는 글자가 전부 안전하지는 않다는 점이다. 터미널은 평범한 글자 사이에 섞인 이스케이프 시퀀스(화면 색을 바꾸거나 커서를 옮기는 특수 신호)도 해석한다. 이 신호로 클립보드를 바꾸거나 링크를 만들거나 이미지를 띄울 수 있다. 기능이 많을수록 믿을 수 없는 글자를 화면에 띄우는 일이 위험해진다. 이번 보안 수정 대부분이 이 지점에 있다.

한 표로 보는 Ghostty 1.4: 숫자마다 조건이 붙어 있다

릴리스 노트에 따르면 1.4.0은 7개월 동안 기여자 172명이 커밋 2,889개로 만든 버전이다. 큰 변화를 숫자와 함께 정리하면 이렇다.

이 표에서 가장 눈에 띄는 5.7배는 128에서 725를 나눈 값이 맞다. 725를 128로 나누면 5.66이라서 반올림한 숫자다. 다만 이건 터미널 전체가 5.7배 빨라졌다는 뜻이 아니라 글자를 해석하는 부품(파서)을 따로 돌린 시험이다. 사람이 체감하는 쪽에 가까운 숫자는 그 아래 cat 시험이다. 1.5초를 0.566초로 나누면 2.65배다. 그것도 맥에서 150MB짜리 파일을 한 번에 쏟아낼 때의 값이다.

보안 수정 10건을 쉬운 말로 풀면

릴리스 노트는 보안 항목마다 권고 번호(GHSA)를 달아 두었다. 번호는 GitHub가 보안 문제에 붙이는 관리 번호다. GitHub 저장소의 권고 목록에서 영향 버전과 점수를 대조해 표로 옮겼다.

릴리스 노트가 직접 선을 긋는 말이 있다. 네 건은 화면에 악성 출력이 뜨기만 해도 해당하고, 나머지는 붙여넣기·클릭·cd·드래그 같은 사용자 동작이 있어야 한다. 노트는 이 조건을 항목마다 적어 두었다.

점수는 GitHub 표기로 이렇다. 점수가 있는 9건은 4.3에서 6.5 사이이고, 전부 심각도 medium이다. 점수가 비어 있는 1건은 Kitty 그래픽 항목이다. 노트에는 이런 말도 있다. 몇 주 전에 CVE 번호를 요청했는데 GitHub가 아직 배정하지 않았다는 것이다. CVE 번호가 없다고 가볍게 볼 일은 아니고, 아직 번호표가 안 붙었을 뿐이다.

13건이라는 숫자: 노트에 없는 3건을 GitHub에서 찾았다

GitHub 저장소의 보안 권고 목록을 직접 조회했다. 10월 27일 UTC 16시 41~42분에 한꺼번에 공개된 권고는 13건이었다. 노트에 적힌 10건 말고 세 건이 더 있고, 모두 앱이 아니라 라이브러리 libghostty-vt 쪽이다.

libghostty는 Ghostty의 터미널 해석 부분만 따로 떼어 다른 앱이 가져다 쓰게 만든 라이브러리다. 노트는 이 라이브러리를 쓴 터미널의 사용자 수가 Ghostty 앱 사용자 수의 “몇 배”일 거라고 쓰면서, 정확히 세기는 어렵다고 덧붙였다. 그러니 Ghostty 앱을 안 써도 libghostty 기반 터미널을 쓰고 있을 수 있다. 어떤 앱이 어떤 버전을 가져다 쓰는지는 이 글이 확인하지 못했다.

붙여넣기·드래그 쪽 방어가 뚫린 게 이번이 처음도 아니다. 같은 저장소 목록에 올해 3월 공개된 권고(CVE-2026-26982)가 있다. 붙여넣기와 드래그 앤 드롭에 섞인 제어 문자로 임의 명령이 실행되는 문제이고, 1.3.0에서 고쳤다. 7개월 만에 같은 영역에서 또 하나가 나온 셈이다. 터미널의 붙여넣기 보호는 한 번 짜 놓으면 끝나는 기능이 아니라 계속 구멍을 메워야 하는 기능으로 읽힌다. 이건 이 글의 해석이다.

새 기능과 새 구멍이 같은 곳에 있다

1.4의 큰 기능 두 가지는 이미지와 클립보드다. Kitty 그래픽 프로토콜(터미널에 이미지를 띄우는 약속)의 마지막 큰 조각인 애니메이션과 상대 배치를 넣어, 노트 표현으로는 공개 사양의 100%를 구현했다. 애니메이션 GIF를 kitten icat으로 띄우면 이제 정지 화면이 아니라 움직인다. 큰 이미지 전송을 한 글자씩이 아니라 묶음으로 읽게 바꿔, 64MiB 시험(x86_64 리눅스)에서 읽는 속도가 약 16배 빨라졌다고 한다.

Kitty 클립보드 프로토콜(OSC 5522)도 새로 구현했다. 기존 OSC 52는 평범한 글자만 클립보드에 쓰고 읽었는데, 이쪽은 이미지나 HTML도 다룬다. 기본 설정은 읽을 때 허락을 묻고 쓸 때는 허락 없이 통과시킨다. 허락 창은 클립보드 내용을 미리 보여 주고, 한 번에 쓸 수 있는 크기는 64MiB로 제한한다.

이 두 기능은 위의 보안 표와 겹친다. 조작된 Kitty 그래픽 명령(mhff)과 Kitty 클립보드 별칭(3r5j)이 같은 영역의 권고다. 기능이 늘면 믿을 수 없는 출력이 건드릴 수 있는 부분도 는다. 이건 개별 권고를 이어 붙인 이 글의 해석이다. 새 기능 쪽에서 노트가 밝힌 안전장치로는, 악용될 수 있다고 본 새 신호 둘(창 크기 조절 CSI 8 t, 화면 체크섬 요청)을 기본으로 꺼 둔 것이 있다.

SSH 쪽 변화도 있다. ghostty +ssh라는 명령은 ssh를 감싸서, 접속하기 전에 원격 서버에 Ghostty용 터미널 정보(terminfo)를 깔고 TERM_PROGRAM 같은 환경 변수를 전달한다. 설치가 안 되면 xterm-256color로 물러난다. 모든 ssh 호출을 이쪽으로 돌리려면 노트가 적은 대로 alias ssh='ghostty +ssh --'를 쓰면 된다.

스크롤백 압축: 기록은 늘리고 메모리는 줄였다

스크롤백은 화면 위로 밀려난 지난 출력 기록이다. 빌드 로그를 스크롤해 올려 보는 그 기록이다. 1.4는 지금 보이지 않는 스크롤백을 터미널이 한가할 때 압축하고, 올려 볼 때나 검색할 때 풀어서 쓴다. 노트가 적은 효과는 글자가 많은 기록에서 물리 메모리 70~90% 감소다. 입출력 속도에는 잴 만한 영향이 없다고 한다.

압축 덕에 기본 한도를 10MB에서 50MB로 올렸다. 여기서 계산 하나가 나온다. 50MB를 70%만 줄이면 15MB가 남는다. 옛 한도 10MB보다 크다. 80%를 줄여야 10MB로 같아지고, 90%면 5MB다. 노트가 “가득 찬 기록이 대체로 옛 10MB 한도보다 메모리를 덜 쓴다”에서 대체로라고 쓴 이유가 이 계산에서 보인다. 압축률이 80% 아래로 떨어지는 기록에서는 이전보다 메모리를 더 쓸 수 있다.

주의할 점도 노트에 적혀 있다. 압축은 가상 메모리가 아니라 물리 메모리를 줄인다. 활동 모니터에서 메모리를 볼 때 상주(resident) 메모리를 봐야 효과가 보인다. 지원 환경은 macOS와 64비트 리눅스다.

그 밖에 메모리 숫자 둘이 있다. 새 터미널은 맨 처음 128KiB 대신 약 16KiB만 쓰고(8배 작다), 탭이 21개 열린 상황에서 20개가 숨어 있으면 GPU 메모리가 약 385MiB에서 18MiB로 준다(약 21배). 탭이 다시 보일 때 되살리는 데는 1밀리초가 안 걸린다고 한다. 이건 전부 macOS에서 잰 값이다.

업데이트 전에 볼 바뀐 기본값

보안 때문에 올리기로 마음먹었다면, 설정을 만져 둔 사람은 아래 몇 가지가 바뀌었다는 점을 알고 있어야 한다.

리눅스 사용자는 더 근본적인 걸림돌이 있다. 1.4는 GTK 4.18과 libadwaita 1.7을 요구해서, 노트가 직접 우분투 24.04 LTS는 이 조건을 못 채운다고 적었다. 노트가 제시한 우회로는 옛 Ghostty에 머물거나 Flatpak 패키지를 쓰는 것이다.

여기서 보안과 부딪힌다. GitHub 목록에서 위 10건의 패치 버전은 전부 1.4.0뿐이다. 1.3.x 패치 릴리스는 목록에 보이지 않는다. 그러니 1.3.1에 머무는 쪽은 이번 수정을 받지 못한다. Flatpak 패키지가 1.4.0을 이미 담았는지는 이 글이 확인하지 못했다. 우분투 24.04 LTS 사용자라면 이 부분을 먼저 알아봐야 한다.

macOS 쪽은 업데이트 부품도 바뀌었다. 변경 목록에 업데이터인 Sparkle을 2.9.6으로 올렸고, Sparkle의 보안 권고 CVE-2026-47121과 CVE-2026-47122가 해결된다고 적혀 있다. macOS 27(Golden Gate) 지원도 들어갔다. 최소 요구는 여전히 macOS 13이다. 노트는 macOS 13의 보안 지원을 애플이 2025년 가을에 끝냈으니 어차피 올리라고 권한다.

해커뉴스에서 갈린 이야기: 그래서 왜 Ghostty냐

발표 당일 해커뉴스 글은 600점대였고 댓글이 190개를 넘었다. 보안 얘기보다 “왜 이걸 써야 하나”가 먼저 나왔다. 모두 개인 의견이다.

• 리눅스에서 Konsole이 Ghostty·Kitty·WezTerm보다 빠르고 기능도 갖췄다며, 이 터미널들이 가져다주는 게 뭔지 모르겠다는 댓글이 가장 많은 답글(30개)을 받았다.
• iTerm2를 쓰는 한 사용자는 맥북 M1에서 1.4를 직접 돌려 봤지만 체감 속도 차이가 없다고 했다. 다른 사용자는 Ghostty·Rio·WezTerm을 각각 한 달쯤 쓰다 작은 불편이 쌓여 iTerm2로 돌아왔다고 했다.
• Kitty의 힌트 모드(화면의 링크나 경로에 글자 표식을 붙여 키보드로 고르는 기능) 때문에 못 넘어온다는 사용자도 있었다.
• 예전에 Ghostty로 SSH 접속하면 이상한 동작이 있었는데 이번 릴리스가 해결했을지 모른다는 댓글이 있었고, 위의 +ssh 항목과 맞닿아 있다.
• 터미널에 AI 기능이 들어올까 걱정된다는 댓글도 있었다.
• 터미널에서 이미지를 띄우는 방법을 클로드 코드에 가르쳐, 화면 구석에 그림을 그려 보게 했다는 사용자도 있었다. 위의 Kitty 그래픽이 이런 용도로 쓰인다.
• mitchellh 계정은 이번 노트가 GUI 앱 얘기라서 따로 짚는다며 libghostty 진전을 강조했다. 노트에 따르면 libghostty-vt는 macOS, 리눅스, 윈도우, FreeBSD, 안드로이드, iOS, 웹어셈블리를 겨냥해 빌드되고 CI가 매번 확인한다.

속도 얘기에는 접근 순서가 있다. 5.7배라는 숫자는 부품 시험이고, 체감 속도는 쓰는 사람마다 갈렸다. 반면 보안 권고는 체감과 무관하게 영향 버전만 보면 된다. 그래서 이 글은 업데이트 이유를 속도에 두지 않는다.

오늘 해 볼 일 넷

1. 버전을 본다. 앱 정보 창이나 설치한 패키지 관리자에서 확인한다. 홈브루로 깔았다면 brew list --versions ghostty로 나온다. 1.3.1 이하면 위 보안 표에 해당한다.
2. 올릴 수 있으면 1.4.0으로 올린다. 리눅스는 GTK가 4.18 이상인지 먼저 본다. pkg-config --modversion gtk4로 확인한다.
3. 설정을 만져 뒀다면 copy-on-select와 Cmd+화살표 키 지정을 다시 본다. 예전 동작을 원하면 위 표의 값으로 적는다.
4. 습관 둘은 업데이트와 무관하게 유효하다. 내용을 모르는 저장소는 cd로 들어가기 전에 한 번 열어 보고, 출처를 모르는 명령은 붙여넣기 전에 편집기에 먼저 붙여서 눈으로 본다.

이 글이 직접 해 보지 않은 것

이 글이 한 일은 노트를 읽고 권고 목록과 맞춰 본 것까지다. 그래서 확실한 결론은 하나다. 버전부터 확인하고, 1.3.1 이하면 올린다. 속도가 얼마나 빨라졌는지는 자기 맥에서 cat 시험 한 번이 가장 정확하다. 지금 쓰는 터미널은 어떤 버전인지 한번 열어 보자.

관련 글로는 비슷하게 “회사가 잰 속도 숫자의 조건”을 따져 본 tsrs 타입스크립트 러스트판 글과, 개발 도구 공급망 문제를 다룬 LiteLLM 악성 버전 글이 있다.