화면 단위의 복잡성을 흡수하다: 여기어때 BFF의 기록

여기어때는 주문, 검색, 쿠폰, 리뷰, 항공, 결제 등 도메인별로 분리된 MSA 구조를 운영하지만, 화면 관점에서는 한 페이지를 위해 여러 API를 조합해야 하는 문제가 커졌다. 2025년 12월 기준 B2C Gateway에 등록된 서비스만 약 50여 개에 이르며, 클라이언트는 검색 결과, 리뷰, 쿠폰, 포인트, 주문 상태 같은 데이터를 직접 모아야 했다.

이때 등장한 해법이 BFF(Backend For Frontend) 다. BFF는 단순한 라우팅 계층이 아니라, 특정 화면이 요구하는 데이터 구조에 맞춰 여러 도메인 API를 Aggregate하고, 도메인 모델을 ViewModel로 변환하며, 화면 단위의 비즈니스 분기와 병렬 호출까지 흡수하는 UI-Driven 서버 계층으로 정의된다.

기존 구조에서는 클라이언트가 Gateway를 거쳐 각 도메인 API를 직접 호출하면서 메쉬업, 데이터 조합, 분기 로직을 모두 떠안았다. BFF 도입 후에는 클라이언트가 단 하나의 BFF API만 호출하고, 내부 Private Zone에서 BFF가 필요한 도메인 데이터를 빠르게 모아 정제된 응답을 내려준다.

실제 적용 사례로는 파트너센터와 광고센터가 소개된다. 주문 내역 상세 화면 하나를 구성하려면 주문 정보, 결제 정보, 제휴점 정보, 잔여금 내역, 카드/가상계좌 내역, 추가 주문 정보 등 7~8개 API가 필요했고, CTA 노출 여부도 결제 상태, 계약 동의, 결제 수단, 중지 여부 같은 조건을 종합 판단해야 했다. 자동이체의 경우에는 출금 요청 정보를 추가로 조회해야 해 응답 모델 자체를 별도로 분리했다.

결과적으로 BFF는 화면 단위의 복잡성을 서버로 옮겨 다중 API 호출 제거, 클라이언트 로직 단순화, 상태 분기 로직 중앙화, 변경 대응 속도 향상을 이끌었다. 다만 중간 계층이 늘어나는 만큼 장애 전파(cascading failures) 와 메모리/힙 과부하 같은 문제도 생기며, 이를 위해 Spring Retry 기반 지수 백오프, 빠른 실패/대체 응답, Circuit Breaker 검토, 강제 페이징, Caffeine cache 같은 운영 장치가 함께 필요했다.

핵심은 MSA가 도메인을 잘게 나누는 구조라면, BFF는 사용자가 실제로 마주하는 ‘하나의 화면’ 단위로 그 복잡성을 다시 흡수하는 레이어라는 점이다.