프론트엔드 마이크로 프론트엔드: Module Federation 아키텍처 마스터하기

오늘날 빠르게 진화하는 웹 개발 환경에서 대규모 프론트엔드 애플리케이션을 구축하고 유지 관리하는 것은 점점 더 복잡해질 수 있습니다. 기존의 모놀리식 아키텍처는 종종 코드 비대화, 빌드 시간 증가, 독립적인 배포의 어려움과 같은 문제로 이어집니다. 마이크로 프론트엔드는 프론트엔드를 더 작고 관리하기 쉬운 조각으로 나누어 해결책을 제시합니다. 이 기사에서는 마이크로 프론트엔드를 구현하기 위한 강력한 기술인 Module Federation을 자세히 살펴보고, 그 이점, 아키텍처 및 실용적인 구현 전략을 탐구합니다.

마이크로 프론트엔드란 무엇인가요?

마이크로 프론트엔드는 프론트엔드 애플리케이션이 더 작고 독립적이며 배포 가능한 단위로 분해되는 아키텍처 스타일입니다. 각 마이크로 프론트엔드는 일반적으로 별도의 팀이 소유하여 더 큰 자율성과 더 빠른 개발 주기를 허용합니다. 이 접근 방식은 백엔드에서 일반적으로 사용되는 마이크로 서비스 아키텍처를 미러링합니다.

마이크로 프론트엔드의 주요 특징은 다음과 같습니다.

• 독립적인 배포 가능성: 각 마이크로 프론트엔드는 애플리케이션의 다른 부분에 영향을 주지 않고 독립적으로 배포할 수 있습니다.
• 팀 자율성: 다른 팀은 선호하는 기술과 워크플로를 사용하여 서로 다른 마이크로 프론트엔드를 소유하고 개발할 수 있습니다.
• 기술 다양성: 마이크로 프론트엔드는 서로 다른 프레임워크와 라이브러리를 사용하여 구축할 수 있으므로 팀에서 작업에 가장 적합한 도구를 선택할 수 있습니다.
• 격리: 마이크로 프론트엔드는 서로 격리되어야 연쇄적 실패를 방지하고 안정성을 보장합니다.

마이크로 프론트엔드를 사용하는 이유는 무엇인가요?

마이크로 프론트엔드 아키텍처를 채택하면 특히 크고 복잡한 애플리케이션에 대해 몇 가지 중요한 이점이 있습니다.

• 확장성 향상: 프론트엔드를 더 작은 단위로 나누면 필요에 따라 애플리케이션을 더 쉽게 확장할 수 있습니다.
• 더 빠른 개발 주기: 독립된 팀이 병렬로 작업할 수 있으므로 개발 및 릴리스 주기가 빨라집니다.
• 팀 자율성 증가: 팀은 코드를 더 잘 제어하고 독립적으로 결정을 내릴 수 있습니다.
• 유지 관리 용이성: 더 작은 코드베이스는 유지 관리 및 디버깅이 더 쉽습니다.
• 기술 무관: 팀은 특정 요구 사항에 가장 적합한 기술을 선택할 수 있으므로 혁신과 실험이 가능합니다.
• 위험 감소: 배포가 더 작고 빈번해져 대규모 실패의 위험이 줄어듭니다.

Module Federation 소개

Module Federation은 JavaScript 애플리케이션이 런타임에 다른 애플리케이션에서 코드를 동적으로 로드할 수 있도록 하는 Webpack 5에 도입된 기능입니다. 이를 통해 진정으로 독립적이고 구성 가능한 마이크로 프론트엔드를 만들 수 있습니다. 모든 것을 단일 번들로 빌드하는 대신 Module Federation을 사용하면 서로 다른 애플리케이션이 로컬 종속성인 것처럼 서로의 모듈을 공유하고 사용할 수 있습니다.

iframe 또는 웹 구성 요소에 의존하는 기존의 마이크로 프론트엔드 접근 방식과 달리 Module Federation은 사용자에게 더욱 원활하고 통합된 경험을 제공합니다. 이러한 다른 기술과 관련된 성능 오버헤드와 복잡성을 피합니다.

Module Federation 작동 방식

Module Federation은 "노출" 및 "사용" 모듈의 개념으로 작동합니다. 하나의 애플리케이션("호스트" 또는 "컨테이너")은 모듈을 노출할 수 있고 다른 애플리케이션("원격")은 이러한 노출된 모듈을 사용할 수 있습니다. 프로세스에 대한 분석은 다음과 같습니다.

