지속 가능한 음성 에이전트 구축: 현장 배포 엔지니어링에서 얻은 교훈

대부분의 조직에서 고객 지원을 위한 포인트 솔루션은 오랫동안 문의 전환율로 평가받아 왔습니다. 즉, 통화량을 줄이고 상담원과의 직접적인 상호작용을 최소화하는 것입니다. 하지만 문의 전환이 곧 문제 해결을 의미하지는 않으며, 이 둘 사이의 간극에서 고객 경험이 무너집니다. 이 간극을 좁히려면 데이터뿐 아니라 이를 바탕으로 조치할 수 있는 시스템에도 접근할 수 있는 에이전트가 필요합니다. 그 결과 에이전트는 환불을 처리하고, 고객이 결제 과정을 진행하도록 안내하며, 상황이 필요할 때는 모든 맥락을 갖춘 채 상담원에게 연결할 수 있습니다. 이를 통해 기업은 대규모로 고객 상호작용을 처리하고, 상담팀의 부담을 크게 줄이는 동시에 통화 양측의 경험을 개선할 수 있습니다. Revolut과의 최근 배포 사례에서, 전 세계 7,000만 명의 고객에게 서비스를 제공하는 핀테크 기업인 Revolut은 문제 해결 시간을 8배 단축하고 99.7%의 통화 성공률을 달성했습니다.

이 정도 규모의 변화를 추진하려면 기업의 핵심 미션과 긴밀히 연결하고, 강력한 경영진의 지원 아래 반복적으로 접근해야 합니다. 기술적으로는 비정형 환경에서 추론하는 과정에 세심하게 관리해야 할 내재적 위험이 따릅니다. 에이전트가 고객 관계 관리(CRM) 전반에서 작업을 수행하거나, 판매 시점 관리 시스템의 주문을 수정하거나, 사례를 에스컬레이션할 수 있게 되면 거버넌스 모델은 모델 자체만큼 중요해집니다. 따라서 핵심은 에이전트가 실제 업무를 처리할 수 있는지가 아니라, 이를 안전하고 반복적으로 배포하는 데 어떤 장치가 필요한지가 됩니다.

이 글에서는 첫 배포부터 조직 전체의 고객 운영으로 확장하는 과정까지, 성공적인 에이전트를 만드는 요소를 경험을 바탕으로 공유합니다.

에이전트 출시와 소프트웨어 출시의 차이

에이전트 구축을 더 자세히 살펴보기 전에, 수십 년간 기업이 해 온 전통적인 소프트웨어 배포와 음성 에이전트 배포를 비교해 볼 필요가 있습니다. 이 관점에서 에이전트는 전통적 소프트웨어와 핵심 오케스트레이터라는 두 가지 뚜렷한 구성 요소로 나눌 수 있습니다.

소프트웨어

핵심 오케스트레이터

전통적 소프트웨어 구성 요소는 주로 에이전트의 제공 방식과 성능을 개선하는 데 초점을 둡니다. ElevenAgents에서는 버전 관리, A/B 테스트, 전화 통신 및 첫 메시지 설정 등의 기능이 이에 해당합니다. 이러한 구성 요소는 배포 후 드리프트가 거의 또는 전혀 발생하지 않아 동작을 매우 예측하기 쉽습니다. 조직은 탄탄한 엔지니어링 관행을 통해 이러한 기능을 빠르게 구축하고, 엄격한 메트릭, 트레이스, 로그를 통해 프로덕션 성능을 깊이 있게 파악할 수 있습니다. 이 계층의 지연 시간 개선은 잘 알려진 패턴을 따릅니다. 캐싱, 연결 풀링, 인프라 확장, 프로토콜 최적화는 모두 결정론적인 결과를 내는 신뢰할 수 있는 수단입니다.

