AI 에이전트의 품질은 평가와 재검증으로 관리하세요

“시스템 이름도 오류 문구도 모르겠어요. 지금은 화면을 다시 확인할 수 없어요.”

사용자가 이렇게 답했는데 AI는 다시 시스템 이름을 물었습니다. 우리가 기업 AX 코칭용 문의 처리 시나리오를 준비하며 남긴 실제 사전 실행 기록입니다. 고객의 실제 장애가 아니라 교육용 데이터로 실행한 결과이며, 업무 명칭은 일반화했습니다.

이 문제는 답변의 말투를 고쳐서는 해결하기 어렵습니다. 이미 무엇을 확인했고, 더 확인할 수 없을 때 어디로 진행해야 하는지를 평가해야 합니다. 이 글에서는 그 실행 기록을 따라 평가 기준을 만들고, 실패 원인을 찾고, 수정 뒤에도 잘 작동하는지 확인하는 방법을 설명합니다.

자연스러운 질문이 업무 진행을 막았습니다

다른 사전 실행에서는 사용자가 업무 포털에서 접근 권한 오류가 난다고 답했습니다. 실행 기록상 AI는 이미 권한 문의로 분류했습니다. 그런데 메뉴와 화면에 대한 추가 질문을 선택했고 문서 검색은 실행하지 않았습니다.

시스템과 증상이 있으면 관련 안내를 찾아볼 수 있었지만, 검색 전에 필요한 정보와 상세 조사에 유용한 정보의 경계가 불분명했던 것입니다.

사실 추출은 성공했지만 추가 질문 선택으로 문서 검색이 실행되지 않은 사례

사실 추출은 됐지만 다음 경로에서 멈춘 사례를 단순화한 그림입니다.

이 기록을 '정보 추출 실패'나 '검색 결과가 나쁨'으로 적으면 잘못된 부분을 고치게 됩니다. 검색은 아예 실행되지 않았습니다. 먼저 손볼 후보는 검색 설정보다 검색을 시작할 조건과 추가 질문을 멈출 조건입니다.

기록은 당시 버전의 결과입니다. 이후 지침과 흐름을 보완했으므로 현재도 모든 문의에서 같은 문제가 나온다고 일반화할 수는 없습니다.

합격 기준에는 멈추는 행동도 들어갑니다

평가 전에 해당 업무에서 허용할 결과를 정하세요. 문의 처리에서는 답변 초안, 정보 보완 요청, 담당자 확인 요청이 모두 적절한 결과가 될 수 있습니다. 무엇을 반환했느냐보다 상황에 맞는 행동인지가 중요합니다.

이 사례의 기준은 다음처럼 쓸 수 있습니다.

• 시스템과 증상으로 관련 자료를 찾을 수 있으면 검색을 시작한다.
• 사용자가 확인할 수 없다고 한 정보를 같은 방식으로 반복 요구하지 않는다.
• 원문에서 확인한 사실과 근거로 알 수 없는 내용을 구분한다.
• 담당자 확인이 필요한 경우 부족한 정보와 확인 이유를 함께 전달한다.
• 실제로 연결하지 않은 접수, 배정, 복구가 완료됐다고 표현하지 않는다.

'질문은 적을수록 좋다'고 채점하면 필요한 질문까지 없앨 수 있습니다. 정보가 없는데도 임의로 시스템을 추정하고 답하는 것은 더 큰 실패입니다. 필요한 질문은 하고, 확인 불가능한 정보 때문에 무한히 기다리지 않는 것을 기준으로 삼습니다.

결과가 맞는지, 필요한 절차를 지켰는지, 사람의 검토 부담이 줄었는지를 함께 확인합니다.

최종 답변, 실행 과정, 사람이 이어서 해야 할 일을 구분해 확인합니다.

평가 항목은 개별적으로 판정하세요. 근거가 맞아도 미승인 확정이 발생했다면 통과가 아닙니다. 평균 점수에 중대한 실패를 묻지 말고 실패 이유를 따로 남깁니다.

단일 질문 대신 대화의 변화를 평가하세요

