엣지 MFE 오케스트레이션으로 TTFB를 줄이는 Cloudflare Workers 구현법

솔직히 처음 마이크로 프론트엔드(MFE) 이야기를 들었을 때, "팀마다 독립 배포가 된다고? 좋아 보이는데, 그럼 사용자 브라우저에서 각자 번들을 다 받아야 하는 거 아냐?" 하는 생각부터 들었습니다. 클라이언트 사이드 컴포지션의 고질적인 문제, 그러니까 여러 MFE의 JS 번들이 순차적으로 로드되면서 초기 렌더링이 느려지는 현상을 경험한 분이라면 공감하실 겁니다. 서버 사이드 컴포지션으로 넘어가면 조금 낫지만, 이번엔 중앙 서버가 병목이 되고 독립 배포라는 MFE의 핵심 가치가 흐릿해지죠.

엣지 MFE 런타임 오케스트레이션은 이 두 가지 한계를 동시에 넘어서는 접근 방식입니다. CDN 엣지 노드에서 각 팀의 HTML·JS 프래그먼트를 사용자와 가장 가까운 위치에서 조립해 단일 응답으로 내려보내는 구조인데, 실제 레퍼런스에서는 중앙 서버 기반 대비 TTFB가 눈에 띄게 줄었다는 보고가 나오고 있습니다(조건과 인프라 구성에 따라 차이가 있습니다). 이 글에서는 이 패러다임이 왜 지금 주목받는지, Cloudflare Workers로 Router Worker를 실제로 어떻게 구성하는지, 그리고 ESI와 Manifest Resolver가 하나의 시스템을 이루는 구조까지 살펴보겠습니다. 현재 클라이언트 사이드 MFE를 운영 중이며 TTFB 개선을 고민 중인 분께 특히 유용할 내용입니다.

핵심 개념

세 가지 컴포지션 방식, 엣지가 다른 이유

MFE를 어떻게 조합하느냐에 따라 크게 세 가지 레이어로 나뉩니다. 각 방식이 어디서 조립을 담당하는지를 보면 차이가 명확합니다.

방식	조립 위치	특징	주요 단점
클라이언트 사이드 컴포지션	브라우저	유연성 최대	초기 로드 느림, 번들 폭증
서버 사이드 컴포지션	중앙 서버	SEO 유리	중앙 서버 병목, 독립 배포 어려움
엣지 사이드 컴포지션	CDN 엣지 노드	TTFB 최소화, 독립 배포 유지	운영 복잡도, 상태 관리 난이도

엣지 컴포지션의 핵심: 사용자와 50ms 이내 거리에 있는 엣지 노드가 각 팀의 MFE 프래그먼트를 수집해 단일 통합 응답으로 조립합니다. 중앙 서버를 거치지 않으니 왕복 지연이 줄고, 각 팀은 여전히 독립 배포를 유지합니다.

오케스트레이션의 핵심 구성 요소

엣지 MFE 오케스트레이션을 이해하려면 다섯 가지 개념을 알아두면 됩니다.

Router Worker는 URL 경로 기반으로 들어오는 요청을 적절한 MFE Worker에 전달하는 관문입니다. Service Binding은 Cloudflare 고유의 기능으로, 같은 데이터센터 내에서 Worker끼리 HTTP 왕복 없이 직접 통신하는 방식입니다. 단순히 "공개 인터넷을 거치지 않는다"는 것이 핵심이 아니라, 별도의 네트워크 왕복 자체가 없기 때문에 일반 HTTP 호출 대비 지연이 거의 0에 수렴한다는 점이 중요합니다.

Remote Entry / Manifest는 런타임에 MFE 번들 위치를 동적으로 선언하는 명세이고, **ESI(Edge Side Include)**는 CDN 레벨에서 <esi:include> 태그로 콘텐츠를 동적으로 조합하는 마크업 기술입니다. Import Map은 조금 낯설 수 있는데, 백엔드 개발자라면 package.json의 imports 필드와 비슷한 역할이라고 생각하면 이해하기 쉽습니다. 브라우저가 import 'team-a/App.js' 같은 구문을 만났을 때 실제 CDN URL로 매핑해주는 브라우저 네이티브 모듈 경로 선언입니다.

Module Federation 3.0과 Native ESM Federation

저도 처음엔 Module Federation이라고 하면 Webpack에 묶인 기술이라고 생각했는데, 2026년 기준으로는 이야기가 많이 달라졌습니다. Native ESM Federation은 Webpack 빌드 과정 없이 브라우저 네이티브 import(), Import Maps, Top-Level Await만으로 MFE를 페더레이션합니다.

html

