프론트엔드 마이크로 프론트엔드 라우터: 애플리케이션 간 내비게이션

현대 웹 개발에서 마이크로 프론트엔드 아키텍처는 크고 복잡한 애플리케이션을 구축하는 방식으로 상당한 주목을 받고 있습니다. 이는 모놀리식 프론트엔드를 더 작고, 독립적이며, 배포 가능한 단위(마이크로 프론트엔드)로 나누는 것을 포함합니다. 이 아키텍처의 핵심 과제 중 하나는 사용자가 이러한 독립적인 마이크로 프론트엔드 간에 원활하게 이동할 수 있도록 하는 애플리케이션 간 내비게이션을 관리하는 것입니다. 이 글은 프론트엔드 마이크로 프론트엔드 라우팅 및 애플리케이션 간 내비게이션에 대한 포괄적인 가이드를 제공합니다.

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

마이크로 프론트엔드는 독립적으로 제공 가능한 프론트엔드 애플리케이션들이 단일하고 응집력 있는 사용자 경험으로 구성되는 아키텍처 스타일입니다. 이는 백엔드의 마이크로서비스와 유사합니다. 각 마이크로 프론트엔드는 일반적으로 별도의 팀이 소유하여 더 큰 자율성, 더 빠른 개발 주기, 그리고 더 쉬운 유지보수를 가능하게 합니다. 마이크로 프론트엔드의 이점은 다음과 같습니다:

• 독립적인 배포: 팀은 애플리케이션의 다른 부분에 영향을 주지 않고 마이크로 프론트엔드를 배포할 수 있습니다.
• 기술 다양성: 서로 다른 마이크로 프론트엔드를 다른 기술을 사용하여 구축할 수 있어, 팀이 작업에 가장 적합한 도구를 선택할 수 있습니다. 예를 들어, 한 팀은 React를 사용하는 반면 다른 팀은 Vue.js나 Angular를 사용할 수 있습니다.
• 확장성: 각 마이크로 프론트엔드를 독립적으로 확장할 수 있으므로 애플리케이션을 더 쉽게 확장할 수 있습니다.
• 유지보수성 향상: 코드베이스가 작을수록 이해하고 유지보수하기가 더 쉽습니다.
• 팀 자율성: 팀은 자체 코드와 개발 프로세스에 대해 더 많은 통제권을 갖습니다.

마이크로 프론트엔드 라우터의 필요성

잘 정의된 라우팅 전략이 없으면 사용자는 마이크로 프론트엔드 간을 이동할 때 단절되고 실망스러운 경험을 하게 됩니다. 마이크로 프론트엔드 라우터는 전체 애플리케이션에 걸쳐 내비게이션을 관리하기 위한 중앙 집중식 메커니즘을 제공하여 이 문제를 해결합니다. 여기에는 다음 사항 처리가 포함됩니다:

• URL 관리: URL이 사용자의 현재 애플리케이션 내 위치를 정확하게 반영하도록 보장합니다.
• 상태 관리: 필요한 경우 마이크로 프론트엔드 간에 상태를 공유합니다.
• 지연 로딩: 성능 향상을 위해 필요할 때만 마이크로 프론트엔드를 로드합니다.
• 인증 및 인가: 여러 마이크로 프론트엔드에 걸쳐 사용자 인증 및 인가를 처리합니다.

애플리케이션 간 내비게이션 전략

마이크로 프론트엔드 아키텍처에서 애플리케이션 간 내비게이션을 구현하는 데는 여러 가지 접근 방식이 있습니다. 각 접근 방식에는 고유한 장단점이 있으며, 최상의 선택은 애플리케이션의 특정 요구 사항에 따라 달라집니다.

1. 중앙 집중식 라우터 사용 (Single-Spa)

Single-Spa는 마이크로 프론트엔드를 구축하기 위한 인기 있는 프레임워크입니다. 중앙 집중식 라우터를 사용하여 다른 애플리케이션 간의 내비게이션을 관리합니다. 메인 애플리케이션은 오케스트레이터 역할을 하며 현재 URL을 기반으로 마이크로 프론트엔드를 렌더링하고 마운트 해제하는 역할을 합니다.

작동 방식:

1. 사용자가 특정 URL로 이동합니다.
2. single-spa 라우터가 URL 변경을 가로챕니다.
3. URL을 기반으로 라우터는 어떤 마이크로 프론트엔드가 활성화되어야 하는지 결정합니다.
4. 라우터는 해당 마이크로 프론트엔드를 활성화하고 다른 활성 마이크로 프론트엔드를 마운트 해제합니다.

예제 (Single-Spa):

home, products, cart라는 세 개의 마이크로 프론트엔드가 있다고 가정해 봅시다. single-spa 라우터는 다음과 같이 구성됩니다:

import { registerApplication, start } from 'single-spa'; registerApplication( 'home', () => import('./home/home.app.js'), location => location.pathname === '/' ); registerApplication( 'products', () => import('./products/products.app.js'), location => location.pathname.startsWith('/products') ); registerApplication( 'cart', () => import('./cart/cart.app.js'), location => location.pathname.startsWith('/cart') ); start();

이 예제에서 각 마이크로 프론트엔드는 single-spa에 등록되며, URL을 기반으로 언제 마이크로 프론트엔드가 활성화되어야 하는지를 결정하는 함수가 제공됩니다. 사용자가 /products로 이동하면 products 마이크로 프론트엔드가 활성화됩니다.

장점:

• 라우팅에 대한 중앙 집중식 제어.
• 단순화된 상태 관리 (single-spa 오케스트레이터가 처리 가능).
• 기존 애플리케이션과 쉽게 통합 가능.

단점:

• 단일 실패 지점. 오케스트레이터가 다운되면 전체 애플리케이션이 영향을 받습니다.
• 효율적으로 구현되지 않으면 성능 병목 현상이 발생할 수 있습니다.

2. 모듈 페더레이션 (Webpack 5)

Webpack 5의 모듈 페더레이션(Module Federation)을 사용하면 런타임에 다른 Webpack 빌드 간에 코드를 공유할 수 있습니다. 즉, 한 빌드(호스트)에서 다른 빌드(리모트)로 컴포넌트, 모듈 또는 전체 애플리케이션을 노출할 수 있습니다. 이는 각 마이크로 프론트엔드가 별도의 Webpack 빌드인 마이크로 프론트엔드를 구축하는 데 용이합니다.

작동 방식:

1. 각 마이크로 프론트엔드는 별도의 Webpack 프로젝트로 빌드됩니다.
2. 하나의 마이크로 프론트엔드가 호스트 애플리케이션으로 지정됩니다.
3. 호스트 애플리케이션은 리모트 마이크로 프론트엔드에서 소비하려는 모듈을 정의합니다.
4. 리모트 마이크로 프론트엔드는 호스트 애플리케이션에 노출하려는 모듈을 정의합니다.
5. 런타임에 호스트 애플리케이션은 필요에 따라 리모트 마이크로 프론트엔드에서 노출된 모듈을 로드합니다.

예제 (모듈 페더레이션):

host 앱과 remote 앱이 있다고 가정합니다.

