Micro Frontend는 "과잉 설계"인가 "필연"인가
Micro Frontend(MFE)는 2018년 ThoughtWorks Technology Radar에 첫 등장한 이래, 찬사와 비판의 양 극단을 오가며 존재해 왔습니다. 2022~2023년의 "모노레포 + Turborepo" 전성기에는 존재감을 잃었지만, 2025년 이후 Module Federation 2.0의 안정화, Rspack의 프로덕션 실용화, AI 에이전트에 의한 팀 생산성 격차 확대라는 세 가지 순풍을 받아 다시 주목받고 있습니다. 본고에서는 2026년 4월 현재의 MFE 기술 스택을 개관하고, 일본의 대형 금융·SaaS·EC 기업의 단계적 이행 사례를 세 가지 소개합니다.
Module Federation 2.0: 2세대의 완성
Module Federation은 Webpack 5에서 2020년에 도입된, 실행 시 원격에서 모듈을 동적으로 로드하는 구조입니다. 2.0에서는 Rspack 팀(ByteDance)의 기여로 Webpack/Rspack 모두 지원하는 새 API가 정비되었습니다. 개선점은 세 가지입니다. 첫 번째로 런타임 플러그인 시스템으로, "리모트 목록" "공유 의존성 버전"을 실행 시에 동적으로 변경할 수 있게 되어, A/B 테스트나 사용자 속성별 배포가 리로드 없이 실현되었습니다. 두 번째로 타입 안전성——2.0은 .d.ts를 리모트 컨테이너에 동봉하여 IDE 자동 완성이 작동합니다. 세 번째로 Chrome DevTools 확장 "Module Federation Inspector"로 로드 상황을 실시간으로 시각화할 수 있게 되었습니다.
Rspack / Vite / Webpack: 빌드 툴 전선
Webpack 5는 레거시적인 위치이지만 에코시스템의 두터움으로 기존 대규모 프로젝트의 첫 번째 선택지입니다. Rspack 1.x는 Rust 기반의 Webpack 호환 빌더로 속도는 5~10배이며, Module Federation 2.0을 공식 지원하여 2025년 이후의 정석이 되었습니다. Vite 6은 `@module-federation/vite` 플러그인으로 지원하지만, HMR과 실행 시 해결의 궁합이 나빠 개발 시에는 experimental 취급이 무난합니다. Turbopack은 2026년 4월 시점에서 Module Federation의 공식 지원이 미구현 상태로, Module Federation을 사용한다면 Webpack/Rspack으로 전환하는 것이 현실적입니다.
Single-SPA와 iframe: 또 하나의 길
Single-SPA는 애플리케이션 쉘이 여러 SPA의 라이프사이클을 관리하는 방식으로, 프레임워크 이기종 혼재(React + Vue + Angular)가 필요한 조직에는 여전히 최선의 선택지입니다. 2025년의 7.0 릴리스에서 시작 오버헤드가 40% 줄었습니다. 실무적으로 가장 균형이 좋은 것은 Module Federation + Single-SPA의 하이브리드로, Single-SPA로 마운트 제어, Module Federation으로 의존성 공유를 담당합니다. 이 구성은 Zalando, IKEA, 그리고 아래에서 소개할 일본 사례에서도 채택되고 있습니다.
엣지 배포와 캐시 무효화
MFE의 최대 운영 과제는 "리모트의 버전 정합성"입니다. 2026년의 베스트 프랙티스는 Immutable Assets + Manifest Indirection입니다. 리모트의 JS 청크에는 내용 해시 기반의 파일명을 붙여 `max-age=31536000, immutable`로 장기 보존하고, 엔트리인 mf-manifest.json만 단명 캐시(max-age=60, stale-while-revalidate=300)로 배포합니다. manifest가 버전 전환의 인다이렉션으로 작동하며, 엔트리를 업데이트하면 다음 TTL 경과 후에 전체 호스트가 새 버전을 취득합니다.
Cloudflare, Fastly, CloudFront 어디서든 manifest를 엣지 KV로 일원 관리하는 운용이 정착되었습니다. 카나리아는 manifest에 traffic_split 필드를 갖게 하고, Module Federation 2.0의 런타임 플러그인으로 비율을 판정합니다.
사례 1: 대형 은행의 "계정계 프론트엔드" 분할
어느 대형 은행의 인터넷 뱅킹은 모놀리식한 React 앱(약 240만 LoC)을 팀별로 7개의 MFE로 분할했습니다. 계기는 "한 팀의 변경이 나머지 6개 팀의 릴리스를 막는다" "npm install에 8분이 걸린다" "빌드에 22분 걸린다"는 고전적인 비대화 문제였습니다.
채택 구성은 Webpack + Module Federation 2.0 + Single-SPA입니다. 호스트는 계좌 요약·네비게이션·인증만을 가진 얇은 쉘로, "송금" "투자신탁" "대출" "카드" "세무신고" "보험" "문의" 7개의 MFE를 동적 로드합니다.
단계적 이행은 18개월 계획으로, 우선 쉘을 먼저 분리하고 기존 모놀리스를 하나의 MFE로 감싸는 "스트랭글러 파사드"에서 시작했습니다. 이어서 기능 단위로 기존 모놀리스에서 MFE를 분리해 나갔습니다. 각 팀은 독립적으로 React 버전을 올릴 수 있게 되었고, 이행 완료 시점에서 각 MFE의 React 버전은 18부터 19.2까지 분포하고 있었습니다.
성과는 명확했습니다. 빌드 시간은 각 팀 평균 3분(22분에서 86% 단축), 배포 빈도는 주 1회에서 하루 평균 12회로, 인시던트 시 영향 범위는 "전체 기능 중단"에서 "해당 MFE만"으로 줄었습니다. 금융 규제 감사 대응에서는 MFE별로 독립된 배포 이력을 남길 수 있다는 것이 추가 이점이 되었습니다.
사례 2: SaaS 기업의 Rspack + Vite 공존
어느 HR Tech SaaS 기업은 관리자 포털(Rspack)과 직원용 셀프 서비스(Vite)를 다른 빌드 툴로 운영하고 있습니다. 관리자 포털은 방대하고 IE11 호환이 필요하며(레거시 고객 요건), 직원 포털은 모바일 중심으로 DX 우선이라는 요건 차이로 인해 빌드 툴을 분리했습니다.
MFE 연계는 공통 네비게이션 바, 알림 센터, 검색, 헬프 채팅 4가지 기능입니다. 이것들은 각각 독립된 리포지토리에서 Rspack으로 빌드되어, 양쪽 포털이 Module Federation 2.0을 통해 로드합니다. Vite 측은 `@module-federation/vite` 플러그인으로 리모트 소비 측으로 통합했습니다.
교훈은 "공유 의존성은 최소한으로". 당초 React, dayjs, Zustand 등 다수를 shared에 지정했지만, singleton 충돌로 3번의 프로덕션 사고를 냈고, 최종적으로 React, React-DOM, i18n 컨텍스트 3개만으로 줄였습니다. Bundle 사이즈는 늘었지만 운영 안정성은 비약적으로 향상되었습니다.
사례 3: EC 플랫폼의 엣지 배포 이행
대형 EC의 쇼핑몰 빌더 SaaS는 테넌트별로 커스텀 프론트엔드를 제공하는 성질상 MFE와 친화성이 높습니다. 2025년에 Rspack + Module Federation 2.0으로 이행하여, Cloudflare Workers가 테넌트 ID에서 MFE manifest를 동적 생성하는 구성으로 전환했습니다. "특정 고객에게만 새 기능을 단계적으로 공개" "공휴일 한정 디자인을 테넌트별로 배포"가 엔지니어 배포 없이 가능해졌습니다. 함정은 SEO였으며, SSR에서의 manifest 사전 해결과 구조화 데이터의 정적 삽입으로 회피했습니다. 인덱스 유효율은 92%에서 98%로 개선되었습니다.
MFE를 도입해야 하는가: 의사결정 체크리스트
도입 여부는 다음 관점으로 판단하십시오. 해당 항목이 3개 이상이라면 MFE를 진지하게 검토해야 합니다. 팀 수가 5개 이상이며 독립된 릴리스 사이클을 가짐 / 모노레포의 빌드 시간이 10분 초과 / 다른 프레임워크·버전의 공존 / 테넌트별 커스터마이즈 배포 / 장애 영향을 기능 단위로 한정하고 싶음 / 기능별로 독립된 감사 이력이 필요. 반대로 팀이 1~2개, 빌드가 3분 이내, 초기 로드의 단순함을 최우선으로 한다면 MFE는 과잉입니다.
결론: MFE는 "재발견"의 시대로
Module Federation 2.0, Rspack의 성숙, 엣지 배포의 진화, 그리고 AI 에이전트에 의한 팀 자율성이라는 순풍을 받아, 2026년의 MFE는 "일부 선진 조직을 위한 기술"에서 "조건이 맞는 조직의 정석"으로 격상되었습니다. 중요한 것은 MFE를 "만능 해법"으로 도입하는 것이 아니라, 조직의 고통과 비즈니스 요건에 대한 구체적인 처방으로 도입하는 것입니다. 본고에서 소개한 3가지 사례가 보여주듯, 적절한 조건 하에서의 MFE는 빌드 시간, 릴리스 빈도, 장애 영향 범위, 커스터마이즈 자유도 모두에서 차원이 다른 개선을 가져옵니다. 다음 아키텍처 회의에서 "MFE? 구식이잖아"라고 일축하기 전에, 다시 한 번 조직의 현상을 되돌아볼 가치가 있습니다.