2026-09-10: 설명과 코드 예시를 보완했습니다. 아래 예시는 글의 설계 의도를 전달하기 위한 것이며, 원 프로젝트에 반영된 변경 내역과는 구분합니다.
MFE 구조를 검토하면서 Module Federation과 iframe을 비교했다. 내가 AI에 물었을 때는 자원 공유와 성능에 초점을 맞춘 답변을 자주 받았다. 하지만 서비스에 적용하려면 장애의 영향 범위와 팀의 운영 방식도 함께 봐야 한다고 생각했다.
두 방식이 나누는 경계
Module Federation은 별도로 빌드한 모듈을 런타임에 연결하는 방식이다. 의존성을 공유할 수 있지만 버전과 로딩 실패를 어떻게 처리할지는 설계가 필요하다. webpack Module Federation
iframe은 별도의 문서와 브라우징 컨텍스트를 만든다. DOM과 스타일을 나누는 데 유리하지만 origin과 sandbox 설정에 따라 접근 경계가 달라진다. 모든 장애를 별도 프로세스로 격리하거나 호스트에 영향을 주지 않는다고 보장하는 것은 아니다. MDN iframe
| 비교할 항목 | Module Federation | iframe |
|---|---|---|
| UI 통합 | 컴포넌트 단위 합성이 가능함 | 크기·포커스·라우팅을 문서 경계 너머로 맞춰야 함 |
| 의존성 | 공유할 수 있지만 호환성 정책이 필요함 | 문서별 런타임과 메모리 비용을 고려해야 함 |
| 실패 처리 | 로딩 실패·렌더링 오류 등에 대한 처리 필요 | 문서 분리는 도움이 되지만 통신 실패와 자원 영향은 남음 |
| 팀 운영 | 공유 계약과 버전 정책이 중요함 | 메시지 계약과 접근·배포 경계가 중요함 |
CDN이 해결하는 범위
CDN과 캐시는 네트워크 전송 비용을 줄일 수 있다. 그러나 여러 문서에서 사용하는 런타임의 평가·실행·메모리 비용까지 자동으로 없애주지는 않는다. “같은 파일을 받으니 비용도 한 번”이라고 정리해서는 안 된다.
반대로 Module Federation이라고 항상 더 빠른 것도 아니다. 공유 설정, 청크 로딩, 앱 초기화와 실제 사용 경로에 따라 결과가 달라지므로 같은 조건에서 확인해야 한다.
내가 먼저 묻고 싶은 질문
- 화면과 상태를 어느 정도까지 함께 구성해야 하는가.
- 한 기능이 실패했을 때 나머지 화면은 어떻게 남아야 하는가.
- 팀이 버전과 통신 계약을 함께 관리할 수 있는가.
- 접근성, 인증, 포커스와 라우팅을 어느 경계에서 처리할 것인가.
- 성능과 운영 비용을 어떤 시나리오로 측정할 것인가.
내가 강조하고 싶은 것은 특정 방식의 우월성보다 실패했을 때의 모습까지 기술 선택에 포함하는 일이다. AI의 답변도 같은 질문으로 검토해야 한다. 성능이라는 단어 하나나 익숙한 도구 이름만으로 서비스의 경계를 결정할 수는 없다.
Assisted by AI
