Search

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

URL
생성 일시
2026/03/10 10:06
최종 편집 일시
2026/03/10 10:06
태그
여기어때
파일과 미디어
|| 안녕하세요. 여기어때컴퍼니 항공연동개발팀(전 BFF개발팀) 리나입니다. 이번 글은 올해 2월까지 BFF개발팀으로서 근무하며 경험했던 내용을 바탕으로, “왜 BFF가 필요했는지” 그리고 “BFF팀이 어떤 역할을 수행했는지”를 정리한 기록입니다. 여기어때는 주문, 검색, 쿠폰, 리뷰, 항공, 결제 등 각 도메인 팀이 독립적으로 운영되는 MSA 구조를 기반으로 서비스되고 있습니다. 도메인 단위로 분리된 구조는 확장성과 자율성을 보장하지만, 화면 단위로 보면 또 다른 문제가 발생합니다. “한 화면을 구성하기 위해 왜 이렇게 많은 API를 호출해야 할까?” 이 질문에서 BFF 도입이 시작되었습니다. 1. 잘 나뉜 도메인, 그러나 무거워진 화면 현재 여기어때의 백엔드는 거대한 시스템을 도메인 단위로 나눈 MSA(Microservices Architecture) 구조로 이루어져 있습니다. 2025년 12월 기준으로 B2C Gateway(GW)에 등록되어 사용 중인 서비스는 약 50여개에 달합니다. 주문결제, 유저혜택, 숙소, 검색, 전시, 패키지, 항공 등 수많은 도메인 팀이 각자의 Bounded Context 내에서 전문성 있게 API를 제공하고 있습니다. 하지만 데이터를 소비해야 하는 클라이언트(iOS, Android, Web) 입장에서는 어떨까요? 앞서 말씀드린 MSA 환경에서는 도메인이 세분화된 만큼 프론트엔드의 고충이 커지게 됩니다. 예를 들어, 새롭게 기획된 화면에서 아래 정보가 동시에 필요하다고 가정해보겠습니다. 검색 결과 리뷰 정보 쿠폰 및 혜택 포인트 잔액 주문 상태 이 경우 클라이언트는 5개 팀의 API를 모두 호출하여 조합하는 무거운 복잡한 연산을 수행해야합니다. 이러한 방식에는 다음과 같은 문제가 발생합니다. 네트워크 오버헤드: 5개의 API를 순차 또는 병렬로 호출하면 응답 시간이 크게 지연됩니다. 클라이언트 복잡도 증가: 각기 다른 API의 데이터를 화면에 맞게 맵핑하는 무거운 연산 로직을 앱과 웹에 구현해야 합니다. 중복 개발 및 유지보수 난이도: iOS, Android, Web 각각에서 동일한 데이터 조합 로직을 반복 구현해야 하며, API 변경 시 모든 플랫폼을 수정해야 합니다. 에러 처리의 어려움: 5개 API 중 1개만 실패해도 전체 화면을 에러 처리할지, 부분만 렌더링할지 클라이언트 단에서 복잡하게 처리해야 합니다. 즉, 도메인은 잘 나뉘어 있었지만화면 단위 복잡성은 클라이언트에 남아 있었습니다.2. BFF란 무엇인가BFF(Backend For Frontend)는 단어 뜻 그대로 ‘프론트엔드를 위한 백엔드’를 의미합니다. 도메인 API가 기능 단위라면, BFF API는 화면 단위입니다. BFF는 단순 라우팅 레이어가 아닌, 특정 클라이언트의 화면(UI)이 요구하는 데이터 구조에 맞춰 여러 도메인 API를 조합하고 가공하는 UI-Driven 서버 계층입니다. BFF의 핵심 역할은 다음과 같습니다. 여러 도메인 API 결과를 Aggregate 도메인 모델을 클라이언트 ViewModel로 변환 화면 단위 비즈니스 분기 로직 처리 내부 병렬 호출 및 성능 최적화 즉, 클라이언트가 하던 데이터 조합 책임을 서버로 이전하는 것.이것이 BFF 도입의 본질이었습니다.3. 구조의 변화일반적인 API 구조클라이언트 → Gateway → 각 도메인 API 기존의 여기어때 B2B/B2C Gateway는 단순한 트래픽 라우팅 역할에 가까웠습니다. 메쉬업, 데이터 조합, 비즈니스 분기 처리는 오롯이 클라이언트의 책임으로 남아있었고, 앱이 점점 무거워지는 원인이 되었습니다. BFF 도입 구조클라이언트 → BFF → (내부망) → 각 도메인 API 이제 클라이언트는 화면을 그리기 위해 단 하나의 BFF API만 호출합니다. BFF는 내부 Private Zone 망에서 여러 도메인 API를 빠르게 호출하고, 클라이언트가 화면을 그리기 편한 View Model 형태로 가공해 내려줍니다. 클라이언트는 복잡한 메쉬업 로직을 알 필요가 없어졌습니다. 4. 실제 적용 사례