BFF란 무엇인가

1. 들어가며

요즘의 소프트웨어 개발에서는 마이크로서비스, 클라우드 네이티브 아키텍처, 클라이언트 디바이스(모바일 앱, 웹 앱, IoT 등)로 전환하게 되는 추세를 맞이하면서 새로운 아키텍처 패러다임이 필요해지게 되었습니다.

 

그 중에 가장 대두되고 있는 패턴은 BFF(Backend for Frontend) 아키텍처입니다. 애플리케이션이 더욱 분산적이게 되면서 유지 관리가 용이하며 안전한 사용자 경험을 가져다 주기 위해 개별 고객의 요구에 맞는 백엔드 서비스를 커스텀하는 것이 중요해졌습니다.

 

2. BFF란?

BFF는 말 그대로 프론트엔드를 위한 백엔드를 말하는 용어입니다. 각 프론트엔드 인터페이스에 전용 백엔드 계층을 제공하는 아키텍처 패턴이 핵심입니다. 

 

각 프론트엔드(모바일 앱, 웹 앱, 스마트 기기 등)는 각기 다른 성능, 데이터 및 상호 작용 요구사항을 가지는데, BFF는 단일 모놀리식 또는 일반화된 API에 의존하는 대신 특정 프론트엔드의 특정 요구사항에 맞게 백엔드를 맞춤화하는 전략으로 문제를 해결합니다.

 

기본적으로 모든 클라이언트 또는 클라이언트 그룹(ex. 모바일 또는 웹)에 대해 별도의 백엔드를 구축합니다.

• 다양한 서비스에 대한 호출을 통합하거나 조율합니다.
• 클라이언트 친화적인(Client-friendly) 형식으로 데이터를 준비합니다.
• 프론트엔드에 연결된 특정 로직을 처리합니다.

이를 통해 관심사의 분리를 가능케하여 클라이언트의 특정 사용 사례에 맞게 각 백엔드를 더 쉽게 최적화할 수 있습니다.

 

3. BFF 동작방식

1. 클라이언트 요청: 클라이언트가 주어진 BFF에 요청을합니다.
2. BFF 계층: BFF는 여러 마이크로서비스의 데이터를 통합하고, 변환 또는 최적화를 수행하며, 맞춤형 응답으로 응답합니다.
3. 마이크로서비스: BFF는 기본 서비스와 상호작용합니다.(ex. user service, order service, etc)

 

4. 전통적인 구조 vs BFF 구조

그렇다면 기존 전통적인 구조와 BFF 구조를 비교해보도록 하겠습니다.

 

기존 아키텍처에서는 단일 API 게이트웨이가 여러 클라이언트(ex. 웹, 모바일 IoT)의 요청을 처리하는 경우가 많았습니다. API 게이트웨이는 요청 라우팅, 인증 추가 및 속도 제한에는 유용하긴 하지만 다음과 같은 프론트엔드별 요구 사항을 처리할 수 있는 유연성은 조금 부족합니다.

• 다양한 클라이언트 앱을 위한 맞춤형 데이터 모델
• 느린 모바일 네트워크를 위해 특화된 성능 최적화
• 특정 프론트엔드에 대한 서비스 간의 복잡한 오케스트레이션 관리

 

모놀리식 API 접근 방식은 종종 오버 페칭 또는 언더 페칭으로 이어져 클라이언트가 필요한 정보를 수집하기 위해 여러 번 API 호출-응답 사이클을 반복해야 하는 상황이 발생하기도 합니다.

 

하지만 BFF는 백엔드를 분리하여 각 클라이언트가 필요한 정보를 정확하게 얻을 수 있도록 함으로써 이 문제를 해결합니다.

 

5. 왜 BFF가 뜨는 것인가

그렇다면 왜 요즘 BFF가 점점 뜨고 있는 것일까요?

 

• 맞춤형 사용자 경험: 모바일 앱, 데스크탑, 웨어러블 디바이스 등 각 프론트엔드에서 불필요한 요소 없이 필요한 데이터를 정확하게 얻을 수 있습니다. 마치 모든 상황에 딱 맞는 사이즈의 정장을 입은 것과도 같습니다.
• 복잡성 감소: BFF는 각 백엔드를 사용자 지정하여 작업을 간소화하고 여러 플랫폼에서 원활한 경험을 보장합니다.
• 성능 향상: BFF는 앱의 강력한 충전기입니다. 불필요한 API 호출을 줄임으로써 더 빠른 응답과 더 행복한 사용자를 보장합니다.
• 더 빠른 개발: 각 프론트엔드에 대해 서로 다른 BFF로 작업하는 팀은 서로의 발끝을 밟지 않고 더 빠르게 움직일 수 있습니다. 마치 주방에 여러 명의 셰프가 각자의 요리를 마스터하는 것과 같습니다.
• 보안 강화: BFF는 백엔드와의 모든 상호작용을 제어하기 때문에 토큰 검증, 입력 검증, 속도 제한과 같은 엄격한 보안 조치를 시행하여 시스템을 더욱 안전하게 만들 수 있습니다.

 

