고민보단 실천을

API Gateway vs BFF 패턴: 라우팅/인증/집계를 어디에 둘까(실무 선택 기준) 본문

카테고리 없음

API Gateway vs BFF 패턴: 라우팅/인증/집계를 어디에 둘까(실무 선택 기준)

Just-Do-It 2026. 3. 23. 20:59

API Gateway vs BFF 패턴: 라우팅/인증/집계를 어디에 둘까(실무 선택 기준)

게이트웨이에 모든 걸 넣으면 거대한 단일 장애 지점이 되고, BFF를 남발하면 중복이 폭발합니다.
API Gateway와 BFF의 책임 경계를 '실무 기준'으로 나눠 봅니다.

이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.

왜 이게 어려운가(운영 관점)

API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.

특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.

실전 내용(바로 적용)

게이트웨이에 모든 걸 넣으면 거대한 단일 장애 지점이 되고, BFF를 남발하면 중복이 폭발합니다.
API Gateway와 BFF의 책임 경계를 '실무 기준'으로 나눠 봅니다.

핵심 요약(결론부터)

  • 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
  • 실패/예외/회귀를 운영 체크리스트로 막는다
  • 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다

각 패턴이 잘 맞는 상황

Gateway: 공통 라우팅/인증/기본 레이트리밋/관측
BFF: 화면/클라이언트별 응답 조합, UX 최적화

실패하는 패턴

Gateway에 도메인 권한/비즈니스 로직까지 넣어 변경이 어려워짐
BFF마다 같은 권한/검증 로직을 복제해 일관성이 깨짐

결정 체크리스트

이 로직이 모든 클라이언트에 동일한가? -> Gateway 후보
도메인 데이터/권한이 필요한가? -> 서비스/BFF에서
장애 시 영향 범위가 큰가? -> 중앙화는 신중하게

운영 체크리스트(바로 적용)

  • Gateway는 공통/단순 규칙 위주로(정책) 유지한다
  • BFF는 화면 단위로 수명주기를 맞춘다
  • 중복이 생기는 검증/권한은 라이브러리/정책으로 공유한다

FAQ

Q. BFF를 Next.js로 하면 되나요?
A. 가능합니다. 다만 BFF는 '서버'이므로 모니터링/재시도/타임아웃/보안까지 운영 책임을 같이 가져가야 합니다.

마무리: 다음 액션

  • 팀의 기본값(정책)을 1페이지로 문서화한다
  • 대표 시나리오 1개를 코드/설정 예시로 고정한다
  • 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다

자주 하는 실수(사고 패턴)

  • 결정 기준 없이 팀원 취향으로 기술을 고른다
  • 문서(스키마)와 구현이 어긋난 상태를 장기간 방치한다
  • 재시도/타임아웃을 '늘리기'만 하고 예산/정렬을 안 맞춘다
  • 장애 시나리오(429/timeout/partial failure)를 테스트에 넣지 않는다

적용 순서(추천)

  • 1) 바꾸려는 것(성능/보안/호환성/운영 단순화)을 한 문장으로 정의한다
  • 2) 기본값과 예외를 먼저 정하고, 예외는 만료일/사유/소유자를 남긴다
  • 3) 대표 시나리오(요청/응답 예시)를 만들어 계약으로 고정한다
  • 4) 지표(p95/p99, 오류율, 재시도율)로 배포 전후를 비교한다
  • 5) CI/PR에서 자동 검증(린트/스키마 diff/계약 테스트)을 걸어 회귀를 막는다

검증/회귀 방지

  • 배포 전후 지표(p95/p99, 4xx/5xx, 재시도율)를 동일 조건으로 비교
  • 프록시/CDN/게이트웨이 설정 변경 이력을 남기고, 롤백 플랜을 준비
  • 대표 시나리오를 e2e 테스트로 고정(문서가 아니라 테스트가 계약이 되게)

팀 합의 템플릿(복붙용)

# 팀 합의 템플릿(복붙용)
목표: (예) 구버전 클라이언트 유지하면서 응답 스키마 변경
기본값: (예) /v1 경로 버전 사용
예외: (예) 내부 API는 헤더 버전 허용(게이트웨이 필수)
대표 시나리오: (요청/응답 예시 첨부)
모니터링: (오류율/지연/트래픽) 대시보드 링크
EOL/변경 정책: (날짜/공지 채널/롤백 규칙)

FAQ

Q. BFF를 Next.js로 하면 되나요?
A. 가능합니다. 다만 BFF는 '서버'이므로 모니터링/재시도/타임아웃/보안까지 운영 책임을 같이 가져가야 합니다.

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

Comments