1. 모듈 노출: Webpack에서 "원격" 애플리케이션으로 구성된 마이크로 프론트엔드는 구성 파일을 통해 특정 모듈(구성 요소, 함수, 유틸리티)을 노출합니다. 이 구성은 공유할 모듈과 해당 진입점을 지정합니다.
2. 모듈 사용: "호스트" 또는 "컨테이너" 애플리케이션으로 구성된 다른 마이크로 프론트엔드는 원격 애플리케이션을 종속성으로 선언합니다. 원격의 모듈 페더레이션 매니페스트(노출된 모듈을 설명하는 작은 JSON 파일)를 찾을 수 있는 URL을 지정합니다.
3. 런타임 확인: 호스트 애플리케이션이 원격 애플리케이션의 모듈을 사용해야 하는 경우 원격의 모듈 페더레이션 매니페스트를 동적으로 가져옵니다. 그런 다음 Webpack은 모듈 종속성을 확인하고 런타임에 원격 애플리케이션에서 필요한 코드를 로드합니다.
4. 코드 공유: Module Federation은 또한 호스트와 원격 애플리케이션 간의 코드 공유를 허용합니다. 두 애플리케이션 모두 동일한 버전의 공유 종속성(예: React, lodash)을 사용하는 경우 코드가 공유되어 중복을 방지하고 번들 크기를 줄입니다.

Module Federation 설정: 실용적인 예

두 개의 마이크로 프론트엔드("제품 카탈로그" 및 "쇼핑 카트")를 포함하는 간단한 예를 통해 Module Federation을 설명해 보겠습니다. 제품 카탈로그는 쇼핑 카트가 관련 제품을 표시하기 위해 사용할 제품 목록 구성 요소를 노출합니다.

프로젝트 구조

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

제품 카탈로그 (원격)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

설명:

• name: 원격 애플리케이션의 고유한 이름입니다.
• filename: 노출될 진입점 파일의 이름입니다. 이 파일에는 모듈 페더레이션 매니페스트가 포함되어 있습니다.
• exposes: 이 애플리케이션에서 노출할 모듈을 정의합니다. 이 경우 `ProductList` 구성 요소를 `./ProductList`라는 이름으로 `src/components/ProductList.jsx`에서 노출합니다.
• shared: 호스트와 원격 애플리케이션 간에 공유해야 하는 종속성을 지정합니다. 이는 코드 중복을 방지하고 호환성을 보장하는 데 매우 중요합니다. `singleton: true`는 공유 종속성의 인스턴스가 하나만 로드되도록 합니다. `eager: true`는 공유 종속성을 처음에 로드하여 성능을 향상시킬 수 있습니다. `requiredVersion`은 공유 종속성에 대한 허용 가능한 버전 범위를 정의합니다.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

쇼핑 카트 (호스트)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

설명:

• name: 호스트 애플리케이션의 고유한 이름입니다.
• remotes: 이 애플리케이션이 모듈을 사용할 원격 애플리케이션을 정의합니다. 이 경우 `product_catalog`라는 원격을 선언하고 해당 `remoteEntry.js` 파일을 찾을 수 있는 URL을 지정합니다. 형식은 `remoteName: 'remoteName@remoteEntryUrl'`입니다.
• shared: 원격 애플리케이션과 유사하게 호스트 애플리케이션도 공유 종속성을 정의합니다. 이렇게 하면 호스트와 원격 애플리케이션에서 공유 라이브러리의 호환 가능한 버전을 사용하도록 할 수 있습니다.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Fetch related products data (e.g., from an API)
      const fetchProducts = async () => {
        // Replace with your actual API endpoint
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Related Products
        {products.length > 0 ?  : 
Loading...
}
      
    );
  };

  export default RelatedProducts;
  

설명:

• import ProductList from 'product_catalog/ProductList'; 이 줄은 `product_catalog` 원격에서 `ProductList` 구성 요소를 가져옵니다. 구문 `remoteName/moduleName`은 Webpack에 지정된 원격 애플리케이션에서 모듈을 가져오도록 지시합니다.
• 그런 다음 구성 요소는 가져온 `ProductList` 구성 요소를 사용하여 관련 제품을 표시합니다.

예제 실행

1. 각 개발 서버(예: `npm start`)를 사용하여 제품 카탈로그 및 쇼핑 카트 애플리케이션을 모두 시작합니다. 서로 다른 포트에서 실행되고 있는지 확인합니다(예: 포트 3001의 제품 카탈로그 및 포트 3000의 쇼핑 카트).
2. 브라우저에서 쇼핑 카트 애플리케이션으로 이동합니다.
3. 제품 카탈로그 애플리케이션의 `ProductList` 구성 요소로 렌더링되는 관련 제품 섹션이 표시되어야 합니다.

고급 Module Federation 개념

기본 설정을 넘어 Module Federation은 마이크로 프론트엔드 아키텍처를 향상시킬 수 있는 몇 가지 고급 기능을 제공합니다.

코드 공유 및 버전 관리

