BFF(Backend For Frontend)?

 

 

요즘 프론트엔드와 백엔드가 분리된 구조가 당연해지고, 서비스가 커지면 자연스럽게 MSA(마이크로서비스 아키텍처)로 넘어가는 경우가 많아졌다.
이런 흐름 속에서 등장한 개념 중 하나가 바로 **BFF(Backend For Frontend)**다.

처음엔 이게 뭔가 싶었는데, 알고 보면 꽤나 실용적인 패턴이었다.
한 마디로 말하면, 프론트엔드가 더 편하게 일할 수 있도록 도와주는 백엔드라고 보면 된다.

---

BFF가 뭐지?

기존의 백엔드는 하나의 공통된 API 서버를 통해 프론트의 요청을 처리했다. 웹이든, 모바일이든, 똑같은 API를 사용해야 했고, 거기에 맞춰 데이터를 가공해서 써야 했다.

근데 이제는 웹, 모바일, 태블릿 등 사용자 환경이 다양해지다 보니 모두에게 딱 맞는 API 하나를 만드는 게 점점 어려워지고 있다.

그래서 나온 게 바로 BFF다.

BFF는 말 그대로 "프론트엔드를 위한 백엔드"다.
각 클라이언트(Web, Android, iOS 등)가 자기만의 백엔드를 가지고, 거기서 필요한 데이터만 받아서 쓴다.

---

왜 필요한 걸까?

예를 들어 모바일 앱을 생각해보자.
모바일은 화면도 작고, 보여줄 수 있는 정보도 제한적이다.
웹에서 쓰는 API를 그대로 가져다 쓰면 너무 많은 데이터를 받아오게 되고,
그걸 다시 프론트에서 필터링하거나 조합해야 하는 번거로움이 생긴다.

이런 상황에서 모바일 전용 BFF가 있다면?

• 모바일에 필요한 데이터만 추려서 내려줄 수 있고,
• 여러 API를 하나로 묶어서 요청 횟수도 줄일 수 있고,
• 화면에 맞는 포맷으로 응답도 재구성할 수 있다.

덕분에 프론트엔드 개발자는 복잡한 비즈니스 로직을 프론트에서 덜어내고,
좀 더 화면에 집중할 수 있게 된다.

---

AWS는 이렇게 설명한다 :: AWS에서도 BFF 패턴을 공식적으로 설명하고 있다.

"하나의 사용자 경험에 맞춘 하나의 백엔드가 요구된다."

즉, 어떤 목적을 위한 공통 API가 아니라,
각 사용자 환경에 최적화된 전용 백엔드가 필요하다는 얘기다.

---

BFF 구조, 이렇게 생겼다

• Web → Web용 BFF → 여러 마이크로서비스 호출
• iOS → iOS용 BFF → 필요한 데이터만 가공
• Android → Android용 BFF → 모바일 전용 응답 구성

프론트엔드가 필요한 데이터를 직접 조합해서 가져가지 않아도 되니까,
불필요한 데이터 낭비도 줄고, 코드도 훨씬 깔끔해진다.

장점

• 프론트 입맛에 맞는 API 구성 가능
• API 응답 가공도 백엔드에서 처리 → 프론트 코드 간결해짐
• 프론트 주도 개발이 가능 → FE와 BE 간 충돌 줄어듦
• 각 클라이언트의 UX 최적화 가능

단점

• BFF 개수 늘어나면 관리 포인트도 늘어남
• 공통 기능(인증, 로깅 등)을 BFF마다 중복 구현해야 할 수도 있음
• 운영/배포 관리가 복잡해질 수 있음

---

언제 쓰면 좋을까?

• 웹/모바일/앱의 UI 구성과 데이터 사용 방식이 많이 다를 때
• 프론트엔드 팀이 빠르게 주도적으로 개발하고자 할 때
• API 호출 수나 트래픽 최적화가 필요한 경우
• 마이크로서비스를 여러 개 조합해서 하나의 응답으로 묶어야 할 때