[Language] Bash

Bash란?

---

Bash는 GNU 프로젝트의 셸이자 명령 언어 인터프리터이다. 이름은 Bourne Again SHell의 약자이며, 전통적인 Bourne shell 계열 문법을 바탕으로 Korn shell과 C shell에서 유용한 기능을 받아들인 확장 셸로 볼 수 있다. 사용자는 터미널에서 대화형으로 명령을 실행할 수 있고, 운영 자동화에서는 파일에 적힌 명령을 스크립트로 실행할 수 있다.

Bash의 실무적 위치는 단순한 명령 실행기를 넘어선다. 개발 환경 초기화, CI/CD 스텝, 배포 스크립트, 컨테이너 엔트리포인트, 장애 대응용 런북까지 Unix 계열 운영 환경의 얇은 접착층 역할을 한다. 다만 범용 프로그래밍 언어처럼 큰 상태와 복잡한 도메인 로직을 오래 유지하는 데 최적화된 도구는 아니므로, 사용 범위를 분명히 정해야 한다.

Bash는 운영체제 명령, 파일, 프로세스, 환경 변수를 빠르게 엮는 자동화 언어이다. 강점은 접근성과 운영 친화성이고, 약점은 복잡도가 커질수록 테스트와 유지보수가 어려워진다는 점이다.

Free Software Foundation의 GNU Bash 로고는 Bourne shell을 확장한 GNU 셸이라는 Bash의 정체성을 보여준다.

핵심 동작 원리

---

Bash는 입력을 읽고, 토큰과 구문으로 파싱한 뒤, 여러 종류의 확장을 적용하고, 명령을 해석한 다음 실행한다. 확장 단계에는 변수 확장, 명령 치환, 산술 확장, 글로브 패턴 확장, 따옴표 제거 등이 포함된다. 이 순서를 정확히 이해하지 못하면 공백, 특수문자, 파일명 패턴, 빈 변수에서 예상하지 못한 동작이 발생한다.

명령 해석 단계에서는 예약어, 함수, 빌트인, 해시된 명령, PATH 검색으로 찾은 외부 실행 파일이 구분된다. 외부 명령은 프로세스로 실행되지만, 일부 빌트인은 현재 셸 프로세스의 상태를 직접 바꾼다. 예를 들어 cd, export, alias 같은 명령은 자식 프로세스에서 실행되면 호출한 셸의 상태를 바꿀 수 없기 때문에 빌트인으로 존재한다.

Bash 스크립트의 많은 버그는 명령 자체보다 확장 순서와 현재 셸 상태를 잘못 이해해서 생긴다.

Bash 명령 처리 흐름은 입력 파싱, 확장, 명령 실행, 종료 상태 확인이 순서대로 이어지는 구조로 이해할 수 있다.

스크립팅 모델과 셸 상태

---

Bash 스크립트는 일반적으로 순차 실행을 기본으로 하고, 파이프라인과 조건문, 반복문, 함수로 흐름을 구성한다. 종료 상태는 $?로 확인할 수 있으며, 조건문과 &&, || 체인의 판단 근거가 된다. 실무 스크립트에서는 set -euo pipefail 같은 옵션을 자주 쓰지만, 이 옵션들도 예외 상황이 있어 무조건적인 안전장치로 보기는 어렵다.

셸 상태는 변수, 위치 매개변수, 옵션, 현재 디렉터리, trap, alias, 함수 정의로 구성된다. 이 상태가 암묵적으로 공유되기 때문에 작은 스크립트는 간결하지만, 큰 스크립트는 함수 간 결합이 쉽게 늘어난다. 따라서 규모가 커지면 입력과 출력, 임시 파일, 오류 반환 규칙을 명시적으로 설계해야 한다.

Bash에서 상태는 편리하지만 숨기 쉽다. 자동화 스크립트는 상태 변경 지점을 짧고 명확하게 유지해야 한다.

POSIX sh와 Bash 확장의 선택 기준

---

Bash는 sh 호환성을 의식해 만들어졌지만, POSIX sh와 동일한 언어는 아니다. 배열, [[ ... ]], brace expansion, process substitution, 일부 문자열 조작, source 같은 기능은 Bash 스크립트를 간결하게 만들지만 다른 POSIX 셸에서 그대로 동작하지 않을 수 있다. 반대로 #!/bin/sh를 선택하면 배포판과 임베디드 환경에서 이식성이 좋아지지만 표현력이 줄어든다.

실무 기준은 실행 환경의 통제 가능성이다. 내부 CI 러너, 표준화된 서버 이미지, 컨테이너 이미지처럼 Bash 설치를 보장할 수 있다면 #!/usr/bin/env bash와 Bash 확장을 쓰는 편이 유지보수에 유리할 수 있다. 반대로 패키지 설치 스크립트, 다양한 Unix 계열 시스템에 배포되는 스크립트, 최소 컨테이너 이미지에서는 POSIX sh 기준을 우선 검토해야 한다.

