MFE 호스트·앱의 역할과 공유 의존성
MFE로 구성된 애플리케이션에 기능을 추가하면서 호스트 셸과 공통 인증, 내비게이션, 각 앱의 연결 방식을 다시 살펴봤습니다. 화면 하나를 바꿀 때도 어느 앱에서 그 기능을 처리하는지부터 알아야 했습니다.
이 글은 그때 파악한 역할을 일반화해 정리한 내용입니다. 예시의 주문·결제 앱 이름과 배포 주소는 설명을 위해 만든 것입니다.
호스트 셸과 도메인 앱
호스트 셸은 사용자가 처음 접속하는 화면에서 공통 레이아웃과 라우팅, 로그인 상태를 관리하고 필요한 앱을 불러옵니다. 각 도메인 앱은 자신이 담당한 화면과 상태, API 호출을 처리합니다.
| 구분 | 함께 확인할 역할 |
|---|---|
| 호스트 셸 | 공통 내비게이션, 앱 진입 경로와 로딩, 인증 상태 전달 |
| 도메인 앱 | 기능별 화면·상태·API 연동과 오류 처리 |
| 공통 패키지 | UI 구성요소와 디자인 토큰, 공통 사용 규약 |
화면에서 메뉴를 숨기거나 셸에서 로그인 여부를 확인하는 것만으로 API 권한 검사가 끝나지는 않습니다. 각 서버가 해당 요청을 허용할 수 있는지도 검증해야 합니다.
Module Federation의 연결 방식
MFE는 기능과 배포 범위를 나누는 접근이고, Module Federation은 별도로 빌드한 모듈을 연결하는 구현 방법 중 하나입니다. iframe이나 서버에서 조합하는 방법도 있으므로 MFE 전체를 Module Federation과 같은 개념으로 볼 수는 없습니다.
Webpack 5에서는 host의 remotes와 remote의 exposes를 맞춥니다. 아래는 각 빌드의 plugins에 넣을 옵션을 보여주는 예시입니다. 전체 빌드·로컬 서버 구성은 생략했습니다.
const { ModuleFederationPlugin } = require("webpack").container;
const hostPlugin = new ModuleFederationPlugin({
name: "shell",
remotes: {
orders: "orders@https://cdn.example.com/orders/remoteEntry.js",
},
});
const remotePlugin = new ModuleFederationPlugin({
name: "orders",
filename: "remoteEntry.js",
exposes: {
"./OrdersPage": "./src/OrdersPage",
},
});이 설정에서 호스트는 import("orders/OrdersPage")로 remote 모듈을 비동기 로드할 수 있습니다. 실제 React 앱에는 앱 진입 시점의 비동기 로딩 처리와 공유 라이브러리 설정, 로딩 실패 처리가 더 필요합니다.
인증과 라우터의 공유 범위
도메인 앱이 같은 로그인 상태와 내비게이션 안에서 움직이려면 전달할 정보와 갱신 방법을 맞춰야 합니다. 토큰 갱신이나 세션 만료를 앱마다 따로 처리하면 서로 다른 상태를 보일 수 있습니다.
라우터도 어느 쪽이 최상위 컨텍스트를 만들고 앱 안의 경로를 어떻게 붙일지 합의해야 합니다. 이미 호스트의 라우터 안에서 렌더링하는 앱이 다시 BrowserRouter를 만드는 식으로 구성하면 충돌할 수 있습니다.
공통 라이브러리의 버전
React처럼 같은 런타임을 공유해야 하는 라이브러리는 shared 설정과 버전 정책을 함께 봅니다. singleton: true는 공유 인스턴스를 제한하는 옵션이지 모든 버전 조합이 호환된다는 보장은 아닙니다.
호스트와 앱의 허용 버전, 버전이 맞지 않을 때 경고하거나 실패시킬 정책을 정해야 합니다. 공통 UI를 패키지로 각 빌드에 포함하는 방식과 실행 시점에 공유하는 방식도 배포 영향이 다릅니다.
로딩 실패와 되돌릴 범위
remote 파일을 받지 못하거나 모듈 실행에서 오류가 나면 해당 화면이 열리지 않을 수 있습니다. React의 Suspense는 로딩 중 화면을 제공하지만 로딩 거부나 렌더링 오류를 처리할 Error Boundary까지 대신하지는 않습니다.
앱을 따로 배포해도 공유 인증과 런타임, CDN 주소와 캐시가 연결돼 있으면 장애도 독립적으로 나뉘지는 않습니다. 이전 remote 버전으로 되돌릴 수 있는지와 호스트가 그 버전과 호환되는지 함께 확인해야 합니다.
이 작업은 MFE를 처음 도입한 사례가 아니라, 기존 구성에 기능을 추가하며 호스트와 각 앱의 역할을 확인한 경험입니다. 앱별로 바꿀 화면과 상태는 나누되 인증·라우팅·공유 라이브러리는 함께 맞춰야 했습니다. 저장소와 배포가 나뉘어 있어도 공유 설정을 바꿀 때는 연결된 앱과 되돌릴 버전을 함께 확인해야 한다는 점이 남았습니다.