기술 학습 노트

테마

마이크로프론트엔드 통합 방식 종합 비교 ​

SSI, 빌드타임, iframe, Web Components, JS(AJAX), Module Federation 등 6가지 통합 방식을 통합 시점, 격리 수준, SPA 지원, 독립 배포, SEO, 성능, 복잡도 기준으로 종합 비교하고, 상황별 추천 방식과 Module Federation이 현대적 표준으로 자리 잡은 이유를 정리한다.

학습 목표 ​

  • 마이크로프론트엔드의 6가지 주요 통합 방식을 한눈에 비교할 수 있다
  • 각 통합 방식의 통합 시점(빌드타임 vs 런타임 vs 서버)을 구분할 수 있다
  • 7가지 비교 항목(통합 시점, 격리, SPA, 독립 배포, SEO, 성능, 복잡도)으로 각 방식을 평가할 수 있다
  • 프로젝트 요구사항에 맞는 통합 방식을 선택하는 기준을 확립한다
  • Module Federation이 현대 마이크로프론트엔드에서 가장 실용적인 이유를 설명할 수 있다

1. 통합 방식 전체 맵 ​

마이크로프론트엔드의 통합 방식은 통합이 일어나는 시점과 위치에 따라 크게 세 범주로 나뉜다.

2. 6가지 통합 방식 종합 비교표 ​

비교 항목SSI/ESI빌드타임 (npm)iframeWeb ComponentsJS 통합 (AJAX)Module Federation
통합 시점서버 렌더 시빌드 시런타임 (로드 시)런타임 (로드 시)런타임 (로드 시)런타임 (로드 시)
격리 수준없음없음완전 격리Shadow DOM 격리없음없음 (규약 기반)
SPA 지원어려움가능부분적가능가능가능
독립 배포가능불가능가능가능가능가능
SEO우수우수불리불리보통보통
성능우수우수낮음보통보통우수
구현 복잡도낮음낮음낮음중간중간중간~높음
프레임워크 공유해당 없음가능불가능불가능불가능가능
런타임 모듈 공유불가능불가능불가능불가능불가능가능

2.1 각 항목 해설 ​

통합 시점:

  • 서버 렌더 시(SSI): 사용자 요청이 서버에 도달하면, 서버가 여러 서비스의 HTML 조각을 모아 완성된 HTML을 응답한다.
  • 빌드 시(npm): 각 마이크로앱을 npm 패키지로 게시하고, Shell 앱이 빌드할 때 의존성으로 포함하여 하나의 번들로 합친다.
  • 런타임(클라이언트): 브라우저가 페이지를 로드한 후, JavaScript로 마이크로앱의 코드를 동적으로 가져와 조합한다.

격리 수준:

  • 완전 격리(iframe): 별도 document, window, CSS, JS 컨텍스트. 가장 강력하지만 통신 비용이 크다.
  • Shadow DOM 격리(Web Components): CSS와 DOM 쿼리는 격리되지만 JS 전역 상태는 공유된다.
  • 없음(SSI, npm, JS, Module Federation): 같은 document 내에서 동작하므로 CSS 충돌 가능성이 있다. 별도의 네이밍 규약이나 CSS-in-JS 등으로 대응해야 한다.

독립 배포:

  • 빌드타임 통합(npm)만 유일하게 독립 배포가 불가능하다. 마이크로앱을 수정하면 Shell 앱을 다시 빌드해야 하므로, 마이크로프론트엔드의 핵심 가치인 팀별 독립 배포가 훼손된다.

3. 방식별 상세 비교 ​

3.1 SSI/ESI (서버 사이드 통합) ​

서버에서 HTML 조각을 삽입하는 방식으로, 초기 페이지 로드 성능과 SEO에 유리하다. 그러나 SPA 방식의 클라이언트 인터랙션을 구현하기 어렵고, 서버 인프라(Nginx, Varnish 등)에 대한 의존이 생긴다.

  • 적합: 콘텐츠 중심 웹사이트, SEO가 핵심인 서비스
  • 부적합: 복잡한 클라이언트 인터랙션, SPA

3.2 빌드타임 통합 (npm 패키지) ​