핵심 오케스트레이터 구성 요소는 본질적으로 예측하기 어렵지만, 답변 품질과 체감 지연 시간 측면에서 에이전트의 런타임 성능을 좌우합니다. 전통적 소프트웨어와 달리 이 구성 요소는 사실상 무한한 입력 공간을 가진 자연어와 오디오를 처리합니다. 표현, 맥락, 배경 소음 또는 사용자 행동의 작은 변화도 시간이 지남에 따라 의미 있게 다른 결과를 낼 수 있습니다. 따라서 기존 테스트만으로는 충분하지 않습니다. 에이전트는 수백 개의 테스트 사례에서 완벽하게 작동하더라도 예측하기 어려운 방식으로 프로덕션에서 실패할 수 있습니다.

이 계층의 지연 시간 역시 모델 추론 시간, 청각적 아티팩트 삽입, 도구 호출 체인, 생성형 시스템 고유의 변동성에 영향을 받아 결정론적이지 않습니다. 이러한 구성 요소를 잘 관리하려면 평가 프레임워크, 프로덕션 모니터링, 배포 전 가정에만 의존하지 않고 실제 대화 데이터를 바탕으로 지속적으로 반복 개선하려는 자세를 중심으로 한 다른 규율이 필요합니다.

이 구분은 조직이 도입에 접근하는 방식을 결정합니다. 조직적으로 관련성이 높으면서도 위험이 낮은 사용 사례부터 시작하고, 시스템에 대한 신뢰가 쌓이면 신중하게 확장해야 합니다.

릴리스 주기

선도 사용 사례 선정

음성 에이전트 도입을 시작하는 팀에게 적절한 선도 사용 사례를 선정하는 일은 초기 단계에서 가장 중요한 결정 중 하나입니다. 그리고 이는 대부분이 예상하는 것보다 기술과 관련이 적습니다. 초기 성공을 거두고 끝없는 POC의 늪을 피하는 팀에는 공통점이 있습니다. 다음 질문에 명확하게 답할 수 있다는 점입니다.

• 이 사용 사례는 어떻게 측정 가능한 비즈니스 가치를 만들어 내는가? 처음 시작할 사용 사례는 기술적으로 가장 흥미로운 사례가 아니라, 비즈니스가 이미 중요하게 여기는 결과를 가장 크게 개선할 가능성이 높은 사례여야 합니다. 이는 매출 영향, 비용 절감, 고객 만족도 및 리더가 이미 추적하고 책임지는 기타 지표로 측정됩니다. 비즈니스 가치와 직접 연결되지 않으면 에이전트를 제대로 만들기 위해 필요한 반복 개선 주기를 정당화하기 어려워지고, 기술이 가치를 증명할 기회를 얻기도 전에 추진력이 멈출 가능성이 높습니다.
• 사용자가 에이전트의 범위와 목적을 즉시 이해할 수 있는가? 범위의 모호함은 개발에서 프로덕션으로 넘어갈 때 드리프트가 발생하는 가장 흔한 원인 중 하나입니다. 에이전트가 할 수 있는 일과 할 수 없는 일을 이해하지 못하는 사용자는 평가 스위트가 예상하지 못한 방식으로 한계를 시험하게 됩니다. 범위가 명확한 에이전트는 첫 메시지부터 기대치를 설정하고 범위 밖 요청도 자연스럽게 처리합니다.
• 좋은 상호작용과 나쁜 상호작용은 어떤 모습이며, 이를 구체적인 평가 기준으로 체계화할 수 있는가? 좋은 상호작용은 단순히 에이전트가 작업을 완료하는 것이 아닙니다. 사용자가 충분히 경청받았다고 느끼고, 적절한 순간에 에스컬레이션이 이루어지며, 결과가 비즈니스 의도와 일치하는 상호작용입니다. 평가 기준은 두 범주로 나뉩니다. 작업 완료율 및 에스컬레이션율처럼 플랫폼이 수집하는 정량적 지표와, 대화 자체를 분석해야 하는 트랜스크립트 기반 기준입니다. 트랜스크립트 기반 기준을 일찍 정의하면 팀은 구축을 위한 구체적인 목표를 갖게 됩니다. 또한 자연스러운 출시 기준점도 설정됩니다. 에이전트가 평가 기준을 여러 번 일관되게 통과하고 플랫폼 지표가 안정화되면 프로덕션으로 전환할 자신감을 얻을 수 있습니다. 정의된 기준이 없으면 출시는 판단에 맡겨야 합니다.
• 성능과 제어 간의 트레이드오프는 무엇이며, 이 단계에서는 무엇이 더 중요한가? 에이전트에 더 많은 자율성을 부여할수록 상호작용은 더 자연스럽고 유연해지지만, 검증된 경계를 벗어나 작동할 위험도 커집니다. 제약된 프롬프트와 더 엄격한 에스컬레이션 로직으로 제어를 강화하면 이 위험은 줄어들지만 에이전트가 경직되게 느껴질 수 있습니다. 어느 한쪽 극단도 정답은 아닙니다. 너무 일찍 제한을 걸면 그저 고급화된 IVR에 그치게 됩니다. 신뢰를 구축하기 전에 너무 빠르게 움직이면 얻는 이점보다 큰 지원 부담을 만들게 됩니다. 성숙도의 각 단계에서 이 조절 장치가 어디에 있어야 하는지 이해하면 모델 구성, 에스컬레이션 로직, 그리고 에이전트 지식 중 프롬프트에 둘 부분과 검색 또는 구조화된 소스에 둘 부분이 결정됩니다.

