동시 통화 86,400건이 쌓일 수 있다: 콜봇 루프의 용량·백프레셔 게이트 설계

통신 계층과 LLM 계층, 서로 다른 두 개의 용량 한도

콜봇 루프를 스케일할 때 흔히 "동시 통화 몇 건까지 버티나"를 하나의 숫자로만 관리합니다. 그런데 실제로는 계층마다 별도의 한도가 걸립니다. 통신 계층에서는 Twilio 같은 통신 사업자가 동시 활성 통화 수(동시성 한도)와 초당 신규 콜 생성 건수(CPS)를 따로 제한합니다. Twilio 공식 에러 문서는 계정에 걸린 동시 통화 허용치를 넘기면 즉시 실패(에러 10004)하고, CPS를 넘긴 콜 생성 요청은 실패가 아니라 최대 24시간까지 큐에 쌓아 순서대로 처리한다고 명시합니다 — 1 CPS 기준으로는 이 큐 하나에 86,400건까지 쌓일 수 있다는 뜻입니다.

두뇌 계층에서는 LLM API가 또 다른 한도를 겁니다. Anthropic 공식 레이트 리밋 문서는 분당 요청 수(RPM)·입력 토큰(ITPM)·출력 토큰(OTPM) 세 축을 토큰 버킷 방식으로 제한하며, 용량이 매 순간 조금씩 다시 채워지는 구조라 "분당 60건 허용"이라도 실제로는 초당 1건 수준의 순간 버스트만 허용될 수 있다고 설명합니다. 통화량이 몰리는 순간에는 통신 계층은 아직 여유가 있어도 LLM 계층이 먼저 막히는 경우가 흔합니다.

평균 부하로는 안 보이는 두 가지 실패 신호

이 두 한도는 실패하는 방식이 다릅니다. 통신 계층의 동시성 한도 초과는 즉시, 시끄럽게 실패합니다 — 콜 생성 API가 에러를 반환하므로 바로 재시도·알림 로직을 붙일 수 있습니다. 반면 CPS 초과는 조용히 실패합니다. 큐에 쌓인 콜은 겉으로는 처리 중으로 보이지만 실제로는 몇 시간 뒤에야 발신되거나, 24시간을 넘기면 자동 취소됩니다. 평균 동시 통화 수만 대시보드에 띄워 두면 이 지연은 눈에 띄지 않다가, 캠페인이 끝난 뒤에야 "왜 통화 수가 목표에 못 미쳤는가"로 뒤늦게 드러납니다.

설계에서 운영까지: 콜봇 루프 용량·백프레셔 체크리스트

용량 설계는 계약된 CPS·동시성 한도와 실제 평균 통화 시간을 곱해 "동시 통화 상한"을 먼저 숫자로 정의하는 데서 시작합니다. 이 상한의 80%를 경보 임계값으로, 95%를 신규 콜 생성 중단선으로 코드에 박아 둡니다. LLM 계층에도 같은 원칙을 적용해 계약 RPM의 70% 수준을 콜봇 루프 전용 예산으로 떼어 두고, 텍스트 챗봇·내부 배치 작업과는 예산을 공유하지 않도록 분리합니다.

통신 계층에서 에러 10004(동시성 초과)를 받으면 해당 콜 시도를 큐가 아니라 즉시 실패로 기록하고, 잠시 후 재시도하거나 우선순위가 낮은 캠페인으로 넘깁니다. CPS 초과로 큐에 들어간 콜은 대기 시간이 일정 기준(예: 10분)을 넘으면 발신을 취소하고 재스케줄하는 편이, 맥락이 사라진 채 24시간 뒤 뒤늦게 연결되는 것보다 안전합니다. LLM 계층에서 요청이 거절되면 지수 백오프로 1~2회만 재시도하고, 그래도 실패하면 미리 준비한 스크립트 기반 폴백 응답으로 전환해 통화를 무음 상태로 방치하지 않습니다.

배포 전에는 예상 피크 동시 통화량의 1.5배까지 부하 테스트를 걸어 두 계층 중 어느 쪽이 먼저 포화되는지 확인합니다. 통화 로그에는 큐 대기 시간, LLM 턴 생성 실패율, 폴백 응답 발생 횟수를 별도 필드로 남기고, 발신 대상 전화번호와 통화 녹취 같은 PII는 마스킹한 뒤 저장합니다. LLM 턴 생성 실패율 0.5% 이하, 재시도·백오프 이후 최종 실패율 0.1% 이하를 배포 합격선으로 둡니다.

큐 대기와 LLM 재시도가 동시에 겹치는 순간에는 두 지표를 하나의 대시보드에서 겹쳐 봐야 합니다. 통신 계층 헤드룸과 LLM 계층 헤드룸을 각각 퍼센트로 표시하고, 둘 중 하나라도 경보선을 넘으면 신규 아웃바운드 콜 생성을 일시 중단하는 단일 스위치를 운영팀이 수동으로도 누를 수 있게 둡니다.

자동 복구 조건도 코드로 선언해 둡니다. 두 계층의 헤드룸이 모두 경보선 아래로 10분 이상 유지되면 콜 생성을 자동으로 재개하고, 재개 직후에는 평소의 절반 속도로 램프업해 재개하자마자 다시 한도를 넘기는 진동을 막습니다.

매주 큐잉·레이트 리밋·동시성 초과 이벤트 상위 유형을 집계해 어느 시간대·캠페인에서 병목이 반복되는지 확인합니다. 반복되는 시간대가 있다면 다이얼러의 페이싱 알고리즘(콜 생성 간격)을 조정하거나 LLM 계층의 티어를 올리는 결정을 데이터에 근거해 내립니다. 용량 한도를 올리는 계약 변경은 되돌리기 어려운 비용 결정이므로, 최소 2주 분의 헤드룸 추이를 근거로 삼습니다.

바로 쓰는 체크리스트

콜봇 루프의 용량 한도는 통신 계층과 LLM 계층에 따로 걸리고, 실패하는 방식도 즉시 실패와 조용한 큐잉으로 서로 다릅니다. 동시 통화 상한의 80%·95% 경보선과 LLM 실패율 0.5% 합격선을 코드에 박아 두고 두 계층의 헤드룸을 한 대시보드에서 함께 보면, 캠페인이 끝난 뒤에야 목표 미달을 발견하는 사고를 막을 수 있습니다.

참고 링크

Rate limits — Claude Platform Docs, Anthropic

Error 30001: Queue overflow — Twilio