🧑🏻💻 Ep.25 | AI 품질을 테스트한다는 것
배송일 변경 AI의 프롬프트를 다듬은 뒤 답변 스무 개를 다시 읽었습니다. 전보다 훨씬 친절했어요. 딱딱했던 문장이 부드러워졌고, 필요한 버튼도 잘 알려줬습니다.
그런데 한 답변이 눈에 걸렸습니다. 이미 출고된 주문에 “변경이 완료됐어요”라고 말하고 있었거든요. 이전 버전은 말투가 투박했지만 적어도 그 주문을 상담원에게 넘겼습니다.
무엇이 더 좋아진 걸까요. 열아홉 문장의 말투가 좋아진 것과, 한 번의 잘못된 약속을 맞바꿔도 될까요?
AI 품질은 좋은 답의 개수가 아니라, 어떤 실패를 얼마나 허용할지 정하는 일에서 시작합니다.
※ 이 글의 장면과 수치는 여러 운영 패턴을 합성한 가상 사례입니다.
1. 테스트가 있는데도 판단이 어려운 이유
일반적인 함수라면
PENDING 상태를 넣었을 때 CHANGEABLE이 나오는지 확인할 수 있습니다. 결과가 다르면 실패입니다.
AI의 문장은 조금 다릅니다. “변경할 수 없습니다”와 “출고가 시작되어 지금은 날짜를 바꾸기 어려워요”는 표현이 달라도 같은 뜻일 수 있습니다. 반대로 문장은 자연스러운데 주문 상태를 반대로 읽을 수도 있고요.
문자열이 같은지를 검사하면 좋은 변형까지 실패합니다. “괜찮아 보이나요?”만 물으면 치명적인 사실 오류가 말투 점수에 묻힙니다. 그래서 답 하나를 여러 질문으로 나눠 봐야 합니다.
✔️ 주문 상태를 맞게 읽었는가
✔️ 실제로 하지 않은 일을 했다고 말하지 않았는가
✔️ 필요한 다음 행동을 알려줬는가
✔️ 불필요한 개인정보를 되풀이하지 않았는가
✔️ 문장이 이해하기 쉬운가
앞의 두 항목은 틀리면 배포를 막을 수 있습니다. 마지막 항목은 비교하며 개선할 수 있고요. 모두 “품질”이지만 무게는 같지 않습니다.2. 좋은 예문보다 실제로 틀린 장면을 모은다
처음 평가 목록을 만들 때는 깔끔한 질문부터 적기 쉽습니다. “배송일을 바꿔줘”, “환불 규정을 알려줘” 같은 것들입니다. 데모는 잘되지만 운영의 모양은 잘 담기지 않습니다.
쓸모 있는 질문은 대개 현장에서 옵니다.
한 사용자는 “그거 금요일 말고 엄마 오는 날로”라고 했습니다. 이전 대화에만 날짜가 있었어요. 다른 사용자는 주문이 두 개인데 “지난번 생수”라고만 했습니다. 변경 요청 도중 물류 상태가 바뀐 경우도 있었고, 제주 배송의 별도 마감 시간을 묻는 질문도 있었습니다.
이 사례를 모을 때 질문만 저장하면 부족합니다. 당시 주문 상태, 적용할 정책 버전, 기대하는 핵심 행동, 절대 나오면 안 되는 행동을 함께 남겨야 합니다.
💡 평가 데이터는 모범 답안 모음이 아니라, 팀이 다시 겪고 싶지 않은 실패의 기록에 가깝습니다.
정책이 바뀌면 기대 결과도 바뀝니다. 그래서 코드처럼 버전을 붙입니다. 지난달 규정을 정답으로 고정한 채 새 답을 검사하면, 정확히 바뀐 시스템을 오답으로 판정하게 되니까요.
3. 한 숫자로 합치지 않는다
팀 대시보드에 “품질 점수 92점” 하나만 있으면 편합니다. 문제는 그 숫자가 무엇을 숨기는지 알기 어렵다는 겁니다.
예를 들어 말투 98점, 사실 정확성 91점, 안전한 중단 70점의 평균은 그럴듯해 보입니다. 하지만 지원하지 않는 주문을 열 번 중 세 번 처리했다고 말하는 제품을 92점짜리라고 부르기는 어렵습니다.
평균 대신 층을 나눠 보는 편이 낫습니다.
첫째, 넘으면 안 되는 선이 있습니다. 잘못된 실행, 권한 밖 정보 노출, 근거 없는 완료 안내처럼 한 건도 가볍게 볼 수 없는 항목입니다.
둘째, 일정 비율을 관리하는 품질이 있습니다. 핵심 사실 포함, 적절한 이관, 질문 이해 같은 항목입니다.
셋째, 서로 비교하며 개선하는 경험 품질이 있습니다. 문장 길이, 친절함, 브랜드 말투처럼 정답 하나로 고정하기 어려운 부분이고요.
이렇게 나누면 “전체 점수는 올랐지만 출시할 수는 없다”는 판단도 설명할 수 있습니다. 숫자가 결정을 대신하는 게 아니라 결정의 이유를 보여줍니다.
4. AI가 채점하면 끝일까
답변이 수천 개가 되면 사람이 전부 읽을 수 없습니다. 이때 다른 모델을 채점자로 쓰면 빠르게 비교할 수 있습니다. 필수 사실이 있는지, 근거와 결론이 맞는지, 두 답 중 어느 쪽이 더 이해하기 쉬운지 같은 1차 분류에는 꽤 유용합니다.
다만 채점 모델도 표현에 끌리고, 긴 답을 더 성실하다고 보거나, 애매한 기준을 자기 방식으로 해석합니다. 그러니 채점자를 심판이 아니라 자동화된 리뷰어로 보는 편이 맞습니다.
사람이 합의한 소량의 기준 답안을 두고 채점 결과와 주기적으로 비교합니다. 사람끼리도 의견이 갈린 문항은 모델 탓을 하기 전에 기준부터 다시 씁니다. “친절한가”보다 “사용자가 다음 행동을 한 번에 알 수 있는가”처럼 관찰 가능한 질문으로 바꾸고요.
그리고 보안·금전·권한처럼 영향이 큰 판단은 사람 검토를 남깁니다. 자동 채점은 넓게 보고, 사람은 틀렸을 때 큰 곳을 깊게 보는 분업입니다.
5. 시험 문제를 외우는 제품이 되지 않게
평가 질문을 보며 프롬프트를 고치다 보면 그 질문에는 놀랍도록 잘 답하게 됩니다. 비슷하지만 처음 보는 질문에서도 잘할지는 별개예요. 시험 문제와 답을 함께 외운 셈이 될 수 있습니다.
그래서 자주 열어보며 고치는 묶음과, 배포 직전에만 확인하는 묶음을 나눕니다. 흔히 개발 세트와 보류 세트라고 부르는 방식입니다. 새로 발견한 실패를 어디에 넣을지도 정해둡니다. 모든 사례를 즉시 고치는 쪽에만 넣으면, 마지막 확인 문제도 결국 익숙해집니다.
운영 데이터의 분포도 함께 봐야 합니다. 평가 목록에는 한국어 일반 주문이 대부분인데 실제 사용자의 30%가 복합 주문을 묻는다면, 점수는 실제 체감보다 낙관적일 수 있습니다.
☑️ 같은 질문에 강해진 것과, 같은 종류의 문제를 잘 풀게 된 것은 다릅니다.
6. 배포 전에 남길 세 줄
평가 체계를 처음부터 크게 만들 필요는 없습니다. 다음 변경을 배포하기 전에 세 가지만 남겨도 시작할 수 있습니다.
1️⃣ 이전 버전보다 나아지기를 기대한 장면
2️⃣ 절대로 나빠지면 안 되는 장면
3️⃣ 실제 사용자가 최근에 실패한 장면
그리고 “좋아졌다”는 말 옆에 정확한 묶음을 적습니다. 모델, 프롬프트, 검색 인덱스, 도구 버전이 달라지면 같은 제품이 아니기 때문입니다. 결과를 재현할 수 있어야 다음 변경도 비교할 수 있습니다.
평가를 통과했다고 사용자가 제품을 좋아한다는 보장은 없습니다. 실제 문의 해결 시간이 줄었는지, 상담원 수정이 줄었는지는 운영에서 따로 봐야 합니다. 하지만 평가는 적어도 어제 막았던 실패를 오늘 다시 들여보내지 않게 해줍니다.
✅ AI 테스트의 목적은 답을 하나로 고정하는 것이 아닙니다. 팀이 지켜야 할 약속을 고정하고, 표현이 바뀌어도 그 약속이 남아 있는지 확인하는 것입니다.
🌱 테스트를 넘어 품질 기준을 만드는 개발자들이 모인 곳, 루퍼스
무엇을 검증할지 정하는 일은 결국 시스템과 사용자를 함께 이해하는 일입니다. 현업의 테스트와 운영 경험을 나누며 그 감각을 키우고 싶다면 루퍼스에서 함께해보세요 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article