monorepo vs polyrepo — 작은 팀의 결론

monorepo냐 polyrepo냐는 팀마다 다른 답이 나오는 주제다. 우리 팀도 두 방식을 모두 써봤고, 지금은 나름의 기준이 생겼다. 정답이 아니라 우리에게 맞는 답이다.

먼저 써본 것은 polyrepo였다

처음에는 각 서비스마다 저장소를 따로 뒀다. 백엔드, 프론트엔드, 인프라 스크립트가 각각 분리되어 있었다. 각 저장소가 독립적으로 배포되고 버전 관리가 된다는 게 장점처럼 느껴졌다.

그런데 얼마 지나지 않아 불편함이 쌓이기 시작했다. 공통으로 쓰는 타입 정의나 유틸 함수를 수정할 때, 어느 저장소에 있는 것을 고쳐야 하는지 헷갈렸다. 인터페이스가 바뀌면 연관된 저장소들을 하나씩 열어서 맞춰야 했다. 3명이서도 충분히 귀찮은 일이었다.

전환을 결정한 직접적인 계기는 “이거 왜 아직도 안 맞아?” 하는 상황이 반복됐을 때였다. 백엔드에서 응답 필드 이름을 바꿨는데 프론트엔드에 반영이 안 된 채로 배포됐다. 두 저장소가 분리되어 있으니 한쪽 PR이 머지됐어도 다른 쪽은 모르는 상태였다.

monorepo로 합친 뒤 가장 먼저 달라진 것은 변경 가시성이었다. 백엔드와 프론트엔드가 같은 PR 안에 있으니 리뷰할 때 양쪽을 함께 볼 수 있었다. 타입 공유도 쉬워졌다. 공통 패키지를 따로 배포하지 않아도 됐다.

팀이 작을수록 컨텍스트 스위칭 비용이 비싸다. 3명이서 여러 저장소를 오가며 일하면 “지금 어디서 뭘 고쳐야 하지”를 파악하는 데 시간이 쓰인다. monorepo는 그 시간을 줄여준다.

공통 린트, 포매터, CI 설정을 한 곳에서 관리할 수 있다는 것도 실질적인 이점이다. polyrepo에서는 같은 설정을 여러 곳에 복사해서 유지해야 하는데, 하나를 고치면 나머지는 자연스럽게 뒤처진다.

모든 게 좋지는 않다. 저장소가 커질수록 빌드 시간과 CI 시간이 늘어난다. 완전히 다른 언어나 기술 스택을 쓰는 팀이 합쳐지면 도구 통합이 어려워진다. 서비스 간 독립 배포가 필요해지면 monorepo에서의 파이프라인 관리가 polyrepo보다 복잡해지기도 한다.

우리 팀의 현재 결론은 이렇다. 팀이 작고, 서비스 간 코드 공유가 있고, 함께 배포되는 경우가 많다면 monorepo가 낫다. 팀이 커지거나 서비스가 완전히 독립된 수명 주기를 갖게 되면 그때 다시 분리를 고려한다.

지금 당장의 편의성을 기준으로 선택하는 것이 가장 현실적이다.

— by slecs