<!-- Import Maps를 활용한 Native ESM Federation -->
<script type="importmap">
{
  "imports": {
    "shell/": "https://cdn.example.com/shell/v2.1.4-a3f8c9d/",
    "team-a/": "https://cdn.example.com/team-a/v1.8.2-b7e2f1a/",
    "team-b/": "https://cdn.example.com/team-b/v3.0.1-c9d4e8b/"
  }
}
</script>
<script type="module">
  const { default: TeamAApp } = await import('team-a/App.js');
  const { default: TeamBApp } = await import('team-b/App.js');
 
  TeamAApp.mount('#section-a');
  TeamBApp.mount('#section-b');
</script>

URL에 버전 해시를 포함한 이유는 CDN 캐시 버스팅 때문입니다. 배포할 때마다 경로가 바뀌어야 CDN이 새 버전을 확실하게 서빙합니다.

한 가지 주의할 점은 Import Maps의 브라우저 지원 현황입니다. Safari 16.4 이상, Chrome 89 이상에서 네이티브 지원되며, 더 낮은 버전을 지원해야 한다면 es-module-shims 같은 폴리필이 필요합니다. 모듈 버전 충돌 문제, 예를 들어 team-a와 team-b가 각각 다른 버전의 React를 요구하는 경우는 Import Map 단계에서 단일 버전으로 강제하거나, 각 MFE를 완전히 격리된 Shadow DOM 컨텍스트로 격리하는 전략을 검토해볼 수 있습니다.

Manifest Endpoint 기반 버전 관리

예전에는 remoteEntry.js를 정적으로 참조했는데, 이제는 Manifest Endpoint를 통해 런타임에 버전을 동적으로 해석하는 방식이 확산되고 있습니다.

json

// GET /manifest.json — 엣지 Worker에서 처리
{
  "version": "2.4.1",
  "entries": {
    "team-a": {
      "url": "https://cdn.example.com/team-a/v1.8.2-b7e2f1a/remoteEntry.js",
      "integrity": "sha384-abc123...",
      "canary": false
    },
    "team-b": {
      "url": "https://cdn.example.com/team-b/v3.0.1-canary.3-c9d4e8b/remoteEntry.js",
      "integrity": "sha384-def456...",
      "canary": true,
      "canaryPercentage": 10
    }
  }
}

이 구조 덕분에 카나리 배포, A/B 테스트, 점진적 롤아웃을 엣지 레이어에서 자연스럽게 처리할 수 있습니다. 배포 담당자 입장에서는 코드 변경 없이 Manifest만 바꿔서 트래픽을 조절할 수 있으니 꽤 편리한 구조입니다.

실전 적용

개념을 이해했으니, 실제로 어떻게 구현하는지 살펴보겠습니다. 아래 세 가지 예시는 독립적인 코드 스니펫이 아니라 하나의 시스템을 구성하는 레이어들입니다.

Router Worker가 모든 요청을 받아 팀별 Worker로 분기하고, 각 팀 Worker 중 일부는 ESI 마크업이 포함된 HTML 응답을 반환하며, 이 HTML에서 어떤 버전의 클라이언트 번들을 로드할지는 Manifest Resolver가 결정합니다. 세 컴포넌트가 순서대로 연결되어 "요청 라우팅 → 서버 프래그먼트 조합 → 클라이언트 번들 버전 결정"이라는 흐름을 만듭니다.

예시 1: Router Worker로 경로 기반 라우팅 구성하기

Cloudflare의 VMFE 공식 템플릿이 공개되면서 구현 패턴이 많이 명확해졌습니다. Router Worker가 URL 경로를 보고 Service Binding으로 각 팀의 Worker를 직접 호출하는 구조입니다. 실무에서 쓸 수 있으려면 팀 Worker가 응답하지 않을 때의 폴백 처리와 요청 헤더 전달이 빠져서는 안 됩니다.

typescript

// router-worker/src/index.ts
export interface Env {
  TEAM_A_WORKER: Fetcher; // Service Binding: /products 경로
  TEAM_B_WORKER: Fetcher; // Service Binding: /orders 경로
  SHELL_WORKER: Fetcher;   // Service Binding: 공통 레이아웃
}
 
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
 
    // 원본 헤더를 그대로 전달해 팀 Worker가 인증·지역 정보를 활용할 수 있도록
    const forwardRequest = new Request(request);
 
    try {
      if (url.pathname.startsWith('/products')) {
        return await withTimeout(env.TEAM_A_WORKER.fetch(forwardRequest), 3000);
      }
 
      if (url.pathname.startsWith('/orders')) {
        return await withTimeout(env.TEAM_B_WORKER.fetch(forwardRequest), 3000);
      }
 
      return await env.SHELL_WORKER.fetch(forwardRequest);
    } catch (err) {
      // 팀 Worker 장애 시 503으로 명시적 응답 (무한 대기 방지)
      const message = err instanceof Error ? err.message : 'upstream error';
      return new Response(`Service unavailable: ${message}`, { status: 503 });
    }
  },
};
 
