🌐 Next.js 심화 12장: Micro-Frontend & Multi-Zones — 거대 공룡을 조각내어 다스리기

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🗺️ Multi-Zones vs Module Federation 🟢
• 🏗️ Multi-Zones 아키텍처 설계 🟡
• 🧩 공유 컴포넌트와 패키지 전략 🟡
• 🚀 실전! next.config.ts에서 Zone 연결하기 🔴
• 💥 에러 해결 카탈로그
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 20분 (전체) / 핵심 파트만: 10분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영수(PM): "영호 님, 우리 커뮤니티가 너무 커져서 빌드 한 번에 15분이나 걸려요! 개발 속도가 너무 느려졌는데 방법 없나요?"
• 영호(리드): "코드가 너무 거대해져서 그래요. 이제 '커뮤니티 메인', '실시간 채팅', '마켓'을 각각 별도의 Next.js 앱으로 쪼개야 할 때가 됐네요."
• 영철(주니어): "어? 앱을 쪼개면 유저가 페이지 이동할 때 새로고침 되잖아요! SPA 같은 느낌이 안 나면 어쩌죠?"
• 영호: "그래서 Multi-Zones가 필요한 거예요. 유저는 하나의 앱인 줄 알지만, 실제로는 여러 앱이 협업하는 거죠."

🎯 이 문서를 다 읽으면 할 수 있는 것

• 거대해진 Next.js 앱을 의미 있는 단위(Zones)로 분리할 수 있다
• 빌드 속도와 배포 단위를 독립시켜 팀별 생산성을 극대화할 수 있다
• rewrites를 이용해 여러 Next.js 앱을 하나의 도메인으로 매끄럽게 연결할 수 있다

🤔 왜 알아야 하는가

서비스가 성장하면 코드가 기하급수적으로 늘어나. 이걸 모놀리식(Monolithic) 프론트엔드라고 해.
문제는 코드가 늘어날수록 빌드가 느려지고, 한 명의 실수로 전체 서비스가 중단될 위험도 커진다는 거야.

마이크로 프론트엔드(MFE) 는 이 거대한 앱을 작게 쪼개는 철학이야.
Next.js에서는 이를 구현하는 가장 강력하고 순정(Native)인 방식이 바로 Multi-Zones야.

시니어의 인사이트:
"Module Federation(Webpack 전용)은 강력하지만 설정이 늪이고 서버 사이드 렌더링(SSR) 지원이 까다로워요. 하지만 Next.js의 Multi-Zones는 rewrites 기반이라 SSR도 완벽하고 구조도 훨씬 단순하죠. 대규모 기업(Vercel, Uber, TikTok 등)들이 이 방식을 선호하는 이유예요."

🏗️ 비유로 먼저 이해하기

🏢 백화점으로 설명한다면?
거대한 백화점 건물 하나를 관리하는 건 힘들어. 전기가 나가면 모든 층이 다 어두워지잖아.

1. 모놀리식: 건물이 통째로 하나인 백화점.
2. Multi-Zones: 1층은 명품존(Next.js 앱 A), 2층은 푸드코트(Next.js 앱 B), 3층은 생활관(Next.js 앱 C)으로 주인이 각각 따로 있는 거야.

손님(유저)은 엘리베이터(네비게이션)를 타고 층을 이동해. 1층(명품) 주인은 지하실 공사를 해도 2층(푸드코트) 영업에는 지장이 없지. 손님 입장에서는 여전히 하나의 '백화점'에 있는 것처럼 보여.

🗺️ Multi-Zones vs Module Federation 🟢

🎯 이 섹션을 읽고 나면:

• 프로젝트 규모에 맞는 마이크로 프론트엔드 전략을 선택할 수 있다.

🏗️ Multi-Zones 아키텍처 설계 🟡

1차 전략: 도메인 매핑

가장 먼저 'Host'(입구) 앱과 'Child'(서브) 앱을 정해야 해.

• Host (Main): youngsu.com/ (메인 홈, 공통 레이아웃)
• Zone 1 (Chat): youngsu.com/chat (실시간 채팅 앱)
• Zone 2 (Market): youngsu.com/market (아이템 거래 앱)

2차 전략: 자산(Assets)의 고유성

각 앱의 _next/static 경로가 겹치면 안 돼! 그래서 assetPrefix를 다르게 설정해야 해.

🚀 실전! next.config.ts에서 Zone 연결하기 🔴

1단계: 서브 앱(Chat) 설정

영철이가 만든 채팅 앱의 설정이야.

// apps/chat/next.config.ts
import type { NextConfig } from "next";
 
const nextConfig: NextConfig = {
  // ✅ 핵심 1: 빌드된 JS/CSS 파일들이 겹치지 않게 경로를 비틀어줌
  assetPrefix: '/chat-static',
 
  // ✅ 핵심 2: 내부 라우팅이 /chat 밑에서만 돌아가도록 고정
  basePath: '/chat',
 
  // 정적 자산 요청을 assetPrefix로 다시 돌려주는 설정
  async rewrites() {
    return [
      {
        source: '/chat-static/_next/:path*',
        destination: '/_next/:path*',
      },
    ];
  },
};
 
