BFF(Backend for Frontend) 패턴으로 프론트엔드 성능 극대화하기

안녕하세요, Devloo입니다. 🙂 이번 시간에는 BFF(Backend for Frontend)에 대해 알아보겠습니다.

이커머스 애플리케이션을 마이크로서비스로 구축해야 하는 상황을 상상해보세요. 예를 들어, 고객, 주문, 제품, 쇼핑 카트 등을 위한 마이크로서비스가 존재하고, 이 마이크로서비스들은 프론트엔드에서 사용할 수 있도록 API를 제공합니다.

하지만 마이크로서비스에서 반환된 데이터는 프론트엔드가 필요로 하는 형식이나 필터링 방식과 다를 수 있습니다.

이런 경우, 프론트엔드가 자체적으로 데이터를 재포맷해야 하므로 브라우저 자원이 더 많이 사용될 수 있습니다.

이러한 상황에서는 BFF(Backend for Frontend)를 사용하여 일부 프론트엔드 로직을 중간 레이어로 이동시킬 수 있습니다. BFF는 프론트엔드와 백엔드 사이의 중간 레이어 역할을 합니다. 프론트엔드가 데이터를 요청할 때 BFF의 API를 호출하게 됩니다.

BFF는 다음과 같은 작업을 수행합니다:

• 관련 마이크로서비스 API를 호출하여 필요한 데이터를 얻습니다.
• 프론트엔드 요구에 맞게 데이터를 포맷합니다.
• 포맷된 데이터를 프론트엔드에 전송합니다.

이를 통해 프론트엔드의 로직이 최소화됩니다. 따라서 BFF는 데이터 표현을 간소화하고 프론트엔드에 최적화된 인터페이스를 제공하는 역할을 합니다.

이커머스에 어떻게 적용될까요?

다음 다이어그램은 각 마이크로서비스가 BFF를 통해 프론트엔드와 어떻게 연결되는지 보여줍니다.

BFF의 역할

우리가 이미 살펴본 것처럼, BFF는 프론트엔드와 마이크로서비스 간의 간단한 인터페이스 역할을 합니다. 이상적으로는 프론트엔드 팀이 BFF를 관리하는 것이 좋습니다.

단일 BFF는 단일 UI에 집중하며, 그 UI만을 위한 것입니다. 그 결과, 프론트엔드를 단순하게 유지하고 백엔드를 통해 통합된 데이터 뷰를 제공하는 데 도움이 됩니다.

그렇다면 여러 UI에 여러 BFF를 가질 수 있을까요? 이 질문에 대한 답은 이 글의 후반부에서 다루겠습니다. 계속 읽어주세요. 😊

BFF로 인해 지연 시간(Latency)이 증가할까요?

이제 BFF가 클라이언트와 다른 외부 API, 서비스 등 사이의 프록시 서버와 유사하다는 것을 알게 되었습니다. 요청이 또 다른 컴포넌트를 거쳐야 한다면 지연 시간이 분명히 증가할 것입니다. 하지만 BFF의 지연 시간은 프론트엔드에 최적화되지 않은 여러 서비스를 사용할 경우 브라우저의 높은 리소스 사용량에 비하면 미미한 수준입니다.

BFF를 구축하면 다른 백엔드나 마이크로서비스로 지능적으로 배치 호출을 수행하고 데이터를 한 번에 반환하거나, 데이터를 변환하고 형식화하여 더 편리한 형태로 반환할 수 있습니다.

이는 2G 또는 3G 네트워크를 사용하는 모바일 클라이언트에게 매우 유용할 수 있습니다. 이러한 네트워크에서는 연결을 설정하는 데 몇 초(또는 그 이상)가 걸릴 수 있기 때문입니다.

애플리케이션에서 BFF를 언제 사용해야 할까요?

많은 다른 패턴들과 마찬가지로, 애플리케이션에서 BFF를 사용하는 것은 상황과 따르려는 아키텍처에 따라 다릅니다. 예를 들어, 애플리케이션이 단순한 모놀리식 앱이라면 BFF는 불필요하며, 거의 아무런 가치가 없습니다.

하지만, 애플리케이션이 마이크로서비스에 의존하고 여러 외부 API와 다른 서비스를 소비하는 경우, BFF를 사용하면 데이터 흐름을 간소화하고 애플리케이션의 효율성을 크게 향상시킬 수 있습니다.

또한, 특정 프론트엔드 인터페이스를 위해 최적화된 백엔드를 개발해야 하거나 클라이언트가 백엔드에서 많은 데이터를 집계해야 하는 경우, BFF는 매우 적합한 선택입니다.

여러 BFF를 가질 수 있을까요?

물론입니다! BFF를 여러 개 갖는 것은 큰 문제가 되지 않습니다.

전통적인 접근 방식(즉, BFF 없이 애플리케이션을 구성하는 경우)에서는 모든 클라이언트를 위한 단일 API 게이트웨이만을 갖게 됩니다. 이는 다음과 같은 모습일 것입니다.

