🚀 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. Next.js Multi-Zones에서 assetPrefix를 설정해야 하는 결정적인 이유는?

• A) 빌드 속도를 높이기 위해서
• B) 여러 앱의 정적 파일(JS, CSS) 경로가 겹쳐서 브라우저가 혼란에 빠지는 걸 막기 위해
• C) SEO 점수를 높이기 위해
• D) 서버 용량을 아끼기 위해

✅ 정답: B
해설: 모든 Next.js 앱은 기본적으로 /_next/static/... 경로를 써. 두 앱의 파일명이 우연히 같으면(예: main.js) 브라우저 캐시가 꼬이겠지? 그래서 챗 앱은 /chat-static처럼 자기만의 이름을 가져야 해.

Q2. 다음 중 Multi-Zones 아키텍처의 장점이 아닌 것은?

• A) 팀별로 기술 스택이나 Next.js 버전을 다르게 가져갈 수 있다 (점진적 업데이트 가능).
• B) 특정 기능(Zone)의 에러가 전체 서비스로 번지는 것을 차단할 수 있다.
• C) 앱 간의 전역 상태 공유가 매우 쉽고 간편하다.
• D) 빌드 단위가 작아져서 배포 속도가 빨라진다.

✅ 정답: C
해설: Multi-Zones는 앱이 물리적으로 분리되어 있어 전역 상태 공유가 오히려 까다로워. 이건 단점이자, 앱 간 의존성을 줄이는 '의도된 설계'이기도 해.

🐣 영철이의 퇴근 일기

오늘은 정말 거대한 서비스의 뼈대를 쪼개고 합치는 'Micro-frontends & Multi-Zones' 를 배우면서 시야가 확 트이는 기분이었어! 처음엔 "왜 멀쩡한 앱을 굳이 쪼개서 복잡하게 만들지?" 싶었는데, 팀별로 독립적인 배포와 개발 속도를 보장하기 위한 '의도된 분리' 라는 걸 알고 나니 정말 깊은 뜻이 있었구나 싶더라.

💡 오늘의 교훈: "마이크로 프론트엔드는 단순한 기술적 유행이 아니라, 조직의 규모에 맞는 아키텍처 선택이다. 독립적인 Zone으로 앱을 격리하되, assetPrefix 와 rewrites 로 사용자에게는 하나의 거대한 '우주' 를 선물하자!"

영호 리드 님이 도메인 입점 비유를 들어 설명해 주실 때, 왜 각 Zone이 자기만의 정적 자산 경로를 가져야 하는지 단번에 이해가 가더라. 단순히 코드를 잘 짜는 걸 넘어, 팀 간의 협업 효율까지 고려하는 게 진짜 '시니어' 의 사고방식이라는 걸 깨달았어. 오늘 너무 거시적인 아키텍처를 고민했더니 머리가 띵하네. 퇴근길에 내가 좋아하는 단골 서점에 들러서 차분하게 책 좀 보면서 뇌를 식혀야겠어. 내일은 더 '유연한' 시스템을 설계하는 개발자가 될 거야! 🐣

🔗 더 알아보기

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