본문 바로가기

Client/Front-end

<BFF> BFF 개발 시의 고려요소

1. 소개

 - 지난 포스팅에서는 BFF란 무엇인지, 어떻게 구현될 수 있는지 알아보았다. BFF는 프론트엔드와 백엔드 사이에서 중간 계층으로 동작하는 서버이다. 서버이기 때문에 BFF를 개발할 때는 데이터 통신, 보안, 성능 최적화, 배포 등을 고려해야 한다. 이 포스팅에서는 BFF 개발 시 이 네 가지 요소에 대해 자세히 알아보고, 각 요소의 중요성과 고려사항을 살펴보겠다.

 

 

2. 고려사항

* 데이터 통신

 - BFF의 데이터 통신은 프론트엔드와 백엔드 간의 효율적인 데이터 전송을 위해 중요한 요소다. 데이터 통신을 최적화하기 위해 다음과 같은 전략과 기법을 고려할 수 있다.

  • 비동기적인 방식으로 API 호출을 처리하여 응답 시간을 단축한다. 이를 통해 클라이언트는 여러 개의 API 요청을 병렬로 처리할 수 있고, 더 빠른 응답을 받을 수 있다.
  • 필요한 데이터만 선택적으로 요청하여 트래픽을 감소시킨다. 클라이언트의 요구에 맞게 필요한 데이터만을 요청하고, 불필요한 데이터는 제외하여 응답의 크기를 최소화한다.
  • 데이터 가공과 필터링을 통해 불필요한 데이터를 제거하고 응답의 크기를 최적화한다. 필요한 데이터만을 추출하여 클라이언트에게 전달하는 방식으로 응답 시간을 최적화할 수 있다.

 

* 보안

BFF는 클라이언트와 백엔드 간의 안전한 데이터 통신과 인증을 제공해야 한다. 보안을 고려하기 위해 다음과 같은 전략과 기법을 고려할 수 있다.

  • HTTPS 프로토콜을 사용하여 데이터의 기밀성과 무결성을 보장한다. 암호화된 연결을 통해 데이터의 안전한 전송을 확보할 수 있다.
  • 인가된 사용자만이 BFF에 접근할 수 있도록 인증 메커니즘을 구현한다. 토큰 기반 인증 방식을 활용하여 유효한 토큰을 이용한 접근 제어를 수행한다.
  • 클라이언트와 백엔드 간의 인증 정보를 연동하여 안전한 통신을 유지한다. 클라이언트로부터 받은 인증 정보를 백엔드로 전달하거나, BFF 자체적으로 인증을 수행하는 방법을 선택할 수 있다.

여기서 드는 의문이 있다. 백엔드 서버에 인증이 있는데 왜 BFF에서 또 인증을 하려고 하는가이다. BFF에서 또한 인증을 수행하는 이유는 크게 3가지 정도가 있다.

 

 

  1. 클라이언트와 백엔드의 인증 체계 분리: BFF는 프론트엔드와 백엔드 사이에서 중간 계층 역할을 수행한다. 클라이언트가 백엔드에 직접 접근하는 대신 BFF를 통해 요청을 처리한다. 이렇게 함으로써 프론트엔드와 백엔드의 인증 체계를 분리할 수 있다. BFF에서는 클라이언트로부터 받은 인증 정보를 백엔드와의 통신에 사용하거나, BFF 자체적으로 인증을 수행하여 클라이언트와 백엔드 간의 인증을 연동한다. 때때로 BFF자체 기능을 사용하여 응답을 해야하는 경우(ex. 캐시응답)에는 인증체계 분리가 필요할 수 있다.
  2. 세밀한 접근 제어: BFF는 클라이언트와 백엔드 간의 중간 계층으로써 클라이언트의 요구에 따라 필요한 데이터만을 전달해야 한다. 이를 위해 BFF에서 인증을 수행하여 클라이언트의 권한을 확인하고 필요한 데이터에 대한 접근을 제어할 수 있다. 백엔드에는 클라이언트로부터 직접 접근되지 않으므로, BFF에서 인증을 통해 적절한 데이터 접근을 보장할 수 있다.
  3. 추가적인 보안 측면 고려: 백엔드에 이미 인증이 구현되어 있더라도, BFF에서도 별도의 인증을 수행함으로써 보안 측면을 더욱 강화할 수 있다. 예를 들어, BFF에서는 백엔드와 통신 시에 암호화된 연결을 사용하거나, 추가적인 인증 요건을 검증하여 보안 취약점을 최소화할 수 있다. 이를 통해 클라이언트와의 안전한 통신을 보장할 수 있다.

 