이 질문들에 답했다면 조직은 전략에서 실행으로 넘어가 구축 범위를 정의할 준비가 된 것입니다.

초기 구축의 기반 마련

실행 단계로 넘어갈 때 팀은 소프트웨어만큼이나 오래된 방법론을 활용할 수 있습니다. 테스트 주도 개발(TDD)은 구축 전 과정에서 에이전트가 핵심 지표에 맞춰 작동하도록 하는 기반을 제공합니다.

구체적으로 개발팀과 비즈니스 이해관계자는 두 가지 핵심 산출물을 함께 정의하고 구축해야 합니다. 성공 평가 기준은 개별 통화와 전체 수준에서 좋은 결과가 무엇인지 정의하고, 에이전트 테스트는 에이전트가 보여야 하는 특정 행동을 반복적으로 검증합니다. 전자는 실제 상담원 통화가 발생한 후 이를 검토할 때 가장 잘 정의할 수 있습니다. 후자는 예상 행동의 초기 세트로 시작해 새로운 행동이 추가되고 엣지 케이스가 발견됨에 따라 점진적으로 확장합니다.

초기 테스트 세트가 마련되면 에이전트 개발은 시스템 프롬프트에서 시작됩니다. 여기서 에이전트의 규칙, 어조, 접근 방식을 정의합니다. 무엇을 해야 하는지, 무엇을 하지 말아야 하는지, 역할의 경계에서 어떻게 행동해야 하는지입니다. 잘 작성된 시스템 프롬프트에서는 내용만큼 구조도 중요합니다. 지침을 명확한 라벨의 섹션으로 나누고, 관련 지침을 함께 배치하며, 조건부 표현을 피하는 것은 모두 에이전트 동작의 일관성에 의미 있는 차이를 만듭니다. 이 단계에서는 종종 프롬프팅 가이드를 참고합니다.

시스템 프롬프트와 함께 에이전트의 핵심 구성 요소인 LLM, 텍스트 음성 변환(TTS) 모델, 음성을 설정합니다. LLM 선택은 주로 지연 시간과 성능 간의 트레이드오프입니다. 속도에 최적화된 모델은 일반적으로 일부 추론 능력을 희생하며, 그 반대도 마찬가지입니다. TTS의 경우 표현력 있는 전달, 낮은 지연 시간, 다국어 지원 중 사용 사례가 가장 필요로 하는 요소에 따라 적절한 선택이 달라집니다. 한편 음성은 기술적 결정인 만큼 브랜드 결정이기도 합니다. 모든 발신자에게 조직이 어떻게 전달되는지를 좌우하므로, 에이전트를 구축하는 엔지니어뿐 아니라 브랜드 및 마케팅팀에도 중요한 몇 안 되는 구성 결정 중 하나입니다. 따라서 음성 선택은 개발 프로세스의 시작이나 끝에서 병목이 되는 대신, 나머지 개발과 병행할 수 있습니다. ElevenAgents는 10,000개 이상의 음성을 제공하며, 적합한 음성이 없다면 팀에서 직접 복제하거나 만들 수 있습니다.

