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이라고 항상 더 빠른 것도 아니다. 공유 설정, 청크 로딩, 앱 초기화와 실제 사용 경로에 따라 결과가 달라지므로 같은 조건에서 확인해야 한다.
선택하기 전에 묻는 것
화면과 상태를 어느 정도까지 함께 구성해야 하는가.
한 기능이 실패했을 때 나머지 화면은 어떻게 남아야 하는가.
팀이 버전과 통신 계약을 함께 관리할 수 있는가.
접근성, 인증, 포커스와 라우팅을 어느 경계에서 처리할 것인가.
성능과 운영 비용을 어떤 시나리오로 측정할 것인가.
이 질문에 답하다 보면 iframe의 문서 경계가 더 필요한 서비스도 있고, Module Federation의 컴포넌트 합성이 더 필요한 서비스도 있을 것이다. 운영하는 팀이 어느 경계를 관리할 수 있는지도 함께 봐야 한다.
내가 AI의 추천에 덧붙이고 싶었던 질문은 이것이다.
“그래서, 문제가 생겼을 때는 어떻게 되는데?”
성능 비교표에도 그때의 화면이 한 줄쯤은 있었으면 좋겠다.
Assisted by AI
© uiwwsw · 본인 소유의 글·이미지에 대한 무단 복제·재게시를 허용하지 않습니다. 개인 열람·원문 링크 공유·검색 색인과 제한적인 미리보기는 허용합니다. 법령상 이용 예외, 기존 이용 허락, 코드·제삼자 자료의 기존 라이선스는 유지합니다. 콘텐츠 이용 안내