그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

BFF(Backend For Frontend)란 무엇인가요?

실무4/5
설계4/5
인간4/5
기초2/5

면접관의 질문 의도

BFF를 용어로만 아는지, 언제 도입하고 어디까지 책임을 넘기는지까지 판단할 수 있는지를 가른다. 정의만 답하면 곧장 'API Gateway랑 어떻게 다른가요'로 좁혀 들어온다.

큐레이션 답변

학습 자료

BFF는 클라이언트와 백엔드 서비스들 사이에 두는 프론트엔드 전용 서버 계층이다. 여러 마이크로서비스 응답을 화면 단위로 한 번에 조합하고, 인증 토큰·CORS·응답 스키마 같은 횡단 관심사를 이 층에서 처리한다. 클라이언트는 한 곳에만 말하고, BFF가 백엔드 분산을 가린다.

좋은 답변 구조

  1. 01BFF가 어떤 계층이고 어떤 책임을 가지는지 정의한다
  2. 02다수 백엔드 호출·채널별 응답·횡단 관심사 중 BFF가 푸는 구체적 문제를 짚는다
  3. 03API Gateway와 책임 경계가 어떻게 다른지 한 문장으로 가른다
  4. 04한 층이 늘어나는 비용과 도입 트리거를 함께 말하며 마무리한다

자주 실수하는 포인트

API Gateway와 BFF를 같은 계층, 같은 책임으로 묶어서 답한다
BFF를 백엔드 응답을 그대로 흘려주는 프록시로만 구현해 클라이언트 복잡도가 그대로 남는다
웹·모바일·외부 채널을 한 BFF에 다 욱여넣어 또 다른 모놀리스로 키운다
소유 팀(프론트 vs 백엔드)을 정하지 않아 BFF 변경이 항상 다른 팀 일정에 끌려간다

실무 맥락

  • 한 화면을 그리려고 마이크로서비스 API를 서너 번씩 호출해야 하는 프론트엔드
  • 웹·iOS·안드로이드처럼 채널마다 응답 스키마가 달라야 하는 서비스
  • 토큰이나 서드파티 비밀 키를 브라우저에 내려주고 싶지 않은 결제·푸시 연동
  • 백엔드 팀이 자주 응답 구조를 바꾸는 환경에서 클라이언트 영향 범위를 좁히고 싶은 조직

본인 경험에 녹이는 힌트

한 화면에서 백엔드 API를 여러 번 부르며 클라이언트 코드가 무거워졌던 경험이 있다면 BFF 도입 전후 호출 구조를 비교해 말할 수 있다

웹과 모바일이 같은 응답을 받으면서 한쪽이 불필요한 필드까지 받던 경험을 채널별 BFF 분리 논의로 연결할 수 있다

백엔드 응답 스키마가 바뀔 때마다 프론트 코드를 같이 고쳐야 했던 경험을 BFF의 완충 계층 역할과 엮을 수 있다

토큰·서드파티 키를 클라이언트에서 다루다 보안 리뷰에 걸렸던 경험이 있다면 BFF의 인증 경계 책임으로 자연스럽게 이어갈 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1BFF와 API Gateway는 책임을 어떻게 나누나요
Q2BFF가 또 다른 병목이나 SPOF가 되지 않게 하려면 어떻게 설계하나요
Q3채널별로 BFF를 분리할지 한 BFF에 분기로 둘지 어떤 기준으로 결정하나요
Q4BFF는 프론트엔드 팀이 소유해야 하나요, 백엔드 팀이 소유해야 하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문