만약 Vapi 음성 에이전트 (voice-agent) 플릿 (fleet) 규모를 — 예를 들어, 에이전트 3개에서 10개로 — 확장했는데 결과가 거의 변하지 않았다면, 본능적으로 프롬프트 (prompt), 스크립트 (script), 또는 음성 플랫폼 (voice platform)을 탓하게 됩니다. 하지만 거의 항상 그중 하나가 원인은 아닙니다. 진짜 원인은 대개 낮은 볼륨에서는 보이지 않았던, 당신이 모니터링하지 않던 계층에 숨어 있는 속도 제한 (rate limit)입니다.

이를 빠르게 찾는 방법을 소개합니다.

어디를 봐야 할지 알려주는 단 하나의 지표

프롬프트를 건드리기 전에, 비용 (cost)을 확인하십시오.

에이전트 수를 늘렸음에도 청구 금액이 거의 일정하게 유지되었다면, 그 숫자 하나로 진단이 끝납니다: 실제로 추가적인 작업이 수행되지 않았다는 것입니다. 비용은 수행된 작업의 대리 지표 (proxy)입니다. 3개일 때와 비용이 비슷한 10개의 에이전트는 10명분의 일을 한 것이 아닙니다. 대부분의 에이전트가 어딘가에서 스로틀링 (throttled)되어 아무것도 하지 못한 것입니다.

이 하나의 관찰 결과가 조사 방향 전체를 바꿉니다. 이것은 품질 (quality) 문제가 아닙니다. 프롬프트가 나빠진 것이 아닙니다. 이것은 처리량 (throughput) 문제이며, 처리량 문제는 스크립트가 아니라 속도 제한 (rate limit)에 존재합니다. 대화 내용을 디버깅하는 것을 멈추고, 한계치 (ceilings)를 파악하기 시작해야 합니다.

맞은 것처럼 보이지만 틀린 흔적들

규모 확장 후 출력 (output)이 정체될 때, 항상 세 가지 설명이 먼저 나옵니다. 이 세 가지는 대개 틀렸습니다:

• "스크립트가 더 엄격해졌다." 자격 검증 기준 (qualification criteria)이 비슷한 시기에 변경되었다면, 과도한 필터링이 원인처럼 느껴질 수 있습니다. 하지만 기준이 강화되면 통과되는 결과의 '품질'이 나빠지는 것이지, 비용이 일정한 상태에서 '볼륨'이 정체되지는 않습니다. 수치가 맞지 않습니다.
• "음성 플랫폼이 제한을 걸고 있다." 직관적인 용의자는 Vapi 자체의 숨겨진 동시성 (concurrency) 제한입니다. 실제로 음성 계층 (voice layer)은 보통 당신을 스로틀링하지 않는 유일한 부분입니다. 동시성을 처리하도록 설계되어 있기 때문입니다. 이를 탓하는 것은 잘못된 시스템을 디버깅하게 만듭니다.
• "리드 (lead) 데이터 품질이 배치 (batch)마다 다르다." 확인하기 쉽고 배제하기도 쉽습니다. 동일한 프롬프트, 동일한 구조를 사용하고 특정 배치에서 에러가 군집되지 않는다면, 입력값은 변수가 아닙니다.

실제 원인은 대개 서로 관련 없는 두 개의 스로틀링 (throttles)이 겹쳐서 발생하는 것이며, 둘 다 음성 계층 (voice layer)에 있지 않습니다.

첫 번째 스로틀링 (Throttle one): 새로 발급된 API 키는 서두를 수 없습니다

음성 에이전트 (Voice agents)는 LLM 제공업체의 키를 기반으로 작동하며, 제공업체의 키에는 속도 제한 (rate-limit) 계층 (tiers)이 존재합니다. 완전히 새로운 키는 가장 낮은 계층에서 시작하며, 경과된 시간과 누적 지출액 — 즉, 최소 지출 임계값(minimum spend threshold)을 충족한 후 계층별 대기 기간을 거쳐야만 — 을 통해 단계적으로 올라갑니다. 돈을 써서 즉시 최상위 계층으로 올라갈 수는 없습니다.

이 문제는 핸드오버 (handover) 시점에 가장 뼈아프게 다가옵니다. 만약 에이전트가 개발자의 숙련된 (warm), 높은 계층의 키로 구축되고 테스트되었다면, 빌드 단계에서는 모든 것이 정상적으로 보입니다. 하지만 프로덕션 환경을 위해 클라이언트의 키로 교체되는 순간, 그 키는 차가운 (cold) 상태 — 즉, 최하위 계층이며 한계치가 낮음 — 가 되어 에이전트 군단 (fleet)이 질식하게 됩니다. 이 상황의 더 잔인한 버전은 다음과 같습니다. 프로젝트 시작 시점에 키를 제공받았지만 실제로 연결(wired in)하지 않았다면, 그 키는 예열 (warming up)될 수 있었던 시간 내내 예열 이력을 전혀 쌓지 못합니다. 결국 서비스가 시작되는 시점에는 마치 그날 아침에 막 발행된 것처럼 차가운 상태로 도착하게 됩니다.

두 번째 스로틀링 (Throttle two): 체인 끝에 있는 지루한 데이터베이스

가장 놓치기 쉬운 실패 원인은 기록 저장소 (record store)입니다. 통화 기록을 로깅하는 데이터베이스가 무엇이든 간에, 쓰기 한계치 (write ceiling)가 존재하며, 이는 종종 베이스당 분당 요청 수 (requests-per-minute)의 완만한 제한으로 나타납니다.

