미리캔버스 프론트엔드팀이 마이크로 프론트엔드(MFE) 아키텍처를 도입해 스쿼드 단위 독립 배포와 변경 영향 범위 최소화를 구현한 사례를 다룬다. 단순한 코드 분리가 아닌 6개 레이어의 단방향 의존성 그래프, 레이어별 Public API 계약, Webpack 5 Module Federation 기반 런타임 원격 로딩까지 구조적으로 구현했다. 목적조직(스쿼드)·기능조직(길드)의 서로 다른 경계가 코드 구조와 불일치하는 문제를 MFE로 해결한다.
핵심 포인트- 6개 레이어 단방향 의존성: shared → entity → feature → service → fragment → application, 역방향·동일 레이어 참조 툴링으로 강제 차단
- Webpack 5 Module Federation + manifest.json 기반 런타임 원격 로딩으로 fragment 단위 독립 배포
- 레이어별 Public API(barrel export) 계약: 내부 모듈 직접 참조 불가, 변경 영향 범위 최소화
- 스쿼드가 fragment 소유, 길드가 shared/entity 레이어 소유 — 조직 경계를 코드 구조에 직접 매핑
- 모노레포 구조를 유지하면서 레이어 규칙으로 모놀리스화 방지
상세 정리- 문제 1: 공유 컴포넌트 변경 시 전체 서비스 검증·배포 필요, 변경 영향 범위 제어 불가
- 문제 2: 목적조직(스쿼드)과 기능조직(길드)의 소유권 경계가 코드 구조와 불일치, 반복 마찰
- MFE 선택 이유: 코드 분리를 넘어 모듈 관계 제어 + 소유권 분리 + 인터페이스·구현 경계 명시화
- 6레이어 구조: shared(유틸·디자인 시스템) → entity(도메인 모델) → feature(비즈니스 로직+UI) → service(크로스 피처 오케스트레이션) → fragment(독립 배포 단위) → application(쉘·조합 진입점)
- 의존성 규칙: 상위 레이어가 하위 레이어 임포트 가능, 동일 레이어 간 참조 금지, 코드 수준 강제
- Public API: 각 패키지는 명시적 barrel export만 외부 노출, 내부 모듈 직접 접근 불가
- 런타임 페더레이션: fragment 패키지를 별도 배포 후 호스트 앱이 manifest.json 기반으로 런타임 로드
- manifest.json: 각 원격 fragment의 로드 버전 제어, 전체 서비스 배포 없이 fragment 단위 롤아웃 가능
- CI/CD: 아티팩트별 lint·type-check·test 3개 파이프라인 병렬 실행
- 빌드 타임 통합(shared/entity/feature/service)과 런타임 통합(fragment, Module Federation 원격 로드) 구분
- 결과: 스쿼드별 독립 배포 달성, 변경 영향 범위 fragment 단위로 축소, 조직 경계 = 코드 경계
왜 읽나모노레포를 유지하면서 마이크로 프론트엔드의 독립 배포 이점을 얻는 6레이어 아키텍처와 Webpack Module Federation 실전 구현 패턴을 조직 구조 매핑까지 포함해 설명한 실용적 사례다.