📋 요약 한 줄 요약 BFF는 특정 클라이언트에 맞게 여러 API의 데이터를 조합하는 백엔드 계층이다. 데이터 조합의 반복과 요구사항 차이가 추가 운영 비용보다 큰지 살펴보고 도입을 결정한다.
사용자 프로필 화면을 만들기 위해 다음 세 API를 호출한다고 해보자.
GET /users/{id} 사용자 정보
GET /users/{id}/posts 작성한 게시글
GET /users/{id}/followers 팔로워 목록세 요청이 같은 사용자 ID만 필요로 하고 서로의 응답에 의존하지 않는다면, 클라이언트에서 병렬로 호출할 수 있다. 요청이 세 개라는 이유만으로 앞 요청이 끝날 때까지 기다려야 하는 것은 아니다.
화면마다 데이터 조합이 반복될 때
그런데 화면이 많아지면 다른 문제가 생긴다. 웹과 모바일에서 여러 API의 응답을 합치는 코드가 반복되고, 일부 요청이 실패했을 때의 처리도 각각 구현해야 한다. 화면마다 필요한 필드와 데이터 양이 달라지면 응답을 가공하는 작업도 늘어난다.
BFF(Backend for Frontend)는 특정 클라이언트의 요구를 담당하는 백엔드 계층이다. 여러 서비스의 데이터를 모아 그 화면에 맞는 형태로 전달하고, 클라이언트가 직접 처리하던 조합 로직을 맡을 수 있다. Sam Newman의 BFF 설명
화면에 맞는 응답 만들기
예를 들어 모바일 프로필 화면에는 다음 응답만 필요할 수 있다.
{
"user": {
"id": 1,
"name": "사용자"
},
"recentPosts": [],
"followerCount": 120
}모바일 앱은 이 데이터를 반환하는 BFF API를 한 번 호출한다. BFF는 내부 API들을 호출해 필요한 필드만 골라 응답을 만든다. 웹 화면에서 팔로워 목록 전체가 필요하다면 웹의 요구에 맞는 응답을 따로 제공할 수 있다.
BFF 안에서도 서로 독립적인 요청은 병렬로 실행할 수 있다. 반대로 첫 번째 응답에서 받은 값이 다음 요청에 필요하다면 순서를 지켜야 한다. BFF를 도입해도 이런 데이터 의존성은 남는다.
실패 처리와 운영 비용
응답을 조합할 때는 실패 처리도 설계해야 한다. 게시글 조회만 실패했을 때 프로필 전체를 실패시킬지, 사용자 정보와 함께 일부 데이터를 표시할지 정하는 식이다. 타임아웃과 재시도 정책도 같은 위치에서 관리할 수 있다.
BFF에는 운영 비용이 따른다. 배포하고 모니터링할 서비스가 늘어나고, 요청이 계층 하나를 더 거치면서 지연이 추가될 수도 있다. 여러 BFF에 비슷한 코드가 생길 가능성도 있다. Microsoft의 BFF 고려 사항
언제 도입하면 좋을까
그래서 클라이언트가 여러 개라는 사실만으로 도입을 결정하기보다 다음 상황을 살펴보는 편이 좋다.
- 웹과 모바일이 요구하는 데이터 형태가 크게 다르다.
- 여러 API를 조합하는 코드가 클라이언트마다 반복된다.
- 화면 변경 때마다 공통 API를 수정하고 다른 팀과 조율하는 부담이 크다.
- 클라이언트 팀이 필요한 백엔드 계층까지 운영할 수 있다.
요구사항이 비슷하고 기존 API로 충분하다면 공통 API를 유지해도 된다. BFF가 맡을 책임과 추가 운영 비용을 구체적으로 비교할 수 있을 때 도입 여부도 판단하기 쉬워진다.