프론트엔드 모노레포(Mono-Repo) 도입 배경

모노레포로 가는 첫 번째 단계: 모놀리식에서 멀티레포로

 

현재 운영하고 있는 서비스의 초기 구성도입니다.

아주 오래전 20세기말(ㅋㅋ) 백과 프론트 소스가 뒤섞인 하나의 거대한 프로젝트로 시작한 서비스인데, 하나씩 리액트로 분리되어 나가는 과정에 합류하게 되었습니다. 3년 전 제가 팀에 합류할 당시 두 명의 프론트엔드 개발자가 서블릿과 리액트 프로젝트 7개를 넘나들며 개발하는 아주 혼란스러운 상황이었습니다.

자사에서 제공하는 상품은 크게 5개의 카테고리로 나뉘는데 이는 각각 별도의 리액트 프로젝트로 존재하고 있었고, 유저 전용 페이지는 2개의 리액트 프로젝트로 존재하고 있었습니다. 여기에 장바구니와 결제를 또 별도의 리액트 프로젝트로 떼어낼 거라는 로드맵까지.. 🫠

애자일 조직에서 이렇게 많은 프로젝트를 관리하는 것은 매우 비효율적이라고 느꼈습니다. (복붙을 통해) 빠르게 기능을 개발하지만, 정작 유지보수에 수십 배 더 많은 시간이 걸리는 것을 보고, 하루빨리 통합해야겠다는 결심을 하게 되었습니다.

모노레포로 가는 두 번째 단계: 멀티 레포의 일부 통합

상품 관련 리액트 프로젝트 ➡️ Product로 통합
장바구니와 결제 ➡️ Order로 통합
USER 전용 페이지 ➡️ USER로 통합

처음에는 최종적으로 총 3개의 프로젝트로 관리하는 것을 목표로 마이그레이션과 리팩토링 작업을 진행했습니다.
(+틈틈이 새로운 feature 개발도..)

긴 시간 끝에 관리 포인트는 줄었지만 여전히 유지보수와 새로운 feature 개발에 불편함은 있었습니다.

 

모노레포로 가는 세 번째 단계: 멀티 레포의 단점 분석

1. 중복 코드와 컴포넌트 재사용의 어려움

멀티 레포를 일부 통합하여 크게 3개의 카테고리로 나누더라도 결국 하나의 서비스 안에서 나누어지는 것이기 때문에 비즈니스 로직의 중복이 필연적으로 발생할 수밖에 없었습니다. 컴포넌트도 마찬가지였습니다. 일관된 사용성과 톤 앤 매너를 유지하기 위해 각 프로젝트별로 중복되는 컴포넌트를 생성할 수밖에 없었습니다. 이 과정에서 스토리북을 이용하기도 했지만 스토리북 또한 별도의 프로젝트로 관리를 해야 하기 때문에 이는 곧 유지 보수의 어려움으로 이어졌습니다.

2. 프로젝트마다 다른 컨벤션

예를 들어, 같은 react-hook-form 라이브러리를 사용하더라도, 각 프로젝트에서 사용하는 버전이 달랐습니다. 이로 인해 동일한 기능을 구현하면서도 각기 다른 방식으로 코드를 작성하게 되었습니다. 또한, 각 프로젝트마다 코드 스타일이나 컨벤션이 상이하여, 협업 시 코드의 일관성을 유지하기 어려웠습니다. 이러한 차이점들은 개발 및 유지보수 과정에서 추가적인 복잡성을 유발하고, 코드 통합 시 충돌이나 오류를 발생시킬 가능성을 높였습니다.

3. 프로젝트마다 다른 컨벤션

멀티 레포 구조에서는 각 레포지토리마다 별도의 빌드 및 배포 프로세스를 관리해야 합니다. 이로 인해 전체 서비스의 배포와 관련된 과정이 복잡해지고, 각 레포의 빌드와 배포 상태를 일관되게 유지하기가 어렵습니다. 또한, 레포 간의 의존성이 존재하는 경우, 의존성이 변경될 때마다 모든 관련 레포를 동기화하고 배포하는 데 추가적인 작업이 필요했습니다. 

 

결론

모노레포를 구성하고 프로젝트를 옮기는데 초기 비용은 많이 들겠지만 장기적으로 봤을 때 다음과 같은 이유로 모노레포가 적합하다고 생각했습니다.

1. 중복 코드와 컴포넌트 재사용 용이

모노레포에서는 여러 프로젝트가 동일한 레포지토리 내에서 관리되기 때문에, 공통 컴포넌트나 유틸리티 코드의 재사용이 훨씬 쉬워집니다. 중복 코드가 줄어들고, 유지보수가 간편해집니다.

2. 일관된 개발 환경

모노레포는 모든 프로젝트가 동일한 개발 환경과 설정을 공유하게 됩니다. 이로 인해 라이브러리 버전 관리가 일관되며, 코드 스타일과 컨벤션의 차이로 인한 문제를 줄일 수 있습니다.

3. 통합된 빌드 및 배포 프로세스

모노레포는 빌드 및 배포 프로세스를 통합하여 관리할 수 있습니다. 이를 통해 CI/CD 파이프라인을 일관되게 유지하고, 배포 과정의 복잡성을 줄이며, 모든 프로젝트의 상태를 중앙에서 관리할 수 있습니다.

4. 의존성 관리의 효율성

 모노레포에서는 여러 프로젝트 간의 의존성을 중앙에서 관리할 수 있어, 패키지 버전 충돌 문제를 줄이고, 모든 프로젝트가 최신 버전의 의존성을 공유할 수 있습니다.

 

이상 모노레포를 도입한 배경이었습니다. 
다음 포스팅에서는 모노레포 도입 과정에 대해 다뤄보겠습니다.