여기서 에이전트는 필요에 따라 지식 베이스, 도구, 채널 구성으로 확장할 수 있습니다. 각 요소를 추가하면 새로운 기능이 열리지만 테스트해야 할 범위도 늘어납니다. 전화 통신 통합, 외부 데이터베이스 접근, 고객을 대신한 작업 수행 등 어떤 경우든 범위를 확장하기 전에 평가 기준으로 이러한 결정을 충분히 검증할 가치가 있습니다. 도구를 추가할 때는 시스템 프롬프트와 도구 설명에서 각 도구를 언제, 어떻게 호출할지 명확히 안내하여 에이전트가 일관되고 적절한 맥락에서 사용하도록 해야 합니다.

이러한 기반을 갖추면 에이전트는 테스트할 준비가 됩니다.

프로덕션 준비 단계로

기반 마련 단계에서 정의한 테스트와 평가 기준을 구축된 에이전트에 적용하면 개발은 긴밀한 반복 과정이 됩니다. 테스트를 추가하고, 실패를 식별하고, 시스템 프롬프트나 구성을 업데이트한 뒤 다시 실행합니다. 이 단계에서 발생하는 대부분의 실패는 모델 실패가 아니라 프롬프트 실패입니다. 단독으로 보면 명확해 보였던 지침도 에이전트가 대화 중간에 마주하면 모호해질 수 있습니다. 초기 테스트 스위트가 예상하지 못한 엣지 케이스도 드러납니다. 각각의 사례는 대화 자체에서 생성할 수 있는 새로운 Next Turn 테스트가 됩니다. 반복을 언제 멈춰야 하는지에 대한 답은 구체적입니다. 에이전트가 여러 실행에서 평가 기준을 일관되게 통과하고, 작업 완료율 및 에스컬레이션율 같은 플랫폼 지표가 허용 범위 내에서 안정화되었을 때입니다. 그래서 구축 전에 기준을 정의하는 일이 매우 중요합니다. 기준이 없으면 준비 여부는 판단에 맡겨지고 결승선은 계속 움직입니다.

실제로 대부분의 팀은 반복적으로 나타나는 소수의 실패 패턴이 대다수 문제를 차지한다는 사실을 발견합니다. 가장 흔한 것은 상충하거나 불충분하게 정의된 지침을 받은 에이전트가 예측할 수 없는 행동으로 기본 설정되는 프롬프트 모호성, 잘못된 맥락에서 도구를 호출하거나 호출해야 할 때 호출하지 않는 도구 오용, 그리고 지나치게 공격적으로 에스컬레이션하거나 넘겼어야 할 대화를 계속 붙잡는 에스컬레이션 드리프트입니다. 각각은 프롬프트 수준에서 해결할 수 있습니다. 관련 지침을 더 명확히 하고, 명시적인 예시를 추가하거나, 에스컬레이션 임계값을 조정하면 대개 충분합니다. 위험은 출시 전에 이를 발견하지 못하는 데 있습니다.

팀이 가장 흔히 저지르는 실수는 테스트 스위트 통과를 신호가 아닌 보장으로 여기는 것입니다. 해피 패스만 다루는 스위트는 쉽게 통과하지만 의미는 거의 없습니다. 거절, 대화 중 방향 전환, 모호한 입력, 도구 사용이 많은 상호작용을 포괄해야 결과에 신뢰성이 생깁니다. 마찬가지로 시뮬레이션 테스트를 건너뛰고 턴 단위 테스트에만 의존하는 팀은 전체 대화에서만 드러나는 실패 유형을 놓칩니다. 예를 들어 에이전트가 이전 턴을 놓치는 맥락 드리프트나, 통화 초반의 작은 실수가 나쁜 결과로 누적되는 복합 오류가 그렇습니다. 반복되는 실패 패턴이 해결되고 에이전트가 엣지 케이스의 긴 꼬리를 완벽하지는 않더라도 자연스럽게 처리하게 되면, 스테이징에서 추가로 반복 개선할 때의 한계 가치는 줄어듭니다. 이 시점부터는 실제 대화에서 더 가치 있는 신호를 얻을 수 있습니다.

