▲

Oh My Zsh는 불필요한 부하를 추가함

 (rushter.com)
14P by GN⁺ 1일전 | ★ favorite | 댓글 8개
  • Oh My Zsh(OMZ) 는 여전히 널리 추천되지만, 셸 시작 시간을 느리게 만드는 불필요한 스크립트 부하를 초래함
  • OMZ는 셸 스크립트로 작성되어 새 터미널 탭을 열 때마다 모든 스크립트를 해석해야 하며, 기본 설정만으로도 약 0.38초의 지연이 발생
  • 단순한 Zsh 최소 설정과 Starship 프롬프트, fzf 기반 히스토리 검색을 사용하면 시작 시간을 0.07초로 단축 가능
  • Starship은 하나의 바이너리로 프롬프트를 구성해, 기존 OMZ의 git·가상환경·언어별 플러그인을 대체함
  • 복잡한 플러그인보다 필요한 기능만 직접 추가하는 경량화된 셸 구성이 효율적임

Oh My Zsh의 성능 문제

  • Oh My Zsh(OMZ) 는 여전히 많이 사용되지만, 불필요한 부하(bloat) 로 인해 셸 시작 속도를 저하시킴
    • OMZ는 셸 스크립트로 구성되어 새 터미널 탭을 열 때마다 모든 스크립트를 해석해야 함
    • 기본 플러그인(git, zsh-autosuggestions, zsh-autocomplete)을 포함한 설정에서 /usr/bin/time -f "%e seconds" zsh -i -c exit 실행 결과 0.38초 소요
  • git 리포지토리 폴더에서 새 탭을 열면 체감상 약 1초의 지연이 발생
  • OMZ는 주기적으로 업데이트를 확인하며, 이 과정이 몇 초의 추가 지연을 유발
  • 셸 설정의 잦은 업데이트는 불필요하며, 필요한 기능만 직접 추가하는 단순한 구성이 권장됨

최소 Zsh 설정

  • 제안된 최소 Zsh 설정은 다음과 같음 
    export HISTSIZE=1000000000
export SAVEHIST=$HISTSIZE
setopt EXTENDED_HISTORY
setopt autocd
autoload -U compinit; compinit
    • HISTSIZE와 SAVEHIST는 명령어 히스토리 크기 지정
    • EXTENDED_HISTORY는 히스토리에 타임스탬프 추가
    • autocd는 cd 명령 없이 디렉터리 이동 가능
    • compinit은 자동 완성 시스템 초기화
  • 이 설정만으로도 완성 기능이 포함된 기본적인 셸 환경 제공

프롬프트 커스터마이징

  • 프롬프트는 Starship을 사용
    • Starship은 하나의 바이너리로 구성된 빠르고 최소한의 프롬프트
    • 기존 OMZ의 플러그인 및 테마를 대체하며, git·가상환경·언어별 상태를 표시
  • Starship 설정 예시에서는 AWS, GCP, Azure, NodeJS 등 클라우드 관련 표시를 비활성화해 시각적 잡음을 줄임
  • Python과 Rust 프로젝트에서 각각의 언어가 프롬프트에 강조 표시되며, 명령 실행 시간도 표시
  • .zshrc에 다음 한 줄을 추가해 활성화 
    eval "$(starship init zsh)"

히스토리 검색

  • 일반적으로 사용되는 zsh-autosuggestions 플러그인은 입력 중 제안이 표시되어 주의를 분산시킬 수 있음
  • 대신 fzf를 Ctrl+R에 바인딩해 대화형 퍼지 검색(fuzzy search) 으로 히스토리를 탐색 
    source <(fzf --zsh)

성능 개선 결과

  • 위 설정 적용 후 셸 시작 시간은 다음과 같음 
    ❯ /usr/bin/time -f "%e seconds" zsh -i -c exit
0.07 seconds
  • OMZ 대비 약 5배 이상 빠른 시작 속도 확보

추가 팁

  • Vim 사용자는 Zsh에서 Vim 모드를 활성화해 명령 편집 속도를 향상 가능 
    set -o vi
bindkey -v '^?' backward-delete-char
    • zle은 기본적으로 Emacs 키 바인딩을 사용하므로, 이 설정으로 Vim 방식 입력 지원

결론 및 사용 사례

  • OMZ에서 전환한 후 며칠 만에 새로운 워크플로에 적응
  • 필요한 플러그인은 직접 수동 로드 가능
  • 다수의 탭을 여는 이유는 tmux와 터미널 기반 편집기(helix) 를 함께 사용하기 때문
    • tmux에서 lazygit과 yazi 파일 관리자를 팝업 형태로 실행
    • 코드 실행 및 테스트 출력을 위한 임시 분할 창을 사용, 각각이 별도 셸 세션으로 동작

