AI를 활용한 음성 에이전트 구축 방법 (전체 가이드)

AI 빌더들이 잘 모르는 사실 하나를 알려드리겠습니다. 음성 에이전트에 꼭 필요한 건

최고의 모델이 아닙니다. 필요한 건 이거예요:

TLDR; 읽는 게 지루하거나 집중력이 부족하다면, 제가 만든 스킬 파일을 사용해서 전체 글을 에이전트에 붙여넣을 수 있습니다 ➡️https://github.com/codejunkie99/voice-agent-builder

구축에 필요한 것은:

• 실제 레이턴시 예산이 있는 실시간 파이프라인
• 올바른 순서로 연결된 다섯 가지 컴포넌트
• 모델이 환각에 빠지지 않도록 하는 확실한 근거
• 효과가 누적되는 주간 리뷰 루프

OpenAI는 2026년 5월 7일 GPT-Realtime-2를 출시했습니다. Salesforce AI Research는 3월 1일에 VoiceAgentRAG 논문을 발표했고, 같은 주에 Deepgram Flux가 베타에서 정식 버전으로 전환되었습니다. 이제 개별 부품들은 더 이상 문제가 아니었습니다.

문제는 이 부품들을 어떻게 연결하고, 에이전트가 무슨 말을 하게 할지였습니다.

저는 지난 3개월 동안 실제로 전화를 받는 음성 에이전트를 만드는 데 시간을 쏟았습니다. 처음부터 깔끔했다고 말하지는 않겠습니다.

• 첫 번째 빌드는 키오스크처럼 들렸습니다. 이틀 만에 폐기했습니다.
• 두 번째 빌드는 첫 1시간 동안 네 개의 가짜 약속을 "잡았습니다". 제가 알아채기 전까지요.
• 세 번째 빌드는 백그라운드 추출기가 새로운 사실을 기록한 후 컨텍스트 캐시를 무효화하는 것을 잊어서 메모리 누수가 발생했습니다.
• 제대로 작동하기 시작한 것은 네 번째 재작성이었습니다.

지금이라면 자신 있게 방어할 수 있는 버전에는 몇 가지 속성이 있으며, 이에 대해 앞으로 6,000단어에 걸쳐 설명하겠습니다.

• 파이프라인은 하나의 예산 안에서 하나의 작업을 수행합니다. 다섯 개의 컴포넌트, 종단 간 700ms 미만, 예외 없음.
• 지식은 문서에 있으며, 모델의 머리에서 꺼내오는 것이 아니라 듀얼 에이전트 캐시를 통해 검색됩니다.
• 대화 디자인은 눈이 아닌 귀를 위한 글쓰기 기술입니다. 대부분의 팀은 이를 부차적인 것으로 취급합니다. 하지만 그렇지 않습니다.
• 각 턴은 90일 후에도 현재 설정과 비교하여 재생할 수 있는 구조화된 로그를 작성합니다.

이 글은 그 90일 동안 제가 실제로 배운 것들과, 오늘 다시 시작한다면 가장 먼저 할 두세 가지 결정을 담고 있습니다.🔽🔽

음성 에이전트의 실제 정체

음성 에이전트는 마이크가 달린 챗봇이 아닙니다. 텍스트 API를 감싼 TTS 래퍼가 아닙니다.

실시간 오디오 시스템입니다. 레이턴시에 제약을 받습니다. 다섯 개의 컴포넌트가 300~800밀리초 윈도우 안에서 조율됩니다.

실제 이벤트 순서대로 본 파이프라인:

1. 사용자가 말합니다.
2. 오디오가 캡처됩니다.
3. 스트리밍 STT가 사용자가 아직 말하는 동안 단어 단위로 실시간 변환합니다.
4. 에이전트가 변환된 텍스트를 읽고 문서에서 관련 지식을 검색합니다.
5. LLM이 응답을 생성합니다.
6. TTS가 응답을 소리 내어 읽습니다.
7. 사용자가 듣습니다.

이 모든 화살표 하나하나는 여러분이 선택하고, 조정하고, 교체할 수 있는 컴포넌트입니다.

처음에는 챗봇 방식으로 구축해 보았습니다. STT가 완료되면 LLM으로 보내고, 전체 응답을 기다린 후 TTS로 보내고, 전체 오디오가 완료될 때까지 기다린 다음 재생했습니다.

끔찍했습니다. 마치 키오스크와 대화하는 느낌이었죠. 이틀 만에 삭제했습니다.