Bash와 POSIX sh의 선택은 취향이 아니라 배포 대상, 런타임 보장, 유지보수 비용의 문제이다.

운영 자동화에서의 강점

---

Bash의 강점은 운영체제 표면과 가까운 곳에서 드러난다. 파일 존재 여부 확인, 프로세스 실행, 표준 입출력 연결, 환경 변수 전달, 원격 명령 실행, 로그 필터링을 짧은 코드로 묶을 수 있다. grep, awk, sed, find, curl, jq 같은 도구와 조합하면 별도 애플리케이션을 만들지 않고도 강력한 자동화를 구성할 수 있다.

CI/CD에서도 Bash는 여전히 기본 단위에 가깝다. YAML 워크플로가 전체 구조를 표현하더라도 실제 빌드, 테스트, 배포 명령은 셸 스텝으로 실행되는 경우가 많다. 이때 Bash 스크립트는 파이프라인 시스템과 애플리케이션 빌드 도구 사이의 경계를 연결한다.

Bash는 복잡한 애플리케이션을 만들기보다 이미 존재하는 명령형 도구를 안정적으로 연결할 때 가장 큰 효과를 낸다.

한계와 장애 지점

---

Bash의 가장 큰 위험은 문자열 중심 모델이다. 공백이 포함된 파일명, 빈 변수, 글로브 확장, 명령 치환 결과의 줄바꿈은 작은 실수로도 데이터 손상이나 잘못된 삭제를 만들 수 있다. 그래서 변수는 기본적으로 따옴표로 감싸고, 배열을 쓸 수 있는 곳에서는 문자열 조합 대신 배열을 쓰며, 위험한 파일 조작은 dry-run과 명시적 경로 검증을 거쳐야 한다.

보안 측면에서는 입력을 명령 문자열로 조립하는 패턴이 위험하다. 사용자 입력, 파일 내용, 외부 API 응답을 그대로 eval하거나 셸 명령에 삽입하면 명령 주입으로 이어질 수 있다. 성능 측면에서는 반복문 안에서 외부 프로세스를 과도하게 호출하면 프로세스 생성 비용이 커진다. 복잡한 파싱, 장기 실행 데몬, 동시성 제어, 구조화된 데이터 처리가 핵심이면 Python, Go, Rust 같은 언어로 옮기는 편이 낫다.

Bash의 생산성은 입력이 신뢰 가능하고 작업 범위가 작을 때 빛난다. 입력이 복잡하거나 실패 비용이 크면 더 강한 언어와 테스트 구조가 필요하다.

실무 작성 원칙

---

• 스크립트 상단에 사용할 셸을 명확히 선언한다. Bash 기능을 쓰면 #!/usr/bin/env bash 또는 조직 표준 경로를 사용한다.
• 입력, 출력, 종료 코드를 문서화하고 함수 단위로 책임을 나눈다.
• 변수 확장은 기본적으로 따옴표로 감싸고, 리스트 처리는 가능한 경우 배열을 사용한다.
• 삭제, 이동, 권한 변경처럼 파괴적인 작업은 대상 경로 검증과 로그를 남긴다.
• ShellCheck 같은 정적 분석 도구와 CI 테스트를 붙여 반복 실수를 줄인다.

좋은 Bash 스크립트는 짧아서 좋은 것이 아니라, 실패 지점과 실행 환경을 읽는 사람이 예측할 수 있어서 좋다.

사례

---

• GitHub Actions workflow syntax는 워크플로의 run 스텝에서 셸을 지정할 수 있게 하며, Linux/macOS 러너의 자동화 명령 실행에서 Bash가 흔히 사용되는 사례이다.
• Debian Policy Manual - Files는 /bin/sh 스크립트가 POSIX Shell Command Language를 가정할 수 있다고 설명한다. 이는 패키징 영역에서 Bash 확장과 POSIX 이식성을 구분해야 하는 대표 사례이다.
• Linux man-pages의 bash(1)는 Bash를 표준 입력, 문자열, 파일에서 명령을 읽어 실행하는 인터프리터로 설명한다. 운영체제 문서에서 Bash가 사용자 명령과 스크립트 실행의 기본 도구로 다뤄지는 사례이다.
• ShellCheck는 셸 스크립트의 quoting, portability, 오류 처리 문제를 정적으로 찾아주는 도구이다. Bash가 실무 자동화에 널리 쓰이기 때문에 별도 품질 관리 생태계가 형성된 사례이다.