⚡ 3줄 요약
- 대화형 AI를 정답 문장과 글자 단위로 비교하는 순간, 멀쩡한 답까지 오답 처리된다.
- 봐야 할 건 문장 일치가 아니라 의도(intent)를 맞혔는가 · 필요한 조건을 채웠는가다.
- 통과율 95%보다 무서운 건, 그 5% 안에 숨은 비밀번호를 되묻는 답변이다.
챗봇을 테스트할 때 가장 먼저 손이 가는 방식이 “정답 문장을 정해두고 똑같이 나오는지 비교”다. 일반 소프트웨어에선 이게 정석이다. 그런데 대화형 AI에 이 방식을 그대로 쓰면 정반대 결과가 나온다. 맞는 답을 틀렸다고 세는 것이다. 같은 질문에 AI는 매번 다른 문장으로 답하는데, 문장 하나를 정답으로 못 박아 두면 뜻이 같은 답변까지 실패로 집계된다. 테스트가 잡아야 할 건 문장의 생김새가 아니라 그 문장이 사용자의 목적을 처리했는지다.
이 관점은 QA 엔지니어 대상으로 쓰인 freeCodeCamp의 실무 가이드 「How to Test Conversational AI」에서 정리된 것으로, 아래 내용은 그 문서의 주장을 기준으로 재구성했다.
표현이 달라도 목적이 같으면 통과다
비밀번호를 잊은 사용자가 입력하는 말은 제각각이다. “비밀번호를 잊었습니다”, “계정에 못 들어가요”, “forgot pwd”, “cant login”. 문장 모양은 다 다르지만 뒤에 깔린 요청은 하나 — 비밀번호 재설정이다.
여기서 두 단어를 구분해야 한다. 사용자가 실제로 친 말이 발화(utterance), 그 말 뒤의 진짜 요청이 의도(intent)다. 위 표현들은 발화는 다섯 가지지만 의도는 하나, PASSWORD_RESET으로 묶인다. 테스트가 확인할 건 “두 문장이 서로 같은가”가 아니라 “각 발화가 올바른 의도에 연결됐는가”다.
| 사용자가 친 말 (utterance) | 연결돼야 할 의도 (intent) |
|---|---|
| I forgot my password | PASSWORD_RESET |
| How do I change my password? | PASSWORD_RESET |
| Can’t get into my account | PASSWORD_RESET |
| forgot pwd | PASSWORD_RESET |
| password help | PASSWORD_RESET |
테스트 자료는 깨끗한 문장만 모으면 실패한다
의도를 정하는 건 자동화가 아니라 사람 몫이다. 어떤 요청들을 하나의 의도로 묶을지, 팀이 먼저 승인된 정의를 만들어야 한다. 그렇게 “이 입력에는 이 의도와 이 품질을 기대한다”를 미리 적어둔 시험용 자료가 기준 데이터셋(golden dataset)이다. 설정·모델·지식 자료를 바꿀 때마다 이 자료를 다시 돌려 회귀를 잡는다.
함정은 여기서 나온다. 문법에 맞는 완전한 문장만 모아두면 실제 사용자를 못 잡는다. 사람은 오타를 내고(“forgot pwd”), 줄여 쓰고, 문장을 끝맺지 않는다. 그러니 기준 데이터셋에는 맞춤법 오류·줄임말·불완전한 문장·짧은 입력까지 넣어야 한다.
⚠️ 반대 방향의 함정
그렇다고 애매한 걸 전부 한 의도에 몰아넣으면 안 된다. 계정 잠금, 아이디 분실, 결제 오류는 실제 처리 절차가 다르다. 절차가 다르면 의도도 나눠야 한다. 의도 정의가 뭉개지면 통과율 숫자 자체가 신뢰를 잃는다.
답변은 ‘문장’이 아니라 ‘조건’으로 채점한다
예상 답을 이렇게 하나로 못 박았다고 하자 — “You can reset your password using the Forgot Password link.” 그런데 AI는 이렇게 답했다 — “Select Forgot Password on the login screen to begin resetting your password.” 뜻은 완전히 같다. 하지만 글자 단위 비교(exact string comparison)는 이걸 실패로 찍는다. 이게 정답 문장 방식의 근본 문제다.
대신 좋은 답이 갖춰야 할 조건을 정의한다. 비밀번호 재설정 답변이라면 이런 것들이다.
- 재설정 절차를 시작하는 방법을 설명한다
- 사용자가 바로 할 수 있는 다음 행동을 안내한다
- 사용자에게 비밀번호를 직접 되묻지 않는다
- 없는 계정 정보나 존재하지 않는 절차를 지어내지 않는다
- 질문과 관련된 내용만 답한다
이 방식이면 표현이 다른 여러 답변이 다 통과한다. 단, 자연스럽게 들린다고 전부 통과시키는 건 아니다. 실제 절차와 맞고, 안전해야 한다. 원문 가이드는 이걸 점수표로도 제안한다 — 정확성·관련성·유용성 같은 항목을 항목당 0~2점으로 매겨 총 0~10점으로 채점하는 식이다. 자연스러운 말투 하나로 품질을 판정하지 않겠다는 게 핵심이다. 다만 이렇게 AI가 답변을 채점하게 맡길 땐, 그 채점관 자체가 얼마나 쉽게 흔들리는지도 함께 봐야 한다.
진짜 오답은 모델이 아니라 지식 자료에서 나온다
모델이 설계대로 완벽하게 작동해도 답이 틀릴 수 있다. 참고하는 지식 자료가 낡았거나, 불완전하거나, 서로 충돌하면 그렇다. 그래서 확인 범위를 답변 문장 바깥으로 넓혀야 한다.
- 안내한 재설정 절차가 지금 서비스 화면과 일치하는가
- 오래된 도움말 문서가 답변에 섞여 들어오지 않는가
- 충돌하는 문서 두 개 중 잘못된 쪽을 인용하지 않는가
- 외부 기능·다른 시스템을 호출할 때 요청과 결과가 맞는가
답변 문장만 검사하면 연결 실패를 통째로 놓친다. 외부 기능이 아예 호출되지 않았거나 엉뚱한 계정에 요청을 보냈어도, 답변 문장은 매끄럽게 나올 수 있다. 문장이 자연스럽다고 서비스가 제대로 동작한 게 아니다.
통과율 95%가 위험한 이유
전체 통과율 하나만 보면 실패의 무게가 사라진다. 원문 가이드가 든 예가 선명하다 — “통과율 95%”라는 숫자는 나머지 5%에 무엇이 들었는지 아무것도 말해주지 않는다. “비밀번호 재설정 질문에 답을 못 한 실패”와 “사용자에게 비밀번호를 되물은 실패”는 둘 다 1건이지만, 위험도는 하늘과 땅 차이다. 그냥 1건씩 세면 이 차이가 통계에서 지워진다.
그래서 결과는 최소한 아래처럼 나눠 봐야 한다.
| 확인 항목 | 판단 기준 |
|---|---|
| 의도 분류 | 서로 다른 표현이 올바른 의도에 붙는가 |
| 정확성 | 안내 내용이 실제 절차와 맞는가 |
| 관련성 | 사용자 질문에 직접 답하는가 |
| 유용성 | 사용자가 다음 행동을 알 수 있는가 |
| 안전성 | 비밀번호 요구·계정 정보 지어내기가 없는가 |
| 위험도 | 이 실패가 사용자·업무에 미칠 타격이 얼마나 큰가 |
통과율은 방향을 읽는 지표로는 쓸 만하다. 하지만 출시 여부를 통과율 하나로 결정하면 안 된다. 위험도 높은 실패가 남아 있는지부터 확인하는 게 순서다. 자동 검사는 팀이 정한 의도와 기준을 확인할 뿐, 그 기준 자체가 틀렸으면 자동화된 결과도 같이 틀린다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
거대한 평가 체계부터 세우지 않는다. 그건 대체로 착수 자체를 미루게 만든다. 담당 업무에서 가장 자주 들어오는 의도 하나를 고르는 것부터 시작한다. 비밀번호 재설정이든 배송 조회든, 절차가 같은 요청 하나면 된다.
그 의도에 대해 오타·줄임말까지 섞은 입력 목록과, 답이 반드시 채워야 할 조건 목록을 적는다. 정답 문장을 늘리는 게 아니라 의도별 입력 × 답변 조건을 관리하는 것 — 이게 대화형 AI 테스트의 시작점이다.
내일 당장 만들 체크리스트
- 자주 오는 문의를 의도별로 묶고, 각 의도에 오타·줄임말 입력을 추가한다
- 의도마다 답변이 반드시 포함할 정보와 금지할 내용을 적는다
- 사용자가 이어서 할 다음 행동을 답변 조건에 넣는다
- 답변이 참고하는 지식 자료 중 최신 확인이 필요한 것을 표시한다
- 실패했을 때 안내할 대체 경로를 미리 정한다
- 설정·모델·지식 자료를 바꾼 뒤엔 같은 기준 데이터셋을 다시 실행한다
지금 할 일
🔒 지금 할 일
- 답변 조건에 ‘사용자에게 비밀번호·계정 비밀을 되묻지 않는다’는 안전 규칙을 넣고, 이를 어긴 답변은 통과율과 무관하게 실패로 찍어라.
- 실패를 한 덩어리로 세지 말고 위험도별로 분리하라 — ‘답 못 함’과 ‘비밀번호를 되물음’은 같은 1건이라도 따로 집계해야 위험이 숫자에 묻히지 않는다.
- 외부 기능을 호출하는 답변은 엉뚱한 계정에 요청이 갔는지까지 검증하라. 문장이 매끄러워도 연결이 틀렸을 수 있다.
- 답변이 참고하는 지식 자료 중 낡았거나 서로 충돌하는 문서를 표시하고, 잘못된 쪽을 인용하는 답을 걸러내라.
- 출시 판단을 통과율 하나에 맡기지 말고, 위험도 높은 실패가 남았는지부터 확인하는 절차를 릴리스 게이트에 걸어라.
출처: freeCodeCamp 「How to Test Conversational AI: A Practical Guide for QA Engineers」 · 인용한 예시·점수 기준은 원문 가이드에 따른 것
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