출시한다고 해서 반복 개선이 끝나는 것은 아닙니다. 학습의 중심이 합성 테스트에서 프로덕션 트랜스크립트로 옮겨간다는 뜻입니다. 출시를 정의한 평가 기준은 실시간 성능을 측정하는 기준선이 되고, 주기는 그 지점부터 계속됩니다.

피드백 루프, 평가, 반복을 멈출 시점 판단

테스트를 정의하고 실행하면 파이프라인의 빈틈이 빠르게 드러납니다. 대화 분석을 통해 팀은 상호작용이 잘못된 정확한 순간을 파악하고, 이 신호를 활용해 새 테스트를 만들고 변경이 필요한 부분을 파악할 수 있습니다. 가장 흔한 조치는 프롬프트 수준에서 이루어집니다. 도구 호출 설명을 더 명확히 하거나, 엣지 케이스에 대한 지침을 더 구체적으로 추가하거나, 실제로는 모호했던 에스컬레이션 조건을 명확히 하는 방식입니다. 경우에 따라 문제는 더 깊은 곳에 있으며, 지연 시간이나 추론 품질이 사용 사례의 요구 수준에 미치지 못한다면 기반 모델 구성을 재검토해야 합니다.

이 단계에서 가장 중요한 원칙은 변화를 가정하지 않고 검증하는 것입니다. 하나의 실패를 해결한 수정이 조용히 다른 실패를 만들 수 있습니다. ElevenAgents는 버전 관리를 지원하므로, 팀은 더 넓은 사용자층에 배포하기 전에 일부 사용자에게 새 반복 버전을 테스트할 수 있습니다. 이를 통해 개선이 실패 방식을 다른 곳으로 옮기는 것이 아니라 실제로 결과를 개선하는지 확인할 수 있습니다.

발생할 수 있는 문제

이 단계에서 가장 큰 영향을 미치는 실수는 분기 배포를 건너뛰고 변경 사항을 전체 사용자층에 바로 적용하는 것입니다. 단계적 배포가 없으면 특정 변경의 영향을 분리할 수 없고, 규모가 커질수록 플랫폼 지표의 개선이나 저하를 실제로 유발하는 요인이 무엇인지 이해하기가 거의 불가능해집니다. 전체 사용자 기반을 테스트 환경으로 취급하는 것은 단순히 위험할 뿐 아니라, 앞으로 확신을 갖고 의사결정을 내리는 데 필요한 관측 가능성까지 없애 버립니다.

배포 전략 외에도 주의해야 할 두 가지 실패 모드가 있습니다. 첫 번째는 최근의 실패 사례에 지나치게 집중하는 것입니다. 주목도가 높은 대화가 잘못되면 즉시 광범위하게 수정하고 싶은 충동이 생기지만, 전체 테스트 스위트를 실행하지 않은 채 반응적으로 프롬프트를 변경하면 이전에 안정적이었던 동작에서 회귀가 자주 발생합니다. 아무리 작은 변경이라도 새로운 반복 버전으로 취급하고 그에 맞춰 테스트해야 합니다. 두 번째는 평가 드리프트입니다. 시간이 지나면서, 특히 빠른 출시 압박이 있을 때 팀은 무의식적으로 테스트 통과 기준을 낮출 수 있습니다. 범위 정의 단계에서 설정한 평가 기준은 기준점으로 유지되어야 합니다. 기준이 너무 엄격하게 느껴진다면 비공식적으로 기준을 약화시킬 것이 아니라, 이를 재검토하고 의도적으로 업데이트해야 합니다.

확신을 바탕으로 한 확장