끔찍했던 이유는 레이턴시 숫자 자체가 나빠서가 아닙니다. 서류상으로는 괜찮았습니다. 이유는 인간이 턴 방식으로 대화하지 않기 때문입니다. 인간은 겹치는 스트림으로 대화합니다.

• 에이전트는 사용자가 문장을 마무리하는 동안에도 응답을 구상하기 시작해야 합니다.
• TTS는 LLM이 글쓰기를 마치기 전에도 말하기 시작해야 합니다.
• STT는 에이전트가 말하는 동안에도 계속 듣고 있어야 언제 조용히 해야 할지 알 수 있습니다.

중단될 수 없는 음성 에이전트는 음성 에이전트가 아닙니다. 음성 사서함입니다.

세 가지 아키텍처

세 가지뿐입니다. 제어하려는 대상에 따라 선택하세요.

체인 파이프라인

• 별도의 STT, LLM, TTS 서비스가 서로 연결됩니다.
• 각각의 작업에 특화된 세 개의 독립적인 모델.
• 텍스트가 그 사이를 흐릅니다.
• 잘 튜닝된 관리형 플랫폼에서 레이턴시는 약 600~700ms입니다.
• 가장 제어하기 쉽고, 디버깅이 쉬우며, 한 레이어씩 업그레이드하기 쉽습니다.

하프 캐스케이드

• 오디오가 변환된 텍스트가 아닌 오디오 자체를 듣는 멀티모달 모델로 직접 입력됩니다.
• 목소리의 좌절감, 억양 상승으로 암시되는 질문, 문장 중간에 바뀌는 언어 등을 포착합니다.
• 출력은 여전히 오디오 제어를 위해 특화된 TTS를 거칩니다.
• 레이턴시가 300~500ms로 낮아집니다.

네이티브 음성-음성

• 하나의 모델, 오디오 입력, 오디오 출력.
• 변환 레이어, 텍스트 핸드오프가 없습니다.
• 2026년, 주요 연구소들은 모두 네이티브 음성 모델을 출시했습니다.
• 레이턴시가 200~300ms로 낮아져, 발신자가 AI와 대화하고 있다는 것을 인지하지 못하는 임계값 아래로 떨어집니다.

어떤 것으로 시작할까

1. 체인 파이프라인으로 시작하세요. 이를 위한 최고의 도구가 존재합니다. 파이프라인에서 제품을 검증한 후, 레이턴시를 획기적으로 개선하고 싶을 때 음성-음성으로 전환하세요.
2. 저는 처음에 모든 것을 음성-음성으로 시도했습니다. 예약 플로우에는 탁월했습니다.
3. 하지만 12단계로 구성된 접수 양식에서는 무너졌습니다. 단일 모델이 9번째 턴이 되면 컨텍스트 팽창 없이 상태 머신을 머릿속에 유지할 수 없었기 때문입니다.
4. 해당 부분은 실제 상태 머신 레이어가 있는 체인 파이프라인으로 전환했고, 완료율이 3일 만에 61%에서 89%로 뛰었습니다.
5. 상태별 도구 범위 지정이 전체 수정 사항이었습니다.

연결해야 할 다섯 가지 컴포넌트

모든 체인 파이프라인은 동일한 다섯 가지 컴포넌트를 가집니다. 에이전트가 첫 통화를 시작하기 전에 채워야 할 다섯 가지 작업입니다.

귀 (스트리밍 STT)

STT 모델은 사용자가 아직 말하는 동안에도 들어오는 오디오를 단어 단위로 실시간 텍스트로 변환합니다. 이는 스택에서 가장 중요한 컴포넌트입니다. 여기서 발생한 전사 오류는 아래의 모든 것에 연쇄적으로 영향을 미칩니다.

2026년에 주목해야 할 점:

• 스트리밍 정확도. 사용자가 말을 마친 후뿐만 아니라 말하는 동안에도 정확해야 합니다.
• 단어 오류율. 실제 프로덕션 오디오에서 6~8%면 좋습니다. 12%를 넘으면 세 번째 통화마다 사용자를 불편하게 만듭니다.
• 내장형 턴 종료 감지. 2026년 가장 큰 UX 업그레이드입니다.

턴 종료 감지가 중요한 이유:

• 일반 STT는 텍스트를 반환합니다. 화자가 말을 마쳤는지는 알려주지 않습니다.
• 이것이 없으면 에이전트는 문장 중간에 끼어들거나 어색하게 2초를 기다립니다.
• 2026년의 스트리밍 STT 모델 웨이브는 텍스트를 생성하는 동일한 네트워크 내부에 턴 종료 감지 기능을 탑재하고 있습니다.
• 모델은 화자가 말을 마쳤다고 판단하면 턴-완료 신호를 방출합니다.
• 이 신호는 단순한 음향적 침묵이 아닌 의미론적 컨텍스트를 사용합니다. 흐려지는 말투를 잡아내고 숨 쉬는 간격은 무시합니다.
• 제공업체가 이 기능을 출시했다면 전환하세요. 에이전트가 말을 시작하기 전의 일시 정지가 모든 턴에서 200~400ms 줄어듭니다.

두뇌 (LLM)

LLM은 텍스트, 대화 기록, 검색된 지식을 읽고 무엇을 말할지 결정합니다. 또한 단어뿐만 아니라 행동도 결정합니다.

음성 특화 규칙:

• 플래그십이 아닌 작고 빠른 모델을 사용하세요. 프론티어 추론 모델은 첫 단어를 생성하는 데 1500ms가 걸립니다. 이는 침묵의 시간입니다. 동일 제품군의 더 작은 모델이 음성 턴에서 거의 항상 승리합니다.
• 실제 계획이 필요한 특정 복잡한 도구 호출에만 큰 모델로 에스컬레이션하세요.
• 시스템 프롬프트를 800토큰으로 제한하세요. 매 턴마다 다시 로드됩니다. 4000토큰 프롬프트는 모든 메시지에 레이턴시를 추가합니다.

함수 호출 (쉽게 설명):

• 각 함수가 수행하는 작업과 필요한 정보에 대한 설명과 함께 정의합니다.
• LLM은 설명을 읽고 대화 상태에 따라 언제 호출할지 결정합니다.
• 조건부 로직 트리가 없습니다. LLM은 자연어에서 의도를 함수에 매핑합니다.

함수 호출의 가장 흔한 프로덕션 실패는 예상과 다릅니다:

• LLM은 함수를 호출할 수 없을 때 오류를 발생시키지 않습니다. 대신 작업을 설명합니다.
• "예약이 확인되었습니다." 실제로는 아무것도 호출되지 않았습니다. 사용자는 예약되었다고 생각합니다. 하지만 그렇지 않습니다.
• 해결 방법은 도구를 현재 상태로 범위를 지정하는 것입니다. "이름 수집" 상태는 book_appointment를 노출해서는 안 됩니다. "세부 정보 확인" 상태는 check_availability를 노출해서는 안 됩니다.
• 상태 머신이 안전 레일이지, 시스템 프롬프트가 아닙니다.

지식 (RAG)

RAG는 에이전트가 모델의 훈련 데이터 대신 문서에서 답변할 수 있게 해주는 메커니즘입니다.

이것을 건너뛸 수 없는 이유:

• LLM은 특정 기준일까지의 공개 인터넷 데이터로 훈련됩니다.
• 세상에 대해서는 많은 것을 알고 있습니다. 하지만 여러분의 제품, 가격, 정책, 고객에 대해서는 전혀 모릅니다.
• RAG가 없으면 "엔터프라이즈 요금제에는 무엇이 포함되어 있나요?"라는 질문에 에이전트는 자신 있게 환각을 일으킬 것입니다.
• RAG가 있으면 응답하기 전에 문서에서 실제 답변을 검색합니다.

기본 메커니즘:

• 사용자가 질문합니다.
• 시스템이 쿼리를 임베딩합니다.
• 벡터 데이터베이스가 가장 관련성 높은 문서 청크를 반환합니다.
• 청크가 LLM의 컨텍스트에 주입됩니다.
• LLM은 해당 컨텍스트에서만 답변하도록 지시받습니다.

음성 특화 과제:

• 일반적인 벡터 데이터베이스 쿼리는 파이프라인에 50~300ms를 추가합니다.
• STT, LLM, TTS와 결합하면 레이턴시 예산을 초과합니다.
• 해결책은 듀얼 에이전트 캐시 패턴입니다. 아래에서 자세히 다룹니다.

입 (TTS)

TTS는 텍스트를 음성 오디오로 변환합니다. 간단해 보이지만 실제로는 인지된 품질의 주요 차별화 요소입니다.

중요한 점:

• 첫 오디오까지의 시간. 말을 시작하는 데 200ms가 걸리는 TTS는 출력 레이어에서만 레이턴시 예산의 1/3을 소모합니다.
• 음성 품질. 인간은 합성 음성에 매우 민감합니다. 미묘한 인공음, 부자연스러운 속도, 잘못된 강세는 모두 전체 시스템에 대한 평가로 이어집니다.
• 의도적으로 음성을 선택하세요. 사용자가 한 문장도 듣기 전에 신뢰 신호가 됩니다.

손 (함수 및 통합)

함수는 LLM이 대화 중에 취할 수 있는 작업입니다:

• 약속 잡기
• 주문 상태 조회
• 확인 SMS 전송
• 사람에게 전환
• CRM의 레코드 업데이트

이것이 바로 현대 음성 에이전트가 "결제하려면 1번을 누르세요" 시스템보다 훨씬 더 강력하게 만드는 아키텍처 변화입니다.

맞춰야 하는 레이턴시 예산

음성 에이전트에 관한 가장 중요하지만 잘 알려지지 않은 사실: 모든 처리 시간 1밀리초는 발신자가 앉아서 견뎌야 하는 1밀리초의 침묵입니다.

계산:

• 인간은 문장을 마친 후 500~700ms 이내에 대화형 응답을 기대합니다.
• 1초가 지나면 시스템이 버벅이는 것처럼 느껴집니다.
• 2초가 지나면 발신자가 에이전트 위에 말하기 시작합니다.

그 700ms가 전체 예산이며, 모든 컴포넌트에 걸쳐 분할됩니다.

컴포넌트별 예산 (고속 차선 vs 저속 차선):

• 전송. P2P 20-50ms. 릴레이 경유 50-100ms.
• STT 첫 중간 결과. 캐시 히트 시 100-150ms. 미스 시 150-250ms.
• 턴 종료 감지. 모델 통합형, 약 50ms. 침묵 임계값 방식, 300-600ms.
• RAG 검색. 캐시 히트 시 서브 밀리초. 로컬 BM25 + 재순위화 시 80-150ms.
• LLM 첫 토큰까지의 시간. 소형 모델 150-250ms. 프론티어 모델 400-600ms.
• TTS 첫 오디오까지의 시간. 고속 티어 60-100ms. 품질 티어 150-250ms.
• 네트워크 오버헤드. 단일 리전 내 총 40-80ms. 리전 간 총 100-160ms.
• 종단 간. 고속 차선 약 440ms. 저속 차선 약 700-900ms.

2026년의 두 가지 가장 큰 혁신:

1. 모델 통합형 턴 종료 감지. 모든 턴에서 200~400ms를 제거합니다. 올해 할 수 있는 가장 큰 단일 업그레이드입니다.
2. 듀얼 에이전트 캐시를 사용한 추측성 프리페치. 약 40%의 턴에서 "벡터 검색 미스"를 "캐시 조회 히트"로 만듭니다.

다른 모든 것은 이 두 가지에 비하면 미미한 차이입니다.

듀얼 에이전트 RAG 패턴

음성 루프 내부의 표준 RAG는 문제가 있습니다. 벡터 데이터베이스 쿼리는 80~300ms가 소요되며 모든 턴에서 레이턴시 예산을 초과합니다.

2026년 연구의 해답은 Salesforce AI Research가 3월에 발표한 VoiceAgentRAG 논문에서 나옵니다. 핵심 아이디어는 간단합니다.

• 실제 대화에서, 다음 질문은 일반적으로 현재 질문에서 예측 가능합니다.
• 가격에 대해 묻는 사람은 아마도 엔터프라이즈 티어에 대해 후속 질문을 할 것입니다.
• 설치에 대해 묻는 사람은 아마도 호환성에 대해 다음에 물어볼 것입니다.

따라서 두 개의 에이전트를 동시에 실행합니다.

백그라운드 에이전트 (느린 사색가)

• 사용자가 현재 응답을 듣는 동안 실행됩니다.
• LLM을 사용하여 가장 가능성 높은 3~5개의 후속 질문을 예측합니다.
• 각 예측에 대한 관련 문서 청크를 사전에 가져옵니다.
• 사용자가 현재 답변을 다 듣기도 전에 로컬 인메모리 캐시에 저장합니다.

포그라운드 에이전트 (빠른 화자)

