| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
- Git
- version-control
- API
- HTTP
- SRE
- Kubernetes
- web
- Debugging
- CSS
- architecture
- backend
- frontend
- auth
- Infra
- reliability
- Performance
- Operations
- 버전관리
- Ops
- Microservices
- observability
- DevOps
- JavaScript
- Security
- aws
- react
- database
- CI
- NextJS
- 성능
- Today
- Total
고민보단 실천을
API Gateway vs BFF 패턴: 라우팅/인증/집계를 어디에 둘까(실무 선택 기준) 본문
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는 '서버'이므로 모니터링/재시도/타임아웃/보안까지 운영 책임을 같이 가져가야 합니다.
참고/출처
버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.
