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

대부분의 조직에서는 오랫동안 지원 기능을 위한 포인트 솔루션의 효과를 문의 회피(디플렉션)로 측정해 왔습니다. 즉, 전화량을 줄이고 실제 상담원과의 직접적인 상호작용을 최소화하는 것이 목표였습니다. 하지만 문의 회피가 곧 문제 해결을 의미하지는 않으며, 이 둘 사이의 간극에서 고객 경험이 무너집니다. 이 간극을 해소하려면 상담원이 단순히 데이터에 접근하는 것뿐만 아니라, 그 데이터를 바탕으로 실제로 조치할 수 있는 시스템에 접근할 수 있어야 합니다. 그 결과, 상담원은 환불을 처리하거나, 고객이 결제 과정을 원활하게 진행하도록 안내하거나, 상황에 따라 모든 맥락을 파악한 상태에서 인간 상담원에게 연결할 수 있습니다. 이를 통해 기업은 대규모로 고객 응대를 처리하면서도 인간 지원팀의 부담을 크게 줄이고, 통화 양쪽 모두의 경험을 향상시킬 수 있습니다.최근 Revolut와의 배포 사례에서글로벌 7천만 명의 고객을 보유한 핀테크 기업인 이곳에서는, 문제 해결까지 걸리는 시간이 8배 단축되고, 통화 성공률이 99.7%에 달했습니다.

이처럼 큰 변화를 추진하려면, 조직은 점진적으로 접근해야 하며, 회사의 핵심 미션과 긴밀하게 연계되고 강력한 경영진의 지원이 필요합니다. 기술적으로는, 비정형 환경에서의 추론에는 본질적인 위험이 따르므로 이를 신중하게 관리해야 합니다. 에이전트가 고객 관계 관리(CRM) 시스템 전반에서 조치를 취하거나, 포스 시스템에서 주문을 수정하거나, 케이스를 에스컬레이션할 수 있도록 한다면, 거버넌스 모델이 모델 자체만큼이나 중요해집니다. 이제 초점은 에이전트가 실제 업무를 처리할 수 있는지가 아니라, 안전하고 반복적으로 배포하기 위해 어떤 메커니즘이 필요한지로 옮겨갑니다.

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

에이전트 배포 vs. 소프트웨어 배포

에이전트 구축에 대해 더 깊이 들어가기 전에, 보이스 에이전트의 배포와 전통적인 소프트웨어 배포를 비교해볼 필요가 있습니다. 기업들이 수십 년간 해온 전통적인 소프트웨어 배포와 달리, 에이전트는 두 가지 주요 구성요소로 나눌 수 있습니다: 전통적인 소프트웨어와 핵심 오케스트레이터입니다.

소프트웨어:

소프트웨어: 관측 가능성 및 거버넌스

핵심 오케스트레이터

코어 오케스트레이터 구성 요소는 본질적으로 예측이 더 어렵지만, 답변 품질과 체감 지연 시간 모두에서 에이전트의 런타임 성능을 좌우합니다. 전통적인 소프트웨어와 달리, 이 구성 요소들은 자연어와 오디오를 다루기 때문에 입력 범위가 사실상 무한하며, 문장 표현, 맥락, 배경 소음, 사용자 행동의 작은 변화만으로도 시간이 지나면서 의미 있는 결과 차이가 발생할 수 있습니다. 이 때문에 기존의 테스트만으로는 충분하지 않습니다. 에이전트가 수백 개의 테스트 케이스를 완벽하게 통과해도 실제 운영 환경에서는 예측하기 어려운 방식으로 실패할 수 있습니다.버저닝, A/B 테스트, 전화 통신 및 첫 메시지 설정 등이 포함됩니다. 이러한 구성요소는 배포 후에도 거의 변동이 없어 동작이 매우 예측 가능합니다. 견고한 엔지니어링을 통해, 조직은 이러한 기능을 빠르게 구축하고, 다양한 지표, 트레이스, 로그를 통해 운영 성능을 깊이 있게 파악할 수 있습니다. 이 계층에서의 지연 시간 개선은 캐싱, 커넥션 풀링, 인프라 확장, 프로토콜 최적화 등 잘 알려진 패턴을 따르며, 결과도 예측 가능합니다.

이 계층의 지연 시간 역시 덜 결정적입니다. 모델 추론 시간, 오디오 아티팩트 삽입, 툴 호출 체인, 생성형 시스템 특유의 변동성 등이 영향을 미칩니다. 이러한 구성 요소를 잘 관리하려면 기존과는 다른 접근이 필요합니다. 평가 프레임워크, 운영 모니터링, 그리고 사전 가정이 아닌 실제 대화 데이터를 기반으로 한 지속적인 반복이 중요합니다.

