마이크로 프론트엔드 아키텍처(MFA)

앱 개발하는데 패키지를 분리하여 Monorepo를 사용하면서 마이크로 프론트엔드 아키텍처에 대해 알게됐어요. 백엔드에 MSA(마이크로 서비스 아키텍처)가 있다면 프론트엔드에는 MFA(마이크로 프론트엔드 아키텍처)가 있어요. MSA와 마찬가지로 MFA도 조직이 커지며 코드 관리의 어려움, 라이브러리 관리의 어려움, 조직별 관리 어려움 등에 따라 따로 코드를 나누는 거에요.

1. 마이크로 프론트엔드란?

백엔드에 MSA(마이크로 서비스 아키텍처)가 있다면 프론트엔드에는 MFA(마이크로 프론트엔드 아키텍처)가 있어요.
MFA는 간단히 말하면 "하나의 거대한 프론트엔드 앱을, 독립적으로 개발 및 배포할 수 있는 여러 개의 작은 앱으로 쪼갠는 것"이에요.

각 작은 앱은 별도의 팀이 소유하고, 팀만의 코드베이스와 배포 파이프라인을 가질 수 있어요. 이론상 팀끼리 서로 기다리지 않고 각자의 속도로 배포할 수 있어요. 물론 이 것이 매력적이지만 그만큼의 어려움도 동반되요.

2. Monolith => Modular Monolith => Micro Frontend

모놀리스, 모듈러 모놀리스, 마이크로 프론트엔드는 각각 하나의 앱에서 여러 앱으로 독립적으로 분리하여 개발하는 순서대로 아키텍처를 나열한거에요.

모놀리스(Monolith)
- 단일 코드베이스 & 배포
모듈러 모놀리스(Modular Monolith)
- 명확한 경계로 모듈이 나뉘어진 단일 코드 베이스 & 단일 배포
마이크로 프론트엔드(Micro Frontend)
- 여러 코드베이스 & 여러 배포 파이프라인

3. 어떻게 쪼갤까?

MFA에서 나누는 기준은 다양한데 보통 세 가지에요.

페이지 단위 - 결제 페이지, 검색 페이지처럼 라우트 별로 통째 분리
도메인 단위(보통 팀 단위) - 장바구니, 상품, 프로필 같이 비즈니스 도메인 별로 분리 (가장 권장)
컴포넌트 단위 - 한 페이지에 여러 팀의 위젯 사용

쪼갤때 중요한 것은 기술보다는 조직이에요. 코드의 경계는 결국 팀의 경계를 따라가요.(콘웨이의 법칙) 팀이 실제로 분리되어 있지 않고 코드만 분리하는 것은 비용만 높아져요.
그래서 MFA를 적용하면 각 앱은 하나의 팀이 소유하기에 충분한 크기로 나눠어져요.

4. Shell App(컨테이너 앱, 공유 앱, 호스트 앱)

독립된 앱들을 하나의 화면으로 보여주려면 이 앱들을 조립하는 컨테이너가 필요해요. 이걸 Shell 또는 Host 또는 Container 앱이라고 불러요.
Shell App은 비즈니스 로직을 갖지 않고 라우팅, 공통 레이아웃, 공유 의존성 관리, 각 앱의 로딩과 마운트를 담당해요.

5. MFA 앱이 합쳐지는 방법

언제 앱들을 합치느냐에 따라 다른 특성(장단점)을 가진 MFA가 되요. 보통 크게 [빌드 타임, 서버사이드, 클라이언트 사이드] 3가지의 시점에 프론트엔드 앱들을 합쳐요.
여기서 사실 빌드 타임에 앱을 통합하는 것은 사실 Modular Monolith에 가까워요. 이와 같이 Modular Monolith에 가깝다는 것은 굳이 MFA의 비싼 비용을 치를 이유가 없다는 의미기도 해요.

Build-Time에 합치기
- 장점
  - 설정이 쉬움
  - 다양한 프레임워크와 작동이 쉬움
  - 런타임 로딩 복잡도가 없음
- 단점
  - 모든 팀이 한번의 릴리즈(배포)에 영향이 있음 => 하나의 팀이 새 버전 배포시, 앱 전체 다시 빌드 및 배포 필요
Server-Side에서 합치기
- 장점
  - SSR을 통한 빠른 FCP 시간
  - 팀별 독립 배포 관리
- 단점
  - 높은 인프라 비용과 복잡도
  - 앱간 상태관리나 통신이 필요한 경우 높은 소통비용
Client-Side에서 합치기
- 여러가지 옵션이 있고 이 옵션에 따라 장단점이 달라짐

6. Client-Side MFA 구현 기술

Client Side에서 앱을 통합하는 기술을 크게 4가지에요.