function withTimeout(promise: Promise<Response>, ms: number): Promise<Response> {
  return Promise.race([
    promise,
    new Promise<Response>((_, reject) =>
      setTimeout(() => reject(new Error(`timeout after ${ms}ms`)), ms)
    ),
  ]);
}

toml

# wrangler.toml — Service Binding 선언
name = "router-worker"
 
[[services]]
binding = "TEAM_A_WORKER"
service = "team-a-worker"
 
[[services]]
binding = "TEAM_B_WORKER"
service = "team-b-worker"
 
[[services]]
binding = "SHELL_WORKER"
service = "shell-worker"

코드 포인트	설명
`Fetcher` 타입	Service Binding 인터페이스. 같은 데이터센터 내 zero-latency 통신, HTTP 왕복 없음
`withTimeout`	팀 Worker 무응답 시 라우터 전체가 멈추는 상황 방지
`new Request(request)`	원본 헤더(쿠키, 인증 토큰, CF-IPCountry 등)를 하위 Worker에 그대로 전달
`[[services]]`	각 팀 Worker를 독립 서비스로 선언해 별도 배포 가능

예시 2: ESI로 레거시 시스템과 MFE 혼합하기

Akamai, Cloudflare, Fastly처럼 ESI를 지원하는 CDN을 이미 쓰고 있다면, 레거시 시스템을 한 번에 교체하지 않고 점진적으로 MFE를 도입할 수 있습니다. 실무에서 가장 자주 맞닥뜨리는 시나리오입니다. Cloudflare의 경우 Workers의 응답 본문에서 ESI를 처리하려면 cf: { minify: { html: false } } 설정을 꺼두고, 응답 헤더에 Surrogate-Control: ESI/1.0을 붙여줘야 합니다.

html

<!-- CDN 레이어에서 처리되는 ESI 마크업 -->
<!DOCTYPE html>
<html>
<head>
  <title>My App</title>
  <esi:include src="https://legacy.example.com/fragments/header" />
</head>
<body>
  <!--
    onerror="continue": 이 프래그먼트 요청이 실패해도 페이지 나머지는 정상 렌더링.
    ESI 요청은 CDN이 병렬로 처리하므로 순차 지연 없음.
    단, 타임아웃은 CDN 벤더 설정에서 별도 조정 필요 (Cloudflare 기본값 30s).
  -->
  <esi:include src="https://mfe-team-a.example.com/fragment/product-list"
               onerror="continue" />
 
  <div id="legacy-content">
    <!-- 기존 서버에서 렌더링된 내용 -->
  </div>
 
  <esi:include src="https://mfe-team-b.example.com/fragment/cart"
               onerror="continue" />
</body>
</html>

typescript

// team-a/src/fragment.ts — 팀A가 독립 운영하는 프래그먼트 엔드포인트
export default {
  async fetch(request: Request): Promise<Response> {
    const html = await renderProductList();
 
    return new Response(html, {
      headers: {
        'Content-Type': 'text/html',
        // 1분 캐시 후 stale-while-revalidate로 부드럽게 갱신
        'Cache-Control': 'public, max-age=60, stale-while-revalidate=300',
        // CDN(Surrogate) 레이어에서는 10분 캐시
        'Surrogate-Control': 'max-age=600',
      },
    });
  },
};

코드 포인트	설명
`onerror="continue"`	특정 프래그먼트 장애가 전체 페이지 렌더링을 막지 않도록 격리
ESI 병렬 처리	CDN이 `<esi:include>` 요청을 병렬 발행. 직렬 체인이 아님
`stale-while-revalidate`	캐시 만료 후에도 이전 버전을 즉시 반환, 백그라운드 갱신
독립 엔드포인트	각 팀이 자기 Fragment URL만 관리하므로 독립 배포 가능

예시 3: Manifest Resolver로 카나리 배포 제어하기

엣지 Worker에서 요청자의 특성에 따라 어떤 MFE 버전을 내려줄지 동적으로 결정할 수 있습니다. 이 예시가 Router Worker → ESI 프래그먼트와 연결되는 지점은, 클라이언트가 페이지를 받은 후 추가로 /manifest.json을 요청해 어떤 JS 번들을 로드할지 결정한다는 것입니다.

초안에서 쓰던 charCode 합산 방식은 분포가 균등하지 않아 카나리 비율이 실제와 차이가 납니다. 아래 FNV-1a 해시를 쓰면 같은 userId에는 항상 동일한 결과를 내면서 100버킷 분포가 훨씬 고릅니다.

typescript

