이번에 시작한 프로젝트에서 3-Tier와 MSA, BFF 구조를 사용하려고 합니다.
3-Tier이전 프로젝트에서 3-Tier와 MSA는 사용해 봤지만 BFF 구조는 처음 보았기에
BFF란 무엇이고 왜 사용하는지, 장단점을 알아보려고 합니다.
BFF (Backend For Frontend) 패턴이란?
클라이언트(웹, 모바일 등) 별로 최적화된 백엔드 API 계층을 제공하기 위해, 각 프론트엔드에 특화된 백엔드 서비스를 따로 분리한 아키텍처 방식입니다.
BFF 서버는 프론트엔드와 백엔드 사이의 중간 역할을 하며 간단한 요청은 BFF에서 처리하기도 합니다.
BFF 서버는 주로 Node.js, Express 등을 사용합니다.
BFF를 이해하기 위해서는 MSA를 알고 있으면 도움이 됩니다.
MSA (Microservices Architecture)
반대되는 용어는 Monolithic Archietecture입니다.
기존 하나의 어플리케이션은 하나의 서비스로 운영하던 것과는 반대로
하나의 어플리케이션을 여러 개의 작은 독립 서비스로 나누어 개발, 배포, 운영하는 아키텍처 스타일입니다.
주로 백엔드에서 사용하며
서비스 별로 독립적으로 배포, 개발이 가능하여 유지보수가 용이하다는 장점이 있습니다.
하지만 여러 마이크로 서비스에 직접 요청을 해야되어 복잡하다는 단점이 있습니다.
그래서 이전 프로젝트에서는 GATEWAY 서버를 사용하여 분산처리를 했습니다.
BFF는 왜 사용하는가?
BFF를 사용하는 이유는 여러가지가 있지만 주로 클라이언트별(Web, IOS, Android)에 불필요한 데이터를 보내지 않고 코드를 모듈화 하기 위해 사용합니다.
BFF를 사용한다면 얻을 수 있는 이점은 아래와 같습니다
- 프론트엔드별로 맞춤 대응 가능
- 각 클라이언트(Web, iOS, Android 등)가 요구하는 데이터 구조, 응답 포맷, 인증 방식, 성능 요구가 다르다면 BFF에서 이를 대응할 수 있습니다.
- 불필요한 데이터를 숨길 수 있음
- BFF에서 프론트엔드가 필요한 데이터만 분리하여 내려보내 줄 수 있다.
- 복잡한 백엔드 호출은 BFF에서 처리할 수 있음
- 하나의 기능을 위해 여러 API를 호출해야 할 경우 Front에서는 하나의 API만 호출하고 BFF에서 Backend 호출 처리를 할 수 있습니다.
-> ex) 상품 조회를 위해 A, B, C api를 호출해야 한다면 BFF에서 D api를 호출하고 BFF에서 A, B, C api 를 호출하여 어떤 API를 호출하는지 Client에서 알지 못하게 제공할 수 있다.
- 재사용성이 용이
- 자주 사용하는 기능은 BFF에서 모듈화 하여 사용할 수 있습니다.
BFF의 단점
BFF는 장점도 있지만 장점도 확실합니다.
1. 운영 복잡도 증가
- 클라이언트마다 BFF를 생성한담녀 관리해야 할 서버 수가 증가하고 운영 비용이 증가합니다.
- 중복 로직 발생 가능성
- 여러 BFF가 공통 기능(유저 정보 조회, 인증 처리 등)을 담당하면 중복 코드가 발생하기 쉽습니다.
- 추가적인 응답 지연 발생 가능성
- Frontend -> BFF -> Backend 사이의 네트워크 홉이 하나 더 발생하기 때문에 불필요하게 처리만 거치고 오히려 응답 속도가 느려질 가능성이 있습니다.
- 아키텍처가 과하게 복잡해 질 수 있음
- 단순한 프로젝트에 BFF를 도입하면 과한 설계가 될 수 있습니다.
BFF는 이러한 단점이 있기 때문에 규모가 큰 프로젝트에서 모듈화를 잘 하여 사용하는 것이 좋을 것 같습니다.
추가적으로
BFF와 GATEWAY의 차이점이 궁금해서 조금 더 알아봤는데
BFF와 API GATEWAY의 차이는?
BFF와 Gateway API는 모두 클라이언트와 백엔드 사이에 위치하고 인증, 라우팅, 요청/응답 변환 등을 수행한다는 공통점이 있지만
API Gateway는 아키텍처적인 관점으로 요청을 필터링하고 정리하는 역할을 하고
BFF는 프론트엔트 친화적으로 데이터를 가공한다는 차이점이 있습니다.
아래는 API Gateway와 BFF의 차이점에 대해 표로 정리한 것입니다.
| 항목 | API Gateway | BFF (Backend For Frontend) |
|---|---|---|
| 주 목적 | 공통 기능을 통합 처리 (인증, 라우팅, 로깅 등) | 클라이언트별 맞춤형 백엔드 |
| 설계 대상 | 모든 클라이언트에 공통 적용 | 프론트엔드 앱(Web, iOS, Android 등)별 전용 |
| 기능 중심 | 보안, 인증, 로깅, 트래픽 제어 등 인프라 관점 | 데이터 가공, 응답 포맷 최적화, 프론트 요구 맞춤 |
| 재사용성 | 공통 기능이라 모든 클라이언트에 재사용 | 클라이언트 맞춤이라 전용 로직 포함 |
| 구현 위치 | 보통 인프라 팀이 관리 | 프론트엔드와 가까운 백엔드 팀이 관리 |
| 예시 | AWS API Gateway, Kong, NGINX 등 | bff-web, bff-mobile 같이 프론트별 서버 |
API Gateway는 클라이언트가 어떤 종류든 모두 동일하게 처리하지만 BFF는 각자 필요한 데이터만 가공해서 반환할 수 있습니다.
API Gateway와 BFF는 역할이 다르기 때문에 병행하여 사용할 수 있습니다.
지금까지 BFF란 무엇이고 어떤 장단점이 있는지 알아봤습니다.