• 먼저 인메모리 캐시를 확인하여 다음 실시간 질문을 처리합니다.
• 캐시 조회는 원격 벡터 데이터베이스 호출의 110ms에 비해 서브 밀리초가 소요됩니다.
• 캐시에 답변이 있으면 데이터베이스를 완전히 건너뜁니다.
• 캐시 미스가 발생하면 데이터베이스로 폴백하고 다음 번을 위해 해당 결과를 캐시합니다.

논문의 벤치마크 수치

• 쿼리의 75%가 캐시 히트
• 캐시 히트 시 검색 속도 316배 향상 (0.35ms 대 110ms)
• 200개 쿼리에서 누적 16초 레이턴시 절감

기억해야 할 원칙: 사용자의 듣기 시간을 컴퓨팅 시간으로 사용하세요. 사용자가 현재 응답을 듣기 시작하는 순간이 다음 질문을 준비하기 시작하는 순간입니다.

첫 번째 빌드에서는 음성 루프 내부에 일반 벡터 RAG를 시도했습니다. 턴당 110ms가 추가되었습니다.

대화의 느낌을 죽였습니다. 6주 차에 듀얼 에이전트 캐시 패턴으로 전환했습니다. 캐시 히트가 발생하는 40%의 턴은 에이전트가 대체하는 인간 콜센터 상담원보다 더 빠릅니다.

대부분의 빌더가 건너뛰는 분야, 대화 디자인

가장 빠른 STT, 가장 작은 LLM, 가장 똑똑한 RAG 캐시를 가질 수 있습니다. 하지만 에이전트가 말하는 방법을 모르면 발신자는 전화를 끊을 것입니다.

대화 디자인은 눈이 아닌 귀를 위한 글쓰기 기술입니다.

처음에 잘못해서 배운 후 지금 따르는 규칙들

• 짧은 문장으로 말하세요. 음성 정보에 대한 평균 인간 주의 집중 시간은 8~10초입니다. 15초 응답은 너무 깁니다. 두 개의 턴으로 나누세요.
• 한 턴에 두 가지 질문을 절대 하지 마세요. 발신자는 작업 기억에 하나만 담을 수 있습니다. 하나를 묻고, 기다린 후, 다음을 물으세요.
• 인정 구문을 사용하세요. "알겠습니다." "네." "확인해 보겠습니다." 이는 사용자가 말을 마치고 응답이 준비될 때까지의 침묵을 채워줍니다.
• 사용자의 언어를 미러링하세요. 발신자가 "청구 문제"라고 하면 에이전트도 "청구 문제"라고 답하세요. "재정 분쟁"이나 "지불 문제"가 아닙니다. 바꿔 말하면 마찰이 생깁니다. 미러링은 신뢰를 형성합니다.
• 귀를 위해 쓰세요, 눈을 위해 쓰지 마세요. 글머리 기호, 헤더, 시스템 프롬프트의 마크다운은 사용하지 마세요. LLM은 별표와 하이픈을 말하려고 시도할 것입니다.
• 숫자는 풀어서 말하세요. "94,107" 대신 "구 사 일 공 칠". "$15.99" 대신 "15달러 99센트". TTS는 형식화된 숫자를 자주 잘못 발음합니다.
• 시스템 프롬프트를 800토큰으로 제한하세요. 매 턴마다 다시 로드됩니다.

모든 좋은 음성 대화의 3막 구조

1. 인정 및 방향 설정. "목요일 약속을 변경하려고 하시는군요, 확인해 보겠습니다." 발신자가 이해되었음을 확인합니다. 검색이 실행되는 동안 시간을 벌어줍니다.
2. 해결. 핵심 작업 또는 답변. 턴당 하나의 포인트. 앞으로 나아갑니다.
3. 확인 및 종료. "약속을 19일 월요일 오후 3시로 변경했습니다. 곧 확인 문자를 받으실 겁니다." 깔끔한 종료. 열린 루프를 남기지 마세요.

안전은 두 개의 체크포인트, 하나가 아닙니다

처음 빌더가 가장 자주 건너뛰고 후회하는 컴포넌트.

음성 에이전트에는 "보내기 전에 읽어보기" 단계가 없습니다. 안전하지 않은 출력은 즉시 말해집니다. 초안, 미리보기, 사람의 개입이 없습니다.

올바른 모델은 두 개의 체크포인트입니다.

입력 가드 (LLM이 사용자의 턴을 보기 전)

