BFF & Front Server
BFF (Backend for Frontend) 패턴과 프론트 서버
1. BFF (Backend for Frontend) 패턴이란?
BFF (Backend for Frontend) 패턴은 특정 프론트엔드 애플리케이션(예: 웹 애플리케이션, iOS 모바일 앱, Android 모바일 앱)의 요구사항에 최적화된 백엔드 서비스를 별도로 두는 아키텍처 패턴입니다.
쉽게 말해, 각 클라이언트(프론트엔드) 유형마다 **자신만을 위한 전담 백엔드(프론트 서버)**를 두는 것이라고 생각할 수 있습니다. 이 전담 백엔드는 해당 클라이언트가 필요로 하는 데이터 형식, API 호출 방식, 그리고 특정 비즈니스 로직을 처리하여 클라이언트의 개발을 단순화하고 성능을 최적화하는 역할을 합니다.
2. 왜 BFF 패턴이 필요한가요?
마이크로서비스 아키텍처는 백엔드를 여러 개의 작은 서비스로 분리하여 유연성과 확장성을 높입니다. 하지만 이러한 분할은 클라이언트 측에서 다음과 같은 문제를 야기할 수 있습니다.
클라이언트의 복잡성 증가:
하나의 화면을 구성하기 위해 여러 개의 마이크로서비스를 각각 호출하고, 그 응답들을 클라이언트에서 직접 조합해야 하는 복잡성이 발생합니다.
모바일 앱과 웹 앱이 동일한 데이터를 필요로 해도, UI/UX와 네트워크 환경이 다르므로 요구하는 데이터 형식이나 API 호출 방식이 다를 수 있습니다. 이를 백엔드의 단일 API로 모두 대응하기 어렵습니다.
성능 저하 및 네트워크 오버헤드:
클라이언트가 여러 백엔드 서비스를 개별적으로 호출하면 네트워크 왕복 횟수(RTT)가 증가하여 지연 시간이 길어지고 성능이 저하될 수 있습니다.
백엔드 서비스의 데이터 형식이 클라이언트에게 불필요하게 비대할 경우, 과도한 데이터 전송으로 네트워크 리소스가 낭비될 수 있습니다.
잦은 백엔드 변경:
프론트엔드 요구사항이 자주 변경될 때마다, 백엔드의 핵심 마이크로서비스까지 변경해야 하는 상황이 발생할 수 있습니다. 이는 백엔드 서비스의 안정성에 영향을 미칠 수 있습니다.
BFF 패턴은 이러한 문제들을 해결하여, 클라이언트와 백엔드 서비스 간의 의존성을 줄이고, 각 클라이언트의 고유한 요구사항을 효과적으로 충족시킵니다.
3. BFF 패턴의 핵심 구현체: 프론트 서버
BFF 패턴에서 "프론트 서버"는 특정 프론트엔드를 위해 설계된 백엔드 서비스를 의미합니다. 이 프론트 서버는 다음과 같은 주요 기능을 수행합니다.
데이터 오케스트레이션 (Orchestration): 하나의 클라이언트 요청을 받아 여러 백엔드 마이크로서비스로 분산 호출하고, 그 응답들을 취합하여 클라이언트가 필요로 하는 최종 형태의 데이터를 가공합니다. 이는 클라이언트에서 직접 여러 번의 네트워크 호출을 할 필요 없게 만듭니다.
클라이언트 맞춤형 데이터 변환: 모바일 앱과 웹 앱처럼 서로 다른 UI/UX를 가진 클라이언트의 요구사항에 맞춰 데이터 형식을 변환하거나, 불필요한 필드를 제거하여 최적화된 응답을 제공합니다. (예: 모바일용은 최소 데이터, 웹용은 좀 더 풍부한 데이터)
클라이언트 전용 비즈니스 로직 처리: 특정 프론트엔드의 화면이나 기능에만 필요한 비즈니스 로직을 프론트 서버에서 처리할 수 있습니다. 이는 핵심 백엔드 마이크로서비스를 오염시키지 않고 클라이언트 요구사항을 빠르게 반영할 수 있게 합니다.
API 버전 관리 단순화: 프론트 서버가 백엔드 API의 버전을 관리하고 매핑함으로써, 클라이언트는 백엔드 API 변경에 직접적으로 영향을 받지 않고 안정적인 API를 사용할 수 있습니다.
4. BFF 패턴의 장점
클라이언트 개발 간소화: 클라이언트는 복잡한 백엔드 호출이나 데이터 조합 없이, 단일한 프론트 서버 API만 호출하면 됩니다.
클라이언트별 최적화: 각 클라이언트의 성능, 네트워크 환경, UI/UX에 맞춰 API 및 응답 데이터를 최적화할 수 있습니다.
백엔드 서비스 변경에 대한 유연성: 프론트 서버가 백엔드 마이크로서비스의 변경 사항을 캡슐화하므로, 클라이언트는 백엔드 변경에 덜 영향을 받습니다.
성능 최적화: 클라이언트의 네트워크 왕복 횟수를 줄여 전반적인 응답 시간을 단축하고 네트워크 오버헤드를 감소시킵니다.
책임 분리 및 확장성: 핵심 백엔드 마이크로서비스는 도메인 로직에 집중하고, 프론트 서버는 클라이언트와의 인터페이스 로직에 집중함으로써 책임이 명확해지고 각자 독립적으로 확장할 수 있습니다.
5. BFF 패턴의 단점
시스템 복잡성 증가: 각 클라이언트 유형별로 별도의 BFF 인스턴스를 두어야 하므로, 전체 시스템의 구성 요소가 늘어나고 관리해야 할 백엔드 서비스가 증가합니다.
추가 개발 및 유지보수 비용: BFF를 개발하고 배포, 운영하는 데 추가적인 인력과 비용이 필요합니다.
중복 로직 발생 가능성: 여러 BFF 간에 유사한 로직이 존재할 경우, 중복된 코드나 기능이 발생할 수 있습니다. (이는 공통 라이브러리나 API 게이트웨이의 활용으로 일부 해결 가능)
단일 실패 지점(SPOF) 위험 (BFF 자체): 특정 BFF에 문제가 생기면 해당 클라이언트 전체가 영향을 받을 수 있으므로, BFF 역시 고가용성을 고려하여 설계해야 합니다.
6. API 게이트웨이와의 관계
BFF 패턴은 종종 API 게이트웨이 패턴과 혼동되지만, 둘은 역할과 목적이 다릅니다.
API 게이트웨이: 모든 클라이언트를 위한 공통된 진입점으로, 주로 인증, 권한 부여, 라우팅, 로깅, 모니터링, 요청 제한 등 비즈니스 로직과 무관한 횡단 관심사를 처리합니다.
BFF (프론트 서버): 특정 클라이언트에 최적화된 백엔드로, 여러 백엔드 서비스의 데이터를 오케스트레이션하고 비즈니스 로직을 적용하여 클라이언트 맞춤형 응답을 제공합니다.
두 패턴은 서로 배타적이지 않으며, 오히려 함께 사용될 때 강력한 시너지를 발휘할 수 있습니다. 예를 들어, 클라이언트 요청이 먼저 API 게이트웨이를 거쳐 기본적인 보안 및 트래픽 제어를 받은 후, 해당 요청이 특정 BFF로 라우팅되어 클라이언트 맞춤형 로직 및 데이터 오케스트레이션이 이루어지는 형태입니다.
클라이언트 → API 게이트웨이 → (웹용 BFF / 모바일용 BFF) → 핵심 마이크로서비스
Last updated