BFF(Backend for Frontend) 란?

frontend SPA 서비스와 backend springboot 애플리케이션을 연결할 BFF(backend for frontend)를 만들기 앞서 BFF 개념을 알아봅니다.

원문을 제가 나름대로 이해한 대로 적어 내용은 약간 다를 수 있습니다.

BFF 란?

BFF(Backend for Frontend) 는 마이크로서비스 아키텍처의 여러 패턴 중의 하나로, 하나의 인터페이스로 구성되어있던 모노리스 서비스에서 마이크로서비스로 전환되면서 여러 UI기반 시스템이 여러 서비스의 api를 호출하고 통신하는 형태로 발전했습니다.

천천히 아키텍처가 발전하는 흐름에 맞춰서 형태가 변경되어온 셈입니다.

Monolith 분해

먼저 하나의 거대한 시스템이 응용 프로그램 자체였던 시절부터 시작합니다.

이전 문서에서는 마이크로서비스가 벡엔드 서비스를 추출하는 것이라고 정의하기도 했습니다.

이런 아키텍처 변경의 주요 목적은 새로운 서비스를 빠르게 개발하기 위한 것이었습니다. 이후에 사용자 인터페이스를 고려한 UI 서비스의 변동 빈도수가 늘어나면서 UI 구성요소만 따로 추출하고, API에서 데이터를 가져오는 형태로 발전했습니다.

위 그림같은 아키텍처를 사용하던 2011년에는 대다수 사용자가 웹을 주로 사용했습니다. Fred Wilson 같은 사람 들이 예측한대로 사람들이 모바일 앱을 더 사용하기 시작했고, 이후에도 오랫동안 모바일과 웹 모두 공용 API 서비스와 직접 통신하는 방식을 유지했습니다.

DogFooding Challenges

Modern SE에서 dogfooding(자체 서비스를 시험 테스트용으로 사용하고 공개한다)은 좋은 사례라고 소개됩니다. 자체 개발 공개API가 좋은 품질로 유지되고, 항상 업데이트되기 때문입니다. 그런데 서비스를 제공하다보니 여러 문제점이 발견되었습니다.

먼저, 공개 API만 사용한다면 타사에서 사용할 수 없는 자체 서비스를 내려면 OAuth 범위를 계속 확인하고 관리하는 것이 어렵다는 문제점이 있었습니다.
두 번째로, 타사 개발자가 여러 흥미로운 프로젝트를 만들어내도록 하려면 데이터 사용 방법을 가정하지 않고, API를 설계하게 되다보니 단일 웹사이트에서 수많은 HTTP 요청이 필요하는 상황이 발생했습니다.

(soundcloud 단일 프로필 페이지 예시)

• GET /tracks/1234.json (트랙의 저자)
• GET /tracks/1234/related.json (관련 추천 트랙)
• GET /users/86762.json (트랙의 저자에 관한 정보)
• GET /users/me.json (현재 사용자에 대한 정보)
  …
  당연히 사용자가 몰리면 네트워크 지연 현상이 일어났고, 특히 신뢰할 수 없고 느린 무선 네트워크를 사용하는 모바일 사용자 측에서 더 사용하기 어려워졌습니다.

세 번째로 모놀리스가 없어도 여전히 병목 현상은 있었다는 점입니다. 개발팀이 기존 엔드 포인트를 변경해야할 때마다 클라이언트(중요한 타사 통합 포함)를 손상시키지 않아야 하고, 새로운 엔드 포인트가 특정 앱에 지나치게 전문화 되지 않고 모든 클라이언트가 쉽게 사용할 수 있도록(단말기별로 최적화) 많은 시간을 투자해야 했습니다. 이런 모든 조정 작업이 훨씬 어려워면서 A/B 테스트를 수행하고 출시하는 기간이 점점 늘어났습니다.

Backend-For-Frontend(BFF) 등장

위에 제시한 아키텍처를 적용한지 1년만에 안드로이드에 이어서 iOS 응용 프로그램을 개발을 시작하는 경우, 아키텍처 변경이 대대적으로 필요합니다.

첫번째 솔루션은 모바일앱과 웹이 다른 API를 사용하는 것입니다. 다른 프론트엔드에 대해서 각기 다른 백엔드를 구현하는 것입니다.

여전히 백앤드는 공개API와 동일하게 구성되어있는 것처럼 보이지만, 시간이 지나면서 BFF에서 클라이언트에서만 존재하던 응용 프로그램 고유 객체(여러 엔드포인트에서 데이터를 모아서 새로운 객체를 만든다)를 사용하기 시작합니다.

이렇게 되면 클라이언트 단에서는 여러 엔드포인트를 동시에 호출하는 대신 필요한 모든 리소스를 단일 엔드포인트에 요청할 수 있습니다.

• GET /user-profile/123.json

결국 아래 그림과 같이 BFF는 API가 아닌 응용 프로그램의 일부입니다.

결국 개발팀은 API를 포함한 모든 새로운 속성을 추가할 때 최종 발전된 패턴을 사용하기 시작합니다.

BFF 개선

개발팀은 생산성을 더욱 높이기 위한 BFF 개선 방향을 고민하던 중, 여러개의 BFF에 걸쳐 데이터를 가져와서 통합하는 코드가 반복되는 것을 발견합니다.
예를 들면, 프로필 페이지에서 사용하기 위한 데이터를 가져온다고 했을 때 모바일보다는 웹에서 훨씬 많은 정보를 사용해야합니다. 그런데 모바일에서 똑같은 모델을 객체로 사용한다면 사용되지 않는 데이터가 쌓이게 되는 현상이 발생합니다. 따라서 UserProfileService 라는 중복 논리를 처리할 수 있는 서비스를 만들어 사용합니다.

시간이 지나면서 이런 경우가 더 많이 발생했고, 대부분의 서비스가 다음 같은 모양으로 발전하게 되었습니다.

BFF 예시

MSA를 도입하는 다양한 금융 회사에서 이런 BFF 패턴을 사용하는 경우가 많은데요, 그 이유는 금융 회사에서 사용하는 시스템의 형태가 BFF 패턴을 활용할 수 있는 좋은 예시가 되기 때문입니다.

예를 들어, 고객에게 은행 서비스와 보험 서비스를 모두 제공하는 은행이 있다고 상상해보세요. 은행은 이미 보험 솔루션을 사용하고 있는 보험 회사를 인수했습니다. 고객 마스터 데이터는 CRM 시스템에 저장되는 상황이고, 은행에서 사용하기 위한 셀프-서비스-포탈을 개발하기 위해서는 세 가지 다른 시스템(CRM/ 은행 / 보험)을 호출해야합니다.

대략 구조를 그려보면 다음 그림과 같습니다.

이 예시는 웹 BFF뿐이지만 고객을 대상으로 한 서비스의 경우 웹 뿐만 아니라 모바일(안드로이드/iOS) 서비스를 고려한 BFF를 구성할 수 있고, 금융 회사에서 현재 해외 서비스로 확장하고 있는 상황을 고려해본다면 각 나라에 맞는 BFF를 개발할 수 있습니다.

금융 산업 뿐만 아니라 모노리스에서 마이크로서비스로 전환하는 다양한 많은 산업군에서 이런 BFF 패턴은 앞으로 응용 가능성이 무궁무진할 것 같습니다.

Reference

• philcalcado, (July 07, 2020), https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html
• kennethlange, (July 07, 2020), https://www.kennethlange.com/backends-for-frontends-pattern/
• giljae, (July 07, 2020), https://medium.com/@giljae/back-end-for-front-end-pattern-bff-4b73f29858d6