mfe how

---

# Micro-Frontend Architecture 패턴 A/B/C 비교


---

# 1. MFE 세 가지 패턴 요약

## 패턴 A

### **Shell만 모노레포, MFE는 모두 독립 레포**

* Shell: monorepo 내 Next.js 프로젝트
* MFE: 각각 별도의 Git repo
* Shell은 URL 기반으로 원격 MFE를 동적 로딩
* 실제 산업에서 **가장 많이 사용되는 방식**

**특징**

* Shell은 통합 관리
* MFE는 완전 독립 배포
* 플랫폼(공통 기능)과 기능 팀(feature)이 자연스럽게 분리됨

---

## 패턴 B

### **모든 앱이 monorepo (Shell + MFE), 배포만 독립**

* Git repo: 하나
* 각각의 앱(MFE)은 별도 CI/CD로 독립 배포
* 변경된 앱만 빌드/배포 (Turborepo, Nx 등 활용)

**특징**

* 공유 코드 관리 쉬움
* monorepo 규칙 통일 용이
* 팀 간 협업이 쉬움
* 중소 규모 조직에 적합

---

## 패턴 C

### **Repo도 완전 분리, 배포도 완전 분리 (Full Decoupling)**

* Shell: repo A
* MFE: repo B, repo C, repo D…
* Shared lib도 별도 repo (npm private registry 관리)

**특징**

* 팀 독립성 최대
* 스택 완전 독립 (React/Vue/Svelte 혼용도 가능)
* 운영·CI/CD 파이프라인 비용 최댓값
* 대규모 조직에 적합

---

# 2. 패턴 A / B / C 비교표

| 항목           | 패턴 A                | 패턴 B         | 패턴 C                 |
| ------------ | ------------------- | ------------ | -------------------- |
| Git repo 수   | Shell 1개 + MFE 여러 개 | 1개           | 모든 앱/공통 repo 각각 분리   |
| Shell 관리     | 모노레포                | 모노레포         | 독립                   |
| MFE 관리       | repo별 완전 분리         | monorepo의 폴더 | repo별 완전 분리          |
| 운영 독립성       | 높음                  | 중간           | 매우 높음                |
| Shared 코드 공유 | 어렵다 (npm 필요)        | 매우 쉬움        | 매우 어렵다 (npm+버전관리 필요) |
| CI/CD 복잡도    | 중간                  | 낮음           | 매우 높음                |
| 기술 스택 자유도    | 중간                  | 낮음           | 최고                   |
| 레이아웃/인증 통합   | 쉬움                  | 쉬움           | 어려움                  |
| 적합 규모        | 중~대형                | 소~중형         | 초대형 조직               |

---

# 3. Cesium 기반 서비스 특성 정리

Cesium 기반 시스템은 다음 특징을 가진다:

## 1) 전역 Viewer를 한 번만 생성해야 함

* Cesium viewer를 여러 MFE에서 각각 만들면
  GPU 메모리 소비 급증
  초기 로딩 지연
  Viewer 객체 충돌 발생
* 즉, **전역 viewer는 Shell에서만 생성**해야 한다.

## 2) 사용자 권한별 서로 다른 기능·툴·레이아웃 제공

* 따로 관리하면 권한 정책이 어긋남
* Shell에서 공통 인증/권한 체크 필요

## 3) 각 Feature는 독립적이지만, Layout은 공통이어야 함

* 3D 뷰 + Panel 구성은 일관되어야 사용자 혼란 없음
* MFE는 기능만 담당해야 함

## 4) 성능 요구가 높음

* 3D 애플리케이션은 페이지 리로드 없이 Mount/Unmount 방식이 필수
* Shell 중심 구조가 안정적

---

# 4. Cesium 서비스에서는 패턴 A가 가장 적합한 이유

Cesium 기반의 사용자 맞춤형 다기능 플랫폼에서는
**Shell(플랫폼)과 Feature(MFE)의 역할 분리가 매우 중요하다.**
아래는 패턴 A가 가장 적합한 이유이다.

---

## 이유 1. 전역 Cesium Viewer를 Shell에서 통합 관리 가능

패턴 A는 Shell이 단일 repo로 유지되므로

* viewer 초기화
* viewer 인스턴스 공유
* 전역 event bus
* resize/layout Control
  같은 Cesium 핵심 로직을 통합적으로 관리할 수 있다.

패턴 C처럼 viewer 책임이 분산되면 성능·구조가 깨진다.

---

## 이유 2. Shell이 Layout/UI/Toolbar 등을 통일할 수 있음

* Shell이 헤더/툴바/패널 위치 관리
* MFE는 기능 UI만 mount
* 사용자 권한에 따라 Shell이 어떤 MFE를 보여줄지 결정

Cesium 기반 서비스에서 UI 구조 통일은 필수적이다.

---

## 이유 3. 인증/권한 관리를 Shell에서 안전하게 통합

* 공통 SSO
* Access Token/Refresh Token 관리
* 사용자 역할 기반 MFE 접근 제어

패턴 C처럼 인증이 각 repo로 분산되면
보안 정책이 일관되지 않게 된다.

---

## 이유 4. MFE는 완전 독립 배포가 가능 → 기능 확장에 강함

Cesium 기반 플랫폼은 보통 기능이 많다:

* 레이어 관리
* 편집 도구
* 분석 기능
* 3D 모델 열람
* 시간축/시뮬레이션
* 사용자 설정 패널

모두 독립 MFE로 배포하면:

* 기능 업데이트가 빠르고
* 다른 기능에 영향을 주지 않고
* 오류에도 안심하고 release 가능하다

패턴 A는 이 독립성이 유지된다.

---

## 이유 5. 운영 복잡도는 C보다 훨씬 낮음

패턴 C는

* Shell도 repo 분리
* Shared UI도 repo 분리
* Auth Client도 repo 분리
* MFE도 repo 분리
  → 총 8~15개의 repo 운영되는 경우도 있음

Cesium처럼 기능이 많은 서비스에서는
운영 오버헤드가 너무 커진다.

패턴 A는 Shell만 monorepo로 묶여 있으니

* 플랫폼 팀 관리가 쉬워지고
* MFE 팀은 자유롭게 개발

정확히 균형 잡힌 구조다.

---

## 이유 6. 실제 GIS/Digital-Twin 기업 구조와 가장 유사

Cesium 기반 기업들은 대부분 다음 구조로 일함:

* **Shell / Viewer 플랫폼 팀**
* **툴/기능(Toolbox) 팀**
* **도메인 기능 팀**
* **분석/워크플로우 팀**

이때 플랫폼 팀은 Shell을 관리하고
기능 팀들은 독립 MFE 형태로 개발한다.

즉, 산업 표준적으로도 **패턴 A가 정답에 가장 가깝다.**

---

# 5. 결론

> **Cesium 기반의 사용자별 맞춤형 다기능 플랫폼**에서는
> **전역 Viewer + 통합 Layout + 공통 인증을 Shell이 담당하고,
> 기능은 독립 MFE로 제공하는 패턴 A가 가장 적합하다.**

패턴 B는 가능하지만 운영 비용 증가
패턴 C는 Viewer/레이아웃/권한 관리 단위가 분산되어
현실적으로 비효율적이다.