모노레포 vs 폴리레포 비교: 데이터로 결정하는 리포지토리 전략

모노레포 vs 폴리레포 비교의 답은 권장사항이 아니라 측정값이다. 구체적으로: 기능 중 몇 퍼센트가 둘 이상의 서비스 경계를 넘어야 하는가?

이 수치를 모른다면, 데이터가 아닌 팀의 선호도로 인프라 결정을 내리는 것이다. 50명 규모의 엔지니어링 조직에서 그 선호도는 누군가의 일요일을 앗아가게 된다.

핵심은 계산이다. 두 접근 방식 모두 비용을 수반한다. 문제는 어느 비용을 조직이 더 잘 흡수할 수 있는가다. 폴리레포의 조율 세금인가, 아니면 모노레포의 툴링 투자인가.

PR 사이클 타임 데이터가 말해주는 것, 그리고 말해주지 않는 것

Faros AI는 320개 엔지니어링 팀을 12개월 동안 분석했다. 모노레포 환경의 PR 중간 사이클 타임은 19시간, 폴리레포는 2시간이었다.

중간값 기준으로 9.5배 차이다. 90번째 백분위수에서는 격차가 좁혀져 8.6일 대 5.5일이지만, 양쪽 꼬리 모두 느리다. 평균도 좁혀진다: 모노레포 3.6일, 폴리레포 2.8일.

반론은 잘 알려져 있다: 캐싱이 작동할 때 모노레포는 개별 빌드 시간이 빠르다. 5개 레포에 5개의 별도 CI 파이프라인과 5개의 CODEOWNERS 승인 요건을 갖춘 폴리레포 팀이 크로스 서비스 변경을 조율하면 2시간 안에 PR을 닫지 못한다.

데이터는 일반적인 PR의 사이클 타임을 캡처한 것이지, 최악의 크로스커팅 변경을 다루는 것이 아니다. 폴리레포 팀은 자신들의 중간값을 인용한다. 모노레포 지지자들은 레포 간 조율의 고통을 인용한다. 양쪽 모두 다른 시나리오에서 옳다.

데이터는 논쟁을 해결하지 않는다. 막연한 느낌보다 더 정확하게 트레이드오프를 기술할 뿐이다.

당신이 계산하지 않은 블래스트 래디어스

컨퍼런스 발표에서 거의 나오지 않는 내용이 있다. 모노레포에서 공유 의존성이 깨지면, 그것을 임포트하는 모든 서비스에 같은 커밋으로, 다운스트림 오너십을 가진 누군가가 변경사항을 검토하기 전에 영향이 미친다.

폴리레포에서는 깨진 패키지 버전이 그것을 업그레이드하는 서비스만 영향을 받는다. 그것도 업그레이드할 때만. 블래스트 래디어스는 소비자의 선택에 의해 지연되고 제한된다.

이것은 SLO 게이트 롤아웃에서 중요하다. 모노레포의 나쁜 공유 라이브러리는 카나리 창을 제공하지 않는다. 단일 배포 이벤트에서 크로스 서비스 블래스트 래디어스를 제공한다. 롤아웃 자동화가 패턴을 감지하고 리버트를 트리거하기 전에 여러 SLO에 걸쳐 에러 버짓이 동시에 소진된다.

폴리레포에서 공유 의존성 변경의 롤아웃은 본질적으로 순차적이다. 서비스 A가 업그레이드하고 SLO를 지켜본다. 서비스 B는 3일 후에 업그레이드한다. 어느 순간이든 블래스트 래디어스는 이미 변경사항을 채택한 서비스에 의해 제한된다.

질문은 어떤 구조가 본질적으로 더 안전한가가 아니다. 배포 프리미티브가 무엇인가다. 배포 단위가 자체 SLO 게이트를 가진 서비스라면 폴리레포가 자연스러운 격리를 제공한다. 배포 단위가 프론트엔드, API, 백그라운드 워커에 걸쳐 일관되게 착지하는 아토믹 기능 변경이라면 모노레포가 버저닝 드리프트 없이 그 조율을 제공한다.

