환자가 병원에 전화해 말합니다.

“다음 주 예약을 취소하고 새로 잡아주세요.”

사람에게는 비교적 평범한 요청이지만 AI 상담원이 처리하려면 여러 판단이 필요합니다. 먼저 기존 예약을 찾아야 하고, 어떤 예약을 취소할지 확인해야 하며, 환자의 최종 동의를 받은 뒤 취소해야 합니다. 그다음에야 새로운 예약 절차를 시작할 수 있습니다.

이 과정에서 AI는 다양한 실수를 할 수 있습니다.

• 예약 취소가 아니라 신규 예약부터 시작할 수 있습니다.
• 환자에게 어떤 예약인지 확인하지 않고 취소를 시도할 수 있습니다.
• 취소에 동의했는지 같은 질문을 두 번 반복할 수 있습니다.
• 예약 시스템에서 오류가 발생했는데도 처리가 끝났다고 말할 수 있습니다.
• 대화 중간에 환자가 말을 바꾸었는데 이전 조건으로 예약을 진행할 수 있습니다.

몇 차례 시연이 성공했다는 사실만으로는 이런 문제를 발견하기 어렵습니다. 특히 Voice AI는 LLM의 판단뿐 아니라 음성 인식, 발화 타이밍, 외부 업무 시스템, 전화망까지 함께 움직입니다.

그렇다면 실제 환자의 전화를 받기 전에 무엇을, 어디까지 테스트해야 할까요?

이 글에서는 와이즈에이아이 인바운드 에이전트를 검증하는 방식을 바탕으로, 병원 Voice AI 테스트를 네 단계로 나누어 살펴보겠습니다.

---

1. 자연스럽게 말하는 것과 안전하게 일하는 것은 다르다

일반적인 챗봇 데모에서는 질문에 자연스럽게 답하는지가 가장 먼저 눈에 들어옵니다. 하지만 병원 Voice AI는 대화만 하는 것이 아니라 실제 업무를 수행합니다.

예약을 조회하고, 새로운 예약을 접수하고, 기존 예약을 변경하거나 취소하며, 필요하면 사람 상담원에게 전화를 연결합니다. 자연스러운 문장 뒤에서 잘못된 Tool이 한 번 호출되면 실제 환자의 일정이나 병원의 업무 흐름에 영향을 줄 수 있습니다.

따라서 테스트의 질문도 달라져야 합니다.

Voice AI의 품질은 말투만으로 판단할 수 없습니다. 대화의 의미, 업무 행동, 외부 시스템의 결과, 실제 음성 환경을 함께 검증해야 합니다.

---

2. 테스트 코드를 만들기 전에 시나리오부터 정의한다

“예약 기능을 테스트한다”라는 목표는 너무 넓습니다. 신규 예약, 예약 조회, 변경, 취소, 본인 확인, 일정 선택, 최종 확인까지 한꺼번에 검사하려 하면 무엇이 실패했는지 알기 어렵습니다.

먼저 하나의 환자 상황과 하나의 핵심 판단을 시나리오 계약으로 정의하는 것이 좋습니다.

여기서 중요한 것은 성공 조건만 적지 않는 것입니다.

“예약 변경 Tool을 호출한다”와 “신규 예약·취소 Tool은 호출하지 않는다”를 함께 검증해야 한다.

LLM은 예상한 행동을 했더라도 동시에 불필요한 다른 Tool을 호출할 수 있습니다. 환자의 데이터가 바뀌는 업무에서는 무엇을 했는가만큼 무엇을 하지 않았는가도 중요합니다.

---

3. 가장 작은 테스트로 먼저 증명한다

AI 상담원의 모든 기능을 실제 전화로만 테스트하면 느리고 비쌉니다. 반대로 모든 것을 텍스트 테스트로 확인하면 음성 환경에서만 나타나는 문제를 놓치게 됩니다.

와이즈에이아이 인바운드 에이전트에서는 검증하려는 대상에 따라 테스트를 네 계층으로 나눕니다.

위로 올라갈수록 실제 통화와 가까워지지만 실행 시간, 비용, 원인 분석의 어려움도 커집니다. 따라서 가장 실제적인 테스트부터 시작하는 것이 아니라, 문제를 증명할 수 있는 가장 작은 계층부터 시작하는 것이 효율적입니다.

LiveKit 역시 구체적인 메시지와 Tool 호출은 테스트 프레임워크로 검증하고, 여러 턴에 걸친 행동은 시뮬레이션으로 확인하는 방식을 안내합니다. 텍스트 기반 검증은 실제 LiveKit Room을 만들지 않고 실행할 수 있습니다. 자세한 구조는 LiveKit Testing and Evaluation 공식 문서에서 확인할 수 있습니다.

