99클럽 26일차 TIL: 아키텍처 패턴 - 모노레포

2024. 4. 29. 21:1199클럽/TIL

728x90
반응형

#1. 오늘의 학습 키워드

개발 아키텍처 패턴 중 모노레포에 대해


#2. 공부한 내용

1. 멀티레포

- MSA로 프로젝트를 진행할 때, 서비스 별 레포지토리를 별도로 가지게 되어서, 
레포지토리가 2개 이상일 때 멀티레포라고 부른다.
  • 요즘 어떤 프로젝트를 개발한다고 했을 때, 웬만해서는 MSA 멀티레포로 개발하게 된다.
    • 보통 프론트엔드, 백엔드 나눠서 진행하게 되기 때문.

1) 장점

  • MSA 의 장점과 거의 동일시하면 된다.
  • 독립적인 빌드, 배포로 인한 개발 생산성
  • 기술 스택의 다양성 등

2) 단점

  • 레포지토리가 많아질 수록, 매번 세팅에 대한 작업과, 패키지 관리에 대한 유지 비용이 든다.
  • 또한, 레포지토리 간 독립성에 의하여 오히려 중복되는 코드 부분이 많아질 수 있다.
    • 보통은 유틸에 관련 된 부분의 중복이 많아질 수 있다.
      • ex) 메일 전송 유틸, pdf 전환 유틸 등등

2. 모노레포

- 하나의 레포지토리를 사용하지만, 개별적인 패키지 관리 및 빌드 배포 사용이 가능한 구조: 모노레포
  • 모노레포는 모놀리식 아키텍처와 MSA 아키텍처와 동일 선상에 두고 비교하면 안 된다.
    • 모노레포는 MSA 아키텍처 구현을 좀 더 좋은 방식으로 하기 위한 것으로 생각하면 된다.

1) 장점

  • 기존 MSA의 대부분 장점을 가지고 있음
    • 서비스 별 빌드, 배포 가능
    • 서비스끼리의 영향이 크지 않음
  • 새로운 프로젝트를 생성하는 데에 오버헤드가 크지 않다.
  • 통합된 버전 관리에서 오는 편의성
  • 유틸 등 공통적인 부분에서의 코드 재사용 및 리소스 공유

2) 단점

  • 초기 세팅의 어려움
    • 모노레포 구조를 구현하기 위해서는 yarn, npm 등 패키지 관리 툴을 사용해야 한다.
  • 다른 서비스끼리 같은 패키지를 사용했을 때, 버전을 맞춰줘야 한다.


#3. 오늘의 회고

  • 우선 그동안 모노레포, MSA, 모놀리식을 같은 선상의 개념으로 생각했지만, MSA, 모놀리식은 개발 방법론에 가까운 것 같고, 모노레포는 MSA를 구현하기 위한 구조 중 하나로 스스로 정리를 했다.
    • MSA는 일반적으로 멀티레포 구조로 관리하는 게 일반적이고, 멀티레포 구조의 단점을 상쇄하고자 등장한 것이 모노레포 구조라고 생각하면 좋을 것 같다.
  • 개인적으로 본인이 이렇게 헷갈렸던 이유는, 처음 입사했을 때 회사에서 사용 중이던 프로젝트 구조는 MSA 모노레포 구조를 모방한 모놀리식 구조여서 그랬던 것 같다.
    • 입사한 지 얼마 안 됐을 때는 회사도 창업한 지 얼마 안 됐을 때라 초기 개발 중이어서 모놀리식 구조로 개발 생산성을 높이는 동시에, 레포지토리 내 코드 구조는 미리 모듈 별로 구분을 하고, 모듈 별로 프론트엔드, 백엔드를 나눈 후 실제로 모노레포 구조에서 쓰이는 패키지 관리자인 yarn 을 쓰고 있었다.
    • 그리고 추후 빠른 출시를 거쳐서 MSA로 변경할 생각이었다.
      • 그러나 node → spring 으로의 리팩토링 때문에 무산 되었다.
  • 그때 모노레포(와 거의 흡사한) 구조를 접하고 느낀 점:
    • 프로젝트 전체가 하나의 저장소로 관리되더라도 코드 구조가 명확하기에 의외로 복잡하진 않다.
    • 그리고 프론트, 백 가리지 않고 공통 된 부분을 가져다 쓸 수 있는 것은 장점이다.
    • 또한 단일 레포지토리에서 모든 코드 변경 사항을 관리하기에 깃 컨벤션 등 코드 컴토 프로세스를 통합할 수 있어서 서로의 진행 사항을 좀 더 명확히 알 수 있었다.
    • 그러나 결국 단일 디렉토리 하에 모든 코드가 있는 것이기에, 처음 접했을 때는 어지러울 수 밖에 없었다.
      • 디렉토리의 수 자체도 엄청 많았기 때문에.
728x90
반응형