이러한 차이는 조직이 도입을 어떻게 접근해야 하는지에 영향을 줍니다. 조직에 의미 있으면서도 위험이 낮은 사용 사례부터 시작해, 시스템에 대한 신뢰가 쌓이면 점진적으로 확장하는 것이 좋습니다.

릴리즈 사이클

경로 개척자 선정

음성 에이전트 도입을 시작하는 팀에게 올바른 경로 개척자를 선정하는 것은 가장 중요한 초기 결정 중 하나입니다. 이는 대부분 예상하는 것보다 기술과는 덜 관련이 있습니다. 초기 성공을 쌓고 끝없는 POC(개념 증명) 단계에 머무르지 않는 팀들은 공통점이 있습니다. 바로 다음 질문에 명확하게 답할 수 있다는 점입니다.

보이스 에이전트 도입을 시작하는 팀에게, 올바른 선도 사례를 선정하는 것은 초기 단계에서 가장 중요한 결정 중 하나입니다. 이는 대부분 예상하는 것보다 기술과는 덜 관련이 있습니다. 초기 성공을 쌓고 끝없는 POC(개념 검증)에서 벗어나는 팀들은 공통적으로 다음 질문에 명확하게 답할 수 있습니다.

• 이 사용 사례가 어떻게 측정 가능한 비즈니스 가치를 창출하는가? 시작에 적합한 사용 사례는 기술적으로 가장 흥미로운 것이 아니라, 이미 비즈니스가 중요하게 여기는 결과에 가장 큰 영향을 줄 수 있는 것입니다. 이는 매출 영향, 비용 절감, 고객 만족도 등 리더들이 이미 추적하고 책임지는 지표로 측정됩니다. 비즈니스 가치와의 직접적인 연결고리가 없다면, 에이전트를 제대로 만들기 위해 필요한 반복 과정을 정당화하기 어려워지고, 기술이 스스로 입증할 기회도 얻지 못한 채 동력이 꺾일 수 있습니다.
• 사용자에게 에이전트의 역할과 목적이 즉시 명확하게 전달되는가?역할의 모호함은 개발에서 운영으로 넘어갈 때 가장 흔하게 발생하는 문제 중 하나입니다. 에이전트가 무엇을 할 수 있고, 무엇을 할 수 없는지 사용자가 이해하지 못하면, 평가 도구가 예상하지 못한 방식으로 한계를 시험하게 됩니다. 역할이 명확한 에이전트는 첫 메시지부터 기대치를 설정하고, 범위를 벗어난 요청도 자연스럽게 처리합니다.
• 좋은 상호작용과 나쁜 상호작용은 무엇이며, 이를 구체적인 평가 기준으로 정립할 수 있는가?좋은 상호작용이란 단순히 에이전트가 작업을 완료하는 것만이 아니라, 사용자가 존중받았다고 느끼고, 적절한 시점에 에스컬레이션이 이루어지며, 결과가 비즈니스 의도와 일치하는 경우입니다. 평가 기준은 플랫폼에서 수집하는 작업 완료율, 에스컬레이션율 같은 정량적 지표와, 대화 자체를 분석해야 하는 대본 기반 기준으로 나뉩니다. 대본 기반 기준을 미리 정의하면 팀이 구체적인 목표를 설정할 수 있고, 자연스러운 출시 기준점도 마련됩니다. 에이전트가 평가 기준을 꾸준히 통과하고, 플랫폼 지표가 안정화되면 운영에 들어갈 자신감을 얻을 수 있습니다. 기준이 없다면, 출시 여부는 결국 주관적 판단에 맡겨집니다.
• 성능과 통제 사이의 트레이드오프는 무엇이며, 지금 단계에서 더 중요한 것은 무엇인가?에이전트에게 자율성을 많이 부여할수록 상호작용은 자연스럽고 유연해지지만, 검증된 범위를 벗어날 위험도 커집니다. 제한된 프롬프트와 엄격한 에스컬레이션 논리를 통해 통제를 강화하면 위험은 줄지만, 에이전트가 딱딱하게 느껴질 수 있습니다. 어느 한쪽 극단이 정답은 아닙니다. 너무 일찍 통제를 강화하면 단순한 IVR(자동응답시스템) 수준에 머물고, 신뢰를 쌓기 전에 너무 빠르게 확장하면 지원 부담이 이득을 넘어설 수 있습니다. 각 단계별로 이 균형점을 어디에 둘지 이해하는 것이 모델 설정, 에스컬레이션 논리, 에이전트의 지식이 프롬프트에 얼마나 담길지, 혹은 외부 데이터에서 가져올지 결정하는 데 영향을 줍니다.