* 성능 최적화

 - 성능 최적화에 대한 얘기를 하기에 앞서, BFF를 두는 것 자체가 통신 레이어가 추가되는 것이므로 응답 시간이 지연되는 것이 아니냐고 얘기할 수도 있겠다. 그러나, 프론트엔드 개발 시 클라이언트에서 여러 API를 가공해야 하는 상황에서는 클라이언트에서 많은 리소스를 사용해야 한다. 이는 성능 저하를 야기할 수 있다.

 

 - 하지만 BFF를 도입하여 API 응답 시간이 약간 지연되더라도 클라이언트에서 API 가공에 대한 부담을 줄일 수 있다. 또한, 리액티브 프로그래밍 방식을 적용하여 여러 API를 동시에 호출하고 조합하는 방법을 사용하면 API 응답 시간을 최적화할 수 있다. 더불어 클라이언트에서 처리하기 어려운 복잡한 데이터 구조를 BFF에서 가공하여 클라이언트의 리소스 사용을 최소화하고 성능을 향상시킬 수도 있다. 특히 2G 또는 3G와 같이 네트워크 연결이 느린 환경에서는 BFF 방식이 더욱 유용할 수 있다.

 

 - 따라서 BFF는 클라이언트와 백엔드 간의 효율적인 연동을 위해 필요한 중간 계층으로서 많은 가치를 가지고 있다. 게다가 BFF는 성능을 최적화 할 수 있는 다양한 가능성을 갖고 있다. BFF의 성능을 최적화하기 위해 다양한 기법을 활용할 수 있다. 몇 가지 예시는 다음과 같다.

  • 데이터 캐싱을 활용하여 반복적인 데이터 요청을 최소화한다. 캐시 서버를 도입하여 자주 사용되는 데이터를 캐싱하고, 필요한 경우 캐시된 데이터를 사용하여 빠른 응답을 제공한다.
  • 레이어드 아키텍처를 적용하여 데이터 가공과 필터링을 효율적으로 수행한다. 여러 개의 레이어를 추가하여 데이터의 가공과 변형을 단계적으로 수행하며, 필요한 데이터만을 추출하여 클라이언트에게 제공한다.
  • 성능 테스트와 모니터링을 통해 성능 이슈를 식별하고 최적화를 수행한다. 부하 테스트를 통해 BFF의 응답 시간과 처리량을 측정하고, 성능 저하의 원인을 파악하여 개선하는 작업을 수행한다.
  • 불필요한 데이터 요청을 최소화하기 위해 클라이언트 요청을 분석하고, 필요한 데이터만을 선택적으로 가져오는 방식을 적용한다.

 

