수십 개의 배민 admin을 하나의 monorepo로 통합했더니 배포 결합·책임 불명확·communication 비용이 오히려 커졌다. 이를 micro-frontend와 Module Federation으로 낮추고, MF 1.0의 한계를 2.0과 사내 platform으로 넘어선 과정을 소개한다.
핵심 포인트- pnpm·Turborepo·Next.js monorepo 통합이 참여 team 증가로 배포 주기 충돌과 dependency 충돌을 키우자, 각 조직이 독립 배포한 component·page를 사용자에게는 하나의 web으로 조합하는 micro-frontend를 목표로 설정
- MF 1.0으로 GNB·sidebar·content를 나눠 S3·menu JSON으로 연결했지만 remote 등록마다 host 재배포, 불안정한 TypeScript 지원, host·remote 동시 실행 test, 5천 줄 넘는 remote entry 문제가 남음
- MF 2.0은 구현을 federation runtime과 container·application으로 분리해 runtime API·lifecycle plugin을 제공하고, 선언형 JSON manifest로 load 비용을 줄이며 production remote의 d.ts를 개발 환경에 자동 갱신하는 dynamic type hint로 type safety 복원
- 남은 host clone·공통 code 중복·runtime remote 관리 문제는 federation·module metadata를 중앙 DB에 두는 Module Federation Platform으로 해결하고, Exodia library·remote control admin·virtual host로 host 재배포 없는 remote 추가와 local 개발 표준화
왜 읽나조직이 커지며 monorepo 결합에 부딪힌 프런트엔드 플랫폼 팀에게, Module Federation 도입부터 사내 platform 표준화까지의 진화 경로를 보여주는 사례.