FrontEnd

BFF(BackEnd-For-FrontEnd)란 무엇일까?

J3SUNG 2025. 4. 8. 07:02
728x90

서론

웹과 모바일을 포함해 다양한 디바이스 환경에서 서비스가 제공되면서, 각각의 플랫폼이 요구하는 데이터 구조나 응답 방식도 점점 달라졌습니다. 이제는 프론트엔드가 단순히 화면만 그리는 역할에서 벗어나, 어떤 데이터를 어떻게 가져오고 가공할지까지 함께 고민해야 할 때가 많아졌습니다.

이 과정에서 자연스럽게 등장하게 된 개념이 바로 BFF입니다. 필요에 따라 프론트엔드에 최적화된 전용 백엔드 계층을 두어, 중복된 연산이나 불필요한 데이터 전달을 줄이고, 개발 효율성과 사용자 경험을 높일 수 있게 도와줍니다.

https://nordicapis.com/building-a-backend-for-frontend-shim-for-your-microservices/

이번 글에서는 BFF가 등장하게 된 배경과 개념, 실무에서 어떻게 활용되는지, 그리고 구현 시 어떤 점을 고려하면 좋은지 정리해보려고 합니다.

BFF란?

BFF(Backend for Frontend)는 프론트엔드에 특화된 전용 백엔드 계층입니다. 기존에는 하나의 백엔드 서버가 모든 플랫폼의 요청을 처리했지만, BFF는 클라이언트 환경에 맞춘 API 응답을 만들어주는 역할을 수행합니다.

https://devowen.com/453
https://devowen.com/453

프론트엔드에서 발생하는 반복적인 데이터 가공 작업이나 복잡한 연산, 보안상의 이유로 클라이언트에서 처리하기 어려운 로직을 BFF에서 대신 수행함으로써, 프론트는 UI 구현에 더 집중할 수 있게 됩니다. 

또한, 마이크로서비스 아키텍처(MSA) 환경에서는 여러 개의 서비스에서 데이터를 받아와야 하는데, 이들을 하나의 응답으로 묶는 역할도 BFF가 담당하게 됩니다.

왜 BFF가 필요할까?

  • 과도한 데이터 전송: 하나의 API에서 너무 많은 데이터를 내려줘서 필요한 부분만 걸러서 써야 하는 경우
  • 여러 API 응답 조합이 필요한 경우: 하나의 화면을 구성하기 위해 2~3개 이상의 백엔드 API를 순차적으로 호출해야 하는 경우
  • 보안상 민감한 데이터를 숨겨야 하는 경우: 클라이언트에 직접 노출되면 안 되는 인증 정보, 내부 식별자 등
  • 연산량이 많은 작업: 엑셀 다운로드, 대용량 데이터 집계 등 브라우저에서 처리하기엔 부담스러운 작업들

이러한 문제들은 프론트엔드에서 직접 처리하기엔 번거롭고 복잡합니다. BFF는 이 중간에서 연산과 데이터를 대신 처리해주기 때문에, 프론트에서는 단순한 요청만으로 필요한 데이터만 받아서 화면을 구성할 수 있게 됩니다.

 

BFF의 구조 예시

BFF는 보통 다음과 같은 흐름으로 동작합니다:

클라이언트(웹, 앱 등) → BFF 서버 → 여러 개의 백엔드 API

예를 들어, 사용자의 대시보드 화면에서 다음과 같은 데이터가 필요하다고 가정해보겠습니다:

  • 사용자 기본 정보
  • 최근 주문 내역
  • 추천 상품 목록

각각의 정보는 다른 API에서 제공되지만, BFF가 이들을 병렬로 호출해서 적절히 가공하고, 프론트엔드가 한 번의 요청만으로 받아볼 수 있도록 정리해줍니다. 덕분에 네트워크 요청 수를 줄이고, 데이터 가공 부담도 줄일 수 있습니다.

BFF 아키텍처 패턴

