[ 아키텍처 ] 프론트엔드를 위한 백엔드 아키텍처(BFF)

프론트엔드를 위한 백엔드, Backends For Frontends(BFF)

 

시간이 지나면서 서비스가 제공하는 프론트 엔드의 코드가 점점 더 복잡해지고 다양해지는 경우는 허다하다. 이에 따라 백엔드 또한 기능 제공을 위해 복잡해지게 된다. 따라서 다양한 프론트엔드 유형의 기능을 지원하는 백엔드 서비스가 필요성이 생겨나게되었고, 이를 위해 BFF 가 탄생하게 되었다.

• 웹 서비스만 제공하던 서비스에서 모바일 서비스를 제공해야하는 경우, 새로운 유형의 프론트엔드를 도입해야한다.(모바일기기의 성능과 데스크톱의 성능이 다르기 때문)
• 새로운 서비스(모바일)을 제공하기 위해서는 백엔드에서도 모바일에 특화된 코드와 기능을 추가해야한다.
  • 모바일 기기는 화면 크기가 더 작으므로, 기존의 API가 아닌 새로운 API 를 통해 더 작거나 다른 데이터를 전송해야한다.
  • 전체 사용자 경험을 다시 고려하여, 클라이언트 측 작업을 서버 측으로 넘겨야 할 수도 있다.

 

BFF 는 서비스하는 프론트엔드의 유형에 따라 개별 백엔드로 나누는 아키텍처 패턴을 말한다. 이를 적용할 경우 다음과 같은 장점을 얻을 수 있다.

• 각 백엔드 서비스에는 연관된 프론트엔드의 기능만 포함되어, 코드베이스가 작아지고 런타임은 더 가벼워질 수 있다.
• 코드가 특정 프론트엔드에 특화된 코드이기 떄문에 궁극적으로 사용자 경험이 개선될 수 있다.
• 조직 전체의 관점으로, 각 프론트엔드와 백엔드를 쌍으로 묶어 해당 플랫폼만 담당하는 개발 팀을 구분할 수 있다.

 

BFF가 없다면?(다른 유형의 프론트엔드에서 획일화된 백엔드 서비스를 제공할 경우)

 

모놀리식 백엔드 서비스 를 제공하게 된다면, 점점 더 비대하고 복잡하며, 환경에 알맞는 최적화된 기능을 제공하지 못할 수 있다.

• 다른 유형의 프론트엔드에서 획일화된 백엔드 서비스를 제공할 경우, 각 프론트엔드가 가진 모든 기능을 활용할 수 없을 가능성이 높다.
• 특정 기기 혹은 모든 기기의 사용자에게 최적의 경험을 제공하지 못할 수 있다.

 

---

BFF를 도입하면서 고려해야 할 사항

 

백엔드를 개별 서비스로 나누면서 공유(재사용)할 수 있는 기능들이 여러 백엔드에 중복 될 수 있는 문제와 백엔드 패턴을 얼마나 세분화 할지 등 적용이전에 고려해야할 내용들이 존재한다.

 

백엔드를 개별 서비스로 나누면서 공유(재사용)할 수 있는 기능들이 여러 백엔드에 중복 될 수 있다.

각각의 다른 환경에서 사용자의 입력 값 과 백엔드 비즈니스 로직은 동일하다. 따라서 모든 공유 로직과 API 를 포함하는 공유 라이브러리 를 구성하여 여러 백엔드 서비스에서 재사용 할 수 있다.

• 변경사항이 적은 로직일 경우 적합하다.
• 라이브러리 형태로 여러 코드베이스에 공유하는 것은 코드베이스의 강한 결합과 팀 간 마찰의 원인이 될 수 있다.
  • 공유 라이브러리가 수정될 경우, 이를 사용하는 모든 백엔드에 영향이 갈 수 있다.
• 공유 라이브러리 형태의 경우, 코드의 품질이나 일관성, 릴리스 일정 등의 책임 소재를 구분하기가 어려워질 수 있다.

 

따라서, 변경사항이 많은 경우에는, 공유 라이브러리의 단점을 보완하기 위해 공유 기능을 개별 서비스로 만드는 것이 좋다.

• 공유 서비스로 정의함으로써, 범위와 API, 소유하는 팀을 명확힐 할 수 있다.

 

프론트엔드를 위해 얼만큼 세분화 할 것 인가?

모바일용 백엔드와 데스크톱용 백엔드, 혹은 iOS, Android, 데스크톱 으로 나눌지 등 얼마나 세분화 할 것인지 결정해야한다.

• 이 결정은 기기의 유형에 따른 개발 유형에 따라 달려있으며, 개발 유형이 달라지는 경우 세분화를 하고 그렇지 않을경우 세분화는 무의미하다.