blog

마이크로 프론트엔드(Micro-Frontend, MFE) 도입 전략

Nextree

• 5 min read
마이크로 프론트엔드(Micro-Frontend, MFE) 도입 전략

1. 마이크로 프론트엔드(Micro-Frontend, MFE)의 이해

마이크로 프론트엔드는 백엔드의 마이크로서비스 아키텍처(MSA) 개념을 프론트엔드로 확장한 패러다임입니다. 거대하고 복잡한 하나의 프론트엔드 애플리케이션을 더 작고 독립적으로 배포 가능한 여러 개의 애플리케이션으로 분할하여 조립하는 방식입니다.

주요 특징

  • 독립적인 배포 (Independent Deployment): 특정 기능이나 메뉴를 수정했을 때 전체 애플리케이션을 다시 빌드하고 배포할 필요 없이, 해당 모듈만 개별적으로 배포할 수 있습니다.
  • 기술 스택의 유연성: 각 마이크로 앱마다 서로 다른 기술 스택을 사용할 수 있습니다. (단, 무분별한 스택 혼용은 성능 저하를 야기할 수 있어 실무에서는 통일하는 경우가 많습니다.)
  • 자율적인 팀 운영: 도메인(기능)별로 팀을 나누어, 각 팀이 기획부터 개발, 배포까지 End-to-End로 책임지는 교차 기능 팀(Cross-functional team) 운영에 적합합니다.
  • 장애 격리 (Fault Isolation): 하나의 마이크로 앱에서 발생한 치명적인 에러가 전체 서비스의 다운으로 이어지지 않도록 구조적으로 격리할 수 있습니다.

2. 저장소 관리 전략 비교: 멀티레포(Multi-Repo) vs 모노레포(Mono-Repo)

구분 멀티레포 (Multi-Repo) 모노레포 (Mono-Repo)
개념 각 MFA별 별도로 Git 저장소 관리 단일 Git 저장소 내에서 폴더로 구분/관리
코드 격리성 물리적 분리로 매우 높음 논리적 분리, 공통 코드 참조 용이
CI/CD 파이프라인 레포별 구성으로 매우 직관적이고 단순함 변경된 앱만 빌드하기 위한 복잡한 설정 필요
장점 명확한 권한 관리, 저장소 경량화, 배포 독립성 보장 공통 컴포넌트/설정(ESLint 등) 공유 및 의존성 관리 용이
단점 공통 모듈 공유의 번거로움 저장소 크기, CI/CD, 유지보수 난이도 증가

3. 마이크로 프론트엔드 전환 또는 도입 전략

기존 인프라 등의 변경 없이 서비스(도메인)별 변경/배포에 영향도 제로를 달성하기 위해서는 멀티레포(Multi-Repo) 기반의 Module Federation 아키텍처가 채택되고 있습니다. 신규의 인프라와 함께 구성이 가능한 경우, 모노레포(Mono-Repo) 기반이 채택되는 추세입니다.

멀티레포(Multi-Repo)를 선택하는 경우

  • 도메인별 자율성이 필요할 시
  • 도메인별 결합도를 낮추고자 할 때
  • 초기 인프라 구축을 기존 인프라 사용을 도모할 때는(CI/CD 구조 등 유지)

저장소의 구조

  • Host-App: 로그인, 공통 레이아웃(GNB, LNB), 라우팅 등을 담당하는 레포지토리
  • Remote-App: 각 메뉴(서비스, 도메인)로 분리된 개별 서비스 레포지토리
    (예: 결제 메뉴, 대시보드, 주문 메뉴 등)

CI/CD의 흐름 방식

  • 코드 변경: 특정 Remote-App의 레포지토리에 코드를 변경 및 push 된다.
  • 독립 빌드: 변경된 이력이 있는 레포지토리만 CI가 트리거되어 빌드를 진행한다.
  • 독립 배포: 빌드된 결과물에 해당하는 레포지토리만 CI/CD의 흐름에 진행된다.
  • 런타임 통합: Host-App은 재빌드/배포 없이 사용자가 해당 Remote-App의 메뉴 등을 호출하면 App이 최신 배포된 remoteEntry.js를 동적으로 호출해 렌더링(rendering)

4. Frontend 마이그레이션 및 Converting 가이드

CRA의 deprecate 등의 이유를 고려해 빌드 및 HMR 속도를 극대화 하기 위해 esbuild/Rollup 기반의 Vite로 전환합니다.

  • CRA에서 Vite 환경 전환: 의존성 교체(react-script 제거, @vitejs/plugin-react 도입)
  • 설정파일 생성/변경: vite.config.ts 생성, tsconfig.json 변경(tsconfig.app,json tsconfig.node.json의 참조 방식)
  • 환경변수 변경/생성: REACT_APP prefix를 VITE_로 변경, 호출 방식을 process.env에서 import.meta.env로 변경
  • React18, TS v5, eslint v9 업그레이드: tsconfig의 target을 “ESNext”에서 “bundler”로 변경 등 최신 옵션 적용
  • ESlint의 flat config로 변경: eslintrc.json 형식에서 flat config 형식으로의 변경에 따른 설정 최신 옵션 적용(버전 미업그레이드 라이브러리와의 충돌 관련 설정도 조정. 예: MUI v4의 findDOMNode, JSS 동작 방식)
  • 레거리 코드의 import 변경: import React from “./react”가 필수가 아니게 되어 기존 코드에서 일괄 제거
  • Host/Remote 연동 설정 추가: vite-plugin-federation을 통한 설정(shared-lib, 공유 대상 컴포넌트, 기능)
  • 라우팅 설정의 분리 및 이중: Host가 메인 라우터를 가지지만, Remote에서 제공되는 화면의 라우팅 설정 추가

Kiziri_dev

참고 문헌

  • 구글 Gemini
  • 마이크로프론트엔드 아키텍쳐: https://tinyurl.com/26cwjuvh
  • 대규모 프론트엔드 아키텍처의 새로운 패러다임: https://tinyurl.com/237udu5r
  • posting thumbnail마이크로 프론트엔드 (대규모 앱 개발 아키텍쳐) - React, 알고 쓰자 10일차: https://tinyurl.com/26os9slv
  • .etc