AI가 고객 문의에 자동으로 답하게 해뒀는데, "이게 진짜 잘 되고 있나?"는 늘 감이었다. 이번에 로나(Rona)가 추천한 AI Eval 스킬로 한 바퀴를 실제로 돌려서, 감 대신 데이터로 확인해봤다.
왜 했나
CS 문의가 들어오면 봇이 ①자동응답할지 사람에게 넘길지 판단하고 ②답변 초안을 만든다. 문제는 — "이 구조가 효율적인지, 허점은 없는지"를 물어보면 답이 감밖에 없었다는 것. AI는 자신감 있게 틀리고, 같은 질문에도 매번 다르게 답한다. 2+2=4 같은 테스트로는 안 잡힌다.
그래서 실제 CS 채팅 31건을 놓고, 감이 아니라 재현 가능한 방식으로 재봤다.
어떻게 (AI Eval 한 바퀴)
이번엔 로나(Rona)가 추천해준 AI Eval 스킬(gpters-evals)의 8단계를, 실제 CS 데이터 위에서 그대로 걸어봤다.
평가 지점 확정 — "좋다"를 확인 가능한 3줄로 못 박음(정책 근거·응대 판단·완결성). → 정적인 'CS 트리'가 아니라 AI가 실제 판단하는 지점에 평가를 붙여야 한다는 게 첫 교훈.
트레이스 남기기 — 실제 채팅 31건을 {문의·봇답변·운영개입·결정} 한 줄 기록으로(개인정보 마스킹).
직접 읽기 — 31건을 사람이 눈으로 읽어 실패 유형을 뽑음(미리 만든 라벨 X).
기준 맞추기 — 같은 건을 둘이 독립 판정 → 자동화 경계를 규칙으로 확정.
먼저 고치기 — 코드 한 줄로 잡히는 싼 실패부터 처리.
코드 체크 — 규칙으로 딱 갈리는 건 자동 검사로.
AI 심판 + 검증 — 판단이 필요한 것만 심판으로, 그 심판이 믿을 만한지 다시 검증.
상시화 — 전부 한 폴더로 묶어 언제든 재실행(
/cs-eval).
삽질에서 나온 것 (여기가 진짜)
자동 탐지기가 놓친 걸 사람이 잡았다. 스크립트로 "테스트 메시지 누출"을 찾게 했더니 1건. 그런데 눈으로 읽으니 2건이었다(형식이 달라 정규식이 못 잡음). → "직접 읽기"를 대체할 자동화는 없다.
일치율 71%인데 실제 합의는 κ=0.30. 두 사람이 71% 같게 판정했지만, 둘 다 '통과' 쪽으로 기우는 습관 때문에 우연히 겹친 것. 우연을 빼니 실제 합의는 약했다. → 단순 일치율은 속는다.
심판이 "실패 23%"라는데, 보정하니 진짜는 54%. AI 심판을 검증해보니 진짜 실패의 절반 넘게 놓치고 있었다. 검증 안 했으면 "23%밖에 안 틀리네" 하고 믿을 뻔. → 심판도 검증해야 믿는다.
결과
허점 카탈로그 — 최대 비효율은 특정 문의 유형에서 봇이 아예 못 잡아 매번 사람이 붙는 것(전체의 약 40%). → 표준 안내 하나로 큰 덩어리를 자동화할 여지 발견.
발송 위생 이슈(테스트 메시지가 실사용자에게 나간 2건) → 발송 전 가드로 차단(검증 완료).
자동/사람 경계 규칙 확정 — "안내까지는 자동, 개별 처리는 사람".
재실행 가능한 평가 세트 — 프롬프트·정책 바꿀 때마다 돌려서 회귀를 잡는다.
배운 것 한 줄씩
허점은 감이 아니라 실제 로그를 직접 읽는 데서 나온다.
싼 건 코드로, 판단이 필요한 것만 AI 심판으로 — 근데 그 심판도 검증해야 한다.
일회성 감사로 끝내지 말고 재실행 가능한 세트로 남겨야 다음 에 또 쓴다.
이 글은 로나(Rona) 추천 스킬 gpters-evals(AI Eval 한 바퀴)를 실제 CS 자동응대 기능에 적용해본 기록입니다. 로나는 AI를 실제 업무에 직접 써보도록 돕는 도구예요.
