마이크로프론트엔드의 모든 것: 장단점, 도입 시기, 그리고 구현 방법

안녕하세요! F-Lab에서 멘토를 맡고 있는 플랫폼 기업에서 근무하는 프론트엔드 시니어 개발자 Gotama 입니다!

개요

예전의 웹사이트는 단순 정보 제공이나 간단한 상호작용에 그쳤다면, 현대의 웹애플리케이션은 복잡하고 다양한 기능을 제공합니다. 이러한 변화로 프론트엔드 프로젝트의 복잡성이 증가하면서 새로운 아키텍처의 필요성이 대두되었는데요. 이에 대한 해결책으로 등장한 것이 마이크로프론트엔드 아키텍처(MFA)입니다. MFA는 대규모 프론트엔드 애플리케이션을 더 작고 독립적인 단위로 분할하여 각각을 개발, 테스트, 배포 할 수 있게 하는 접근 방식입니다.
 

기존 모놀리식 시스템의 문제점

대부분의 프로젝트 에서 사용하는 모놀리식 시스템은 모든 구성 요소가 단일코드베이스에 통합된 전통적인 아키텍처 방식입니다. 이 접근법은 초기 개발 단계에서는 간단하고 직관적일 수 있지만, 프로젝트 규모가 커지고 복잡해짐에 따라 여러 문제점을 드러냅니다.

 

• 중복 개발 : 프로젝트가 커질수록 비슷한 기능이나 컴포넌트가 여러 부분에서 중복 구현되는 경우가 많아집니다.

 

• 업무 결합도 증가 : 프로젝트가 커질수록 하나의 팀이 아닌 다양한 팀이 하나의 코드베이스를 공유하게 되어 의존성 및 복잡성이 증가합니다. 또 팀 간 협업 과정에서 충돌과 병목 현상이 발생합니다.

 

• 응집도 낮음 : 다양한 기능이 하나의 애플리케이션에 있다보니응집도가 떨어집니다. 특정 기능을 수정하거나 확장할 때 전체 시스템에 대한 이해가 필요하여 코드 품질 관리가 복잡해집니다.

 

• 장애파급범위 : 시스템의 한 부분에서 발생한 문제가 전체 애플리케이션에 영향을 미칠 수 있습니다. 문제 발생 시 근본 원인을 찾아 해결하는데 비교적 많은 시간과 노력이 필요합니다.

 

• 배포시간지연 : 전체 애플리케이션을 한 번에 빌드하고 배포해야 하므로 시간이 오래 걸립니다. 작은 변경사항에도 전체 애플리케이션을 다시 배포해야하는 비효율또한 발생합니다.

기존 프로젝트가 커져서 위와같은 문제점이 발생한다면 MFA와 같은 아키텍처 도입을 검토해야 할 시점이라고 할 수 있습니다.
 

MFA 도입을 위한 검토

MFA 도입 검토는 시스템의 복잡성, 팀 구조 그리고 비즈니스 요구사항을 종합적으로 고려하는 과정입니다. 주요 검토 사항은 다음과 같습니다.
 

 

• 적절한 규모의 팀과 서비스 : 단순한 웹사이트 보다는 어느정도 복잡한 웹 애플리케이션에 적합합니다. 여러 개의 독립적인 기능 영역이 있는 대규모 앱에 적합합니다.

 

• 기능적으로 마이크로 앱으로 분해가 가능한 경우 : 도메인 주도 설계(DDD)원칙을 적용하여 비즈니스 도메인별로 분리가 가능한지 검토합니다. 각 마이크로앱이 독립적으로 가치를 제공하고 의존성을 최소화 할 수 있는 구조인지 확인합니다.

 

• URL 기반 기능 구분 : 주요 기능이 고유한 URL 경로를 가질수 있는지 검토합니다. 마이크로앱 간의 라우팅과 통합을 용이하게 하고 사용자 관점에서 자연스러운 네비게이션 흐름을 제공할 수 있습니다.

 

• 각 서비스와 팀의 책임이 명확히 구분되는 경우 : 조직 구조와 아키텍처를 일치시켜 각 팀이 특정 비즈니스 도메인이나 기능에 대해 end-to-end 책임을 질 수 있습니다.

 

