zsh에서 fish로 갈아탄 이유, 그리고 다시 zsh로 돌아간 이유

fish 한 번 써보면 못 돌아간다고들 했다

터미널 관련 글을 읽다 보면 fish 예찬을 자주 본다. "기본 설정이 zsh + Oh My Zsh보다 좋다", "문법이 일관적이다", "자동완성이 마법이다". 호기심이 생길 만하다.

나도 그래서 갈아탔다. 6개월 썼다. 그리고 다시 zsh로 돌아왔다. 양쪽을 충분히 써본 사람으로서 무엇을 얻고 잃는지 정리한다.

왜 fish로 갔는가

fish의 매력은 기본 설정이 그대로 좋다는 거다. zsh는 Oh My Zsh, Powerlevel10k, 플러그인 다 깔아야 그럭저럭 쓸 만해진다. fish는 깔자마자 끝난다.

1. 자동완성이 강력하다

fish는 명령어 사용 패턴을 학습해서, 빈 줄에서 시작 글자만 쳐도 과거에 자주 쓰던 전체 명령을 회색으로 미리 보여준다. 오른쪽 화살표 한 번이면 채워진다.

$ git push          # 회색으로 미리 표시
$ git push origin feature/login  # 화살표 한 번에 자동완성

zsh에서도 비슷한 걸 하려면 zsh-autosuggestions 플러그인을 깔아야 한다. fish는 기본이다.

2. man page를 파싱해서 옵션 자동완성

tar -까지 치고 Tab을 누르면 fish가 tar의 man page를 파싱해서 모든 옵션을 설명과 함께 보여준다. 처음 보면 마법 같다.

$ tar -<Tab>
-c  Create archive
-x  Extract files
-z  Use gzip
-v  Verbose
...

3. 문법이 일관적이다

zsh/bash는 if/while/for의 끝이 fi/done이다. 어색한 비대칭이다. fish는 끝이 end로 통일된다.

if test -f file.txt
    echo "exists"
end
 
for i in 1 2 3
    echo $i
end

스크립트를 길게 짜본 사람이라면 이 일관성이 작은 차이가 아니라는 걸 안다.

6개월 쓰고 만난 한계

다 좋았으면 안 돌아왔을 거다. 시간이 지나면서 자잘한 마찰이 쌓였다.

1. POSIX 호환이 아니다

이게 가장 결정적이었다. fish는 의도적으로 POSIX와 다른 문법을 쓴다.

# bash/zsh
export FOO=bar
 
# fish
set -x FOO bar

문제는 인터넷에 있는 99%의 셸 스크립트가 bash 문법이라는 거다. 블로그 가이드, GitHub README, 팀 동료가 공유하는 한 줄 명령 — 다 bash다.

# Stack Overflow 답변
echo "deb https://example.com" | sudo tee /etc/apt/sources.list.d/example.list

이걸 fish에서 그대로 붙여넣으면 동작 안 한다. 변환하는 시간이 누적되니 마찰이 컸다.

2. 환경 변수 export가 어색하다

.env 파일을 source하거나 한 줄로 환경 변수를 주는 패턴이 fish에서 어색하다.

# bash
FOO=bar npm test

fish는 안 된다. env FOO=bar npm test로 우회해야 한다. 한 번 한 번은 작은 마찰이지만 매일 발생한다.

3. 동료들이 다 zsh/bash다

팀에서 셸 스크립트를 공유할 때, 내가 fish를 쓰면 검증을 두 번 해야 한다. "이 스크립트 fish에서 어떻게 도냐"를 매번 묻는다. 1인 환경이면 모르겠지만 협업 환경에서는 비용이다.

4. AI 도구가 bash를 가정한다

Claude Code, Cursor의 Bash 도구가 동작할 때 이들은 기본적으로 sh/bash 문법을 가정한다. AI가 만든 명령을 fish에 붙여넣으면 호환 안 되는 경우가 종종 생긴다. AI 시대에 이건 점점 더 무거운 비용이다.

다시 zsh로 돌아오면서 한 것

fish가 좋았던 부분을 zsh에서 최대한 재현했다.

1. zsh-autosuggestions

fish의 인라인 자동완성과 거의 같은 동작을 한다.

brew install zsh-autosuggestions
echo 'source $(brew --prefix)/share/zsh-autosuggestions/zsh-autosuggestions.zsh' >> ~/.zshrc

