핵심 인사이트 (3줄 요약)
- 본질: API 스로틀링(API Throttling)은 서비스 과부하와 남용을 막는 보호 메커니즘이고, BFF(Backend for Frontend)는 각 클라이언트에 최적화된 API 계층을 분리하여 오버패칭(Overfetching)과 언더패칭(Underfetching)을 해결한다.
- 가치: 토큰 버킷(Token Bucket), 리키 버킷(Leaky Bucket), 슬라이딩 윈도(Sliding Window) 알고리즘은 각각 버스트 허용, 균일 속도, 시간 정확성의 트레이드오프를 가진다.
- 판단 포인트: BFF 패턴은 클라이언트 종류가 다양(모바일/웹/IoT)하고 각각의 API 요구사항이 다를 때 효과적이며, 그렇지 않으면 GraphQL이 더 단순한 대안이다.
Ⅰ. 개요 및 필요성
API 스로틀링 필요성: 공개 API나 내부 MSA API 모두 무제한 요청을 허용하면 서버 과부하, DDOS(Distributed Denial of Service), 특정 클라이언트의 자원 독점이 발생한다. Rate Limiting(속도 제한)은 단위 시간당 요청 수를 제한하여 공정한 자원 배분과 서비스 안정성을 동시에 확보한다.
BFF 필요성: 하나의 범용 API가 모바일, 웹, IoT, TV 등 모든 클라이언트를 지원하려 하면:
-
오버패칭(Overfetching): 필요 없는 데이터까지 받아 대역폭 낭비
-
언더패칭(Underfetching): 필요한 데이터를 얻기 위해 여러 번 API 호출
-
클라이언트별 최적화가 불가능하여 모바일 성능 저하
-
📢 섹션 요약 비유: 스로틀링은 수도꼭지 조절 밸브이고, BFF는 각 방에 맞는 수압과 온도를 따로 설정하는 전용 배관이다.
Ⅱ. 아키텍처 및 핵심 원리
Rate Limiting 알고리즘 비교:
[토큰 버킷 (Token Bucket)]
버킷에 토큰이 채워짐 → 요청마다 토큰 소비
버킷이 비면 요청 거부 → 버스트(순간 폭주) 허용
[리키 버킷 (Leaky Bucket)]
큐에 요청을 쌓음 → 일정 속도로 처리
큐가 가득 차면 거부 → 균일한 출력 속도 보장
[슬라이딩 윈도 (Sliding Window)]
최근 N초 요청 수를 실시간 집계
고정 윈도의 경계 문제 해결 → 정확한 제한
| 알고리즘 | 버스트 허용 | 구현 복잡도 | 정확성 | 적합 사례 |
|---|---|---|---|---|
| 토큰 버킷 (Token Bucket) | ✓ | 낮음 | 중간 | API 게이트웨이 기본값 |
| 리키 버킷 (Leaky Bucket) | ✗ | 낮음 | 중간 | 균일한 업스트림 보호 |
| 슬라이딩 윈도 (Sliding Window) | 부분 | 높음 | 높음 | 정밀한 SLA 제어 |
| 고정 윈도 (Fixed Window) | 부분 | 매우 낮음 | 낮음 | 단순 구현 필요 시 |
BFF(Backend for Frontend) 아키텍처:
클라이언트 BFF 계층 마이크로서비스
┌────────┐ ┌────────────┐
│ 모바일 │────→│ Mobile BFF │─┐
└────────┘ └────────────┘ │ ┌──────────────┐
┌────────┐ ┌────────────┐ ├─→│ 주문 서비스 │
│ 웹 │────→│ Web BFF │─┤ ├──────────────┤
└────────┘ └────────────┘ ├─→│ 사용자 서비스 │
┌────────┐ ┌────────────┐ │ ├──────────────┤
│ IoT │────→│ IoT BFF │─┘ │ 상품 서비스 │
└────────┘ └────────────┘ └──────────────┘
각 BFF는 해당 클라이언트에 최적화된 집계(Aggregation), 변환(Transformation), 필터링(Filtering)을 담당한다.
- 📢 섹션 요약 비유: BFF는 각 손님(클라이언트)에게 맞춤 메뉴를 제공하는 전담 웨이터다 — 어린이 손님에겐 단 음식, 다이어트 손님에겐 저칼로리 메뉴를 따로 준비한다.
Ⅲ. 비교 및 연결
BFF vs GraphQL:
| 구분 | BFF | GraphQL |
|---|---|---|
| 유연성 | 클라이언트별 완전 최적화 | 단일 스키마로 유연한 쿼리 |
| 서버 복잡성 | BFF 서비스 수만큼 증가 | 단일 서비스 유지 |
| 타입 안전성 | 언어 종속 | SDL 스키마로 타입 보장 |
| N+1 문제 | BFF에서 사전 집계로 해결 | DataLoader 패턴 필요 |
| 적합 상황 | 클라이언트 종류 다양, 팀 분리 | 다양한 클라이언트, 중앙 집중 선호 |
API 버저닝 전략:
-
URI 버저닝:
/v1/users,/v2/users— 명확하지만 URL 중복 -
헤더 버저닝:
API-Version: 2— URL 깔끔하지만 캐싱 복잡 -
콘텐츠 협상:
Accept: application/vnd.api+json;version=2— RESTful하지만 구현 복잡 -
📢 섹션 요약 비유: GraphQL은 뷔페처럼 먹고 싶은 것을 원하는 만큼 가져올 수 있지만, BFF는 각 손님의 입맛을 미리 파악해 최적 정식을 차려주는 방식이다.
Ⅳ. 실무 적용 및 기술사 판단
기술사 시험 판단 포인트:
- 세 가지 Rate Limiting 알고리즘의 트레이드오프(버스트 허용, 구현 복잡도, 정확성)를 표로 비교한다.
- BFF 도입 근거를 "오버패칭/언더패칭"과 "클라이언트별 팀 독립 개발"로 정당화한다.
- Redis를 이용한 분산 Rate Limiting 구현(슬라이딩 윈도, Lua 스크립트 원자 연산)을 언급하면 깊이를 인정받는다.
실무 시나리오: 이커머스 모바일 앱 — 상품 목록 화면에서 상품 기본 정보 + 리뷰 수 + 재고 여부를 하나의 API로 제공해야 할 때, 범용 API는 3개 서비스를 각각 호출해야 하지만, Mobile BFF가 서버 측에서 집계하여 단일 최적화 응답 반환. 모바일 네트워크 요청 수 66% 감소.
- 📢 섹션 요약 비유: BFF 집계는 배달 대행 서비스가 여러 식당에서 음식을 대신 픽업해 한 번에 배달하는 것이다 — 손님은 한 번만 문을 열면 된다.
Ⅴ. 기대효과 및 결론
API 스로틀링과 BFF 패턴을 적용하면:
- 서비스 안정성: Rate Limiting으로 과부하, 남용, DDOS 부분 방어
- 클라이언트 성능: BFF로 오버패칭 제거, 모바일 데이터 사용량 감소
- 팀 독립성: 각 클라이언트 팀이 자체 BFF를 소유하여 독립 배포
- API 수명: 버저닝 전략으로 하위 호환성 유지하며 점진적 발전
API 설계는 기능 구현만큼이나 클라이언트 경험과 서비스 보호를 함께 고려해야 한다.
- 📢 섹션 요약 비유: 스로틀링과 BFF는 고속도로 설계의 두 축이다 — 스로틀링은 과속 방지 카메라(보호), BFF는 클라이언트별 맞춤 출구 램프(최적화)다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| API Gateway | 인증/인가, 라우팅, 로드밸런싱 · 505 |
| GraphQL | 스키마, 리졸버, N+1 문제 · 505 |
| Redis | 분산 캐시, 슬라이딩 윈도 카운터 · 506 |
| MSA (Microservice Architecture) | 서비스 집계, 팀 독립 · 505 |
| DDOS (분산 서비스 거부 공격) | Rate Limiting, WAF, CDN · 508 |
📈 관련 키워드 및 발전 흐름도
[인증 · 인가] → [API 스로틀링과 BFF 백엔드 포 프론트엔드] → [Rate Limiting · WAF]
👶 어린이를 위한 3줄 비유 설명
- API 스로틀링은 놀이공원 입장 줄처럼, 한 번에 너무 많은 사람이 들어오면 잠깐 기다리게 해서 놀이기구(서버)가 고장 나지 않게 해요.
- BFF는 각 반마다 다른 급식 메뉴를 제공하는 급식 담당 선생님이에요 — 운동부는 많이, 다이어트 반은 적게.
- 오버패칭은 도시락에 필요 없는 음식이 가득 담긴 것처럼, BFF가 딱 맞는 양만 담아주면 배낭(대역폭)이 가벼워져요.