macOS는 2019년 카탈리나 버전부터 기본 로그인 쉘을 Bash에서 Zsh로 바꿨어요. 애플이 그 이전부터 Bash를 3.2 버전에 묶어둔 채 10년 넘게 업데이트를 안 했다는 사실은 의외로 잘 안 알려져 있는데, 2007년 Bash가 GPLv3 라이선스로 전환되자 애플이 업데이트를 아예 멈추고 결국 기본값 자체를 Zsh로 갈아탄 거예요. 그렇다면 Bash, Zsh, Fish는 실제로 뭐가 다르고, 지금 리눅스를 쓰는 나에게는 어떤 쉘이 맞을까요?
Bash는 왜 여전히 리눅스의 기본값일까?
Bash(Bourne Again Shell)는 1989년 GNU 프로젝트의 브라이언 폭스가 옛 유닉스 Bourne 쉘을 계승해 만든 이후 지금까지 거의 모든 리눅스 배포판에서 기본 로그인 쉘 자리를 지키고 있는 쉘이에요. POSIX 표준을 충실히 따르는 덕분에 서버 관리 스크립트와 CI 파이프라인 대부분이 Bash(혹은 그 하위 호환인 sh) 문법을 기준으로 짜여 있고, 우분투를 비롯한 주요 배포판도 새 계정을 만들면 기본으로 Bash를 배정해요. 자동완성이나 프롬프트 꾸미기는 상대적으로 기본기에 머물러 있지만, 그만큼 어디서나 예측 가능하게 동작한다는 게 Bash의 가장 큰 무기예요.
Zsh는 Bash와 무엇이 근본적으로 다를까?
Zsh(Z Shell)는 1990년 폴 팔스타드가 Bash 문법을 대부분 그대로 계승하면서 자동완성과 확장성을 큰 폭으로 강화해 만든 쉘이에요. 명령어 일부만 입력하고 탭을 누르면 후보를 메뉴 형태로 골라 넘길 수 있고, 오타를 내도 비슷한 명령어를 추천해주는 등 상호작용 편의성이 Bash보다 한 단계 위예요. 여기서 끝이 아니에요. Oh My Zsh나 Powerlevel10k 같은 커뮤니티 프레임워크가 테마·플러그인 생태계를 두껍게 쌓아 올리면서, Zsh는 “Bash 문법을 알면서 더 편하게 쓰고 싶은 사용자”를 겨냥한 쉘로 자리 잡았어요. 애플이 macOS 기본값으로 Zsh를 택한 것도 이 호환성과 편의성을 동시에 챙길 수 있었기 때문이에요.
Fish는 왜 “설정 없이 바로 쓰는” 쉘을 표방할까?
Fish(Friendly Interactive Shell)는 2005년 등장 이후 플러그인 설치 없이도 자동완성, 문법 강조, 실시간 명령어 추천 기능이 기본으로 켜져 있는 걸 핵심 철학으로 삼은 쉘이에요. 명령어를 입력하는 도중에 과거 기록을 바탕으로 회색 글씨 제안이 바로 떠서 Zsh처럼 별도 플러그인을 얹지 않아도 즉시 쾌적한 사용감을 얻을 수 있어요. 다만 이 편의성은 공짜가 아니에요. Fish는 문법을 아예 새로 설계하면서 기존 셸 스크립트와의 호환성을 과감히 포기했고, 그 결과 Bash나 Zsh용 스크립트를 그대로 가져와 쓸 수 없다는 점이 진입 장벽으로 남아 있어요.
자동완성과 프롬프트, 실제로 체감 차이가 있을까?
체감 차이는 생각보다 크게 갈려요. Bash는 탭을 두 번 눌러야 후보 목록이 나열되는 수준이고, Zsh는 플러그인을 얹었을 때 메뉴 방식 선택이 가능해지며, Fish는 아무 설정 없이도 입력 즉시 회색 글씨로 제안이 뜨는 구조예요. 설정 파일 위치도 각 쉘마다 달라서 새 쉘로 옮길 때 가장 먼저 부딪히는 부분이니 코드로 정리해두는 게 편해요.
# 쉘별 기본 설정 파일 위치
~/.bashrc # Bash
~/.zshrc # Zsh
~/.config/fish/config.fish # Fish프롬프트 꾸미기도 마찬가지예요. Bash는 PS1 변수를 직접 손으로 편집해야 하지만, Zsh와 Fish는 Powerlevel10k나 Starship 같은 도구를 얹으면 Git 브랜치나 실행 시간 정보를 몇 줄 설정만으로 바로 띄울 수 있어요.
스크립트 호환성 문제는 실제로 언제 터질까?
스크립트 호환성 문제는 대부분 “쉘을 바꿨는데 예전 스크립트가 갑자기 안 돌아간다”는 형태로 터져요. Bash와 Zsh는 대부분의 기본 문법을 공유하지만 배열 인덱스나 일부 확장 문법에서 미묘하게 다르게 동작하는 구간이 있고, Fish는 아예 if/then과 변수 선언 방식부터 Bash와 다르기 때문에 호환 자체가 안 돼요. 그래서 배포 자동화나 서버 초기화처럼 여러 환경에서 실행될 스크립트라면 셔뱅을 #!/bin/bash나 #!/bin/sh로 명시해, 로그인 쉘이 뭐든 항상 같은 쉘로 실행되게 만드는 게 안전해요. 쉘 자체는 apt·dnf·pacman·zypper 같은 패키지 매니저로 어느 배포판에서든 비슷하게 설치할 수 있지만, 그 뒤에 짜는 스크립트의 이식성은 결국 어떤 쉘 문법을 썼는지에 달려 있어요.
그래서 나한테는 어떤 쉘이 맞을까?
정답은 결국 어떤 작업을 얼마나 자주 하느냐에 달려 있어요.
- 서버·인프라 작업이 많다면: Bash를 그대로 쓰는 게 가장 무난해요. 거의 모든 배포판의 기본값이라 별도 설치 없이 어디서나 동일하게 동작해요.
- 터미널을 하루 종일 들여다보는 개발자라면: Zsh에 자동완성 플러그인을 얹는 조합이 잘 맞아요. 개발자를 위한 리눅스 배포판을 고민하는 단계라면 쉘도 함께 세팅해두는 걸 추천해요.
- 리눅스 쉘을 처음 접한다면: Fish처럼 설정 없이 바로 편한 쉘이 진입 장벽을 낮춰줘요. 초보자에게 좋은 첫 배포판을 고르는 것과 비슷한 맥락이에요.
- 여러 서버를 오가며 스크립트 이식성이 중요하다면: Fish나 커스터마이징한 Zsh보다는 Bash 문법을 지키는 편이 안전해요.
애플이 10년 넘게 구버전 Bash를 붙잡고 있다가 결국 Zsh로 갈아탄 사례는, 쉘 선택이 단순한 취향을 넘어 라이선스·유지보수 부담까지 얽힌 문제라는 걸 보여줘요. Bash, Zsh, Fish 중 뭐가 정답인지는 결국 지금 내가 어떤 작업을 얼마나 반복하느냐에 달려 있는 셈이에요.
자주 묻는 질문
Q1. 쉘을 Bash에서 Zsh나 Fish로 바꾸면 기존 스크립트가 안 돌아가나요?
아니요, 스크립트는 파일 상단 셔뱅(#!/bin/bash)이 지정한 쉘로 실행되기 때문에 로그인 쉘을 바꿔도 기존 Bash 스크립트는 그대로 동작해요. 다만 Fish 문법으로 새로 짠 스크립트는 Bash나 sh에서는 실행되지 않아요.
Q2. Zsh는 Bash와 완전히 다른 언어인가요?
아니요, Zsh는 Bash 문법을 대부분 그대로 이해하는 상위 호환에 가까운 구조라서 기존 .bashrc 설정이나 스크립트 대부분을 큰 수정 없이 옮겨올 수 있어요.
Q3. Fish는 왜 POSIX 표준 문법을 안 쓰나요?
Fish는 자동완성과 문법 강조 같은 사용성을 설계 단계부터 최우선으로 삼으면서 기존 셸 문법과의 호환성을 의도적으로 포기했기 때문에, 표준 셸 스크립트와는 다른 자체 문법을 씁니다.
Q4. Oh My Zsh를 꼭 설치해야 Zsh를 쓸 수 있나요?
아니요, Oh My Zsh는 테마와 플러그인을 편하게 관리해주는 커뮤니티 프레임워크일 뿐이라 Zsh 자체는 별도 설치 없이 기본 상태로도 바로 쓸 수 있어요.
Q5. 서버 관리용으로는 어떤 쉘이 제일 무난한가요?
대부분의 서버 배포판이 로그인 쉘과 /bin/sh를 Bash나 Dash 기준으로 맞춰두고 있어서, 서버 환경에서는 Bash를 그대로 쓰는 게 호환성 문제가 가장 적어요.
Q6. 쉘을 바꾸는 명령어는 뭔가요?
chsh -s 명령어로 로그인 쉘을 바꿀 수 있으며, 예를 들어 chsh -s /usr/bin/fish처럼 원하는 쉘의 경로를 지정하면 다음 로그인부터 적용돼요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.