마이크로 프론트엔드: Module Federation vs Iframe
한 줄 답변
독립적인 배포와 개발을 위해 마이크로 프론트엔드를 도입하며, 런타임 통합의 유연성을 제공하는 Module Federation과 완전한 격리를 보장하는 Iframe의 트레이드오프를 이해하는 것이 핵심입니다.
핵심 개념 정리
마이크로 프론트엔드는 거대한 모노리스 프론트엔드를 독립적으로 개발, 테스트, 배포 가능한 작은 단위로 쪼개는 아키텍처입니다. 이는 조직 규모가 커짐에 따라 발생하는 의존성 병목 현상을 해결하기 위해 등장했습니다. 단순히 코드를 나누는 것을 넘어, 서로 다른 팀이 기술 스택의 제약 없이 독립적으로 가치를 전달하는 것에 목적이 있습니다.
런타임 통합 방식 중 가장 주목받는 것은 Webpack 5에서 도입된 Module Federation입니다. 이는 별도의 빌드 과정 없이 원격에 배포된 컴포넌트나 로직을 로컬 모듈처럼 동적으로 불러와 사용할 수 있게 해줍니다. 번들 크기를 최적화하면서도 마치 하나의 앱처럼 매끄러운 사용자 경험을 제공하며, 공유 라이브러리의 중복 로드를 방지하는 강력한 기능을 제공합니다.
반면, 가장 고전적이면서도 확실한 방법은 Iframe을 사용하는 것입니다. Iframe은 브라우저 수준에서 CSS, 자바스크립트 실행 환경을 완벽하게 격리(Sandbox)하므로 기술 스택 간의 충돌 가능성을 원천적으로 차단합니다. 하지만 메인 페이지와의 통신 비용, SEO 문제, 브라우저 메모리 사용량 증가 등 성능과 사용자 경험 측면에서의 비용이 큽니다.
비교 정리
| 항목 | Module Federation | Iframe |
|---|---|---|
| 격리 수준 | 코드 수준의 통합, 전역 오염 가능성 존재 | 브라우저 레벨의 완벽한 샌드박스 격리 |
| 통신 방식 | Direct JS API, State Sharing 용이 | postMessage API를 통한 비동기 통신 |
| 성능/UX | 공유 의존성 최적화로 빠른 로딩 속도 | 중복 리소스 로드 및 레이아웃 제약 |
| 유지보수 | 공통 라이브러리 버전 관리 전략 필요 | 완전 독립적이나 통합 복잡도 증가 |
면접에서 이렇게 답하세요
시니어 면접에서는 단순히 기술적 특징을 나열하기보다 '의사결정 프로세스'를 보여줘야 합니다. 모든 것을 Module Federation으로 가야 한다는 답변보다, 격리가 최우선인 결제 모듈이나 외부 서비스 통합에는 Iframe을, 긴밀한 인터랙션과 성능이 중요한 대시보드에는 Module Federation을 사용했다는 식으로 상황별 트레이드오프를 언급하세요. 특히 버전 충돌 해결 전략이나 Error Boundary 적용 경험을 덧붙이면 좋습니다.
자주 묻는 추가 질문
Q. Module Federation에서 공유 라이브러리 버전이 다를 때의 처리 방법은?
singleton 설정을 통해 특정 버전으로 강제하거나, SemVer 범위를 지정해 호환성을 관리하며 버전 불일치 시 별도 로드를 허용합니다.
Q. Iframe의 레이아웃 제약(모달, 툴팁 등)은 어떻게 해결하나요?
부모 창과 통신하여 부모 레벨에서 UI를 띄우는 프록시 레이어를 구축하거나 브라우저 뷰포트 기반의 포탈을 사용해 해결합니다.
Q. 마이크로 프론트엔드 도입 시 공통 UI 컴포넌트는 어떻게 관리하나요?
별도의 npm 패키지로 관리하거나, 이 또한 Module Federation으로 배포하여 런타임에 동적으로 싱크를 맞춰 중복을 방지합니다.
커뮤니티 하이라이트
“결국은 DX와 UX의 균형입니다. MF는 공유가 쉽지만 버전 관리가 꼬이면 지옥이 펼쳐지니 거버넌스 수립이 먼저예요.”
“금융권처럼 보안과 격리가 생명인 곳은 여전히 Iframe이 정답인 경우가 많습니다. 기술의 우위보다 도메인 특성을 보세요.”
42명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.