예제에서 설명했듯이 Module Federation을 사용하면 호스트와 원격 애플리케이션 간에 코드를 공유할 수 있습니다. 이는 Webpack의 `shared` 구성 옵션을 통해 달성됩니다. 공유 종속성을 지정하면 코드 중복을 방지하고 번들 크기를 줄일 수 있습니다. 호환성을 보장하고 충돌을 방지하려면 공유 종속성의 적절한 버전 관리가 중요합니다. SemVer(Semantic Versioning)는 소프트웨어 버전 관리에 널리 사용되는 표준으로, 호환 가능한 버전 범위를 정의할 수 있습니다(예: `^17.0.0`은 17.0.0 이상 18.0.0 미만의 모든 버전을 허용합니다.).

동적 원격

이전 예에서는 원격 URL이 `webpack.config.js` 파일에 하드코딩되었습니다. 그러나 많은 실제 시나리오에서 런타임에 원격 URL을 동적으로 결정해야 할 수 있습니다. 이는 promise 기반 원격 구성을 사용하여 달성할 수 있습니다.

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Fetch the remote URL from a configuration file or API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

이를 통해 환경(예: 개발, 스테이징, 프로덕션) 또는 기타 요소를 기반으로 원격 URL을 구성할 수 있습니다.

비동기 모듈 로딩

Module Federation은 비동기 모듈 로딩을 지원하여 필요에 따라 모듈을 로드할 수 있습니다. 이렇게 하면 중요하지 않은 모듈의 로딩을 연기하여 애플리케이션의 초기 로드 시간을 개선할 수 있습니다.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Related Products
        Loading...
}>
          
        
      
    );
  };
  

`React.lazy` 및 `Suspense`를 사용하여 `ProductList` 구성 요소를 원격 애플리케이션에서 비동기적으로 로드할 수 있습니다. `Suspense` 구성 요소는 모듈이 로드되는 동안 대체 UI(예: 로딩 표시기)를 제공합니다.

연합된 스타일 및 자산

Module Federation은 마이크로 프론트엔드 간에 스타일과 자산을 공유하는 데에도 사용할 수 있습니다. 이렇게 하면 애플리케이션 전체에서 일관된 모양과 느낌을 유지하는 데 도움이 될 수 있습니다.

스타일을 공유하려면 CSS 모듈 또는 스타일 구성 요소를 원격 애플리케이션에서 노출할 수 있습니다. 자산(예: 이미지, 글꼴)을 공유하려면 Webpack을 구성하여 자산을 공유 위치로 복사한 다음 호스트 애플리케이션에서 참조할 수 있습니다.

Module Federation을 위한 모범 사례

Module Federation을 구현할 때는 성공적이고 유지 관리 가능한 아키텍처를 보장하기 위해 모범 사례를 따르는 것이 중요합니다.

• 명확한 경계 정의: 마이크로 프론트엔드 간의 경계를 명확하게 정의하여 긴밀한 결합을 방지하고 독립적인 배포 가능성을 보장합니다.
• 통신 프로토콜 확립: 마이크로 프론트엔드 간에 명확한 통신 프로토콜을 정의합니다. 이벤트 버스, 공유 상태 관리 라이브러리 또는 사용자 지정 API 사용을 고려하십시오.
• 공유 종속성 신중하게 관리: 버전 충돌을 방지하고 호환성을 보장하기 위해 공유 종속성을 신중하게 관리합니다. 의미 체계적 버전 관리를 사용하고 npm 또는 yarn과 같은 종속성 관리 도구 사용을 고려하십시오.
• 강력한 오류 처리 구현: 연쇄적 실패를 방지하고 애플리케이션의 안정성을 보장하기 위해 강력한 오류 처리를 구현합니다.
• 성능 모니터링: 병목 현상을 식별하고 성능을 최적화하기 위해 마이크로 프론트엔드의 성능을 모니터링합니다.
• 배포 자동화: 일관되고 안정적인 배포를 보장하기 위해 배포 프로세스를 자동화합니다.
• 일관된 코딩 스타일 사용: 가독성 및 유지 관리를 개선하기 위해 모든 마이크로 프론트엔드에서 일관된 코딩 스타일을 적용합니다. ESLint 및 Prettier와 같은 도구가 이에 도움이 될 수 있습니다.
• 아키텍처 문서화: 모든 팀 구성원이 시스템과 작동 방식을 이해하도록 마이크로 프론트엔드 아키텍처를 문서화합니다.

Module Federation 대 다른 마이크로 프론트엔드 접근 방식

Module Federation은 마이크로 프론트엔드를 구현하기 위한 강력한 기술이지만 유일한 접근 방식은 아닙니다. 다른 널리 사용되는 방법은 다음과 같습니다.

