Next.js에서 모듈 페더레이션(Module Federation, MF)을 적용할 때, 비즈니스/서비스/기술 관점을 고려해서 GPT 도움을 받아 정리 해보았습니다. 결론부터 말씀드리겠습니다.
결론
- Next.js App Router(=Next 13~15, RSC 중심)에서는 “모듈 페더레이션”을 1급 시민으로 쓰지 않는 것이 현재 베스트 프랙티스입니다. 대신 Vercel의 Microfrontends(Multi‑Zones, 경로 기반 조합)을 사용하세요. 이는 App Router와 RSC에 자연스럽게 맞고, 공식 문서와 템플릿, 툴링이 갖춰져 있습니다. (Vercel)
- 모듈 페더레이션을 꼭 써야 한다면: Pages Router 기반에서만 현실적으로 추천 가능합니다. 공식 MF 코어팀의
nextjs-mf는 유지보수(maintenance) 모드이며 App Router 미지원이고, EOL(사용 종료) 타임라인을 공지했습니다. 단기 브리지로는 가능하되, 중장기 메인 아키텍처로 두는 건 리스크가 큽니다. (GitHub)
- Edge Runtime와 MF를 함께 쓰는 것은 한계가 있습니다. MF의 SSR은 Node.js Runtime을 전제로 하는 경우가 많고, Edge Runtime은 Node API 미지원/제약이 있어 충돌 소지가 큽니다. MF가 필요한 경로는
runtime='nodejs'로 고정하세요. (Next.js)
2025년 현재 Next.js × MF 생태계의 현실
@module-federation/nextjs-mf(일명 nextjs‑mf): App Router 미지원, 프로젝트 디프리케이션 공지, Pages Router만 “필요시 최소 수정 백포트” 수준으로 유지. 2026년 즈음 완전 EOL 가능성을 명시. (GitHub)- Vercel Microfrontends: 경로 기반 조합(Multi‑Zones)을 App Router와 함께 공식적으로 밀고 있으며, 템플릿/로컬 프록시/툴바/관리/제한(그룹당 3개 등)까지 제공. RSC와 자연스럽게 호환. (Vercel)
- Vercel Labs 예제: MF + Pages Router 예제(실행 가능), App Router는 Multi‑Zones 예제를 제공. (GitHub)
- Nx 문서: MF 개념/주의점/버전관리/번들크기 트레이드오프를 정리. Next.js 전용은 아님. (Nx)
4가지 실전 시나리오 비교
시나리오 A — App Router + Vercel Microfrontends(Multi‑Zones)
용도: 마케팅/문서/애플리케이션 등 경로 단위로 앱을 분리하고 RSC 그대로 유지하고 싶은 경우.
핵심: 경로(/docs, /account 등)에 따라 다른 Next 앱에 라우팅(엣지 프록시). 컴포넌트 레벨 공유는 없음(대신 공유 패키지로 해결). (Vercel)
- 장점
- App Router/RSC와 자연 호환, 공식 지원/문서/템플릿 풍부. (Vercel)
- 팀 자율 배포(앱 별 독립 배포), 점진적인 마이그레이션 용이. (Vercel)
- 개발 경험 도구(로컬 프록시, Vercel Toolbar) 제공. (Vercel)
- 단점
- 기술 난이도: 낮음–중간(템플릿/도구 활용)
- 퍼포먼스: 경로 단위 분리로 빌드/런타임 분리 이점. 크로스 네비게이션 최적화 필요. (Vercel)
- 비즈니스 타이밍: 가장 안전한 선택. App Router를 이미 쓰고 있거나 RSC 중심 철학(예: Clean F.S.D)라면 사실상 표준 해법.
간단 설정 스케치* 루트 앱과 서브 앱 각각에 @vercel/microfrontends 설정 + microfrontends.json 정의* 필요하면 PrefetchCrossZoneLinksProvider로 하드 네비 최적화 (Vercel)
시나리오 B — Pages Router + 모듈 페더레이션(nextjs‑mf)
용도: 런타임 컴포넌트 공유가 반드시 필요하고, Pages Router를 쓰거나 유지할 합리적 이유가 있는 경우(레거시/서드파티 위젯 등).
중요 제약: App Router 미지원, 유지보수 모드, 중장기 기술 부채 가능성. (GitHub)
- 장점
- 컴포넌트/훅/상태 모듈의 런타임 공유 가능(MF의 강점).
- SSR 지원(Node 런타임)으로 SEO·초기 페인트 전략 조합 가능. (Module Federation)
- 단점
- App Router/RSC 비호환, 프로젝트 디프리케이션 공지. 리스크 큼. (GitHub)
- Edge Runtime과 상극(Node API 제약). SSR 경로는 반드시 Node 런타임 사용 필요. (Next.js)
- 버전/공유 스코프 관리 복잡, 번들 트리셰이킹 저하 가능. (Nx)
- 기술 난이도: 중간–높음(웹팩/공유스코프/런타임 에러 경계 등)
- 퍼포먼스:
remoteEntry.js 네트워크 오버헤드·의존성 중복 리스크. 캐싱 전략/싱글톤 공유로 완화. (Module Federation)
- 비즈니스 타이밍: 단기 브리지로는 가치. 장기 메인 전략은 비추천.
최소 예시(요지)* next.config.js에서 NextFederationPlugin 등록 + React.lazy로 연동 권장* App Router 미지원, NEXT_PRIVATE_LOCAL_WEBPACK=true 요구 사항 등 확인 필요 (Module Federation)
시나리오 C — 싱글‑페이지 오케스트레이션(single‑spa) + MF(혼합)
용도: 여러 프레임워크 혼재(React+Vue 등) 또는 온전한 SPA 오케스트레이션이 필요한 경우.
Vercel Labs가 single‑spa × MF 예제를 제공. App Router 안에서 “아일랜드”로 클라이언트 섹션을 삽입하는 식으로 응용. (GitHub)
- 장점: 프레임워크 혼합, 컴포넌트 레벨 공유와 오케스트레이션 병행.
- 단점: RSC와의 간극(클라이언트 아일랜드로 격리), 전역 상태/디자인 토큰/접근성 일관성 관리 난이도.
- 난이도: 높음
- 비즈니스 타이밍: 특수한 경우에만 고려.
시나리오 D — SDK/위젯(웹 컴포넌트/스크립트) 방식(비‑MF)
용도: 외부 파트너나 여러 도메인에 기능을 ‘심어’야 하는 SaaS/위젯형 배포.
- 장점: 프레임워크 독립, 배포·롤백 간단.
- 단점: 의존성 중복/번들 크기 증가, 호스트와의 상태·스타일 격리 필요(CSS 캡슐화).
- 난이도: 중간
- 비즈니스 타이밍: 파트너 통합/화이트 라벨에 강함.
제가 추천하는 스택(Next.js 15 App Router + Clean F.S.D(Server‑first))에 대한 권장안
- 1안(권장): Multi‑Zones + Monorepo 공유 패키지
- 엔터티(READ, RSC)는 각 존에서 그대로 RSC로 구현.
- 공용 디자인 토큰/유틸/타입은
packages/ui, packages/shared로 분리(터보레포).
- 경로 기준으로 Camp/Docs/Marketing/Console 등을 분리하고, 크로스 네비 프리패치로 UX 부드럽게. (Vercel)
- 2안(제한적): 특정 레거시 Pages Router 영역만 MF 도입(브리지)
- 런타임 공유가 꼭 필요한 협업 라인(예: 사내 팀이 유지하는 위젯)을 Pages 서브앱으로 두고 MF 연결.
- 호스트(App Router)에서는 해당 섹션을 클라이언트 섬으로만 삽입(서버 경로 분리), Node 런타임 강제.
- 중장기적으로는 A안으로 통합 권장. (GitHub)
구현 체크리스트(핵심만)
A안: App Router + Multi‑Zones
@vercel/microfrontends 설치 → 각 앱에 withMicrofrontends 구성, 루트에 microfrontends.json 작성. (Vercel)- 로컬 프록시로 단일 앱만 띄워도 전체 동작 확인. 툴바로 경계/성능 가시화. (Vercel)
- 크로스‑존 네비 최적화:
PrefetchCrossZoneLinksProvider/전용 Link 사용. (Vercel)
B안: Pages + MF(nextjs‑mf)
NextFederationPlugin 구성 시 React/next 내부를 싱글톤 공유(기본 공유 스코프 참고), React.lazy 사용 권장. (Module Federation)- Node 런타임 강제(Edge 금지), SSR 전용 remoteEntry 경로 사용. (Next.js)
- 버전/공유 스코프:
shared는 최소 공유 원칙, react, react-dom은 singleton/strictVersion 설정. (webpack)
- 캐싱 전략:
remoteEntry.js는 항상 최신화, 나머지는 캐시. (해시/타임스탬프 전략) (Medium)
성능·안정성 관점의 팁(공통)
- 공유 최소화: 필요 라이브러리만 공유. 무분별 공유는 번들 비대화/트리셰이킹 저하를 유발. (Nx)
- React는 무조건 싱글톤: 중복 로딩 시 미묘한 런타임 버그 발생.
singleton: true, strictVersion 고려. (webpack)
- 런타임 실패 격리: 원격 모듈 로딩 실패 대비 에러 바운더리/폴백 UI 필수(예제에도 포함). (GitHub)
- 보안/신뢰 경계: 원격 도메인 화이트리스트, CSP, 서명/고정 URL 관리. (Vercel 관리/툴바로 가시화) (Vercel)
- 테스팅/계약 관리: 타입 선언(d.ts)·계약 테스트로 호스트/리모트 호환성 보장. (Vercel 예제/문서 권장) (GitHub)
대표 사례별 권장안
- 대규모 콘텐츠+앱 통합(마케팅/문서/콘솔)
- A안(Multi‑Zones) 채택 → 경로로 분리, 공용 컴포넌트는 패키지화.
- 장점: App Router와 100% 합, RSC/서버‑퍼스트 전략 유지. (Vercel)
- 레거시 Pages Router에 있는 사내 UI를 그대로 재사용해야 하는 경우(런타임 공유 필수)
- B안으로 한시적 MF 도입 → 호스트는 Node 런타임에서만 SSR. App Router 전면 도입은 지연.
- 리스크:
nextjs-mf EOL 감안, 중장기 전환 계획 필수. (GitHub)
- 여러 프레임워크 병행(파트너 팀이 Vue/Solid를 사용)
- C안(single‑spa + MF) 또는 D안(SDK/Widget)을 비교.
- 제품/조직 구조상 ‘한 화면에 여러 앱’ 요구가 강하면 C, 외부 임베드는 D. (GitHub)
최소 설정 예시
1) Multi‑Zones(App Router) — microfrontends.json
{
"applications": {
"marketing": {
"development": { "local": 3000, "fallback": "marketing.vercel.app" }
},
"docs": {
"development": { "local": 3001 },
"routing": [{ "group": "docs", "paths": ["/docs", "/docs/:path*"] }]
}
}
}
루트 앱에 withMicrofrontends와 프리패치 Provider를 추가. 템플릿/문서를 그대로 따르면 된다. (Vercel)
2) Pages + MF — next.config.js(요지)
const { NextFederationPlugin } = require('@module-federation/nextjs-mf');
module.exports = {
webpack(config, { isServer }) {
config.plugins.push(
new NextFederationPlugin({
name: 'host',
remotes: {
content: `content@http://localhost:3025/_next/static/${isServer ? 'ssr' : 'chunks'}/remoteEntry.js`
},
shared: {
react: { singleton: true, requiredVersion: false },
'react-dom': { singleton: true, requiredVersion: false }
}
})
);
return config;
}
};
React.lazy로 로드하는 패턴 권장. App Router 미지원, Node 런타임 사용. (Module Federation)
리스크 로그(주의해야 할 함정)
- App Router + MF 불가: 플러그인에서 공식적으로 “App Router Not Supported”, 프로젝트 디프리케이션 공지. (Module Federation)
- Edge Runtime 제약: Node API 미지원, ISR 미지원 등. MF SSR 경로는 Node로 고정. (Next.js)
- 버전 지옥: 공유 스코프/싱글톤/strictVersion 설계를 잘못하면 런타임 충돌. Nx 문서의 버전 관리 주의점 참고. (Nx)
- 네트워크 레이턴시/캐시:
remoteEntry.js 새 버전 선호 vs 캐시 전략 균형. remoteEntry는 신선하게, 나머지는 강캐시. (Medium)
최종 추천
- 현재 Next 15, App Router, RSC/Server‑first를 지향이라면 A안(멀티‑존)이 안전하고 현실적입니다. 조직/배포/마이그레이션까지 고려된 공식 솔루션이고, 성능·DX·장기 유지가 균형 잡혀 있습니다. 런타임 컴포넌트 공유가 꼭 필요한 영역만 제한적으로 Pages+MF로 브리지하세요. (Vercel)
참고 출처
- Vercel Microfrontends(공식 문서/템플릿/로컬 프록시/툴바/제한) (Vercel)
- Next.js Multi‑Zones 가이드(App Router) (Next.js)
- Vercel Labs 예제: Pages+MF, App Router+Multi‑Zones (GitHub)
- Module Federation 공식: Next.js 페이지(App Router 미지원/Deprecation 명시), shared 설정/싱글톤/버전 (Module Federation)
- nextjs‑mf Deprecation 공지 이슈(타임라인/권고) (GitHub)
- Edge vs Node Runtime 제약(Edge는 Node API/ISR 미지원 등) (Next.js)
