테마
마이크로 프론트엔드 통합 기술의 발전 과정
서버사이드 구성(SSI, ESI)에서 클라이언트사이드 런타임(Ajax, iframe, Web Components)을 거쳐 모듈 페더레이션까지, 마이크로 프론트엔드 통합 기술이 어떤 시대적 맥락 속에서 진화해 왔는지를 조망한다.
학습 목표
- 마이크로 프론트엔드 통합 기술의 세 세대를 구분하고 각각의 등장 배경을 설명할 수 있다
- 서버사이드 구성, 클라이언트사이드 런타임, 모듈 페더레이션 각 방식의 핵심 특징을 비교할 수 있다
- 프로젝트 상황에 따라 적절한 통합 기술을 선택하기 위한 판단 기준을 이해한다
1. 통합 기술의 전체 흐름
마이크로 프론트엔드 통합 기술은 웹 생태계의 발전과 함께 진화해 왔다. 크게 세 세대로 나눌 수 있으며, 각 세대는 이전 세대의 한계를 보완하는 방향으로 등장했다.
각 세대는 완전히 대체되는 관계가 아니다. SSI는 지금도 유효한 기술이며, iframe은 특수한 격리가 필요한 경우에 여전히 사용된다. 중요한 것은 각 기술의 특성과 한계를 이해하고, 프로젝트 상황에 맞게 조합하여 사용하는 것이다.
2. 1세대: 서버사이드 구성 (SSI, ESI)
2.1 등장 배경
1990년대 후반~2000년대 초반, 웹은 서버가 HTML을 생성하여 내려주는 구조가 지배적이었다. 정적 HTML 파일만으로는 공통 헤더/푸터 같은 반복 요소를 관리하기 어려웠고, 이를 해결하기 위해 서버에서 HTML 조각을 조합하는 기술이 등장했다.
2.2 주요 기술
| 기술 | 동작 위치 | 설명 |
|---|---|---|
| SSI | 웹 서버(Nginx, Apache) | <!--#include virtual="..." --> 지시문으로 HTML 파일을 서버에서 합침 |
| ESI | CDN/캐시 서버(Varnish, Akamai) | <esi:include src="..." /> 태그로 엣지에서 조합. CDN 레벨 캐싱과 결합 가능 |
| 서버 템플릿 엔진 | 애플리케이션 서버 | PHP include, JSP include, Thymeleaf fragments 등으로 서버에서 조합 |
2.3 특징
- 장점: SEO에 유리, 클라이언트에 완성된 HTML 전달, 내부 네트워크 레이턴시가 낮음
- 한계: 동적 사용자 인터랙션 처리 어려움, 유저별 맞춤 콘텐츠에 비효율적, SPA 경험 제공 불가
3. 2세대: 클라이언트사이드 런타임 통합
3.1 등장 배경
2005년 Gmail과 Google Maps가 Ajax를 본격적으로 활용하면서, 웹은 "새로고침 없는 동적 페이지" 시대로 진입했다. SPA(Single Page Application) 패러다임이 부상하면서, 클라이언트 측에서 여러 팀의 UI 조각을 조합하려는 시도가 시작되었다.
3.2 주요 기술
3.3 Ajax 프래그먼트 로딩
fetch()로 다른 팀 서버의 HTML 조각을 요청하여 현재 페이지 DOM에 삽입- 구현이 간단하고 성능 오버헤드가 적음
- 스타일/스크립트 격리가 되지 않아 네임스페이스 규칙이나 IIFE 패턴 필요
- 비동기 로딩으로 인한 레이아웃 깜빡임(FOUC) 발생 가능
3.4 iframe 내장
- 완벽한 격리(browsing context가 분리)를 제공하지만 별도 document를 로드하므로 무거움
postMessageAPI로만 부모-자식 통신 가능, 반응형 높이 조절이 까다로움- 금융/결제처럼 보안 격리가 필수인 영역에서 여전히 유효
3.5 Web Components
- Custom Elements, Shadow DOM, HTML Template 등 웹 표준 기술
- 프레임워크에 구애받지 않는 컴포넌트 정의 가능
- Shadow DOM으로 스타일 격리 가능하지만, SSR 지원이 제한적
4. 3세대: 모듈 페더레이션과 빌드타임/런타임 하이브리드
4.1 등장 배경
SPA가 대세가 되면서 프론트엔드 애플리케이션 규모가 급격히 커졌다. 단일 SPA를 여러 팀이 공동으로 개발하면 빌드 시간 증가, 배포 병목, 라이브러리 버전 충돌 같은 문제가 심화되었다. 이를 해결하기 위해 빌드타임에 경계를 나누되 런타임에 동적으로 연결하는 기술이 등장했다.
4.2 핵심 기술: Webpack Module Federation
- Webpack 5에서 도입된 플러그인으로, 별도로 빌드된 애플리케이션이 런타임에 서로의 모듈을 공유
host(소비자)와remote(제공자) 관계를 선언적으로 설정- 공유 라이브러리(React, lodash 등)의 중복 로딩을 자동으로 방지(singleton 설정)
- 각 팀이 독립적으로 빌드/배포할 수 있으면서도, SPA 수준의 매끄러운 사용자 경험 제공
5. 세대별 비교와 기술 선택 기준
5.1 세대별 비교표
| 비교 항목 | 1세대 (서버사이드) | 2세대 (클라이언트) | 3세대 (모듈 페더레이션) |
|---|---|---|---|
| 조합 시점 | 서버 응답 전 | 브라우저 런타임 | 빌드타임 설정 + 런타임 로딩 |
| SEO | 유리 | 불리(추가 처리 필요) | SSR 조합 시 유리 |
| 초기 로딩 | 빠름(완성 HTML) | 깜빡임 가능 | 최적화 가능 |
| 사용자 인터랙션 | 제한적 | 자유로움 | 자유로움 |
| 팀 독립성 | 서버 배포 의존 | 높음 | 매우 높음 |
| 스타일 격리 | 불필요(서버 조합) | 직접 구현 필요 | 프레임워크 수준 |
| 공유 리소스 관리 | 어려움 | 중복 로딩 | 자동 dedup |
5.2 기술 선택 시 고려 요소
완전한 솔루션은 없다. 실제 프로덕션에서는 여러 기술을 함께 사용하거나 특정 상황에서만 사용하는 경우가 많다. 예를 들어:
- 헤더/푸터는 SSI로 서버에서 조합하고, 인터랙티브 영역은 Module Federation으로 통합
- 결제 모듈은 iframe으로 격리하고, 나머지는 Web Components로 통합
- 팀 간 전환이 드문 서비스는 Nginx 프록시 기반 Linked SPA로 충분
6. 파트 3에서 다루는 기술의 위치
이후 학습에서는 다음 기술을 순서대로 다룬다. 이 기술들이 현재도 유효하며, Module Federation을 이해하기 위한 기초가 된다.
| 순서 | 기술 | 위치 | 핵심 키워드 |
|---|---|---|---|
| 1 | Ajax 템플릿 통합 | 이번 장 02 | 비동기 프래그먼트, innerHTML |
| 2 | Nginx 프록시 통합 | 이번 장 03 | 리버스 프록시, Linked SPA |
| 3 | SSI 서버사이드 인클루드 | 이번 장 04 | #include 지시문, 서버 조합 |
| 4 | Web Components 통합 | 다음 장 01 | Custom Elements, Shadow DOM |
이 예제들은 프로덕션 레벨의 코드가 아니라, 원리를 이해하기 위한 학습용 예제이다. 각 기술의 흐름과 동작 방식을 파악하는 데 집중하자.
핵심 정리
- 1세대 서버사이드 구성(SSI/ESI)은 서버에서 HTML을 조합하여 완성된 페이지를 내려주며, SEO와 초기 로딩에 유리하지만 동적 인터랙션에 한계가 있다.
- 2세대 클라이언트사이드 런타임(Ajax/iframe/Web Components)은 브라우저에서 UI를 조합하여 풍부한 인터랙션을 제공하지만, 깜빡임, 격리, SEO 문제를 직접 해결해야 한다.
- 3세대 모듈 페더레이션은 빌드타임 설정과 런타임 로딩을 결합하여 독립 배포와 리소스 최적화를 동시에 달성한다.
- 완전한 솔루션은 없으며, 실제 프로덕션에서는 여러 기술을 조합하여 사용하는 경우가 많다.
- 기술 선택 시 SEO 중요도, 사용자 인터랙션 수준, 팀 독립성 요구, 기술 스택 다양성 등을 종합적으로 고려해야 한다.
다음 단계
- Ajax 기반 템플릿 통합: fetch로 HTML 프래그먼트를 비동기 로딩하여 통합하는 방법과 그 한계를 학습한다.