• Iframe: Iframe은 마이크로 프론트엔드 간의 강력한 격리를 제공하지만 원활하게 통합하기 어렵고 성능 오버헤드가 발생할 수 있습니다.
• 웹 구성 요소: 웹 구성 요소를 사용하면 서로 다른 마이크로 프론트엔드에서 사용할 수 있는 재사용 가능한 UI 요소를 만들 수 있습니다. 그러나 Module Federation보다 구현하기 더 복잡할 수 있습니다.
• 빌드 타임 통합: 이 접근 방식에는 빌드 시점에 모든 마이크로 프론트엔드를 단일 애플리케이션으로 빌드하는 것이 포함됩니다. 배포를 단순화할 수 있지만 팀 자율성을 줄이고 충돌 위험을 증가시킵니다.
• Single-SPA: Single-SPA는 여러 단일 페이지 애플리케이션을 단일 애플리케이션으로 결합할 수 있는 프레임워크입니다. 빌드 타임 통합보다 더 유연한 접근 방식을 제공하지만 설정이 더 복잡할 수 있습니다.

어떤 접근 방식을 사용할지는 애플리케이션의 특정 요구 사항과 팀의 규모와 구조에 따라 달라집니다. Module Federation은 유연성, 성능 및 사용 편의성의 균형을 잘 유지하여 많은 프로젝트에서 인기 있는 선택입니다.

Module Federation의 실제 예

특정 회사 구현은 종종 기밀이지만 Module Federation의 일반적인 원칙은 다양한 산업 및 시나리오에서 적용되고 있습니다. 몇 가지 잠재적 예는 다음과 같습니다.

• 전자 상거래 플랫폼: 전자 상거래 플랫폼은 Module Federation을 사용하여 제품 카탈로그, 쇼핑 카트, 결제 프로세스 및 사용자 계정 관리와 같은 웹사이트의 서로 다른 섹션을 별도의 마이크로 프론트엔드로 분리할 수 있습니다. 이를 통해 서로 다른 팀이 이러한 섹션에서 독립적으로 작업하고 플랫폼의 나머지 부분에 영향을 주지 않고 업데이트를 배포할 수 있습니다. 예를 들어, *독일*의 팀은 제품 카탈로그에 집중하고 *인도*의 팀은 쇼핑 카트를 관리할 수 있습니다.
• 금융 서비스 애플리케이션: 금융 서비스 애플리케이션은 Module Federation을 사용하여 거래 플랫폼 및 계정 관리와 같은 민감한 기능을 별도의 마이크로 프론트엔드로 격리할 수 있습니다. 이는 보안을 강화하고 이러한 중요한 구성 요소에 대한 독립적인 감사를 허용합니다. *런던*의 팀이 거래 플랫폼 기능을 전문으로 하고 *뉴욕*의 다른 팀이 계정 관리를 처리한다고 상상해 보십시오.
• 콘텐츠 관리 시스템(CMS): CMS는 Module Federation을 사용하여 개발자가 사용자 지정 모듈을 마이크로 프론트엔드로 만들고 배포할 수 있도록 할 수 있습니다. 이를 통해 CMS 사용자를 위한 더 큰 유연성과 사용자 지정이 가능합니다. *일본*의 팀은 특수 이미지 갤러리 모듈을 구축할 수 있고 *브라질*의 팀은 고급 텍스트 편집기를 만들 수 있습니다.
• 의료 애플리케이션: 의료 애플리케이션은 Module Federation을 사용하여 전자 건강 기록(EHR), 환자 포털 및 청구 시스템과 같은 서로 다른 시스템을 별도의 마이크로 프론트엔드로 통합할 수 있습니다. 이는 상호 운용성을 개선하고 새로운 시스템을 더 쉽게 통합할 수 있도록 합니다. 예를 들어, *캐나다*의 팀은 새로운 원격 의료 모듈을 통합하고 *호주*의 팀은 환자 포털 경험 개선에 집중할 수 있습니다.

결론

Module Federation은 마이크로 프론트엔드를 구현하기 위한 강력하고 유연한 접근 방식을 제공합니다. 애플리케이션이 런타임에 서로 코드를 동적으로 로드할 수 있도록 함으로써 진정으로 독립적이고 구성 가능한 프론트엔드 아키텍처를 생성할 수 있습니다. 신중한 계획과 구현이 필요하지만 확장성 증가, 더 빠른 개발 주기, 더 큰 팀 자율성의 이점은 대규모의 복잡한 웹 애플리케이션에 대한 매력적인 선택입니다. 웹 개발 환경이 계속 발전함에 따라 Module Federation은 프론트엔드 아키텍처의 미래를 형성하는 데 점점 더 중요한 역할을 할 것입니다.

이 기사에서 설명된 개념과 모범 사례를 이해하면 Module Federation을 활용하여 오늘날 빠르게 변화하는 디지털 세계의 요구를 충족하는 확장 가능하고 유지 관리 가능하며 혁신적인 프론트엔드 애플리케이션을 구축할 수 있습니다.