스로틀링과 서킷 브레이커: 외부 시스템 장애가 내 서비스까지 망치지 않게 막는 기술

외부 API가 느려지면 왜 내 서비스까지 같이 느려지는가

외부 결제나 문자 발송 API가 잠깐 느려졌을 뿐인데, 내 서비스의 로그인·주문·조회까지 전반적으로 지연되는 경험이 생긴다.

요청이 계속 쌓이면서 타임아웃이 늘고, 결국 정상 기능까지 같이 실패하는 현상이 반복되기도 한다.

스로틀링과 서킷 브레이커는 이런 연쇄 확산을 끊기 위해 “요청을 어떻게 제한하고, 언제 빠르게 차단할지”를 다루는 기술이다.

• 스로틀링이 요청 폭주를 어떻게 줄이는지
• 서킷 브레이커가 장애 전파를 어떻게 끊는지
• 둘을 어디에 적용해야 효과가 나는지
• 비교표와 YES/NO로 선택 기준 세우기
• 실제 장애 상황에서 확인·해결 절차 따라가기

스로틀링은 “너무 많이 들어오는 요청”을 제어하고, 서킷 브레이커는 “망가진 의존성”으로 가는 길을 끊는다

핵심 개념 1: 스로틀링은 처리 가능한 속도로 요청을 제한하는 방식이다

정의: 스로틀링(throttling)은 특정 사용자, 특정 IP, 특정 API, 특정 서비스에 대해 초당/분당 요청량 또는 동시 처리 수를 제한해 시스템이 버틸 수 있는 범위 안에서만 일을 받게 하는 기법이다.

핵심 특징: 요청이 폭주할 때 서버가 무한히 버티려 하지 않게 만들고, 과부하로 인한 전체 붕괴를 예방한다. 제한을 걸어도 완전히 멈추는 것이 아니라 “정상 범위의 요청은 계속 처리”하도록 설계하는 경우가 많다.

• 내부 동작 원리: 토큰 버킷, 리키 버킷 같은 알고리즘으로 “허용량”을 관리하며, 허용량을 넘으면 즉시 거절하거나(예: 429) 대기 큐로 보낼 수 있다.
• 범위: API 게이트웨이, 로드밸런서, 애플리케이션 미들웨어 등 여러 계층에 적용할 수 있다. 어디에 거느냐에 따라 차단 시점과 비용이 달라진다.
• 제약: 제한 정책이 너무 빡빡하면 정상 사용자까지 막혀 체감 품질이 떨어진다. 반대로 너무 느슨하면 과부하 상황에서 효과가 약해진다.
• 정리 필요성: “누가 얼마나 쓰는지”를 기록하지 않으면 제한 기준이 감에 의존하게 된다. 사용자군별 트래픽 분포를 기준으로 임계치를 주기적으로 조정해야 한다.

주의점: 스로틀링은 장애 원인을 해결하지 못한다. 외부 시스템이 느려진 상태에서 스로틀링만 걸면 내 서비스는 버티더라도 외부 호출 성공률이 낮은 상태가 지속될 수 있다.

주의점: 제한 방식이 일관되지 않으면 우회가 생긴다. IP 기준만 쓰면 NAT 환경에서 정상 사용자가 묶일 수 있고, 사용자 ID 기준만 쓰면 익명 호출의 방어가 약해질 수 있다.

 

스로틀링이 요청 폭주를 완충하는 흐름

 

핵심 개념 2: 서킷 브레이커는 실패율이 높아진 의존성을 빠르게 차단하는 방식이다

정의: 서킷 브레이커(circuit breaker)는 외부 시스템 호출에서 실패율·타임아웃이 일정 기준을 넘으면 호출을 즉시 차단하고, 일정 시간이 지난 뒤 일부 요청만 흘려보내 회복 여부를 시험하는 패턴이다.

핵심 특징: 외부 시스템이 이미 망가진 상태에서 계속 호출을 시도하면 스레드·커넥션·CPU가 소모되며 내 서비스까지 같이 쓰러질 수 있다. 서킷 브레이커는 이 소모를 멈추고, 빠르게 실패 응답을 돌려서 자원을 보호한다.

• 내부 동작 원리: 일반적으로 닫힘(정상 호출), 열림(즉시 차단), 반열림(소량 시험 호출) 상태를 가지며, 최근 N건 실패율 또는 시간 창 기반 지표로 상태를 전환한다.
• 범위: 외부 HTTP 호출, DB 연결, 메시징 API 등 “내 서비스가 직접 제어할 수 없는 의존성” 앞에 두는 경우가 많다.
• 제약: 차단 시에는 기능이 일부 제한될 수밖에 없다. 따라서 대체 동작(폴백), 캐시, 지연 안내 같은 사용자 경험 설계가 함께 필요하다.
• 정리 필요성: 차단 기준과 복구 기준이 문서화되지 않으면 “왜 갑자기 차단되었는지”를 운영자가 설명하기 어렵다. 실패율, 타임아웃, 차단 시간의 근거를 남겨야 한다.

