Micro Frontend vs SPA: Which Architecture Should You Choose?

Context

단일 페이지 애플리케이션(SPA)으로 시작한 프로젝트가 성장하면서 단일 코드베이스의 한계에 직면한다. 여러 팀이 동일 저장소에서 작업할 때 병합 충돌과 느린 코드 리뷰가 발생하고, 작은 기능 변경도 전체 애플리케이션을 재빌드·재배포해야 한다(예: 30분 이상의 빌드 시간). 또한 하나의 프레임워크에 종속되며, 단일 점장애로 인한 전체 애플리케이션 중단 위험이 존재한다.

Technical Solution

• SPA 아키텍처: Create React App, Vite, Next.js 같은 단일 번들러로 하나의 저장소, 하나의 언어, 하나의 프레임워크 사용
• Micro Frontend 아키텍처: 대규모 프론트엔드 애플리케이션을 여러 작은 독립적 애플리케이션으로 분해(예: Header, Product Listing, Product Details, Shopping Cart, Checkout 각각이 별도 마이크로 프론트엔드)
• 독립적 배포: 각 마이크로 프론트엔드를 별도 팀이 소유하고 다른 버전의 React 또는 Vue, Angular 같은 다른 프레임워크로 개발·배포 가능
• 동적 로딩 구현: Shell 애플리케이션이 런타임에 마이크로 프론트엔드의 JavaScript 번들을 동적으로 로드(Webpack Module Federation 또는 커스텀 JS 로더 사용)
• 마이크로 프론트엔드 간 통신: 이벤트 버스 같은 견고한 통신 패턴을 통해 명확한 API 계약 정의

Key Takeaway

마이크로 프론트엔드는 기술적 구현만큼 조직 구조(자율적 팀, 명확한 도메인 경계, 엔지니어링 성숙도)가 중요하다. 새 프로젝트는 SPA로 시작하되, 팀 간 병합 충돌과 배포 지연 같은 구체적 통증이 발생할 때 전략적 마이그레이션을 검토해야 한다.