// manifest-resolver/src/index.ts
export default {
  async fetch(request: Request): Promise<Response> {
    const userId = request.headers.get('X-User-Id') ?? '';
    const isCanaryUser = shouldReceiveCanary(userId, 10); // 10% 카나리
 
    const manifest = {
      'team-a': isCanaryUser
        ? 'https://cdn.example.com/team-a/v1.9.0-canary.1-d3a8f2c/remoteEntry.js'
        : 'https://cdn.example.com/team-a/v1.8.2-b7e2f1a/remoteEntry.js',
      'team-b': 'https://cdn.example.com/team-b/v3.0.1-c9d4e8b/remoteEntry.js',
    };
 
    return Response.json(manifest, {
      headers: { 'Cache-Control': 'no-store' }, // 개인화 응답은 캐시 불가
    });
  },
};
 
function shouldReceiveCanary(userId: string, percentage: number): boolean {
  // FNV-1a 32-bit: charCode 단순 합산보다 균등한 버킷 분포
  let hash = 2166136261;
  for (let i = 0; i < userId.length; i++) {
    hash ^= userId.charCodeAt(i);
    hash = Math.imul(hash, 16777619) >>> 0;
  }
  return (hash % 100) < percentage;
}

코드 포인트	설명
FNV-1a 해시	동일 userId → 항상 동일 버킷. 사용자가 새로고침할 때마다 버전이 바뀌지 않음
`Math.imul(...) >>> 0`	32-bit 정수 연산을 JS에서 안전하게 처리
`no-store`	개인화된 응답은 CDN이 캐싱하면 안 됨. Manifest만 no-store, 번들은 별도 캐싱 전략

장단점 분석

장점

항목	내용
초저지연	사용자 근거리 엣지에서 실행. 중앙 서버 왕복 제거로 TTFB 크게 개선
독립 배포	팀별 CI/CD 파이프라인, 기술 스택 선택 완전 자유
고가용성	엣지 노드 분산 특성으로 단일 장애점 제거
콜드 스타트 최소화	V8 Isolate 기반 아키텍처로 밀리초 수준 콜드 스타트
유연한 캐싱	동적·정적 콘텐츠 혼재 시 프래그먼트별 캐싱 전략 독립 적용

단점 및 주의사항

항목	내용	대응 방안
운영 복잡도	다수 엣지 Worker 및 라우팅 규칙 관리 부담	Terraform, Pulumi 등 IaC로 Worker 선언 자동화
CDN 의존성	ESI 지원 CDN이 제한적 (Akamai, Cloudflare, Fastly, Varnish)	Import Maps 기반 Native Federation으로 CDN 의존 최소화
무상태성 제약	엣지 함수는 상태를 유지하지 않아 세션 관리가 복잡	Cloudflare KV, Durable Objects 등 엣지 스토리지 활용
로컬 개발 난이도	엣지 환경(Web API 전용)을 로컬에서 재현하기 어려움	Miniflare, Wrangler 로컬 모드 초기 세팅
벤더 파편화	ESI 동작 방식이 CDN 벤더마다 미묘하게 다름	특정 벤더 전용 기능 의존 최소화, 공통 추상화 레이어
조직 성숙도 필요	명확한 API 계약과 팀 간 거버넌스 없으면 효과 반감	인터페이스 계약 문서화, 공통 디자인 시스템 선행 구축

V8 Isolate: Chromium V8 엔진이 제공하는 격리 실행 환경. 컨테이너 없이 수십 밀리초 안에 시작할 수 있어 엣지 함수의 콜드 스타트 문제를 해결하는 핵심 기술입니다.

stale-while-revalidate: HTTP 캐싱 지시어. 캐시가 만료된 이후에도 이전 버전을 즉시 반환하면서 백그라운드에서 새 버전을 가져옵니다. 사용자는 항상 빠른 응답을 받을 수 있습니다.

실무에서 가장 흔한 실수

ESI와 클라이언트 사이드 컴포지션을 혼용하면서 캐싱 정책을 통일하지 않는 경우. 저희 팀이 처음 ESI를 도입했을 때 서버·엣지·브라우저 캐시에 각각 다른 버전이 올라가는 바람에, 특정 사용자에게 장바구니 UI가 헤더와 버전이 다르게 렌더링되는 상황을 경험했습니다. Surrogate-Control과 Cache-Control을 함께 명시적으로 선언하는 것이 첫 번째 점검 항목이었습니다.
팀 간 API 계약 없이 엣지 오케스트레이션부터 도입하는 경우. 각 팀의 프래그먼트가 어떤 인터페이스를 노출해야 하는지 사전 합의 없이 시작하면, Router Worker가 금세 팀별 예외 처리로 가득 차게 됩니다. 프래그먼트 URL 패턴, 캐싱 헤더 규격, 에러 응답 형식을 JSON Schema로 먼저 정의하는 것이 나중에 훨씬 편합니다.
로컬 개발 환경 세팅을 미루는 경우. 엣지 환경은 Node.js API를 쓸 수 없고 Web API만 사용 가능한 제약이 있는데, 이걸 배포 직전에 발견하면 디버깅이 매우 고통스럽습니다. wrangler dev 또는 Miniflare를 프로젝트 초기에 세팅해두면 이 문제를 사전에 차단할 수 있습니다.

