Backend For Frontend

hahhhm·2025년 10월 28일

JWT&BFF

목록 보기

3/4

BFF란

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

Monolithic Architecture

전통의 아키텍처를 지칭한다. 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어 있는 형태이다.
빠르게 개발해야하는 소규모 프로젝트에는 합리적이지만, 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다.

기존에는 모든 서비스가 한 곳에 모인 Monolithic한 구조로 개발을 진행하는 경우가 많았지만, 서비스의 규모가 커지면서 Monolithic한 구조로는 해결이 어려운 문제들에 직면하게 되고 이를 해결하기 위해 MSA로 서비스를 전환하거나 전환을 시도하는 곳이 늘어나고 있다.

MSA(Microservice Architecture)

MSA는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다. 독립적인 배포가 가능한 서비스들로 구성된 아키텍처라는 의미를 갖는다.
서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.

MSA에서는 각 서비스를 도메인별로 분리시킨다. 서비스는 작은 서비스의 집합으로 구성되며 각 서비스는 독립적이고 단일 비즈니스 기능에 대한 책임만을 가진다.
프론트엔드 관점에서, MSA구조에서는 각 서비스가 기능별로 흩어져 있으므로 화면을 완성하기 위해 호출해야 하는 서비스도 늘어나게 된다. 따라서 화면을 그리기 위해서는 다수의 서비스에 연동을 해야하며, 여러 서비스에 분산되어 있는 데이터를 가져와서 적절히 합쳐야 하는 경우도 발생하게 된다.

이를 돕기 위해 BFF가 등장했다.

BFF의 등장

프론트엔드를 위한 백엔드 서버를 의미한다. 프론트엔드를 요구사항에 맞게 구현하기 위한 도움을 주는 보조 서버 정도로 정의할 수 있을 것 같다.

아래는 BBFF의 필요성을 살펴보기 위한 MSA 구조의 이커머스 서비스이다.

MSA답게 고객, 주문, 물건, 장바구니 등 커머스 도메인 별로 나뉘어 서비스가 구현되어 있다. 각 서비스는 프론트엔드에서 사용하는 API를 제공한다.
기능별로 서비스가 잘 분리되어있는 것 같지만 실제로 개발을 진행하다 보면 여러 고민들에 봉착하게 된다.

하나의 view(기능)을 완성하기 위해 여러 도메인의 API 응답 값을 조작해야 하는 경우
데이터를 전송하는 과정에서 불필요한 데이터를 숨겨야 하는 경우
프론트엔드에서 많은 양의 연산을 요구하는 작업을 진행해야 하는 경우

이런 경우 BFF가 좋은 해결책이 될 수 있다. 클라이언트는 BFF 서버를 호출하고, BFF 서버는 다시 각 MSA 서버를 호출한다. BFF를 두는 목적은 프론트엔드의 로직을 중간 레이어를 두어 BFF에 위임하는 것이다. 이로써 프론트엔드는 구체적인 구현을 내용을 감추고 추상화된 API를 사용할 수 있게된다. 결과적으로 프론트엔드에는 더 적은 로직이 남게 된다.

BFF가 여러개

BFF는 클라이언트에서 손쉽게 사용할 수 있는 API를 제공하는 것이 목적이다. 예를 들어, 브라우저/모바일앱/써드파티 API에 제공 해야 하는 인터페이스는 각각 다를 수 있다. 이러한 상황이라면 각각의 디바이스 유형에 맞는 BFF를 제공할 수 있다.

BFF 역할

BFF가 하는 역할은 이렇다.
1. MSA API를 호출하여 데이터를 가져온다.
2. 클라이언트를 위한 형식으로 데이터를 재가공한다.
3. 데이터를 클라이언트에 반환한다.
이렇게 하면 클라이언트에서는 최소한의 논리 로직만 지니게 된다. 그래서 클라이언트는 화면을 구성하는 데에 집중할 수 있다.

BFF 장단점

장점

클라이언트별로 최적화된 데이터 제공
보안 강화 (토큰 관리, API 보호)
API 변경에 유연한 대응
마이크로서비스와의 연결 최적화

단점

API 서버와 BFF 서버가 분리되므로 관리해야 할 서버가 증가함
BFF가 병목(Bottleneck)이 될 가능성이 있음
잘못 설계하면 불필요한 중복 로직이 생길 수 있음

언제 BFF를 써야할까?

단순한 모놀리틱에서는 BFF가 필요하지 않다. 그러나 애플리케이션이 여러 MSA에 의존하는 경우, BFF를 사용하여 데이터의 흐름을 간소화할 수 있다. 그리고 인터페이스에 최적화된 백엔드 애플리케이션을 만들어야하거나, 프론트엔드를 위해 가공해야하는 데이터 크기가 큰 경우, BFF가 유용하다.

하나의 view(기능)를 완성하기 위해 여러 도메인의 API 응답 값을 조작해야 하는 경우
데이터를 전송하는 과정에서 불필요한 데이터를 숨겨야 하는 경우
프론트엔드에서 많은 양의 연산을 요구하는 작업을 진행해야 하는 경우
Open API 연동 시 제공하는 API의 조합으로 특정 기능을 완성해야 하는 경우

BFF 사용하면 더 느려지지 않나?

BFF를 사용하는 경우, 통신해야하는 서버 레이어가 추가되는 것이기 때문에 응답시간 지연이 우려될 수 있다. (Proxy Server, 외부 API 호출 추가 등등..) 그러나 프론트엔드를 그리기에 최적화되지 않은 여러 API를 클라이언트에서 가공해야 하는 경우, 클라이언트에서 많은 리소스를 사용하게 된다. 이러한 상황인 경우, BFF 추가로 인한 API 응답 시간 지연은 감수할만 하다. 그리고 리액티브 프로그래밍 방법을 사용하여, 여러개의 API를 동시에 호출한 후 조합하는 방법 등을 사용하면, API 응답 시간을 최적화할 수 있다. 혹은 클라이언트에서 다루기 편한 구조로 데이터를 변환하여, 클라이언트의 리소스를 줄여 속도를 높일 수도 있다. 네트워크 연결이 몇초 이상 소요되는 2G 혹은 3G 환경에서는 BFF 방법이 더 유용할 수 있다.