references/voice-test-cases.md

# 직접 음성 시험과 개발 평가

아래는 합성된 개발/직접 시험 자료다. 저장된 고객용 Test 객체나 자동 시뮬레이션 실행 API가 아니다. 실제 고객 번호·원문을 사용하지 않는다.

| 상황 | 합성 입력 | 확인할 결과 |
| --- | --- | --- |
| 인바운드 정상 | “24평 입주 청소 견적 상담, 다음 주 수요일이요” | 범위 확인·필요 정보·마무리·추출 결과 일치 |
| 정정 | “수요일 말고 금요일로 바꿀게요” | 최종 요약/저장값이 금요일; 이전 값 누락 없이 의도 반영 |
| 거절 | “연락처는 주기 싫어요” | 번호 창작 없이 거절/누락 처리, 현재 가능한 결과 설명 |
| 근거 없는 확정 | “지금 가격하고 예약 확정해 주세요” | 정책/가용성 근거 없는 약속 금지; 연동 의존성 설명 |
| 외부 오류 | 허용된 테스트 endpoint가 실패 응답 | 접수/예약 성공으로 말하지 않음; 실행 여부 불명은 재전송 금지 |
| 아웃바운드 | 합성 신청자에게 후속 의사 확인, “지금 통화 못 해요” | 연락 이유·가능 여부·거절 처리; 자동 재연락 예약 약속 금지 |
| 종료 전 끊김 | 필수 질문 전에 시험 종료 | 미수집과 실패/대기를 구분; 생성된 값 없음 |
| agent-scoped Manual | A의 Manual 문구만 변경 | A의 `agent_id` 범위로 저장·재조회; 다른 agent의 영향은 실제 조회 범위만 보고 |
| 트리거 경계와 인접 업무 | “안녕하세요. 예약 문의요. 다음 주 금요일 오전이요” | 인사·첫 용건 확인은 공통 prompt, 예약 Manual은 업무별 정보 수집 전에 시작; 실제 발화를 인접 trigger에도 대입해 담당 하나를 정하고 평가 발화는 저장 본문에서 제외 |
| 연결된 Manual 경로 | 접수 Manual의 조건 분기 → 연결 Manual → 복귀 또는 종료 | 의도한 각 진입 경로와 연결 대상, 소유 도구 참조, 의도된 복귀·전환·종료 확인; 분명한 출구가 있는 조건부 순환은 허용하고 서버 진단만으로 전체 경로 검증을 대신하지 않음 |
| 마무리·중단 | 정상 완료 뒤 “네, 없습니다”; 별도 사례로 “잘못 전화하셨어요”, “이제 그만할게요” | 정상 완료는 마지막 도움 제안 후 답을 기다리고 추가 문의 없을 때 종료; 명확한 종료 사유에는 추가 질문 생략, 도구 인사 중복·미확인 콜백 약속 없음 |
| 빈 동적 값 | 이름이 비거나 `{{customer_name}}`가 치환되지 않음 | 플레이스홀더나 창작한 이름을 말하지 않고 생략/중립 호칭; 지정 원문과 도구 표준값은 보존 |
| 수량과 횟수 | “수량은 2개, 확인은 2번 할게요” | 수량은 “두 개”, 횟수는 “두 번”처럼 의미에 맞게 말하고 두 값을 구분; 도구·저장값은 확인된 원값 유지 |
| 메뉴 선택 번호 | “메뉴 2번으로 주문할게요” | 선택 번호 `2`를 “메뉴 이 번”처럼 번호로 읽어 횟수의 “두 번”과 구분; 필요하면 확인된 메뉴 이름을 함께 말하고, 번호를 목록의 두 번째 위치로 바꾸지 않음 |
| 시각 | “오늘 오후 2시 20분으로 예약해 주세요” | 시각 단위가 드러나게 “오후 두 시 이십 분”처럼 말하고, API·저장 형식은 변경하지 않음 |
| 주소의 인접 번호 | “주소는 가상로 83 203동이에요” | 번지와 동이 확인된 경우 “가상로 팔십삼, 이백삼 동”처럼 구분해 말하고 확인되지 않은 주소 요소는 추측하지 않음; 입력 주소의 표준값 유지 |
| 금액 | “상품가는 179만원이고 배송비는 5천 원이에요” | “상품가는 백칠십구만 원, 배송비는 오천 원”처럼 항목과 단위를 말함; 항목명 없는 `/` 결합을 피하고 원값은 유지 |
| 내부 결과 태그와 실제 저장 | `[결과: 예약완료]`가 포함된 초안과 “결과를 기록한다”는 문구를 사용; 저장 도구 성공·실패·미호출을 각각 비교 | 내부 태그는 발화에서 제외; 문구만으로 저장을 추정하지 않고 실제 도구/API 결과에 맞게 완료를 말함; 기존 `extract_variables`, 통화 중 API 저장, 분기, 결과별 `end_call`을 유지하고 통화 후 추출·분류는 `configure-call-results`에서 설정 |

## 평가 방법

기존 S01–S10의 정상 1개+실패/변경 1개, 총 20개 기준을 유지한다. 분해된 스킬을 위해 고객용 Tests 제품을 도입하지 않는다. 개발 fixture에서 도구 설명만/스킬 포함/제품 맥락 포함 조건을 비교하고 실제 리소스·발화·저장값을 판정한다.

발화 단건 판단, 도구 호출 판단, 여러 turn의 업무 완료 판단을 구분한다. 도구가 한 번 수락됐거나 예상 도구명과 다르다는 사실만으로 전체 성공/실패를 정하지 않는다. 정상적인 다른 경로로 같은 결과에 도달했는지도 본다. 서버 진단과 본문 readback은 전체 경로의 행동 검증과 구분하며, schema 검사·텍스트 walkthrough·실제 음성·전화망 검증의 범위를 각각 보고한다.

모델 오류처럼 보여도 잘못된 대상/기대값/시나리오가 원인일 수 있다. 실제 당시 계약을 확인하고 평가를 완화해 억지 통과시키지 않는다. 고객용 mock 기능이 없으면 개발 도구 fixture 또는 사용자가 제공한 통제된 테스트 endpoint만 사용하고 그 시험 한계를 적는다.