Micro Frontend 알아보기

이종경·2025년 6월 2일
0

기본 개념

프론트엔드 구조

마이크로 프론트엔드 아키텍처는 대규모 프론트엔드 애플리케이션을 여러 개의 작은 단위로 분리하여 개발하고 통합하는 방법입니다.

전통적인 모놀리식 프론트엔드(Monolithic Frontend)에서는 하나의 프론트엔드 애플리케이션이 모든 기능을 포함하여 한 번에 배포됩니다. 이는 개발과 배포가 단순하지만, 작은 변경에도 전체 애플리케이션을 다시 배포해야 하고, 하나의 거대한 코드베이스에서 여러 팀이 함께 작업할 경우 충돌이 발생하기 쉽습니다. 또한 모든 팀이 동일한 기술 스택을 사용해야 하므로 새로운 기술 도입이나 개별 최적화에 제약이 있습니다

이에 반해, 마이크로 프론트엔드(Micro Frontend)에서는 프론트엔드를 도메인이나 기능별로 잘게 나눈 독립적인 프론트엔드 모듈들로 구성합니다. 각 모듈은 자체 코드베이스와 빌드 파이프라인을 가지며, 독립적으로 개발·테스트·배포가 가능합니다. 다시 말해 “독립적으로 배포 가능한 여러 개의 프론트엔드 애플리케이션을 모아 전체 애플리케이션을 구성하는” 아키텍처입니다. 이러한 분산 구조 덕분에 필요에 따라 각 모듈마다 서로 다른 기술 스택을 사용할 수도 있어 전체 애플리케이션 내에서 기술 다각화를 허용합니다.

비교 항목모놀리식 프론트엔드마이크로 프론트엔드
코드베이스 구조하나의 거대한 저장소(repo) 또는 프로젝트에 전체 UI 코드 통합여러 개의 독립된 코드베이스 (기능/도메인 별 분리)
배포 단위프론트엔드 전체를 일괄 배포 (한 부분 수정 시 전체 재배포)마이크로앱 단위로 개별 배포 (다른 모듈 영향 없이 부분적 배포)
기술 스택전체 애플리케이션에 단일 기술 스택 적용 (한 가지 프레임워크/버전)모듈마다 최적 기술 선택 가능 (여러 프레임워크 공존 허용)
스케일링애플리케이션 전체로만 확장/최적화 가능트래픽 많은 모듈만 별도 확장 또는 최적화 가능 (독립 스케일링)
배포 빈도릴리스 단위가 크고 낮은 빈도의 배포 (예: 수주일 간격)작고 잦은 배포 가능 (모듈 단위로 수시 출시)
장애 영향한 부분의 버그가 전체 프론트엔드에 영향 줄 수 있음개별 모듈 장애는 해당 부분만 영향 (격리 및 신속한 롤백 용이)
초기 구축 난이도아키텍처 단순, 설정 용이아키텍처 복잡, 통합/배포 설정 난이도 높음

구현 방식

Build-Time MFE : MonoRepo

BuildTime MFE
빌드 타임 MFE는 각 마이크로 프론트엔드를 빌드 시점에서 미리 통합하는 방식입니다. 즉, 개발 단계에서 코드가 통합되어 하나의 번들로 만들어지는 접근법입니다.

  • 단일 저장소 관리
    • 모든 마이크로 프론트엔드 모듈이 하나의 리포지토리 안에 구성됩니다.
    • 주로 Yarn workspaces, pnpm workspace, Nx, Turborepo 같은 툴을 이용해 관리합니다.
  • 의존성 관리의 용이성
    • 중복된 라이브러리 관리가 용이하며 공통된 라이브러리를 쉽게 공유할 수 있습니다.
    • 동일한 버전 관리 및 코드 통합 관리가 쉽습니다.
  • 빌드 및 배포
    • 빌드/배포 파이프라인을 중앙에서 통합적으로 관리합니다.
    • 배포 단위가 크며, 변경 사항이 생기면 전체 또는 일부 앱이 함께 배포됩니다.
  • 장점
    • 빌드 과정에서 전체 애플리케이션이 최적화되어 로드 시간과 효율성이 향상됩니다.
    • 하나의 통합된 번들을 사용하면 여러 배포 복잡성에 대한 배포 및 보호가 더 쉬워집니다.
    • 모든 측면이 특정 종속성 버전을 기반으로 구축되도록 하여 충돌을 방지합니다.
  • 단점
    • 독립적으로 업데이트하거나 배포할 수 없으므로 팀의 유연성이 떨어집니다.
    • 모든 구성 요소를 구축 과정에서 통합하고 테스트해야 하므로 복잡하고 시간이 많이 걸립니다.
    • 확장성 문제는 다른 부분에 영향을 주지 않고 특정 애플리케이션 부분을 확장해야 할 때 발생합니다.
    • 구성 요소는 빌드 시점에 긴밀하게 결합됩니다.
my-monorepo/
├── packages
│   ├── mfe-cart
│   ├── mfe-payment
│   └── shared-ui
├── apps
│   └── container-app
├── package.json (워크스페이스 설정)
└── turbo.json / nx.json

Run-Time MFE : Module Federation

RunTime MFE

런타임 MFE는 마이크로 프론트엔드 모듈들이 런타임에 동적으로 통합되는 방식입니다. 배포 이후에도 동적으로 모듈을 로드하거나 변경할 수 있습니다.

특징

  • URL 경로에 따라 애플리케이션을 분할하는 방식입니다.
  • 각 경로는 완전한 독립적인 앱으로 구분됩니다.
  • 화면이 완전히 교체될 때 사용하는 방식입니다.

예시

  • /cart, /product, /user-profile 각각의 경로가 다른 애플리케이션으로 구성되어 별도 로드됩니다.
- /cart → cart-app 로드
- /payment → payment-app 로드

장점

  • 시스템의 각 부분은 독립적으로 확장될 수 있습니다.
  • 각 팀은 소프트웨어 구성 요소를 개발할 때 자신이 가장 선호하는 도구와 기술을 사용할 수 있습니다.
  • 여러 팀이 동시에 개발할 수 있어 개발 시간이 단축됩니다.
  • 단일 마이크로 프론트엔드 내의 문제는 전체 애플리케이션을 중단시키지 않습니다.
  • 다양한 프로젝트와 애플리케이션에서 구성 요소의 재사용을 향상합니다.

단점

  • 여러 구성 요소를 통합하는 것은 매우 어려울 수 있습니다.
  • 동적 로딩 및 통합 프로세스는 성능 지연이나 오버헤드로 이어질 수 있습니다.
  • 다양한 마이크로 프론트엔드에서 일관된 사용자 인터페이스와 경험을 제공하는 것은 어렵습니다.
  • 구성 요소 전체의 호환성과 기능을 테스트하기 위한 포괄적인 테스트 전략이 필요합니다.

참고
Module Federation으로 알아보는 Micro Front-end
Everything You Need to Know About Micro Frontends
Micro Frontend: Run-Time Vs. Build-Time Integration
Microfrontend: Build-Time Intergation vs Run-Time Integration Concepts

profile
작은 성취들이 모여 큰 결과를 만든다고 믿으며, 꾸준함을 바탕으로 개발 역량을 키워가고 있습니다

0개의 댓글