2. zsh-syntax-highlighting

명령어를 치는 동안 색으로 유효성을 알려준다. 명령어가 빨간색이면 못 찾는다는 뜻이다. fish의 기본 동작과 비슷하다.

brew install zsh-syntax-highlighting
echo 'source $(brew --prefix)/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh' >> ~/.zshrc

3. fzf-tab

Tab 자동완성을 fzf 인터페이스로 바꿔준다. 옵션이 많을 때 검색하면서 고를 수 있다. 효과적으로는 fish의 옵션 자동완성보다 더 강력하다.

brew install fzf
git clone https://github.com/Aloxaf/fzf-tab ~/.zsh/fzf-tab
echo 'source ~/.zsh/fzf-tab/fzf-tab.plugin.zsh' >> ~/.zshrc

4. Starship

크로스 셸 프롬프트. fish에서도 zsh에서도 같은 프롬프트를 쓸 수 있다. 셸을 갈아타도 시각적으로는 일관된다. 터미널 도구 글에서 더 자세히 다뤘다.

이 네 개를 합치면 fish의 핵심 매력은 거의 다 zsh에서 누릴 수 있다. POSIX 호환은 그대로 가져가면서.

결론적으로 누구에게 fish가 좋은가

fish가 잘 맞는 사람이 분명히 있다.

• 단일 머신, 단독 작업: 다른 사람의 셸 스크립트를 자주 다룰 일이 없는 환경
• 셸 자체에 시간 투자하기 싫은 사람: zsh + 플러그인 5개 세팅이 부담스러운 경우
• POSIX 문법을 평생 쓸 일 없는 사람: 셸 스크립트를 거의 안 짜는 경우

이 조건이면 fish가 즉시 행복을 준다.

반대로 zsh가 나은 경우:

• 팀 협업, 다양한 OS, 서버 작업이 잦은 환경
• AI 코딩 도구를 적극적으로 쓰는 경우
• 셸 스크립트, .env 파일, 환경 변수를 자주 다루는 경우

대부분의 개발자가 두 번째 그룹에 속한다. 그래서 결국 zsh로 돌아오는 흐름이 자연스럽다.

직접 겪은 일: 돌아온 zsh는 17줄이다

돌아왔다고 썼으니 돌아온 자리가 어떤지도 적어두는 게 맞겠다. 지금 내 .zshrc는 17줄이다.

들어 있는 건 거의 전부 경로 설정이다. nvm, rbenv, bun, 그리고 예전에 쓰던 rvm 경로가 아직 한 줄 남아 있다. 프롬프트를 꾸미는 줄도, 플러그인 매니저도 없다.

fish를 떠난 이유를 다시 생각해 보면 여기에 답이 있다. fish의 장점은 기본값이 좋다는 것이었는데, 나는 결국 셸에 아무것도 안 하고 싶었던 사람이었다. 기본값이 좋은 셸과 아무것도 안 깐 셸은 겉보기에 비슷한 자리에 도착한다.

대신 자동완성과 히스토리 검색은 확실히 아쉽다. 그건 fish 쪽이 나았다. 다만 그 아쉬움의 크기가, 스크립트 문법이 다른 데서 오는 잔고장보다는 작았다.

셸을 고르는 일은 기능 비교가 아니라 «내가 셸을 얼마나 만질 사람인가»를 정하는 일이었다. 그걸 모른 채로 옮겼다가 돌아온 셈이다.

정리

fish는 "기본 설정이 좋은 셸"이다. zsh는 "튜닝하면 더 강해지는 셸"이다. 둘 다 좋은 셸이고, 어느 쪽이 절대적으로 우월하지 않다.

내 결론은 이렇다. 현대 개발 환경에서는 zsh가 더 안전한 디폴트다. POSIX 호환, 협업, AI 도구와의 호환성 — 이 세 가지가 일상을 바꾼다. fish의 매력은 zsh + 좋은 플러그인 4개로 거의 따라잡힌다.

다만 fish를 한 번도 안 써본 사람은 6개월 정도 써보는 것도 추천한다. 셸이 어디까지 좋아질 수 있는지 감이 잡힌다. 그 감각을 가지고 zsh로 돌아오면, zsh를 더 잘 튜닝하게 된다.