초기 구축의 기준 잡기

실행 단계로 넘어갈 때, 팀은 소프트웨어만큼 오래된 방법론을 참고할 수 있습니다. 테스트 주도 개발(TDD)은 구축 과정 내내 에이전트가 핵심 지표에 맞춰 정렬되도록 돕는 뼈대 역할을 합니다.

실행 단계로 넘어갈 때, 팀은 소프트웨어만큼 오래된 방법론을 참고할 수 있습니다. 테스트 주도 개발(TDD)은 구축 과정 내내 에이전트가 핵심 지표에 맞춰 정렬되도록 하는 뼈대를 제공합니다.

초기 테스트 세트가 준비되면, 에이전트 개발은 시스템 프롬프트부터 시작합니다. 여기서 에이전트의 규칙, 톤, 접근 방식이 정의됩니다. 무엇을 해야 하고, 무엇을 하지 말아야 하며, 역할의 경계에서 어떻게 행동해야 하는지 등이 포함됩니다. 잘 설계된 시스템 프롬프트는 내용뿐만 아니라 구조도 중요합니다. 지침을 명확하게 구분된 섹션으로 나누고, 관련 안내를 함께 배치하며, 조건문 표현을 피하는 것이 에이전트의 일관된 행동에 큰 차이를 만듭니다. 이 단계에서 자주 참고하는 것이 바로 프롬프트 가이드입니다.에이전트 테스트는(은) 에이전트가 보여야 할 특정 행동을 반복적으로 검증합니다. 성공 평가 기준은 실제 인간 상담 통화를 검토하면서 도출하는 것이 가장 좋습니다. 에이전트 테스트는 예상 행동의 초기 세트로 시작해, 새로운 행동이 추가되거나 예외 상황이 발견될 때마다 점진적으로 확장합니다.

시스템 프롬프트와 함께 에이전트의 핵심 구성 요소도 설정합니다. LLM, 텍스트 음성 변환(TTS) 모델, 그리고 보이스입니다. LLM 선택은 주로 지연 시간과 성능의 균형 문제로, 속도에 최적화된 모델은 일부 추론 능력을 희생하고, 그 반대도 마찬가지입니다. TTS는 사용 사례가 가장 요구하는 것이 무엇인지(표현력, 저지연, 다국어 지원 등)에 따라 선택이 달라집니다. 보이스는 기술적 요소이자 브랜드 결정이기도 합니다. 모든 발신자에게 조직의 이미지를 전달하는 요소이기 때문에, 에이전트 개발자뿐 아니라 브랜드·마케팅팀도 함께 결정해야 합니다. 따라서 보이스 선택은 개발 과정과 병행할 수 있으며, 시작이나 마지막에 병목이 될 필요가 없습니다. ElevenAgents는 10,000개 이상의 보이스를 제공하며, 원하는 것이 없다면 팀이 직접 복제하거나 새로 만들 수도 있습니다.

여기서부터 에이전트는 선택적으로 지식 베이스,

이런 기반이 갖춰지면, 에이전트는 본격적인 테스트를 받을 준비가 됩니다.지식 베이스, 툴, 채널 설정 등을 추가로 확장할 수 있습니다. 각 추가 기능은 새로운 역량을 열어주지만, 동시에 테스트해야 할 영역도 늘어납니다. 전화 통신 연동, 외부 데이터베이스 접근, 고객을 대신해 조치하는 기능 등 어떤 것이든, 범위를 확장하기 전에 평가 기준에 맞춰 충분히 검증하는 것이 중요합니다. 툴이 추가되면, 시스템 프롬프트와 툴 설명에 언제, 어떻게 각 툴을 사용할지 명확하게 안내해, 에이전트가 일관되고 적절한 맥락에서 활용할 수 있도록 합니다.

운영 준비 단계로