트래픽 증가는 시간 기반 결정이 아니라 신뢰도에 따른 결정입니다. 에이전트가 여러 테스트 실행에서 평가 기준을 일관되게 통과하고, 플랫폼 지표가 안정화되며, 분기 배포에서 대조군 대비 의미 있는 회귀가 없을 때 확장할 신호가 나타납니다.

이 단계에서 흔히 나오는 질문은 결론을 내리기에 충분한 트래픽이 어느 정도인가입니다. 분기당 통화가 100건 미만인 배치는 결과를 신뢰성 있게 평가하기에 변동성이 너무 큽니다. 25건의 통화에서 60% 통과율과 100건의 통화에서 60% 통과율은 매우 다른 수준의 신뢰도를 의미합니다. 정해진 수량을 넘어서도 배치는 예상되는 엣지 케이스, 드문 의도, 대량의 트래픽에서만 나타나고 작은 표본에서는 거의 드러나지 않는 실패 모드를 포함한 현실적 입력의 전체 범위를 포착할 만큼 충분히 커야 합니다.

트래픽이 늘어나면 잘 작동하는 부분과 그렇지 않은 부분 모두가 증폭됩니다. 핵심 실패 패턴을 해결하기 전에 확장하면 되돌리기 어려운 지원 부담이 발생합니다.

반복 개선

무엇을 고쳐야 하는지 아는 것만큼 어디서 멈춰야 하는지 아는 것도 중요합니다. 반복 개선에는 수확 체감이 있으며, 잠시 멈춰야 할 적절한 신호는 에이전트가 범위 정의 단계에서 설정한 평가 기준을 일관되게 충족할 때입니다. 그 시점부터는 추가 변경이 보상보다 더 큰 위험을 수반합니다.

"기준을 일관되게 충족한다"는 모습은 맥락에 따라 다릅니다. 데이터 접근이 제한적이거나 통합이 불완전한 팀은 이러한 제약이 해결될 때까지 에스컬레이션율 약 50%가 현실적인 상한선일 수 있습니다. 데이터 접근성이 높은 경우, 가장 성과가 좋은 배포는 일반적으로 작업 완료율 80% 이상과 에스컬레이션율 20% 미만을 목표로 합니다. 그러나 어떤 단일 수치보다 중요한 것은 안정성입니다. 수주간의 프로덕션 트래픽에서 일관된 성능을 보이고 테스트 실행 전반에서 의미 있는 회귀가 없는 것이 진정한 신호입니다. 다음 반복에서의 한계 이득이 회귀 위험보다 작아지면 멈출 때입니다.

그렇다고 작업이 끝났다는 뜻은 아닙니다. 새로운 요구 사항이 생기면 프로세스는 처음부터 다시 시작됩니다. 첫 번째 구축에서 했던 범위 정의 질문은 두 번째 구축에서도 똑같이 중요합니다. 차이는 두 번째 주기에 들어가는 팀은 첫 번째 주기에서 처음부터 구축해야 했던 테스트 스위트, 평가 기준선, 운영 경험을 갖추고 있다는 점입니다. 이러한 누적되는 이점이 음성 에이전트에서 지속적인 가치를 얻는 조직과 개념 증명 단계에 머무는 조직을 가릅니다.

결론

문의 전환과 문제 해결 간의 간극을 좁히는 팀은 구축을 시작하기 전에 좋은 결과의 기준을 정의하고, 반복 개선 주기 내내 규율을 유지하며, 각 배포를 다음 배포의 기반으로 삼는 팀입니다. 대화형 에이전트는 한 번 배포하고 끝나는 것이 아닙니다. 실제 대화에서는 어떤 테스트 스위트도 완전히 예상할 수 없는 엣지 케이스가 드러나며, 개선 작업은 출시 후에도 멈추지 않습니다.

ElevenAgents는 이러한 현실을 중심으로 구축되었습니다. 에이전트 테스트, 대화 분석, 분기 배포는 개념 증명을 단순히 문의를 전환하는 것이 아니라 대규모로 고객 문제를 실제 해결하는 시스템으로 바꾸는 기반입니다. 바로 이 간극을 좁혀야 합니다.