BFF (Backend for Frontend) 패턴 이란 ?

BFF (Backend For Frontend) 패턴은 마이크로서비스 아키텍처에서 백엔드와 프론트엔드 간의 인터페이스를 효율적으로 구성하기 위해 사용하는 패턴입니다. 이 패턴은 각 클라이언트 유형(웹, 모바일 앱 등)에 특화된 백엔드 인터페이스를 제공하는 방법입니다. BFF 패턴의 주요 목표는 클라이언트별로 필요한 데이터를 최적화하여 제공함으로써 성능을 향상시키기 위하여 주로 사용됩니다.

BFF Pattern

 

1. BFF 패턴의 시작과 넷플릭스에서의 활용

넷플릭스는 사용자 수가 폭발적으로 증가하면서, 다양한 클라이언트에 맞춘 UI와 성능 최적화가 중요해졌습니다. 예를 들어, 모바일 앱과 웹 브라우저의 요구 사항은 다르며, 동일한 백엔드 API로 모든 클라이언트를 지원하면 비효율적이거나 불필요한 데이터가 전송될 수 있었습니다.

이러한 이슈에 대한 해결방안으로, 넷플릭스는 각 클라이언트 유형(모바일, 웹, 스마트 TV)에 맞는 데이터와 기능을 맞춤형으로 제공하기 위해 BFF 패턴을 도입했습니다. 각 클라이언트에 맞춘 개별 BFF 서비스가 백엔드의 데이터를 가공하여 제공함으로써, 클라이언트가 간편하게 필요한 정보만 요청하고 받을 수 있게 했습니다.

 

2. BFF 패턴의 확산 시기

BFF 패턴이 명확하게 정의되어 업계에 확산된 것은 2010년대 중반으로 알려져 있습니다. 이 시기는 클라우드 기반 아키텍처와 마이크로서비스가 널리 보급되던 때로, 많은 기업들이 사용자 경험을 개선하고자 클라이언트별 맞춤형 백엔드 구성을 고민하게 되었습니다. 넷플릭스뿐만 아니라, 페이스북과 같은 대규모 기업들도 비슷한 아키텍처 패턴을 채택하여 모바일과 웹 클라이언트에 최적화된 데이터를 제공하기 시작했습니다.

 

BFF 패턴은 넷플릭스의 성공적인 적용 이후 마이크로서비스 아키텍처를 도입하는 많은 기업들 사이에서 인기를 끌기 시작했으며, 특히 다음과 같은 상황에서 유용성이 부각되었습니다:

• 다양한 클라이언트 지원이 필요한 경우 (예: 웹, iOS, Android, TV 앱 등)
• 빠르게 변하는 UI 요구사항을 백엔드에 미치지 않고 독립적으로 관리하고 싶은 경우
• 클라이언트에 불필요한 데이터 전송을 줄이고 성능을 최적화하고 싶은 경우

 

이렇게 BFF 패턴은 넷플릭스를 비롯한 주요 기술 회사들의 혁신적인 아키텍처 실험에서 시작되어, 마이크로서비스와 API 기반 아키텍처가 발전하면서 더 널리 사용되게 되었습니다. 현재는 소규모 스타트업부터 대규모 기업까지 다양한 조직에서 클라이언트 최적화를 위해 BFF 패턴을 사용하고 있습니다.

 

3. BFF 패턴의 특징과 동작 방식

1) 클라이언트별 맞춤형 백엔드 :

• 일반적인 백엔드 시스템은 모든 클라이언트(웹, 모바일, 데스크톱)에게 동일한 API를 제공합니다. 그러나 각 클라이언트는 필요한 데이터가 다를 수 있으며, 이를 모두 통합해 제공하면 불필요한 데이터를 포함하거나 요청이 복잡해질 수 있습니다.
•  BFF 패턴에서는 각 클라이언트에 맞는 맞춤형 백엔드를 따로 제공하여, 해당 클라이언트가 필요한 데이터만 정확히 받을 수 있게 합니다.

2) BFF와 서비스 레이어의 분리 :

•  BFF는 클라이언트별로 필요한 데이터를 수집하고 가공하는 역할을 합니다. BFF는 마이크로서비스 아키텍처의 다른 서비스들과 통신하여 데이터를 받아온 후, 이를 조합하여 클라이언트에게 전달합니다.
• 이 패턴은 각 클라이언트가 백엔드의 복잡한 로직을 신경 쓰지 않고, 필요한 데이터와 로직을 BFF에서 처리하게 함으로써 프론트엔드 개발을 간소화합니다.

