본문으로 건너뛰기
BringTalk
설계

보이스 에이전트가 자신 없는 답을 걸러내는 법

모델이 틀린 줄 모르고 말하는 것이 가장 위험하다. 저신뢰 응답을 세 겹으로 걸러내는 실무 설계를 공유한다.

Moon Kim3분 읽기

모델이 틀린 답을 자신 있게 말하는 것보다 더 나쁜 상황이 하나 있습니다. 틀린 줄 모르고 말하는 것입니다.

신뢰도를 왜 별도로 추정해야 하나

딥러닝 분류 모델은 틀린 답에도 높은 확신을 붙이는 경향이 있습니다. 2026년 8월 arXiv(논문 사전 공개 사이트)에 올라온 TCP_α 논문은 이 문제를 다룹니다. 이미 학습을 마친 분류 모델은 그대로 두고, 그 위에 "이 답이 맞을 가능성"만 따로 맞히는 가벼운 보조 장치를 학습시키는 방식입니다. 음악 정보 검색 과제에서 이 보조 장치가 가장 자신 없다고 판단한 8%를 걸러내자 기본 모델의 정확도 지표(macro-F1)가 0.89에서 0.98로 올랐다고 보고합니다.

음악 분류와 상담 통화는 다른 과제입니다. 그래도 "답을 만드는 장치"와 "그 답을 믿어도 되는지 판단하는 장치"를 나눠야 한다는 생각은 그대로 가져올 수 있습니다. 실시간 통화에서 LLM(대규모 언어 모델)이 고객 질문에 답할 때도, 모델이 내놓는 확신만 믿고 답을 내보내면 같은 약점이 생깁니다.

콜 환경에서 저신뢰 응답이 위험한 이유

텍스트 인터페이스에서는 사용자가 모호한 답변을 읽고 다시 질문할 수 있습니다. 음성 통화에서는 그 기회가 없습니다. 상담사가 자신 없는 답변을 자신 있는 톤으로 전달하면, 고객은 틀린 정보를 사실로 받아들인 채 통화를 끊습니다.

그래서 저희가 상담용 보이스 에이전트를 설계할 때 가장 먼저 정하는 것도 이 지점입니다. 에이전트가 어떤 조건에서 스스로 멈춰야 하는가.

실제로 설계한 저신뢰 응답 자동중단 구조

세 개의 레이어로 답을 걸러냅니다.

1. 응답 생성 전: 의도 분류 신뢰도 체크

고객 발화가 들어오면 에이전트는 먼저 의도를 분류합니다. 이때 분류 신뢰도가 임계값 아래로 내려가면 응답을 생성하지 않습니다. 대신 명확화 질문을 먼저 던집니다. "죄송합니다, 말씀하신 내용을 다시 한번 확인해도 될까요?"

2. 응답 생성 후: 루브릭 기반 자가검증

에이전트가 답변 초안을 만든 뒤, 해당 답변이 허용된 정보 범위 안에 있는지 루브릭(항목별 채점 기준표) 체크리스트를 통과시킵니다. 체크리스트는 보장 범위, 예외 조건, 금지 발화 패턴을 항목별로 구조화해두었습니다. 한 항목이라도 실패하면 에이전트는 해당 응답을 폐기하고 에스컬레이션 스크립트로 전환합니다.

3. 치명적 오류(Critical Failure) 자동중단

두 레이어를 통과했더라도 부정확한 법적 조건, 허위 보장 약속, 확인되지 않은 가격 정보 같은 특정 패턴이 감지되면 통화를 즉시 사람 상담사에게 넘깁니다. 이 단계는 상황을 봐 가며 넘기는 단계가 아니라, 걸리면 무조건 멈추는 하드스톱입니다.

저신뢰 응답을 거르는 세 겹: 응답 생성 전 신뢰도 체크, 생성 후 루브릭 검증, 발화 직전 하드스톱
저신뢰 응답을 거르는 세 겹: 응답 생성 전 신뢰도 체크, 생성 후 루브릭 검증, 발화 직전 하드스톱

세 층은 서로 다른 신호를 봅니다. 어느 층에서 걸리든 그 답은 고객에게 발화되지 않습니다. 본문에서 설명한 설계 구조이며 측정치가 아닙니다.

이 방법이 통하지 않는 경우

세 겹을 다 쌓아도 새는 자리가 있습니다. 가장 흔한 건 의도가 하나로 떨어지지 않는 발화입니다. 고객이 한 문장에 두 가지를 섞어 물으면 분류기는 그중 하나를 높은 신뢰도로 골라내고, 그 하나에 대한 답은 루브릭도 무사히 통과합니다. 신뢰도 체크는 "모르겠다"는 신호에만 반응합니다. 절반만 알아들은 상태는 애초에 그 신호를 만들지 않습니다.

루브릭에도 같은 성질의 빈틈이 있습니다. 체크리스트는 허용된 범위를 항목으로 적어 둔 물건이라, 목록에 아예 없는 주제가 들어오면 걸릴 항목 자체가 없습니다. 규칙이 침묵하면 답은 그냥 나갑니다. 그래서 저희는 새로운 문의 유형이 관측되면 루브릭에 항목을 먼저 넣고, 들어가기 전까지는 그 유형을 통째로 사람에게 넘깁니다.

마지막은 운영 시간 문제입니다. 하드스톱은 넘겨받을 사람이 있다는 전제 위에서만 안전장치로 작동합니다. 야간이나 주말처럼 대기 중인 상담사가 없는 시간대에는 같은 하드스톱이 통화 종료로 끝나버립니다. 이 구조를 검토하신다면 에스컬레이션을 받을 사람의 근무 시간부터 확인해 보시길 권합니다. 콜백 예약 같은 대체 경로가 붙어 있어야 제 몫을 합니다.

설계할 때 선택해야 하는 것

이 구조를 실제로 만들 때 팀이 가장 많이 논쟁한 지점은 "임계값을 어디에 설정할 것인가"였습니다. 너무 낮으면 에이전트가 너무 많은 질문에 스스로 멈추고, 너무 높으면 저신뢰 응답이 그냥 나가버립니다.

저희가 내린 결론은 임계값을 하나의 수치로 고정하지 말자는 것이었습니다. 의도 유형별로, 리스크 수준별로 임계값을 달리 설정했습니다. 보장 내용에 관한 질문은 엄격하게, 일반 안내에 관한 질문은 느슨하게.

상담 업무를 밖으로 넘기는 경우라면 계약서에서 확인할 것들을 콜센터 아웃소싱 계약 전 체크리스트에 따로 정리해 두었습니다.

저신뢰 응답을 걸러낸다고 에이전트가 약해지지는 않습니다. 말해도 되는 것만 말하게 될 뿐입니다.

이 글 공유하기
우리 콜에서는?

같은 전환을 한국어 콜 운영에서, 6주 안에 숫자로 확인하세요.