Micro Frontend Architecture, BFF, and Microservices — 실제 사례를 통해 쉽게 설명

Source: Dev.to

1️⃣ 전통적인 모놀리식 아키텍처가 실패하는 이유

❌ 모놀리식 아키텍처

In a monolith:

• Frontend + Backend are tightly coupled → 프론트엔드 + 백엔드가 긴밀하게 결합되어 있음
• One codebase → 단일 코드베이스
• One deployment → 단일 배포

One failure = entire app down → 하나의 실패 = 전체 앱 다운

[ UI ] → [ Backend ] → [ Database ]

문제점

• Slow deployments → 배포가 느림
• Hard to scale → 확장이 어려움
• One small bug can crash everything → 작은 버그 하나가 전체를 다운시킬 수 있음
• Large teams block each other → 대규모 팀이 서로를 방해함

👉 해결책

Break the system into smaller independent parts. → 시스템을 더 작고 독립적인 부분으로 나눕니다.

2️⃣ 마이크로서비스 아키텍처 (백엔드 레벨)

✅ 마이크로서비스란?

마이크로서비스는 백엔드를 작고 독립적인 서비스로 분할하며, 각 서비스는 자체 데이터와 로직을 소유합니다.

User Service     Order Service     Payment Service
     │                  │                 │
     └────── API Gateway / BFF ────────┘

예시: 전자상거래 앱

• 각 서비스는 자체 DB를 가집니다
• 독립적으로 배포할 수 있습니다
• 독립적으로 확장됩니다

🧠 간단한 예시 (Node.js)

// user-service/index.js
app.get('/users/:id', (req, res) => {
  res.json({ id: 1, name: 'Kamal' })
})

3️⃣ 아직 남아 있는 문제는?

마이크로서비스를 사용하더라도 프론트엔드가 여러 서비스에 호출을 해야 합니다. 웹, 모바일 등 서로 다른 프론트엔드 애플리케이션은 각기 다른 API가 필요하므로 프론트엔드가 복잡해집니다.

Frontend → User Service
Frontend → Order Service
Frontend → Payment Service
Frontend → Notification Service

바로 여기서 BFF가 등장합니다.

4️⃣ Backend For Frontend (BFF)

✅ BFF란?

BFF는 프론트엔드 전용으로 설계된 백엔드 레이어입니다.

Web App   → Web BFF   → Microservices
Mobile App → Mobile BFF → Microservices

왜 BFF를 사용하나요?

• 프론트엔드 복잡도 감소
• 여러 API를 하나로 집계
• 디바이스별 맞춤 응답 제공
• 성능 향상

🧠 예시

프론트엔드가 사용자 정보, 주문 내역, 지갑 잔액을 필요로 합니다. 세 개의 별도 호출 대신 하나의 엔드포인트를 요청할 수 있습니다:

Frontend → /dashboard

BFF는 내부적으로 다음과 같이 집계합니다:

/dashboard → User Service
           → Order Service
           → Wallet Service

🧩 BFF 예시 (Node.js)

app.get('/dashboard', async (req, res) => {
  const user = await getUser()
  const orders = await getOrders()
  const wallet = await getWallet()

  res.json({ user, orders, wallet })
})

5️⃣ 마이크로 프론트엔드 아키텍처 (프론트엔드 레벨)

❓ 마이크로 프론트엔드란?

마이크로 프론트엔드는 프론트엔드에 마이크로서비스 개념을 적용한 것입니다. UI가 독립적인 앱들로 분할되며, 각 앱은 다른 팀이 담당합니다.

Shell App
 ├── Header (Team A)
 ├── Product App (Team B)
 ├── Cart App (Team C)
 └── Payment App (Team D)

실제 사례 비유 – 쇼핑몰

• 각 매장은 독립적으로 운영됩니다
• 쇼핑몰은 그들을 단순히 호스팅합니다

6️⃣ 마이크로 프론트엔드 예시

구조

/container-app
/product-app
/cart-app
/payment-app

컨테이너 앱 (호스트)

// 원격 마이크로 프론트엔드 로드
import('productApp/ProductList')

상품 앱

export default function ProductList() {
  return 

제품

}

각 앱:

• 자체 저장소를 가지고 있습니다
• 자체 배포 파이프라인을 가지고 있습니다
• React, Vue, Angular 등을 사용할 수 있습니다

7️⃣ 모든 것이 어떻게 맞물리는가 (전체 그림)

Browser
   ↓
Micro Frontend Shell
   ↓
BFF (Web)
   ↓
Microservices
   ↓
Databases

책임

8️⃣ 언제 무엇을 사용해야 할까?

마이크로서비스를 사용해야 할 때

• 대규모 백엔드 범위
• 독립적인 스케일링 필요
• 여러 백엔드 팀

BFF를 사용해야 할 때

• 다수의 프론트엔드(웹, 모바일 등)
• 무거운 API 집계 필요
• 디바이스별 응답 필요

마이크로 프론트엔드를 사용해야 할 때

• 대규모 UI 영역
• 다수의 프론트엔드 팀
• 독립적인 UI 배포 원함

9️⃣ 장점 및 단점 요약

✅ 장점

• 독립적인 배포
• 빠른 개발 주기
• 향상된 확장성
• 팀 자율성

❌ 과제

• 전체 복잡도 증가
• DevOps 오버헤드 증가
• 집계로 인한 네트워크 지연 가능성
• 강력한 가시성 필요

🔚 Final Thoughts

Microservices, BFF, and Micro Frontends are not buzzwords — they are survival tools for large‑scale systems.

Start small:

• Monolith → Microservices
• Add BFF when the frontend grows
• Add Micro Frontends when UI teams scale