---

4. 1단계: 정답이 있는 로직은 단위 테스트로 검증한다

LLM을 사용한다고 해서 모든 테스트에 LLM이 필요한 것은 아닙니다.

다음과 같은 동작은 입력과 기대 결과가 명확합니다.

• “오후 두 시”를 14:00으로 변환하는 로직
• 예약 가능한 날짜 범위를 검사하는 규칙
• 진료과와 담당자 식별자를 연결하는 처리
• 동일한 예약 요청이 중복 실행되지 않도록 막는 상태
• 사용자 확인 전에는 예약을 확정할 수 없도록 하는 조건
• API의 빈 응답과 오류 응답을 구분하는 처리

이런 로직을 LLM에게 판단하게 하면 테스트가 느려지고 결과도 흔들릴 수 있습니다. 정답을 코드로 명확하게 증명할 수 있다면 일반적인 pytest 단위 테스트가 더 적합합니다.

단위 테스트는 대화의 자연스러움을 검증하지는 못하지만, AI가 의존하는 업무 규칙을 빠르고 반복 가능하게 보호합니다. LLM 모델이나 프롬프트가 바뀌어도 동일한 규칙을 그대로 검사할 수 있다는 장점도 있습니다.

---

5. 2단계: 텍스트 Agent 평가로 AI의 판단을 확인한다

다음 질문에는 하나의 고정된 문장 정답이 없습니다.

“지난번에 잡아 둔 예약을 다른 날로 바꾸고 싶어요.”

AI는 “예약 변경을 도와드리겠습니다”라고 말할 수도 있고, “변경할 예약부터 확인하겠습니다”라고 말할 수도 있습니다. 두 문장은 다르지만 업무 의미는 같습니다.

이 단계에서는 문장 전체를 비교하기보다 다음과 같은 행동을 검사합니다.

• 예약 변경 의도로 분류했는가?
• 기존 예약 조회 또는 변경 Tool을 선택했는가?
• 신규 예약이나 취소 Tool을 잘못 호출하지 않았는가?
• 환자가 말한 조건을 올바른 Tool 인자로 전달했는가?
• 병원 FAQ에 없는 내용을 임의로 만들어내지 않았는가?
• 처리할 수 없는 요청이라면 적절한 대안을 안내했는가?

현재 서비스의 텍스트 평가는 실제 운영 프롬프트와 LLM 구성을 사용합니다. 대신 예약 생성, 예약 취소, 통화 종료, 상담원 전환처럼 외부에 영향을 줄 수 있는 Tool 실행은 테스트용 결과로 대체합니다.

이를 통해 실제와 같은 판단은 관찰하면서 실제 업무 부작용은 막을 수 있습니다.

LiveKit Agents의 AgentSession 테스트 실행과 Tool Mocking도 같은 목적을 가집니다. LLM에는 실제 Tool 구조를 보여주되 실행만 안전하게 가로채는 방식은 LiveKit Test Framework 공식 문서에 설명되어 있습니다.

---

6. 3단계: 환자 시뮬레이션으로 대화 전체를 흔들어 본다

한 문장의 의도 분류가 정확하더라도 여러 턴의 대화에서는 새로운 문제가 생깁니다.

예를 들어 환자가 처음에는 “아무 의사나 괜찮아요”라고 말했다가, 예약을 확정하기 직전에 “잠깐만요. 김 원장님 진료로 바꿀게요”라고 할 수 있습니다. AI는 이전 후보를 그대로 예약하지 않고 새로운 조건으로 일정을 다시 조회해야 합니다.

환자 시뮬레이터는 정해진 답변만 재생하는 스크립트와 다릅니다. 환자 역할과 목표를 가진 시뮬레이터가 AI의 질문을 보고 다음 답변을 생성하면서 대화를 이어갑니다.

와이즈에이아이에서는 다음과 같은 환자 페르소나와 상황을 사용합니다.

• 빠르게 결론을 원하는 성급한 환자
• 질문에 “네”, “아니요”처럼 짧게 답하는 환자
• 희망 날짜와 담당자를 대화 중간에 바꾸는 환자
• 첫 번째 추천 시간을 거절하고 다음 시간을 묻는 환자
• 본인과 가족의 요청을 한 통화에서 함께 말하는 환자
• 병원에 존재하지 않는 진료과나 시술명을 사용하는 환자
• 예약 절차 도중 전체 요청을 취소하는 환자
• AI가 답할 수 없는 정보를 반복해서 묻는 환자

시뮬레이션에서는 단순히 마지막 답변만 확인하지 않습니다.