export default nextConfig;

2단계: 메인 호스트(Main) 설정

영호가 관리하는 메인 게이트웨이 설정이야.

// apps/main/next.config.ts
import type { NextConfig } from "next";
 
const CHAT_URL = process.env.CHAT_APP_URL || 'http://localhost:3001';
 
const nextConfig: NextConfig = {
  async rewrites() {
    return [
      // ✅ 핵심: /chat으로 들어오는 모든 요청을 채팅 서버(Zone 1)로 토스!
      {
        source: '/chat',
        destination: `${CHAT_URL}/chat`,
      },
      {
        source: '/chat/:path*',
        destination: `${CHAT_URL}/chat/:path*`,
      },
      // ✅ 정적 파일도 서라운드로 토스
      {
        source: '/chat-static/_next/:path*',
        destination: `${CHAT_URL}/chat-static/_next/:path*`,
      }
    ];
  },
};
 
export default nextConfig;

🧩 공유 컴포넌트와 패키지 전략 🟡

🤔 잠깐, 먼저 생각해봐
앱을 쪼갰는데 'Header'나 'Footer' 코드를 모든 앱에 복사 붙여넣기 하면 관리할 수 있을까?
당연히 안 되겠지. 그래서 Turborepo 같은 모노레포 도구를 써서 packages/ui를 따로 관리해야 해.

영호의 Pro-Tip:
"상태 관리(Redux, Query)를 여러 Zone에서 공유하는 건 권장하지 않아요. 각 Zone은 독립적인 데이터 흐름을 가져야 합니다. 공유가 꼭 필요하다면 Shared Cookie나 URL 파라미터를 쓰세요. 그게 마이크로 프론트엔드답게 '느슨하게 연결된' 상태거든요."

🏁 이번에 배운 내용 총정리

📋 Multi-Zones 체크리스트

⚠️ 절대 하지 말 것

📝 마무리 퀴즈

Q1. Multi-Zones에서 assetPrefix를 설정해야 하는 이유는 무엇인가?

✅ 정답: 여러 Next.js 앱의 /_next/static 자산 경로가 충돌하지 않게 하기 위해서다.

💡 상세 해설: 각 Zone은 독립된 Next.js 앱이지만 같은 도메인 아래 합쳐질 수 있다. 자산 경로가 겹치면 브라우저가 다른 앱의 JS/CSS를 가져오거나 캐시가 꼬일 수 있다. assetPrefix는 Zone마다 정적 자산의 출처를 분리하는 안전장치다.

Q2. 메인 앱에서 /chat 요청을 채팅 Zone으로 보내면서 주소창은 유지하려면 어떤 설정이 필요한가?

✅ 정답: next.config의 rewrites 또는 프록시 계층에서 /chat/:path*를 채팅 앱의 URL로 매핑한다.

💡 상세 해설: redirect는 사용자 주소를 바꾸고 앱 경계를 드러낸다. Multi-Zones는 사용자에게 하나의 도메인처럼 보이게 하면서 내부적으로 요청을 다른 Zone에 보낸다. 공식 가이드도 Zone은 일반 Next.js 앱이며 라우팅 계층이 올바른 Zone으로 요청을 전달한다고 설명한다.

Q3. 영철이의 테스트 타임: 채팅 팀만 Next.js 새 버전으로 먼저 올리고 싶다. Multi-Zones가 도움 되는 지점과 조심할 지점은 무엇인가?

✅ 정답: Zone별 독립 배포와 버전 선택은 쉬워지지만, 공유 UI/인증/관측 규칙은 패키지와 계약으로 명확히 관리해야 한다.

💡 상세 해설: Multi-Zones는 조직 경계를 기술 경계로 반영할 때 강하다. 하지만 전역 상태를 쉽게 공유하는 구조가 아니므로 로그인 세션, 디자인 시스템, 이벤트 추적 이름이 흩어지기 쉽다. 영호라면 "쪼갤 수 있는가"보다 "쪼갠 뒤 계약을 유지할 수 있는가"를 먼저 묻는다.

🐣 영철이의 퇴근 일기

오늘은 마이크로 프론트엔드를 앱을 잘게 쪼개는 기술로만 보지 않게 됐다. 빌드 시간, 팀 자율성, 버전 업그레이드 속도 같은 조직 문제를 해결할 수 있지만, 그만큼 경계 계약을 더 엄격히 세워야 했다.

💡 "Multi-Zones는 코드 분리가 아니라 팀 간 책임 경계를 URL과 배포 단위로 드러내는 선택이다."

다음에 큰 기능을 별도 Zone으로 빼자는 이야기가 나오면 assetPrefix와 rewrites만 보지 않겠다. 인증 쿠키 범위, 공통 패키지 버전, 장애가 한 Zone에 머무르는지, 로그가 한 사용자 여정으로 이어지는지까지 같이 체크하겠다.

🔗 더 알아보기

• Next.js 공식 문서 — Multi-Zones
• Turborepo Documentation
• Vercel — Micro Frontends with Next.js