회사 규모가 커지면 코드 저장소를 어떻게 나눌지가 슬그머니 큰 문제로 떠오른다. 프로젝트마다 저장소를 따로 둘지, 아니면 하나에 몰아넣을지. 최근 몇 년의 흐름은 뚜렷하다. 여러 프로젝트를 한 저장소에 모으는 모노레포(Monorepo)가 다시 힘을 얻고 있다. 그리고 그걸 가능하게 만든 진짜 열쇠는 원격 캐시와 빌드 오케스트레이션이다.
모노레포는 여러 애플리케이션과 공용 라이브러리를 하나의 저장소에서 함께 관리하는 방식이다. 말만 들으면 단순히 폴더를 합친 것 같지만, 규모가 커지면 "매번 전부 빌드하고 테스트할 수 없다"는 벽에 부딪힌다. 이 벽을 넘게 해 준 게 바뀐 부분만 골라 처리하고 결과를 캐시로 공유하는 도구들이다.
모노레포를 되살린 건 철학이 아니라 캐시였다.
원격 캐시는 한 번 한 빌드를 팀 전체가 나눠 쓰게 만든다.
바뀐 것만 다시 빌드하고, 나머지는 이미 계산된 결과를 재사용한다. 이 단순한 원칙이 거대한 저장소를 다룰 만하게 바꿔 놓았다.
단일소스 하나의 저장소 하나의 버전 |
증분빌드 바뀐 부분만 다시 계산 |
공유캐시 팀·CI가 결과 재사용 |
의존그래프 영향 범위를 자동 계산 |
왜 다시 모노레포인가
저장소를 프로젝트마다 쪼개면 처음엔 깔끔하다. 하지만 공용 코드를 여럿이 나눠 쓰기 시작하면 이야기가 달라진다. 공용 라이브러리를 고칠 때마다 버전을 올려 배포하고, 그걸 쓰는 프로젝트마다 새 버전으로 갱신하고, 버전 조합이 안 맞아 생기는 문제를 붙잡고 씨름한다. 이 "버전 지옥"을 겪어 본 사람은 안다. 어디서 무엇이 깨졌는지 추적하는 데 하루가 훌쩍 간다.
모노레포는 이 문제를 정면으로 없앤다. 모든 코드가 한 저장소, 한 버전으로 존재하니 공용 라이브러리를 고치면 그걸 쓰는 모든 곳이 같은 커밋 안에서 함께 바뀐다. 변경과 그 영향이 하나의 원자적 단위로 묶인다. 코드 검색, 일괄 리팩터링, 일관된 도구 적용도 훨씬 쉬워진다.
진짜 문제: 규모
그런데 여기서 진짜 어려움이 시작된다. 수십, 수백 개 프로젝트가 한 저장소에 있으면 "테스트 한 번 돌려 봐"가 재앙이 된다. 전부 빌드하고 전부 테스트하면 몇 시간이 걸릴 수도 있다. 이걸 해결하지 못하면 모노레포는 그저 느린 괴물이 된다.
의존성 그래프와 증분 처리
현대 모노레포 도구의 첫 번째 무기는 프로젝트 간 의존 관계를 그래프로 파악하는 것이다. 어떤 파일을 고쳤을 때 그 변경이 영향을 미치는 프로젝트가 어디까지인지 정확히 계산한다. 그래서 관련 없는 부분은 아예 건드리지 않고 건너뛴다. 커밋 하나가 작은 유틸 하나만 바꿨다면, 그와 무관한 수십 개 앱은 빌드도 테스트도 하지 않는다.
원격 캐시
두 번째 무기가 핵심이다. 한 번 실행한 빌드·테스트의 결과에 입력값의 지문을 붙여 저장해 둔다. 나중에 같은 입력이 다시 들어오면, 실제로 실행하지 않고 저장된 결과를 그대로 꺼내 쓴다. 이걸 로컬을 넘어 팀 전체와 CI가 공유하는 게 원격 캐시다. 동료가 이미 빌드한 것을 내가 다시 빌드하지 않고, CI가 만든 결과를 개발자가 로컬에서 재사용한다.
# 입력이 같으면 실행 없이 캐시에서 즉시 반환
build ui-lib → cache HIT (재사용)
build web-app → cache MISS (실제 실행 후 저장)나는 이 원격 캐시를 처음 붙였을 때의 충격을 기억한다. 방금 브랜치를 새로 받았는데 빌드가 몇 초 만에 끝났다. 내 동료가 이미 만든 결과를 통째로 내려받은 것이다.
비교로 정리
| 항목 | 모노레포 | 다중 저장소 |
|---|---|---|
| 공용 코드 변경 | 한 커밋에 원자적 | 버전 올려 전파 |
| 일괄 리팩터링 | 쉬움 | 저장소마다 반복 |
| 빌드 관리 | 전용 도구 필수 | 저장소별 독립 |
| 권한 분리 | 세분화 필요 | 저장소 단위로 자연스러움 |
모두를 위한 답은 아니다
솔직히 말하면 모노레포가 만능은 아니다. 도입에는 전용 빌드 도구와 캐시 인프라가 필요하고, 이걸 세팅하고 유지하는 데 사람이 든다. 저장소가 작고 팀이 독립적으로 굴러간다면 굳이 이 복잡함을 떠안을 이유가 없다. 조직 규모, 코드 공유의 정도, 팀 간 결합도를 보고 판단할 문제다.
다만 확실한 건, 원격 캐시와 의존성 그래프라는 도구가 성숙하면서 모노레포의 진입 장벽이 크게 낮아졌다는 점이다. 예전엔 거대 기업만의 사치였던 방식이, 이제는 중간 규모 팀도 현실적으로 택할 수 있는 선택지가 됐다.
자주 묻는 질문
모노레포와 모놀리스는 같은 말인가요?
아니다. 모노레포는 코드를 어떻게 저장하느냐의 문제고, 모놀리스는 애플리케이션을 어떻게 배포하느냐의 문제다. 한 저장소 안에 여러 개의 독립적인 마이크로서비스를 두는 것도 얼마든지 가능하다.
원격 캐시가 왜 그렇게 중요한가요?
대규모 저장소에서 매번 전부 빌드·테스트하는 건 비현실적이기 때문이다. 이미 계산한 결과를 팀과 CI가 공유해 재사용하면, 실제로 바뀐 부분만 처리하면 되므로 전체 시간이 극적으로 줄어든다.
작은 팀도 모노레포를 써야 하나요?
반드시 그럴 필요는 없다. 코드 공유가 적고 팀이 독립적이라면 다중 저장소가 단순하고 편하다. 공용 코드가 많고 여러 프로젝트가 얽혀 함께 움직여야 할 때 모노레포의 이점이 커진다.
모노레포에서 배포는 어떻게 하나요?
저장소가 하나여도 프로젝트별로 독립 배포가 가능하다. 의존성 그래프로 바뀐 프로젝트만 골라 배포 파이프라인을 태우는 방식이 일반적이며, 이 선택적 실행이 모노레포 도구의 핵심 기능 중 하나다.
댓글 0