빠른 셸에 대해 내가 틀렸던 것 — zsh-bench가 말하는 진짜 병목

zsh-bench로 본 셸 시작 지연

빠른 셸에 대해 내가 틀렸던 것 — zsh-bench가 말하는 진짜 병목

터미널이 느리다는 느낌이 어디서 오는지 한 번이라도 고민해 본 적이 있는가. 셸을 열면 첫 키 입력까지 눈에 띄는 지연이 따라붙고, 그 지연이 반복되면 작업 흐름이 끊긴다. 원인은 .zshrc의 절대 길이 자체라기보다 측정 방식과 도구 선택에 있다. mijdertstuij.nl의 후속 글은 이 부분을 솔직하게 인정하면서, zsh-bench 관점에서 셸 시작 지연을 다시 정리한 내용을 담고 있다. 빠르고 즉각적인 셸 구성에 대해 내가 틀렸던 부분을 공유하고, 그 정정 과정을 함께 보여주는 글로, 단순성과 즉각성을 함께 잡는 방법에 대한 좋은 참고가 된다. 첫 글을 보고 zshrc를 최적화해 시간을 절반으로 줄였다는 반응이 댓글에 실린 만큼 실용성 면에서도 검증된 주제다.

zsh-bench가 보는 체감 지연

기존의 time zsh -i -c exit는 초기화와 종료를 한 묶음으로 잰다는 한계가 있다. 이 방식은 흔히 쓰이는 벤치마크지만, zsh-bench는 이 방식이 잘못된 이유를 별도 섹션으로 다룬다. zsh-bench는 다른 항목을 따로 본다. 첫 프롬프트가 뜨는 시간, 첫 명령이 실행되기까지의 시간, 명령 지연, 입력 지연까지 분리해 측정한다. 실제 사용자가 기다리는 것은 전체 초기화 시간이 아니라 프롬프트가 표시되는 순간과 키 입력의 반응성이다. 어떤 설정은 종료 시간 숫자로는 느리게 나와도 실제 사용에서는 더 빠르게 느껴질 수 있다. 그래서 숫자만 맹신해서는 안 되며, 체감 항목을 따로 보는 시각이 필요하다. 사용자가 셸을 어떻게 사용하는지를 먼저 이해해야 한다.

instant prompt의 의미

instant prompt는 셸이 시작되자마자 캐시된 프롬프트를 즉시 보여주는 기법이다. .zshrc가 아직 로드 중이어도 입력이 가능하도록 만들어 주기 때문에, 이 기법이 적용되면 초기화 비용과 무관하게 체감 시작 시간이 거의 0에 가까워진다. 종료 시간 숫자의 의미가 자연스럽게 줄어든다. 사용자는 "느낌"으로 셸을 평가하기 때문이다. instant prompt는 이 느낌을 거의 무료로 만들어 준다. 캐시된 프롬프트가 먼저 보이고, 백그라운드에서 무거운 초기화가 진행되는 구조다. zsh4humans 같은 도구에서 이 패턴을 찾아볼 수 있으며, 직접 괴물 같은 프롬프트를 만들고 허술하게 캐싱해 본 경험이 있는 사람이라면 더 와닿을 것이다.

플러그인 매니저에 대한 정정

모든 플러그인 매니저가 느리다고 단정하는 것은 부정확하다. 일부 매니저는 시작 시 의존성 해석을 추가하지만, antidote는 동작 방식이 다르다. 플러그인 목록을 단일 정적 스크립트로 컴파일해 두고, 셸을 열 때는 그 파일 하나만 source한다. 의존성 해석이 매번 일어나지 않기 때문에 시작 오버헤드가 작다. 직접 작성한 source 줄과 거의 같은 구조라 보면 된다. 무거운 프레임워크와 정적 번들링은 구분해야 하며, 이 차이가 체감 속도를 가른다. 정적 번들링 매니저는 업데이트 관리 기능도 함께 제공하므로, 수작업 설치 스크립트보다 운영 면에서도 유리하다. 새 도구로 갈아탈 때도 마이그레이션 부담이 작다.

