마이크로 프론트엔드 아키텍처는 대규모 프론트엔드 애플리케이션을 여러 개의 작은 단위로 분리하여 개발하고 통합하는 방법입니다.
전통적인 모놀리식 프론트엔드(Monolithic Frontend)에서는 하나의 프론트엔드 애플리케이션이 모든 기능을 포함하여 한 번에 배포됩니다. 이는 개발과 배포가 단순하지만, 작은 변경에도 전체 애플리케이션을 다시 배포해야 하고, 하나의 거대한 코드베이스에서 여러 팀이 함께 작업할 경우 충돌이 발생하기 쉽습니다. 또한 모든 팀이 동일한 기술 스택을 사용해야 하므로 새로운 기술 도입이나 개별 최적화에 제약이 있습니다
이에 반해, 마이크로 프론트엔드(Micro Frontend)에서는 프론트엔드를 도메인이나 기능별로 잘게 나눈 독립적인 프론트엔드 모듈들로 구성합니다. 각 모듈은 자체 코드베이스와 빌드 파이프라인을 가지며, 독립적으로 개발·테스트·배포가 가능합니다. 다시 말해 “독립적으로 배포 가능한 여러 개의 프론트엔드 애플리케이션을 모아 전체 애플리케이션을 구성하는” 아키텍처입니다. 이러한 분산 구조 덕분에 필요에 따라 각 모듈마다 서로 다른 기술 스택을 사용할 수도 있어 전체 애플리케이션 내에서 기술 다각화를 허용합니다.
비교 항목 | 모놀리식 프론트엔드 | 마이크로 프론트엔드 |
---|---|---|
코드베이스 구조 | 하나의 거대한 저장소(repo) 또는 프로젝트에 전체 UI 코드 통합 | 여러 개의 독립된 코드베이스 (기능/도메인 별 분리) |
배포 단위 | 프론트엔드 전체를 일괄 배포 (한 부분 수정 시 전체 재배포) | 마이크로앱 단위로 개별 배포 (다른 모듈 영향 없이 부분적 배포) |
기술 스택 | 전체 애플리케이션에 단일 기술 스택 적용 (한 가지 프레임워크/버전) | 모듈마다 최적 기술 선택 가능 (여러 프레임워크 공존 허용) |
스케일링 | 애플리케이션 전체로만 확장/최적화 가능 | 트래픽 많은 모듈만 별도 확장 또는 최적화 가능 (독립 스케일링) |
배포 빈도 | 릴리스 단위가 크고 낮은 빈도의 배포 (예: 수주일 간격) | 작고 잦은 배포 가능 (모듈 단위로 수시 출시) |
장애 영향 | 한 부분의 버그가 전체 프론트엔드에 영향 줄 수 있음 | 개별 모듈 장애는 해당 부분만 영향 (격리 및 신속한 롤백 용이) |
초기 구축 난이도 | 아키텍처 단순, 설정 용이 | 아키텍처 복잡, 통합/배포 설정 난이도 높음 |
빌드 타임 MFE는 각 마이크로 프론트엔드를 빌드 시점에서 미리 통합하는 방식입니다. 즉, 개발 단계에서 코드가 통합되어 하나의 번들로 만들어지는 접근법입니다.
my-monorepo/
├── packages
│ ├── mfe-cart
│ ├── mfe-payment
│ └── shared-ui
├── apps
│ └── container-app
├── package.json (워크스페이스 설정)
└── turbo.json / nx.json
런타임 MFE는 마이크로 프론트엔드 모듈들이 런타임에 동적으로 통합되는 방식입니다. 배포 이후에도 동적으로 모듈을 로드하거나 변경할 수 있습니다.
특징
예시
/cart
, /product
, /user-profile
각각의 경로가 다른 애플리케이션으로 구성되어 별도 로드됩니다.- /cart → cart-app 로드
- /payment → payment-app 로드
장점
단점
참고
Module Federation으로 알아보는 Micro Front-end
Everything You Need to Know About Micro Frontends
Micro Frontend: Run-Time Vs. Build-Time Integration
Microfrontend: Build-Time Intergation vs Run-Time Integration Concepts