• 독립적인 인프라 구성이 가능한 경우 : 각 마이크로앱을 위한 별도의 CI/CD 파이프라인을 구축할수 있어야 합니다. 독립적인 배포와 스케일링이 가능한 인프라 구조를 통해 공통 서비스를 공유하면서도 개발 마이크로앱의 독립성을 유지합니다.

 

• 코드 수정의 영향 범위 : 작은 변경이 예상치 못한 부작용을 일으킨다면 MFA를 고려합니다. 새로운 기능 추가가 어려운 경우 MFA가 해결책이 될 수 있습니다.

 

• 증가하는 커뮤니케이션 비용과 배포 시간 : 팀 간 조율에 많은 시간이 소요되어 개발 속도가 저하되면 MFA를 고려해 볼 수 있습니다. 전체 앱의 빌드, 테스트, 배포 시간이 지나치게 길어진 경우에 MFA를 통해 개선할 수 있습니다.

MFA 도입의 적절성과 잠재적 이점은 여러 요소를 종합적으로 평가하여 판단할 수 있습니다. 프로젝트의 규모, 복잡성, 팀 구조, 기술적 요구사항 등 앞서 언급한 요소들 중 다수가 해당될 때, MFA 도입을 고려해볼 만합니다.

 

마이크로프론트엔드(MFA)의 장점과 단점

완벽한 아키텍처는 존재하지 않습니다. MFA역시 장점과 단점을 모두 가지고 있는데요. 장점과 단점을 구체적으로 살펴보고, 웹 개발 프로세스에 어떤 영향을 미치는지 분석해보도록 하겠습니다.
 

장점

 

• 업무 결합도 감소 : 각 팀이 독립적으로 개발, 테스트, 배포할 수 있어 팀 간 의존성이 줄어듭니다. 코드베이스가 작고 집중되어 있어 개발자가 전체 시스템을 이해하지 않아도 효과적으로 작업할 수 있습니다.

 

• 컴포넌트 재사용성 증가 : 공통 컴포넌트 라이브러리를 만들어 여러 마이크로프론트엔드에서 재사용 할 수 있습니다. 일관된 UI 를 유지하고 개발 시간을 단축할 수 있습니다.

 

• 배포 단위 분할 : 각 마이크로프론트엔드를 독립적으로 배포할 수 있어 배포 주기가 빨라집니다. 특정 기능을 업데이트하고 싶을때 전에 애플리케이션을 배포할 필요가 없습니다.

 

• 장애 파급 범위 축소 : 마이크로 앱 단위로 개별적으로 개발 하고 부분 배포하기 때문에 장애 파급 범위가 비교적 낮습니다. 모든 시스템이 다운되는 현상을 방지할 수 있어 전반적인 안정성과 가용성을 향상시킵니다.

 

• 낮은 커뮤니케이션 비용 : 팀별로 각각의 마이크로앱을 개발할 수 있기 때문에 자율성이 높고 불필요한 회이의나 조율 과정이 줄어들어 커뮤니케이션 비용이 낮습니다. 책임과 권한이 명확해서 의사결정 과정이 간소화됩니다.

 

• 빠른 개발 주기 : 각팀이 독립적으로 병렬로 작업을 할 수 있기 때문에 개발 주기가 빨라질 수 있습니다. 새로운 기능을 빠르게 프로토타이핑하고 테스트 할 수 있어 비즈니스 경쟁력이 향상됩니다.

단점

 

• 운영 복잡도 증가 : 여러 개의 독립된 애플리케이션을 관리해야 해서 운영 복잡도가 증가합니다. 각 마이크로앱 마다 CI/CD 파이프라인을 구축해야하며, 또 런타임에 동적으로 통합하는 과정에서 문제가 발생할 수 있습니다.

 

• 초기 구축 비용 증가 : 각 마이크로 프론트엔드 간 통합과 상태관리, 라우팅 등을 처리하기 위해 추가적인 시간과 노력이 필요합니다. 이로인해 초기개발 속도가 느립니다.

 

• 빌드/배포, 개발환경 설정의 복잡성 : 여러 앱 간의 빌드 설정이 필요하며, 이들을 통합하는 과정이 복잡할 수 있습니다. 또 여러 마이크로앱을 동시에 실행하고 디버깅하는 것이 까다로울 수 있습니다.

 

