핵심 인사이트 (3줄 요약)
- 본질: BFF는 각 클라이언트(Web·Mobile·IoT)에 최적화된 별도의 API 레이어를 두는 패턴이며, 하나의 범용 API Gateway 대신 클라이언트별 맞춤 Gateway를 구성한다.
- 가치: Mobile은 작은 화면·제한된 대역폭으로 최소한의 데이터만 필요하고, Web은 풍부한 데이터가 필요한데, 범용 API는 양쪽 모두 만족시키기 어렵다. BFF가 각 클라이언트에 딱 맞는 응답을 제공한다.
- 판단 포인트: BFF 개수가 늘면 코드 중복·관리 비용이 증가하므로, GraphQL을 대안으로 고려할 수 있다(클라이언트가 필요한 필드만 쿼리).
Ⅰ. 개요 및 필요성
┌───────────────────────────────────────────────────────┐
│ BFF 패턴 │
├───────────────────────────────────────────────────────┤
│ [Web Client] → Web BFF → Microservices │
│ [Mobile App] → Mobile BFF → Microservices │
│ [IoT Device] → IoT BFF → Microservices │
│ │
│ 각 BFF: 해당 클라이언트에 최적화된 API 제공 │
│ Web BFF: 풍부한 데이터, 다중 서비스 조합 │
│ Mobile BFF: 최소 데이터, 압축 응답 │
└───────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: 범용 API는 원사이즈 티셔츠(모두에게 맞추려다 아무도 만족 못함)이고, BFF는 **맞춤 양복(클라이언트별 최적화)**이다.
Ⅱ. 아키텍처 및 핵심 원리
BFF vs 범용 API vs GraphQL
| 비교 | 범용 API | BFF | GraphQL |
|---|
| 맞춤 | 없음 | 클라이언트별 | 쿼리별 |
| 개수 | 1개 | N개 | 1개 |
| 복잡도 | 낮음 | 중간 | 스키마 관리 |
- 📢 섹션 요약 비유: 범용은 뷔페, BFF는 코스 요리(손님별 맞춤), GraphQL은 주문형 뷔페(원하는 것만 골라 담기)이다.
Ⅲ. 비교 및 연결
| 비교 | 범용 Gateway | BFF |
|---|
| 응답 | 모든 클라이언트 동일 | 클라이언트별 최적화 |
| 유지보수 | 1곳 | N곳 |
| 성능 | Over-fetching | 최적 |
Ⅳ. 실무 적용 및 기술사 판단
BFF 도입 기준
- ✅ Web/Mobile/IoT 클라이언트 3개+ → BFF 유효.
- ❌ 클라이언트 1개 → 불필요 (범용 API 충분).
Ⅴ. 기대효과 및 결론
BFF는 클라이언트 다양성이 높은 MSA에서 최적의 사용자 경험을 제공하며, GraphQL과 상황에 맞게 선택한다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|
| BFF | 클라이언트별 맞춤 API |
| API Gateway | BFF의 상위 인프라 |
| GraphQL | BFF의 대안 (쿼리형) |
| Over-fetching | 범용 API의 문제 (BFF 해결) |
| Sam Newman | BFF 패턴 창시자 |
📈 관련 키워드 및 발전 흐름도
[범용 API (REST, 2010s)]
│
▼
[BFF Pattern (Sam Newman, 2015)]
│
▼
[GraphQL (Facebook, 2015) — 쿼리형 대안]
│
▼
[BFF + GraphQL 조합 (2018~)]
│
▼
[현재: Server Components — 서버에서 클라이언트 맞춤 렌더링]
👶 어린이를 위한 3줄 비유 설명
- 범용 API는 원사이즈 티셔츠예요. 모두에게 맞추려다 아무도 편하지 않아요.
- BFF는 맞춤 양복이에요. 웹용·모바일용·IoT용 각각 딱 맞게 만들어요.
- 덕분에 스마트폰에서는 가볍게, PC에서는 풍성하게 볼 수 있답니다!