MSA/API 기반 프론트앤드 개발에 가장 필요한 기술이 되어버린 Backends Fro Frontends(BFF)의 개념 및 사레에 대해 정리해본다.
1. Backend For Frontends(BFF) 란?
BFF(Backend For Frontends)란 이름 그대로 프론트앤드를 위한 백앤드 (서버)이다. 프론트앤드를 위해 API를 호출하거나 HTML을 생성하기 위한 서버를 말한다. 여기까지 설명을 들으면 '기존 웹애플리케이션과 무엇이 다른거지?'라고 생각할지 모르겠지만 본질적으로 달라지는 것이 아니라 '프로트앤드 전용' 이라는 역할이 달라지는 것이다.
웹어플리케이션 (서버)는 다음과 같은 여러가지 용도를 가진다.
- 데이터베이스나 미들웨어(연계 등)로부터 데이터를 가져와서 데이터를 갱신한다.
- 웹페이지(사이트)를 구축한다.
- HTTP/HTTPS를 인터페이스로 하여 사용자의 입력 정보를 받는다.
여기서 데이터베이스나 미들웨어로부터 데이터를 얻거나 갱신하는 부분은 데이터의 정합성과 신뢰성을 기반으로 관리하는 것을 목적으로 한다. 웹페이지를 만들거나 사용자 입력을 받는 것은 사용자 인터페이스(UI)가 담당하며 사용자 경험(UX)을 향상시키는 것을 목적으로 한다.
전자를 백앤드, 후자를 프론트앤드로 역할을 나누고 각가 전문 영역을 집중할 수 있게 만드는 아키텍처 설계를 'BFF(Backend Fro Frontends)' 라고 한다.
BFF의 개념를 구성도로 그려보면 다음과 같다.
이와 같이 BFF는 Reverse Proxy와 Backend API 서버 사이에 구축하는 구성을 갖는 경우가 많다. Reverse Proxy는 정적 리소스 파일을 압축하거나 리소스를 캐싱하는 등 웹 어플리케이션 서버의 역할을 대신하기 위한 서버이다. 백앤드 API 서버는 주로 데이터베이스나 미들웨어와 연계하여 데이터를 다루거나 관리하는 역할로 동작한다.
BFF는 이 2개의 서버 사이에서 웹페이지를 구축하거나 사용자로부터 입력 정보를 받아 백앤드로 전송하거나 하는 UI/UX에 관한 기능을 담당한다.
좀 더 자세한 내용을 알고 싶다면 'Building Microservices'의 저자인 Sam Newman의 블러그 'Pattern: Backends For Frontends' 기고(https://samnewman.io/patterns/architectural/bff/) 내용을 참고하기 바란다.
2. BFF가 왜 필요할까?
BFF(Backend For Frontends)가 왜 필요한지 이해라려면 애플리케이션의 내부 구조가 시대에 따라 어떻게 변화하고 있는 지에 대해 알아야 한다.
예전 웹어플리케이션은 HTML을 기반으로 개발되었으며 동작도 간단했다. CGI가 주류를 이루고 있을 때에는 주로 HTML로 화면을 구성하고 JavaScript로 동적인 요소를 추가하는 정도의 애플리케이션이 많았다. 이 시대의 웹어플리케이션은 주로 단일 서버로 구성되는 경우가 많았고 데이터베이스 조회부터 HTML 을 만드는 것 같이 하나의 애플리케이션으로 구축되었습니다.
2000년대로 들어오면서 JavaScript로 HTTP 요청을 하는 'Ajax' 기반 통신이라는 개념이 나오면서 점차 웹어플리케이션은 리치해지고 인터액티브해 졌다. 리치 웹어플리케이션이 늘어나면서 클라이언트에서의 처리가 늘어나면서 서버단은 API로 데이터만 송수신하는 방식의 아키텍처가 증가되었다.
또한 웹어플리케이션뿐만 아니라 모바일 애플리케이션 등 클라이언트가 다양해짐에 따라 서버는 비즈니스 로직에만 집중하는 형태의 AIP를 구축하는 형태로 발전하고 있습니다. 마이크로서비스(MSA)라고 불리는 '툭정 리소스를 다루는데 특화된 아키텍처'로 발전하고 있다.
하지만 클라이언트 환경이 다양해지면서 모든 클라이언트의 요구 사항을 대응하는 API 서버를 만드는 것을 어려워지고 있다. 모바일 애\어플리케이션과 웹애플리케이션을 만들 때에도 UI를 동일하게 가져갈 수 없다. 또한 클라이언트에 따라 요구되는 항목이 다른 경우가 있다. 예를 들어 웹애플리케이션을 만든 경우라도 PC나 스마트폰은 화면의 해상도가 다르기 때문에 사용자에게 보여지는 정보가 달라지거나 모바일 애플리케이션과 완전히 다른 UI를 가져가는 경우도 있다.
게다가 웹애플리케이션은 HTTP/1.1 에서 동시에 요청할 수 있는 요청 수가 6개까지로 제한되어 있는 것 같은 환경적인 제약 사항도 있다.
이런 상황을 감안하여 프론트엔드 측에서 클라이언트 별 요구 사항에 대응하기 위히 서버를 구성하고 백엔드 API서버와 연동하는 역할을 하는 아키텍처가 개발되었다. BFF로 HTML을 구축하거나, 요청(request) 수를 줄일 수 있는 등의 장점이 있기 때문입니다.
이와 같이 'BFF' 아키텍처가 나오게 되었다.
3. BFF는 누가 담당해야 하나? (Frontend vs Backend Engineer)
BFF는 클라이언트 측을 담당하는 프론트엔드 개발자가 개발에 대한 역할을 담당하는 경우가 많다. 하지만 BFF는 서버 측이기 때문에 백엔드 개발자가 개발해야 한다고 생각하는 경우도 있지만, UI를 구성하고 다루는 서버 측이므로 프론트엔트 개발자의 담당 영역으로 보는 것이 맞다.
BFF 아키텍처에서는 백엔드 개발자는 API를 기반으로한 리소스 관리가 담당 영역으로 불 수 있다.
4. BFF 아키텍처 패턴
BFF의 아키텍처 패턴에는 '프런트엔드 전용 서버를 둠으로서 UI을 구축하기 쉽게 하는' 효과와 '프런트엔드와 백엔드의 경계를 두고 아키텍처의 레이어를 분할함으로써 역할을 명확히 하고 독립적으로 개발을 쉽게할 수 있는' 효과가 있다.
예전에는 JSP 처럼 BE/FE가 한 소스 안에서 동작하였는데, BFF 패턴에 따라, FE 서버와 BE 서버로 나누어 개발하게 되었다
BFF의 아키텍처 패턴은 '백엔드와 프런트엔드가 조직적으로 나누어져 독자적으로 개발을 진행하려고 할 때' 적용 할 수 있다. 또한 BFF는 '다양한 클라이언트를 지원해야 하며, 각각의 클라이언트가 동일한 API을 이용하려고 할 때' 에 API을 정리하는 레이어로도 쓰인다. 웹애플리케이션의 경우는 HTML(화면단)을 구축하기 위한 계층으로 활용할 수도 있다.
반대로 BFF 패턴을 채용하지 않는 경우에는 그 반대의 경우이다. 백엔드와 프런트엔드 구분 없이 개발하며 개발 담당자의 책임 범위를 넓힘으로써 효율적으로 개발하고 요구사항에 대한 커뮤니케이션 시간을 줄일 때에 유용하다. 클라이언트의 종류가 1개 정도라면 BFF가 없이도 백엔드 서버가 HTML을 구축하거나 API을 특정 클라이언트 전용으로 구축을 진행하면 문제 없다.
BFF는 개발 프로세스나 개발하는 대상에 따라 개발 방식이 적합한지 결정되기 떄문에 프로젝트 환경에 맞게 적용할 것을 권장한다.
5. BFF 사례 소개 - Netflix, Twitter, Recruit Technologies
BFF 아키텍처 적용 사례에 대해 설명한다.
5.1. Netflix 사례
Netflix에서는 BFF라는 아키텍처에 대한 이름이 생기기 전부터 BFF와 같은 아키텍처를 도입하고 있었다. Netflix의 기술 블로그 'Embracing the Differences:Inside the Netflix API Redesign' 에서는 2012년 시점에서 'Client Adapter' 라는 이름으로 소개되고 있다.
('Embracing the Differences:Inside the Netflix API Redesign' 블러그에서 인용함)
BFF라는 아키텍처 자체는 이전부터 사용되었으며 최근에서야 BFF라는 이름이 붙었을 뿐이다. 사실은 예전부터 BFF 아키텍처로 구축하고 있는 회사도 많았다. 특히 Netflix에서는, 다양한 클라이언트, 즉 PC나 모바일뿐만 아니라 게임기나 자동자 네비게이션과 같은 디바이스에서도 사용되고 있었으며 클라이언트가 다양해져서 1개 API로 모든 클라이언트를 지원하는 ('one size fit all') API로 만든다는 것은 상당히 어려운 일이며 이로 인해 이 Client Adapter패턴이 생겨났다고 소개되어 있다.
5.2. Twitter 사례
Twitter에서는 모바일 웹을 지원하는 'Twitter Lite'라고 불리는 애플리케이션을 개발하고 있는데 이 애플리케이션도 BFF 아키텍처로 구축되고 있다.
백엔드의 API는 Scala 기반으로 마이크로 서비스로 구축되어 있고, 그것을 웹애플리케이션으로서 페이지를 출력(랜더링)할 때 Node.js를 사용하여 API을 제공하고 있다.
Twitter는 원래 단독 서버 방식으로 Ruby on Rails로 구축되고 있었지만 시대적인 요구 사항에 따라 스케일 아웃 기능이 필요하게 되어, Scala기반 마이크로 서비스로 재구축되었고 UI/UX를 최적화하는 구조로 BFF가 도입되어 현재의 아키텍처를 구축하게 되었다.
자세한 것은 Twitter의 기술 블로그 'How we built Twitter Lite' 를 참조하세요.
5.3. Recruit Technologies 사례
Recruit Technologies 에서는 이미 BFF 기반으로 시스템을 구축하고 있다. 예를 들어, 자사 서비스로 운영하고 있는 'bookingtable' 사이트는 BFF 기반으로 구축되어 있다. 그 외에도 SNS나 설문 애플리케이션, 스케줄 관리 애플리케이션 등도 BFF 아키텍처로 구축되어 있다.
기본적으로는 다음과 같은 아키텍처로 구축하고 있다. .
API에 대한 일괄 처리, HTML 렌더링 처리를 하는 BFF의 계층은 Node.js로 구축하고 있다. 여기에는 몇가지 이유가 있지만 가장 큰 이유는 Node.js로 구축하게되면 프론트앤드의 JavaScript와 동일한 언어를 사용할 수 있기 때문이다. 백엔드 API는 Java와 Go로 개발되어 있으며 시스템의 데이터를 관리하기 쉬운 언어로 개발하고 있다.
6. 정리
BFF 개념과 적용 사례에 대해 설명하였다. BFF는 새로운 기술이 아니고 예전부터 엔터프레이즈 아키텍처에 적용되어 있었고 BFF 기반으로 시스템을 구축도 하고 있었다.
최근 BFF 아키텍처는 마이크로 서비스가 적용이 되면서 서버 측에 비해 클라이언트 측에 대한 요구사항이 많아 졌으며 프론트엔트 개발자가 클라이언트 뿐만 아니라 서버를 개발할 필요성도 나오게 되었고 구현 방법에 대해서도 기존 개발 방식이 아닌 다양한 개발 패턴이 나오게 되었다.
다음번에는 실제 BFF 기반 개발 패턴에 대해서 정리해 보겠다 ; )
최근댓글