사전 실행에는 처음에 '세 명이 로그인하지 못한다'고 했다가 '다른 사람들은 되고 나만 안 된다'고 정정하는 사례도 있었습니다. 후속 입력에서 영향 인원을 최신 값으로 바꾸는지, 이전 판단을 그대로 반복하지 않는지 확인한 것입니다.

최신 추출값을 사용하도록 규칙을 보완한 뒤 담당 팀이 바뀌는 동작을 확인한 기록이 있습니다. 이 한 건만으로 모든 정정이 올바르게 처리된다고 할 수는 없습니다. 정정 자체를 평가 묶음의 한 유형으로 남기는 편이 좋습니다.

다음은 같은 업무를 위한 평가 설계 예시입니다. 아래 모든 경로를 이미 검증했다는 뜻은 아닙니다.

1. 정상 문의: 필요한 정보가 모두 있을 때 근거와 초안을 제공하는가?
2. 정보 부족: 시스템이 없을 때 필요한 항목을 묻는가?
3. 확인 불가: 사용자가 모른다고 답하면 확인 담당자에게 넘길 준비를 하는가?
4. 정보 정정: 같은 대화에서 바뀐 인원이나 조건을 최신 사실로 사용하고 다시 판단하는가?
5. 근거 충돌: 적용 문서가 서로 다르면 근거를 숨기거나 임의로 확정하지 않는가?
6. 실행 실패: 검색이 비거나 도구가 실패하면 완료했다고 쓰지 않고 오류와 다음 행동을 남기는가?

새 사례는 새 대화에서 시작하고, 같은 사례의 보완 답변과 정정은 같은 대화에서 이어갑니다. 시작 상태가 다르면 이전 대화의 영향과 기능 변경의 효과를 구분하기 어렵습니다.

사내 자료를 쓰기 어렵다면 가상 문서와 문의로 이 절차를 만들 수 있습니다. 다만 가상 문서에서 검색이 됐다는 사실은 실제 사내 문서의 품질, 권한과 연결까지 검증했다는 뜻이 아닙니다. 자료의 성격과 현업에서 다시 확인할 항목을 함께 적으세요.

답변이 아니라 실패한 단계부터 고치세요

실행 기록에서 원문, 추출된 사실, 경로 선택, 검색 결과, 초안, 최종 상태를 순서대로 대조합니다. 가장 먼저 기준을 어긴 지점부터 찾습니다.

• 사실 추출: 사용자가 정정한 값을 반영했는가?
• 경로 선택: 검색, 추가 질문, 인계 중 맞는 행동을 골랐는가?
• 검색: 필요한 문서가 존재하는가? 존재하지만 못 찾았는가?
• 근거 전달과 생성: 찾은 내용을 초안에 전달했는가? 없는 조치를 덧붙였는가?
• 도구 실행과 확정: 맞는 값을 전달했는가? 실제 결과와 완료 표현이 일치하는가?

앞선 권한 문의의 기록은 다음처럼 남길 수 있습니다.

입력: 업무 포털과 접근 권한 오류를 확인한 대화
기대 행동: 관련 자료 검색 후 안내 또는 담당자 확인 초안
관찰: 권한 문의로 분류했지만 추가 질문을 선택, 검색 미실행
판정: 검색 시작 조건 미충족
원인 가설: 필수 정보와 보조 정보의 구분이 불명확함
변경 후보: 필수 정보 기준을 명시하고 경로 조건을 규칙으로 검사
재검증: 같은 대화, 확인 불가, 정상 문의와 정보 정정 사례

위 관찰은 실행 기록에 근거합니다. 원인 가설과 변경 후보는 그 관찰을 바탕으로 확인할 내용입니다. 기록을 봤다는 것만으로 원인이 확정되지는 않습니다.

실제 개선 구성에서는 AI가 사실을 추출하고, 프로그램이 누락 정보와 질문 상한을 검사하도록 역할을 나눴습니다. 그러나 프로그램이 받는 추출값이 틀리면 경로도 틀릴 수 있습니다. 규칙을 넣은 뒤에도 원문과 추출값의 대조는 남습니다.

종료 성공과 업무 정답률은 다릅니다

보완 후 사전 검증 기록에는 14개 대화, 26턴에서 빈 응답과 실행 실패가 0건으로 남아 있습니다. 모두 안내 또는 확인 요청 초안으로 종료했다는 기록입니다.

