sh 논란 정리 요약

많은 분들이 sh를 하나의 고정된 프로그램으로 생각하지만, 실제로는 시스템마다 sh가 가리키는 대상이 다릅니다. 어떤 곳은 sh가 dash를 가리키고, 어떤 곳은 bash를 호환 모드로 실행하기도 합니다. 그래서 같은 스크립트라도 sh로 돌리면 되는 곳이 있고, 오류가 나는 곳이 있습니다. 특히 함수 문법, 배열, 확장 패턴처럼 sh 표준에 없는 문법을 쓰면 곳곳에서 삐걱거립니다. 논란의 핵심은 바로 이 차이에서 시작됩니다. 이름은 sh인데, 안에서는 서로 다른 해석기를 쓰다 보니 환경별 결과가 달라지기 때문입니다.

sh와 bash, zsh의 차이로 생기는 문제

sh, bash, zsh는 겉보기엔 비슷하지만 기능 범위가 다릅니다. bash나 zsh에서 편하게 쓰던 배열, 이중 대괄호, 확장 대입 같은 문법은 sh에서 동작하지 않을 수 있습니다. 그래서 스크립트 맨 위에 sh를 적어두고, 본문에 bash 문법을 섞으면 배포 환경에서 바로 실패합니다. 또 macOS와 Linux의 sh 해석기 선택이 다를 수 있어, 로컬에서는 잘 되고 서버에서 멈추는 상황이 흔합니다. 논란이 불붙는 지점은 여기입니다. 개발자는 “내 PC에선 잘 됨”이라 말하고, 운영 담당자는 “프로덕션에서 깨짐”이라 말하게 되죠. 결국 sh로 돌릴 스크립트는 sh 문법만 쓰거나, 아예 bash로 명확히 선언해야 충돌을 줄일 수 있습니다.

sh 스크립트 작성과 검증 포인트

실무에서 sh를 써야 한다면 몇 가지 점검이 필요합니다. 첫째, 스크립트 첫 줄에서 어떤 해석기를 쓸지 분명히 선언합니다. sh를 선택했다면 표준 문법만 사용하고, 확장 문법이 꼭 필요하면 bash로 바꾸는 편이 안전합니다. 둘째, set 옵션으로 오류를 빨리 드러내면 좋습니다. 예를 들어 set -e로 오류 시 중단, set -u로 정의되지 않은 변수 사용 금지 같은 기본 방어가 가능합니다. 셋째, printf를 써서 출력 형식을 고정하면 환경 차이로 인한 줄바꿈 문제나 공백 처리 문제를 줄일 수 있습니다. 넷째, CI에서 실제 배포 환경과 같은 sh로 테스트를 돌려야 합니다. 로컬의 sh와 서버의 sh가 다를 수 있으니, 동일한 이미지나 같은 런타임에서 검증하는 게 좋습니다. 마지막으로, 스크립트가 길어지면 sh로 유지하기 어렵습니다. 이럴 때는 기능을 나누고, 꼭 필요한 부분만 sh로 남기거나, 관리가 쉬운 언어로 옮기는 방법을 고려해 보세요.

오늘 다룬 내용의 요지는 단순합니다. sh는 이름이 같아도 동작이 같다는 보장이 없습니다. 그래서 혼용하면 논란이 생깁니다. 쓰임을 분명히 하고, 문법을 맞추고, 환경을 같게 맞추면 문제는 훨씬 줄어듭니다. 여기까지 이해하셨다면, sh를 둘러싼 헷갈림에서 한 발 떨어져 보다 안정적으로 스크립트를 다룰 수 있을 것입니다.