폴리레포 팀이 엔지니어 50명 규모에서 조율 벽에 부딪히는 이유

조율 세금은 복리로 증가한다. 엔지니어 8명일 때 4개의 레포를 관리하는 것이 귀찮지만 가능하다. 50명에서는 여러 사람의 파트타임 업무가 된다.

폴리레포 조율 오버헤드가 구조적이 되었다는 구체적인 신호들:

• 플랫폼 팀이 명확한 오너십 없는 공유 라이브러리 레포를 관리하고 있다

• 서비스 간 버저닝이 충분히 드리프트되어 공유 라이브러리를 올리는 것이 2주짜리 프로젝트다

• 새 엔지니어가 23개 레포 중 어느 것을 먼저 클론해야 할지 이해 없이는 생산적이 될 수 없다

• 공유 의존성에 대한 보안 패치가 추적 스프레드시트를 동반한 12개 레포에 걸친 조율 PR을 필요로 한다

이것들은 상상의 병리가 아니다. 80명 엔지니어에 달했다가 레포 결정을 후회하며 돌아본 팀들에서 기록된 실패 모드다.

폴리레포는 팀들이 진정으로 독립적일 때 작동한다. 다른 릴리스 사이클, 다른 기술 스택, 다른 온콜 로테이션. 한 서비스의 변경이 다른 서비스 3개에 대한 추론을 필요로 할 만큼 팀들이 충분한 코드를 공유할 때, 폴리레포가 제공한 격리는 조율을 고통스럽게 만드는 메커니즘이 된다.

조직적 신호는 이것이다: 크로스 레포 릴리스를 조율하기 위해 존재하는 Slack 채널이 몇 개인지 세어보라. 답이 0보다 크다면 조율 세금을 꾸준히 내고 있는 것이다.

모노레포가 95번째 백분위수에서 실제로 치르는 비용

Faros AI의 P90 데이터는 시사적이다: 90번째 백분위수에서 모노레포 PR 8.6일. 느린 팀이 아니다. 여러 코드 오너, 더 넓은 CI 매트릭스, 조직 경계를 넘는 리뷰 사이클을 요구하는 대규모 크로스커팅 변경의 구조적 결과다.

구글은 Bazel을 가지고 있다. 메타는 Buck을 만들었다. Nx Cloud와 Turborepo 원격 캐시는 모노레포를 성능 있게 만드는 툴링 투자가 사소하지 않기 때문에 존재한다. 영향 받는 빌드 선택, 분산 캐싱, 자동화된 머지 큐 없이 엔지니어 200명에서의 모노레포는 공유 유틸리티 함수에 닿는 PR에서 45분 CI 실행을 생산한다.

툴링 비용은 실재하며 일상적으로 과소평가된다. 규모에서 성공적으로 모노레포를 운영하는 팀들은 일반적으로 그 인프라에 특별히 집중하는 플랫폼 엔지니어를 고용했다. 성장하는 코드베이스에 모노레포 툴링을 후속으로 갖추면서 제품도 출시하는 것은 포스트모텀에서 보이기 전에 배포 빈도에서 나타나는 소모다.

플랫폼 팀이 이미 과부하 상태라면 모노레포 툴링 유지보수 추가는 구성 선택이 아니라 의미 있는 약속이다.

고성능 팀이 실제로 사용하는 30% 법칙

이 결정을 신중하게 내린 팀들의 유용한 경험칙: 기능의 30% 이상이 여러 서비스 경계에 걸친 변경을 요구한다면 폴리레포의 조율 오버헤드가 결국 잘 운영되는 모노레포의 툴링 투자를 초과한다.

30% 미만이면 대부분의 마이크로서비스 조직이 여기에 해당한다. 폴리레포의 격리 이점이 보통 조율 세금보다 크다. 크로스 서비스 변경은 발생하지만 공유 툴링이 격리보다 더 빨리 회수될 만큼 빈번하지 않다.