• 보안 관리의 복잡성 : 여러 개의 독립된 애플리케이션으로 인해 보안 취약점이 증가할 수 있습니다.

MFA아키텍처는 복잡성과 큰 규모에 대응하기에는 적합한 방식입니다. 업무 결합도 감소, 배포 유연성 향상, 장애 파급 범위 축소 등의 장점을 통해 대규모 프로젝트의 효율성과 유연성을 크게 개선할 수 있습니다. 그러나 운영 복잡도 증가, 초기 구축비용 상승 등의 단점도 존재합니다. 따라서 프로젝트의 규모와 비즈니스 요구사항 등을 종합적으로 평가해야 합니다.

 

MFA와 모노레포

모노레포는 여러 프로젝트나 패키지를 단일 저장소에서 관리하는 개발 전략입니다. MFA의 맥락에서는 여러개의 프로젝트(마이크로앱)이 모여 하나의 앱을 만들기 때문에 여러 프로젝트가 필요하고, 이 프로젝트들은 잘 정의된 관계를 가지고 있습니다. 따라서 이런 경우 모노레포를 사용하면 아래와 같은 장점이 있습니다.
 

 

• 코드 공유와 재사용 : 공통 컴포넌트, 유틸리티 함수 등을 별도의 패키지로 분리하여 여러 마이크로 앱에서 쉽게 재사용 할 수 있어, 코드 중복을 줄이고 일관성을 유지할 수 있습니다.

 

• 패키지간 의존 관계를 명확히 가지고 있음 : 의존 관계가 명확히 정의하고 관리하여 버전 충돌 문제를 줄이고, 의존성 업데이트를 더 쉽게 할 수 있습니다.

 

• 변경 영향도 분석 : 특정 패키지 변경이 어떤 마이크로 앱에 영향을 미치는지 쉽게 파악할 수 있어 리팩토링이나 기능 변경시 리스크를 관리하는 데 도움이 됩니다.

 

• 프로젝트 생성 및 관리의 효율성 : 새로운 마이크로앱이나 라이브러리르 추가하는 과정을 간소화 할 수 있습니다.

 

• 각 프로젝트마다 일관된 설정과 DX 향상 : 모든 프로젝트에 일관된 개발 환경과 도수를 제공하여 생산성을 높이고 context switching 비용을 줄입니다.

MFA와 모노레포는 서로 독립적인 개념이니지만, 함께 사용될 때 더 큰 시너지를 낼 수 있습니다. MFA에서 모노레포는 필수 구현 사항은 아니지만, MFA의 복잡성을 관리하고 개발 효율성을 높이는 여러 장점을 줄 수 있습니다. 또한 모노레포툴 (Ex.: Turborepo, NX)을 이용하면 모노레포 관리를 더욱 효율적으로 할 수 있는데요. 캐싱을 통해 중복 작업을 줄이고, 병렬 실행을 통해 전체 빌드 시간을 단축할 수 있습니다. 따라서 모노레포 빌드툴 없이 모노레포를 운영할수는 있지만, 빌드툴을 사용하면 모노레포를 효율적으로 관리할 수 있습니다.

 

MFA 아키텍처의 통합 방식

마이크로프론트엔드 아키텍처(MFA)를 구현할 때 가장 중요한 과제 중 하나는 여러 독립적인 프론트엔드 모듈을 효과적으로 통합하는 것입니다. 이를 위해 다양한 통합 방식이 존재하며, 각각의 장단점이 있습니다. 주요 통합 방식들은iFrame 방식, 웹 컴포넌트, 서버 사이드 통합, 런타임 통합, 빌드 타임 통합 등 다양한 방식이 있는데요.
 

이 중에서 최근 주목받고 있는 방식은 Webpack 5에서 제공하는 Module Federation입니다. Module Federation은 런타임 통합 방식의 일종으로, 다음과 같은 이유로 MFA 구현의 강력한 도구로 인정받고 있습니다:
 

 

1. 동적 로딩 : 필요한 모듈을 런타임에 동적으로 로드할 수 있어 배포된 코드의 변경 사항이 실시간으로 반영 됩니다.
    
2. 유연한 설정 : webpack.config.js 파일을 통해 어떤 모듈을 공유할지, 어떤 모듈을 가져올시 비교적 손쉽게 설정할 수 있습니다.
    
