AI 에이전트가 교육 제안서를 10분 만에 완성했습니다. 문장도 자연스럽고 표도 깔끔합니다. 그런데 강의 시간은 지난해 자료에서 가져왔고, 기관이 요구한 대상 연령은 빠졌습니다. 겉으로 보기 좋은 결과와 실제로 제출할 수 있는 결과는 다릅니다. 오류를 고치려면 “AI가 틀렸다”에서 한 걸음 더 들어가 어느 단계가 실패했는지 알아야 합니다.
에이전트 평가는 최종 답변의 품질과 과정의 품질을 함께 봅니다. Microsoft Foundry의 에이전트 평가 항목에도 과업 완료와 도구 호출 정확성처럼 서로 다른 관점이 있습니다. Anthropic 역시 평가할 때 최종 산출물뿐 아니라 에이전트의 진행 기록을 살펴보는 방법을 설명합니다. Microsoft Learn, Agent evaluators · Anthropic, Demystifying evals
같은 ‘오답’도 고칠 곳은 다릅니다
“주민 대상 교육 제안서에 지난해 강의 시간이 들어갔다”는 오류를 예로 들어 보겠습니다. 요청에 ‘올해 기준’이 명시되지 않았을 수도 있고, 검색 도구가 최신 문서를 찾지 못했을 수도 있습니다. 최신본을 찾았는데 에이전트가 오래된 파일을 택했거나, 초안 작성 과정에서 시간을 잘못 옮겼을 수도 있습니다.
| 실패 지점 | 확인할 흔적 | 수정 방향 |
|---|---|---|
| 요청 해석 | 기간·대상·완료 조건을 어떻게 이해했나 | 필수 조건을 명시하고 모호하면 되묻게 함 |
| 자료 검색 | 검색 결과에 최신 승인본이 있었나 | 문서 상태·검색 범위·색인 갱신 점검 |
| 도구 선택·입력 | 올바른 도구를 적절한 날짜·대상으로 호출했나 | 도구 설명·입력 검증·권한 범위 개선 |
| 결과 해석 | 출처의 수치와 최종 문장이 일치하나 | 인용 확인과 불확실성 표시 단계 추가 |
| 실행 통제 | 승인 없이 발송·수정했나 | 승인 지점과 쓰기 권한 분리 |
최신 문서가 검색 결과에 없었다면 답변 문구만 다시 쓰게 해도 근본 문제는 남습니다. 반대로 최신 문서는 있었지만 모델이 다른 파일을 골랐다면 검색 색인보다 선택 기준과 중간 검토가 문제입니다. 실패 위치에 맞는 수정을 해야 재발을 줄일 수 있습니다.
테스트 질문에는 예상 답보다 ‘성공 조건’을 적습니다
작은 평가 세트를 만든다면 직원들이 실제로 하는 질문부터 모으세요. “교육 제안서 초안 만들어줘”, “최신 강의계획서로 시간표를 바꿔줘”, “기관 담당자에게 메일로 보내줘”처럼 자료 조회, 초안, 외부 실행을 섞습니다. 각 사례에 정답 문장 하나만 적지 말고 통과 조건과 금지 행동을 적습니다.
- 입력
- “올해 주민 대상 AI 교육 제안서 초안을 만들어줘.”
- 사용 가능한 자료
- 올해 승인 강의안, 지난해 폐기 강의안, 기관 요청서
- 통과 조건
- 올해 승인본의 시간·대상 반영, 기관 필수 항목 포함, 원본 링크 표시
- 실패 조건
- 폐기본 사용, 확인되지 않은 예산 단가 단정, 요청 없는 외부 발송
이렇게 만들면 표현이 조금 다른 초안도 기준에 맞으면 통과할 수 있고, 문장이 매끄러워도 폐기본을 썼다면 실패로 볼 수 있습니다. 평가 기준은 현장 담당자가 실제 제출 전에 확인하는 항목과 맞춰야 합니다. 평가 자동화 도구의 점수는 검토에 도움을 주지만, 특히 중요한 사례는 사람이 근거와 실행 결과를 직접 확인할 필요가 있습니다. Anthropic, 평가 설계
실행 기록이 있어야 원인을 찾습니다
에이전트가 어떤 도구를 어떤 순서로 호출했고, 무슨 결과를 받았으며, 언제 사람의 승인을 요청했는지를 남기면 실패를 재현할 수 있습니다. 이를 실행 추적(trace)이라고 부릅니다. OpenAI Agents SDK의 추적 기능도 모델 호출, 도구 호출, 인계 등의 과정을 관찰할 수 있게 합니다. 기록에는 업무상 필요한 정보만 남기고, 개인정보와 민감 자료는 접근 범위와 보존 기준에 따라 다뤄야 합니다. OpenAI Agents SDK, Tracing
한 사례를 고친 뒤 다른 사례가 망가지는 일도 있습니다. 예를 들어 “항상 올해 문서만 사용”이라는 규칙은 지난해 실적을 비교하는 요청에서는 장애가 됩니다. 수정 후에는 원래 실패한 질문뿐 아니라 정상 작동하던 대표 질문도 다시 검사해야 합니다.
한 개 점수보다 네 가지 관찰 지표가 낫습니다
시범 운영에서는 ① 과업 완료, ② 근거 충실도, ③ 도구 선택·입력 정확성, ④ 승인 절차 준수를 따로 기록해 보세요. 속도와 비용도 함께 볼 수 있지만 정확성과 통제를 가리는 합계 점수로 뭉치지 않는 편이 좋습니다. 도구를 적게 호출해 빨리 끝냈어도 자료를 잘못 골랐다면 성공으로 보기 어렵습니다. Microsoft의 평가 문서 역시 과업 완료와 도구 사용의 평가를 구분합니다. Microsoft Learn, 에이전트 평가 항목
질문 · 기대하는 자료와 결과 · 실제 찾은 자료 · 사용한 도구와 입력값 · 최종 답변 · 승인 필요 여부 · 담당자 판정 · 수정할 단계
좋은 평가는 작은 실패 사례에서 시작합니다
처음부터 모든 업무를 숫자로 평가할 필요는 없습니다. 이미 직원이 “이 답은 위험하다”고 느낀 사례 다섯 개를 모아 보세요. 각 사례의 통과·실패 조건을 쓰고, 자료와 도구의 실행 기록을 살펴 원인을 분류합니다. 수정 하나를 적용한 뒤 같은 사례와 다른 업무 질문을 다시 실행합니다. 이 과정이 쌓이면 조직에 맞는 평가 세트가 됩니다. 다섯 개는 시작을 위한 예시이며 공식 기준은 아닙니다.
에이전트의 품질은 “한 번 잘했다”보다 실패를 발견하고, 어디를 고쳐야 하는지 설명하고, 다시 확인할 수 있는가에 달려 있습니다. 결과물의 미감과 속도에 가려진 경로를 열어 보는 일이 실제 업무에 쓸 수 있는 AI를 만듭니다.
Microsoft Learn, Agent evaluators · Anthropic, Demystifying evals for AI agents · OpenAI Agents SDK, Tracing