모노레포 빌드 그래프 — 팀을 빠르게 할 때와 느리게 할 때

모노레포는 합치는 순간 생산성이 오를 것처럼 보인다. 저도 그렇게 생각하고 들어간 적이 많다. 공용 타입 한 군데, refactor 한 번에 전파, PR에서 변경 맥락이 한눈에 보인다. 여기까진 맞다. 문제는 빌드 그래프를 안 세운 모노레포는 팀을 빠르게 만드는 게 아니라, 느린 문제를 더 크게 공유한다는 점이다.

## 1. 가장 먼저 무너지는 곳은 CI다

패키지 하나 바꿨는데 전 서비스 테스트가 다 돌고, 문서 수정 하나에도 Docker 이미지가 다시 만들어지고, 캐시 키를 너무 크게 잡아서 사실상 매번 cold build가 난다. 로컬도 마찬가지다. 개발자는 자신이 건드린 앱 하나만 보고 싶은데 워크스페이스 install, 타입 체크, lint가 루트 단위로 묶여 있으면 한 저장소의 이점보다 한 저장소 전체를 매번 깨워야 하는 비용이 먼저 온다.

## 2. 디렉터리보다 의존성 경계가 중요하다

그래서 모노레포의 핵심은 폴더 구조가 아니라 의존성 경계다. 어떤 패키지가 누구를 참조할 수 있는지 명확해야 하고, 변경 영향을 역으로 계산할 수 있어야 한다. Nx든 Turborepo든 Bazel이든 이름은 중요하지 않다. 중요한 건 affected graph가 진짜로 작동하느냐다. 제가 보는 기준은 단순하다. 패키지 A를 바꿨을 때 왜 B 테스트가 다시 도는지 설명할 수 없으면 그래프가 없는 거다.

## 3. 항상 정답은 아니다

또 하나, 모노레포가 항상 polyrepo보다 낫다는 말도 믿지 않는다. 배포 주기가 완전히 다르고, 팀 책임선이 강하게 분리돼 있고, 공용 코드 비율이 낮으면 polyrepo가 오히려 운영이 편하다. 반대로 design system, shared schema, internal SDK처럼 동시에 바뀌는 자산이 많으면 모노레포가 강하다. 결국 저장소 형태보다 변경 전파의 방향이 더 중요하다.

실무에서 보면 대부분 이 지점에서 막힌다. 모노레포를 도입하면서 도구만 붙이고 규칙은 안 만든다. 태그 기반 dependency rule, task cache, package ownership, release 단위 같은 운영 규칙이 없으면 저장소만 커진다. 저는 모노레포를 좋아하지만, 아무 조건 없이 추천하진 않는다. 빠른 팀을 만드는 건 폴더 하나가 아니라 어디까지 같이 묶고 어디서 끊을지에 대한 결정이다.

모노레포 빌드 그래프 — 팀을 빠르게 할 때와 느리게 할 때

// COMMENTS

ON THIS PAGE