각 마이크로앱을 npm 패키지로 배포하고 Shell 앱에서 import하는 방식이다. 가장 단순하지만 독립 배포가 불가능하여 마이크로프론트엔드의 핵심 가치를 달성할 수 없다.

  • 적합: 공통 라이브러리, 디자인 시스템 공유
  • 부적합: 팀별 독립 배포가 필요한 마이크로프론트엔드

3.3 iframe ​

가장 오래되고 가장 강력한 격리를 제공하지만, 성능, SEO, 접근성, 반응형 모든 면에서 불리하다.

  • 적합: 관리자 도구, 서드파티 위젯 삽입, 레거시 과도기
  • 부적합: 고객 대면 서비스, 모바일 서비스

3.4 Web Components ​

웹 표준 기반으로 Shadow DOM 격리를 제공하지만, SSR 지원과 프레임워크 연동에 한계가 있다.

  • 적합: 프레임워크 무관한 위젯 제공, 디자인 시스템
  • 부적합: SSR 필수 서비스, React 생태계 중심 프로젝트

3.5 JS 통합 (AJAX) ​

JavaScript로 마이크로앱의 번들을 동적으로 로드하고 DOM에 마운트하는 방식이다. 유연하지만 로딩 순서 관리와 공유 의존성 처리가 복잡하다.

  • 적합: 단순한 프래그먼트 통합, 소규모 마이크로프론트엔드
  • 부적합: 대규모 마이크로프론트엔드, 공유 의존성이 많은 경우

3.6 Module Federation ​

Webpack 5에서 도입된 런타임 모듈 공유 메커니즘이다. 각 마이크로앱이 독립적으로 빌드/배포되면서도 런타임에 모듈(React, 공유 라이브러리 등)을 공유할 수 있다.

  • 적합: 대부분의 현대적 마이크로프론트엔드 프로젝트
  • 부적합: Webpack 외 번들러만 사용하는 프로젝트 (다만 Vite, Rspack 등도 지원 확대 중)

4. 상황별 추천 방식 ​

4.1 결정 기준 요약 ​

상황추천 방식이유
SEO 최우선 + SPA 불필요SSI/ESI서버에서 완성된 HTML을 제공하므로 검색엔진 최적화에 가장 유리
SEO + SPA 모두 필요Module Federation + SSR런타임 통합의 유연함과 SSR 프레임워크(Next.js 등)의 SEO를 결합
독립 배포 불필요빌드타임 (npm)구현이 가장 단순. 공통 라이브러리, 디자인 시스템에 적합
완전 격리 + 내부 시스템iframe구현이 간단하고 격리가 완벽. 성능/SEO가 덜 중요한 내부 도구에 적합
프레임워크 무관 + 격리Web Components웹 표준으로 Shadow DOM 격리 제공. 위젯, 디자인 시스템에 적합
대부분의 현대적 프로젝트Module Federation독립 배포 + 런타임 모듈 공유 + SPA 지원. 가장 균형 잡힌 선택

5. Module Federation이 가장 현대적이고 실용적인 이유 ​

6가지 통합 방식 중 Module Federation이 현대 마이크로프론트엔드의 사실상 표준으로 자리 잡은 이유는, 다른 방식들이 하나씩 가지고 있는 한계를 종합적으로 해결하기 때문이다.

5.1 다른 방식들의 한계와 Module Federation의 해결 ​

다른 방식의 한계Module Federation의 해결
빌드타임 통합: 독립 배포 불가각 마이크로앱이 독립적으로 빌드/배포되며, 런타임에 원격 모듈을 가져옴
SSI: SPA 인터랙션 어려움클라이언트에서 동적으로 모듈을 로드하고 SPA 내비게이션 지원
iframe: 성능 오버헤드, 통신 복잡같은 document 내에서 동작하므로 추가 컨텍스트 비용 없음
Web Components: 프레임워크 연동 복잡React, Vue 등을 직접 공유하므로 프레임워크 래핑이 불필요
JS 통합: 공유 의존성 중복 로드shared 설정으로 React, lodash 등 공통 모듈의 중복을 자동 제거

