BFF(Backend For Frontend) 가 과연 UI 패턴 영역일까?, 아니면 API Gateway의 패턴 영역일까?

BFF(Backend For Frontend) 가 과연 UI 패턴 영역인지, 아니면 API Gateway의 연장선인지는 클라우드 네이티브 MSA 아키텍처 관점에서 설계 구조상 매우 중요한 결정입니다.

결론부터 말씀드리면:

🔷 BFF는 "UI 패턴의 확장 개념"에 더 적합하며, API Gateway와는 역할 경계가 명확히 분리됩니다.

 

클라우드 네이티브 MSA 아키텍처에서의 구성 영역

 

구성요소	주 책임영역	분류
MFE (Micro FE)	UI 단위의 분리/배포	UI 패턴
BFF	화면 맞춤 API 조합/포맷팅	UI 패턴 / 표현 계층 확장
API Gateway	인증, 권한, 라우팅, 공통 정책	인프라 / 보안 계층

➡ BFF는 “화면에 맞는 API 제공자”로서, 표현 계층(View Layer) 확장의 일부로 간주됨

BFF와 API Gateway의 책임 분리

항목	BFF	API Gateway
주 목적	UI에 맞는 API 응답 가공 / 통합	API 호출의 인증, 권한, 라우팅, 속도 제한 등 제어
데이터 조합	여러 마이크로서비스에서 수집한 데이터 조합	없음 (단일 서비스 라우팅 중심)
도메인 인지	UI와 밀접한 도메인 지식 포함	도메인 지식 없음 (경로 기반 정책 처리)
위치	UI팀 또는 FE 개발팀의 책임 선상	DevOps 또는 인프라 팀에서 관리

➡ BFF는 Gateway보다 프론트단 로직과 훨씬 더 밀접하게 연결되어 있습니다.

 

클라우드 네이티브 관점에서의 위치 정의

기준	적합한 위치 분류
UI 최적화를 위한 구성	✅ UI 패턴 내부의 확장 구성(BFF)
인증/정책/공통제어	✅ API Gateway (인프라 경계 제어)

 

즉, **BFF는 프론트엔드 개발자들이 API 조합을 담당할 수 있도록 설계된 ‘UI 중심 계층의 백엔드’**입니다.

---

설계 시 유의할 점

• BFF는 UI 도메인 별로 분리되는 것이 이상적 (ex: 상품조회용 BFF, 결제화면 BFF)
• API GW → BFF → MSA Backend 흐름으로 구성 시,
  • API GW는 보안/정책 중심
  • BFF는 화면-도메인 매핑 중심
• MFE와 조합 시, 각 MFE ↔ 전용 BFF 간 호출 구조가 가장 유지보수성과 유연성 높음

 

결론

 

질문	해답
BFF는 UI 패턴 영역인가?	예. BFF는 표현 계층(View Layer)의 확장 구성입니다.
API GW와 유사한가?	아니오. API GW는 인증·속도제어·로깅 등 기술 정책 관리를 담당합니다.
클라우드 네이티브 MSA에서 어디에 위치하는가?	BFF는 UI/MFE 영역의 일부로 설계되어야 하며, API Gateway와 분리되어야 합니다.

---

이글이 도움이 되셨으면 아래↓의 [공감] 버튼과 우측상단↗의 [구독하기] 클릭 부탁드려요 ^^