Micro Frontend(MFE) 구조에서 빌드 시간을 줄이는 방법

프로젝트의 구조는 MFE(Micro Frontend) 아키텍처를 적용하고 있고, 약 10개 이상의 FE로 구성되어 있습니다.

그리고 런타임에 통합되는 애플리케이션이 존재합니다.

런타임에 통합되는 애플리케이션이란?

• Application : 런타임에 통합되는 애플리케이션
• Micro Service * : Micro Frontend 모듈

※ MFE를 Micro Service라고 칭하고, MS라고 사용하겠습니다.

 

각 MS가 모듈로 작성 및 생성되고, Application에서 각 MS를 가져다가 사용합니다.

즉, 배포되어 서비스되는 것은 Application입니다.

 

그렇다면 무슨 문제가 발생하였는가?

발생한 문제는 다음과 같습니다.

각 MS 모듈에서 사용하고 있는 dependencies와 함께 빌드되어 생성되면 모듈 사이즈가 엄청 커진다는 것입니다.

그러면 Application에서 각 MS 모듈을 설치할 때의 많은 비용이 발생합니다.

결국 최종 서비스되는 Application이 빌드될 때 각 MS 모듈의 크기로 인해 설치가 오래 걸리고, 이는 Application 빌드 시간이 늘어나는 문제가 발생합니다.

 

아, 참고로 AWS 환경에서 진행하였습니다.

 

이 문제를 어떻게 해결했는가?

먼저, 각 MS의 package.json을 살펴볼 필요가 있습니다.

왜냐하면 우리는 이미 MS가 사용하고 있는 라이브러리 때문에 모듈 사이즈가 커졌다는 사실을 알고 있기 때문입니다.

 

각 MS가 모듈로 빌드되어 생성이 될 때, 아래의 예시처럼 package.json의 dependencies, devDependencies에 라이브러리들이 명시되어 있는 상태였습니다.

// Micro Service A, Micro Service B, Micro Service C
// package.json
{
...
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "yarn": "^1.22.19"
  },
  "devDependencies": {
    "@types/react": "^18.0.28",
    "@types/react-dom": "^18.0.11",
    "@typescript-eslint/eslint-plugin": "^5.57.1",
    "@typescript-eslint/parser": "^5.57.1",
    "@vitejs/plugin-react": "^4.0.0",
    "eslint": "^8.38.0",
    "eslint-plugin-react-hooks": "^4.6.0",
    "eslint-plugin-react-refresh": "^0.3.4",
    "typescript": "^5.0.2",
    "vite": "^4.3.2"
  }
}

 

여기서 하나 짚고 가야할 점이 있습니다.

위에서 언급하긴 했지만, 기본적으로 dependencies에 명시된 라이브러리는 빌드할 때 bundle에 포함이 됩니다.

그 이유는 애플리케이션이 정상적으로 동작하기 위한 필수 구성 요소로 간주되기 때문입니다.

단순하게 생각해봅시다. 만약 bundle에 react가 포함되어 있지 않다면 애플리케이션이 동작하지 않겠죠..? 이런 이유 때문에 필수 구성 요소로 간주되는 것입니다.

 

그렇다면 devDependencies는 포함이 되지 않는 것인가? 그렇습니다. devDependencies는 bundle에 포함되지 않습니다.

devDependencies는 개발 환경에서만 필요한 라이브러리입니다. 예를 들어, 테스트 프레임워크, 빌드 도구, 린터 등이 이에 해당합니다.

일반적으로 번들링 도구(Webpack, Rollup 등)를 사용하여 애플리케이션을 번들링할 때, devDependencies에 있는 라이브러리는 번들에 포함되지 않습니다.

 

위의 예시는 A, B, C 총 3개의 프론트가 모두 dependencies에 라이브러리가 명시되어 있고, 이들을 빌드를 하면 dependencies에 명시된 라이브러리가 포함되어 모듈을 생성합니다.

 

그 상태로 Application에서 A, B, C 모듈을 가져다가 사용하고 빌드를 하면 빌드 시간도 오래 걸리고, 사이즈도 커지는 것입니다.

 

이제 모듈의 사이즈를 줄이기 위해 A, B, C의 package.json을 다음과 같이 수정하였습니다.

// Micro Service A, Micro Service B, Micro Service C
// package.json
{
  ...
  "peerDependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "yarn": "^1.22.19",
    "@types/react": "^18.0.28",
    "@types/react-dom": "^18.0.11",
    "@typescript-eslint/eslint-plugin": "^5.57.1",
    "@typescript-eslint/parser": "^5.57.1",
    "@vitejs/plugin-react": "^4.0.0",
    "eslint": "^8.38.0",
    "eslint-plugin-react-hooks": "^4.6.0",
    "eslint-plugin-react-refresh": "^0.3.4",
    "typescript": "^5.0.2",
    "vite": "^4.3.2"
  },
  "devDependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "yarn": "^1.22.19",
    "@types/react": "^18.0.28",
    "@types/react-dom": "^18.0.11",
    "@typescript-eslint/eslint-plugin": "^5.57.1",
    "@typescript-eslint/parser": "^5.57.1",
    "@vitejs/plugin-react": "^4.0.0",
    "eslint": "^8.38.0",
    "eslint-plugin-react-hooks": "^4.6.0",
    "eslint-plugin-react-refresh": "^0.3.4",
    "typescript": "^5.0.2",
    "vite": "^4.3.2"
  }
}

 

왜 peerDependencies와 devDependencies 모두 중복되게 수정을 했을까요?

그 이유는 다음과 같습니다.

• peerDependencies
  • npm이나 yarn을 사용하여 패키지를 설치할 때 자동으로 설치되지 않습니다. 대신, 해당 패키지를 사용하는 프로젝트에서 직접 설치해야 합니다. peerDependencies의 주요 목적은 특정 버전의 패키지가 프로젝트에 이미 존재해야 함을 보장하는 것입니다.
• devDependencies
  • 해당 모듈을 개발하기 위해 필요합니다. peerDependencies에만 작성한다고 해서 설치되는 것이 아니기 때문에 devDependencies에도 작성을 해야 합니다.

자, 이제 빌드를 하면 A, B, C 모듈 사이즈는 줄어들었을 것이고, Application에서 A, B, C를 설치 및 빌드 시간이 대폭 줄어든 것을 알 수 있습니다.

 

마무리

저처럼 런타임에 통합되는 Application이 하나인 MFE 구조에서는 의존성 관계를 잘 파악하며 개발을 진행해야 합니다.

 

 

끗!