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

• 빠른 셸 구성은 최소 설정만으로 달성되는 것이 아니며, 최신 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에 있으며, 구문 하이라이터도 그대로 남아 있음
  • 일부 설정은 더 최신 도구를 쓰도록 업데이트될 예정임