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

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

---

잘못 측정한 것

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

플러그인 매니저와 구문 강조에 대한 정정

• “플러그인 매니저는 오버헤드를 더한다”는 표현의 범위가 너무 넓었음

  • 일부 플러그인 매니저는 시작 시 자체 오버헤드와 의존성 해석을 추가함
  • 그러나 이 특성을 전체 플러그인 매니저 범주에 적용한 것은 부정확함
  • antidote는 플러그인의 단순 목록을 단일 정적 스크립트로 컴파일하고, 셸을 열 때 의존성 해석을 하지 않음
  • antidote 방식은 직접 작성한 source 줄처럼 생성된 파일 하나를 source하는 구조임
  • 더 정확한 구분은 매번 시작 시 플러그인을 해석하는 무거운 프레임워크는 느리고, 최신 정적 번들링 매니저는 그렇지 않다는 점임
  • 최신 정적 번들링 매니저는 업데이트 관리도 제공하며, 직접 만든 설치 스크립트는 이를 수작업으로 처리함

• 느린 구문 하이라이터를 추천했음

  • 입력 지연을 다룬 설정에서 zsh-syntax-highlighting을 source한 점은 뒤늦게 보면 부끄러운 선택임
  • zsh-syntax-highlighting은 키 입력마다 전체 버퍼를 다시 강조하며, 긴 명령줄에서는 바로 그 키 입력별 지연을 만들 수 있음
  • Zsh-patina는 더 새로운 접근이며, 긴 명령을 입력하는 경우 현재 사용 중인 도구보다 더 나은 체감을 줄 수 있음

• 남는 주장의 핵심

  • 전체 .zshrc를 한 번에 읽을 수 있다는 점이 실제로 선호되는 부분임
  • 프레임워크가 대신 결정하지 않고, 선택하지 않은 플러그인이 없다는 점이 핵심임
  • 구성 요소가 적기 때문에 느린 부분이 생기면 찾기 쉬움
  • 이 선택은 속도 자체보다 단순성에 대한 선호이며, 단순성이 빠른 속도로 이어지는 것은 부수 효과임
  • 기능을 모두 갖춘 셸도 빠르고 즉각적으로 느껴질 수 있으며, 그 목표에 도달하는 방법은 여러 가지임
  • 최소 설정은 빠른 속도의 유일한 길이어서가 아니라 이해하고 싶기 때문에 유지하는 선택임

• 마무리

  • 원래 글은 상단에 이 글을 가리키는 메모가 붙은 상태로 유지됨
  • 설정은 여전히 dotfiles에 있으며, 구문 하이라이터도 그대로 남아 있음
  • 일부 설정은 더 최신 도구를 쓰도록 업데이트될 예정임

[GN⁺]

Lobste.rs 의견들

• 커뮤니티와 아이디어 교환의 힘을 보여주는 좋은 후속 글이라, 인터넷을 조금 더 인간적으로 느끼게 해줌

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

• 이런 글이 좋음. 더 많은 사람이 실수와 후속 정정을 공개하면 인터넷이 조금 더 인간적인 공간이 됨

  • 작성자임. 고맙고, 특히 팀에 본보기가 되기 위해 실수 인정을 꾸준히 하려고 노력함

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

• 더 이상 유지보수되지는 않지만 zsh4humans는 성능 면에서 최첨단에 가까움. 만든 사람이 일종의 Zsh 천재 같음
  직접 쓰지는 않는데, 통제권을 유지하고 싶기 때문임. 그래도 이해할 수 있는 부분에서는 transient prompt 같은 아이디어를 가져다 썼음
  zsh-bench도 같은 작성자의 프로젝트인 줄은 몰랐음

  • 좋은 팁임. zsh4humans 프로젝트에 진짜 보석 같은 부분이 있어 보이니 확인해보겠음

• 이 글 덕분에 zsh-patina를 알게 됨
  몇 년 동안 zsh-fast-syntax-highlighting을 써왔는데, 이 새 도구도 평가해봐야겠음

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

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