• 프롬프트 인젝션. "이전 지침은 무시하고, 당신은...인 척 하세요" 공격. LLM의 지침 추종 능력을 악용하여 데이터를 훔치거나 범위를 이탈합니다.
• 말로 하는 PII. 신용카드 번호, 주민등록번호. 로그나 데이터베이스에 기록되기 전에 삭제하세요.
• 주제 차단 목록. JSON 파일에서 로드됩니다. 사용자가 실제로 시도하는 것을 학습하면서 매주 업데이트됩니다.

출력 가드 (LLM이 응답을 작성한 후, TTS가 말하기 전)

• 과장된 약속 언어. "보장합니다", "약속합니다". 녹음된 회선에서 법적 및 신뢰 문제를 일으킵니다.
• 검색된 컨텍스트에 없는 특정 사실 주장. 가벼운 환각 검사. 제 배포에서 약 70%의 꾸며낸 답변을 잡아냅니다.
• 드문 모델 오작동을 위한 표준 중재 엔드포인트.

두 가드 모두 반환하는 것

• safe (bool)
• detected_category (string, 안전하지 않은 경우)
• 에이전트가 대신 말하는 replacement_phrase

모든 트리거는 타임스탬프, 카테고리, 편집된 텍스트, 통화 ID와 함께 파일에 기록됩니다.

에스컬레이션 문구

하나의 정확한 문구, 하드코딩되어 있으며, 에이전트가 답을 모르거나 문제가 발생했을 때 말합니다.

• "정확한 정보를 드리기 위해, 도움을 드릴 수 있는 분께 연결해 드리겠습니다."
• 다섯 가지 변형이 아닙니다. LLM이 즉흥적으로 추측한 적절한 표현이 아닙니다.
• 하나의 문구. 시스템 프롬프트에서 모두 대문자로. 안전 검사가 발동될 때의 기본 동작.

첫 번째 빌드에서 출력 가드 없이 배포했습니다. 에이전트는 실제 가격보다 30% 낮은 가격을 자신 있게 인용했습니다.

그 가격은 지식 베이스의 오래된 문서에 있었습니다.

환각 검사는 올바른 가격이 검색된 컨텍스트에 없었기 때문에 이를 잡아냈을 것입니다.

평가, 또는 좋은지 아는 방법

측정할 수 없으면 개선할 수 없습니다. 대부분의 팀은 평가를 건너뛰고 고장난 에이전트를 배포합니다.

4계층 프레임워크

계층 1: 인프라. 기본 연결.

• 실제 도메인에서의 WER (벤더 벤치마크가 아님)
• 전체 파이프라인의 p50, p95, p99 레이턴시
• 첫 오디오까지의 시간
• 전송에서의 오디오 품질

계층 2: 실행. 에이전트가 요청된 대로 수행하는가.

• 작업 성공률
• 도구 호출 정확도
• 매개변수 정확성
• 응답 근거성
• 작고 빠른 모델에서 LLM-as-judge 사용. 네 가지 예/아니오 질문: 올바르게 답변했는가, 근거를 유지했는가, 음성에 자연스러웠는가, 적절히 간결했는가.

계층 3: 사용자 행동. 대화하는 것이 자연스러운가.

• 끼어들기 복구율
• 재프롬프트율
• 평균 턴 길이
• 대화 복구 횟수
• 주당 20통의 통화를 샘플링하세요. 실제 대화록을 읽으세요. 10개 안에 패턴이 보일 것입니다.

계층 4: 비즈니스 결과. 문제를 해결하는가.

• 컨테인먼트율 (인간 개입 없이 해결된 통화 비율)
• 전환율
• 고객 만족도
• 첫 통화 해결율
• 컨테인먼트에 대해 최적화하세요. 이것은 다른 모든 것과 상관관계가 있으며 계측 없이 측정하기 가장 쉽습니다.

테스트 세트 구성

출시 전에 구축하세요. 최소 50개의 대화.

• 40% 해피 패스
• 30% 에지 케이스
• 15% 오류 처리
• 10% 적대적 (프롬프트 인젝션, 탈옥 시도)
• 5% 음향 변형 (배경 소음, 심한 억양, 스피커폰)

각 시나리오에 대해:

• 어떤 도구가 호출되었어야 하는지
• 어떤 매개변수로
• 에이전트가 무엇을 말했어야 하는지

주간 리뷰 루프

매주 월요일 아침. 30분.

1. 메트릭 가져오기
2. 20통의 통화 샘플링 (7건 에스컬레이션, 7건 해결, 6건 무작위)
3. 대화록 읽기
4. 가장 흔한 실패 유형 하나를 지목하기
5. 하나의 변경 수행 (항상 한 번에 하나의 변수만)
6. 48시간 동안 A/B 테스트
7. 승리한 쪽 배포