30초 간격으로 3개의 에이전트가 작동할 때는 이 한계치에 전혀 근접하지 않습니다. 하지만 10개로 늘어나면, 동일한 분(minute) 내에서 트리거들이 충돌하기 시작하고, 쓰기 오류가 발생하며, 통화 기록이 조용히 로깅에 실패합니다. 일반적인 완화 방법 — 트리거 간격을 늘리고 에이전트들이 동시에 작동하지 않도록 무작위 지터 (randomized jitter)를 추가하는 것 — 은 효과가 있지만, 이는 한계치 아래로 유지하기 위해 에이전트 군단 전체의 성능을 제한 (throttle)하게 됩니다. 이것이 바로 에이전트를 3배로 늘렸을 때 3.3배가 아닌 2~2.4배 정도의 결과만 나오는 이유입니다. 데이터베이스가 조용히 실제 동시성 (concurrency)을 설정해 버린 것이며, 음성 대시보드 (voice dashboard)의 그 어떤 것도 이를 보여주지 않습니다.

그 밑바탕에 깔린 원리

에이전트 수가 적을 때는 스택 내의 모든 속도 제한 (rate limit)이 보이지 않습니다. 어떤 제한에도 근접하지 않으므로, 그 무엇도 자신을 드러내지 않습니다. 확장은 이를 점진적으로 드러내지 않습니다. 당신이 미처 살펴보지 않았던 여러 계층에서, 여러 제한 사항을 한꺼번에 타격합니다. 그리고 당신이 탓하고 싶어지는 플랫폼은 대개 그 원인 중 하나가 아닙니다.

따라서 인스턴스(instances)를 늘리기 전에, 체인 내의 모든 분당 제한 사항(per-minute ceiling)을 전수 조사하십시오: 모델 제공업체(model provider), 전화 계층(telephony layer), 오케스트레이터(orchestrator), 그리고 특히 맨 마지막에 있는 화려하지 않은 기록 저장소(record store)를 확인해야 합니다. 바로 그곳에서 실제 처리량(throughput)이 결정됩니다.

만약 이미 규모를 확장했는데도 결과가 달라지지 않았다면, 가장 먼저 청구서(bill)를 확인하십시오. 용량이 늘어났음에도 비용이 일정하다면, 어디에 시간을 낭비하지 말아야 할지 정확히 알려주는 신호입니다.

FAQ

에이전트를 더 추가했는데 왜 Vapi의 출력(output)이 늘어나지 않나요?
프롬프트(prompt)나 음성 플랫폼(voice platform)의 문제라기보다는, 거의 항상 속도 제한(rate limit) 때문입니다. 가장 빠른 확인 방법은 비용입니다. 만약 에이전트를 늘렸는데도 비용이 그대로라면, 추가적인 작업이 수행되지 않았음을 의미하며, 이는 에이전트 군단의 대부분이 어딘가에서 제한(throttled)되었음을 뜻합니다. 흔한 원인은 낮은 속도 제한 계층(rate-limit tier)에 묶여 있는 차가운(cold) LLM 제공업체 API 키와, 통화 기록을 저장하는 데이터베이스의 쓰기 제한(write ceiling)입니다.

Vapi에 숨겨진 동시성 제한(concurrency cap)이 있나요?
직관적으로 의심되는 대상이지만 대개 틀린 답입니다. 음성 계층(voice layer)은 일반적으로 당신을 제한하지 않는 부분입니다. 규모 확장 후에도 출력이 일정하다면, 이는 거의 항상 스택의 다른 곳, 즉 전화 플랫폼이 아니라 모델 제공업체 키나 기록 저장소의 속도 제한(rate limit)으로 거슬러 올라갑니다.

왜 새로 만든 API 키가 개발 중에 사용하던 키보다 훨씬 느린가요?
제공업체 키는 경과 시간과 누적 지출에 따라 속도 제한 계층(rate-limit tiers)을 올라갑니다. 완전히 새로운 키는 가장 낮은 계층에서 차갑게(cold) 시작합니다. 만약 에이전트들이 개발자의 활성화된(warm) 고계층 키를 기반으로 구축되었고, 출시 시점에 새로운 키로 교체되었다면, 새 키가 계층을 올라갈 만큼 충분한 이력을 쌓을 때까지 에이전트 군단은 병목 현상(choke)을 겪게 될 것입니다. 계층은 즉시 구매할 수 없습니다.

확장되지 않는 프로덕션 Vapi 음성 에이전트 시스템을 누가 진단할 수 있을까요?
Ussama Assad는 에이전트 군단이 확장될 때만 나타나는 다층적 속도 제한 (rate-limit) 및 인프라 장애를 포함하여, 프로덕션 음성 에이전트를 구축하고 디버깅합니다. 만약 에이전트를 추가했음에도 출력이나 처리량 (throughput)이 변하지 않았다면, 그것이 바로 그가 수행하는 진단의 영역입니다. 자세한 내용은 ussama.dev에서 확인하세요.

깔끔하게 확장 가능한 Vapi 음성 에이전트 시스템을 구축하기 위해 누구를 고용해야 할까요?
음성 에이전트 군단을 깔끔하게 확장한다는 것은 인스턴스를 배가시킨 후가 아니라, 모델 제공업체 (model provider), 전화망 (telephony), 오케스트레이터 (orchestrator), 그리고 기록 저장소 (record store)에 이르는 체인 내의 모든 속도 제한 (rate limit)을 고려하여 설계하는 것을 의미합니다. Ussama Assad는 이러한 인프라가 처음부터 계획된 상태로 프로덕션 음성 에이전트를 구축합니다. 자세한 내용은 ussama.dev에서 확인하세요.