느린 구문 하이라이터 문제

zsh-syntax-highlighting은 키 입력마다 전체 버퍼를 다시 강조한다. 긴 명령줄에서는 그 지연이 그대로 입력 지연으로 이어진다. 더 새로운 대안은 zsh-patina다. 키 입력 반응성을 우선시하는 접근이며, 긴 명령을 입력하는 경우 기존 도구보다 더 나은 체감을 줄 수 있다. 짧은 명령이 많은 일상 흐름에서도 두 도구의 차이는 분명하게 드러난다. 명령이 길어질수록 효과가 커진다는 점이 특징이다. 입력 지연이 누적되면 결국 사용자가 체감하는 시간이 눈에 띄게 늘어난다. 직접 비교해 보면 그 차이는 분명하며, 몇 년 동안 zsh-fast-syntax-highlighting을 써온 사람도 새 도구로 갈아탈 이유가 충분하다.

단순성을 고수하는 이유

최소 설정을 유지하는 이유는 속도만이 아니다. .zshrc를 한 번에 읽을 수 있다는 점, 그리고 선택하지 않은 플러그인이 없다는 점이 실제로 중요하다. 구성 요소가 적으면 느린 지점을 찾기 쉽고, 프레임워크가 대신 결정하지 않는다는 점도 장점이다. 기능을 모두 갖춘 셸도 즉각적으로 느껴질 수 있으며, 그 길은 여러 가지다. 단순성은 그 자체로 가치가 있고, 그 단순성이 결국 빠른 셸로 이어진다. 속도는 단순성을 유지하면서 얻는 부수 효과에 가깝다는 것이 원문의 주장이다. 구성 요소가 적다는 점이 디버깅 시간을 줄여 주며, 새로운 도구를 추가할 때의 심리적 비용도 낮춘다.

그래서 우리도 따라 할 수 있는가

zsh-bench로 현재 셸을 측정해 보는 것이 첫걸음이다. instant prompt를 적용하고, 구문 하이라이터를 zsh-patina로 교체해 본다. 플러그인 매니저는 정적 번들링 방식으로 전환한다. 이 세 가지만 바꿔도 체감 시작 시간이 달라진다. 한 줄 설정이 쌓이는 곳이 결국 일의 속도를 만든다는 점을 기억해 두면 좋다. 작은 개선이 모여 큰 차이를 만드는 셈이다. 측정을 멈추지 않는 것이 핵심이며, 본문 정정 과정 자체가 우리에게도 좋은 참고가 된다. 매일 셸을 여는 개발자라면 이런 작은 개선이 누적되어 큰 영향을 준다는 점을 기억해 둘 만하다. 우선순위를 정해 보면, instant prompt 적용이 비용 대비 효과가 가장 크다. 다음으로 구문 하이라이터 교체, 마지막으로 플러그인 매니저 정적 번들링 순서로 진행하면 무리 없이 체감 속도를 끌어올릴 수 있다. 마지막으로 한 가지 더, 자신의 .zshrc를 정기적으로 다시 읽는 습관을 들이면 불필요한 항목이 눈에 들어온다. 시간이 지나면서 누적된 별칭과 함수가 체감 속도를 무겁게 만들 수 있기 때문이다. 한 줄 더 추가하자면, 도구 변경 후 며칠간 직접 체감한 지연 시간을 기록해 두면 다음 최적화 단계에서 비교 기준으로 삼을 수 있다. 체감 시간은 숫자보다 직관적이라, 작은 개선의 효과가 누적되었는지 판단하는 데 큰 도움이 된다. 도구 변경은 한 번에 하나씩 진행해 봐야 각각의 효과를 분리해서 체감할 수 있다. 이런 작은 과정을 쌓아가면, 결국 매일 마주하는 셸이 더 즐거워지는 결과로 이어진다. 한 줄로 정리하면, 단순성과 즉각성을 함께 잡는 것이 핵심이다. 본문 정정 과정이 우리에게도 같은 메시지를 남긴다. 실용성을 함께 챙기자고 싶다.