주의점: 서킷 브레이커는 스로틀링과 목적이 다르다. 트래픽 폭주를 줄이는 데만 기대하면, 외부 시스템이 정상인데도 너무 쉽게 차단되는 부작용이 생길 수 있다.

주의점: 타임아웃이 길면 차단이 늦는다. 외부 호출 타임아웃을 과도하게 길게 두면 스레드가 오래 묶여, 서킷 브레이커가 열리기 전에 내부 자원이 먼저 고갈될 수 있다.

외부 장애가 내 서비스까지 망치지 않게 하려면 “받는 양을 조절하는 장치”와 “나쁜 길을 끊는 장치”를 함께 바라봐야 한다.

 

서킷 브레이커 상태 전이와 폴백 흐름

 

비교와 선택 기준: 무엇을 먼저 적용하면 효과가 큰가

두 기술은 경쟁 관계가 아니라 역할 분담에 가깝다. 스로틀링은 과도한 요청을 줄여 시스템의 기본 체력을 지키고, 서킷 브레이커는 망가진 의존성 호출을 끊어 내부 자원 소모를 줄인다.

적용 위치도 다르게 잡는 경우가 많다. 스로틀링은 입구(게이트웨이/프록시)에서 효과가 크고, 서킷 브레이커는 외부 호출 직전(클라이언트 라이브러리/미들웨어)에서 효율이 좋다.

비교 항목	스로틀링	서킷 브레이커
주요 목적	요청 폭주로 인한 과부하 완화	실패하는 의존성 호출의 연쇄 확산 차단
작동 기준	요청량/동시성/사용자별 한도	실패율/타임아웃/지연시간 상승
적용 위치	API 게이트웨이, 로드밸런서, 엔드포인트 앞단	외부 API 호출 직전, 클라이언트/미들웨어 계층
사용자 체감	일부 요청이 거절(429)되거나 지연될 수 있다	외부 기능이 빠르게 실패하고 대체 동작으로 전환될 수 있다
운영 포인트	임계치 조정, 사용자군별 정책, 우회 방지	타임아웃, 실패율 임계치, 차단 시간, 폴백 품질

표 제목: 스로틀링 vs 서킷 브레이커 핵심 비교

어떤 상황이면 무엇을 쓰는가: YES/NO 체크리스트

• 질문: 특정 시간대에 요청이 몰리며 서버가 전체적으로 느려지는가. YES: 스로틀링으로 입구에서 요청량을 조절하는 편이 먼저다. NO: 외부 의존성 문제 여부를 추가로 본다.
• 질문: 외부 API 호출이 타임아웃으로 늘어나고, 내부 스레드/커넥션이 묶이는가. YES: 서킷 브레이커로 빠른 차단과 폴백을 준비하는 편이 맞다. NO: 단순 지연이라면 타임아웃과 재시도 정책을 먼저 점검한다.
• 질문: 특정 사용자나 봇이 과도하게 호출해 정상 사용자가 피해를 보는가. YES: 사용자/키/경로 기준 스로틀링이 효과적이다. NO: 전체 트래픽 구조를 다시 본다.
• 질문: 외부 시스템이 간헐적으로 장애를 내며 실패율이 튄 뒤 회복되는 패턴인가. YES: 서킷 브레이커의 반열림 시험 호출로 회복을 확인하는 구조가 유리하다. NO: 지속 장애라면 외부 전환(대체 공급자)까지 검토한다.
• 질문: 기능 제한 시 사용자 안내 또는 대체 동작을 제공할 수 있는가. YES: 서킷 브레이커를 공격적으로 설정해도 운영 안정성이 올라갈 수 있다. NO: 차단 임계치를 보수적으로 잡고, 스로틀링 중심으로 시작하는 편이 안전하다.

실전 예시: 외부 문자 발송 장애가 주문 처리까지 흔드는 상황을 막는 절차

문제: 주문 완료 시 문자 발송을 함께 처리하는데, 문자 업체 API가 느려지면 주문 완료 응답도 늦어지고 일부는 실패한다.

왜 발생: 외부 호출이 길어지면 애플리케이션 스레드가 대기 상태로 묶이고, 대기 스레드가 늘어 전체 요청 처리량이 급감한다. 여기에 재시도가 겹치면 외부 호출이 더 늘어나는 악순환이 생긴다.

어떤 선택이 적합: 문자 발송처럼 주문 확정에 필수가 아닌 처리는 분리하는 편이 낫다. 우선 문자 발송 호출 앞에 서킷 브레이커를 두고, 실패가 늘면 빠르게 차단해 주문 흐름의 자원을 보호한다. 동시에 문자 발송 요청을 과도하게 쏟아내지 않도록 스로틀링으로 발송 속도를 제한한다.