마치며

엣지 MFE 런타임 오케스트레이션은 팀 독립성과 사용자 경험이라는 두 목표를 동시에 추구할 때 가장 강력한 선택지가 됩니다. 다만 이 기술을 도입하기 전에 솔직히 물어봐야 할 것이 하나 있습니다. 트래픽이 많지 않은 내부 도구나, 개발팀이 1~2개인 작은 제품에서는 엣지 Worker 여러 개를 운영하는 복잡도가 이점보다 비용이 더 클 수 있습니다. "독립 배포해야 할 팀이 실제로 여럿인가?"라는 질문이 이 기술의 적합성을 판단하는 가장 빠른 기준입니다.

지금 바로 시작해볼 수 있는 3단계:

Cloudflare의 VMFE 공식 템플릿을 클론해서 로컬에서 돌려볼 수 있습니다. npm create cloudflare@latest -- --template=cloudflare/workers-sdk/templates/worker-mfe 명령어로 시작하면, Router Worker와 두 개의 서브 Worker가 함께 생성되어 Service Binding 구조를 바로 체험해볼 수 있습니다.
현재 운영 중인 모놀리스에서 독립 배포 가능한 작은 영역 하나를 선정해 ESI 프래그먼트로 분리해보는 것을 권장합니다. 첫 번째 후보로는 다른 팀이 소유하거나, 업데이트 빈도가 나머지 페이지와 확연히 다른 UI 블록이 좋습니다. 예를 들어 헤더는 디자인팀이 자주 바꾸지만 상품 목록은 커머스팀이 관리하는 경우, 헤더 하나를 ESI 프래그먼트로 분리해 각자 배포할 수 있게 되는 것입니다. 변경 주기가 다른 두 영역이 하나의 배포 단위로 묶여 있는 곳을 찾는 것이 핵심입니다.
팀 간 MFE 인터페이스 계약을 Manifest Endpoint 스펙으로 문서화해두면 좋습니다. 어떤 경로에서 어떤 프래그먼트를 반환하는지, 캐싱 정책은 어떻게 되는지를 JSON Schema로 정의해두면 이후 오케스트레이션 레이어 구성이 훨씬 수월해집니다.

참고 자료

#MicroFrontends#CloudflareWorkers#엣지컴퓨팅#ESI#ModuleFederation#ImportMap#ServiceBinding#NativeESM#TypeScript#카나리배포

엣지 MFE 오케스트레이션으로 TTFB를 줄이는 Cloudflare Workers 구현법 | DEV BAK - 기술블로그

frontend

엣지 MFE 오케스트레이션으로 TTFB를 줄이는 Cloudflare Workers 구현법

핵심 개념

세 가지 컴포지션 방식, 엣지가 다른 이유

MFE를 어떻게 조합하느냐에 따라 크게 세 가지 레이어로 나뉩니다. 각 방식이 어디서 조립을 담당하는지를 보면 차이가 명확합니다.

방식	조립 위치	특징	주요 단점
클라이언트 사이드 컴포지션	브라우저	유연성 최대	초기 로드 느림, 번들 폭증
서버 사이드 컴포지션	중앙 서버	SEO 유리	중앙 서버 병목, 독립 배포 어려움
엣지 사이드 컴포지션	CDN 엣지 노드	TTFB 최소화, 독립 배포 유지	운영 복잡도, 상태 관리 난이도

엣지 컴포지션의 핵심: 사용자와 50ms 이내 거리에 있는 엣지 노드가 각 팀의 MFE 프래그먼트를 수집해 단일 통합 응답으로 조립합니다. 중앙 서버를 거치지 않으니 왕복 지연이 줄고, 각 팀은 여전히 독립 배포를 유지합니다.

오케스트레이션의 핵심 구성 요소

엣지 MFE 오케스트레이션을 이해하려면 다섯 가지 개념을 알아두면 됩니다.

Module Federation 3.0과 Native ESM Federation

html

<!-- Import Maps를 활용한 Native ESM Federation -->
<script type="importmap">
{
  "imports": {
    "shell/": "https://cdn.example.com/shell/v2.1.4-a3f8c9d/",
    "team-a/": "https://cdn.example.com/team-a/v1.8.2-b7e2f1a/",
    "team-b/": "https://cdn.example.com/team-b/v3.0.1-c9d4e8b/"
  }
}
</script>
<script type="module">
  const { default: TeamAApp } = await import('team-a/App.js');
  const { default: TeamBApp } = await import('team-b/App.js');
 
  TeamAApp.mount('#section-a');
  TeamBApp.mount('#section-b');
