모노레포

모노레포와 폴리레포.

모노레포(Monorepo)는 버전 컨트롤 시스템에서 하나의 저장소에 여러 프로젝트의 코드를 모아서 관리하는 소프트웨어 개발 전략이다. 구글, 메타, 마이크로소프트와 같은 빅테크 기업들이 대규모 모노레포를 운영하고 있다.

배경

모노레포의 등장 배경은 모놀리식 애플리케이션의 한계로부터 출발한다. 소스 코드가 모듈화 없이 하나의 프로젝트로 구성된 모놀리식 애플리케이션은 관심사의 분리가 어려워지고, 배포 단위가 거대해지는 문제가 있다. 이러한 구조를 모듈화를 통해 해결했고, 하나의 애플리케이션을 구성하는 여러 모듈을 각각의 독자적인 저장소에 분리하는 폴리레포(Polyrepo)가 자연스럽게 도입됐다.

폴리레포는 각 저장소가 자기만의 개발, 테스트, 빌드, 배포 파이프라인을 갖는다. 만약 조직이 여러 팀으로 나뉘어 있다면, 폴리레포는 각 팀의 자율성을 보장할 수 있는 효과적인 방법이다. 콘웨이의 법칙에 따라 기업 규모가 작을 때는 하나의 저장소로 출발했다가, 코드베이스에 기여하는 개발자가 늘어나고 팀이 쪼개짐에 따라 저장소를 분리하는 전략이 대부분의 엔터프라이즈 애플리케이션에 표준적으로 자리잡았다.

그러나 시간이 지나며 폴리레포의 단점이 드러났다. 폴리레포 구조에서는 새로운 프로젝트를 생성할 때마다 저장소의 CI/CD 파이프라인을 새로 구축해야 하고, 각 저장소가 고립되어 중복 코드를 작성하게 된다. 또한 저장소가 늘어나는 만큼 관리 포인트가 증가하며, 만약 한 개발자가 여러 저장소에서 작업을 해야 한다면 작업량도 많을 뿐더러 일관된 개발자 경험을 제공하기도 어렵다. “자율성은 고립에 의해 제공되고, 고립은 협업을 방해한다.”

가능성과 한계

모노레포 구조에서는 새로운 프로젝트를 추가할 때 이미 구축된 파이프라인을 그대로 사용할 수 있다. 또한 모든 의존성 패키지가 같은 저장소에 있기 때문에 패키지 레지스트리에 공통 패키지나 라이브러리를 배포할 필요가 없다. 또한 관리 포인트가 하나로 통합되므로, 개발 환경에 대한 업데이트를 한번에 반영할 수 있고, 이를 통해 일관된 개발자 경험을 제공할 수 있다.

만약 저장소 내 프로젝트들 사이에 유사한 부분이 없거나, 공통 기능을 재사용하지 않는 경우, 프로젝트의 변화를 개발자들이 서로 알 필요가 없을 때는 모노레포가 부적절할 것이다. 저장소 크기가 커지면 성능이 저하되고, 구조가 복잡해질 수 있다. 저장소 내의 코드베이스에 대한 오너십 관리와 개별 프로젝트에 대한 독립된 배포 파이프라인도 필요하다. 모노레포에서 고려해야 하는 특유의 문제를 효과적으로 해결, 관리하기 위한 다양한 전략과 도구가 있다.

사례

구글

토스

그린랩스

참고자료

• monorepo.tools

관련문서

• 플랫폼 엔지니어링
• Git

이 문서를 인용한 문서

• 소프트웨어 공학
• Yarn

  • 특히 이는 모노레포에서 매우 유용하다.

• ESLint

  • 모노레포에서는 각 워크스페이스마다 구성 파일을 따로 두는 경우가 있는데, 플랫 구성에서는 명령을 실행한 위치에 따라 다른 구성 파일이 적용될 수 있어 주의해야 한다.

• 『Why Google Stores Billions of Lines of Code in a Single Repository』

  • 모노레포의 이점에 대해 이야기해보자:

  • 구글은 모노레포의 단점보다 장점에서 얻는 것이 많다고 판단했다.