* 배포

 - BFF의 핵심 목적은 프론트엔드 생산성을 향상시키는 것이다. 앞서 언급한 문제 해결과 장점들은 BFF를 도입함으로써 프론트엔드와 백엔드를 분리함으로써 나타나는 것은 자명하다. 따라서 이상적으로는 BFF는 프론트엔드 요구사항을 충족하기 위해 프론트엔드 개발자에 의해 빌드되고 배포되어야 한다. BFF의 배포 과정은 일반적으로 다음과 같은 단계를 포함한다.

 

 

  1. 개발: 프론트엔드 개발자는 BFF를 구현하기 위해 필요한 로직과 기능을 개발한다. 이 단계에서는 BFF에 필요한 서버 사이드 기술을 선택하고 개발 환경을 설정한다.
  2. 테스트: BFF의 기능과 동작을 확인하기 위해 단위 테스트와 통합 테스트를 한다. 이를 통해 개발한 BFF가 예상대로 동작하고 요구사항을 충족하는지 확인할 수 있다.
  3. 빌드: BFF 소스 코드를 빌드하여 실행 가능한 형태로 변환한다. 이 단계에서는 의존성 관리와 소스 코드 최적화 등을 수행한다.
  4. 배포: 빌드된 BFF를 실제 서버 환경에 배포한다. 이 단계에서는 BFF가 실행될 서버 환경을 설정하고, 필요한 환경 변수 및 구성 파일을 설정한다. 배포는 수동으로 수행될 수도 있고, CI/CD 파이프라인을 통해 자동화될 수도 있다.
  5. 모니터링: 배포된 BFF의 상태와 성능을 모니터링하고, 로그를 분석하여 장애나 성능 이슈를 식별하고 대응한다. 이를 통해 BFF의 안정성과 성능을 유지하며 사용자에게 원활한 경험을 제공할 수 있다.

 

 - 예를 들어, 프론트엔드 팀이 Next.js를 사용하여 개발한 웹 애플리케이션에서 BFF를 구현한다고 가정해보자. Next.js로 개발된 프론트엔드 애플리케이션과 분리된 BFF 서버를 배포하기 위해 다음과 같은 절차를 따를 수 있다.

  1. 개발:  Next.js 프레임워크를 활용하여 BFF 서버를 구현하고 필요한 API 엔드포인트를 정의한다.
  2. 테스트: BFF의 단위 테스트와 통합 테스트를 작성하여 개발한 기능을 검증한다. Jest와 Supertest와 같은 테스트 도구를 사용하여 테스트를 자동화한다.
  3. 빌드: BFF 소스 코드를 빌드하여 실행 가능한 형태로 변환한다. Next.js의 빌드 명령어를 사용하여 서버 사이드 렌더링 및 코드 번들링을 수행한다.
  4. 배포:  클라우드 서비스 (예: Vercel, AWS, Azure, Google Cloud)나 가상 서버에 BFF를 배포한다. Next.js의 배포 기능을 활용하거나, Docker와 Kubernetes와 같은 컨테이너 기반의 배포 환경을 구성한다.
  5. 모니터링: 클라우드 서비스 제공자가 제공하는 모니터링 및 로깅 도구를 활용하거나, 서드파티 모니터링 도구를 활용하여 BFF의 상태를 지속적으로 관찰한다. 장애나 성능 이슈가 있다면 탐지하고 대응한다.

 

 - 위와 같은 방식으로 Next.js를 활용한 BFF를 개발하고 배포함으로써 프론트엔드와 백엔드의 독립성과 생산성을 유지할 수 있다.

 

3. 결론

 - BFF 개발 시 데이터 통신, 보안, 성능 최적화, 배포는 매우 중요한 요소이다. 이러한 요소들은 사용자 경험을 향상시키고 시스템의 성능을 향상시킬 수 있다. 이를 위해 BFF 개발자는 데이터 통신 최적화, 보안 고려사항, 성능 최적화 기법을 종합적으로 고려하여 안정적이고 성능 우수한 BFF를 개발해야 한다.

 

 - 뿐만 아니라 프론트엔드 개발자가 독립적으로 BFF를 빌드하고 배포함으로써 FE 생산성을 극대화시킬 수 있다. 이를 위해서는 프론트엔드 개발자도 테스트, 빌드, 배포 그리고 모니터링에 해당하는 Ops(운영)측면을 소홀히 해서는 안된다.

 

 


참고

 

 

카카오페이지는 BFF(Backend For Frontend)를 어떻게 적용했을까? | 카카오엔터테인먼트 FE 기술블로그

박수빈(cheese) 유저와 가장 가까이 맞닿아있는 프론트엔드를 좋아합니다. 취미로 "기타의숩"이라는 YouTube를 하고 있습니다.

fe-developers.kakaoent.com

 

 

BFF (Backend For Front. aka Aggregator)

BFF는 왜 사용할까? 마이크로 서비스 아키텍처로 구현된 이커머스는 여러 도메인 앱으로 구성되어 있다. 도메인의 예로는 회원, 장바구니, 주문, 상품, 쿠폰 등이 있다. 그리고 각 MSA는 프론트엔

americanopeople.tistory.com