</script>

URL에 버전 해시를 포함한 이유는 CDN 캐시 버스팅 때문입니다. 배포할 때마다 경로가 바뀌어야 CDN이 새 버전을 확실하게 서빙합니다.

Manifest Endpoint 기반 버전 관리

예전에는 remoteEntry.js를 정적으로 참조했는데, 이제는 Manifest Endpoint를 통해 런타임에 버전을 동적으로 해석하는 방식이 확산되고 있습니다.

json

// GET /manifest.json — 엣지 Worker에서 처리
{
  "version": "2.4.1",
  "entries": {
    "team-a": {
      "url": "https://cdn.example.com/team-a/v1.8.2-b7e2f1a/remoteEntry.js",
      "integrity": "sha384-abc123...",
      "canary": false
    },
    "team-b": {
      "url": "https://cdn.example.com/team-b/v3.0.1-canary.3-c9d4e8b/remoteEntry.js",
      "integrity": "sha384-def456...",
      "canary": true,
      "canaryPercentage": 10
    }
  }
}

실전 적용

예시 1: Router Worker로 경로 기반 라우팅 구성하기

typescript

// router-worker/src/index.ts
export interface Env {
  TEAM_A_WORKER: Fetcher; // Service Binding: /products 경로
  TEAM_B_WORKER: Fetcher; // Service Binding: /orders 경로
  SHELL_WORKER: Fetcher;   // Service Binding: 공통 레이아웃
}
 
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
 
    // 원본 헤더를 그대로 전달해 팀 Worker가 인증·지역 정보를 활용할 수 있도록
    const forwardRequest = new Request(request);
 
    try {
      if (url.pathname.startsWith('/products')) {
        return await withTimeout(env.TEAM_A_WORKER.fetch(forwardRequest), 3000);
      }
 
      if (url.pathname.startsWith('/orders')) {
        return await withTimeout(env.TEAM_B_WORKER.fetch(forwardRequest), 3000);
      }
 
      return await env.SHELL_WORKER.fetch(forwardRequest);
    } catch (err) {
      // 팀 Worker 장애 시 503으로 명시적 응답 (무한 대기 방지)
      const message = err instanceof Error ? err.message : 'upstream error';
      return new Response(`Service unavailable: ${message}`, { status: 503 });
    }
  },
};
 
function withTimeout(promise: Promise<Response>, ms: number): Promise<Response> {
  return Promise.race([
    promise,
    new Promise<Response>((_, reject) =>
      setTimeout(() => reject(new Error(`timeout after ${ms}ms`)), ms)
    ),
  ]);
}

toml

# wrangler.toml — Service Binding 선언
name = "router-worker"
 
[[services]]
binding = "TEAM_A_WORKER"
service = "team-a-worker"
 
[[services]]
binding = "TEAM_B_WORKER"
service = "team-b-worker"
 
[[services]]
binding = "SHELL_WORKER"
service = "shell-worker"

코드 포인트	설명
`Fetcher` 타입	Service Binding 인터페이스. 같은 데이터센터 내 zero-latency 통신, HTTP 왕복 없음
`withTimeout`	팀 Worker 무응답 시 라우터 전체가 멈추는 상황 방지
`new Request(request)`	원본 헤더(쿠키, 인증 토큰, CF-IPCountry 등)를 하위 Worker에 그대로 전달
`[[services]]`	각 팀 Worker를 독립 서비스로 선언해 별도 배포 가능

예시 2: ESI로 레거시 시스템과 MFE 혼합하기

html

<!-- CDN 레이어에서 처리되는 ESI 마크업 -->
<!DOCTYPE html>
<html>
<head>
  <title>My App</title>
  <esi:include src="https://legacy.example.com/fragments/header" />
</head>
<body>
  <!--
    onerror="continue": 이 프래그먼트 요청이 실패해도 페이지 나머지는 정상 렌더링.
    ESI 요청은 CDN이 병렬로 처리하므로 순차 지연 없음.
    단, 타임아웃은 CDN 벤더 설정에서 별도 조정 필요 (Cloudflare 기본값 30s).
  -->
  <esi:include src="https://mfe-team-a.example.com/fragment/product-list"
               onerror="continue" />
 
  <div id="legacy-content">
    <!-- 기존 서버에서 렌더링된 내용 -->
  </div>
 
  <esi:include src="https://mfe-team-b.example.com/fragment/cart"
               onerror="continue" />
</body>
</html>

typescript

