BusyBox vs coreutils, 임베디드에서 무엇을 고르나
임베디드 루트파일시스템에 유닉스 유틸 집합을 넣을 때 선택지는 크게 둘입니다. BusyBox(작은 multi-call 바이너리 + 선택적 applet)와 GNU coreutils(풀옵션 개별 바이너리 세트)입니다.
BusyBox 문서는 스스로를 The Swiss Army Knife of Embedded Linux라 부르며, GNU coreutils·util-linux 등에서 흔히 쓰는 유틸의 미니멀 대체를 한 실행 파일에 넣는다고 설명합니다. 포함된 옵션은 기대 동작을 제공하지만, GNU 사촌보다 옵션이 적다고 명시합니다. GNU coreutils는 풀 기능 POSIX/GNU 유틸리티 세트입니다.
이 글의 축은 크기/호환 · 스크립트 깨짐 · 선택 기준뿐입니다. 보드별 실측 MB·가격·창작 현장 후기는 없습니다. 제휴·요금 링크도 없습니다.
근거: BusyBox, BusyBox FAQ, GNU Coreutils, Coreutils manual.
크기·호환은?
한 줄 답: BusyBox는 크기·모듈성이 설계 목표이고, coreutils는 기능·GNU 호환이 강점입니다. “같은 ls/cp 이름”이어도 옵션 집합이 같지 않다는 점이 호환의 핵심입니다.
| 축 | BusyBox | GNU coreutils |
|---|---|---|
| 배포 형태 | 하나의 multi-call 바이너리; applet이 코드 공유 | 유틸별 개별 실행 파일 |
| 크기 | 컴파일 시 applet/기능 on·off로 줄임; FAQ상 풀기능 동적 x86 예시는 1MB 전후 수준(설정·libc·아키텍처에 따라 다름) | 유틸·옵션이 넓어 루트fs 점유는 보통 더 큼 |
| 설정 | make menuconfig로 applet·FEATURE 선택 | 패키지/빌드에서 유틸 단위 설치 |
| 옵션 깊이 | 포함된 옵션은 GNU와 비슷하게 동작하되, 옵션 수 자체는 적음(BusyBox 문서) | GNU long option·확장 동작이 풍부 |
| 표준 기준 | BusyBox 측은 coreutils 불일치 ≠ 자동 버그; SUS/POSIX를 우선 기준으로 언급(메일링·FAQ 맥락) | GNU 확장 + POSIX |
크기 쪽에서 BusyBox가 유리한 이유(문서 요약):
- ELF·공통 코드 1회 — multi-call이라 applet이 한 바이너리를 공유합니다.
- 필요 applet만 — menuconfig로 미사용 명령을 빼면 바이너리가 줄어듭니다.
- FEATURE 토글 — 같은 applet도 verbose usage 등 기능을 끌 수 있습니다.
- libc·static/dynamic — 최종 footprint는 BusyBox뿐 아니라 libc 선택에 크게 좌우됩니다(BusyBox “use less RAM” 등).
호환 쪽에서 coreutils가 유리한 이유:
- 데스크톱·CI에서 검증한 GNU 스크립트를 타깃에 그대로 가져올 때.
--long-option,find -printf,date -d,stat -c등 GNU 확장에 의존할 때.- 동작 차이를 “버그”로 취급하지 않고 문서화된 GNU 동작을 계약으로 삼을 때.
하지 말 것: 특정 SoC의 “우리 보드에서는 BusyBox가 N KB” 같은 창작 실측으로 일반화하기. 크기는 설정·툴체인·libc·스트립의 함수입니다.
스크립트 깨짐은?
한 줄 답: 깨짐의 대부분은 “명령이 없다”보다 옵션·출력이 GNU와 다르다는 데서 옵니다. BusyBox는 의도적으로 작은 옵션 집합을 유지합니다. 호스트(coreutils)에서 통과한 셸 스크립트가 타깃(BusyBox)에서 실패하는 패턴을 전제로 검증하십시오.
흔한 깨짐 축(공개 문서·관행; 보드 일화 아님):
| 증상 | 원인 축 | 대응 |
|---|---|---|
unrecognized option / invalid option | GNU long option·확장 플래그 | POSIX/짧은 옵션으로 재작성, 또는 해당 GNU 바이너리만 병행 설치 |
| applet not found | menuconfig에서 해당 applet OFF | applet 활성화, 또는 스크립트에서 제거 |
| 출력 형식·정렬·에러 문구 불일치 | 파서가 GNU 출력에 고정 | 파싱 대신 exit code·간단한 필드만 신뢰 |
cp/ln/install 플래그 서브셋 | BusyBox 옵션 표가 GNU보다 좁음 | --help(및 CONFIG_FEATURE_VERBOSE_USAGE)로 타깃 바이너리 확인 |
| 빌드 호스트 ≠ 런타임 | 개발 PC는 coreutils, 이미지는 BusyBox | 타깃(또는 동일 BusyBox 빌드)에서 스크립트 스모크 |
검증 루틴 예:
# On the target (or rootfs chroot with the same busybox):
busybox # list compiled-in applets
busybox ls --help # or: ls --help via symlink
# Re-run the install/init scripts that assume GNU flags
# Prefer POSIX options; quarantine GNU-only helpers실무 규칙:
- 호스트에서만 “통과”한 스크립트를 신뢰하지 않습니다. 타깃 BusyBox로 한 번 더 돌립니다.
--help는 타깃 것을 봅니다. BusyBox는 대부분 applet에--help를 둡니다.- 하이브리드 — 루트는 BusyBox, GNU 확장이 꼭 필요한 몇 개만 coreutils 개별 패키지로 넣는 구성이 Buildroot/Yocto 등에서 흔합니다(이미지 정책에 따름).
- 불일치를 BusyBox 버그로 바로 올리지 않습니다. BusyBox 커뮤니티는 coreutils와의 차이를 표준(POSIX) 기준으로 재검토하라고 합니다.
선택 기준은?
한 줄 답: 플래시/RAM 예산과 스크립트 계약으로 고릅니다. 크기·모듈성이 우선이면 BusyBox, GNU 스크립트·옵션 충실도가 계약이면 coreutils(또는 BusyBox + 선택적 GNU 유틸).
| 조건 | 기울기 | 이유 |
|---|---|---|
| 루트fs·RAM이 빡셈, applet 집합을 통제하고 싶음 | BusyBox | multi-call + menuconfig |
| initramfs·복구·최소 사용자공간 | BusyBox | “kernel + /dev + /etc + BusyBox”로 POSIX-ish 환경(문서 표현) |
| 공장/필드 스크립트가 GNU 옵션에 고정 | coreutils(또는 해당 유틸만 GNU) | 옵션 호환이 계약 |
| CI·데스크톱과 동일 셸 유틸 동작을 보장 | coreutils 쪽 | 환경 차이를 줄임 |
| 대부분 BusyBox로 충분, 소수 명령만 GNU 필요 | 하이브리드 | 크기와 호환 타협 |
| “이름만 같으면 된다”고 가정 | 금지 | 옵션·출력이 다름 |
결정 체크리스트:
1. Flash/RAM budget? → favors BusyBox + trim applets
2. Which scripts must run unchanged? → list GNU-only flags
3. Can those scripts be rewritten to POSIX? → keep BusyBox-only
4. Must keep GNU flags? → coreutils or hybrid for those tools
5. Smoke-test on the actual target busybox/coreutils build
6. Document the contract: "target utils = BusyBox X.Y / coreutils Z"한 줄 정리: BusyBox는 작게 맞추는 도구 상자, coreutils는 GNU 호환 풀세트입니다. 임베디드 선택은 취향이 아니라 용량 예산 × 스크립트 호환 계약입니다.
FAQ
BusyBox만으로 “완전한” 사용자공간이 되나요?
BusyBox는 작은·임베디드 시스템에 상당히 완전한 POSIX 환경을 제공한다고 스스로 설명합니다. 다만 모든 GNU 확장·모든 POSIX 유틸을 의미하지는 않습니다. applet 구성과 FEATURE에 따라 범위가 달라집니다.
coreutils를 쓰면 BusyBox가 필요 없나요?
코어 파일 유틸은 coreutils로 대체 가능하지만, BusyBox는 init·쉘·네트워킹·모듈 도구 등 coreutils 밖 applet도 묶습니다. “coreutils만”과 “BusyBox 전체”는 집합이 다릅니다. 이미지가 systemd+coreutils+util-linux 조합인지, BusyBox ash+applets인지에 따라 다릅니다.
옵션이 없으면 BusyBox 버그인가요?
항상은 아닙니다. BusyBox는 적은 옵션으로 크기 최적화를 목표로 하고, coreutils와의 불일치를 자동으로 버그로 보지 않습니다. POSIX/문서·설정(FEATURE)을 먼저 확인하십시오.
Buildroot/Yocto에서 둘 다 쓰는 경우는?
가능합니다. 많은 임베디드 빌드 시스템은 BusyBox를 기본으로 두고, 필요 시 coreutils 패키지(또는 개별 GNU 유틸)를 추가합니다. PATH에서 어느 바이너리가 앞서는가를 이미지에서 확인하십시오.
출처 (Sources)
- BusyBox — The Swiss Army Knife of Embedded Linux — multi-call, 모듈성, GNU보다 적은 옵션, POSIX-ish 환경
- BusyBox FAQ — 크기(풀기능 ~1MB급 예시), applet 비용, bloatcheck/sizes, 설계 의도
- BusyBox — use less RAM — data/bss·static/dynamic·libc가 footprint에 미치는 영향
- GNU Coreutils — GNU 핵심 유틸리티 세트
- GNU Coreutils manual — 개별 유틸 옵션·동작 명세