근거는 신뢰 시스템입니다

대부분의 빌더는 RAG를 성능 기능, 즉 더 정확한 답변을 얻는 방법으로 생각합니다. 그 프레이밍은 RAG의 가치를 과소평가합니다.

음성 에이전트에서 모든 답변의 정확성은 제품이 얼마나 신뢰할 수 있는지에 대한 직접적인 진술입니다. 가격, 보장 범위 또는 정책에 대한 잘못된 답변을 자연스러운 목소리로 자신 있게 들은 발신자는 단순히 불편함을 느끼는 것을 넘어 속았다고 느낄 것입니다.

신뢰 약속의 구현에는 네 부분이 있습니다.

1. 진실의 원천

• 여러분의 문서지, 모델의 훈련 데이터가 아닙니다.
• 시스템 프롬프트는 이를 명시적으로, 대문자로 말해야 합니다: 제공된 컨텍스트에서만 답변하세요.
• 모델은 여전히 때때로 일반 지식으로 표류하지만, 명시적인 지침은 그 비율을 한 자릿수로 낮춥니다.

1. 우아한 거절

• 에이전트가 답을 찾을 수 없으면 직접적으로 말합니다.
• 정확한 문구가 중요합니다.
• "정확한 정보를 드리기 위해 확인해 보겠습니다"는 우아한 전환을 위한 시간을 벌어줍니다.
• "잘 모르겠습니다"는 무능력하게 들립니다.
• "제 정보에 따르면"은 변호사의 애매한 표현처럼 들립니다.
• 하나의 문구를 선택하고, 하드코딩하고, LLM이 여기서 즉흥적으로 말하게 두지 마세요.

1. 신뢰도 인식 응답

• 검색된 청크의 최고 BM25 점수는 신뢰도의 유용한 대용 지표입니다.
• 점수 0.6 이상: 에이전트가 자신 있게 답변합니다.
• 점수 0.3 ~ 0.6: 에이전트가 답변하지만 "제 생각에는"이라는 헤지를 추가합니다.
• 점수 0.3 미만: 에이전트가 답변하지 않고 전환을 제안합니다.
• 시스템 프롬프트 구성 코드의 20줄 변경. 환각을 대략 절반으로 줄입니다.

1. 지식 베이스 위생

• 오래된 문서는 오래된 답변을 생성하며, 이는 위험한 답변입니다.
• 금요일 감사를 실행합니다: 해당 주의 신뢰도 점수 하위 5% 응답을 읽습니다.
• 절반의 경우 답변은 맞았지만 검색이 오래된 청크를 찾았습니다.
• 청크를 업데이트하고, 다시 임베딩하고, 다음 주는 더 조용해집니다.

주의해야 할 점

당신을 괴롭힐 여섯 가지 실패 모드.

파이프라인이 아닌 전송에 VAD 배치

• 문제. 에이전트가 자신의 TTS 출력에 트리거되어 끼어들기 루프에 빠지거나 턴 종료를 전혀 감지하지 못합니다.
• 해결책. VAD 분석기는 항상 전송에 배치하세요. 최근 어시스턴트 출력과 일치하는 STT 텍스트를 무시하는 에코 가드와 쌍을 이루세요.

잘못된 상태에서 사용 가능한 도구

• 문제. LLM이 여전히 환자 이름을 수집하는 상태에서 book_appointment를 호출합니다. 또는 실제로 발생하지 않은 예약을 지어냅니다.
• 해결책. 상태별로 도구 범위를 지정하세요. 하나의 상태, 자신의 함수만. 상태 머신이 안전 레일이지, 시스템 프롬프트가 아닙니다.

함수 핸들러가 예외를 발생시키고 결과 콜백을 호출하지 않음

• 문제. LLM이 오지 않는 도구 결과를 기다리며 멈춥니다. 또는 하나를 환각합니다.
• 해결책. 모든 핸들러는 try/except로 감쌉니다. 모든 분기는 결과를 다시 보냅니다. 모든 실패에는 말로 하는 폴백이 있습니다. 빈 결과는 절대 없습니다.

프롬프트에서 사용자 데이터 검증 (코드에서 하지 않음)

