Life is too short for a slow terminal

터미널을 매일 장시간 쓰는 사람의 성능 튜닝 노트. 핵심은 “무엇을 더하느냐”보다 “무엇을 뺄 수 있느냐”에 가깝다.

핵심 요약

  • 본문은 startup time, prompt lag, input latency 세 가지 지연을 분리해서 봐야 한다고 정리한다.
  • 빠른 셸의 핵심은 거대한 프레임워크를 쓰지 않고, 꼭 필요한 플러그인만 직접 로드하는 것이다.
  • compinit는 캐시(.zcompdump)가 24시간 이내면 -C로 건너뛴다.
  • nvm, kubectl completion 같은 무거운 작업은 lazy-loading 패턴으로 늦게 불러온다.
  • pure처럼 비동기 프롬프트를 써서 git status로 인한 입력 지연을 줄인다.
  • 터미널 에뮬레이터도 중요하며, 글에서는 Ghosttytmux alias(t) 조합을 사용한다.

실전 레시피

1) shell startup 줄이기

  • oh-my-zsh / prezto / plugin manager 같은 프레임워크를 배제한다.
  • 플러그인은 fzf-tab, zsh-autosuggestions, zsh-syntax-highlighting 정도만 유지한다.
  • compinit는 매 실행마다 돌리지 않고 캐시를 활용한다.

2) 느린 도구는 lazy-load

  • nvm은 함수 stub으로 두고 첫 호출 때 실제 스크립트를 source한다.
  • kubectl completion도 실제로 kubectl을 쓴 뒤에만 불러온다.
  • eval "$(tool init zsh)" 형태는 기본적으로 startup 비용이 있는 후보로 본다.

3) prompt lag 제거

  • git status 동기 실행은 큰 저장소에서 체감 지연을 만든다.
  • pure처럼 async로 git 정보를 채우는 prompt가 더 낫다.
  • prompt가 느리면 shell startup이 빨라도 체감은 나빠진다.

4) 측정부터 하기

  • time zsh -i -c exit
  • hyperfine --warmup 3 'zsh -i -c exit'
  • zmodload zsh/zprof + zprof
  • zsh -ixc exit 2>&1 | ts -i '%.s' | sort -rn | head -20

남는 판단 기준

  • 터미널은 하루 종일 보는 도구이므로, 수십 ms 차이도 누적되면 크다.
  • “내가 자주 쓰는 것만 남기고 나머지는 늦게 불러오기”가 이 글의 핵심이다.
  • shell은 fast, prompt는 async, emulator는 native/gpu acceleration 쪽이 균형이 좋다.

관련 노트