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

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

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

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

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

2. Monolith => Modular Monolith => Micro Frontend

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

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

3. 어떻게 쪼갤까?

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

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

중요한 것은 기술이 아닌 조직이에요. 코드의 경계는 결국 팀의 경계를 따라가요.(콘웨이의 법칙) 팀이 실제로 분리되어 있지 않고 코드만 분리하는 것은 비용만 높아져요.

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

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

5. MFA 앱을 합치는 시점에 따른 분류

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

6. MFA 구현 기술

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

기술	설명	격리 수준	설명
Module Federation	Webpack 5 / Rspack의 런타임 모듈 공유	중간	같은 프레임워크로 통합하는 경우 사용
Single SPA	서로 다른 프레임워크의 여러 앱을 한 페이지에 마운트/언마운트	중간	여러 프레임워크로 통합하는 경우 사용
iframe	브라우저가 보장하는 완전한 격리 (구현은 단순, 단 통신이 많아지면 글쎄)	높음	보안/격리가 최우선이고. UX가 덜 중요한 경우
Web Components	브라우저 표준(Custom Elements + Shadow DOM) 기반 캡슐화	높음	프레임워크에 중립적인 컴포넌트 사용시 사용

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

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

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

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

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

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

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

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

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

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

10. AI와 MFA

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

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

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

결론

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