3. 독립적 개발과 배포 : 런타임 통합으로 인한 각 서비스의 개별적인 배포와 동적 로딩이 가능합니다. 이를 통해 개발 속도와 유연성이 향상됩니다.

모듈 통합을 위한 웹팩의 Module Federation

Webpack의 Module Federation은 여러 자바스크립트 애플리케이션에서 코드를 동적으로 공유할 수 있는 기능입니다. 여러 자바스크립트 애플리케이션 코드를 동적으로 런타임에 공유하여 MFA 구현을 위한 ‘컴파일 타임’ 종속성을 ‘런타임’ 종속성으로 변환합니다. 

webpack.config.js 파일에서 expose를 통해 다른 애플리케이션에 노출할 모듈을 지정하고, remote를 통해 다른 애플리케이션에 가져올 모듈을 지정하는 식으로 사용합니다. 이렇게 설정하면 런타임에 원격 모듈을 비동기적으로 로드하여, 각 마이크로 앱은 독립적인 빌드 프로세스를 가지면서도, 배포 후에는 동적으로 통합 됩니다.

 
이를 통해 코드 분할과 지연 로딩을 통한 성능 최적화와 독립적인 개발 및 배포로 인한 각 팀의 자율성 증가, 런타임 통합으로 인한 유연한 아키텍처 구현이 가능합니다.

따라서 Module Federation은 MFA를 구현하는 데 있어 중요한 도구입니다. 이를 통해 각 개발 팀은 독립성과 유연성을 유지하면서도 효율적으로 협업할 수 있으며, 최종 사용자에게는 통합된 하나의 애플리케이션으로 보이는 경험을 제공할 수 있습니다.
 

Module Federation 핵심 개념

Module Federation의 세 가지 주요 구성 요소인 Host, Remote, Shared에 대해 상세히 살펴보도록 하겠습니다. 각 요소의 역할과 특징을 살펴보고, 어떻게 상호작용하여 MFA 를 구현하는지 알아봅니다.
 

Module Federation은 3가지 개념 Host, Remote, Shared로 구성됩니다.
 

 

• Host(Consumer)
  • 앱의 주요 진입점 역할을 하며, 다른 Remote모듈을 통합하고 관리합니다.
  • 전에 앱의 구조와 레이아웃을 정의합니다.
  • 전역 상태관리, 라우팅 로직, 인증 및 인가 처리를 합니다.
  • 동적 import()를 통해 Remote 모듀을 런타임에 로드합니다.

 

• Remote(Provider)
  • 독립적으로 개발, 테스트, 배포가 가능한 애플리케이션입니다.
  • Host에 의해 소비되는 모듈이나 컴포넌트를 제공합니다.
  • Remote를 통해 독립적인 개발 및 배포주기를 갖으며 팀 간 명확한 책임 분리가 가능합니다.
  • expost 옵션을 통해 공유할 모듈을 지정합니다.

 

• Shared
  • 마이크로 앱 간 공통적으로 사용하는 라이브러리가 번들링된 JS 마다 존재할수 있습니다. 따라서 Shared를 통해 의존성 중복 로딩을 방지하여 payload 크기가 커지는 현상을 방지합니다.
  • shared 옵션을 통해 공유할 라이브러리를 지정하면 라이브러리 중복 로딩을 방지합니다.

각 Host와 Remote는 독립적인 빌드 프로세스를 갖으며, 빌드 과정에서 원격 엔트리 파일이 생성되어 해당 앱이 노출하는 모듈에 대한 메니페스트 역할을 합니다. 이를 통해 Host 앱이 시작될 때, 필요한 Remote 모듈의 원격 엔트리 파일을 동적으로 로드하여, 필요한 시점에 Remote 모듈을 비동기적으로 import하여 사용합니다. 이를 통해 초기 로딩 시간을 최적화 할수 있습니다.

 

MFA구현에 필요한 개념 Application Shell

Application Shell은 MFA 구현에 중추적인 역할을 하는 메인 애플리케이션 입니다. 이 개념은 MFA 아키텍처를 효과적으로 구성하고 관리하는데 중요한 역할을 하는데요.
 

 

