BFF

주제 선정 이유

프로젝트를 진행하면서 프론트엔드와 백엔드를 분리하여 개발하는 구조에는 점점 익숙해졌지만, 화면이 복잡해지고
기능이 다양해질수록 데이터를 가져오는 방식에 대해서는 깊이 고민해본 적이 많지 않았는데 특히 하나의 화면을
구성하기 위해 여러 API를 호출해야 하는 상황이나, 여러 서비스의 데이터를 직접 조합해야 하는 흐름이 자연스럽게
느껴졌지만 이를 명확하게 설명하기는 어려웠고, 이러한 구조가 과연 효율적인 방식인지에 대한 궁금증이 생기게
되었습니다.

또한 MSA(Microservice Architecture) 구조를 접하면서 서비스가 도메인별로 분리되는 것은 이해가 되었지만,
그걸로 인해 프론트엔드가 여러 서비스를 직접 호출하고 데이터를 조합해야 하는 구조가 생긴다는 점이 인상적이었고, 이러한 복잡도를 어떻게 해결할 수 있는지에 대한 고민을 하게 되었습니다.

그래서 이번 글에서는 BFF(Backend For Frontend)라는 개념을 중심으로 여러 백엔드 서비스를 조합하는 과정에서
발생하는 문제와 이를 해결하기 위한 중간 계층으로서의 역할, 그리고 실제 데이터 흐름이 어떻게 단순화되는지를
정리해보고자 합니다.

BFF가 뭘까?

BFF(Backend For Frontend)는 말 그대로 Frontend를 위한 Backend로, 프론트엔드가 필요로 하는 데이터를 보다
쉽게 사용할 수 있도록 여러 백엔드 서비스를 대신 호출하고, 그 결과를 조합하여 하나의 응답으로 전달하는 중간
계층입니다.

특히 MSA 구조에서는 사용자, 주문, 결제, 상품과 같은 기능이 각각 독립된 서비스로 분리되어 있기 때문에, 하나의
화면을 구성하기 위해 프론트엔드가 여러 API를 직접 호출해야 하는 상황이 자주 발생합니다.

이때 프론트엔드는 단순히 데이터를 받아서 화면에 표시하는 역할을 넘어서, 여러 서비스의 응답을 조합하고 흐름을
관리하는 책임까지 가지게 되는데, 이러한 구조는 코드 복잡도와 네트워크 요청 횟수를 늘리는 원인이 됩니다.

기존 구조

기존 구조에서는 프론트엔드가 여러 서비스를 직접 호출하기 때문에 하나의 화면을 구성하기 위해 여러 요청을 보내야 하며 응답 데이터를 프론트엔드에서 직접 조합해야 하고 이러한 구조를 가지는 것은 크게 두 가지 형태로 나타납니다.

모놀리식 구조

모놀리식 구조는 하나의 애플리케이션 안에 모든 기능이 포함된 형태로, 사용자, 주문, 상품과 같은 기능이 하나의
서버에서 함께 동작하는 구조인데 이 경우 하나의 서버에서 API를 제공하지만, 기능별로 엔드포인트가 나뉘어 있기
때문에 프론트엔드는 여전히 여러 API를 호출하고 데이터를 직접 조합해야 하는 상황이 발생할 수 있습니다.

MSA

MSA(Microservice Architecture)는 하나의 애플리케이션을 여러 개의 작은 서비스로 분리하여 구성하는
아키텍처이며, 각 서비스는 사용자, 주문, 결제, 상품과 같이 도메인 단위로 나뉘고 독립적으로 개발, 배포, 확장이
가능하도록 설계됩니다.

이러한 구조는 확장성과 유연성 측면에서 큰 장점을 가지지만, 서비스가 분리된 만큼 프론트엔드가 여러 서비스를 직접 호출해야 하는 상황이 더 자주 발생하게 됩니다.

역할과 필요성

기존 구조에서는 프론트엔드가 여러 서비스를 직접 호출하고 데이터를 조합해야 하기 때문에, 하나의 화면을 구성하기 위해 많은 네트워크 요청이 발생하고 데이터 처리 로직까지 함께 증가하게 됩니다.

이러한 문제를 해결하기 위해 BFF를 도입하게 되었고, 프론트엔드가 담당하던 데이터 처리와 요청 흐름을 대신
수행하며 다음과 같은 역할을 합니다.

역할	설명
데이터 조합	여러 API 응답을 하나로 합쳐 화면에 맞게 가공
API 호출 관리	프론트 대신 API 호출 및 흐름 제어
응답 최적화	필요한 데이터만 전달하여 성능 개선
책임 분리	프론트는 UI, BFF는 데이터 처리 담당

이러한 구조를 통해 프론트엔드는 UI와 상태 관리에 집중할 수 있고, 데이터 처리 로직은 서버에서 일관되게 관리할 수 있어 전체 시스템의 복잡도를 효과적으로 줄일 수 있습니다.

그래서 어떻게 쓰라고?

BFF는 모든 상황에서 반드시 필요한 구조라기보다는, 클라이언트와 백엔드 사이의 복잡도가 높아질 때 도입하는 것이 효과적입니다.

특히 다음과 같은 상황에서 유용합니다.

• 하나의 화면에서 여러 API를 호출해야 하는 경우
• Web, Mobile 등 클라이언트별 요구사항이 다른 경우
• 프론트엔드에서 데이터 조합 로직이 점점 복잡해지는 경우

이때 BFF를 도입하면, 프론트엔드는 하나의 API만 호출하고 UI에 집중할 수 있으며, 데이터 처리와 조합 로직은
BFF에서 일관되게 관리할 수 있고 반대로 단순한 구조에서는 BFF를 추가하는 것이 오히려 불필요한 계층이 될 수
있기 때문에, 프로젝트 규모와 복잡도를 고려하여 선택적으로 사용하는 것이 중요합니다.

마무리

BFF를 정리하면서 느낀 핵심을 다시 정리해보면 다음과 같습니다.

1. BFF는 프론트엔드를 위한 중간 계층으로, 여러 백엔드 서비스를 조합하여 하나의 응답으로 전달합니다.
2. MSA 환경에서 발생하는 다중 API 호출과 데이터 조합 문제를 효과적으로 해결할 수 있습니다.
3. 프론트엔드는 UI와 상태 관리에 집중하고, 데이터 처리 책임은 BFF로 분리할 수 있습니다.
4. 다만 모든 상황에서 필요한 것은 아니며, 시스템 복잡도에 따라 선택적으로 도입하는 것이 중요합니다.