Micro Frontend vs SPA: Which Architecture Should You Choose?

Context

개발팀이 3명에서 8명으로 확대되면서 SPA 구조에서 매일 발생하는 병합 충돌, 한 팀의 배포 지연이 다른 팀 릴리스를 차단하는 상황, 5분으로 증가한 빌드 시간(기존 20초), 그리고 홈페이지에 불필요한 chart.js·leaflet·xlsx를 포함한 2.8MB 번들이 발생했다.

Technical Solution

• SPA 단일 webpack.config.js를 로컬/프로덕션 환경별로 다른 MFE webpack.config.js로 분리
• 한 파일에 모든 라우트를 정의하는 SPA 라우팅을 지연 로딩되는 원격 앱 기반 MFE 라우팅으로 변경
• 일괄 빌드·배포 방식에서 30초 단위 독립 빌드와 개별 배포 파이프라인으로 전환
• 2.8MB 전체 번들을 MFE당 150-300KB 단위 타겟 로딩으로 분할
• React Host에서는 ModuleFederationPlugin, Next.js Host에서는 NextFederationPlugin을 적용하되 설정이 동일하지 않음을 반영
• Turborepo 파이프라인으로 MFE 병렬 빌드 구성
• SPA에서 MFE로의 4단계 점진적 마이그레이션 패턴(strangler pattern) 제시

Impact

빌드 시간을 5분에서 30초로 단축, 번들 크기를 2.8MB에서 MFE당 150-300KB로 축소, 7개의 독립적으로 실행되는 MFE를 프로덕션 환경에서 운영 중.

Key Takeaway

Micro Frontend는 MFE가 항상 우월한 것이 아니며, 소규모 팀·단일 도메인·빠른 MVP 단계에서는 SPA가 올바른 선택이다. 기술 결정은 조직 규모와 배포 독립성 요구도에 따라 달라지며, 각 아키텍처의 트레이드오프를 정확히 이해해야 한다.