댓글 요약

  • 일부 사용자는 OMZ의 시작 시간이 0.03초 수준으로 충분히 빠르다고 주장
  • 작성자는 zsh-autocomplete 플러그인이 속도를 저하시킨다고 지적
  • zsh-bench 결과에서 OMZ의 첫 프롬프트 지연 603ms, 단순 Zsh 설정은 103ms로 측정됨
  • Starship은 OMZ의 프롬프트 관련 기능을 단일 도구로 대체
  • 다른 사용자들은 Zimfw, Atuin, 직접 작성한 bash 프롬프트 등 대안을 언급
▲
tesha001 8시간전  [-]

아직 그렇게 눈에 띌만큼 불편한 느낌은 아니었는데.

답변달기
▲
princox 10시간전  [-]

웹 서버도 아니고, 불편을 느낄 정도가 아니면 그러려니 합니다..

답변달기
▲
zxcv123 1일전  [-]

개발자들 아니랄까봐 쓸데없는 몇 ms 가지고 난리부르스네 ㅋ

답변달기
▲
kayws426 2시간전  [-]

쓸데없는 몇 ms 때문에 기술이 발전하고 있는것 아니었습니까?

답변달기
▲
edunga1 8시간전  [-]

시작을 omz와 함께 시작해서, 감수하는 불편함인 줄 알았어요 ㅠㅠ
최근엔 플러그인을 하나씩 제거하고 업데이트 정책도 변경했는데.. 이걸 보니 없어도 되겠다 싶네요.
저는 tmuxinator로 설정 불러올 때 omz update y/n이 떠있으면 별로더라고요.

답변달기
▲
devfluotin 10시간전  [-]

몇 달 전에 prezto로 갈아탔는데 omz가 이렇게 느렸었나 싶긴 하더라고요
기본적인 플러그인 몇 개만 해도 확 느려져서...

답변달기
▲
t7vonn 1일전  [-]

