[Daily morning study] BFF (Backend for Frontend) 패턴

09 Nov 2026 in Daily morning study / Backend

#daily morning study

---

BFF 패턴이란

BFF(Backend for Frontend)는 각 클라이언트 유형에 맞는 전용 백엔드 레이어를 별도로 두는 아키텍처 패턴이다. 웹, 모바일 앱, IoT 디바이스 등 클라이언트마다 데이터 요구사항이 다를 때 단일 API로 모두를 만족시키기 어렵다는 문제에서 출발했다.

Sam Newman이 2015년 마이크로서비스 맥락에서 처음 제안한 패턴이다.

---

등장 배경

기존 단일 백엔드 API는 모든 클라이언트가 공유한다.

모바일 앱 ──┐
웹 앱     ──┼──→ 단일 API ──→ 여러 마이크로서비스들
데스크탑  ──┘

이 구조에서 발생하는 문제들:

• Over-fetching: 모바일은 이름과 아바타만 필요한데 전체 사용자 객체를 받는다
• Under-fetching: 대시보드를 그리려면 여러 엔드포인트를 순차 호출해야 한다
• 클라이언트 간 충돌: 모바일을 위한 변경이 웹 클라이언트를 망가뜨릴 수 있다
• 팀 의존성: 프론트엔드 팀이 백엔드 팀의 일정에 종속된다

---

BFF 구조

각 클라이언트 채널마다 별도의 BFF를 둔다.

모바일 앱  ──→ Mobile BFF ──┐
웹 앱      ──→ Web BFF    ──┼──→ 내부 마이크로서비스들
파트너 API ──→ Partner BFF ─┘

BFF의 주요 역할:

1. 여러 마이크로서비스 호출을 aggregation한다
2. 클라이언트 형태에 맞게 데이터를 변환한다
3. 불필요한 데이터를 필터링한다

---

코드 예시

모바일 BFF — 네트워크 최소화, 최소 데이터

// 모바일: 사용자 프로필 + 최근 주문 3개만 필요
app.get('/mobile/user-summary', async (req, res) => {
  const [user, orders] = await Promise.all([
    userService.getUser(req.userId),
    orderService.getRecentOrders(req.userId, { limit: 3 })
  ]);

  res.json({
    name: user.name,
    avatarUrl: user.avatarUrl,
    recentOrders: orders.map(o => ({
      id: o.id,
      status: o.status,
      total: o.totalAmount
    }))
  });
});

웹 BFF — 더 풍부한 데이터

// 웹: 대시보드에 전체 주문 이력 + 추천 상품 + 알림 필요
app.get('/web/dashboard', async (req, res) => {
  const [user, orders, recommendations, notifications] = await Promise.all([
    userService.getUser(req.userId),
    orderService.getAllOrders(req.userId),
    recommendationService.get(req.userId),
    notificationService.getUnread(req.userId)
  ]);

  res.json({
    user: {
      name: user.name,
      email: user.email,
      preferences: user.preferences,
      memberSince: user.createdAt
    },
    orders: orders.map(mapOrderDetail),
    recommendations,
    notifications
  });
});

한 엔드포인트 호출로 대시보드 렌더링에 필요한 데이터를 모두 받는다. 클라이언트는 N번 호출하지 않아도 된다.

---

API Gateway와의 차이

BFF와 API Gateway는 비슷해 보이지만 역할이 다르다.

항목	API Gateway	BFF
목적	공통 횡단 관심사 처리	클라이언트별 데이터 최적화
로직	거의 없음(라우팅, 인증)	비즈니스 로직 포함 가능
범위	모든 클라이언트 공유	클라이언트 유형별 분리
주체	플랫폼 팀	프론트엔드 팀

실제로 둘을 함께 쓰는 경우가 많다.

클라이언트 ──→ API Gateway (인증/속도제한/TLS) ──→ BFF (aggregation/변환)

---

장단점

장점

• 클라이언트 최적화: 각 클라이언트가 딱 필요한 데이터만 받는다
• 팀 자율성: 프론트엔드 팀이 BFF를 직접 소유하고 변경할 수 있다
• 독립 배포: BFF 변경이 다른 클라이언트에 영향을 주지 않는다
• 장애 격리: 웹 BFF 장애가 모바일 BFF에 전파되지 않는다

단점

• 코드 중복: 여러 BFF에서 비슷한 비즈니스 로직이 중복될 수 있다
• 운영 복잡도: 관리해야 하는 서비스 수가 늘어난다
• 팀 경계 불명확: “어느 팀이 BFF를 소유하는가”를 명확히 해야 한다

---

GraphQL과의 관계

GraphQL은 BFF의 대안으로 자주 언급된다. 클라이언트가 필요한 필드를 쿼리에 직접 명시하기 때문에 over-fetching, under-fetching 문제를 해소할 수 있다.

# 모바일: 필요한 필드만 요청
query MobileProfile {
  user(id: "123") {
    name
    avatarUrl
    recentOrders(limit: 3) {
      id
      status
      total
    }
  }
}

단, GraphQL이 항상 BFF를 대체하진 않는다:

• 기존 REST 인프라를 유지해야 하는 경우
• 클라이언트별 복잡한 aggregation 로직이 필요한 경우
• GraphQL의 학습 곡선이 부담인 경우

GraphQL BFF 조합도 존재한다 — GraphQL 스키마를 클라이언트별로 나누는 방식이다.

---

언제 BFF를 선택하나

BFF가 적합한 상황:

• 클라이언트 유형이 다양하고 각각 다른 데이터 모델을 요구할 때
• 프론트엔드 팀이 백엔드 의존성 없이 빠르게 반복하고 싶을 때
• 마이크로서비스 환경에서 클라이언트가 여러 서비스를 직접 호출하는 복잡도를 줄이고 싶을 때

BFF가 과할 수 있는 상황:

• 클라이언트가 한 종류뿐일 때
• 서비스 초기 단계로 오버헤드가 부담될 때
• 팀이 작아서 BFF를 별도로 운영하기 어려울 때