초기 구축 단계에서 정의한 테스트와 평가 기준을 실제 에이전트에 적용하면, 개발은 빠른 반복의 루프가 됩니다. 테스트를 추가하고, 실패를 찾아내며, 시스템 프롬프트나 설정을 수정하고, 다시 실행하는 식입니다. 이 단계에서 발생하는 대부분의 실패는 모델 자체가 아니라 프롬프트의 문제입니다. 개별적으로는 명확해 보였던 지침이 실제 대화 중에는 모호하게 작동할 수 있습니다. 초기 테스트 세트가 예상하지 못한 예외 상황이 드러나기도 합니다. 이런 경우마다 대화에서 새로운 Next Turn 테스트를 만들 수 있습니다. 반복을 언제 멈출지에 대한 답은 명확합니다. 에이전트가 여러 번의 테스트에서 평가 기준을 꾸준히 통과하고, 작업 완료율·이관율 등 플랫폼 지표가 허용 범위 내에서 안정화되면 준비가 된 것입니다. 그래서 기준을 미리 정의하는 것이 매우 중요합니다. 기준이 없으면 준비 여부가 단순한 판단에 의존하게 되고, 목표점도 계속 바뀌게 됩니다.

실제로 대부분의 팀은 반복적으로 나타나는 소수의 실패 패턴이 전체 문제의 대부분을 차지한다는 것을 알게 됩니다. 가장 흔한 것은 프롬프트의 모호함(에이전트가 상충되거나 불충분한 지침을 받아 예측 불가능하게 행동하는 경우), 툴 오용(잘못된 맥락에서 툴을 호출하거나 필요할 때 호출하지 않는 경우), 이관 드리프트(에이전트가 너무 공격적으로 이관하거나, 넘겨야 할 대화를 계속 붙잡는 경우)입니다. 이런 문제는 프롬프트 수준에서 해결할 수 있습니다. 관련 지침을 강화하거나, 명확한 예시를 추가하거나, 이관 기준을 조정하면 대부분 충분합니다. 중요한 것은 운영 전 반드시 이런 문제를 잡아내는 것입니다.

가장 흔한 실수는 테스트 통과를 보장으로 착각하는 것입니다. '행복 경로'만 커버하는 테스트 세트는 쉽게 통과하지만 의미는 거의 없습니다. 거절, 대화 중 전환, 모호한 입력, 툴 사용이 많은 상호작용까지 폭넓게 커버해야 결과에 신뢰가 생깁니다. 마찬가지로, 시뮬레이션 테스트를 건너뛰고 턴 단위 테스트만 하면, 전체 대화에서만 드러나는 실패(예: 맥락 드리프트, 초반 실수가 누적되어 나쁜 결과로 이어지는 경우)를 놓치게 됩니다. 반복되는 실패 패턴이 해결되고, 에이전트가 예외 상황도 무난하게 처리하면, 스테이징에서 추가 반복의 효과는 점점 줄어듭니다. 이 시점부터는 실제 대화에서 얻는 신호가 더 가치 있습니다.

운영에 들어간다고 반복이 끝나는 것은 아닙니다. 학습의 중심이 인공 테스트에서 실제 운영 대화로 옮겨간다는 의미입니다. 운영 전 정의한 평가 기준이 이제는 실시간 성능을 측정하는 기준선이 되고, 그 위에서 반복이 계속됩니다.

피드백 루프, 평가, 반복 중단 시점 알기

테스트가 정의되고 실행되면, 파이프라인의 빈틈이 빠르게 드러납니다.

이 단계에서 가장 중요한 것은 변경을 가정하지 말고 반드시 검증하는 것입니다. 하나의 실패를 해결한 수정이 조용히 다른 문제를 만들 수 있습니다. ElevenAgents는 버전 관리를 지원해, 전체 사용자에게 적용하기 전에 일부 사용자에게만 새 버전을 테스트할 수 있습니다. 이를 통해 개선이 실제로 성과를 내는지, 아니면 실패 유형만 바뀌는지 확인할 수 있습니다.

무엇이 잘못될 수 있는가버저닝을 지원해, 전체 사용자에게 적용하기 전에 일부 사용자에게만 새로운 버전을 테스트할 수 있습니다. 이를 통해 개선이 실제로 성과를 내는지, 아니면 실패 유형만 바뀌는지 확인할 수 있습니다.

이 단계에서 가장 치명적인 실수는 분기 배포 없이 전체 사용자에게 바로 변경 사항을 적용하는 것입니다. 단계별 배포가 없으면, 각 변경의 영향을 분리해 볼 수 없고, 대규모에서는 플랫폼 지표의 개선 또는 악화 원인을 파악하기 거의 불가능해집니다. 전체 사용자를 테스트 환경으로 삼는 것은 위험할 뿐 아니라, 앞으로 신뢰 있는 결정을 내리는 데 필요한 관측 가능성을 잃게 됩니다.