• 문제. LLM이 12번째 통화에서 "john@"을 실제 이메일로 받아들입니다. 47번째 통화에서 플러스 기호가 있는 유효한 이메일을 거부합니다.
• 해결책. 검증은 Python에 있습니다. 이메일용 정규식, 날짜용 날짜 파서, 이름 길이 확인, 검증 실패 시 다시 묻는 응답.

긴 통화에서 컨텍스트 윈도우가 무제한으로 증가

• 문제. 코드 변경 없이 p95 레이턴시가 주간에 걸쳐 위쪽으로 표류합니다. 20번째 턴이 되면 턴당 12K 토큰을 보내고 있습니다.
• 해결책. 마지막 N턴 + 시스템 프롬프트의 슬라이딩 윈도우. 또는 각 개별 단계가 끝날 때의 이정표 기반 컨텍스트 재설정.

TTS가 코드와 ID를 문자 그대로 읽음

• 문제. 확인 코드 "A3X7"가 "에이 쓰리 엑스 세븐"으로 쉼 없이 나옵니다. 환자는 어쨌든 반복을 요청합니다.
• 해결책. NATO 음성 알파벳 확장과 SSML 중단 태그 사용. 느리게 들리지만 처음에 올바르게 읽힙니다.

다르게 할 일들

• 1일차에 턴 로그 스키마를 구축하세요, 4주 차가 아니라. 재생 엔드포인트는 제가 만든 가장 가치 있는 도구였고 필요해진 후에야 만들었습니다.
• 처음부터 의미론적 턴 종료 감지를 사용하고 침묵 임계값과 싸우지 마세요.
• 시스템 프롬프트가 300단어를 넘는 날 실제 상태 머신으로 전환하세요. 산문으로 상태 머신을 인코딩하려고 하지 마세요.
• 프롬프트에서 검증을 중단하세요. LLM은 파서가 아닙니다. Python이 파서입니다. Python을 사용하세요.
• 통화 시작 시 가장 가능성 높은 5개의 RAG 문서를 캐시하세요. 턴 루프 내부에서 벡터 검색을 건너뛰세요.
• 검색을 구축하기 전에 잡담 게이트를 구축하세요. "안녕하세요"는 시스템에서 가장 저렴한 200ms 절감입니다.
• 첫 프로덕션 통화 전에 평가 세트를 실행하세요. 최소 50개의 대화.
• 1일차부터 내구성 있는 추출 큐를 배치하세요. 단일 재시도 워커가 있는 pending_extractions Postgres 테이블은 200줄이면 되고 실제 장애를 막아줍니다.
• 50번째 통화마다 비동기 LLM 평가자를 실행하세요. 근거성, 관련성, 간결성에 대해 점수를 매기세요. 대시보드로 파이프하세요. 드리프트는 실제입니다.
• 주간 리뷰 루프를 실행하세요. 매주 월요일 20통의 통화를 샘플링하세요. 하나의 변경을 수행하세요. A/B 테스트하세요. 승리한 쪽을 배포하세요.

결론

음성 에이전트는 AI처럼 보입니다. 하지만 실시간 시스템처럼 작동합니다.

배포하는 팀은 그렇게 취급합니다. 6개월 늦게 배포하는 팀은 더 나은 프롬프트가 시스템 문제를 해결할 것이라고 생각합니다.

자신의 파이프라인을 소유하세요. 자신의 로그를 소유하세요. 어떤 장애라도 한 번의 재생으로 해결할 수 있는 일반 파일에 보관하세요.

첫 번째 에이전트는 주말이면 완성했지만, 프로덕션 시스템을 구축하는 데는 10주가 걸렸습니다. 그 이후로는 제가 손대지 않아도 매일 더 나아지고 있습니다. 사용자는 그런 점을 측정하지 않습니다. 그저 에이전트가 기다리게 하지 않고 "감사합니다"라고 답한 것만 알아차릴 뿐입니다.

면책 및 공개

이 글은 저자가 직접 조사하고 작성했으며, AI 모델이 편집을 도왔습니다. 썸네일은 Pinterest에서 가져왔습니다.

이 글은 저자가 더 깊은 인프라에서 음성 에이전트를 작업하면서 조사하고 작성했습니다.

Perplexity, Claude, ChatGPT를 사용한 진화하는 노트와 심층 연구, 그리고 학부 수준의 몇몇 대학 교재에서 얻은 시스템 설계 및 API 설계를 기반으로 합니다.

Minimax M2.7과 Claude Opus 4.7이 문법 오류와 서식을 철저히 편집했습니다.