title: 멀티존(Multi-zones)과 Next.js를 사용하여 마이크로 프론트엔드 구축하는 방법
description: Next.js 멀티존을 사용하여 단일 도메인 아래에 여러 Next.js 앱을 배포하는 마이크로 프론트엔드 구축 방법에 대해 배워볼게요.
url: "https://nextjs.org/docs/app/guides/multi-zones"
version: 16.1.6
lastUpdated: 2026-02-27
prerequisites:
예제 코드 확인하기
여러분, 안녕하세요! 오늘은 조금 고급 주제일 수 있는 멀티존(Multi-Zones)에 대해 알아보겠습니다.
멀티존은 하나의 도메인에 있는 거대한 애플리케이션을 각각 특정 경로(path) 모음을 담당하는 더 작은 여러 개의 Next.js 애플리케이션으로 분리하는 마이크로 프론트엔드(micro-frontends) 접근 방식이에요. (마이크로 프론트엔드라는 개념이 조금 생소하실 수도 있는데, 백엔드의 마이크로서비스 아키텍처를 프론트엔드에 적용한 거라고 생각하시면 이해하기 쉬워요. 거대한 하나의 앱을 여러 조각으로 쪼개서 관리하는 거죠!)
이 기능은 애플리케이션 내에서 다른 페이지들과 별로 연관성이 없는 페이지 그룹이 있을 때 아주 유용하답니다. 이런 독립적인 페이지들을 별도의 존(zone, 즉 별도의 애플리케이션)으로 이동시키면, 각 애플리케이션의 크기를 확 줄일 수 있어요. 덕분에 빌드 시간도 훨씬 빨라지고, 특정 존에만 필요한 코드를 다른 곳에서 로드하지 않아도 되니 성능적으로 아주 훌륭하죠. 게다가 애플리케이션들이 서로 분리되어 있기 때문에, 멀티존을 사용하면 같은 도메인 내의 다른 애플리케이션들이 각자 원하는 다른 프레임워크를 선택해서 사용하는 것도 가능해집니다.
예를 들어, 다음과 같이 분리하고 싶은 페이지 모음이 있다고 가정해 볼게요.
/blog/*: 모든 블로그 포스트 페이지/dashboard/*: 사용자가 대시보드에 로그인했을 때 보는 모든 페이지/*: 다른 존(zone)에서 다루지 않는 나머지 모든 웹사이트 메인 페이지들
멀티존 기능을 지원받으면, 이 세 개의 애플리케이션이 모두 같은 도메인에서 서비스되고 사용자에게는 똑같은 하나의 사이트처럼 보이게 만들 수 있어요. 하지만 우리 같은 개발자들은 각 애플리케이션을 완전히 독립적으로 개발하고 배포할 수 있게 되는 거죠!
💡 강사의 팁: 만약 포트폴리오 프로젝트로 '벨로그(Velog) 뷰어'나 'AI 문서 번역기' 같은 걸 기획 중이시라면 이 멀티존 개념을 꼭 한 번 적용해 보세요. 예를 들어, 기존에 만들어둔 개인 웹 프로필이나 메인 포트폴리오 사이트는 /* 경로에 그대로 두고, 벨로그 뷰어 앱은 /velog-viewer/* 라는 완전히 독립된 Next.js 프로젝트로 분리해서 개발하는 겁니다. 면접관들에게 "프로젝트의 확장성과 유지보수성을 고려해 마이크로 프론트엔드 아키텍처를 도입해봤다"고 어필하기에 아주 강력한 무기가 될 거예요!
같은 존(zone) 안에 있는 페이지들 사이를 이동할 때는 소프트 네비게이션(soft navigation)이 발생해요. 이건 페이지를 아예 새로고침할 필요가 없는 부드럽고 빠른 이동 방식이죠. 예를 들어, 위 다이어그램에서 / 경로에서 /products 경로로 이동하는 건 동일한 구역 내의 이동이므로 소프트 네비게이션이 됩니다.
반면에, 한 존에서 다른 존에 있는 페이지로 이동할 때(예를 들어 / 에서 /dashboard로 이동)는 하드 네비게이션(hard navigation)이 발생하게 돼요. 이때는 현재 페이지의 리소스들을 메모리에서 완전히 내리고(unload), 새로운 페이지의 리소스들을 처음부터 다시 불러오게(load) 됩니다. 쉽게 말해 브라우저가 화면을 한 번 새로고침 하는 셈이죠. 그렇기 때문에 사용자가 자주 함께 방문하는 페이지들은 반드시 같은 존 안에 두어서 불필요한 하드 네비게이션을 피하는 것이 핵심입니다!
존(Zone)을 정의하는 방법
존은 특별한 게 아니라 그냥 평범한 Next.js 애플리케이션이에요. 다만, 다른 존에 있는 페이지나 정적(static) 파일들과 이름이 겹쳐서 충돌하는 것을 막기 위해 assetPrefix 속성을 추가로 설정해 주어야 합니다.
/** @type {import('next').NextConfig} */
const nextConfig = {
assetPrefix: '/blog-static',
}이렇게 설정하면 JavaScript나 CSS 같은 Next.js 에셋(자원)들은 앞에 assetPrefix가 붙게 되어서 다른 존의 에셋들과 절대 충돌하지 않게 돼요. 결과적으로 이런 에셋들은 각 존마다 /assetPrefix/_next/... (위 예시라면 /blog-static/_next/...) 같은 고유한 경로 아래에서 제공될 겁니다.
참고로, 다른 구체적인 존으로 라우팅되지 않은 나머지 모든 경로를 처리하는 기본(default) 애플리케이션은 굳이 assetPrefix를 설정할 필요가 없습니다.
Next.js 15 버전보다 이전 버전을 사용 중이시라면, 정적 에셋들을 제대로 처리하기 위해 아래처럼 별도의 rewrites (재작성) 설정이 추가로 필요할 수도 있었어요. 하지만 Next.js 15부터는 내부적으로 개선되어서 이 작업이 더 이상 필요하지 않으니 참고만 해주세요!
/** @type {import('next').NextConfig} */
const nextConfig = {
assetPrefix: '/blog-static',
async rewrites() {
return {
beforeFiles: [
{
source: '/blog-static/_next/:path+',
destination: '/_next/:path+',
},
],
}
},
}올바른 존으로 요청 라우팅하기
멀티존으로 분리해 두었다면, 각각의 경로들이 서로 다른 애플리케이션에 의해 서비스되고 있기 때문에 사용자의 요청을 알맞은 존으로 정확히 넘겨주어야(라우팅) 해요. 이를 위해 Nginx 같은 임의의 HTTP 프록시를 사용할 수도 있지만, 개발 편의성을 위해 Next.js 애플리케이션 중 하나(보통은 메인 앱)를 도메인 전체의 라우터 역할로 사용할 수도 있답니다.
Next.js 애플리케이션을 사용해 올바른 존으로 라우팅하려면 rewrites 기능을 활용하시면 돼요. 다른 존에서 서비스하는 각 경로마다 해당 요청을 다른 존의 도메인으로 보내도록 rewrite 규칙을 추가하는 거죠. 이때, 정적 에셋들에 대한 요청도 잊지 말고 함께 넘겨주셔야 합니다. 아래 코드를 볼까요?
async rewrites() {
return [
{
source: '/blog',
destination: `${process.env.BLOG_DOMAIN}/blog`,
},
{
source: '/blog/:path+',
destination: `${process.env.BLOG_DOMAIN}/blog/:path+`,
},
{
source: '/blog-static/:path+',
destination: `${process.env.BLOG_DOMAIN}/blog-static/:path+`,
}
];
}여기서 destination(목적지)은 반드시 스킴(예: https://)과 도메인을 모두 포함하여 해당 존에서 서비스되는 완전한 URL이어야 합니다. 일반적으로 이 도메인은 해당 존이 배포된 실제 프로덕션 도메인을 가리키게 설정하지만, 로컬에서 개발하실 때는 localhost 포트로 요청을 보내도록 설정할 수도 있어요.
알아두면 좋은 점: URL 경로는 각 존마다 고유해야 합니다. 예를 들어, 서로 다른 두 개의 존이 똑같이
/blog경로를 서비스하려고 한다면 라우팅 충돌이 발생하니 꼭 주의해 주세요!
💡 강사의 팁: 실무에서 개발하실 때 위 코드처럼 process.env.BLOG_DOMAIN 과 같은 환경 변수를 사용하는 건 정말 좋은 습관입니다. 로컬, 테스트, 운영 서버마다 바라봐야 하는 주소가 다를 텐데 이걸 하드코딩 해놓으면 나중에 수정하기가 아주 골치 아프거든요.
프록시(Proxy)를 사용한 요청 라우팅
요청에 대한 지연 시간(latency)을 최소화하려면 방금 배운 next.config.js의 rewrites를 통해 라우팅하는 것을 가장 추천합니다. 하지만 라우팅을 할 때 "특정 조건"에 따라 동적인 결정이 필요한 특별한 상황이라면 프록시를 사용할 수도 있어요.
예를 들어, 서버 마이그레이션을 진행 중이거나 A/B 테스트를 할 때 특정 기능 플래그(feature flag)가 켜져 있는지 확인해서 경로를 동적으로 라우팅해야 한다면 아래와 같이 프록시를 활용할 수 있습니다.
export async function proxy(request) {
const { pathname, search } = request.nextUrl
if (pathname === '/your-path' && myFeatureFlag.isEnabled()) {
return NextResponse.rewrite(`${rewriteDomain}${pathname}${search}`)
}
}존(Zones) 간의 링크 연결하기
현재 존에서 다른 존에 있는 경로로 링크를 걸 때는 Next.js가 기본으로 제공하는 <Link> 컴포넌트 대신 일반적인 HTML <a> 태그를 사용하셔야 합니다!
왜냐고요? Next.js의 <Link> 컴포넌트는 기본적으로 링크된 상대 경로의 페이지를 미리 불러오는 프리페칭(prefetch)을 시도하고, 앞서 설명했던 부드러운 화면 전환인 '소프트 네비게이션'을 하려고 시도하기 때문이에요. 하지만 멀티존 환경에서는 다른 존이 아예 다른 애플리케이션 서버이기 때문에 이 방식이 정상적으로 작동하지 않습니다. 따라서 브라우저가 완전히 새로운 페이지를 불러오도록(하드 네비게이션) 하려면 <a> 태그를 써야만 한답니다. 꼭 기억해 두세요!
코드 공유하기
서로 다른 존을 구성하는 Next.js 애플리케이션들은 제각각 다른 레포지토리(코드 저장소)에 따로 보관해도 아무 문제 없습니다. 하지만 여러 존에서 공통으로 쓰는 UI 컴포넌트나 유틸리티 함수들의 코드를 훨씬 쉽게 공유하기 위해 이 존들을 하나의 거대한 모노레포(monorepo) 안에 모아두는 방식이 실무에서는 훨씬 편리하게 쓰입니다.
만약 존들이 서로 다른 레포지토리에 떨어져 있다면, 공개(public) 또는 비공개(private) NPM 패키지 형태로 공통 코드를 배포해서 가져다 쓰는 방식으로 코드를 공유할 수도 있어요.
그리고 서로 다른 존에 있는 페이지들은 배포되는 시기가 다를 수 있겠죠? 이럴 때는 앞서 언급한 '기능 플래그(feature flags)'를 활용하면, 서로 다른 존에 흩어져 있는 연관 기능들을 배포 타이밍에 맞춰 동시에 한 번에 켜거나 끌 수 있어서 아주 유용하게 쓰일 수 있습니다.
서버 액션 (Server Actions)
멀티존 환경에서 서버 액션(Server Actions) 기능을 사용할 때는 아주 중요한 설정이 하나 있습니다. 바로 사용자가 마주하는(user-facing) 오리진(origin, 즉 도메인)을 명시적으로 허용해 주어야만 해요.
왜냐하면 사용자에게는 하나의 통합된 도메인으로 보이지만, 실제로는 뒤에서 여러 개의 각기 다른 애플리케이션 서버들이 동작하고 있어서 보안상 출처를 명확히 해줘야 하기 때문이죠. 여러분의 next.config.js 파일에 다음 설정들을 꼭 추가해 주세요:
const nextConfig = {
experimental: {
serverActions: {
allowedOrigins: ['your-production-domain.com'],
},
},
}이 설정에 대해 더 자세히 알고 싶으시다면 serverActions.allowedOrigins 공식 문서를 참고해 보세요!
모든 문서의 구조적인 개요를 확인하시려면 https://nextjs.org/docs/sitemap.md 를 확인해 주세요.
이용 가능한 모든 문서의 목록(인덱스)을 확인하시려면 https://nextjs.org/docs/llms.txt 를 확인해 주세요.
