이번에 진행한 사이드 프로젝트에서 소비자(피커) 서비스와 공급자(메이커) 서비스를 하나의 앱에서 제공하기로 결정했는데, 개발환경 및 디자인이 둘 모두 동일하기에 모노레포를 적용하면 좋겠다는 생각이 들었습니다. 그래서 제가 간략하게 알고 있던 모노레포에 대해 더 자세히 알아보고 현 상황에 적용하는게 맞는지 알아보고자 합니다!
모노레포란 무엇인가?
모노레포란 여러 프로젝트나 라이브러리를 하나의 저장소에서 관리하는 단일 레포를 말합니다. 이를 통해 코드 공유와 의존성 관리가 용이해지고, 함께하는 개발자에게 일관된 개발 경험을 제공할 수 있습니다. 또한 다인 저장소로 모든 프로젝트르 관리하기 때문에 CI/CD 설정을 같이 가져갈 수 있습니다!
앞으로 현재 진행하는 프로젝트를 피커 서비스와 메이커 서비스로 구분하고, 앱으로 배포해 경쟁력을 가짐과 동시에 소규모 사장님들을 끌어모아 규모를 키워 주문 제작 케이크 시장을 점유하려면 그만큼 안정화 된 구조(유지보수성이 높고, 빠르게 코드를 파악해 발생한 에러의 원인을 해결할 수 있는 구조)가 필요합니다. 그렇기에 모노레포를 도입하고자 합니다.
모노레포와 멀티레포
모노레포의 경험을 더 확실하게 이해하고자 멀티레포와 비교하며 알아보겠습니다.
모노레포는 앞서 말씀드렸다시피 여러 프로젝트를 하나의 저장소에서 관리하는 것을 말합니다. 그리고 멀티레포는 프로젝트별로 저장소를 따로 분리한 것을 말하죠 이러한 멀티레포가 나오게 된 배경에 대해 더 자세히 설명하겠습니다.
위와 같이 거대한 서비스를 개발하는 과정에서 모듈화를 통한 관심 분리는 필수적입니다. 위와 같은 상황에서 분리된 모듈을 사용할 또다른 어플리케이션을 만들어야 한다면, 각 모듈을 관리하기 위한 독자적인 저장소가 필요하겠죠? 그래서 나온 구조가 멀티레포입니다.
위와 같이 각 모듈마다 고유한 저장소를 가지는 독자적인 프로젝트가 되고, 각각 독립적으로 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재합니다. 이를 통해서 팀의 자율성을 보장할 수 있게 되었죠. 하지만 이는 고립에 의해 제공되는 자율성이기에 협업하는 과정에는 안 좋은 영향을 주었습니다.
[멀티레포의 문제]
- 프로젝트마다 통일되지 않은 컨벤션 사용하게 됩니다.
- 새로운 프로젝트를 구축하기 위한 비용이 많이 듭니다.
- 중복된 코드와 프로젝트 관리에 대한 비효율 발생 (동일한 코드를 공유하기 위해 중복, 동기화가 필요)
- 일관성 없는 DX(개발자 경험)
- 늘어난 프로젝트 저장소의 수만큼 관리 공수가 늘어납니다
모노레포는 이러한 문제를 어떻게 해결해 줄까요? 이를 알아보기 전에 모노레포의 정의를 조금 더 파헤칠 필요가 있습니다. 단순히 여러 프로젝트가 하나의 저장소를 이용한다고 해서 이를 모노레포 구조라고 부를 수 없습니다. 모노레포 내부에서는 프로젝트 사이의 의존성이 존재하거나 같은 제품군이거나 하는 정의된 관계가 존재하고, 이를 효율적으로 관리하기 위해 사용하는 것이 모노레포입니다. 즉 내부에 존재하는 각 프로젝트끼리 관계성이 있어야 의미가 있다는 것입니다.
모노레포를 이용함으로써 다음과 같은 이점을 얻을 수 있습니다.
[모노레포가 해결하는 멀티레포의 문제]
- 간편한 새로운 프로젝트 생성
- 통합된 버전 관리: 모든 프로젝트와 라이브러리가 하나의 저장소에 있어 버전 관리가 통합됩니다. 이를 통해 의존성 관리를 최소화하고 코드베이스 전반에 걸친 변경 사항을 쉽게 추척할 수 있습니다.
- 단일화된 관리 포인트
- 일관된 개발자 경험 제공
- 서로 의존하는 저장소들의 리팩토링 비용 감소
- 코드 재사용 및 협업 촉진
- 효율적인 CI/CD 통합
이러한 모노레포를 어떻게 적용하면 될지는 다음 포스팅에 적용 후 정리하여 작성하겠습니다!