배포 전략 외에도 주의해야 할 실패 유형이 두 가지 더 있습니다. 첫째는 최근 실패에 과도하게 반응하는 것입니다. 주목받는 대화에서 문제가 발생하면 즉각적이고 광범위하게 수정하고 싶어지지만, 전체 테스트를 거치지 않은 프롬프트 변경은 이전에 안정적이던 행동에 역효과를 낼 수 있습니다. 사소한 변경도 새로운 반복으로 간주하고 반드시 테스트해야 합니다. 둘째는 평가 기준의 변질입니다. 시간이 지나면서 팀이 무의식적으로 테스트 통과 기준을 낮추는 경우가 많습니다. 범위 설정 단계에서 정의한 평가 기준이 항상 기준점이 되어야 합니다. 기준이 너무 엄격하게 느껴진다면, 비공식적으로 완화하지 말고, 공식적으로 재정의하는 것이 옳은 방법입니다.

신뢰를 바탕으로 확장하기

트래픽을 늘릴지 여부는 시간 기준이 아니라 신뢰에 따라 결정해야 합니다. 에이전트가 여러 번의 테스트에서 평가 기준을 꾸준히 통과하고, 플랫폼 지표가 안정화되며, 분기 배포에서 대조군 대비 의미 있는 악화가 없을 때 확장 신호가 됩니다.

이 단계에서 자주 나오는 질문은 '얼마나 많은 트래픽이 있어야 결론을 내릴 수 있나'입니다. 분기별 100건 미만의 통화는 결과 평가에 변동성이 너무 커 신뢰하기 어렵습니다. 25건 중 60% 통과와 100건 중 60% 통과는 신뢰 수준이 완전히 다릅니다. 숫자뿐 아니라, 배치가 현실적인 입력(예외 상황, 드문 의도, 대량에서만 드러나는 실패 유형 등)을 충분히 포함할 만큼 커야 합니다.

트래픽이 많아질수록 잘되는 점과 문제점 모두 더 뚜렷하게 드러납니다. 핵심 실패 패턴이 해결되기 전에 확장하면, 되돌리기 어려운 지원 부담이 생깁니다.

반복과 검증의 순환

어디서 멈출지 아는 것은 무엇을 고칠지 아는 것만큼 중요합니다. 반복은 점점 효과가 줄어들고, 범위 설정 단계에서 정한 평가 기준을 에이전트가 꾸준히 충족할 때가 멈출 신호입니다. 그 시점 이후의 변경은 위험이 보상보다 커집니다.

"꾸준히 기준을 충족한다"는 것은 상황에 따라 다릅니다. 데이터 접근이나 연동이 제한된 팀은 이관율 50% 내외가 현실적인 한계일 수 있습니다. 데이터 접근이 충분한 곳에서는 작업 완료율 80% 이상, 이관율 20% 이하가 일반적인 목표입니다. 어떤 단일 수치보다 중요한 것은 안정성입니다. 몇 주간의 운영 트래픽에서 꾸준한 성능과 테스트 반복에서 의미 있는 악화가 없는 것이 진짜 신호입니다. 다음 반복의 기대 효과가 악화 위험보다 작아지면, 멈출 때입니다.

이것이 일이 끝났다는 의미는 아닙니다. 새로운 요구가 생기면, 처음부터 다시 시작해야 합니다. 첫 구축에서 사용한 범위 설정 질문은 두 번째에도 똑같이 중요합니다. 차이점은 두 번째 사이클에서는 이미 테스트 세트, 평가 기준선, 운영 경험이 쌓여 있다는 점입니다. 이 누적된 이점이 음성 에이전트에서 지속적인 가치를 얻는 조직과 POC 단계에 머무는 조직을 가릅니다.

결론

우리가 본 성공적인 팀들은 구축 전에 '좋은'의 기준을 명확히 정의하고, 반복 과정에서 원칙을 지키며, 각 배포를 다음 단계의 기반으로 삼습니다. 대화형 에이전트는 한 번 배포로 끝나는 것이 아닙니다. 실제 대화에서는 어떤 테스트 세트도 예측하지 못한 예외 상황이 드러나며, 개선 작업은 운영 전환 이후에도 계속됩니다.

ElevenAgents는 이러한 현실을 바탕으로 설계되었습니다. 에이전트 테스트, 대화 분석, 분기 배포는 개념 증명을 실제로 고객 문제를 대규모로 해결하는 시스템으로 바꾸는 핵심입니다. 이것이 바로 반드시 극복해야 할 간극입니다.

ElevenAgents는 이런 현실을 바탕으로 설계되었습니다. 에이전트 테스트, 대화 분석, 브랜치 롤아웃은 POC를 실제로 고객 문제를 대규모로 해결하는 시스템으로 바꾸는 핵심입니다. 이것이 바로 반드시 좁혀야 할 간극입니다.