Bun 1.2 모노레포 워크스페이스 완전 정복 — Turborepo 대체와 workspaces:* 실전 구성 2026

Bun 1.2 기준으로 Turborepo를 대체하는 실무형 모노레포 구성 가이드입니다. workspaces:* 운영 패턴, CI 안정화, 릴리스 단계화, 실패 전파 격리까지 실전으로 정리했습니다.

Bun 1.2은 모노레포에서 Turborepo와 직접 비교할 때 속도뿐 아니라 운영 안정성 비용을 크게 줄여준다. 많은 팀이 기능 도입보다 실패 범위 관리가 더 중요하다는 점을 늦게 깨닫는다. 본 가이드의 목표는 대규모 교체 없이도 실무에서 바로 적용 가능한 기준을 잡는 것이다. 따라서 처음부터 고급 오케스트레이션을 요구하지 않고, workspaces:로 변경 범위 실행을 선제적으로 구성한다. 먼저 폴더를 고정한다. apps와 packages를 나누고, 각 패키지를 owner와 책임 SLA로 묶는다. 앱은 배포 책임, 패키지는 재사용 책임으로 분리하면 리뷰 체계가 선명해진다. 루트 package.json은 간결해야 한다. workspaces만 지정하고, scripts는 lint/test/build/smoke를 최소 집합으로 둔다. CI에서 전체 실행보다 변경 scope 실행을 기본으로 만들면 실패가 한 번에 번지는 비용이 급감한다. 권장 구조: apps/web, apps/admin, packages/config, packages/ui, packages/eslint, packages/tsconfig, packages/utils. 각 폴더별로 exports 규칙을 명확히 하여 순환 의존성을 막고, 사이드 이펙트를 낮춘다. 공용 타입은 최소한으로 공유한다. run 예시: bun test --workspaces, bun run build --workspaces, bun run test --workspaces --filter=apps/web, bun run test --workspaces --filter=packages/ui. 이 네 줄만 정확히 돌리면, 릴리스에서 70% 이상의 불필요한 재실행을 줄일 수 있다. CI 파이프라인 예시는 lint -> test -> build -> smoke다. build가 실패하면 전체 대신 실패한 workspace만 정밀 재실행하고, 성공한 범위는 로그에 남겨 재사용한다. 캐시는 workspace 단위 키로 분리하고 git sha를 포함해 오염을 막는다. 이주 전략은 한 번에 바꾸지 않는다. 1주차는 규칙, 2~4주차는 scope 분리, 5~8주차는 canary, 이후 메트릭 회고로 고도화한다. 팀 속도가 4주 연속 흔들려도 구조는 흔들리지 않게 기록 중심으로 운영한다. 실행 인사이트: 1) 실수는 로그가 부족할 때 폭증한다. 2) dependency 방향이 순환되면 지표가 무의미해진다. 3) 실패 시 10분 이내 복구 절차가 없으면 하루가 날아간다. 4) owner 미정이면 병목이 팀 전체로 확산된다. FAQ 1) Bun 1.2로 Turborepo를 즉시 대체할 수 있나? A) 소규모~중형팀은 CI 규칙이 확립되면 가능하며, 그래프 최적화는 추후 확장한다. FAQ 2) workspaces:의 가장 큰 장점은? A) 범위 실행을 강제해 blast radius를 줄인다. FAQ 3) lockfile 충돌은? A) CI 단일 업데이트와 병합 템플릿으로 줄인다. FAQ 4) 릴리스 실패 대응은? A) 실패 scope만 재실행하고 smoke 후 canary 배포한다. FAQ 5) 지표는 무엇을 보나? A) scope 실패율, rollback 수, 캐시 히트율, 회복시간을 본다. FAQ 6) 내부 링크는 왜 필요한가? A) 참조 경로를 통해 정책 변경 근거를 추적하고 검색성과 체류 시간을 확보한다. 마지막으로 내부 링크: /tools/monorepo-guide, /tools/ci-stability, /tools/workspace-template, /tools/release-playbook, /tools/cloudflare-pages-deploy. 실무에서 이 체크리스트를 남기면 다음 분기에도 동일한 템플릿을 재사용할 수 있다.