통화는 자연스러웠는데, 예약은 틀리게 잡혔다
AI 전화 에이전트가 또박또박 말하고 적절히 맞장구쳤다고 업무까지 성공한 것은 아닙니다. 고객 이름을 잘못 기록하거나, 지원하지 않는 일정 변경을 확정하거나, 사람에게 넘겨야 할 요청을 혼자 마무리할 수 있으니까요. 아웃바운드 통화라면 발신 조직과 목적을 밝히지 않거나 수신 거부 요청을 놓치는 것도 실패입니다. 대화 품질과 업무 완료 품질은 다릅니다.
ThunderPhone에서 먼저 볼 것도 분당 2센트보다 실패를 다루는 구조입니다. 배포 전에는 AI 발신자로 전체 대화를 시뮬레이션하고, 제한된 실통화에서 발견한 특정 실패 턴은 Validation example로 저장해 수정한 초안에 다시 재생할 수 있습니다.
다만 Validation 실패가 배포를 자동으로 막아주지는 않습니다. 결과를 검토한 뒤 그대로 배포할 수 있고, 대시보드의 Success Rate도 AI 채점에 기반합니다. 결국 운영자가 실패를 수집하고, 사람이 업무 결과를 판정하고, 수정 뒤 같은 상황을 다시 실행하는 절차를 만들어야 합니다.
가입부터 첫 시뮬레이션 확인까지 이어가세요
첫 과제는 ‘웨비나 참석 여부 확인’처럼 결과를 명확히 판정할 수 있는 업무가 좋습니다. 처음부터 전체 영업 흐름을 맡기면 어떤 지시가 문제였는지 찾기 어렵습니다. 아래 입력과 판정 기준은 ThunderPhone이 성능을 보장한 공식 템플릿이 아니라, 품질 루프를 시작하기 위한 편집 예시입니다.
- ThunderPhone 앱에 가입하거나 로그인하고 에이전트 초안을 엽니다. 역할, 발신 조직·연락처 번호와 목적, 반드시 확인할 값, 금지 행동, 수신 거부 처리와 구체적인 사람 연결 절차를 프롬프트에 적으세요. ThunderPhone의 프롬프팅 가이드는 전환 번호나 콜백 약속처럼 에이전트가 실제로 수행할 수 있는 hand-off 경로를 지정하라고 안내합니다. Talk를 누르고 브라우저의 마이크 권한을 허용해 현재 초안이 응답하는지 확인합니다. 시뮬레이션 전에 콜백 담당자와 확인 담당자를 정하고 아래의 후속 요청 기록표도 준비하세요. 아직 Deploy하지 않습니다. Talk와 Simulation은 현재 초안을 대상으로 작동합니다.
- 결제수단과 첫 시뮬레이션 비용을 준비합니다. Organization → Billing Settings에서 결제수단을 등록하고, 첫 Simulation 승인 화면에 표시될 예상액을 감당할 조직 잔액을 충전하세요. 시뮬레이션은 AI 발신자와 대상 에이전트 양쪽 비용이 조직 잔액에서 차감됩니다. 전화번호를 통한 실통화까지 시험하려면 공식 빠른 시작에서 안내하는 최소 US$3의 선불 잔액이 필요합니다. 이어서 Config에서 엔진·언어·음성을 고르고 화면에 표시되는 올인 분당 요금을 기록합니다.
- 에이전트 빌더에서 Simulation을 엽니다. 첫 검증은 전화번호 대신 에이전트 직접 연결을 선택하세요. 정상 사례와 함께 사람 상담 요청, 지원하지 않는 변경, 재연락 거부가 포함된 예외 사례를 입력합니다. 실행 전에 표시되는 최대 10분 기준 예상 비용을 확인해 승인하세요. AI 발신자와 대상 에이전트 양쪽에 사용료가 발생합니다.
- Call History에서 종료된 시뮬레이션을 확인합니다. 대화록, 녹음, 자동 평가와 도구 호출을 함께 보세요. 운영자는 조직명·연락처 번호·통화 목적을 밝혔는지, 이름과 참석 여부가 정확한지, 금지된 변경을 확정하지 않았는지, 사람 요청에는 회신 번호와 기한을 확인했는지, 후속 요청 기록표에 담당자가 배정됐는지, 재연락 거부에는 사과하고 추가 설득 없이 종료했는지를 별도로 판정합니다.
- 내부 필수 기준을 만족한 초안만 Deploy합니다. 발신자 식별, 필수 값의 정확성, 금지 행동 방지, 사람 연결 절차와 수신 거부 종료 절차를 모두 통과한 경우에만 운영 버전으로 승격하세요. 하나라도 실패하면 프롬프트를 수정해 같은 Simulation부터 다시 실행합니다.
첫 입력 예시
에이전트 프롬프트: “당신은 [조직명]의 웨비나 참석 확인 담당자다. 통화를 시작하면 ‘안녕하세요, [조직명]에서 [웨비나명] 참석 여부를 확인하려고 전화드렸습니다. 저희 연락처는 [조직 연락처 번호]입니다’라고 조직명·연락처·목적을 먼저 밝힌다. 신청자의 이름과 참석 여부만 확인한다. 결제·할인·개인정보 변경을 약속하지 않는다. 상대가 재연락을 원하지 않는다고 말하면 사과하고, 연결된 수신 거부 기록 도구가 있으면 해당 연락처를 수신 거부로 기록한 뒤 즉시 통화를 종료한다. 기록 도구가 없더라도 추가 질문이나 설득 없이 종료한다. 기록과 답변이 충돌하거나 상대가 사람과 통화하기를 요청하면 먼저 회신받을 번호를 읽어 확인하고 ‘담당자가 확인한 연락처로 다음 영업일 안에 다시 전화드리겠습니다’라고 안내한다. 이후 재연락을 거부하면 콜백 약속을 취소하고 수신 거부 절차를 우선한다. 이후 참석 상태나 시간을 변경하지 말고 대화를 종료한다.”
[조직명], [조직 연락처 번호], [웨비나명], ‘다음 영업일’은 내부 시험을 위한 편집 예시입니다. 시험 전 모든 대괄호를 실제 조직명·연락 가능한 조직 전화번호·통화 목적으로 바꾸고, 콜백 기한은 담당자가 지킬 수 있는 값으로 정하세요. ThunderPhone의 미국 발신 안내에는 발신자 식별과 연락처 번호 제공이 함께 적혀 있습니다. 실제 통화 전환을 시험하려면 조직이 관리하는 테스트용 E.164 형식의 목적지 번호를 프롬프트에 명시해야 하며, 시뮬레이션 중 외부 통화가 발생할 수 있음을 먼저 확인해야 합니다.
예외 사례: “신청자가 소음이 있는 장소에서 한국어로 이름 철자를 두 번 정정한 뒤 지원되지 않는 참석 시간 변경과 사람 상담을 요구하고, 마지막에는 다시 전화하지 말라고 말한다.” 조직과 목적을 먼저 밝혔는지, 이름을 추측하거나 변경을 확정하지 않았는지, 수신 거부 요청 뒤 추가 설득 없이 종료했는지를 확인하세요. 수신 거부 기록 도구가 연결돼 있다면 해당 도구 호출도 필수 판정 항목입니다.
2센트는 완성된 통화의 가격이 아니에요
공식 기본 엔진 요금은 Spark 2센트, Bolt 5센트, Storm 9센트입니다. 선불 종량제지만, Supervision을 켜면 Spark와 Storm에서 분당 8센트가 추가됩니다. 이는 사람이 듣는 서비스가 아니라 두 번째 AI가 각 턴의 지시 준수를 검사하고 필요할 때 조용히 개입하는 옵션입니다. 음성·언어 경로, 긴 프롬프트, Storm 추가 옵션, 번호와 전화망 비용에 따라 최종 요금은 달라질 수 있습니다.
| 선택 | 기본 요금 | 먼저 비교할 업무 |
|---|---|---|
| Spark | 2¢/분 | 참석 확인처럼 짧고 정형화된 흐름 |
| Bolt | 5¢/분 | 일반적인 응답 품질과 속도의 균형이 필요한 흐름 |
| Storm | 9¢/분 | 긴 지침과 여러 예외를 처리해야 하는 흐름 |
| Supervision | +8¢/분 | Spark·Storm에서 두 번째 AI의 턴별 검사가 필요한 흐름 |
시뮬레이션도 무료 복제 통화가 아닙니다. AI 발신자는 Spark 요금으로, 대상 에이전트는 실제 설정에 따라 계산됩니다. 양쪽 모두 Spark이고 추가 옵션과 전화망이 없다면 엔진 요금의 단순 합계는 분당 4센트지만, 이는 실제 청구액을 보장하는 견적이 아닙니다.
가격은 성공한 업무 1건의 원가로 비교하세요.
통화비와 시뮬레이션 비용에 재통화, 사람 연결 또는 콜백, 잘못된 예약과 수신 거부 누락을 처리한 비용을 더한 뒤 실제 완료된 예약이나 검증된 리드 수로 나눕니다. 분당 단가가 낮아도 실패와 재통화가 늘면 전체 원가는 더 높아질 수 있습니다.
제한 실통화는 번호 검증과 Campaign 설정까지 해야 합니다
브라우저 시뮬레이션을 통과했다고 실제 전화 경로까지 확인된 것은 아닙니다. ThunderPhone의 미국 데모 번호는 인바운드 테스트 전용이므로 고객에게 발신하는 시험에는 VoIP 제공업체에서 보유한 번호를 연결하고 왕복 검증해야 합니다.
- Connections → VoIP에서 제공업체를 연결합니다. Twilio·Telnyx 같은 지원 제공업체의 인증정보를 입력해 Connect & Test를 완료하거나, 수동 SIP 연결이라면 Test & Save Connection을 통과시키세요.
- Phone Numbers → Add number → Connect VoIP provider에서 보유 번호를 가져옵니다. 인바운드 확인과 아웃바운드 권한 확인을 포함한 왕복 검증이 끝나 번호가 양방향 사용 가능 상태인지 확인하세요. 검증에 실패하면 제공업체 인증정보와 SIP 설정부터 바로잡아야 합니다.
- 적용 대상 조직이라면 관리자의 준수 책임 확인을 마칩니다. 첫 캠페인이나 API 발신 전에 요구되는 일회성 절차지만, 이 화면이 실제 수신 동의, 발신자 식별, 고지와 수신 거부 요건을 대신 검증해 주지는 않습니다.
- Engagement → Campaigns → New campaign을 엽니다. 배포된 에이전트와 검증된 VoIP 발신 번호를 선택하고,
phone또는phone_number열이 있는 연락처 CSV를 올립니다. 첫 시험에는 통화 목적과 동의가 확인됐고 내부 수신 거부 목록에 없는 소수 연락처만 넣으세요. - 수신 거부 기록의 담당자와 완료 기준을 먼저 정합니다.
아래는 편집부가 제안하는 운영 절차입니다. 통화 전 Call History 확인 담당자와 실제 콜백 담당자를 지정하고, 공유 시트나 CRM에 통화 ID·확인한 회신 번호·요청 시각·담당자·기한·상태·완료 시각을 기록할 칸을 만드세요. 매 통화 뒤 확인 담당자가 대화록을 읽고 콜백 건을 등록·배정하며, 콜백 담당자가 기한 안에 회신하고 실제 연결 결과와 시각을 남깁니다. 미연결이면 완료로 닫지 않고 재시도 상태로 둡니다. 자동 등록 도구를 연결했다면 실제 작업 생성과 담당자·기한 저장까지 확인해야 합니다.
재연락 거부는 콜백보다 우선합니다. 요청이 나오면 대기 중인 콜백을 취소하고 내부 제외 목록에 등록한 뒤 다음 캠페인 CSV에서 번호가 빠졌는지 확인하세요. ‘콜백하겠다’는 발화는 접수일 뿐, 실제 회신 완료나 요청 철회 확인과 구분해 기록합니다. - 통화 시간대와 재시도 조건을 정합니다. 제품은 동시 통화 1~10을 지원하고 기본값은 3이지만, 처음에는 동시 통화 1로 두는 것을 편집 예시로 권합니다. 이는 공식 성능 보장값이 아니라 실패 한 건을 바로 검토하기 위한 보수적인 시작값입니다. 수신 거부나 명시적 거절에는 재시도하지 않도록 운영 기준을 맞춘 뒤 예상 비용에 동의하고 Start를 누르세요.
- 성공 여부는 Call History와 내부 제외 목록에서 함께 확인합니다. 검증한 번호로 발신된 통화가 종료 상태로 기록되고 대화록·녹음·도구 호출을 검토할 수 있어야 합니다. 조직명·연락처 번호·목적을 밝혔는지, 요청 기록표에서 약속한 콜백의 실제 완료 또는 요청 철회를 확인했는지, 수신 거부 요청에는 즉시 종료하고 기록 도구 또는 담당 운영자를 통해 다음 발신 대상에서 제외했는지까지 확인해야 전화망 시험이 끝난 것입니다.
제품의 확인 화면이 법률 검토를 대신하지는 않습니다.
연락처를 올리기 전에 통화 목적과 수신 지역에 적용되는 동의, 발신자 식별, AI·녹음 고지, 개인정보 처리와 수신 거부 기준을 확인하세요. 대상 국가와 통화 유형이 정해지지 않았다면 적용 규정을 하나로 단정할 수 없습니다.
실통화의 실패 한 턴을 회귀 테스트로 바꾸세요
Validation sets의 실무적 가치는 실제 비시뮬레이션 통화의 문제 장면을 고정해 다시 실행할 수 있다는 데 있습니다. 특정 에이전트 턴을 고르면 그때까지의 대화 맥락, 관련 발신자 오디오와 실제 응답을 가져올 수 있고, 사람이 기대 행동과 허용할 도구 호출을 수정해 Active example로 저장할 수 있습니다.
수정한 현재 초안에 예제를 실행하면 Pass·Warn·Fail·Skipped·Error 상태와 통과율을 볼 수 있으며, 직전 실행에서 Pass였던 항목이 Fail로 바뀐 회귀도 확인할 수 있습니다. 단, 이는 전체 통화를 처음부터 다시 거는 검사가 아닙니다. 실제 전화망, 변경된 CRM 상태나 긴 대화에서 누적된 모든 오해까지 그대로 재현하지는 않습니다.
- 제한 실통화에서 업무 결과를 바꾼 턴을 찾습니다. 발신 조직이나 목적을 밝히지 않은 시작, 잘못 알아들은 이름, 금지된 약속, 틀린 도구 호출, 수신 거부 뒤 추가 설득, 사람 요청을 무시하거나 약속한 콜백 절차를 벗어난 응답처럼 구체적인 실패를 고르세요.
- 그 턴을 Validation example로 저장합니다. 기대 행동과 허용할 응답·도구 호출을 운영자가 구체화하고 Active 상태로 만듭니다. 수신 거부 사례라면 사과, 즉시 종료, 연결된 기록 도구 호출을 판정 항목으로 적되 도구가 없는 운영에서는 Call History 이후의 수동 목록 반영을 별도로 확인해야 합니다.
- 프롬프트를 수정한 뒤 예제 상태를 다시 확인합니다. 프롬프트 변경으로 해당 예제가 Stale 상태가 됐다면 기대 행동과 허용할 응답·도구 호출이 여전히 맞는지 검토하고 다시 Active로 전환하세요. 전체 Validation run에는 Active example만 포함되므로 이 확인을 건너뛰면 방금 저장한 실패 사례가 실행에서 빠질 수 있습니다.
- 현재 초안에서 Validation run을 실행합니다. 새 실패가 Pass로 바뀌었는지뿐 아니라 발신자 식별, 기존 수신 거부 처리와 다른 성공 사례가 Fail로 돌아가지 않았는지도 확인하세요. 개별 예제를 먼저 초안에 재생할 수 있지만 전체 통과율과 회귀 확인에 포함하려면 Active 상태여야 합니다.
- 내부 배포 중단 기준을 적용합니다. 예를 들어 필수 사례의 Fail이나 기존 Pass의 회귀가 하나라도 있으면 배포를 멈출 수 있습니다. 이는 제품의 기본값이 아니라 조직이 정할 기준입니다. ThunderPhone에서는 실패를 검토한 뒤에도 의도적으로 배포할 수 있습니다.
자동 성공률은 실제 업무 결과와 대조하세요
Observability의 Success Rate는 AI 채점에 기반하며 인프라 오류는 분모에서 제외됩니다. 통화량이 많은 기간의 상세 지표는 최근 통화 표본으로 계산될 수도 있습니다. 따라서 이 수치를 CRM의 예약 완료율이나 리드 검증률과 같은 숫자로 읽으면 안 됩니다.
자동 점수 옆에 운영자가 확인한 발신자 식별, 이름·참석 여부, 실제 CRM 반영, 콜백 절차 준수, 수신 거부 목록 반영, 재통화와 잘못된 도구 실행을 기록하세요. 자동 평가와 사람 판정이 어긋난 통화는 에이전트 프롬프트만 고치기 전에 평가 기준이 모호하지 않은지도 살펴봐야 합니다.
ThunderPhone 평가의 가장 작은 완성 단위는 에이전트 하나를 배포하는 것이 아닙니다. 초안을 시뮬레이션하고, 검증된 보유 번호로 제한 캠페인을 실행하고, 수신 거부 요청을 다음 발신 대상에서 제외한 뒤, 발견한 실패 턴을 Validation example로 저장하는 데까지 이어져야 합니다. 프롬프트를 수정했다면 예제의 Stale 여부와 기대 행동을 다시 검토해 Active로 전환하고, 수정 초안의 전체 Validation run에서 필수 사례와 기존 성공 사례가 내부 기준을 모두 통과해야 다음 배포로 넘어갈 수 있습니다. 분당 가격은 그 사이클의 비용 중 하나일 뿐이에요.