// team-a/src/fragment.ts — 팀A가 독립 운영하는 프래그먼트 엔드포인트
export default {
  async fetch(request: Request): Promise<Response> {
    const html = await renderProductList();
 
    return new Response(html, {
      headers: {
        'Content-Type': 'text/html',
        // 1분 캐시 후 stale-while-revalidate로 부드럽게 갱신
        'Cache-Control': 'public, max-age=60, stale-while-revalidate=300',
        // CDN(Surrogate) 레이어에서는 10분 캐시
        'Surrogate-Control': 'max-age=600',
      },
    });
  },
};

코드 포인트	설명
`onerror="continue"`	특정 프래그먼트 장애가 전체 페이지 렌더링을 막지 않도록 격리
ESI 병렬 처리	CDN이 `<esi:include>` 요청을 병렬 발행. 직렬 체인이 아님
`stale-while-revalidate`	캐시 만료 후에도 이전 버전을 즉시 반환, 백그라운드 갱신
독립 엔드포인트	각 팀이 자기 Fragment URL만 관리하므로 독립 배포 가능

예시 3: Manifest Resolver로 카나리 배포 제어하기

typescript

// manifest-resolver/src/index.ts
export default {
  async fetch(request: Request): Promise<Response> {
    const userId = request.headers.get('X-User-Id') ?? '';
    const isCanaryUser = shouldReceiveCanary(userId, 10); // 10% 카나리
 
    const manifest = {
      'team-a': isCanaryUser
        ? 'https://cdn.example.com/team-a/v1.9.0-canary.1-d3a8f2c/remoteEntry.js'
        : 'https://cdn.example.com/team-a/v1.8.2-b7e2f1a/remoteEntry.js',
      'team-b': 'https://cdn.example.com/team-b/v3.0.1-c9d4e8b/remoteEntry.js',
    };
 
    return Response.json(manifest, {
      headers: { 'Cache-Control': 'no-store' }, // 개인화 응답은 캐시 불가
    });
  },
};
 
function shouldReceiveCanary(userId: string, percentage: number): boolean {
  // FNV-1a 32-bit: charCode 단순 합산보다 균등한 버킷 분포
  let hash = 2166136261;
  for (let i = 0; i < userId.length; i++) {
    hash ^= userId.charCodeAt(i);
    hash = Math.imul(hash, 16777619) >>> 0;
  }
  return (hash % 100) < percentage;
}

코드 포인트	설명
FNV-1a 해시	동일 userId → 항상 동일 버킷. 사용자가 새로고침할 때마다 버전이 바뀌지 않음
`Math.imul(...) >>> 0`	32-bit 정수 연산을 JS에서 안전하게 처리
`no-store`	개인화된 응답은 CDN이 캐싱하면 안 됨. Manifest만 no-store, 번들은 별도 캐싱 전략

장단점 분석

장점

항목	내용
초저지연	사용자 근거리 엣지에서 실행. 중앙 서버 왕복 제거로 TTFB 크게 개선
독립 배포	팀별 CI/CD 파이프라인, 기술 스택 선택 완전 자유
고가용성	엣지 노드 분산 특성으로 단일 장애점 제거
콜드 스타트 최소화	V8 Isolate 기반 아키텍처로 밀리초 수준 콜드 스타트
유연한 캐싱	동적·정적 콘텐츠 혼재 시 프래그먼트별 캐싱 전략 독립 적용

단점 및 주의사항

항목	내용	대응 방안
운영 복잡도	다수 엣지 Worker 및 라우팅 규칙 관리 부담	Terraform, Pulumi 등 IaC로 Worker 선언 자동화
CDN 의존성	ESI 지원 CDN이 제한적 (Akamai, Cloudflare, Fastly, Varnish)	Import Maps 기반 Native Federation으로 CDN 의존 최소화
무상태성 제약	엣지 함수는 상태를 유지하지 않아 세션 관리가 복잡	Cloudflare KV, Durable Objects 등 엣지 스토리지 활용
로컬 개발 난이도	엣지 환경(Web API 전용)을 로컬에서 재현하기 어려움	Miniflare, Wrangler 로컬 모드 초기 세팅
벤더 파편화	ESI 동작 방식이 CDN 벤더마다 미묘하게 다름	특정 벤더 전용 기능 의존 최소화, 공통 추상화 레이어
조직 성숙도 필요	명확한 API 계약과 팀 간 거버넌스 없으면 효과 반감	인터페이스 계약 문서화, 공통 디자인 시스템 선행 구축

V8 Isolate: Chromium V8 엔진이 제공하는 격리 실행 환경. 컨테이너 없이 수십 밀리초 안에 시작할 수 있어 엣지 함수의 콜드 스타트 문제를 해결하는 핵심 기술입니다.

stale-while-revalidate: HTTP 캐싱 지시어. 캐시가 만료된 이후에도 이전 버전을 즉시 반환하면서 백그라운드에서 새 버전을 가져옵니다. 사용자는 항상 빠른 응답을 받을 수 있습니다.