host/webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container; module.exports = { // ... plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { remote: 'remote@http://localhost:3001/remoteEntry.js', }, shared: ['react', 'react-dom'], }), ], };

remote/webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container; module.exports = { // ... plugins: [ new ModuleFederationPlugin({ name: 'remote', exposes: { './Button': './src/Button', }, shared: ['react', 'react-dom'], }), ], };

이 예제에서 host 애플리케이션은 remote 애플리케이션의 Button 컴포넌트를 사용합니다. shared 옵션은 두 애플리케이션이 동일한 버전의 react와 react-dom을 사용하도록 보장합니다.

장점:

• 분산형 아키텍처. 각 마이크로 프론트엔드는 독립적이며 별도로 개발 및 배포될 수 있습니다.
• 코드 공유. 모듈 페더레이션을 사용하면 런타임에 다른 애플리케이션 간에 코드를 공유할 수 있습니다.
• 지연 로딩. 모듈은 필요할 때만 로드되어 성능을 향상시킵니다.

단점:

• single-spa보다 설정 및 구성이 더 복잡합니다.
• 버전 충돌을 피하기 위해 공유 종속성을 신중하게 관리해야 합니다.

3. 웹 컴포넌트

웹 컴포넌트(Web Components)는 재사용 가능한 맞춤형 HTML 요소를 만들 수 있게 해주는 웹 표준 집합입니다. 이러한 컴포넌트는 사용된 프레임워크에 관계없이 모든 웹 애플리케이션에서 사용할 수 있습니다. 이는 UI 컴포넌트를 구축하고 공유하는 기술에 구애받지 않는 방법을 제공하므로 마이크로 프론트엔드 아키텍처에 자연스럽게 부합합니다.

작동 방식:

1. 각 마이크로 프론트엔드는 UI를 웹 컴포넌트 집합으로 노출합니다.
2. 메인 애플리케이션(또는 다른 마이크로 프론트엔드)은 이러한 웹 컴포넌트를 가져와 HTML에서 사용함으로써 소비합니다.
3. 웹 컴포넌트는 자체 렌더링 및 로직을 처리합니다.

예제 (웹 컴포넌트):

micro-frontend-a.js:

class MyComponent extends HTMLElement { constructor() { super(); this.attachShadow({ mode: 'open' }); this.shadowRoot.innerHTML = `

Hello from Micro-Frontend A!

`; } } customElements.define('micro-frontend-a', MyComponent);

index.html (메인 애플리케이션):

Main Application

이 예제에서 micro-frontend-a.js 파일은 micro-frontend-a라는 웹 컴포넌트를 정의합니다. index.html 파일은 이 파일을 가져와 HTML에서 웹 컴포넌트를 사용합니다. 브라우저는 웹 컴포넌트를 렌더링하여 "Hello from Micro-Frontend A!"를 표시합니다.

장점:

• 기술에 구애받지 않음. 웹 컴포넌트는 어떤 프레임워크와 함께 사용하거나 프레임워크 없이도 사용할 수 있습니다.
• 재사용성. 웹 컴포넌트는 다른 애플리케이션에서 쉽게 재사용할 수 있습니다.
• 캡슐화. 웹 컴포넌트는 자체 스타일과 로직을 캡슐화하여 애플리케이션의 다른 부분과의 충돌을 방지합니다.

단점:

• 다른 접근 방식보다 구현이 더 장황할 수 있습니다.
• 오래된 브라우저를 지원하기 위해 폴리필(polyfill)이 필요할 수 있습니다.

4. Iframe

Iframe(인라인 프레임)은 마이크로 프론트엔드를 격리하기 위한 오래되었지만 여전히 실행 가능한 옵션입니다. 각 마이크로 프론트엔드는 자체 iframe 내에서 실행되어 높은 수준의 격리를 제공합니다. Iframe 간의 통신은 postMessage API를 사용하여 달성할 수 있습니다.

작동 방식:

1. 각 마이크로 프론트엔드는 별도의 웹 애플리케이션으로 배포됩니다.
2. 메인 애플리케이션은 각 마이크로 프론트엔드를 iframe에 포함합니다.
3. 메인 애플리케이션과 마이크로 프론트엔드 간의 통신은 postMessage API를 사용하여 수행됩니다.

예제 (Iframes):

index.html (메인 애플리케이션):

Main Application

이 예제에서 index.html 파일은 두 개의 iframe을 포함하며, 각각 다른 마이크로 프론트엔드를 가리킵니다.

장점:

• 높은 수준의 격리. 마이크로 프론트엔드는 서로 완전히 격리되어 충돌을 방지합니다.
• 구현 용이성. Iframe은 간단하고 잘 알려진 기술입니다.

단점:

• iframe 간의 통신이 어려울 수 있습니다.
• 여러 iframe의 오버헤드로 인해 성능 문제가 발생할 수 있습니다.
• 원활한 통합 부족으로 인해 사용자 경험이 저하될 수 있습니다.

마이크로 프론트엔드 간 상태 관리

마이크로 프론트엔드 간의 상태 관리는 애플리케이션 간 내비게이션의 중요한 측면입니다. 여러 전략을 사용할 수 있습니다:

• URL 기반 상태: 상태를 URL 내에 인코딩합니다. 이 접근 방식은 애플리케이션 상태를 URL을 통해 공유할 수 있고 쉽게 북마크할 수 있게 만듭니다.
• 중앙 집중식 상태 관리 (Redux, Vuex): 전역 상태 관리 라이브러리를 사용하여 마이크로 프론트엔드 간에 상태를 공유합니다. 이는 공유 상태가 많은 복잡한 애플리케이션에 특히 유용합니다.
• 커스텀 이벤트: 커스텀 이벤트를 사용하여 마이크로 프론트엔드 간에 상태 변경을 통신합니다. 이 접근 방식은 마이크로 프론트엔드 간의 느슨한 결합을 가능하게 합니다.
• 브라우저 저장소 (LocalStorage, SessionStorage): 브라우저 저장소에 상태를 저장합니다. 이 접근 방식은 모든 마이크로 프론트엔드에서 공유할 필요가 없는 간단한 상태에 적합합니다. 그러나 민감한 데이터를 저장할 때는 보안 고려 사항에 유의해야 합니다.

인증 및 인가

인증 및 인가는 모든 웹 애플리케이션의 중요한 측면이며, 마이크로 프론트엔드 아키텍처에서는 더욱 중요해집니다. 일반적인 접근 방식은 다음과 같습니다:

• 중앙 집중식 인증 서비스: 전용 서비스가 사용자 인증을 처리하고 토큰(예: JWT)을 발급합니다. 그런 다음 마이크로 프론트엔드는 이러한 토큰을 검증하여 사용자 인가를 결정할 수 있습니다.
• 공유 인증 모듈: 공유 모듈이 인증 로직을 처리하는 역할을 합니다. 이 모듈은 모든 마이크로 프론트엔드에서 사용할 수 있습니다.
• 에지 인증: 인증은 네트워크의 에지(예: 리버스 프록시 또는 API 게이트웨이 사용)에서 처리됩니다. 이 접근 방식은 마이크로 프론트엔드의 인증 로직을 단순화할 수 있습니다.

마이크로 프론트엔드 라우팅 모범 사례

마이크로 프론트엔드 라우팅을 구현할 때 명심해야 할 몇 가지 모범 사례는 다음과 같습니다:

• 단순하게 유지하기: 필요에 맞는 가장 간단한 라우팅 전략을 선택하십시오.
• 마이크로 프론트엔드 분리: 독립적인 개발 및 배포를 촉진하기 위해 마이크로 프론트엔드 간의 종속성을 최소화하십시오.
• 일관된 URL 구조 사용: 사용자 경험과 SEO를 개선하기 위해 모든 마이크로 프론트엔드에서 일관된 URL 구조를 유지하십시오.
• 지연 로딩 구현: 성능 향상을 위해 필요할 때만 마이크로 프론트엔드를 로드하십시오.
• 성능 모니터링: 마이크로 프론트엔드 애플리케이션의 성능을 정기적으로 모니터링하여 병목 현상을 식별하고 해결하십시오.
• 명확한 커뮤니케이션 채널 구축: 서로 다른 마이크로 프론트엔드에서 작업하는 팀이 개발 노력을 조정하고 통합 문제를 해결할 수 있도록 명확한 커뮤니케이션 채널을 확보하십시오.
• 견고한 오류 처리 구현: 개별 마이크로 프론트엔드의 실패를 정상적으로 처리하고 전체 애플리케이션에 영향을 미치지 않도록 견고한 오류 처리를 구현하십시오.
• 자동화된 테스트: 단위 테스트, 통합 테스트, 엔드투엔드 테스트를 포함한 포괄적인 자동화 테스트를 구현하여 마이크로 프론트엔드 애플리케이션의 품질과 안정성을 보장하십시오.

결론

마이크로 프론트엔드 라우팅은 복잡하지만 확장 가능하고 유지보수하기 쉬운 웹 애플리케이션을 구축하는 데 필수적인 측면입니다. 이 글에서 설명한 다양한 라우팅 전략과 모범 사례를 신중하게 고려함으로써 사용자를 위한 원활하고 사용자 친화적인 경험을 만들 수 있습니다. Single-Spa와 같은 중앙 집중식 라우터, 모듈 페더레이션, 웹 컴포넌트, 또는 Iframe 등 올바른 접근 방식을 선택하는 것은 특정 요구 사항과 우선순위에 따라 달라집니다. 분리, 일관된 URL 구조 및 성능 최적화를 우선시하는 것을 기억하십시오. 잘 설계된 라우팅 전략을 구현함으로써 마이크로 프론트엔드 아키텍처의 잠재력을 최대한 발휘하고 전 세계 사용자를 위한 진정으로 뛰어난 웹 애플리케이션을 구축할 수 있습니다.