피드로 돌아가기
대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 1. 마이크로프론트엔드 너 뭐야?
올리브영 테크블로그올리브영 테크블로그
Frontend

대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 1. 마이크로프론트엔드 너 뭐야?

올리브영이 모놀리식 프론트엔드 아키텍처의 배포 의존성·빌드 시간·기술 스택 제약을 마이크로프론트엔드로 분할하여 팀 독립성 확보

2025년 7월 22일12intermediate

Context

모놀리식 프론트엔드 아키텍처에서 애플리케이션 규모가 커지면서 작은 변경사항도 전체 애플리케이션을 다시 빌드·배포해야 하는 배포 의존성이 발생했다. 모든 팀이 동일한 프레임워크와 버전을 사용해야 하는 기술 스택 제약과 여러 팀의 동시 작업 시 머지 충돌이 빈번하게 발생했으며, 코드 베이스 증가에 따라 빌드와 테스트 시간이 지속적으로 증가했다.

Technical Solution

  • 웹 애플리케이션을 독립적으로 개발·배포·운영 가능한 작은 단위로 분할: 백엔드 마이크로서비스 패턴을 프론트엔드에 적용하여 단일 SPA 대신 여러 개의 작은 애플리케이션 조합 구성
  • 빌드 타임 통합 전략 도입: npm 패키지 방식(각 마이크로 앱을 npm 패키지로 관리) 또는 Nx·Turborepo 같은 모노레포 도구를 활용하여 여러 마이크로 앱을 하나의 저장소에서 관리하면서 독립적 라이브러리로 취급
  • 런타임 통합 전략 도입: Module Federation(Webpack 5)을 통해 호스트 애플리케이션이 리모트 애플리케이션을 런타임에 동적으로 불러와 통합
  • 통합 위치 선택: 서버 측 구성(SSR)으로 완성된 HTML을 브라우저로 전송, 클라이언트 측 구성(CSR)으로 브라우저에서 마이크로 앱 동적 로드, 또는 Edge Computing으로 에지 네트워크에서 조합
  • 각 마이크로 앱의 기술 스택 독립화: 헤더(React), 상품(Vue.js), 장바구니(Angular), 결제(Svelte) 등 팀별로 다른 기술 스택 선택 가능

Key Takeaway

마이크로프론트엔드는 코드 분리만으로는 실현되지 않으며, 각 단위가 독립적인 생명주기(개발·빌드·배포)를 가질 수 있도록 하는 통합 방식(언제·어디서 조합할지)이 핵심이다. 도입 시 단순히 최신 기술이기 때문이 아니라 팀 규모·도메인 복잡성·조직 문화·인프라 역량을 종합적으로 고려한 후 점진적으로 접근해야 하며, 빌드 타임 통합의 경우 모든 앱이 동일 라이브러리 버전(Single Version Policy)을 강제해야 하는 제약이 있다.


모놀리식 프론트엔드로 인해 배포 의존성·기술 스택 통일 문제를 겪는 팀에서는 npm 패키지 방식 또는 모노레포(Nx) 기반 빌드 타임 통합을 먼저 시도하면 기존 JavaScript 생태계를 그대로 활용하면서 팀 간 코드 공유와 초기 로딩 성능을 확보할 수 있다. 반면 각 팀의 완전한 배포 독립성이 필수라면 Module Federation 등 런타임 통합을 검토하되, SSR·CSR·Edge Computing 중 SEO·초기 로딩 속도·서버 부하 요구사항에 따라 통합 위치를 신중히 선택해야 한다.

원문 읽기