피드로 돌아가기
Micro Frontends & The Hidden Code Sharing Problem
Dev.toDev.to
Frontend

마이크로 프론트엔드 팀들이 Polyrepo + 내부 npm 패키지 방식에서 모노레포 워크스페이스로 전환하여 공유 코드 변경 시 발행-버전 범프-재테스트 사이클 제거

Micro Frontends & The Hidden Code Sharing Problem

Dhinesh K.S2026년 3월 28일5intermediate

Context

마이크로 프론트엔드 아키텍처는 팀 자율성을 제공하지만, 여러 앱이 동일한 포매터, API 클라이언트, 훅, 타입, 비즈니스 로직 등 공유 빌딩 블록에 의존한다. Polyrepo + 내부 npm 패키지 구조에서는 공유 코드의 단일 변경도 PR 검수 → npm 발행 → 모든 소비 앱의 의존성 범프 → 각 앱 재테스트 → 별도 배포의 6단계 워크플로우를 거쳐야 한다.

Technical Solution

  • 모노레포 구조 도입: 여러 마이크로 프론트엔드 앱(auth-app, product-catalog-app, cart-checkout-app, account-app)과 공유 패키지(shared-ui, shared-hooks, shared-utils, shared-types, api-client)를 단일 저장소로 통합
  • 내부 워크스페이스 기반 의존성 관리: 발행 단계 없이 @repo/shared-ui, @repo/shared-hooks 등으로 직접 import하여 공유 코드 즉시 사용 가능
  • 원자적 리팩토링 지원: 공유 코드 변경 시 소비 앱과 함께 단일 PR에서 테스트 및 배포
  • 의도적 공유 원칙 준수: 2개 이상 앱에서 사용되고, 시스템 전체에서 일관성 유지가 필요하며, 안정적인 코드만 공유 패키지로 추출
  • 로컬 코드 보존: 단일 앱 전용 코드는 해당 앱 내부에 유지하여 과도한 추상화 방지

Key Takeaway

모노레포의 진정한 가치는 패키지 스타일의 모듈성을 발행 오버헤드 없이 제공하는 데 있으며, 의도적 공유(intentional sharing)를 통해서만 건강한 모노레포 생태계를 유지할 수 있다.


마이크로 프론트엔드를 운영하는 팀에서 공유 코드가 3개 이상의 내부 npm 패키지로 분산되어 있다면, 모노레포 워크스페이스 도입을 검토하면 공유 코드 변경 시 발행-의존성 범프-재테스트 사이클을 제거하고 단일 PR 기반 원자적 리팩토링을 구현할 수 있다.

원문 읽기
Micro Frontends & The Hidden Code Sharing Problem | Devpick