하지만 BFF를 가지는 목적은 클라이언트가 연결할 수 있는 집중된 인터페이스를 제공하는 것입니다. 예를 들어, 모바일 UI가 데이터를 소비하는 방식과 브라우저가 데이터를 소비하는 방식은 다를 수 있습니다. 이러한 경우, 더 나은 데이터 표현을 위해 두 개의 BFF를 사용할 수 있습니다. 다음은 여러 BFF가 있는 애플리케이션 다이어그램입니다.

보시다시피, 각 클라이언트는 여기에 BFF를 가지고 있습니다. 이는 서비스(Sa, Sb … Sn)가 응답을 최적화하는 데 도움을 줄 것입니다.

BFF를 가지는 것의 장점

BFF를 가지는 것의 몇 가지 장점은 다음과 같습니다:

• 관심사의 분리 — 프론트엔드 요구사항이 백엔드의 관심사와 분리되기 때문에 유지보수가 더 쉬워집니다.
• API 유지 및 수정의 용이성 — 클라이언트 애플리케이션은 API의 구조에 대해 덜 알게 되어, API가 변경되더라도 더 안정적으로 작동할 수 있습니다.
• 프론트엔드에서의 오류 처리 개선 — 서버 오류는 대부분의 경우 프론트엔드 사용자에게 큰 의미가 없습니다. 서버에서 보내는 오류를 직접 반환하는 대신, BFF는 사용자에게 보여줘야 할 오류를 매핑할 수 있습니다. 이를 통해 사용자 경험이 향상됩니다.
• 다양한 장치에서 병렬로 백엔드 호출 가능 — 브라우저가 브라우저 BFF에 요청을 보내는 동안 모바일 장치도 동일한 작업을 수행할 수 있습니다. 이를 통해 서비스로부터 더 빠르게 응답을 받을 수 있습니다.
• 보안 강화 — 민감한 정보는 숨길 수 있고, 프론트엔드에 불필요한 데이터는 응답에서 제외할 수 있습니다. 이러한 추상화는 공격자가 애플리케이션을 타겟으로 삼기 어렵게 만듭니다.
• 구성 요소의 팀 간 공유 소유권 — 애플리케이션의 다양한 부분을 각기 다른 팀들이 쉽게 관리할 수 있습니다. 프론트엔드 팀은 클라이언트 애플리케이션과 그 기반 리소스 소비 계층을 모두 소유하게 되어, 개발 속도가 매우 빨라집니다. 아래 다이어그램은 BFFs(프론트엔드를 위한 백엔드)와 함께 이러한 팀 분리의 예시를 보여줍니다.

실무에서 따라야 할 모범 사례

지금까지 본 것은 정말 놀라웠습니다! 그러나 BFFs가 완벽할까요?

답은 ‘아니오’입니다! 다른 모든 기술이나 패턴과 마찬가지로 BFFs에도 단점이 있습니다. 이러한 단점을 피하기 위해서는 모범 사례를 따라야 합니다.

• BFF에 모든 API를 자체 포함하여 구현하지 않기 — 모든 API는 마이크로서비스 계층에 있어야 합니다. 많은 개발자들이 이를 잊고 BFF에서도 서비스 수준의 API를 구현하기 시작합니다. BFF는 클라이언트와 서비스 간의 변환 계층이라는 점을 명심해야 합니다. 서비스 API에서 데이터가 반환되면, 이 데이터를 클라이언트 애플리케이션에서 지정한 데이터 유형으로 변환하는 것이 목적입니다.
• BFF 로직 중복 방지 — 하나의 BFF는 특정 사용자 경험을 제공해야 합니다. 디바이스 유형을 대상으로 해서는 안 됩니다. 예를 들어, 대부분의 경우 모든 모바일 장치(iOS, Android 등)는 동일한 사용자 경험을 공유합니다. 이 경우 하나의 BFF가 모든 운영 체제에 충분합니다. iOS와 Android를 위한 별도의 BFF가 필요하지 않습니다.
• BFF에 지나치게 의존하지 않기 — BFF는 단순히 변환 계층일 뿐입니다. 물론 애플리케이션에 일정 수준의 보안을 제공하기도 합니다. 하지만 BFF에 과도하게 의존해서는 안 됩니다. API 계층과 프론트엔드 계층은 BFF의 존재 여부와 관계없이 모든 기능과 보안 측면을 처리해야 합니다. BFF는 격차를 메우기 위한 것이지, 애플리케이션에 기능이나 서비스를 추가하기 위한 것이 아니기 때문입니다.

결론

BFF 패턴은 개발을 도울 뿐만 아니라 사용자 경험을 극적으로 향상시킬 수 있습니다. BFF를 사용하면 프론트엔드에 집중하면서 데이터 최적화와 집계를 효율적으로 관리할 수 있습니다. 이러한 모범 사례를 따르면 BFF를 효과적으로 활용하여 애플리케이션의 성능과 유연성을 높일 수 있습니다.

BFF 패턴을 아직 사용해보지 않았다면, 지금이 바로 시작하기 좋은 때입니다. 새로운 도전을 통해 더 나은 개발 환경과 사용자 경험을 만들어보세요.

여러분의 경험과 의견도 궁금합니다. 어떤 어려움을 겪었는지, 어떤 해결책을 찾았는지 댓글로 공유해주세요. 😃