Ghostty 1.4의 스크롤백 압축, 보관 한도와 검색 비용을 함께 본다

오래 켜 둔 터미널에는 지금 보는 화면보다 훨씬 많은 출력이 남는다. 지나간 빌드 오류를 다시 찾으려면 기록이 필요하지만, 탭마다 기록을 늘리면 메모리도 함께 쓴다. Ghostty 1.4는 화면 밖의 기록을 압축해 이 관계를 바꾼다. 다만 “메모리 70~90% 절감”을 앱 전체의 절감률로 읽거나, 압축을 이유로 기록 한도를 없애면 도입 판단이 어긋난다.

Ghostty 1.4.0의 공식 출시일은 2026년 10월 27일이며, GeekNews에는 28일 오전 3시 41분, 한국 시각으로 등록됐다. 아래는 릴리스 노트와 구현 제안을 읽은 분석이다. Ghostty를 설치하거나 성능을 직접 측정하지 않았다.

줄어드는 것은 화면 밖 페이지의 물리 메모리다

스크롤백은 현재 화면 위로 지나간 출력을 다시 볼 수 있도록 보관하는 기록이다. 1.4는 보이지 않는 기록 페이지를 터미널이 쉬는 동안 압축하고, 스크롤하거나 검색할 때 필요한 페이지를 푼다. 개발팀은 일반적인 텍스트 위주의 기록에서 해당 페이지의 물리 메모리를 70~90% 줄였다고 보고한다. 전체 프로세스나 실행 중인 셸의 메모리를 그만큼 줄인다는 뜻은 아니다. 측정 대상과 지원 범위

메모리 표시를 읽는 방법도 달라진다. 압축 구현 제안은 가상 주소 공간을 유지하면서 운영체제에 물리 메모리를 반환한다고 설명한다. 가상 메모리는 프로세스가 사용할 주소 공간이고, 상주 메모리는 현재 물리 메모리에 올라와 있는 부분이다. 주소를 계속 확보해 두므로 압축을 풀 때 그 공간을 다시 사용할 수 있다. 가상 메모리 숫자가 그대로라는 이유로 압축이 작동하지 않는다고 판단하면 안 된다.

제안은 LZ4 방식의 압축을 사용한다고 밝힌다. 그 안의 상세 측정은 gh --help 출력을 반복한 7.3MB 자료를 120×80 터미널에 넣은 사례다. 약 49.56MB의 페이지가 약 3.03MB로 줄었지만, 작성자도 반복이 많은 입력이라 일반적인 기록보다 잘 압축됐다고 명시한다. 이 결과를 우리 로그의 예상치로 가져오기는 어렵다. 실험 조건과 한계

내가 주목한 부분은 오래 보관하되 자주 읽지 않는 데이터에 비용을 덜 쓰는 선택이다. 반대로 과거 기록을 계속 검색하는 작업이라면 압축 해제가 자주 필요할 수 있다. 릴리스가 보고한 입출력 처리량 저하 없음은 그런 작업의 검색 지연까지 없다는 보장이 아니다.

압축률과 기록 보관 한도는 다른 결정이다

압축에 맞춰 기본 스크롤백 한도는 터미널당 10MB에서 50MB로 늘었다. 개발팀은 압축 지원 환경에서 가득 찬 기록도 대체로 이전 한도보다 적은 물리 메모리를 쓴다고 설명한다. 기본값 변경 따라서 이전 버전과 새 버전을 기본값 그대로 비교하면 압축 방식뿐 아니라 보관량도 함께 바뀐다.

설정에는 두 기준이 생겼다. 기존 scrollback-limit는 scrollback-limit-bytes로 이름이 바뀌었고, scrollback-limit-lines가 추가됐다. 이전 이름도 호환용으로 동작한다. 둘을 함께 설정하면 먼저 도달한 한도가 적용된다. 설정 변경의 의미

줄 수가 같아도 메모리는 같지 않다. 구현 제안은 줄 수가 화면 크기의 영향을 받고, 바이트 사용량은 스타일과 문자 구성 등의 영향을 받는다고 설명한다. 예를 들어 창 너비를 바꿔 줄바꿈이 달라지는 기록과, 색상 정보가 많은 출력은 서로 다른 조건이다. “몇 줄을 남길 것인가”와 “어느 정도 자원을 쓸 것인가”를 함께 정할 이유다.

나는 압축을 켰다는 이유로 unlimited부터 선택하지 않겠다. 탭과 기록이 계속 늘면 압축된 상태의 비용도 누적된다. 먼저 되돌아볼 범위를 정하고, 오래 보존해야 하는 빌드·작업 결과는 별도 로그 파일로 남기는 방법을 비교하겠다. 터미널의 탐색 편의와 장기 기록 보존을 같은 기능에 모두 맡길 필요는 없다.

