크로스 플랫폼 스크립트
크로스 플랫폼 스크립트
프로젝트가 Windows · macOS · Linux 사용자를 모두 대상으로 할 때, 자동화 스크립트를 어떤 도구로 짤지가 자주 문제가 됩니다. 정답이 정해진 영역은 아니고 환경 제약과 팀 익숙함에 따라 선택이 갈립니다.
1. bash 일원화 + Git Bash · WSL 안내
bash 스크립트로 모든 자동화를 작성하고, Windows 사용자는 Git for Windows 에 포함된 Git Bash 또는 WSL2 안에서 실행하도록 안내.
- 장점 — macOS · Linux 환경에서 가장 자연스러움. 인터넷 자료 풍부. 셸 표준 도구 (
grep·awk·sed) 그대로. - 단점 — Windows 네이티브 사용자에게 추가 설치 요구. 경로 처리 (
/c/Users/...vsC:\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. 비교 정리
| 방식 | Windows 친화도 | macOS · Linux 친화도 | 추가 설치 | 적합한 규모 |
|---|---|---|---|---|
| bash | 보통 (Git Bash 필요) | 높음 | Git Bash · WSL | 모든 규모 |
Node (zx · .mjs) |
높음 | 높음 | Node | 작음~중간 |
| PowerShell 7 | 높음 | 보통 | pwsh | 작음~중간 |
| Python | 높음 | 높음 | Python | 중간~큼 |
| Make | 보통 | 높음 | (Win 별도) | 작음~중간 |
| Just | 높음 | 높음 | just 바이너리 | 작음~중간 |
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 를 참고합니다.