1. 필요한 정보를 모두 수집했는지 확인합니다.
2. 조건이 바뀌었을 때 이전 후보를 폐기했는지 봅니다.
3. 같은 질문을 불필요하게 반복하지 않았는지 확인합니다.
4. 환자의 명확한 거절을 동의로 해석하지 않았는지 검사합니다.
5. 최종 결과와 종료 이유가 기대한 상태인지 확인합니다.

공식 LiveKit Agent Simulation은 여러 턴의 시나리오를 실행하는 기능을 제공하지만 LiveKit Cloud에서 실행됩니다. 셀프호스팅 환경인 현재 서비스에서는 프로젝트에 맞게 만든 로컬 환자 시뮬레이터로 텍스트·오디오·전화 경로를 검증하고 있습니다. 중요한 것은 특정 도구의 이름보다 다양한 환자 행동이 전체 흐름을 실제로 통과하는가입니다.

---

7. 4단계: 음성과 전화망에서만 발견되는 문제를 검증한다

텍스트 평가와 시뮬레이션이 모두 성공해도 실제 전화에서는 실패할 수 있습니다. 텍스트에는 음성 인식과 발화 타이밍이 없기 때문입니다.

예를 들어 다음 상황은 텍스트 테스트만으로 충분히 확인할 수 없습니다.

• 환자가 “6월 13일”이라고 말했는데 STT가 “6월 30일”로 인식함
• AI가 확인 질문을 말하는 도중 환자가 “네”라고 끼어듦
• 환자가 잠시 생각하느라 침묵했는데 AI가 통화를 종료함
• 인사말 재생 중 누른 DTMF가 다음 단계에 전달되지 않음
• TTS 발화는 끝났지만 전화망에서는 음성이 일부 잘려 들림
• 상담원 전환 중 두 요청이 겹쳐 통화 상태가 꼬임
• 환자가 먼저 전화를 끊었는데 Agent 세션이 남아 있음

현재 프로젝트의 환자 시뮬레이터도 검증 범위에 따라 세 가지 실행 경로를 사용합니다.

모든 테스트를 전화망에서 실행할 필요는 없습니다. 다만 음성이나 전화망에 의존하는 기능을 텍스트 테스트만 통과했다는 이유로 검증이 끝났다고 판단해서도 안 됩니다.

---

8. 테스트 환경에서는 실제 환자와 실제 업무를 분리한다

병원 시스템을 테스트할 때는 기능 정확성만큼 데이터와 부작용 관리가 중요합니다.

테스트 데이터에는 실제 환자의 이름, 전화번호, 차트 번호를 사용하지 않습니다. 특정 상황을 재현할 수 있는 합성 환자와 고정된 예약 데이터를 만듭니다.

또한 테스트 계층에 따라 외부 시스템의 사용 범위를 제한합니다.

• 의도 분류 테스트에서는 예약 API를 호출하지 않습니다.
• 예약 흐름 테스트에서는 조회 결과를 고정된 테스트 데이터로 대체합니다.
• 최종 확인 테스트에서는 실제 예약 생성 요청을 차단합니다.
• 전화 전환 테스트가 아니라면 실제 상담원 번호로 연결하지 않습니다.
• 실제 네트워크가 필요한 검증은 격리된 테스트 환경에서만 수행합니다.

LLM 평가에도 비용과 비결정성이 존재합니다. 같은 시나리오가 모델 호출마다 조금 다르게 진행될 수 있으므로, 모든 단위 테스트와 함께 무조건 실행하기보다 별도의 평가 게이트로 운영할 수 있습니다. 반면 빠르고 결정적인 단위 테스트는 변경할 때마다 반복합니다.

---

9. AI의 답변은 누가 채점해야 할까?

평가 방법은 크게 세 가지로 나눌 수 있습니다.

코드가 직접 확인하는 결정적 검증

• 특정 Tool이 호출되었는가?
• 필수 인자가 정확히 전달되었는가?
• 금지된 Tool이 호출되지 않았는가?
• 예약 확정 전에 확인 상태를 통과했는가?
• Task가 기대한 결과로 종료되었는가?

LLM Judge가 의미를 판단하는 평가

• 환자에게 오류 상황을 이해하기 쉽게 설명했는가?
• 확인되지 않은 병원 정보를 만들어내지 않았는가?
• 위험하거나 부적절한 의료 조언을 하지 않았는가?
• 업무를 완료하지 못했을 때 적절한 대안을 안내했는가?

사람이 직접 듣고 확인하는 평가

• 음성이 자연스럽고 명확한가?
• 환자가 끼어든 뒤 응답 타이밍이 어색하지 않은가?
• 반복 질문이 불쾌하게 느껴지지 않는가?
• 전화 전환 과정에서 환자가 방치되었다고 느끼지 않는가?

