마이크로 프론트엔드는 하나의 웹 앱을 여러 독립적인 프론트엔드 애플리케이션으로 분리하여, 각 팀이 독립적으로 개발하고 배포할 수 있게 하는 아키텍처입니다.

면접에서 "마이크로 프론트엔드를 알고 있나요?"라고 물으면, 장단점과 적용 기준 을 명확히 설명할 수 있어야 합니다. 모든 프로젝트에 적합한 것은 아닙니다.


왜 마이크로 프론트엔드인가?

PLAINTEXT
모놀리식 프론트엔드의 문제:
- 코드베이스 커지면 빌드/배포 시간 증가
- 팀 간 코드 충돌 빈번
- 기술 스택 변경이 어려움 (전체 교체 필요)
- 한 팀의 장애가 전체에 영향

마이크로 프론트엔드로 해결:
- 팀별 독립 배포
- 기술 스택 자유 (Vue, React 혼용 가능)
- 장애 격리
- 점진적 마이그레이션 가능

구현 방식

1. Module Federation (Webpack 5 / Vite)

TYPESCRIPT
// vite.config.ts — host (shell) 앱
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    vue(),
    federation({
      name: 'host',
      remotes: {
        // 원격 앱에서 컴포넌트를 가져옴
        productApp: 'http://localhost:3001/assets/remoteEntry.js',
        cartApp: 'http://localhost:3002/assets/remoteEntry.js'
      },
      shared: ['vue', 'pinia']  // 공유 의존성
    })
  ]
})
TYPESCRIPT
// vite.config.ts — remote (상품) 앱
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    vue(),
    federation({
      name: 'productApp',
      filename: 'remoteEntry.js',
      exposes: {
        // 외부에 공개할 컴포넌트
        './ProductList': './src/components/ProductList.vue',
        './ProductDetail': './src/components/ProductDetail.vue'
      },
      shared: ['vue', 'pinia']
    })
  ]
})
VUE
<!-- host 앱에서 원격 컴포넌트 사용 -->
<script setup lang="ts">
import { defineAsyncComponent } from 'vue'

const RemoteProductList = defineAsyncComponent(() =>
  import('productApp/ProductList')
)
</script>

<template>
  <RemoteProductList @select="handleSelect" />
</template>

2. Web Components 기반

TYPESCRIPT
// Vue 컴포넌트를 Web Component로 변환
import { defineCustomElement } from 'vue'
import ProductCard from './ProductCard.vue'

const ProductCardElement = defineCustomElement(ProductCard)
customElements.define('product-card', ProductCardElement)

// 어떤 프레임워크에서든 사용 가능
// <product-card title="상품명" price="10000"></product-card>

3. iframe 기반

VUE
<template>
  <!-- 가장 단순하지만 제한적 -->
  <iframe src="http://product-app.example.com" />
</template>

앱 간 통신

TYPESCRIPT
// 1. Custom Events (느슨한 결합)
// 앱 A에서 이벤트 발행
window.dispatchEvent(new CustomEvent('cart:add', {
  detail: { productId: 123, quantity: 1 }
}))

// 앱 B에서 이벤트 수신
window.addEventListener('cart:add', (e: CustomEvent) => {
  console.log('상품 추가:', e.detail)
})

// 2. 공유 상태 (localStorage + BroadcastChannel)
const channel = new BroadcastChannel('app-state')
channel.postMessage({ type: 'USER_LOGIN', payload: user })
channel.onmessage = (event) => {
  console.log('상태 변경:', event.data)
}

언제 마이크로 프론트엔드를 도입해야 하나?

PLAINTEXT
도입이 적합한 경우:
✓ 10명 이상의 프론트엔드 개발자
✓ 독립적인 제품 팀 (팀별 배포 주기가 다름)
✓ 레거시 마이그레이션 (점진적 전환)

도입이 부적합한 경우:
✗ 소규모 팀 (1-5명)
✗ 단일 제품, 단일 팀
✗ 초기 스타트업 (오버엔지니어링)

면접 팁

  • 마이크로 프론트엔드의 복잡성 비용 을 함께 설명하세요 — 빌드, 배포, 의존성 관리, 통신, 스타일 충돌 등
  • "모든 프로젝트에 필요한 것은 아니다"라는 현실적인 판단을 보여주면 좋습니다
  • Module Federation의 shared 의존성 설정이 왜 중요한지 설명할 수 있어야 합니다

요약

마이크로 프론트엔드는 대규모 팀에서 독립 배포와 기술 스택 자유를 제공하는 아키텍처입니다. Module Federation, Web Components, iframe 등의 구현 방식이 있으며, 복잡성 비용을 고려하여 팀 규모와 프로젝트 상황에 맞게 도입 여부를 판단해야 합니다.

댓글 로딩 중...