3) 단순한 요청과 효율적인 데이터 전달 :

•  BFF 패턴은 클라이언트에서 여러 개의 요청을 보내는 것을 방지합니다. 필요한 데이터를 BFF에서 조합하여 한 번에 제공하기 때문에, 클라이언트는 단일 요청으로 필요한 정보를 받아볼 수 있습니다. 이렇게 하면 성능이 최적화되고, 네트워크 비용이 줄어듭니다.

 

4. BFF 패턴의 장점

1) 클라이언트에 특화된 API 제공 : 클라이언트별로 최적화된 API를 제공하여, 각각의 클라이언트가 필요로 하는 데이터를 정확하게 제공합니다. 이를 통해 오버헤드를 줄이고 성능을 향상시킬 수 있습니다.

2) 프론트엔드와 백엔드의 명확한 역할 분리 : BFF는 백엔드의 복잡성을 클라이언트가 직접 다루지 않도록 하여, 프론트엔드 개발자는 백엔드의 복잡한 마이크로서비스 구조에 대해 알 필요가 없게 됩니다. 이를 통해 프론트엔드와 백엔드 간의 역할 분리가 명확해집니다.

3) 신속한 UI 변경 지원 : UI 요구 사항이 빠르게 변화하는 경우, BFF에서 데이터를 가공하는 로직을 수정하는 것만으로 대응할 수 있습니다. 전체 백엔드 시스템을 수정할 필요 없이, BFF에서만 수정하면 클라이언트의 요구에 맞출 수 있기 때문에 민첩하게 대응할 수 있습니다.

4) 보안 강화 : BFF를 통해 클라이언트가 직접 마이크로서비스에 접근하지 않고, BFF를 경유하여 데이터를 받게 함으로써 보안을 강화할 수 있습니다. BFF는 인증, 권한 부여 등의 역할도 수행할 수 있습니다.

 

5. BFF 패턴의 단점

1) 복잡성 증가 : 클라이언트별로 BFF를 제공해야 하기 때문에, 각 BFF마다 관리와 유지보수의 부담이 커질 수 있습니다. 특히 클라이언트 유형이 많아질수록 BFF의 수가 증가하여 복잡성이 커질 수 있습니다.

2) 일관성 문제 : 동일한 데이터 요청을 여러 BFF에서 처리하게 되면, 각 BFF 간에 일관성을 유지하기 어려울 수 있습니다. 이를 해결하기 위해 각 BFF 간의 데이터 동기화가 필요할 수도 있습니다.

3) 성능 병목 : BFF가 클라이언트와 마이크로서비스 사이에 중간 계층으로 자리 잡기 때문에, 성능 병목이 발생할 수 있습니다. BFF가 과도한 데이터 조작이나 비즈니스 로직을 포함하면 성능 저하의 원인이 될 수 있습니다.

 

6. BFF 패턴 적용 시 고려사항

1) 유지보수 전략 : 각 BFF에 대해 코드베이스를 따로 관리할 경우 유지보수가 어려워질 수 있으므로, 공통 코드와 클라이언트 전용 코드를 분리하는 전략이 필요합니다.

2) API 게이트웨이와의 연계 : BFF는 API 게이트웨이와 함께 사용되는 경우가 많습니다. API 게이트웨이는 보안, 인증 등을 관리하고, BFF는 클라이언트별 비즈니스 로직을 처리하는 식으로 역할을 분담할 수 있습니다.

3) 테스트 : BFF는 클라이언트별로 다른 API를 제공하므로, 각각의 BFF에 대해 개별적인 테스트가 필요합니다. 이를 위해 자동화된 테스트가 필수적입니다.

 

7.적용사례

(카카오페이지 사례) BFF서버의 주요기능은 각 서비스에서 불러온 데이터를 통합 처리하는 형태로 사용함

(K 생명 사례) Business서비스를 조합하여 UI에서 원하는 데이터를 생성하는 별도의 Composite(합성) 서비스 형태로 사용

 

8. 결론

BFF 패턴은 클라이언트별 맞춤형 인터페이스를 제공함으로써, 마이크로서비스 아키텍처에서 프론트엔드와 백엔드 간의 통신 효율을 높여주는 유용한 패턴입니다. 클라이언트의 다양성에 따른 요구사항을 최적화하여 제공하고자 할 때 특히 효과적이며, 유지보수 전략을 적절히 마련한다면 매우 유용한 아키텍처 패턴이 될 수 있습니다.