[Git] Monorepo

이전에는 monorepo 방식으로만 작업했었는데,
최근 백엔드 팀원과 다른 repository로 구분하여 작업하게 되어 두 방식을 비교해보았다.

Monorepo

Monorepo는 여러 패키지/서비스를 하나의 저장소에서 관리하는 방식이다.
공통 코드 공유와 버전 관리가 쉬워지지만, 빌드/테스트 비용이 커질 수 있다.

장점

• 공통 라이브러리 공유가 쉽다.
• 변경 이력과 의존성 추적이 단순해진다.
• 일관된 개발 규칙/도구를 유지할 수 있다.

단점

• 빌드/테스트 범위가 커져 느려질 수 있다.
• 접근 권한과 배포 흐름이 복잡해질 수 있다.

Multi-repo (Polyrepo)

Monorepo와 반대로, 하나의 프로젝트/서비스당 하나의 저장소를 운영하는 전통적인 방식이다.

장점

• 프로젝트 간의 코드 간섭이 전혀 없어 독립적인 배포와 개발이 가능하다.
• 해당 프로젝트의 코드만 빌드/테스트하면 되므로 초기 CI/CD 속도가 빠르다.
• 특정 팀원에게 특정 저장소의 접근 권한만 부여하기 쉽다.

단점

• 공통 로직(예: API 통신 모듈, UI 컴포넌트)을 매번 복사하거나 별도 라이브러리로 배포해야 한다.
• 공통 라이브러리 버전이 올라가면 이를 사용하는 수십 개의 저장소를 일일이 수정해야 한다.

구분	Monorepo	Multi-repo
코드 공유	매우 쉬움 (내부 참조)	어려움 (NPM 배포 등 필요)
의존성 관리	단일 버전 관리 (일관성)	저장소별 별도 관리 (파편화)
빌드 속도	프로젝트 규모에 따라 느려짐	각 저장소별로 매우 빠름
도구/설정	전사적으로 동일한 규칙 적용	프로젝트마다 제각각일 확률 높음

결론

두 가지 방식을 비교해본 결과, 결국 중요한 것은 운영 규칙이라고 느꼈다.

프론트엔드 개발자 3명이 각자의 범위를 나누어 모노레포로 작업했을 때는 공통 컴포넌트 재사용성 덕분에 작업이 효율적이었다. 하지만 프론트엔드 작업 중 실수로 백엔드 코드가 수정되어 이슈로 고생한 적이 있다. 이를 방지하려면 저장소 분리도 방법이지만, 모노레포 내에서 CODEOWNERS 같은 권한 설정과 엄격한 코드 리뷰 절차도 있음을 알게되었다.

이후 팀 프로젝트에 컨벤션 설정 단계에서 이러한 방법을 적용해 볼 것이다.