터미널을 자주 사용한다면, omz로 인해 추가되는 지연이 상당히 불쾌합니다.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 나는 oh-my-zsh를 쓰는 이유가 단 하나임
    새 머신이나 원격 호스트, 컨테이너 어디서든 바로 쓸 수 있는 즉시 생산성 있는 셸 환경을 얻기 위함임
    설정을 직접 만지느라 몇 시간을 쓰기보단 그 시간을 더 중요한 일에 쓰고 싶음

    • Starship을 써보라고 권하고 싶음
      “설치 후 바로 사용” 경험은 그대로인데 200ms 이상의 프롬프트 지연이 없음
      curl 한 줄로 설치하고, 설정도 간단함
      써보면 후회하지 않을 거라 생각함
    • 만약 커스텀 설정을 허용하는 머신이라면, 직접 만든 dotfiles를 복사해 쓰는 게 더 낫다고 생각함
      한 번 구성 파일을 만들어 git으로 관리하면, 다른 머신에서도 그대로 쓸 수 있음
      나도 새 머신 세팅할 때 dotfiles만 가져오면 익숙한 환경이 바로 돌아옴
    • 사실 dotfiles가 그런 용도로 만들어진 거 아님?
      농담이지만, 기본 셸을 설치하는 것보다 .bashrc 복사하는 게 훨씬 간단함
    • 나도 Oh My Zsh를 썼지만, 너무 느려서 포기했음
      탭을 열 때마다 기다려야 해서 짜증났음
      결국 Homebrew로 필요한 플러그인 몇 개만 직접 설치했는데, 한 시간도 안 걸렸음
      지금은 빠르고 가벼운 셸로 훨씬 생산적이고 기분도 좋음
    • Zim도 괜찮음. Oh My Zsh보다 빠르고 설정이 간단함
      셸 시작 속도가 매우 빠르고 세팅도 손쉬움

  • 그래서 나는 fish로 갈아탐
    완벽히 내 입맛은 아니지만 기본 설정이 충분히 좋아서 그냥 익숙해졌음
    이제는 셸 설정에 신경 쓸 일이 거의 없음

    • 이 접근의 장점은 어떤 호스트에서도 fish를 설치하면 추가 설정 없이 동일한 환경을 쓸 수 있다는 점임
    • fish는 기본 상태에서도 성능이 뛰어나고 UX가 훌륭함
      다만 초보자는 키 바인딩을 꼭 읽어보길 권함
      팀 동료가 tab 완성이나 shift+arrow 같은 기능을 몰라서 속도가 느려졌던 적이 있음
    • 기본 설정에서 빠진 게 뭔지 궁금함
      나는 가끔 vim 바인딩이나 fuzzy find 플러그인만 추가함
      기본 fish만으로도 충분히 훌륭함

  • 나는 Vim 모드를 Zsh에서 켜는 걸 추천한다는 의견에 동의하지 않음
    기본 readline도 단일 명령엔 충분히 좋음
    긴 명령은 C-x C-e로 편집하면 됨
    같이 페어 프로그래밍할 때, Vim 모드 전환 때문에 오히려 느려 보임

    • C-x C-e 단축키는 정말 유용하다는 걸 새로 알게 됨
    • 나도 Vim 모드를 켜고 나서 readline 바인딩을 다시 추가함
      대부분은 insert 모드에 있고, 큰 편집이 필요할 때만 C-x C-e를 씀
    • 모드 전환은 키 한 번이면 되므로 느릴 이유가 없음
      vi 키 바인딩에 익숙하면 w, b, dw 같은 명령이 근육 기억으로 더 빠름
      에디터를 여는 건 흐름을 끊고 출력도 가려서 선호하지 않음
      셸에서도 Vim의 문자 사이 삭제(di") 같은 기능이 있었으면 좋겠음

  • 나도 oh-my-zsh를 기본 세팅용으로만 씀
    git 플러그인 하나만 쓰고, 커스텀 함수는 자동 로드함
    hyperfine으로 측정해보니 로그인 셸은 54ms, 일반 셸은 6ms 정도였음
    380ms 지연은 다른 원인일 수도 있다고 생각함

    • zsh 성능에 관심 있다면 zsh4humans를 추천함
      즉시 시작이 가능하고, 유지보수 모드라 오히려 시간 낭비를 막아줌
    • zsh -l은 로그인 셸이라 zshrc를 로드하지 않음
      zsh -ic exit으로 테스트해야 함
      자세한 내용은 zsh-bench 가이드를 참고할 것
    • 더 정확한 측정은 zprof를 .zshrc에 추가해서 하는 게 좋음 
      zmodload zsh/zprof
...
zprof
    • git 리포지토리 안에서 벤치마크를 해보는 것도 추천함
    • extract, z, fzf 같은 플러그인도 써보길 권함

  • 나는 fish + starship 조합으로 옮겼음
    fish는 기본적으로 자동완성과 구문 하이라이팅을 제공해서 oh-my-zsh의 주요 기능을 대체함
    관련 글 참고

    • 다만 fish는 POSIX 호환이 안 돼서 불편함이 있음
      그래서 나는 zsh+starship+간단한 init 스크립트를 유지함
      fish가 완벽히 “그냥 작동”하길 바라지만 아직은 아쉬움
    • 나도 수십 년간 zsh를 썼지만, 작년부터 fish로 바꿔서 계속 쓰고 있음
      HEREDOC이 없고 백그라운드 블록이 안 되는 건 불편하지만,
      요즘은 복잡한 스크립트 대신 단일 바이너리로 빌드되는 언어를 더 선호함
      안정화되면 nushell로 옮길 생각임
    • 사실 fish는 기본 상태로도 충분히 훌륭해서 커스터마이징이 거의 필요 없음

  • 나는 몇 년 전 Zim으로 갈아탔음
    필요한 기능은 다 있고 빠르고 설치도 간단함
    https://zimfw.sh/

    • Zimfw는 매우 빠르고 유연한 설치 시스템을 가짐
      다양한 소스와 형식을 지원하고, zsh 코드 통합도 뛰어남
      대부분의 플러그인 시스템보다 속도와 호환성이 훨씬 좋음
      정말 멋진 프레임워크임

  • 대학 시절 15년 전쯤 oh-my-zsh를 설치했는데,
    그때부터 너무 만족스러워서 다른 셸이나 설정을 시도할 필요를 못 느낌
    새 컴퓨터를 세팅할 때마다 가장 먼저 설치함

  • 오랫동안 oh-my-zsh를 써왔지만, 이번에 Claude를 이용해 5분 만에 제거함
    필요한 기능만 raw zsh로 대체했음
    starship을 프롬프트로 쓰기 때문에 추가 설정이 거의 필요 없었음
    지금까지는 모든 기능이 잘 작동하는 것 같음

  • 어떤 사람은 oh-my-zsh의 0.5초 지연을 문제 삼는 게 과하다고 생각함
    그냥 bash와 KDE konsole을 쓰면 충분하다고 함
    셸은 단순한 작업용 래퍼일 뿐이라며, 이런 미세 최적화에 신경 쓸 필요 없다고 봄

    • 하지만 터미널 중심으로 일하면 하루에도 수십 개의 셸을 열게 됨
      각 셸이 작업 흐름의 일부이기 때문에 1초 지연도 체감이 큼
      그래서 빠른 셸이 중요하다고 생각함
    • 반대로 하루에 셸을 몇 번이나 여는지 묻는 사람도 있음
      많아야 20번 정도라며, 그 정도면 큰 문제 아니라고 함
    • 또 다른 사람은 이 문제를 단순히 개인 취향으로 보는 게 맞다고 함
      성능이 빠른 게 좋긴 하지만, 이건 본질적인 문제는 아니라고 생각함

  • 내 zsh 설정은 90줄 정도이고 플러그인 3개(compinit, vcs-info, edit-command-line)만 씀
    시작-종료까지 0.32초 정도 걸림
    대형 리포지토리에서는 브랜치 정보 가져오느라 지연이 생김
    bkt 캐싱 유틸리티(https://github.com/dimo414/bkt)로 이런 문제를 해결할 수 있음
    아마 Starship도 비슷한 방식으로 캐싱을 활용하는 듯함

답변달기