기술	설명	격리 수준	사용 가이드
Module Federation	Webpack 5 / Rspack의 런타임 모듈 공유 장점 자동 의존성 중복 관리 MFE 간의 직접적인 임포트(코드) 단점 설정 복잡도 설정에 의한 버그 추적 및 해결 어려움	중간	같은 프레임워크인 경우 유용 여러팀이 하나의 SPA로 작업중일 때 유용
Single SPA	서로 다른 프레임워크의 여러 앱을 한 페이지에 마운트/언마운트 보통 Applications/Parcels/Utilities 3가지로 나뉘어 사용 장점 번들러 의존성이 없음 더 나은 의존성 격리 단점 의존성 최적화 수동으로 설정 필요 Next.js같은 SSR 어려울 수 있음	중간	여러 프레임워크로 통합하는 경우 유용 점진적으로 프레임워크 바꾸는 경우 유리
iframe	브라우저가 보장하는 완전한 격리 (구현은 단순, 단 통신이 많아지면 글쎄) 장점 완전한 격리 (CSS, JS) 낮은 복잡도 단점 라이브러리 공유가 아에 없음(중복 다운) postMessage를 통한 앱간 소통 SEO, 접근성 문제	높음	보안/격리가 최우선이고. UX가 덜 중요한 경우 3rd party 앱(결제 등) 레거시 앱 확실한 경계가 필요한 경우 사용
Web Components	브라우저 표준(Custom Elements + Shadow DOM) 기반 캡슐화 장점 별도 번들러 없이 작동 가능 browser 빌트인 기능으로 라이브러리 필요 없음 단점 MFE 간의 상호작용엔 별도 코드 필요 Data 전달의 어려움(attributes 속성을 통한 단순 값만 전달)	높음	프레임워크에 중립적인 컴포넌트 사용시 사용 3rd party 앱(결제 등) 레거시 앱

7. 마이크로 프론트엔드의 한계(단점)

마이크로 프론트엔드는 이론상 완벽해보이지만, 실제 도입하면 많은 어려움이 있다고 해요. 그 비용은 아래와 같이 대표적인 예시들이 있어요.

운영 복잡도 폭증 — 빌드, 배포, 모니터링, 라우팅을 N개의 앱에 대해 각각 관리.
번들 중복 — 각 조각이 React 같은 의존성을 따로 들고 와 사용자에게 더 무거운 페이지를 전송.
버전·의존성 지옥 — 공유 라이브러리 버전이 조각마다 어긋나며 런타임에서 깨짐.
일관된 UX의 어려움 — 디자인 시스템이 있어도 조각 사이의 미묘한 불일치가 새어 나옴.
디버깅·관측의 어려움 — 문제가 어느 조각에서 비롯됐는지 추적하기가 훨씬 까다로움.

그리고 대부분의 팀이 위 비용을 감당할 만큼 크지 않다고 해요. 굳이 MFA가 필요하지 않은 규모의 조직에서 분산 시스템의 고통과 비용을 가져갈 뿐이에요.

8. 마이크로 프론트엔드가 필요한 경우는?

아주 큰 조직과 독립적인 여러 팀들이 존재하는 경우에 필요할 수 있어요. 팀마다 서로 다른 릴리즈 주기, 라이브러리를 가질 수도 있고 조직이 더 유연해져요. 그래서 "조직 문제"를 풀기 위한 아키텍처 이기도 해요.

하지만, 중간 이하의 팀이거나, 하나의 응집된 제품이나 성능에 민감한 서비스에 사용하면 오히려 문제를 새로 만들거에요.

9. 대부분 조직에서의 대안 : 모듈러 모놀리스 (모노레포)

사람들이 MFA에서 원했던 것은 명확한 경계, 모듈성, 팀의 자율성이에요. 사실 이것은 모듈러 모놀리스에서도 분산 시스템 비용 없이 얻을 수 있어요.

그래서 MFA는 필요해질 때까지 미루는 것이 좋은 전략이에요. 경계만 잘 그어두면 MFA로 분리는 훨씬 쉬워져요.

10. AI와 MFA

MFA의 가장 큰 명분은 "큰 코드베이스를 사람이 다루기 힘들기 때문에 물리적으로 쪼개 팀별로 관리"하도록 하는 거에요. 하지만 AI가 발전하면서 새로운 명분이 계속 생기고 있어요.

AI는 큰 코드베이스를 더 잘 다뤄.요 모듈 경계를 탐색하고, 여러 파일에 걸친 변경을 따라가며, 컨벤션을 유지하는 일에서 사람의 인지 한계가 덜 병목이 됩니다.
분산은 AI에게도 비용이.에요 여러 레포·여러 배포·버전 불일치로 흩어진 시스템은 AI 에이전트가 전체 맥락을 파악하기 더 어렵게 만듭니다.
경계 유지가 더 싸졌어.요 모듈러 모놀리스의 약점이었던 "경계가 시간이 지나며 무너지는 문제"를, AI 보조 리뷰·리팩터링이 잡아주기 쉬워졌습니다.

그래서 사실 MFA보다 모듈러 모놀리스 방식이 좀 더 선호될 수 있다고 생각해요. (경계 유지비가 싸져서)

결론

MFA는 독립적인 팀으로 나뉜 거대한 조직에서 올바른 도구에요. 그래서 트레이드오프를 냉정하게 본다면 대부분의 팀에게는 모듈러 모놀리스로 시작하는 것이 현명해요. 왜냐하면 모듈러 모놀리스는 경계가 분명하고 배포는 하나로 되고있기도 하고, AI가 큰 코드베이스의 인지 비용을 많이 낮추면서 "MFA가 정말 필요한 경우" 문턱이 더 높아졌기 때문이에요.