[Backend] BFF 개념과 서비스 적용에 대한 생각
BFF는 필수적인가?
회사 프론트엔드 팀원으로부터 BFF(Backend For Frontend)를 도입해보자는 제안을 받았다.
설명을 들어보니, 프론트엔드에서 호출하는 여러 API를 BFF가 취합하여 하나의 API로 제공하고, 프론트엔드는 해당 API만 호출하는 구조를 의미했다.
처음에는 “굳이 레이어를 하나 더 추가해야 할까?”라는 생각이 들었다. 현재 프로젝트는 모놀리식 아키텍처 기반이며, DDD를 적용한 레이어드 아키텍처로 구성되어 있다. 그렇다면 프레젠테이션 레이어에서 필요한 서비스들을 조합하고, 전용 DTO를 구성하여 응답하면 되는 것 아닌가 하는 의문이 생겼다.
하지만 BFF를 제대로 이해하지 못한 상태에서 반박하는 것은 의미가 없다고 생각해 조금 더 자세히 살펴보게 되었다.
개념
Backend For Frontend(BFF)는 이름 그대로 프론트엔드를 위한 백엔드이다.
기존의 공용 API 서버 대신, 클라이언트 환경에 맞는 전용 API 계층을 두는 아키텍처 패턴이다. BFF는 프론트엔드와 백엔드 사이에 위치하며 여러 서비스로부터 데이터를 수집하고 가공하여 프론트엔드에 최적화된 형태로 제공한다.
즉, 프론트엔드는 여러 API를 직접 호출하는 대신 BFF가 제공하는 단일 API를 호출하게 된다.
등장 배경
대부분의 아키텍처 패턴은 특정 문제를 해결하기 위해 등장한다. 따라서 BFF를 이해하기 위해서는 어떤 문제를 해결하려고 만들어졌는지 먼저 알아야 한다.
BFF는 모놀리식 아키텍처에서 마이크로서비스 아키텍처(MSA)로 전환하는 과정에서 주목받기 시작했다.
MSA 환경에서는 기능이 여러 서비스로 분리된다. 이로 인해 하나의 화면을 구성하기 위해 프론트엔드가 여러 서비스의 API를 직접 호출해야 하는 상황이 발생한다.
예를 들어 사용자 프로필 화면 하나를 구성하기 위해 다음과 같은 API 호출이 필요할 수 있다.
- 사용자 정보 서비스
- 알림 서비스
- 결제 서비스
- 통계 서비스
이 경우 프론트엔드는 여러 API를 호출하고 응답을 조합해야 한다. 결과적으로 네트워크 비용과 레이턴시가 증가하고 구현 복잡도 또한 높아진다.
문제는 이것만이 아니다.
하나의 범용 API를 웹, 모바일, 태블릿 등 다양한 클라이언트가 함께 사용하는 경우도 많다.
하지만 모바일은 네트워크 사용량을 최소화하고 빠른 응답을 원한다. 반면 웹은 더 많은 데이터를 받아도 상대적으로 부담이 적다.
결국 하나의 범용 API로 모든 클라이언트를 만족시키기 어려워진다.
이러한 문제를 해결하기 위해 BFF 패턴이 등장했다.
클라이언트별 전용 API 계층을 두어 필요한 데이터만 제공하고, 여러 백엔드 서비스를 하나의 응답으로 통합함으로써 네트워크 비용과 응답 지연을 줄일 수 있게 되었다.
일반적으로 BFF는 프론트엔드와 백엔드 사이의 내부 네트워크 영역에 위치하며, 프론트엔드 팀이 직접 관리하는 경우도 많다. 이 경우 프론트엔드 애플리케이션과 동일한 주기로 배포할 수 있다는 장점도 존재한다.
장점
API 호출 횟수 감소
여러 API 호출을 하나로 통합할 수 있다.
- 네트워크 왕복 횟수 감소
- 모바일 환경에서 응답 속도 개선
- API Gateway 비용 감소
클라이언트 최적화
웹, 모바일 등 클라이언트 특성에 맞는 응답을 제공할 수 있다.
- 불필요한 데이터 제거
- 화면에 필요한 형태로 데이터 가공
- 프론트엔드 구현 단순화
프론트엔드와 백엔드의 독립성 향상
백엔드 서비스 구조가 변경되더라도 BFF가 이를 흡수할 수 있다.
- 프론트엔드 영향 최소화
- 클라이언트별 독립적인 API 제공
- 프론트엔드 팀의 개발 속도 향상
단점
운영 비용 증가
BFF 자체가 별도 서비스이므로 추가적인 인프라 비용이 발생한다.
- 서버 운영 비용
- 모니터링 비용
- 배포 비용
유지보수 복잡도 증가
시스템 계층이 하나 더 늘어나기 때문에 관리 포인트도 증가한다.
- 데이터 가공 로직 중복
- 서비스 간 책임 경계 모호
- 장애 분석 복잡도 증가
좋아 보이지만 우리 프로젝트에 적합할까?
BFF의 핵심 가치는 분산된 API를 통합하고, 클라이언트 전용 엔드포인트를 제공하는 것이다.
하지만 현재 우리 프로젝트는 모놀리식 아키텍처 기반이다.
이미 DDD 기반 레이어드 아키텍처를 사용하고 있으며, 프레젠테이션 레이어에서 여러 서비스 계층을 조합하여 화면 전용 API를 만드는 것이 어렵지 않다.
즉, BFF가 제공하는 주요 기능 중 상당 부분을 현재 구조 안에서도 구현할 수 있다.
또한 현재 팀 규모를 고려하면 BFF를 별도 서비스로 운영하는 부담도 존재한다.
- 추가 서버 운영
- 별도 배포 파이프라인
- 모니터링 체계 구축
- 유지보수 비용 증가
이러한 비용을 감수할 만큼 현재 서비스 규모가 큰지도 의문이다.
따라서 현 시점에서 BFF를 별도 계층으로 도입하는 것은 과한 선택일 수 있다고 생각한다.
다만 BFF가 추구하는 방향 자체는 매우 중요하다.
클라이언트 입장에서 필요한 데이터를 한 번에 제공하고, API 호출 횟수를 최소화하며, 레이턴시를 줄이는 것은 어떤 아키텍처를 사용하든 추구해야 하는 목표이다.
결론적으로 현재 프로젝트에서는 BFF를 별도 서비스로 도입하기보다는, 기존 모놀리식 구조 내에서 화면 전용 API를 제공하는 방식이 더 현실적이다.
향후 서비스 규모가 커지고, MSA 전환이나 다양한 클라이언트 지원이 필요한 시점이 온다면 그때 BFF 도입을 검토하는 것이 적절하다고 생각한다.
댓글남기기