Backend for Frontends
Backend for Frontends는 웹, 모바일, 파트너 포털처럼 서로 다른 클라이언트 채널마다 전용 백엔드를 두는 패턴입니다. 핵심은 도메인 서비스를 클라이언트가 직접 조합하게 두지 않고, 각 채널에 맞는 응답 형태와 호출 흐름을 중간 계층에서 맞춰 주는 것입니다. 같은 비즈니스 기능을 다루더라도 채널마다 필요한 데이터와 호출 빈도, 인증 방식이 다르다는 사실을 구조에 반영합니다.
▶아키텍처 다이어그램
🔗 관계 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
하나의 공통 API가 모든 채널을 만족시키려 하면 응답이 애매해지기 쉽습니다. 웹은 화면 하나를 위해 여러 리스트와 상세 정보를 한 번에 원하고, 모바일은 네트워크 비용 때문에 꼭 필요한 데이터만 받고 싶어합니다. 파트너 API는 안정된 계약과 긴 호환성을 요구할 수 있습니다. 이 차이를 하나의 공통 게이트웨이에서 모두 해결하려 하면 응답은 비대해지고, 프런트엔드는 여러 내부 서비스를 직접 호출하며 결합도가 올라갑니다.
초기 서버 렌더링 시대에는 클라이언트 종류가 많지 않았고, 하나의 백엔드가 대부분의 화면을 커버할 수 있었습니다. 그러나 SPA, 모바일 앱, 다양한 디바이스 경험이 늘어나면서 채널별 요구가 크게 벌어졌습니다. 같은 도메인이라도 웹과 앱이 원하는 응답 구조와 캐시 전략이 달라졌고, 프런트엔드 팀이 자기 채널의 사용자 경험을 더 빠르게 개선하고 싶어 했습니다. 이 압력이 BFF 패턴을 자연스럽게 만들었습니다.
클라이언트는 자기 채널 전용 BFF에 요청을 보냅니다. BFF는 내부 도메인 서비스 여러 개를 호출해 화면에 맞는 응답으로 조합하거나, 채널별 인증과 캐시 정책을 적용합니다. 웹 BFF와 모바일 BFF는 같은 도메인 서비스를 보더라도 서로 다른 응답 스키마와 호출 전략을 가질 수 있습니다. 중요한 점은 BFF가 새로운 도메인 규칙을 소유하는 곳이 아니라, 채널 최적화와 경험 조합을 담당하는 곳이어야 한다는 것입니다.
API Gateway와 BFF는 모두 진입점 역할을 하지만 수준이 다릅니다. API Gateway는 모든 외부 요청에 공통으로 적용할 인증, 라우팅, 속도 제한 같은 입구 정책을 맡습니다. BFF는 그 위나 뒤에서 채널별 화면 요구를 맞춥니다. 즉 Gateway는 공통 입구이고, BFF는 채널별 맞춤 조합 계층입니다. 클라이언트가 하나뿐이거나 채널 간 요구 차이가 작다면 BFF를 따로 두는 비용이 과할 수 있습니다.
웹과 모바일이 같은 도메인을 보지만 필요한 응답 구조가 자주 달라지거나, 프런트엔드 팀이 백엔드 릴리스와 독립적으로 화면 API를 조정해야 할 때 적합합니다. 특히 홈 화면처럼 여러 서비스를 조합해야 하는 복합 UI에서 효과가 큽니다. 반대로 BFF 안에 도메인 규칙이 쌓이기 시작하면 채널별 중복이 늘고, 결국 또 다른 핵심 서비스처럼 비대해질 수 있으므로 역할을 엄격히 제한해야 합니다.