Ghostty 앱의 자동 압축이 내장 라이브러리까지 자동은 아니다

현재 압축 지원은 macOS와 64비트 Linux다. Ghostty GUI의 Windows 지원 계획은 철회됐으며, 프로젝트는 Windows에서 libghostty를 활용하는 다른 앱을 지원하는 방향을 밝혔다. 코어 라이브러리가 Windows를 지원한다는 사실과 공식 GUI를 Windows에서 사용할 수 있다는 사실은 구분해야 한다. 플랫폼별 상태

터미널을 제품에 내장하는 개발자에게는 한 가지 조건이 더 있다. 압축 API 설명에 따르면 libghostty 사용자는 호스트 앱에서 언제 쉬고 있는지 판단하고 점진적 압축 API를 호출해야 한다. 필요한 페이지의 압축 해제는 자동이지만, 압축을 시작하는 정책까지 라이브러리가 대신 정하지는 않는다.

이를 IDE에 붙인다면 보이지 않는 패널도 계속 출력을 받을 수 있고, 사용자가 잠시 타이핑하지 않는다는 사실만으로 터미널 처리가 한가하다고 볼 수도 없다. 어떤 활동을 기준으로 압축을 미루고 한 번에 얼마나 처리할지 호스트의 실행 구조에 맞춰 정해야 한다는 것이 내 해석이다.

libghostty는 별도 출시 주기를 따르며 API·ABI 안정화도 아직 계획 단계다. 릴리스 노트는 이번 개발 주기에도 호환성이 여러 번 바뀌었고 정식 태그 전 추가 변경을 예상한다고 설명한다. 공식 저장소는 MIT 라이선스를 명시하지만, 라이선스가 허용하는 사용 범위와 인터페이스를 따라가는 유지보수 비용은 별개의 문제다. Ghostty 1.4의 성능 수치만 보고 내장 터미널에서도 같은 효과를 기대해서는 안 된다.

비교는 같은 기록과 같은 한도에서 시작한다

이전 Rune 글에서는 터미널 출력 처리량과 편집 반응성을 나눠 봤다. 이번에는 기록이 쌓인 뒤의 상태 전환을 더해 보겠다. 아래는 직접 수행한 결과가 아니라, 업데이트나 라이브러리 도입 전에 사용할 비교 기준이다.

관찰할 순간	확인할 항목
같은 출력을 채운 직후와 유휴 시간 뒤	상주 메모리 변화, 압축 작업의 CPU 사용
오래된 기록을 처음 스크롤·검색할 때	첫 응답 지연과 반복 검색 지연, 결과의 정확성
탭을 늘리고 기록을 지운 뒤	전체 자원 증가, 해제된 메모리의 반환

먼저 운영체제와 버전, 창 크기, 탭 수, 입력 자료와 보관 한도를 고정한다. 압축 자체의 효과를 볼 때는 1.4에서 압축 설정만 바꿔 비교하고, 실제 사용 판단에서는 새 기본값을 쓴 결과도 따로 남긴다. 압축 기능은 scrollback-compression으로 끌 수 있다. 비교에 사용할 설정

업데이트의 전제 조건도 확인한다. macOS는 13 이상을 유지하지만, GTK 앱은 GTK 4.18·libadwaita 1.7 이상을 요구해 Ubuntu 24.04 LTS의 기본 환경과 맞지 않는다. Linux·FreeBSD의 새 렌더러는 EGL을 쓰며, 드라이버가 DMABUF를 내보내지 못하면 더 느린 CPU 복사 경로를 사용한다. macOS에서는 선택 시 자동 복사 기본값도 바뀐다. 시스템 요구와 동작 변경

긴 출력과 여러 탭 때문에 메모리 부담이 있던 개발자라면 이번 변경을 시험할 이유가 있다. 기존 Ghostty 사용자에게는 악성 터미널 출력과 붙여넣기 관련 보안 수정도 업데이트 근거다. 수정 목록 다만 좋은 결과의 기준은 가장 작은 메모리 숫자가 아니다. 필요한 기록을 남기고, 다시 찾는 시간이 허용 범위에 들며, 쓰는 플랫폼에서 일상 작업이 이어지는가를 함께 보겠다.

참고 자료

• Ghostty 1.4.0 릴리스 노트
• terminal: scrollback page compression — PR #13264
• Introduce scrollback-limit-lines — PR #13473
• Ghostty 공식 저장소