6. BFF는 언제 사용해야 하는가

Multi-Platform Application (다중 플랫폼 애플리케이션)

 

플랫폼이 여러가지인 앱을 구축하는 기업의 경우 BFF를 통해 각 플랫폼에 맞는 맞춤형 경험을 제공할 수 있습니다.

 

Microservice Orchestration(마이크로서비스 오케스트레이션)

 

마이크로서비스 아키텍처에서 클라이언트는 여러 서비스(ex. user service, order service, inventory service)에서 데이터를 가져와야 할 수 있습니다. BFF는 다양한 서비스에서 필요한 데이터를 취합하여 클라이언트에게 일관된 응답으로 제시하는 오케스트레이터 역할을 할 수 있습니다.

 

Optimizing Legacy APIs (레거시 API 최적화)

 

마이크로서비스로 마이그레이션하거나 레거시 시스템을 사용할 때 BFF는 기본 아키텍처의 복잡성을 조금 해소하는 데 도움이 될 수 있습니다. 기존 구형 시스템과 계속 상호작용하면서도 프론트엔드에 최신 인터페이스를 제공합니다.

 

7. 고려해야 할 사항(문제점)

그렇다고 BFF가 무작정 좋은 것만은 아닙니다. 아래와 같은 사항들을 고려해볼 수 있습니다.

 

• 유지보수 오버헤드 증가: 유지보수 해야 할 백엔드가 여러 개(프론트엔드당 하나씩)가 있으면 당연히 이를 관리하는 데 있어 복잡성이 증가할 수 있습니다.(추가적인 모니터링, 확장 및 보안 조치가 필요)
• 일관성 문제: 신중하게 설계하지 않으면 별도의 백엔드를 사용하기 때문에 여러 클라이언트에서 반환되는 데이터의 일관성이 떨어질 수 있습니다.
• 성능 병목현상: BFF 계층은 수많은 요청을 처리하는 데 최적화되어 있지 않거나 무거운 연산을 수행하는 경우 성능 병목 현상이 발생할 수 있습니다.

 

8. BFF를 구현할 때 다음을 신경써야 합니다.

1. BFF에서 비즈니스 로직 제한: BFF는 복잡한 비즈니스 로직을 구현하는 것이 아니라 주로 프론트엔드의 데이터 오케스트레이션 및 서식 지정에 집중해야 합니다.
2. 캐싱 사용: 특히 모바일 클라이언트의 성능을 개선하기 위해 BFF 계층에서 일반적인 응답을 캐싱할 수 있습니다.
3. 오류 처리: BFF에서 오류 처리 및 로깅을 중앙 집중화하여 클라이언트 대면 문제를 방지합니다.
4. 보안: BFF 수준에서 인증, 인가 및 rate limit 등을 적용하여 백엔드 서비스를 보호하여 BFF를 보호합니다.

 

9. BFF를 적용한 기업

Netflix

 

넷플릭스의 원활한 크로스 디바이스 경험의 뒷단에는 BFF 아키텍처가 있습니다. 모바일 앱은 가벼운 데이터만 가져오고, 데스크톱 앱은 더 풍부한 기능을 위해 더 자세한 정보들을 가져옵니다. 

 

Spotify

 

휴대폰, 태블릿, 스마트 스피커 등 어떤 기기를 사용하든 스포티파이의 BFF는 각 기기에 최적화된 데이터를 전송하여 모든 플랫폼에서 빠르고 원활한 음악 경험을 보장합니다.

 

10. 결론

프론트엔드 용 백엔드 아키텍처는 사용하는 목적에 따라 엄청난 개선을 가져다 줄 수 있는 게임체인저임은 확실합니다. 개발자는 각 UI에서 필요한 것만 정확하게 제공할 수 있습니다. 여러 개의 BFF를 관리하면 물론 복잡성이 증가할 수 있지만 성능 향상과 유연성을 중요시 하게 여기는 서비스일 수록 그만한 가치가 있다고 할 수 있습니다.