BFF(Backend For Frontend)

 

BFF는 특정 프론트엔드(웹, 모바일, 데스크톱 등)에 최적화된 백엔드 API 레이어를 말한다.

쉽게 말하면:

“모든 클라이언트가 공통 API를 쓰는 게 아니라,
클라이언트별로 맞춤형 백엔드를 따로 둔다는 개념.”

---

🤔 왜 BFF가 필요한가?

요즘 하나의 서비스라도 다양한 클라이언트가 존재한다.

• Web(React/Next.js)
• Mobile(Android/iOS)
• Tablet 전용 UI
• 관리자(Admin) 페이지
• Smart TV UI

문제는…
이 각각이 필요한 데이터 구조도 다르고, 화면 구성도 다르고, 호출 패턴도 다르다는 점!

여기에 “공통 API만 제공”하면 이런 문제가 생긴다:

• 모바일에서 너무 많은 데이터가 내려와 → 트래픽 낭비
• 웹에서는 데이터가 부족해서 여러 API를 연달아 호출해야 함
• 관리자 화면은 복잡한 조합 데이터를 필요로 함
• 클라이언트가 늘수록 API 복잡도도 폭증

그래서 등장한 게 BFF다.

---

🧱 BFF 구조를 한눈에

   [Web Client]  ───┐
                    │
   [Mobile App] ────┼──►  [BFF Layer]  ───►  [Backend Services / MSA]
                    │
   [Admin Page] ────┘

클라이언트별로 BFF가 따로 존재할 수 있다.

예:

• Web BFF
• Mobile BFF
• Admin BFF

---

🌟 BFF의 핵심 역할

✔ 1) 클라이언트 맞춤 데이터 조합

웹과 모바일이 원하는 데이터가 다를 때,
BFF는 여러 MSA API를 조합해 “한 번에” 내려준다.

✔ 2) API 호출 축소

모바일처럼 네트워크 품질이 중요한 환경에서는
단일 API로 필요한 데이터를 한 번에 내려주는 게 매우 중요함.

✔ 3) 프론트엔드 요구사항 변화에 유연하게 대응

UI가 바뀌더라도 BFF만 수정하면 되고,
백엔드는 그대로 유지할 수 있다 → 프론트/백엔드 간 충돌 감소

✔ 4) 클라이언트별 인증/권한 처리

웹, 모바일, 관리자 화면은 인증 방식도 제각각임
→ BFF에서 통일 혹은 분리해 처리 가능

✔ 5) 캐싱, 어그리게이션, 포맷 변환

• 여러 서비스 API를 모아 하나로 정제 (aggregation)
• 모바일 최적화를 위한 응답 데이터 축소
• JSON 스키마 변환 등도 가능

---

📦 BFF가 없으면 생기는 문제들

• 프론트엔드 개발팀이 백엔드 API 요구 때문에 계속 기다려야 함
• 웹/모바일 요구사항 충돌 → 백엔드 API가 점점 복잡
• 화면에 따라 호출 조합이 달라서 프론트 코드가 난잡해짐
• MSA 환경에서 API 호출 수 폭증

그래서 최근에는 “BFF는 선택이 아니라 필수”라는 말도 많다.

---

🛠 실제 예시 (아주 쉬운 버전)

예) 주문 상세 화면

모바일 화면 구성

• 주문 정보
• 배송 정보
• 배송 진행 상태만 표시

웹 화면 구성

• 주문 정보
• 배송 정보
• 결제 이력
• 환불 정보
• 주문자 정보 등 더 많은 데이터 필요

백엔드 API가 GET /order-detail 하나뿐이라면?

→ 모바일은 너무 많은 데이터 받아서 낭비
→ 웹에서는 데이터가 부족해 또 여러 개 API 호출해야 함
→ 화면마다 “조합 코드”를 프론트엔드가 직접 구현해야 함

BFF가 있으면?

• Mobile BFF: /mobile/order-detail → 딱 필요한 필드만 전달
• Web BFF: /web/order-detail → 상세 정보까지 조합해서 내려줌

---

🧩 BFF의 아키텍처 다이어그램 (텍스트 버전)

                  ┌─────────────┐
     [Web UI] ───►│ Web BFF      │───┐
                  └─────────────┘   │
                  ┌─────────────┐   │
 [Mobile App] ───►│ Mobile BFF   │   │
                  └─────────────┘   │
                  ┌─────────────┐   ▼
    [Admin UI] ─► │ Admin BFF    │──►[Backend Services]
                  └─────────────┘   

각 BFF는 서로 독립적으로 운영될 수 있고
버전 관리도 분리된다.

---

🌈 BFF의 장점 요약

• UI 변경에 백엔드가 흔들리지 않는다
• 모바일·웹 요구사항 충돌을 해결
• 백엔드는 도메인 로직만 집중 → 깔끔
• 프론트는 “맞춤 API”만 사용 → 개발 속도 증가
• 네트워크 효율 ↑
• MSA 환경에서 API 호출 수 감소

---

⚠ BFF의 단점 (주의해야 할 점)

• BFF가 많아지면 서버 관리가 늘어남
  → Web BFF / Mobile BFF / Admin BFF / Partner BFF …
• 너무 많은 조합 로직이 BFF에 쌓이면
  → “미니 백엔드”가 되어버림
  → 도메인 로직이 섞이면 안 됨 (BFF는 조합과 표현만 담당해야 함)
• API Gateway와 혼동되기 쉽다
  → Gateway는 라우팅/보안/정책 중심
  → BFF는 UI 맞춤 백엔드

---

🔥 BFF를 언제 도입해야 할까?

아래 상황이면 거의 확실히 BFF 도입이 이득이다.

✔ 웹/모바일/관리자 UI가 서로 형태가 다른 경우
✔ 프론트엔드 팀이 여러 팀으로 나뉘어 있는 경우
✔ MSA 환경에서 프론트가 여러 서비스 API를 호출하는 구조일 때
✔ 프론트엔드 요구사항 변경이 빠른 서비스
✔ 성능 최적화(트래픽 감소)가 필요한 모바일 환경

---

✨ 마무리

BFF는 프론트엔드를 위한, 프론트엔드에 맞춘, 프론트엔드 친화적인 백엔드다.

MSA 시대가 되면서
“도메인은 도메인대로”,
“프론트는 화면대로”
독립적으로 개발해야 할 필요성 때문에 자연스럽게 등장한 구조다.

UI 중심 서비스라면
BFF는 선택이 아니라 베스트 프랙티스에 가깝다.