문제 상황

Next.js에서 micro frontend를 빠르게 붙이기 위해 rewrites를 사용했다.

// next.config.ts
rewrites: async () => [
  { source: '/test/micro-test', destination: 'http://localhost:8001' },
],

의도는 다음과 같았다.

/test/micro-test 경로는 유지
내부적으로는 별도의 micro frontend 서버로 요청 전달
동시에 Next.js의 layout.tsx를 통해 공통 헤더/사이드바 유지

하지만 실제 동작은 기대와 달랐다.

layout.tsx가 적용되지 않음
공통 UI가 사라지고, micro frontend가 전체 화면을 덮어씀

원인 분석

핵심은 rewrites의 동작 방식이다.

rewrites는 Next.js 내부 라우팅을 확장하는 기능이 아니라, 요청을 다른 서버로 프록시하는 기능이다.

즉:

/test/micro-test → Next 내부 page가 렌더되는 것이 아님
실제로는 → http://localhost:8001의 응답을 그대로 반환

결과적으로:

해당 요청은 Next의 App Router 트리 안으로 들어오지 않음
app/layout.tsx, app/test/layout.tsx 모두 실행되지 않음
micro frontend의 HTML이 최종 문서처럼 응답됨

정리하면:

rewrites는 “페이지 합성”이 아니라 “요청 우회(proxy)”이다.

해결 접근 방법

이 문제를 해결하려면,
“micro frontend를 어떻게 통합할 것인가”에 대한 전략을 바꿔야 한다.

1. iframe 기반 통합

방식

Next.js의 page 안에서 iframe으로 micro frontend를 삽입

export default function Page() {
  return (
    <iframe
      src="http://localhost:8001"
      style={{ width: '100%', height: '100%', border: 0 }}
    />
  );
}

특징

Next.js layout 유지 가능
micro frontend는 완전히 독립적으로 동작

장점

구현이 가장 단순
기술 스택 제약 없음

단점

라우팅 분리
SEO 불리
iframe 간 통신 필요 (postMessage 등)

2. Remote Component 방식 (권장)

방식

micro frontend를 “앱”이 아니라 “컴포넌트”로 가져와서 렌더

// app/test/micro-test/page.tsx
import MicroTestRoot from '@/components/micro/MicroTestRoot';

export default function Page() {
  return <MicroTestRoot />;
}

특징

Next.js layout 유지
micro frontend는 UI 단위로 통합

장점

가장 자연스러운 통합 방식
App Router와 충돌 없음

단점

remote 번들 설계 필요
독립 배포 구조 설계 필요

3. Module Federation

방식

Webpack Module Federation을 활용하여 remote 컴포넌트를 로드

const RemoteComponent = React.lazy(() => import('remote/App'));

특징

진짜 “마이크로 프론트엔드” 구조
독립 배포 가능

장점

대규모 시스템에 적합
팀 단위 분리 가능

단점

설정 복잡
Next.js App Router와의 호환성 이슈 존재
webpack 의존성 강함

4. rewrites 유지 (레이아웃 포기)

방식

현재 방식 유지

rewrites → external app

특징

/test/micro-test는 사실상 다른 앱

장점

간단한 연결
점진적 마이그레이션에 유리

단점

layout 공유 불가능
UX 일관성 깨짐

결론

이번 문제를 통해 명확해진 점은 하나다.

rewrites는 micro frontend를 “붙이는 기술”이 아니라
“다른 앱을 같은 경로에 노출시키는 기술”이다.

내가 원했던 구조는:

Next.js layout 유지
특정 영역만 micro frontend로 교체

이 요구사항은 rewrites로 해결할 수 있는 문제가 아니었다.

현재 상태

iframe: 구현 쉬움, 하지만 제약 존재
remote component: 가장 이상적, 설계 필요
module federation: 강력하지만 복잡
rewrites: 단순하지만 layout 공유 불가

마무리

어떤 방식이 가장 적합한지는 아직 결정하지 못했다.

각 방식마다 트레이드오프가 명확하고,
현재 프로젝트의 규모와 방향에 따라 선택이 달라질 것 같다.

결론은 아직 고민 중이며, 추가적인 학습과 실험이 더 필요하다.

Next.js 에서 Micro-Frontend 는 어떻게 적용해야할까

Next.js 에서 Micro-Frontend 는 어떻게 적용해야할까