잘못 쓰면 어떤 문제: 스로틀링을 너무 낮게 잡으면 정상 주문에서도 문자가 과도하게 누락되어 CS가 늘 수 있다. 서킷 브레이커 임계치를 너무 민감하게 잡으면 외부 API가 잠깐 흔들릴 때마다 기능이 자주 꺼져 사용자 불만이 생길 수 있다.

확인/해결: 외부 API의 지연·실패율이 내부 처리량 저하와 함께 움직이는지 확인한 뒤, 타임아웃·재시도·차단 기준을 동시에 조정해야 한다.

확인하는 방법: 장애 징후를 수치로 붙잡고 적용 위치를 정한다

1. 모니터링 대시보드에서 외부 API의 응답 지연시간과 실패율(5xx, 타임아웃)을 확인한다.
2. 같은 시간대에 애플리케이션의 스레드 수, 커넥션 풀 사용률, 요청 대기열 증가가 동반되는지 확인한다.
3. 외부 API 호출 타임아웃 값과 재시도 횟수를 점검한다. 타임아웃이 과도하게 길거나 재시도가 공격적이면 내부 자원 소모가 커질 수 있다.
4. 서킷 브레이커 적용 지점을 정한다. 외부 호출을 감싸는 클라이언트 모듈 또는 미들웨어 계층에 적용하고, 차단 시 반환할 폴백 동작(예: “문자 발송은 지연될 수 있다” 상태 저장)을 정한다.
5. 서킷 브레이커 기준을 정한다. 최근 실패율 기준, 연속 타임아웃 기준, 차단 유지 시간, 반열림 시험 횟수를 설정하고 로그로 상태 전환이 남도록 한다.
6. 스로틀링 적용 지점을 정한다. 문자 발송 엔드포인트 또는 발송 작업 실행부에 초당 발송량 제한을 걸어, 피크 타임에 외부를 과도하게 두드리지 않게 한다.
7. 적용 후 확인한다. 차단(Open) 상태 빈도, 429 발생 비율, 주문 성공률, 평균 응답 시간, 문자 발송 지연 분포가 어떻게 바뀌는지 비교한다.

자주 발생하는 실수를 줄이는 운영 포인트

첫째, 타임아웃과 재시도는 서킷 브레이커보다 먼저 설계 대상이다. 타임아웃이 길고 재시도가 많으면 서킷 브레이커가 열리기 전에 내부가 먼저 지칠 수 있다.

둘째, 스로틀링은 “정상 사용자 보호”를 목표로 해야 한다. 전체를 막기보다 사용자군별·경로별로 제한을 나누면 체감 품질이 안정된다.

셋째, 서킷 브레이커는 폴백 품질이 반이다. 차단 시 사용자에게 무엇을 보여줄지, 어떤 상태를 저장할지, 나중에 어떻게 보완 처리할지까지 함께 정해야 운영이 흔들리지 않는다.

결론

스로틀링은 과도한 요청을 제한해 시스템 과부하를 줄이는 방식이다.

서킷 브레이커는 실패하는 외부 의존성 호출을 빠르게 차단해 내부 자원 고갈을 막는 방식이다.

지연·실패율·처리량을 수치로 붙잡고 적용 위치를 정하면 외부 장애가 내부로 번지는 범위를 줄일 수 있다.

• 다음에 읽으면 좋은 연계 주제: 타임아웃과 재시도(백오프) 설정으로 실패 폭주를 줄이는 방법
• 다음에 읽으면 좋은 연계 주제: 폴백과 캐시로 기능 제한 상황에서 사용자 경험을 유지하는 방법

FAQ

스로틀링을 걸면 왜 429 같은 응답이 늘어나는가

허용된 요청량을 넘은 요청을 즉시 거절하기 때문이다. 이는 서버가 무너지는 것보다 “일부를 명시적으로 거절”해 정상 범위 요청을 지키는 쪽을 선택한 결과다.

서킷 브레이커가 열리면 외부 기능은 완전히 못 쓰는가

차단(Open) 상태에서는 해당 외부 호출을 빠르게 실패 처리하는 경우가 많다. 다만 폴백을 설계해 대체 화면을 보여주거나, 나중에 처리할 수 있도록 상태를 저장하는 방식으로 기능 제한의 충격을 줄일 수 있다.

두 기술 중 하나만 적용해도 되는가

상황에 따라 가능하다. 트래픽 폭주가 핵심이면 스로틀링이 먼저이고, 외부 실패율 상승이 핵심이면 서킷 브레이커가 먼저다. 다만 외부 장애가 트래픽 폭주와 함께 나타나는 경우가 많아, 운영 안정성을 위해 둘을 조합하는 경우가 자주 있다.