개인의 기록
  • 소개
  • 프로젝트
  • 글
  • 링크

© 2026 newgirok

← 글 목록

Backend For Frontend — 클라이언트별 전용 백엔드를 두는 패턴

2025년 1월 11일
BFFBFFAPI GatewayClient OptimizationAggregation

모바일 앱과 웹 앱이 동일한 API를 공유하면 어느 한쪽은 항상 필요 이상의 데이터를 받거나, 반대로 여러 번 요청을 보내야 하는 문제가 생긴다. BFF(Backend For Frontend) 는 클라이언트 유형마다 전용 백엔드 레이어를 두어 이 불일치를 해소하는 패턴이다. Sam Newman이 마이크로서비스 문맥에서 정립한 이 패턴은 프론트엔드 팀이 백엔드 인터페이스를 직접 소유할 수 있게 해준다.

API Gateway와 무엇이 다른가

API Gateway는 인증, 레이트 리밋, 라우팅 같은 횡단 관심사(cross-cutting concerns)를 단일 진입점에서 처리한다. 클라이언트 종류에 무관하게 동일한 규칙을 적용하는 인프라 레이어다. BFF는 그 위에 놓이는 클라이언트 맞춤형 집계 레이어다.

구분API GatewayBFF
목적인증·라우팅·보안클라이언트별 응답 최적화
클라이언트 인식없음있음 (클라이언트마다 별도 존재)
비즈니스 로직없음집계·변환 로직 포함
소유 팀인프라/플랫폼프론트엔드 팀

횡단 관심사(Cross-Cutting Concerns) — 여러 레이어에 걸쳐 공통으로 적용되는 관심사. 인증, 로깅, 트레이싱 등.

구조 예시 — Web BFF와 Mobile BFF 분리

           ┌──────────┐      ┌──────────┐
           │  Web App │      │Mobile App│
           └────┬─────┘      └────┬─────┘
                │                 │
        ┌───────▼──────┐  ┌───────▼──────┐
        │   Web BFF    │  │  Mobile BFF  │
        │  (Node.js)   │  │  (Node.js)   │
        └──┬───┬───┬───┘  └──┬───┬───┬──┘
           │   │   │          │   │   │
     ┌─────▼┐ ┌▼──┐ ┌▼────┐  │   │   │
     │User  │ │Order│ │Product│  (동일 마이크로서비스 호출)
     │ SVC  │ │ SVC │ │ SVC  │
     └──────┘ └─────┘ └──────┘

Web BFF는 대시보드에 필요한 주문 목록, 사용자 정보, 추천 상품을 한 번의 요청으로 집계해서 반환한다. Mobile BFF는 네트워크 비용을 줄이기 위해 이미지 URL을 썸네일로 교체하고 불필요한 필드를 제거한다.

Aggregation과 Composition

BFF의 핵심 역할은 두 가지다.

Aggregation — 여러 마이크로서비스를 병렬 호출하고 결과를 하나로 합친다.

async function getOrderDetailPage(orderId: string) {
  const [order, user, products] = await Promise.all([
    orderService.getOrder(orderId),
    userService.getUser(order.userId),
    productService.getProducts(order.productIds),
  ]);

  return { order, user, products };
}

Composition — 클라이언트가 소화하기 좋은 형태로 데이터를 재조합한다. 예를 들어 모바일은 페이지네이션 크기를 10으로, 웹은 50으로 다르게 적용한다.

Aggregation — 분산된 데이터를 하나의 응답으로 묶는 것. Composition — 묶인 데이터를 클라이언트 요구에 맞게 재구성하는 것.

장단점

장점

  • 클라이언트별 Over-fetching / Under-fetching 제거
  • 프론트엔드 팀이 API 형태를 직접 제어 — 백엔드 팀과 독립적으로 배포 가능
  • 마이크로서비스 내부 구조가 클라이언트에 노출되지 않음

단점

  • BFF가 늘어날수록 중복 로직이 생긴다. 공통 로직은 별도 라이브러리나 공유 서비스로 분리해야 한다.
  • 클라이언트마다 BFF를 운영하므로 배포 파이프라인과 모니터링 비용이 증가한다.
  • BFF가 비즈니스 로직을 끌어당기는 경향이 있다. 집계·변환 외의 로직은 도메인 서비스에 남겨야 한다.

BFF는 클라이언트 종류가 두 개 이상이고, 각 클라이언트의 데이터 요구사항이 뚜렷이 다를 때 도입을 검토할 만하다. 단일 클라이언트라면 API Gateway 수준에서 충분한 경우가 많다.

← 이전 글Saga Pattern — 분산 트랜잭션을 관리하는 방법
다음 글 →Service Mesh — 서비스 간 통신을 인프라 수준에서 관리하는 방법