이 결과로 '정확도 100%'를 주장할 수는 없습니다. 실행이 끝났는지, 답변이 맞는지, 실제 문제가 해결됐는지는 서로 다른 항목입니다. 같은 기록에는 권한 문의에서 세 번째 질문이 나온 한계와 문장 정확성에 사람 검토가 필요하다는 점도 남아 있습니다.

중요한 사례는 같은 시작 상태에서 반복하세요. 예를 들어 3개 사례를 각각 3회 실행하는 것은 평가 절차를 만드는 작은 연습입니다. 현업 전체를 대표하는 충분한 표본이라는 뜻은 아닙니다.

9회 실행 중 8회 통과했다는 숫자와, 세 번 모두 통과한 사례가 2개라는 숫자를 같이 적으면 반복 중 실패가 드러납니다. 이 숫자는 설명용 예시이며 실제 프로젝트의 결과가 아닙니다. 반복 횟수, 사례 수와 중대한 실패를 함께 표시합니다.

Anthropic의 평가 가이드도 최종 문장과 실제 결과 상태를 구분하고, 한 사례를 여러 번 실행하며, 코드와 모델과 사람의 평가를 조합하도록 설명합니다. 여기서는 그 방법을 문의 처리의 실행 기록에 맞춰 적용했습니다. 원문 읽기

AI 채점과 수정 결과도 다시 확인하세요

AI에게 '좋은 답변인가?'만 물으면 정중한 추가 질문을 합격으로 볼 수 있습니다. 앞선 사례에서는 사용자가 이미 확인할 수 없다고 했는지를 채점 자료에 포함해야 합니다.

사람이 먼저 정상, 실패, 경계 사례를 판정하고 같은 원문과 실행 기록을 AI 채점기에 줍니다. 의견이 갈린 사례, 특히 실패를 합격으로 본 사례를 골라 이유를 확인하세요. 사람끼리도 판단이 다르면 기준부터 명확히 합니다. 기록이 부족해 판단할 수 없는 항목을 합격으로 채우지 않습니다.

한 부분을 수정했으면 실패 사례와 이전에 통과한 사례를 모두 다시 실행합니다. 정정 처리를 고치며 정상 문의의 인원을 놓치거나, 질문을 줄이면서 정보가 부족한 문의까지 답하는 문제가 생길 수 있기 때문입니다.

대표 사례를 고르고 통과 기준을 적은 뒤 같은 조건으로 비교합니다. 발견한 실패는 다음 평가에 포함합니다.

같은 사례와 기준으로 비교하고 새 실패를 다음 평가에 남깁니다.

모델, 자료, 시작 상태와 기준을 유지하고 변경한 요소를 적습니다. 여러 요소를 함께 바꿨다면 묶음 전체의 결과로 보고합니다. 최종 확인용 사례 일부는 개선 작업에 쓰지 않고 남겨두세요. 그 결과를 보고 다시 수정했다면 이미 개발에 사용한 사례가 되므로 별도 확인 사례가 필요합니다.

아래 기록을 동료와 함께 한 건씩 채우면 평가를 다시 실행할 수 있습니다.

사례와 대화 순서: (입력)
자료, 버전과 시작 상태: (입력)
필수 결과와 허용한 다음 행동: (입력)
금지 행동: (입력)
반복 횟수와 회차별 판정: (입력)
실패 단계와 실행 근거: (입력)
사람의 수정 내용과 시간: (입력)
채점 불일치와 판단 보류: (입력)
변경한 요소: (입력)
기존 성공 사례의 재검증: (입력)
아직 확인하지 못한 범위: (입력)

최근 실패한 대화 하나를 골라, 어느 단계에서 처음 기대와 어긋났는지 적어보세요. 그 지점을 기준으로 다음 실험을 정하면 프롬프트를 막연히 길게 고치는 일을 줄일 수 있습니다.

이 글의 실제 관찰은 AIPM의 교육용 시나리오 사전 실행 기록을 바탕으로 했습니다. 고객명과 업무 명칭은 일반화했으며, 평가 설계 예시와 아직 수행하지 않은 검증을 실제 성과로 표시하지 않았습니다.