BFF는 단순히 기능 하나로 고정된 구조가 아니라, 프로젝트의 규모나 클라이언트 종류에 따라 다양한 방식으로 구성될 수 있습니다. 대표적으로 다음과 같은 패턴들이 있습니다:

  • 단일 BFF 패턴
    하나의 BFF 서버가 웹, 모바일 등 모든 클라이언트를 동시에 지원하는 방식입니다.
    비교적 소규모 프로젝트나 단일한 API 응답 구조로도 충분한 경우에 적합합니다.
  • 클라이언트별 BFF 패턴
    웹, 모바일, 데스크톱 등 각 클라이언트 유형에 따라 별도의 BFF를 운영합니다.
    플랫폼별로 요구하는 데이터나 응답 구조가 많이 다를 경우 효과적입니다.
  • 기능별 BFF 패턴
    사용자, 결제, 콘텐츠 등 도메인 또는 주요 기능 단위로 BFF를 분리하는 방식입니다.
    대규모 서비스에서 API 변경이나 기능 확장을 유연하게 관리할 수 있다는 장점이 있습니다.

상황에 따라 이들을 조합하거나, 단계적으로 전환해가며 활용하는 경우도 많습니다.

어떤 기술로 구현할까?

BFF는 일반적으로 Node.js 기반으로 구현되며, 다음과 같은 기술들이 자주 활용됩니다.

  • Express: 간단한 구조와 빠른 학습곡선 덕분에 소규모 프로젝트나 빠른 프로토타입에 적합합니다.
  • NestJS: 타입 기반의 아키텍처와 모듈화된 구조 덕분에 규모 있는 프로젝트에서 안정적으로 활용할 수 있습니다.
  • Next.js API Routes: 프론트엔드와 BFF를 하나의 프로젝트 안에서 함께 다루고 싶을 때 적합한 방식입니다.

함께 자주 쓰이는 도구들

  • Redis: 자주 조회되는 데이터를 캐싱해 서버 부하를 줄이고 응답 속도를 높입니다.
  • Axios/Fetch: 다른 백엔드 API 서버와의 통신을 위한 HTTP 클라이언트로 활용됩니다.
  • JWT: 인증 및 인가 로직을 처리할 때 사용됩니다.

BFF를 도입할 대 고려할 점

  • 도입 시점: 단순한 프로젝트에는 오히려 구조가 복잡해질 수 있습니다. 다양한 클라이언트나 복잡한 연산, 보안 요건이 있는 프로젝트에서 효과가 큽니다.
  • 응답 구조 설계: 프론트엔드가 최대한 간단한 요청과 응답으로 작업할 수 있도록 화면 단위로 데이터를 묶어주는 방식이 좋습니다.
  • 보안: 민감한 데이터가 외부로 노출되지 않도록 하고, 인증/인가 로직은 서버에서 관리해야 합니다.
  • 성능: 병렬 호출, 캐싱, 응답 압축 등을 통해 서버 측 응답 속도도 함께 고려해야 합니다.
  • 유지보수: 로직이 복잡해지면 테스트와 코드 관리가 중요해지므로, 기능 단위로 잘게 나누고 중복을 줄이는 설계가 필요합니다.

마무리

BFF는 단순히 서버 한 개를 더 두는 게 아니라, 프론트엔드가 더 깔끔하고 효율적으로 동작할 수 있도록 도와주는 중간 계층입니다. 특히 MSA 구조나 다양한 클라이언트를 지원해야 하는 환경에서 큰 역할을 하게 됩니다.

모든 클라이언트 요구사항을 하나의 API로 해결하려다 보면 자연스럽게 복잡도가 증가하게 되는데, 이런 시점에서 BFF는 유연한 해결책이 될 수 있습니다. 프로젝트의 성격과 구조에 맞춰 잘 설계하고 도입한다면, 개발자 입장에서는 유지보수가 쉬워지고, 사용자 입장에서는 더 나은 경험을 제공받을 수 있습니다.

저작자표시