5.2 Module Federation의 핵심 이점 ​

런타임 모듈 공유의 동작 원리:

Module Federation은 빌드 시 각 마이크로앱을 독립된 번들로 빌드하되, 공유 모듈(React, React-DOM 등)은 shared 설정에 따라 런타임에 버전 협상을 거쳐 단일 인스턴스만 로드한다. 이로 인해 각 마이크로앱이 React를 별도로 번들하지 않아도 되고, 중복 로드에 의한 번들 크기 증가를 방지한다.

javascript
// Webpack 5 Module Federation 설정 예시
// Shell 앱 (호스트)
new ModuleFederationPlugin({
  name: 'shell',
  remotes: {
    teamA: 'teamA@http://localhost:3001/remoteEntry.js',
    teamB: 'teamB@http://localhost:3002/remoteEntry.js',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.0.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
  },
});

// 마이크로앱 (리모트)
new ModuleFederationPlugin({
  name: 'teamA',
  filename: 'remoteEntry.js',
  exposes: {
    './App': './src/App',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.0.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
  },
});

5.3 Module Federation의 한계 ​

Module Federation이 만능은 아니다. 알아두어야 할 한계와 트레이드오프가 있다.

한계설명
번들러 의존기본적으로 Webpack 5에 의존한다. Vite, Rspack 등에서의 지원은 확대되고 있지만 완전히 동등하지는 않다
격리 없음같은 document에서 동작하므로 CSS 충돌 가능성이 있다. CSS Modules, CSS-in-JS 등의 별도 전략 필요
초기 설정 복잡도shared 설정, 버전 관리, 타입 공유 등 초기 구성에 학습 비용이 있다
런타임 의존성리모트 서버가 다운되면 해당 마이크로앱 로드가 실패한다. 폴백 처리가 필요하다
디버깅 난이도모듈이 여러 서버에서 로드되므로 소스맵 추적이 복잡할 수 있다

6. 통합 방식 진화의 흐름 ​

마이크로프론트엔드 통합 방식은 서버 사이드 -> 빌드타임 -> 클라이언트 사이드(iframe, Web Components, JS) -> Module Federation 순서로 진화해 왔다. 각 단계는 이전 단계의 한계를 극복하려는 시도에서 탄생했다.

세대방식해결한 문제남긴 한계
1세대SSI/ESI서버에서 다수 서비스의 HTML 조합SPA 인터랙션 불가
2세대빌드타임 (npm)프레임워크 활용, SPA 지원독립 배포 불가
3세대iframe완전한 격리, 독립 배포성능, SEO, UX 문제
3세대Web Components표준 기반 격리, 독립 배포SSR 어려움, 생태계 부족
3세대JS 통합 (AJAX)유연한 런타임 통합공유 의존성 중복
4세대Module Federation런타임 모듈 공유, 독립 배포, SPA번들러 의존, CSS 격리 없음

핵심 정리 ​

핵심 개념요약
6가지 통합 방식SSI, 빌드타임, iframe, Web Components, JS 통합, Module Federation
통합 시점 구분서버(SSI), 빌드(npm), 런타임(iframe, WC, JS, MF)
독립 배포빌드타임 통합만 유일하게 독립 배포 불가. 나머지는 모두 가능
격리 강도 순iframe(완전) > Web Components(Shadow DOM) > 나머지(없음)
SEO 유리 순SSI = 빌드타임 > JS = MF > WC > iframe
Module Federation 핵심런타임 모듈 공유로 공유 의존성 중복 제거 + 독립 배포 + SPA
현대적 추천대부분의 프로젝트에서 Module Federation이 가장 균형 잡힌 선택
상황별 예외SEO 최우선이면 SSI, 완전 격리 필수면 iframe, 프레임워크 무관이면 Web Components

다음 단계 ​

지금까지 마이크로프론트엔드의 모든 통합 방식을 비교하고, Module Federation이 현대적 표준으로 자리 잡은 이유를 확인했다. 다음 장에서는 Module Federation의 구체적인 동작 원리, 설정 방법, 호스트/리모트 개념을 상세히 학습한다.

다음: Webpack 5 모듈 페더레이션 기초 ->