크로스 플랫폼 스크립트

프로젝트가 Windows · macOS · Linux 사용자를 모두 대상으로 할 때, 자동화 스크립트를 어떤 도구로 짤지가 자주 문제가 됩니다. 정답이 정해진 영역은 아니고 환경 제약과 팀 익숙함에 따라 선택이 갈립니다.

1. bash 일원화 + Git Bash · WSL 안내

bash 스크립트로 모든 자동화를 작성하고, Windows 사용자는 Git for Windows 에 포함된 Git Bash 또는 WSL2 안에서 실행하도록 안내.

• 장점 — macOS · Linux 환경에서 가장 자연스러움. 인터넷 자료 풍부. 셸 표준 도구 (grep · awk · sed) 그대로.
• 단점 — Windows 네이티브 사용자에게 추가 설치 요구. 경로 처리 (/c/Users/... vs C:\Users\...) 어긋남. cmd · PowerShell 에서 직접 실행 안 됨.
• 적합한 곳 — 백엔드·데이터·DevOps 가 중심.

2. Node 기반 스크립트

Node.js 와 그 위의 도구로. JavaScript/TypeScript 프런트엔드 프로젝트는 어차피 Node 가 깔려 있으므로 추가 의존성이 적음.

대표 도구:

• zx (Google) — bash 같은 느낌으로 명령을 실행하는 Node 라이브러리. await $\ls`` 같은 문법.
• tsx — TypeScript 파일을 즉시 실행. tsx scripts/build.ts.
• 순정 .mjs — 외부 의존 없이 ESM 으로. node scripts/clean.mjs.

// scripts/clean.mjs
import { rm } from "node:fs/promises";
await rm("dist", { recursive: true, force: true });
console.log("cleaned");

장점은 OS 추상화가 표준 라이브러리에 있다는 점 (fs · path · os). 단점은 Node 가 없으면 못 돔, CLI 가 아닌 일을 시키면 코드량이 늘 수 있음.

3. PowerShell 7+

PowerShell 7+ 는 Windows · macOS · Linux 에서 모두 동작. 객체 파이프와 .NET 라이브러리.

• 장점 — Windows 사용자에게 가장 자연스러움. 관리·자동화 cmdlet 풍부. 7+ 는 진짜 크로스 플랫폼.
• 단점 — macOS · Linux 사용자에게 별도 설치 (brew install powershell · apt install powershell). 셸 자체의 인지도가 Unix 진영에서 낮음.
• 적합한 곳 — Windows 위주의 팀이 macOS · Linux 호환을 더하고 싶을 때.

4. Python 스크립트

Python 은 표준 라이브러리가 두텁고 OS 추상화가 잘 되어 있음 (pathlib · subprocess · shutil).

• 장점 — 풍부한 표준 라이브러리. 가독성. 데이터 처리·HTTP 요청·파일 조작이 한 줄.
• 단점 — Python 인터프리터와 버전 관리 (가상 환경) 필요. 단순한 명령 호출에는 셸보다 코드가 길어짐.
• 적합한 곳 — 이미 Python 이 핵심인 프로젝트, 또는 자동화 스크립트가 데이터·네트워킹을 다룰 때.

5. Make · Just

make 는 Unix 빌드 자동화의 고전. just 는 그 흐름을 단순화한 현대 도구.

• make — macOS · Linux 에 대부분 기본 탑재. Windows 는 별도 설치 (MSYS2 · GnuWin). Makefile 의 탭/공백 문법이 까다로움.
• just — Rust 로 작성. 의존성 그래프 없이 명령 모음. 크로스 플랫폼 친화도가 make 보다 높음. cargo install just 또는 brew install just.

# Makefile
build:
	npm run build

test:
	npm test

# justfile
build:
    npm run build

test:
    npm test

장점은 명령 모음을 한 파일에 정리. 단점은 내부에서 결국 셸 명령을 호출하므로 OS 차이는 그대로.

6. package.json scripts

JS · TS 프로젝트에서는 package.json 의 scripts 가 사실상 기본 진입점.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "lint": "eslint ."
  }
}

npm · pnpm · yarn 어디서든 동작. 전역 설치 없이 node_modules/.bin 의 도구를 부름. OS 차이가 큰 명령은 cross-env (환경변수) · rimraf (디렉터리 삭제) · npm-run-all 같은 보조 도구로 추상화.

scripts 에 들어가는 명령이 길어지기 시작하면 zx 나 별도 .mjs 로 분리하는 편이 유지보수에 유리.

7. 비교 정리

8. 같은 작업의 4 가지 표현

# bash
rm -rf dist

# PowerShell
Remove-Item -Recurse -Force dist -ErrorAction SilentlyContinue

// Node .mjs
import { rm } from "node:fs/promises";
await rm("dist", { recursive: true, force: true });

# Python
import shutil; shutil.rmtree("dist", ignore_errors=True)

9. 자주 걸리는 자리

bash 스크립트의 줄바꿈이 CRLF 가 되어 Linux 에서 깨짐 — .gitattributes 의 *.sh text eol=lf.

Node 스크립트에서 path.join 대신 "a/b/c" 같은 하드 슬래시 — Windows 에서 동작은 하지만 출력·로그가 어색.

PowerShell 7+ 가 깔린 줄 알고 pwsh 만 부르면 5.1 만 있는 환경에서 실패 — 검사 후 안내.

Makefile 들여쓰기가 공백이라 make 가 깨지는 경우 — Make 는 탭 문자 필수.

Windows 에서 && 를 cmd 가 아닌 PowerShell 5.1 에서 부르면 파서 에러.

하고픈 말

크로스 플랫폼 스크립트는 정답이 없습니다. 팀 환경 (Windows · Unix 비중) 과 프로젝트 성격 (프론트엔드 · 백엔드 · 데이터) 에 따라 결정. OS 별 동등 스크립트 3 종 동시 유지 또는 Node .mjs 일원화가 자주 보이는 두 모양.

Next

• markdown
• text-encoding-line-endings

google/zx · tsx · PowerShell 설치 · casey/just · npm Docs scripts 를 참고합니다.