제135회 정보관리기술사 2교시 4번 — 마이크로프론트엔드(Module Federation·Single-SPA)

정보관리기술사 · 135회 2교시 · 4번 · 배점 25점

Table of Contents

제135회 정보관리기술사 2교시 4번

서술형 | 25점

[문제] 마이크로프론트엔드(Micro Frontend) 아키텍처의 개념과 모놀리식 프론트엔드와의 차이점을 설명하고, 마이크로프론트엔드 구현 방식(iFrame, Web Components, Module Federation, Single-SPA)을 비교하시오. 또한 마이크로프론트엔드 도입 시 고려해야 할 공통 UI 일관성, 성능, 팀 자율성 간의 트레이드오프를 논하시오.

1. 마이크로프론트엔드 개념과 모놀리식 비교

마이크로프론트엔드(Micro Frontend)는 마이크로서비스 아키텍처 원칙을 프론트엔드에 적용하여, 대형 SPA를 팀별로 독립적으로 개발·배포할 수 있는 소형 애플리케이션으로 분할하는 아키텍처 패턴이다.

구분	모놀리식 프론트엔드	마이크로프론트엔드
배포 단위	전체 앱을 단일 번들로 배포	기능 도메인별 독립 배포
팀 구조	단일 프론트엔드 팀, 중앙 집중	수직 팀(풀스택), 도메인 자율성
기술 스택	단일 프레임워크(React/Vue)	팀별 다른 프레임워크 혼용 가능
확장성	팀 증가 시 코드 충돌·병목	팀 간 독립적 개발·배포

2. 마이크로프론트엔드 구현 방식 비교

방식	원리	장점	단점
iFrame	HTML iFrame으로 독립 앱 삽입	완전 격리, 레거시 지원	UX 불연속, SEO 불리, 성능 저하
Web Components	Custom Elements + Shadow DOM으로 캡슐화된 컴포넌트	프레임워크 독립, 브라우저 표준	브라우저 호환성 (폴리필 필요)
Module Federation	Webpack 5 기능. 런타임에 원격 모듈을 동적 로드	공유 의존성 중복 제거, 동적 로딩	Webpack 의존성, 버전 불일치 위험
Single-SPA	라우팅 기반 MFE 오케스트레이션 프레임워크	다중 프레임워크 공존, 성숙한 생태계	초기 설정 복잡, 추가 런타임 번들

현재 주류: Webpack 5 Module Federation이 가장 많이 사용됨

3. 마이크로프론트엔드 트레이드오프

UI 일관성: 팀별 독립 개발 → 디자인 시스템(Design System) 공유 필수. Storybook + 공유 컴포넌트 라이브러리로 일관성 유지
성능: 각 MFE가 프레임워크를 별도 로드 → 중복 번들 증가. Module Federation 공유 의존성으로 완화. 최초 로드 시간 증가 위험
팀 자율성: 독립 기술 스택 허용 시 일관성·공유 어려움. “기술 선택 자유 vs 플랫폼 표준” 균형 필요
팀 간 통신: MFE 간 상태 공유는 Custom Events, 공유 상태 라이브러리, URL 파라미터로 제한
테스팅: E2E 테스트에서 여러 MFE 통합 환경 구축 복잡도 증가

[ 결론 ]

마이크로프론트엔드는 대규모 팀의 프론트엔드 독립 배포를 가능하게 하지만, UI 일관성·성능·팀 간 통신의 트레이드오프가 발생한다. Module Federation이 현재 가장 실용적인 구현 방식이며, 공유 디자인 시스템과 명확한 기술 거버넌스 정책이 성공의 핵심이다.

zerg96