모노레포의 등장배경
모노레포(Monorepo)는 여러 개의 프로젝트 코드가 동일한 저장소에서 관리되는 소프트웨어 개발 전략입니다. 글로벌 테크 기업들인 Google, Facebook, Microsoft, Uber, Airbnb, 그리고 Twitter 등은 이미 대규모 모노레포 시스템을 운영하며, 각각의 독특한 운영 전략을 가지고 있습니다.
모노레포가 등장하기 전에, 대부분의 프로젝트가 선택했던 방식은 멀티레포(Multirepo)였죠. 멀티레포는 여러 개의 저장소를 각각 독립적으로 관리하는 방식으로, 각 프로젝트가 개별적인 저장소에 존재합니다. 이는 오늘날 대부분의 애플리케이션 개발에서 사용되는 표준적인 방법이기도 합니다.
멀티레포의 문제점
멀티레포는 각 프로젝트가 독립적인 저장소를 가진다는 점에서, 여러 가지 문제를 동반할 수 있습니다. 예를 들어, 하나의 서비스가 웹, 앱, 공통 디자인 시스템 등을 갖추고 있다면, 각 부분에 대해 별도의 리포지토리를 관리해야 하므로 다음과 같은 문제가 발생합니다.
-
번거로운 프로젝트 생성
새로운 공유 패키지를 만들 때마다, 저장소 생성부터 커밋, 개발 환경 구축, CI/CD 설정, 빌드, 패키지 저장소에 퍼블리싱까지 여러 단계를 거쳐야 합니다. 이는 많은 시간과 노력을 소모합니다. -
중복 코드와 관리 부담
각 프로젝트가 공통 구성 요소를 자체적으로 구현하는 경우, 초기 개발 속도는 빠를 수 있지만 시간이 지날수록 보안 및 품질 관리의 부담이 커집니다. -
관리 포인트의 증가
프로젝트가 많아지면 그만큼 관리해야 할 포인트가 늘어납니다. 린트, 테스트, 빌드, 배포 등 동일한 작업을 각 저장소에서 반복해야 하므로 관리의 효율성이 떨어집니다. -
일관성 없는 개발자 경험(DX)
각 프로젝트가 고유한 빌드, 테스트, 린트 명령어를 사용하면, 여러 프로젝트를 넘나드는 개발자에게 정신적 오버헤드가 발생할 수 있습니다. -
변경 사항 추적의 어려움
서로 다른 저장소에서 작업하고 있기 때문에, 관련 패키지 간의 변화를 추적하고 반영하는 데 어려움이 있습니다. -
교차 저장소 리팩터링의 비용
여러 저장소에 걸쳐 리팩터링을 해야 할 경우, 이를 관리하는 데 드는 시간과 비용이 커집니다.
서비스가 커질수록 이러한 멀티레포의 문제는 점점 더 복잡해지고, 각 모듈의 의존성에 따라 업데이트 시간이 길어집니다. 그렇다면 어떻게 하면 모듈을 적절히 분리하면서도, 테스트, 빌드, 배포 등을 효율적으로 처리할 수 있을까요? 바로 이때 모노레포가 등장합니다.
모노레포(Monorepo)란?
모노레포는 여러 개의 프로젝트가 동일한 저장소에서 관리되는 소프트웨어 개발 전략입니다. 앞서 언급한 멀티레포와 달리, 모노레포는 저장소를 하나로 통합하여 여러 프로젝트를 관리할 수 있게 해줍니다. 이렇게 함으로써, 여러 프로젝트가 공통된 환경에서 동작하게 되고, 그로 인해 여러 가지 이점이 생깁니다.
모노레포가 해결하는 멀티레포의 문제들
모노레포는 멀티레포에서 발생하는 문제를 해결하며, 프로젝트 관리와 개발 환경을 한층 개선할 수 있습니다. 주요 해결점을 살펴보겠습니다.
-
더 쉬운 프로젝트 생성
멀티레포에서는 새로운 프로젝트를 시작하려면 저장소를 생성하고, 커밋을 추가하며, 개발 환경과 CI/CD, 빌드 등을 다시 설정해야 합니다. 그러나 모노레포에서는 이미 공통된 환경이 준비되어 있기 때문에, 새로운 프로젝트를 시작할 때 추가적인 설정 없이 쉽게 진행할 수 있습니다. -
더 쉬운 의존성 관리
여러 프로젝트가 동일한 저장소 내에 있기 때문에, 의존성 관리가 매우 간편합니다. 별도로 패키지를 퍼블리싱하거나 버전을 관리할 필요 없이, 동일한 저장소 내에서 모든 패키지의 의존성을 직접 관리할 수 있습니다. -
단일화된 관리 포인트
개발 환경과 DevOps 시스템을 한 곳에서 관리할 수 있기 때문에, 관리해야 할 포인트가 단일화됩니다. 업데이트나 변경 사항을 한 번에 적용할 수 있어 관리가 더 효율적입니다. -
일관된 개발자 경험 제공
모든 프로젝트가 동일한 환경에서 동작하므로, 개발자들이 각기 다른 프로젝트에 기여할 때 일관된 개발자 경험(DX)을 제공합니다. 다양한 프로젝트에서 사용되는 명령어 집합이 동일하므로, 새로운 프로젝트를 맡았을 때 정신적 오버헤드가 줄어듭니다. -
원자적 커밋
모노레포에서는 하나의 커밋이 모든 프로젝트에 일관되게 적용됩니다. 이로 인해 변경 사항이 영향을 미치는 모든 조직에서 쉽게 변화를 확인할 수 있습니다. -
교차 저장소 리팩터링 비용 절감
여러 저장소에 걸친 리팩터링을 쉽게 할 수 있으며, 100개의 라이브러리와 10개의 앱이 있을 때도, 모노레포는 이를 효율적으로 관리할 수 있게 해줍니다.
모노레포에 대한 오해
모노레포가 항상 멀티레포보다 우수한 방식일까요? 답은 아니오입니다. 모노레포와 멀티레포는 장단점이 뚜렷하게 교차하므로, 각각의 방식이 적합한 상황에서 사용해야 합니다. 모노레포가 적합한 상황은 다음과 같습니다:
-
유사한 제품 집합
같은 종류의 프로젝트들이 함께 있는 경우. -
여러 프로젝트의 변화를 동시에 관리해야 할 때
다양한 프로젝트에서 일어나는 변경 사항을 한눈에 파악할 때 유리합니다. -
플러그인 형태로 애플리케이션을 확장할 때
동일한 기본 애플리케이션을 여러 플러그인으로 확장하는 경우. -
공통 기능을 재사용하는 프로젝트 집합
여러 프로젝트가 동일한 기능을 공유하는 경우. -
유사한 DevOps 환경을 갖춘 프로젝트들
DevOps 시스템이 비슷한 여러 프로젝트가 있는 경우.
모노레포 도입 전 고려할 점
모노레포를 도입할 때는 위와 같은 장점 외에도 몇 가지 고려해야 할 점들이 있습니다. 예를 들어, 대규모 프로젝트에서는 저장소 크기가 커질 수 있고, 이를 관리하는 데 필요한 도구들이 복잡해질 수 있습니다. 그렇지만, 모노레포는 프로젝트 간의 의존성을 간소화하고 개발 효율성을 높일 수 있는 유효한 전략입니다.
실제 사례를 통해 배우기
모노레포를 다룬 이론만으로는 이해가 부족할 수 있습니다. 실제로 Turborepo와 같은 도구를 사용해 모노레포 환경을 구축하며, 그 장점을 직접 경험하는 것이 중요합니다. 다음 글에서는 Turborepo를 적용해 보며 모노레포의 실용적인 면을 살펴보겠습니다.
