728x90
반응형
SMALL
MSA 강의를 마치고 실습에 도전하려 하는 순간 바로 장애물이 하나 생겼다.
레포지터리를 어떻게 만들어야 하지....? 라는 고민이 생긴것이다. 검색해보니 모노 레포와 멀티 레포라는 두 가지 방식이 존재 했고 이에 대한 내용을 정리해보려고 한다.
멀티 리포
시스템상 각각의 서비스를 별도의 레포지터리로 만들어서 관리하는 방식이다. 서비스 간 연동이 소스 단위로 구성되지 않고, 별도의 폴더로 구성된다.
멀티 리포의 장점
- 모듈화 : 각 저장소가 독립적으로 관리되기 때문에, 프로젝트의 규모가 커지더라도 유지보수성이 향상되고 각각의 리포지터리의 책임관계(오너쉽)가 더 뚜렷하다.
- 더 쉬운 의존성 관리 : 각 저장소마다 별도의 의존성 관리를 하기 때문에 쉽게 관리할 수 있다.
- 원활한 협업 : 각 저장소는 모노레포보다 더 작은 규모로 관리되기 때문에, 개발자들이 동시에 작업을 하더라도 마스터 브랜치에 병합하는 과정에서 발생하는 충돌의 확률이 비교적 더 줄어든다.
- CI 및 테스트 : 모노 레포는 전체 프로젝트를 빌드하거나 배포해야 하지만, 멀티 레포는 일부분만 변경하여 배포하는 방식이 가능하다. 대규모 프로젝트에서는 프로덕션 배포 속도를 높일 수 있다.
멀티 리포의 단점
- 코드 재사용성 감소, 중복 코드 증가 : 다른 리포지터리의 코드를 사용하기 위해서 해야 하는 작업들이 증가한다. 동일한 코드를 두 번 이상 적어야 하는 일이 발생할 수 있다.
- 하나의 feature를 개발하기 위해 여러 리포지터리를 병합해야 할 수 있다.
- 프로젝트별 다른 버전 및 컨벤션 : 각 프로젝트마다 코드 컨벤션이 나뉠 수 있고, 사용하는 버전이 달라질 수 있어 충돌이 발생할 수 있다.
- 방치되는 프로젝트 발생 : 오랫동안 건드리지 않은 프로젝트들은 방치되는 경우가 생기며, 시간이 지날수록 레거시 프로젝트의 파악이 어려워 진다.
- 복잡성 증대 : 저장소 수가 많아질 수록 관리가 복잡해지며, 각 저장소마다 버전 및 의존성 관리가 필요하여 추가적인 시간과 노력이 필요하다.
모노리포
시스템의 각 서비스를 온전히 하나의 리포지터리에서 통합 관리한다. 두 개 이상의 프로젝트 코드가 하나의 리포지터리에 저장되는 방식이다.
구글, 페이스북 등의 대규모 기업들에서는 이 모노레포 방식을 사용하기도 한다. 한국에서는 토스가 대표적인 예시라고 한다.
모노 리포의 장점
- 전체 코드의 일관성 및 무결성 : 하나의 저장소에서 모든 코드를 관리하기 때문에, 일관성이 비교적 향상되는 특징이 있다. 동일한 코드 컨벤션을 가져갈 수 있다. 또한 모든 서비스가 올바른 상태를 유지할 수 있다.
- 공유 라이브러리 : 여러 프로젝트에서 공유되는 라이브러리를 관리하는데 적합하다.
- 코드 공유 및 재사용 용이 : 소스 단위의 연동이 이루어진 상태이기 때문에 코드의 공유가 가능하다.
- 단일 버전 관리 : 모든 코드가 하나의 버전 관리 체계에서 관리되기 때문에, 멀티 레포에 비해 비교적 버전 충돌이 일어날 일이 적다.
- 최신화 상태 유지 : 많은 레포지터리가 멀티 레포로 형성되면 레거시 프로젝트가 생기기 마련이고 관리가 되지 않을 수 있으나, 모노 리포는 비교적 더 신경 쓸 수 있는 환경이다.
- 코드 협업 및 리뷰 : 하나의 리포지터리에서 한눈에 코드들을 확인 가능하기에, 자연스럽게 다른 프로젝트의 코드에 대한 리뷰가 가능한 환경이 구성된다.
모노 리포의 단점
- 무분별한 의존성 연결: 과도한 의존성 관계가 발생할 수 있다.
- 형상 관리 및 CI속도 저하 : 리포지터리의 스케일이 크기 때문에, 리포지터리 혹은 기반으로 동작하는 도구들의 속도가 비교적 느리다.
- 복잡성 증가 : 모든 코드가 하나의 저장소에 관리되기 때문에, 배포 프로세스가 더 복잡해 질 수 있다.
- 높은 러닝 커브 : 단일 저장소에서 새로운 개발자는 전체 코드베이스와 서로 다른 구성 요소 간의 의존성 관계를 이해해야 하기 때문에 어려운 작업이 될 수 있다.
내 프로젝트에는 어떤 전략이 적절할까?
사실상 지금 내 프로젝트 규모를 본다면 모노리딕 서버로 생성해도 상관은 없지만 MSA 실습이라는 목적에서 본다면 모노리포가 더 적절하다고 생각한다.
또한 앞으로도 모노 리포 방식을 더 선호할 것 같다. 코드의 복잡성이 방대하게 늘어날 상황이 생길 것 같지 않으며 나는 팀원간의 코드 리뷰를 중요시하기 때문이다. 내가 맡은 서비스 개발을 위해서는 다른 파트의 서비스 개발에 대한 로직도 충분히 알고 있어야 한다는 생각을 갖고 있기 때문이다.
728x90
반응형
SMALL
'Spring > Spring Cloud' 카테고리의 다른 글
[MSA - Resilienc4j] CircuitBreaker, fallback 메서드 개발하기 (0) | 2025.02.11 |
---|---|
[MSA - Spring Cloud] Spring Cloud Gateway 개발하기 (1) | 2025.02.08 |
[MSA] 멀티 모듈에서 중복되는 코드를 서브모듈끼리 공유하는 방법 (0) | 2025.02.08 |
[MSA - Spring Cloud] Eureka Client 개발하기(feat. FeignClient) (0) | 2025.02.07 |
[MSA - Spring Cloud] Eureka Server 개발하기(feat. Service Discovery란? 서버/클라이언트 사이드 디스커버리 전략) (0) | 2025.02.07 |