# 빠른 터미널에 대해 내가 틀렸던 것

> Clean Markdown view of GeekNews topic #30353. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30353](https://news.hada.io/topic?id=30353)
- GeekNews Markdown: [https://news.hada.io/topic/30353.md](https://news.hada.io/topic/30353.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-10T14:01:03+09:00
- Updated: 2026-06-10T14:01:03+09:00
- Original source: [mijndertstuij.nl](https://mijndertstuij.nl/posts/what-i-got-wrong-about-fast-terminals/)
- Points: 1
- Comments: 1

## Topic Body

- 빠른 셸 구성은 최소 설정만으로 달성되는 것이 아니며, 최신 Zsh 도구는 **체감 시작 속도**를 다른 방식으로 개선함
- `time zsh -i -c exit`는 초기화와 종료 시간을 함께 재지만, 실제 사용자가 기다리는 지점은 **첫 프롬프트**, 첫 명령 실행, 입력 지연임
- zsh-bench는 첫 프롬프트 시간, 첫 명령 실행 시간, 명령 지연, 입력 지연처럼 실제 체감 항목을 측정함
- 플러그인 매니저가 항상 느린 것은 아니며, antidote는 플러그인 목록을 단일 정적 스크립트로 컴파일해 시작 시 의존성 해석을 하지 않음
- 최소 설정은 빠른 속도의 유일한 길이 아니라 **이해 가능한 단순성**을 위한 선택이며, 기능을 갖춘 셸도 즉각적으로 느껴질 수 있음

---

### 잘못 측정한 것
- `time zsh -i -c exit`는 대화형 셸을 시작한 뒤 즉시 종료하는 방식이며, 전체 초기화 시간과 종료 시간을 함께 측정함
- 이 방식은 흔히 쓰이는 벤치마크지만, [zsh-bench](https://github.com/romkatv/zsh-bench#how-not-to-benchmark)는 이 방식이 잘못된 이유를 별도 섹션으로 다룸
- 실제 사용자가 기다리는 것은 전체 초기화 시간이 아니라 프롬프트 표시, 첫 명령 실행, 이후 모든 키 입력의 지연임
- 어떤 설정은 이 벤치마크에서 느리게 나와도 실제 사용에서는 더 빠르게 느껴질 수 있음
- [zsh-bench](https://github.com/romkatv/zsh-bench)는 첫 프롬프트 시간, 첫 명령 실행까지의 시간, 명령 지연, 입력 지연을 측정함
- [instant prompt](https://github.com/romkatv/zsh-bench#instant-prompt)는 셸 시작 순간 캐시된 프롬프트를 렌더링하고, `.zshrc` 완료 전에도 입력을 가능하게 함
- instant prompt가 적용되면 초기화 비용과 상관없이 체감 시작 시간이 거의 0에 가까워져 종료 시간 숫자의 중요성이 낮아짐

### 플러그인 매니저와 구문 강조에 대한 정정
- ## “플러그인 매니저는 오버헤드를 더한다”는 표현의 범위가 너무 넓었음
  - 일부 플러그인 매니저는 시작 시 자체 오버헤드와 의존성 해석을 추가함
  - 그러나 이 특성을 전체 플러그인 매니저 범주에 적용한 것은 부정확함
  - [antidote](https://github.com/mattmc3/antidote)는 플러그인의 단순 목록을 단일 정적 스크립트로 컴파일하고, 셸을 열 때 의존성 해석을 하지 않음
  - antidote 방식은 직접 작성한 `source` 줄처럼 생성된 파일 하나를 source하는 구조임
  - 더 정확한 구분은 매번 시작 시 플러그인을 해석하는 무거운 프레임워크는 느리고, 최신 정적 번들링 매니저는 그렇지 않다는 점임
  - 최신 정적 번들링 매니저는 업데이트 관리도 제공하며, 직접 만든 설치 스크립트는 이를 수작업으로 처리함
- ## 느린 구문 하이라이터를 추천했음
  - 입력 지연을 다룬 설정에서 `zsh-syntax-highlighting`을 source한 점은 뒤늦게 보면 부끄러운 선택임
  - `zsh-syntax-highlighting`은 키 입력마다 전체 버퍼를 다시 강조하며, 긴 명령줄에서는 바로 그 키 입력별 지연을 만들 수 있음
  - [Zsh-patina](https://github.com/michel-kraemer/zsh-patina)는 더 새로운 접근이며, 긴 명령을 입력하는 경우 현재 사용 중인 도구보다 더 나은 체감을 줄 수 있음
- ## 남는 주장의 핵심
  - 전체 `.zshrc`를 한 번에 읽을 수 있다는 점이 실제로 선호되는 부분임
  - 프레임워크가 대신 결정하지 않고, 선택하지 않은 플러그인이 없다는 점이 핵심임
  - 구성 요소가 적기 때문에 느린 부분이 생기면 찾기 쉬움
  - 이 선택은 속도 자체보다 단순성에 대한 선호이며, 단순성이 빠른 속도로 이어지는 것은 부수 효과임
  - 기능을 모두 갖춘 셸도 빠르고 즉각적으로 느껴질 수 있으며, 그 목표에 도달하는 방법은 여러 가지임
  - 최소 설정은 빠른 속도의 유일한 길이어서가 아니라 이해하고 싶기 때문에 유지하는 선택임
- ## 마무리
  - 원래 글은 상단에 이 글을 가리키는 메모가 붙은 상태로 유지됨
  - 설정은 여전히 [dotfiles](https://github.com/mijndert/dotfiles)에 있으며, 구문 하이라이터도 그대로 남아 있음
  - 일부 설정은 더 최신 도구를 쓰도록 업데이트될 예정임

## Comments



### Comment 59334

- Author: neo
- Created: 2026-06-10T14:01:04+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/pf0tx3/what_i_got_wrong_about_fast_terminals) 
- 커뮤니티와 아이디어 교환의 힘을 보여주는 좋은 후속 글이라, 인터넷을 조금 더 인간적으로 느끼게 해줌

- 오류를 인정하고 고치는 일이 가능하다니 놀랍다는 반응이 먼저 나옴  
  진지하게는, 여러 새 셸을 별로 좋아하지 않아 첫 글은 넘겼지만 이번 글은 좋았음. `ash`는 기본 히스토리 동작이 내 사용 방식과 맞지 않고, `fish` 같은 셸은 관심 없는 **UI 기능**이 과하다고 느꼈음  
  다만 자동 **프롬프트 캐시**처럼 보이는 기능은 좋아 보임. 직접 괴물 같은 프롬프트를 만들고 허술하게 캐싱해본 적이 있어서 더 와닿음

- 이런 글이 좋음. 더 많은 사람이 실수와 후속 정정을 공개하면 인터넷이 조금 더 인간적인 공간이 됨
  - 작성자임. 고맙고, 특히 팀에 본보기가 되기 위해 **실수 인정**을 꾸준히 하려고 노력함

- 첫 글을 보고 이미 `zshrc`를 최적화해서 시간을 절반으로 줄였음. 이후 더 찾아보다가 `zsh-bench`도 썼고, 그 글이 **최적화 계기**가 되어줌

- 더 이상 유지보수되지는 않지만 [zsh4humans](https://github.com/romkatv/zsh4humans)는 성능 면에서 최첨단에 가까움. 만든 사람이 일종의 **Zsh 천재** 같음  
  직접 쓰지는 않는데, 통제권을 유지하고 싶기 때문임. 그래도 이해할 수 있는 부분에서는 [transient prompt](https://vincent.bernat.ch/en/blog/2021-zsh-transient-prompt) 같은 아이디어를 가져다 썼음  
  `zsh-bench`도 같은 작성자의 프로젝트인 줄은 몰랐음
  - 좋은 팁임. `zsh4humans` 프로젝트에 진짜 보석 같은 부분이 있어 보이니 확인해보겠음

- 이 글 덕분에 [`zsh-patina`](https://github.com/michel-kraemer/zsh-patina)를 알게 됨  
  몇 년 동안 [`zsh-fast-syntax-highlighting`](https://github.com/zdharma-continuum/fast-syntax-highlighting)을 써왔는데, 이 새 도구도 평가해봐야겠음

- `zsh-syntax-highlighting`이 매 키 입력마다 전체 버퍼를 다시 강조해서 지연을 만든다는 부분이 실제로 눈에 띄는지 궁금함  
  코드 편집기에서도 본질적으로 비슷한 일을 하는데 지연을 거의 못 느꼈음. 명령줄은 편집기 기준으로 보면 “긴” 명령도 대체로 짧으니 문제가 생긴다는 게 의외임  
  다만 **구문 강조**가 생각보다 훨씬 복잡하다면 그럴 수도 있겠음

- 이 글에서 새 요령을 많이 배움. 지금까지는 프롬프트에 들어가는 데이터가 느린 백엔드에서 오지 않게 하는 정도의 단순한 수정만 해왔음  
  여기에는 훨씬 더 세밀한 **프롬프트 최적화**가 들어 있고, 터미널을 셀 수 없이 많이 여는 일상 흐름에서는 이런 작은 개선이 누적되어 큰 영향을 줌