실무에서 가장 흔한 실수

ESI와 클라이언트 사이드 컴포지션을 혼용하면서 캐싱 정책을 통일하지 않는 경우. 저희 팀이 처음 ESI를 도입했을 때 서버·엣지·브라우저 캐시에 각각 다른 버전이 올라가는 바람에, 특정 사용자에게 장바구니 UI가 헤더와 버전이 다르게 렌더링되는 상황을 경험했습니다. Surrogate-Control과 Cache-Control을 함께 명시적으로 선언하는 것이 첫 번째 점검 항목이었습니다.
팀 간 API 계약 없이 엣지 오케스트레이션부터 도입하는 경우. 각 팀의 프래그먼트가 어떤 인터페이스를 노출해야 하는지 사전 합의 없이 시작하면, Router Worker가 금세 팀별 예외 처리로 가득 차게 됩니다. 프래그먼트 URL 패턴, 캐싱 헤더 규격, 에러 응답 형식을 JSON Schema로 먼저 정의하는 것이 나중에 훨씬 편합니다.
로컬 개발 환경 세팅을 미루는 경우. 엣지 환경은 Node.js API를 쓸 수 없고 Web API만 사용 가능한 제약이 있는데, 이걸 배포 직전에 발견하면 디버깅이 매우 고통스럽습니다. wrangler dev 또는 Miniflare를 프로젝트 초기에 세팅해두면 이 문제를 사전에 차단할 수 있습니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

Cloudflare의 VMFE 공식 템플릿을 클론해서 로컬에서 돌려볼 수 있습니다. npm create cloudflare@latest -- --template=cloudflare/workers-sdk/templates/worker-mfe 명령어로 시작하면, Router Worker와 두 개의 서브 Worker가 함께 생성되어 Service Binding 구조를 바로 체험해볼 수 있습니다.
현재 운영 중인 모놀리스에서 독립 배포 가능한 작은 영역 하나를 선정해 ESI 프래그먼트로 분리해보는 것을 권장합니다. 첫 번째 후보로는 다른 팀이 소유하거나, 업데이트 빈도가 나머지 페이지와 확연히 다른 UI 블록이 좋습니다. 예를 들어 헤더는 디자인팀이 자주 바꾸지만 상품 목록은 커머스팀이 관리하는 경우, 헤더 하나를 ESI 프래그먼트로 분리해 각자 배포할 수 있게 되는 것입니다. 변경 주기가 다른 두 영역이 하나의 배포 단위로 묶여 있는 곳을 찾는 것이 핵심입니다.
팀 간 MFE 인터페이스 계약을 Manifest Endpoint 스펙으로 문서화해두면 좋습니다. 어떤 경로에서 어떤 프래그먼트를 반환하는지, 캐싱 정책은 어떻게 되는지를 JSON Schema로 정의해두면 이후 오케스트레이션 레이어 구성이 훨씬 수월해집니다.

참고 자료

#MicroFrontends#CloudflareWorkers#엣지컴퓨팅#ESI#ModuleFederation#ImportMap#ServiceBinding#NativeESM#TypeScript#카나리배포

핵심 개념

세 가지 컴포지션 방식, 엣지가 다른 이유

오케스트레이션의 핵심 구성 요소

Module Federation 3.0과 Native ESM Federation

Manifest Endpoint 기반 버전 관리

실전 적용

예시 1: Router Worker로 경로 기반 라우팅 구성하기

예시 2: ESI로 레거시 시스템과 MFE 혼합하기

예시 3: Manifest Resolver로 카나리 배포 제어하기

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

세 가지 컴포지션 방식, 엣지가 다른 이유

오케스트레이션의 핵심 구성 요소

Module Federation 3.0과 Native ESM Federation

Manifest Endpoint 기반 버전 관리

실전 적용

예시 1: Router Worker로 경로 기반 라우팅 구성하기

예시 2: ESI로 레거시 시스템과 MFE 혼합하기

예시 3: Manifest Resolver로 카나리 배포 제어하기

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

EAA 발효 후 프론트엔드 접근성 점검 체크리스트 15가지 (유럽 접근성법 WCAG 2.1 AA 기준)

CSS Anchor Positioning으로 Popper.js 제거하기 — 브라우저가 직접 처리하는 플로팅 UI

Vite 8 + Rolldown: 이중 번들러 통합으로 프로덕션 빌드 시간을 87% 단축한 원리

TanStack DB 실전 도입: 클라이언트 사이드 DB가 낙관적 업데이트를 어떻게 바꾸는가

Tailwind v4 @container — 사이드바에서도 그리드에서도 깨지지 않는 반응형 컴포넌트

린팅이 62배 빨라지면 개발 습관이 달라진다 — ESLint에서 Oxlint로, Vite 프로젝트 마이그레이션 경험