• Application Shell의 정의와 역할
  • MFA에서 중심적인 역할을 하는 메인 애플리케이션으로 여러 정보를 마이크로 앱에 전달합니다.
  • 전체 애플리케이션의 구조와 공통 기능을 제공합니다.
  • Module Federation에서 주로 Host 역할을 담당하며, 각각의 앱들이 Remote 역할을 맡게 됩니다. 이를 통해 런타임에 Shell과 각 마이크로앱들이 통합 됩니다.

 

• Application Shell의 주요 책임 : 
  • 라우팅 : 브라우저 URL을 해석하여 적절한 마이크로 앱으로 라우팅합니다.(예 : React-Router 사용)
  • 인증 및 인가 : 사용자 인증 상태 및 인증 토큰을 저장하고 갱신합니다. 각 마이크로 앱에 인증 정보를 제공합니다. 
  • 전역 상태 관리: 여러 마이크로앱에서 공유하는 상태를 관리합니다. 
  • 레이아웃 관리: 공통 UI요소(헤더, 푸터, 네비게이션)등을 관리하고 렌더링 합니다.

 

• 이벤트 시스템
  • Shell은 메인 이기 때문에 각 마이크로 앱이 필요한 정보(토큰등)을 가져다 쓸 수 있도록 이벤트 시스템을 구축합니다.
  • window의 dispatch 이벤트를 이용해 CustomEvent를 만듭니다. 비동기 이벤트 기반의 데이터 버스를 만들어 각 마이크로 앱간 느슨한 결합을 유지하면서 통신할 수 있습니다.

Application Shell은 MFA의 중요한 구성 요소로, 전체 애플리케이션의 일관성을 유지하면서도 각 마이크로 앱의 독립성을 보장하는 중요한 역할을 수행합니다.

 

결론

웹 애플리케이션의 복잡성이 증가함에 따라, 프론트엔드 개발 영역에서도 근본적인 해결책이 필요해졌습니다. 이러한 맥락에서 등장한 마이크로프론트엔드 아키텍처(MFA)는 백엔드의 마이크로서비스 아키텍처(MSA)에서 영감을 받아 발전한 패턴으로, 프론트엔드 개발의 새로운 아키텍처를 제시하고 있습니다.

MFA는 대규모 프론트엔드 애플리케이션을 독립적으로 개발, 테스트, 배포할 수 있는 더 작은 단위로 분해함으로써, 개발 팀의 자율성을 높이고 시스템의 유연성과 확장성을 크게 향상시킵니다. 이는 배포 단위의 세분화, 개발 생산성 개선, 장애 영향 범위 최소화 등 다양한 이점을 제공하는데요. 현재 MFA 생태계는 지속적으로 발전하고 있습니다. Webpack 외의 Vite 에서도 Module Federation을 플러그인이 아닌 자체 기능으로 지원을 예고 했습니다. 더 나아가 WebAssembly 같은 웹 표준과의 통합을 통해 더욱 강력한 솔루션이 탄생할 가능성도 있습니다.
 

그러나 모든 기술적 선택과 마찬가지로, MFA 도입에는 신중한 고려가 필요합니다. 팀의 규모, 프로젝트의 복잡성, 개발 문화 등 다양한 요소를 종합적으로 평가해야 합니다. MFA는 특히 서비스 규모가 크고, 각 팀이 독립적으로 기능을 개발하고 배포해야 하는 환경에서 그 진가를 발휘합니다.

결론적으로, MFA는 현대 웹 개발이 직면한 많은 도전과제들에 대한 효과적인 해결책이 될 수 있습니다. 물론 모든 상황에 적합한 만능 해결책은 아니지만, 적절한 환경에서 MFA는 개발 프로세스를 효율적으로 개선하고, 제품의 품질을 높이며, 비즈니스의 빠른 성장을 지원할 수 있는 도구입니다.

프론트엔드 개발의 미래는 더욱 모듈화되고, 유연해지며, 확장 가능한 방향으로 나아가고 있습니다. MFA는 이러한 흐름의 앞장서있으며, 앞으로도 웹 개발 생태계에 중요한 영향을 미칠 것으로 전망됩니다. 따라서 MFA에 대해 지속적인 관심을 가지고, 자신의 프로젝트에 적용할 수 있는 기회를 모색해 볼 필요가 있습니다. MFA가 제공하는 이점을 활용한다면, 더 효율적이고 유지보수가 용이한 대규모 웹 애플리케이션을 구축할 수 있기 때문입니다.