LLM Judge는 문장이 정확히 일치하지 않아도 의미를 평가할 수 있다는 장점이 있습니다. 하지만 Judge도 또 하나의 LLM이므로 절대적인 정답 판정기로 취급해서는 안 됩니다.

가장 좋은 원칙은 단순합니다.

코드로 증명할 수 있는 것은 코드로 검사하고, 의미가 필요한 부분에만 LLM Judge를 사용한다.

---

10. 실제 통화에서 발견한 문제를 테스트 자산으로 바꾼다

출시 전 테스트만으로 모든 환자 행동을 예측할 수는 없습니다. 실제 서비스에서는 기획 단계에서 생각하지 못했던 표현과 상황이 계속 나타납니다.

중요한 것은 운영 중 발생한 문제를 한 번 수정하고 끝내지 않는 것입니다.

와이즈에이아이에서는 실제 통화에서 발견한 문제를 개인정보 없이 재구성해 새로운 평가 시나리오로 만들 수 있습니다. 예를 들어 예약을 하나만 가진 환자에게 동일한 확인 질문을 두 번 했던 문제가 발견되었다면 다음 조건을 검증합니다.

• 환자가 한 번 “네”라고 답하면 선택이 완료되어야 합니다.
• 같은 예약 내용을 다시 확인해서는 안 됩니다.
• 모호한 답변을 동의로 처리해서는 안 됩니다.
• 명시적으로 거절하면 예약을 확정해서는 안 됩니다.

수정 전에는 이 시나리오가 실패하고, 수정 후에는 성공해야 합니다. 이후 프롬프트나 모델을 바꾸더라도 같은 테스트를 다시 실행합니다.

이 과정이 반복되면 실제 통화의 실패는 단순한 장애 기록이 아니라, 같은 문제가 다시 발생하지 않도록 막는 회귀 테스트 자산이 됩니다.

---

11. 출시 전 확인해야 할 체크리스트

마지막으로 병원 Voice AI를 출시하거나 모델·프롬프트를 변경하기 전에 확인할 항목을 정리해 보겠습니다.

업무 판단

• 주요 환자 의도를 올바르게 구분하는가?
• 필요한 Tool과 올바른 인자를 선택하는가?
• 동시에 호출하면 안 되는 Tool을 함께 호출하지 않는가?
• 처리할 수 없는 요청을 억지로 수행하지 않는가?

안전과 Grounding

• 병원에서 제공하지 않은 정보를 추측하지 않는가?
• 의료적 판단이나 처방을 제공하지 않는가?
• 예약 변경·취소·확정 전에 환자 확인을 받는가?
• 실패를 성공한 것처럼 안내하지 않는가?

대화 흐름

• 같은 질문을 불필요하게 반복하지 않는가?
• 환자가 조건을 바꾸면 이전 선택을 안전하게 폐기하는가?
• 명확한 거절과 모호한 답변을 구분하는가?
• 업무를 중단하려는 요청을 존중하는가?

음성과 전화 환경

• 날짜, 시간, 숫자가 안정적으로 인식되는가?
• 환자의 끼어들기 이후에도 문맥이 유지되는가?
• 침묵과 지연을 통화 종료로 성급하게 판단하지 않는가?
• DTMF, SIP 연결, 상담원 전환이 실제 환경에서 동작하는가?
• 환자가 먼저 전화를 끊어도 세션이 정상적으로 정리되는가?

운영과 회귀

• 실제 환자 정보 없이 테스트할 수 있는가?
• 외부 업무의 부작용이 격리되어 있는가?
• 과거에 수정한 문제가 다시 발생하지 않는가?
• 모델이나 프롬프트 변경 전후 결과를 비교했는가?

---

마치며

안정적인 AI 상담원을 만드는 방법은 완벽한 프롬프트 하나를 찾는 것이 아닙니다.

규칙은 단위 테스트로 빠르게 보호하고, LLM의 판단은 텍스트 평가로 확인하며, 여러 턴의 대화는 환자 시뮬레이션으로 흔들어 보고, 마지막에는 실제 음성과 전화망에서 검증해야 합니다.

그리고 운영 중 새로운 문제가 발견될 때마다 그 상황을 다시 실행할 수 있는 테스트로 남겨야 합니다.

좋은 Voice AI는 한 번도 실패하지 않는 AI가 아니라, 발견한 실패를 다시 반복하지 않도록 학습하는 서비스다.

AI 상담원의 신뢰성은 모델 이름보다 얼마나 현실적인 테스트 시나리오를 꾸준히 축적했는가에서 만들어집니다.