마이크로서비스 아키텍처와 다양한 클라이언트 환경이 보편화되면서, 클라이언트 중심의 백엔드 설계 방식이 중요해졌다.
이때 유용하게 활용되는 아키텍처 패턴이 BFF(Backend For Frontend)이다.
BFF 패턴이란?

BFF(Backend For Frontend)는 클라이언트(Web, Mobile, Wearable 등)의 특성에 맞춰 전용 백엔드 API를 제공하는 아키텍처 패턴이다.
즉, 하나의 백엔드가 모든 클라이언트를 처리하는 대신, 클라이언트별로 별도의 백엔드 계층(BFF)을 둬서 맞춤형 API를 제공하는 방식이다.
BFF 패턴의 등장 배경
1️⃣ 다양한 클라이언트 요구사항
웹, 모바일, 웨어러블, IoT 등 클라이언트의 종류가 다양해지면서 각기 다른 UI/UX 요구가 발생한다.
👉 동일한 데이터를 다르게 표현하거나, 필요한 데이터가 다를 수 있다.
예시
- 모바일: 트래픽 절약을 위해 필수 정보만 요청
- 웹: 상세하고 복잡한 데이터를 한번에 요청
2️⃣ 마이크로서비스 아키텍처의 복잡성 증가
마이크로서비스 기반 시스템은 서비스 간 연동이 복잡해질 수 있다.
또한 프론트엔드에서 여러 마이크로서비스에 직접 호출하게 되면 클라이언트 코드가 복잡해지고 응답 속도도 저하된다.
👉 BFF가 중간에서 데이터를 조합 및 가공해 클라이언트의 부담을 줄인다.
BFF 패턴의 필요성
1️⃣ 클라이언트별 최적화된 사용자 경험 제공
클라이언트마다 화면 크기, 네트워크 상태, 처리 능력이 다르므로 UI/UX 설계가 달라야 한다.
| 클라이언트 | 특성 | BFF의 역할 |
| 모바일 | 화면 작고 네트워크 느림 | 필요한 데이터만 간결하게 응답 |
| 웹 | 화면 크고 복잡한 UI 구성 | 다양한 데이터 일괄 제공 |
| IoT | 저전력, 제한된 연산 능력 | 최소한의 처리 및 응답 제공 |
2️⃣ 네트워크 호출 최소화
여러 API를 호출해야 하는 작업을 BFF가 한 번의 요청으로 묶어서 처리
👉 오버헤드 감소 | 응답 속도 개선 | 서버 부하 감소
예시: 주문 상세 조회 API
공통 백엔드 응답 (원본 API)
{
"orderId": "123456",
"user": {
"id": "u789",
"name": "Jane Doe",
"email": "jane@example.com",
"phone": "010-1234-5678"
},
"items": [
{
"productId": "p001",
"name": "Bluetooth Headphones",
"quantity": 1,
"price": 129000,
"imageUrl": "https://cdn.example.com/product/p001.jpg",
"description": "High-quality wireless headphones with noise cancellation."
}
],
"delivery": {
"status": "배송중",
"expectedDate": "2025-06-10",
"trackingUrl": "https://track.example.com/123456"
},
"payment": {
"method": "카드",
"status": "결제완료",
"amount": 129000
}
}
📱모바일 클라이언트용 BFF 응답 예시
모바일은 화면 공간이 제한적이기 때문에 간결한 정보 중심으로 응답
{
"orderId": "123456",
"status": "배송중",
"expectedDate": "2025-06-10",
"items": [
{
"name": "Bluetooth Headphones",
"quantity": 1,
"imageUrl": "https://cdn.example.com/product/p001.jpg"
}
]
}
- 불필요한 사용자 정보, 상세 상품 설명, 결제 정보 등은 제외
- 배송 상태와 제품 요약 정보만 제공하여 화면 로딩을 빠르게 하고 네트워크 트래픽 최소화
💻 웹 클라이언트용 BFF 응답 예시
웹은 화면이 넓고 다양한 기능 지원 가능, 더 풍부한 정보 제공
{
"orderId": "123456",
"user": {
"name": "Jane Doe",
"email": "jane@example.com"
},
"items": [
{
"name": "Bluetooth Headphones",
"quantity": 1,
"price": 129000,
"description": "High-quality wireless headphones with noise cancellation."
}
],
"deliveryStatus": "배송중",
"trackingUrl": "https://track.example.com/123456",
"paymentStatus": "결제완료"
}
- 고객 센터, 주문 취소, 배송 추적 기능 등을 위해 더 많은 정보 필요
- 웹에서는 UI가 복잡해도 빠른 네트워크 환경을 가정하여 세부 정보 제공
3️⃣ 마이크로서비스 아키텍처와의 효율적인 통합
- 클라이언트가 마이크로서비스 내부 구조를 몰라도 되므로 추상화 효과
- 마이크로서비스가 변경되더라도 BFF만 수정하면 클라이언트는 변경이 불필요
👉 시스템 유연성과 확장성 확보
BFF 패턴의 장·단점
1️⃣ 프론트엔드 요구사항과 백엔드 요구사항의 분리
- BFF는 클라이언트(UI)와 백엔드 비즈니스 로직 사이의 계층을 분리하여 각각의 관심사를 분리한다.
- 프론트엔드 개발자는 데이터 가공 없이 화면 그리기에 집중할 수 있고, 백엔드 개발자는 핵심 로직과 데이터 처리에 집중할 수 있다.
예시: 주문 상세 화면에서 주소 포맷 처리
백엔드에서 제공하는 원시 주소 데이터
{
"orderId": "ORD123456",
"deliveryInfo": {
"address": {
"city": "서울시",
"district": "강남구",
"detail": "역삼동 123-45 3층"
}
}
}
- 백엔드 비즈니스 로직은 주소를 시(city), 구(district), 상세주소(detail)로 분리해서 저장
웹 프론트엔드의 요구사항
- 주소를 "서울시 강남구 역삼동 123-45 3층" 형태로 보여주길 원함
- 하지만 프론트엔드에서 해당 포맷을 만들기 위해 null 체크, 띄어쓰기, 구분자 처리 등 불필요한 가공 로직 추가 필요
BFF에서 처리한 응답
{
"orderId": "ORD123456",
"deliveryAddress": "서울시 강남구 역삼동 123-45 3층"
}
- BFF는 백엔드 응답을 받아 포맷을 조합해 프론트엔드가 바로 사용할 수 있는 형태로 변환
- 프론트엔드는 단순히 deliveryAddress 값을 화면에 출력 하면 됨
2️⃣ 더 쉬운 API 유지보수 및 구조 변경 대응
- 프론트엔드는 BFF만 바라보기 때문에, 백엔드 API가 변경되더라도 영향 최소화
- BFF에서 API 통합 및 필드 변환을 처리하면 클라이언트는 별도 수정 없이 사용 가능
예시
- 기존 사용자 정보 API에서 userInfo.name -> userName으로 변경
- 👉 BFF에서 userName = userInfo.name 매핑 처리하여 클라이언트는 무관하게 유지
3️⃣ 프론트엔드에서 더 나은 오류 처리 가능
- BFF는 백엔드의 복잡한 에러 메시지를 클라이언트 친화적으로 가공할 수 있다.
- 사용자 경험을 고려해 UI에 적합한 오류 메시지 전달 가능
예시
- 백엔드 에러: "error_code": "ERR_USER_NOT_FOUND"
- 👉 BFF 가공 후: "해당 사용자를 찾을 수 없습니다. 다시 시도해주세요."
4️⃣ 백엔드 서비스의 공유 및 재사용
- 하나의 BFF가 여러 프론트엔드와 백엔드 사이에서 중간 다리 역할 수행
- 동일한 백엔드 로직을 여러 프론트엔드에서 재활용 가능
5️⃣ 보안 강화
- BFF는 불필요한 데이터 제거, 민감 정보 필터링 등의 역할을 수행하여 프론트로 유출되는 정보 최소화
6️⃣ 팀 간 역할 명확화와 소유권 분배
- 프론트엔드 팀은 BFF와 UI를, 백엔드 팀은 마이크로서비스를 담당
👉 각 팀이 독립적으로 작업 가능하되, 협업이 유연하게 진행됨
'아키텍처 & 설계(Architecture & Design) > MSA' 카테고리의 다른 글
| SAGA 패턴과 멱등성 – 분산 트랜잭션에서 꼭 짚고 넘어가야 할 관계 (0) | 2025.11.10 |
|---|---|
| 분산 트랜잭션의 한계와 SAGA 패턴 (0) | 2025.11.07 |
| [API Gateway] API Gateway에서 분산 로깅 및 추적 (0) | 2025.04.28 |
| [API Gateway] 로깅과 모니터링의 중요성 (0) | 2025.04.16 |
| [API Gateway] API Gateway에서의 트래픽 제어 (0) | 2025.04.08 |