이것은 측정 가능하다. 지난 6개월의 병합된 PR을 가져와서 단일 사용자 대면 기능을 출시하기 위해 둘 이상의 레포에서 변경이 필요했던 수를 세어라. 그 비율이 입력값이다. 소수점까지 정밀하지는 않겠지만 방향성은 알 수 있다. 방향성만으로도 팀 선호도로 논쟁이 진행되는 것을 막기에 충분하다.

크로스 서비스 비율이 12%인 팀은 모노레포가 필요 없다. 38%이고 증가 추세인 팀은 계속 복리로 증가할 조율 세금을 내고 있다.

롤아웃 전략이 계산을 어떻게 바꾸는가

거의 다루지 않는 이 결정의 차원이 있다: 롤아웃 프리미티브.

SLO 게이트와 함께 백분율 기반 롤아웃을 실행한다면, 기능을 트래픽의 5%에 출시하고 에러 버짓을 지켜보다가 점진적으로 확장한다면 블래스트 래디어스 계산은 기능이 하나의 서비스에 걸쳐 있는지 여러 서비스에 걸쳐 있는지에 따라 달라진다.

폴리레포에서 멀티 서비스 기능 롤아웃은 서비스 전반에 걸쳐 롤아웃 상태를 조율해야 한다. 서비스 A는 20%이고 서비스 B는 여전히 0%일 수 있어 인시던트 조건에서 추론하기 진정으로 어려운 일관성 없는 상태를 만든다. 피처 플래그가 도움이 되지만 롤아웃 진행에 대한 단일 출처 없이 크로스 서비스 플래그 상태를 여전히 관리해야 한다.

아토믹 커밋을 가진 모노레포에서 기능은 서비스 전반에 걸쳐 일관되게 착지한다. 롤아웃은 인프라 수준에서 여전히 백분율 기반일 수 있지만 배포가 발생하는 순간부터 코드는 일관적이다. SLO 게이트는 일관된 상태에 대해 실행된다.

아토믹 멀티 서비스 기능을 많이 다루고 SLO 위반 시 자동 롤백을 가진 점진적 롤아웃을 실행하는 팀들은 종종 모노레포의 일관성이 폴리레포에는 깔끔한 이름이 없는 인시던트 카테고리 전체를 제거한다는 것을 발견한다. 버그처럼 보이지만 실제로는 배포 조율 문제인 크로스 서비스 상태 분기 인시던트가 그것이다.

포스트모텀이 실제로 말할 내용

대부분의 엔지니어링 조직은 아무도 하이브리드라고 부르지 않는 하이브리드로 끝난다. 아키텍처 타협처럼 들리기 때문이다.

긴밀하게 결합된 제품 표면에는 하나 또는 두 개의 모노레포. 독립적인 배포 사이클, 자체 온콜 로테이션, 그리고 6개월 동안 공유 라이브러리 변경을 조율할 필요가 없었던 팀을 가진 진정으로 자율적인 서비스에는 별도의 레포.

현재 설정을 재검토할 신호:

• 크로스 서비스 변경 빈도가 30%를 넘었고 CI 런타임이 복리로 증가하고 있다

• 모노레포 툴링에 투자할 여력이 있는 플랫폼 엔지니어를 고용했다

• 블래스트 래디어스 인시던트가 폴리레포 격리가 거짓임을 드러냈다. 서비스들이 충분한 인프라를 공유해서 격리가 안전이 아니라 안도감을 제공하고 있었다

결정이 지금 당장은 괜찮다는 신호:

• 팀들이 진정으로 독립적이고 조율 오버헤드가 낮다

• 최악의 인시던트가 크로스 서비스 의존성 드리프트로 인한 것이 아니었다

• 제품 출시를 늦추지 않으면서 모노레포 툴링을 유지할 플랫폼 엔지니어링 역량이 없다

포스트모텀이 당신이 실제로 어느 상황에 있는지 말해줄 것이다. 그 문서는 보통 그것이 기술하는 시스템보다 앞서 작성된 아키텍처 결정 기록보다 더 솔직하다.