테마
모놀리식 vs 마이크로프론트엔드: 8가지 기준으로 비교
모놀리식 프론트엔드와 마이크로프론트엔드를 8가지 핵심 기준으로 비교하여 각각의 특성을 이해한다.
학습 목표
- 모놀리식 프론트엔드와 마이크로프론트엔드의 차이를 8가지 기준에서 설명할 수 있다
- 각 아키텍처가 유리한 상황과 불리한 상황을 구분할 수 있다
- 시스템 규모에 따라 아키텍처의 장단점이 어떻게 변하는지 이해한다
- 커뮤니케이션 비용 증가가 아키텍처 선택에 미치는 영향을 파악한다
현재 프론트엔드의 현실
현재 대부분의 프론트엔드 프로젝트는 모놀리식 단일 코드베이스로 개발된다. React SPA, Next.js, Vue + Nuxt 등으로 만든 하나의 큰 애플리케이션이 전체 UI를 담당하는 구조다.
이 구조는 익숙하고, 도구 생태계가 성숙해 있으며, 학습 자료가 풍부하다. 하지만 시스템이 성장하고 팀이 커지면서 다양한 문제가 발생한다.
이제 두 아키텍처를 8가지 기준으로 비교해보자. 이 비교는 상대적이고 일반화된 것이며, 실제 상황은 구현 방식과 팀 역량에 따라 달라질 수 있다.
8가지 비교 기준
위 도표에서 볼 수 있듯이, 초기 단계에서는 모놀리식이 유리한 항목이 3개, 마이크로프론트엔드가 유리한 항목이 5개다. 하지만 핵심은 이 비교가 시스템 규모에 따라 달라진다는 점이다.
기준 1: 초기 개발 속도
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 빠름 | 느림 |
| 이유 | 사전 작업 불필요 | 설계/설정에 시간 소요 |
모놀리식 프론트엔드:
create-react-app, npx create-next-app, npm create vue@latest 등의 명령 하나로 프로젝트를 시작할 수 있다. 별도의 아키텍처 설계 없이 바로 기능 개발에 들어갈 수 있다. 라우팅, 상태 관리, 빌드 설정이 하나의 프로젝트 안에서 간단하게 해결된다.
마이크로프론트엔드:
개발을 시작하기 전에 많은 설계 결정이 필요하다:
- 마이크로앱을 어떤 기준으로 나눌 것인가? (도메인, 페이지, 기능)
- 통합 방식은 무엇을 사용할 것인가? (Module Federation, iframe, Web Components)
- 공유 라이브러리는 어떻게 관리할 것인가?
- 마이크로앱 간 통신은 어떻게 할 것인가?
- 모노레포를 사용할 것인가, 멀티레포를 사용할 것인가?
이 결정들 하나하나가 시간과 노력을 필요로 한다.
기준 2: 빌드/배포 설정
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 단순 | 복잡 |
| 이유 | 하나의 파이프라인 | 여러 파이프라인 + 통합 전략 |
모놀리식 프론트엔드:
하나의 CI/CD 파이프라인이면 충분하다. npm run build 한 번으로 전체 애플리케이션이 빌드되고, 하나의 배포 경로로 배포된다.
마이크로프론트엔드:
각 마이크로앱마다 독립적인 빌드 파이프라인이 필요하다. 또한 다음과 같은 추가 설정이 필요하다:
- 모노레포 도구 설정 (Nx, Turborepo 등)
- 의존성 캐싱 전략
- 마이크로앱 간 버전 호환성 관리
- 통합 테스트 환경 구성
- 배포 순서와 롤백 전략
기준 3: 개발 환경
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 간단 | 복잡 |
| 이유 | 하나의 dev server | 여러 앱 동시 실행 필요 |
모놀리식 프론트엔드:
npm run dev 하나면 로컬 개발 환경이 준비된다. HMR(Hot Module Replacement)도 기본적으로 잘 동작하고, 디버깅도 하나의 애플리케이션 컨텍스트 안에서 수행된다.
마이크로프론트엔드:
전체 화면을 로컬에서 보려면 여러 마이크로앱을 동시에 실행해야 한다. 셸 애플리케이션과 개별 마이크로앱의 개발 서버가 함께 돌아가야 하고, 이들 간의 연동 설정이 필요하다. 단, 특정 마이크로앱만 독립적으로 개발하는 경우에는 해당 앱만 실행하면 되므로 이 복잡도가 줄어들 수 있다.
기준 4: 커뮤니케이션 비용
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 규모에 따라 급증 | 비교적 일정 |
| 이유 | 팀 간 조율 비용 기하급수적 증가 | 팀 내부에서 대부분 해결 |
이 항목은 마이크로프론트엔드 도입을 결정하는 가장 핵심적인 기준 중 하나다.
모놀리식 프론트엔드에서의 커뮤니케이션 비용:
하나의 코드베이스에서 여러 팀이 작업할 때, 팀 수가 늘어나면 조율해야 할 관계의 수가 급격히 증가한다. n개의 팀이 있으면, 잠재적 커뮤니케이션 채널은 n(n-1)/2개다.
- 2개 팀: 1개 채널
- 3개 팀: 3개 채널
- 5개 팀: 10개 채널
- 10개 팀: 45개 채널
- 20개 팀: 190개 채널
여기에 코드 충돌, 빌드 큐 대기, 배포 일정 조율, 공유 라이브러리 변경 합의 등이 더해진다.
마이크로프론트엔드에서의 커뮤니케이션 비용:
각 팀은 자신의 마이크로앱에 대한 완전한 소유권을 갖는다. 팀 간 소통은 인터페이스(계약) 수준에서만 이루어진다. 새 팀이 추가되어도 기존 팀의 커뮤니케이션 비용은 거의 변하지 않는다.
모놀리식에서 팀 수가 2개에서 20개로 늘어나면 커뮤니케이션 비용이 190배로 증가한다. 반면 마이크로프론트엔드에서는 15~20배 수준에 머문다. 이 차이는 팀 규모가 커질수록 더욱 극적으로 벌어진다.
기준 5: 배포 시간
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 규모에 따라 느려짐 | 빠르고 일정 |
| 이유 | 전체 빌드/배포 필수 | 변경된 마이크로앱만 배포 |
모놀리식 프론트엔드:
코드베이스가 커질수록 빌드 시간이 길어진다. 작은 수정 하나를 배포하더라도 전체 애플리케이션을 빌드하고 배포해야 한다. 또한 여러 팀의 변경 사항이 하나의 배포에 묶이므로, 배포 일정 조율도 필요하다.
- 초기: 빌드 2분, 배포 5분
- 6개월 후: 빌드 5분, 배포 10분
- 1년 후: 빌드 15분, 배포 20분
- 2년 후: 빌드 30분 이상, 배포 30분 이상
마이크로프론트엔드:
변경된 마이크로앱만 빌드하고 배포하면 된다. 각 마이크로앱의 코드베이스는 작으므로 빌드 시간이 짧고 일정하게 유지된다. 다른 팀의 배포 일정과 무관하게 독립적으로 배포할 수 있다.
기준 6: 장애 범위
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 넓음 (전체 영향) | 좁음 (마이크로앱 수준) |
| 이유 | 하나의 런타임 공유 | 격리된 실행 환경 |
모놀리식 프론트엔드:
하나의 모듈에서 발생한 JavaScript 에러가 전체 애플리케이션을 먹통으로 만들 수 있다. 의존하는 공유 라이브러리의 버그가 모든 페이지에 영향을 준다. 하나의 잘못된 배포가 전체 서비스를 중단시킬 수 있다.
마이크로프론트엔드:
적절히 설계하면, 하나의 마이크로앱에서 발생한 장애가 다른 마이크로앱에 영향을 주지 않는다. 검색 기능에 문제가 생겨도 결제 기능은 정상 동작할 수 있다. 다만, 이를 위해서는 에러 경계(Error Boundary) 와 장애 격리 설계가 필수적이다.
기준 7: 자율성
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 낮음 | 높음 |
| 이유 | 공유 코드베이스의 제약 | 독립적 의사결정 가능 |
모놀리식 프론트엔드에서 제한되는 것들:
- 기술 선택: 전체 프로젝트가 하나의 프레임워크에 묶인다 (React면 전부 React)
- 배포 주기: 다른 팀의 작업이 완료될 때까지 기다려야 할 수 있다
- 라이브러리 버전: 모든 팀이 동일한 라이브러리 버전을 사용해야 한다
- 코딩 컨벤션: 모든 팀이 동일한 규칙을 따라야 한다
- 릴리즈 일정: 전체 프로젝트의 릴리즈 일정에 맞춰야 한다
마이크로프론트엔드에서 가능한 것들:
- 팀별로 최적의 기술 스택 선택
- 독립적인 배포 주기 결정
- 팀 내에서 라이브러리 버전 관리
- 팀별 코딩 컨벤션 설정
- 독립적인 릴리즈 스케줄
기준 8: 확장성
| 모놀리식 | 마이크로프론트엔드 | |
|---|---|---|
| 평가 | 제한적 | 유연함 |
| 이유 | 코드베이스 커질수록 한계 도달 | 마이크로앱 추가로 확장 |
모놀리식은 코드베이스가 커지고 팀이 늘어나면 점점 한계에 도달한다. 마이크로프론트엔드는 새로운 비즈니스 요구가 있을 때 새 마이크로앱을 추가하는 방식으로 유연하게 확장할 수 있다.
시스템 규모에 따른 역학 변화
핵심 통찰:
마이크로프론트엔드의 8가지 비교에서 가장 중요한 점은, 이 비교가 정적이지 않다는 것이다. 시스템의 규모와 팀의 크기에 따라 유불리가 역전된다.
모놀리식이 유리한 3가지 항목(초기 개발 속도, 빌드/배포 설정, 개발 환경)은 시스템 규모와 관계없이 대체로 모놀리식이 간단하다. 이것이 초기에 모놀리식을 선택하는 강력한 이유가 된다.
마이크로프론트엔드가 유리한 5가지 항목(커뮤니케이션 비용, 배포 시간, 장애 범위, 자율성, 확장성)은 시스템이 커질수록 그 이점이 더욱 두드러진다. 시스템이 충분히 커지면 이 5가지 이점이 모놀리식의 3가지 장점을 압도한다.
전환 시점의 판단:
모놀리식에서 마이크로프론트엔드로의 전환을 고려해야 하는 신호들:
- 배포 때마다 여러 팀의 일정을 조율해야 한다
- 하나의 팀의 변경이 다른 팀의 기능에 영향을 준다
- 빌드 시간이 10분을 넘긴다
- 새로운 기능 추가에 걸리는 시간이 점점 늘어난다
- 배포 후 장애 발생 시 전체 서비스에 영향이 간다
- 새로운 팀원의 온보딩에 오래 걸린다 (코드베이스가 너무 커서)
- 기술 부채 해소를 위한 리팩터링이 점점 어려워진다
핵심 정리
| 비교 기준 | 모놀리식 | 마이크로프론트엔드 | 규모 영향 |
|---|---|---|---|
| 초기 개발 속도 | 빠름 | 느림 | 규모 무관 |
| 빌드/배포 설정 | 단순 | 복잡 | 규모 무관 |
| 개발 환경 | 간단 | 복잡 | 규모 무관 |
| 커뮤니케이션 비용 | 기하급수적 증가 | 비교적 일정 | 규모 커질수록 MFE 유리 |
| 배포 시간 | 규모에 비례 증가 | 빠르고 일정 | 규모 커질수록 MFE 유리 |
| 장애 범위 | 전체 영향 | 마이크로앱 수준 | 규모 커질수록 MFE 유리 |
| 자율성 | 낮음 | 높음 | 규모 커질수록 MFE 유리 |
| 확장성 | 제한적 | 유연함 | 규모 커질수록 MFE 유리 |
한 줄 요약: 마이크로프론트엔드는 초기 비용이 크지만, 시스템이 커질수록 모놀리식 대비 이점이 기하급수적으로 증가한다. 아키텍처 선택은 현재 규모와 성장 전망을 함께 고려해야 한다.
다음 단계
모놀리식과 마이크로프론트엔드의 전반적인 비교를 마쳤다. 다음 장에서는 마이크로프론트엔드 도입 시 기대할 수 있는 8가지 구체적인 장점을 하나씩 심층 분석한다.