[문제] 마이크로프론트엔드(Micro Frontend) 아키텍처의 개념과 모놀리식 프론트엔드와의 차이점을 설명하고, 마이크로프론트엔드 구현 방식(iFrame, Web Components, Module Federation, Single-SPA)을 비교하시오. 또한 마이크로프론트엔드 도입 시 고려해야 할 공통 UI 일관성, 성능, 팀 자율성 간의 트레이드오프를 논하시오.
1. 마이크로프론트엔드 개념과 모놀리식 비교
마이크로프론트엔드(Micro Frontend)는 마이크로서비스 아키텍처 원칙을 프론트엔드에 적용하여, 대형 SPA를 팀별로 독립적으로 개발·배포할 수 있는 소형 애플리케이션으로 분할하는 아키텍처 패턴이다.
| 구분 | 모놀리식 프론트엔드 | 마이크로프론트엔드 |
|---|---|---|
| 배포 단위 | 전체 앱을 단일 번들로 배포 | 기능 도메인별 독립 배포 |
| 팀 구조 | 단일 프론트엔드 팀, 중앙 집중 | 수직 팀(풀스택), 도메인 자율성 |
| 기술 스택 | 단일 프레임워크(React/Vue) | 팀별 다른 프레임워크 혼용 가능 |
| 확장성 | 팀 증가 시 코드 충돌·병목 | 팀 간 독립적 개발·배포 |
2. 마이크로프론트엔드 구현 방식 비교
| 방식 | 원리 | 장점 | 단점 |
|---|---|---|---|
| iFrame | HTML iFrame으로 독립 앱 삽입 | 완전 격리, 레거시 지원 | UX 불연속, SEO 불리, 성능 저하 |
| Web Components | Custom Elements + Shadow DOM으로 캡슐화된 컴포넌트 | 프레임워크 독립, 브라우저 표준 | 브라우저 호환성 (폴리필 필요) |
| Module Federation | Webpack 5 기능. 런타임에 원격 모듈을 동적 로드 | 공유 의존성 중복 제거, 동적 로딩 | Webpack 의존성, 버전 불일치 위험 |
| Single-SPA | 라우팅 기반 MFE 오케스트레이션 프레임워크 | 다중 프레임워크 공존, 성숙한 생태계 | 초기 설정 복잡, 추가 런타임 번들 |
현재 주류: Webpack 5 Module Federation이 가장 많이 사용됨
3. 마이크로프론트엔드 트레이드오프
- UI 일관성: 팀별 독립 개발 → 디자인 시스템(Design System) 공유 필수. Storybook + 공유 컴포넌트 라이브러리로 일관성 유지
- 성능: 각 MFE가 프레임워크를 별도 로드 → 중복 번들 증가. Module Federation 공유 의존성으로 완화. 최초 로드 시간 증가 위험
- 팀 자율성: 독립 기술 스택 허용 시 일관성·공유 어려움. “기술 선택 자유 vs 플랫폼 표준” 균형 필요
- 팀 간 통신: MFE 간 상태 공유는 Custom Events, 공유 상태 라이브러리, URL 파라미터로 제한
- 테스팅: E2E 테스트에서 여러 MFE 통합 환경 구축 복잡도 증가
[ 결론 ]
마이크로프론트엔드는 대규모 팀의 프론트엔드 독립 배포를 가능하게 하지만, UI 일관성·성능·팀 간 통신의 트레이드오프가 발생한다. Module Federation이 현재 가장 실용적인 구현 방식이며, 공유 디자인 시스템과 명확한 기술 거버넌스 정책이 성공의 핵심이다.