Published on

MFA 구축하기 - 1. 레포지토리 환경

ma vs mfa

모놀리식 아키텍쳐

하나의 프로젝트로 구성된 어플리케이션 아키텍쳐이다. 프론트엔드 서비스의 규모가 크지 않을때, 빠르게 개발 후 운영을 시도할때 사용되는 단일 코드 베이스 구조를 말한다.

코드 공유가 쉽고 코딩 컨벤션 & 배포가 간편하다는 장점이 있어 일반적으로 서비스 초기에 많이 쓰인다. 하지만 여러팀으로 구성 될 정도로 서비스가 커졌을때 운영적인 측면에서 여러 문제가 발생할 수 있다.

예를 들어 어드민/상품/주문/결제 등의 큼직한 도메인이 여러개가 있을 경우 각 도메인의 결합력이 높다면 하나의 서비스에서 문제 발생시 다른 서비스에도 영향을 줄 수 있다. 또, 상품 서비스의 수정사항만 배포가 필요하더라도 전체 프로젝트를 빌드하게 되는등 배포시에도 비효율이 발생하고 프로젝트가 너무 커지면 실시간으로 개발하는데에 생산성에도 영향을 미칠 수도 있다.

마이크로 프론트엔드 아키텍쳐(MFA)

MFA는 서비스가 대규모화 되었을 경우 단점을 보완하기 위해 각 도메인 별로 비즈니스 영역을 모듈화해 완전히 독립적으로 운영하는 아키텍쳐를 말한다.

각 팀에서 자율적으로 코딩 컨벤션이나 개발 스택을 독립적으로 운용할 수 있고, 배포도 각 도메인별로 따로 진행 가능하다는 장점이 있다.

물론, 모놀리식의 코딩 컨벤션이 일관적이고, 배포가 간편하다는 장점이 정반대가 되어 MFA는 프로젝트가 분리되기 때문에 각 팀별로 코딩 컨벤션이 다를 수 있고, 모듈을 import하는 것에 대한 러닝커브 그리고 배포설정도 난이도가 높은 편이다. 하지만 계란을 한바구니에 담지 말라는 말이 있듯, 서비스가 어느정도 이상의 규모로 커지면 각 도메인 별로 분리해 위험부담을 나누는것이 운영측면에서 효과적이다.

레포지토리 환경 정하기 (멀티레포 vs 모노레포)

MFA 환경을 구축하는데 있어 첫번째 고려사항은 바로 레포지토리 구성이다. 하나의 host 레포지토리와 각 서비스별 별도의 레포지토리를 구성하는 멀티레포. 하나의 레포지토리에서 각 서비스별 프로젝트를 관리 하는 모노레포 두 방식이 많이 사용된다.

multi vs mono

멀티레포

하나의 host 레포지토리와 각 서비스별 별도의 레포지토리를 구성하는 방식을 말한다. 비교적 간단하게 MFA 환경을 구축할 수 있다.

  • 장점
    • 완전히 독립되어 수월한 패키지 관리 가능.
    • 빠른 CI/CD
    • 각 서비스별 의존 관계가 없기 때문에 추가/수정 등 운영 유지 보수 관리에 유연성이 뛰어남.
  • 단점
    • 높은 자유도 때문에 서비스별 갭이 차이가 커질 수 있어 적절한 관리가 필요함. (boiler plate 등과 같은 가이드라인 필요.)
    • 레포지토리 분리로 중복 코드가 많아짐. (module federation의 의존성 설정 등을 통한 중복 코드 관리가 필요.)

모노레포

하나의 레포지토리 내부에서 여러 프로젝ㅌ를 관리하는 방식을 말한다. (멀티레포의 장단점을 반대로 가지고 있다.)

  • 장점
    • 동일한 개발 환경 제공 가능.
      • eslint, build, unit test 등 동일한 개발 환경을 제공하고 node module도 한번의 설치로 세팅 가능.
    • 쉬운 package 공유
    • 단일 이슈 트래킹: 모노레포 내 연관된 패키지들의 이슈 트래킹이 수월.
    • 효율적인 의존성 관리
  • 단점
    • 레포지토리의 사이즈가 비대해짐
    • 느린 CI build
      • 초기엔 단점으로 작용했지만, build 해시를 비교하는 라이브러리등이 제공되는등 많은 부분에서 개선되고 있음.
    • 과도한 의존성 관계 발생할 위험성 존재.

실습해볼 레포지토리 환경 - 모노레포

하나의 도메인으로 배포 가능하고 동일한 개발 환경 제공 가능한 이점에서 모노레포 + 모듈 페더레이션 으로 다음 포스트 진행 예정.

이어지는 포스트

ref