Monorepo Build Graph 최적화

도입

Monorepo는 협업 효율이 높지만 빌드 그래프를 관리하지 않으면 CI가 빠르게 병목된다. 전체 재빌드가 기본이 되면 작은 변경에도 대기 시간이 길어져 개발 리듬이 깨진다. 이 글은 의존성 그래프 기반 증분 빌드 전략을 정리한다.

Monorepo Build Graph 최적화 커버 — Wikimedia Commons 기반 무료 이미지

문제 정의

모노레포 빌드 비용은 저장소 크기보다 그래프 설계에 좌우된다.

패키지 경계가 모호해 변경 영향 범위를 계산할 수 없다.
캐시 키가 단순해서 동일 입력에도 캐시 미스가 잦다.
테스트 범위가 과도해 핵심 변경과 무관한 잡이 실행된다.

핵심은 그래프를 코드로 선언하고 파이프라인이 이를 신뢰하도록 만드는 것이다. affected-only 전략이 기본이어야 한다.

핵심 개념

관점	설계 기준	검증 포인트
그래프 선언	패키지 의존성 명시	영향도 계산 정확도
증분 빌드	affected target 실행	평균 빌드 시간
원격 캐시	hash 기반 재사용	cache hit ratio
테스트 최적화	변경 경계별 테스트	불필요 잡 비율

모노레포 최적화는 도구 도입보다 규칙 정의가 먼저다. 패키지 경계를 엄격히 관리하면 빌드 그래프가 단순해지고 성능도 안정화된다.

코드 예시 1: 빌드 그래프 선언 예시

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": ["coverage/**"]
    },
    "lint": {
      "outputs": []
    }
  }
}

코드 예시 2: affected 패키지 계산

#!/usr/bin/env bash
set -euo pipefail

BASE=\${1:-origin/main}

pnpm turbo run build test \
  --filter="...[\${BASE}]" \
  --cache-dir=.turbo/cache \
  --summarize

아키텍처 흐름

Mermaid diagram rendering...

트레이드오프

그래프 기반 최적화는 초기 설정이 어렵지만 장기 CI 비용을 크게 줄인다.
원격 캐시는 속도에 유리하지만 캐시 일관성 관리가 필요하다.
affected-only 전략은 효율적이지만 그래프 누락 시 회귀 위험이 있다.

정리

Monorepo 성능은 빌드 도구보다 그래프 정확성에서 결정된다. 의존성 경계를 명확히 하고 증분 실행을 기본화하면 대규모 저장소에서도 빠른 개발 루프를 유지할 수 있다.

이미지 출처

Cover: source link
License: CC BY 2.0 / Author: Paul Hudson from United Kingdom
Note: Wikimedia Commons 무료 라이선스 이미지를 다운로드 후 1600px 기준 JPG로 최적화했습니다.

도입