마이크로 프론트엔드는 하나의 큰 프론트엔드 앱을 기능별 조각으로 나눠, 팀마다 따로 개발·배포하고 런타임에 하나의 화면으로 조립하는 아키텍처다. 백엔드의 마이크로서비스(microservices) 발상을 프론트엔드로 가져온 것이다.
구조
얇은 Shell(컨테이너, container application) 앱이 라우팅과 공통 레이아웃을 맡고, 헤더·상품 목록·장바구니 같은 조각을 각 팀의 앱에서 불러와 끼운다. 사용자는 하나의 사이트로 느낀다.
flowchart TD
Shell["Shell (컨테이너)<br/>라우팅 · 공통 레이아웃"]
subgraph R["각 팀이 따로 배포한 앱"]
direction LR
H["헤더"]
P["상품 목록"]
C["장바구니"]
end
Shell -- "런타임에 불러와 끼움" --> R
조합 방식
- 빌드 타임(build-time integration): 조각을 npm 패키지로 만들어 Shell이 빌드할 때 가져온다. 단순하지만 조각을 고칠 때마다 Shell을 다시 배포해야 해 독립 배포라는 장점이 약해진다
- iframe: 격리는 확실하지만 스타일·라우팅·상태 공유가 어렵고 사용자 경험이 매끄럽지 않다
- JS 런타임 조합(run-time integration via JavaScript): 브라우저가 각 조각의 번들을 동적으로 불러온다. Webpack의 Module Federation이 대표적이고 Vite·Rspack 진영에도 같은 도구가 있다(코드 스플리팅과 동적 임포트, 번들러)
- Web Components: 조각을
<product-list>같은 커스텀 엘리먼트(Custom Elements)로 만들어 프레임워크 의존을 줄인다
장단점
- 장점: 팀별 독립 배포, 조각 단위의 점진적 기술 교체, 레거시를 한 번에 갈아엎지 않는 현대화
- 단점: 라이브러리 중복으로 번들이 커지기 쉽고(번들 크기 줄이기), 디자인 일관성을 위해 공통 디자인 시스템이 필요하며, 조각 간 통신·인증·라우팅 조율과 배포 파이프라인이 늘어난다
언제 쓰나
팀이 여럿이고 각자 빠르게 배포해야 하며 앱이 정말 클 때만 이득이 비용보다 크다. 팀이 한두 개라면 복잡성만 늘어난다. 팀 경계를 따라 시스템을 자르는 결정이라 콘웨이의 법칙가 그대로 작동한다. 코드를 어떻게 저장하느냐는 별개 문제로, 마이크로 프론트엔드 조각들을 모노레포 하나에 두고 공통 패키지를 공유하는 조합이 흔하다.
출처: Micro Frontends Cam Jackson (martinfowler.com) · webpack: Module Federation