모노레포 도입 검토서 작성법과 템플릿

묶는 이유를 측정값으로 쓰기

“관리가 편해서”는 검토 이유가 되지 못합니다. 어떤 작업이 여러 저장소를 오가며 얼마나 걸리는지, 함께 바뀌는 파일이 몇 번이나 되는지를 적습니다. 이 사이트에 모인 모노레포 주제 글은 3편이고, 그 가운데 전환 사례가 2편입니다.

전환 사례에서 무엇을 봤는가

컬리는 프론트엔드 모노레포에서 Nx를 메이저 버전 여러 단계 올리면서 런타임까지 바꿨습니다. 검토서에는 “모노레포 도구를 올린다”가 아니라 “버전 단계마다 무엇을 검증했는가”를 적어야 합니다.

CyberAgent는 광고 모노레포에서 Go 1.27 업데이트의 영향을 검증했습니다. 모노레포는 한 번의 언어 버전 변경이 여러 서비스에 동시에 닿는다는 점을 검토서에 명시해야 합니다.

CI 시간을 줄이는 방법 확인하기

모노레포의 가장 큰 비용은 전체 테스트를 매번 돌리는 것입니다. 스트라이프는 5천만 줄 규모의 Ruby 모노레포에서 바뀐 부분에 관련된 테스트만 골라 실행하는 방식을 공유했습니다. 검토서에는 “테스트 선별을 하는가”를 항목으로 두고, 선별 기준이 틀렸을 때 놓치는 범위를 함께 적습니다.

되돌림 조건 정하기

모노레포는 한 번 묶으면 되돌리는 비용이 큽니다. 빌드 시간 목표를 숫자로 정하고, 목표를 몇 주 연속 넘기면 다중 저장소로 되돌린다는 조건을 검토서 첫 장에 적습니다.

템플릿(복사용)

## 1. 묶으려는 대상과 이유

- 함께 바뀌는 코드, 독립 배포가 필요한 코드

## 2. 현재 병목

- 빌드 시간, 테스트 시간, 권한 문제 (측정값으로 적기)

## 3. 선택지

| 선택지 | 장점 | 비용 | 되돌리기 |
|---|---|---|---|
| 모노레포 | | | |
| 다중 저장소 유지 | | | |

## 4. 전환 계획

- 단계, 빌드 캐시, 소유권 규칙

## 5. 성공 지표와 되돌림 조건

- 빌드 시간 목표, 실패 시 되돌릴 조건