AI 에이전트 평가는 결국 골든셋으로 돌아온다
AI 에이전트 평가는 결국 골든셋으로 돌아온다
TL;DR
AI 에이전트를 평가할 때 “이번 답변이 괜찮았나?”만 보면 오래 지속하기 어렵다. 모델이나 프롬프트를 바꿨을 때 좋아졌는지 비교할 수 없고, 평가하는 사람마다 기준도 달라진다.
지속 가능한 에이전트 평가는 사람이 만든 골든셋으로 돌아온다. 다만 에이전트의 정답지는 최종 답변 하나로 끝나지 않고, 어떤 맥락을 찾아야 하는지, 어떤 도구를 써야 하는지, 언제 질문해야 하는지, 어떻게 검증해야 하는지까지 포함한다.
감상평으로 시작하는 평가
AI 에이전트를 써보면 자연스럽게 감상평을 하게 된다.
“이번엔 꽤 잘했네.”
“테스트도 안 돌리고 완료했다고 하네.”
이런 감각은 중요하다. 처음에는 사람이 직접 써보면서 “좋다”, “불안하다”, “아직은 못 맡기겠다”를 느껴야 한다.
하지만 감상평만으로는 평가가 지속되지 않는다.
모델을 바꿨을 때 실제로 좋아졌는지, 프롬프트를 수정했을 때 개선됐는지, 도구를 하나 추가했을 때 일을 더 잘하게 됐는지 비교할 방법이 없다. 평가하는 사람마다 “좋은 에이전트”의 기준도 달라진다. 어떤 사람은 최종 답변이 깔끔하면 좋다고 느끼고, 어떤 사람은 테스트를 돌리지 않았으면 답이 좋아도 불안해한다.
이런 차이는 각자가 에이전트에게 일을 맡기는 방식에서 나온다.
그래서 에이전트 평가는 감상에서 출발할 수는 있지만, 운영되려면 반복 가능한 기준으로 고정되어야 하고 그 기준은 골든셋의 형태를 띠게 된다. 골든셋은 사람이 “이런 상황에서는 이렇게 일해야 한다”고 정해둔 기준이다. 에이전트가 매번 얼마나 그 기준에 가까운지 비교할 수 있어야 한다.
지속 가능한 평가는 우리가 중요하게 보는 케이스에서 이전보다 더 안정적으로 통과했는지를 말할 수 있어야 한다.
행동까지 포함하는 에이전트 정답지
일반적인 LLM 평가는 비교적 답변 중심으로 설계할 수 있다. 요약이 정확한가, 번역이 자연스러운가, 객관식 문제를 맞혔는가, 코드의 출력값이 기대값과 일치하는가 정도로 정답을 정할 수 있다.
에이전트 평가는 여기서 한 단계 더 복잡하다. 에이전트는 답변만 하는 존재가 아니라 일을 처리하는 존재다. 일을 처리한다는 것은 중간에 여러 선택을 한다는 뜻이다.
예를 들어 사용자가 이렇게 요청했다.
“이 버그 좀 고쳐줘.”
이 요청에 대해 에이전트는 어떤 파일을 봐야 할지, 관련 테스트가 있는지, 기존 구현의 의도가 무엇인지 먼저 파악해야 하고, 요구사항이 애매하면 질문할지 합리적인 기본값으로 진행할지 판단해야 하며, 코드를 수정한 뒤에는 테스트를 돌리고 실패하면 로그를 보고 원인을 좁혀서 어떤 검증을 했는지 사용자에게 알려야 한다.
이 모든 과정이 에이전트의 품질을 만든다.
최종 코드가 우연히 맞았더라도 과정이 불안하면 좋은 에이전트라고 보기 어렵다. 반대로 최종 결과가 아직 완벽하지 않더라도, 어떤 맥락을 확인했고 어디서 막혔으며 다음에 무엇을 해야 하는지 명확히 남겼다면 더 신뢰할 수 있다.
그래서 에이전트의 정답지는 최종 답변 하나로 부족하다.
입력 상황
필수로 확인해야 할 맥락
허용되는 가정
금지되는 행동
기대되는 도구 사용
기대되는 중간 판단
최종 산출물의 조건
검증 방법
최종 보고 형식
예컨대 검증 가능한 작업에서 테스트 없이 완료를 선언했다면, 정답에 가까운 답변을 했더라도 좋은 에이전트 행동으로 보기 어렵다. “사용자에게 질문했는가?”도 비슷하게 봐야 한다. 스스로 확인할 수 있는 정보를 사용자에게 다시 묻는 것은 오히려 나쁜 행동일 수 있고, 위험한 의사결정을 해야 하는 상황에서 질문하지 않고 진행하는 것도 나쁜 행동이다.
에이전트 평가에서 봐야 하는 것은 “무슨 답을 냈는가”뿐 아니라 “어떤 방식으로 그 답에 도달했는가”이다. 에이전트의 정답지는 결과 정답지이면서 동시에 행동 정답지여야 한다.
골든셋을 사람이 만드는 이유
에이전트 평가를 이야기하면 자연스럽게 자동 평가를 떠올리게 된다. LLM-as-a-judge처럼 또 다른 모델에게 결과를 평가하게 할 수도 있고, 실행 결과나 테스트 통과 여부로 점수를 낼 수도 있다.
이런 방식은 분명 유용하다. 하지만 출발점은 사람이 만든 골든셋이어야 한다고 생각한다. 에이전트에게 맡길 일의 기준은 대체로 보편 정답이 아니라 사람, 팀, 제품, 프로젝트의 맥락에 묶여 있기 때문이다.
어떤 팀은 코드를 수정하기 전에 관련 테스트를 먼저 확인해야 한다고 생각하고, 어떤 팀은 작은 수정이라면 먼저 고치고 테스트로 검증하는 방식을 선호한다. 어떤 제품에서는 에러 메시지를 기술적으로 정확하게 쓰는 것보다 사용자의 다음 행동을 명확히 안내하는 것이 더 중요할 수 있다.
이런 기준은 모델이 인터넷에서 알아서 배울 수 있는 종류의 지식이 아니다. 사람이 “우리에게 좋은 에이전트란 이런 식으로 일하는 것이다”라고 적어두어야 한다.
골든셋을 만든다는 것은 문제와 정답을 쌓는 일이라기보다, 사람이 자신의 판단 기준을 외부화하는 일이다.
평소에는 머릿속에만 있던 기준들이 있다.
“이 정도 애매함은 그냥 진행해도 된다.”
“이 작업은 테스트 없이 완료했다고 말하면 안 된다.”
이런 암묵지가 골든셋 안에 들어간다. 그래서 골든셋은 AI를 평가하기 위한 자료이기 전에 사람이 중요하게 생각하는 작업 기준의 기록이다. 에이전트 평가는 그 기록에 에이전트의 행동이 얼마나 가까운지를 보는 과정이다.
골든셋 예시와 필수 항목
그렇다면 에이전트 평가용 골든셋은 어떻게 생겨야 할까?
단순히 입력과 출력만 있으면 부족하다.
{
"input": "이 버그 고쳐줘",
"expected_output": "수정 완료했습니다"
}
이런 형태로는 에이전트를 제대로 평가하기 어렵다. 무엇을 확인해야 하는지, 어떤 행동을 하면 안 되는지 알 수 없기 때문이다.
에이전트용 골든셋은 조금 더 작업 명세에 가까워야 한다. 예를 들면 이런 형태다.
id: bugfix-user-guidance-001
task: "사용자 상태 안내 메시지가 이상해. 고쳐줘."
context:
domain: user-guidance
request_is_ambiguous: true
given:
- 사용자 상태에는 여러 종류가 있다.
- 각 상태는 사용자에게 다른 다음 행동을 안내해야 한다.
- 기존 테스트가 존재한다.
expected_behavior:
should:
- 관련 도메인 파일을 먼저 찾는다.
- 기존 테스트를 확인한다.
- 상태별 사용자 안내 문구를 구분한다.
- 수정 후 관련 테스트를 실행한다.
- 최종 보고에 실행한 테스트와 남은 리스크를 적는다.
should_not:
- 모든 상태를 같은 메시지로 뭉갠다.
- 테스트 없이 완료했다고 말한다.
- 사용자가 말하지 않은 정책을 새로 만든다.
- 확인할 수 있는 파일 구조를 사용자에게 다시 묻는다.
scoring:
context_retrieval: 2
tool_use: 2
domain_correctness: 3
verification: 2
final_report: 1
이 예시에서 중요한 것은 기대되는 행동 쪽이다.
좋은 에이전트 골든셋에는 최소한 다음 항목이 들어가야 한다.
1. Task
에이전트에게 실제로 줄 요청이다. 너무 정제된 문제보다 실제 사용자가 할 법한 요청에 가까워야 하는데, 현실의 요청은 대부분 불완전하다. 사용자는 모든 배경을 설명하지 않고, 파일명을 정확히 알려주지 않을 수도 있다. 그래서 평가용 task도 어느 정도 현실적인 모호함을 담는 게 좋다.
2. Context
이 작업을 평가하기 위해 필요한 배경이다. 프로젝트, 도메인, 기존 규칙, 사용자 선호, 운영 환경 같은 정보가 들어갈 수 있다.
다만 에이전트에게 모든 컨텍스트를 처음부터 다 주면 “맥락을 찾는 능력”을 평가하기 어렵다. 어떤 정보는 명시적으로 주고 어떤 정보는 파일이나 문서에서 찾게 두면 컨텍스트 회수 능력을 평가할 수 있다.
3. Expected behavior
에이전트가 해야 하는 행동이다. 위 YAML 예시의 expected_behavior처럼 관련 파일을 먼저 찾고 기존 테스트를 확인한 뒤 수정 후 테스트를 실행하고 결과를 보고하는 흐름을 적는다. 에이전트 평가는 결과물뿐 아니라 이 행동을 봐야 한다.
4. Forbidden behavior
하면 안 되는 행동도 명시한다. 위 예시의 should_not처럼 확인 가능한 정보를 추측하거나 테스트 없이 완료를 선언하거나 위험한 변경을 허락 없이 수행하는 행동을 적어둔다. 좋은 에이전트의 기준은 “해야 할 일”뿐 아니라 “하지 말아야 할 일”에서도 드러난다.
5. Verification
어떤 검증을 거쳐야 완료로 볼 수 있는지 명시한다. 코드 작업이라면 테스트, 타입체크, 린트, 빌드가 될 수 있고, 문서 작업이라면 링크 확인이나 민감 정보 제거가 될 수 있다. 에이전트의 완료 보고는 검증 결과의 형태여야 한다.
6. Scoring rubric
마지막으로 부분 점수 기준이 필요하다. 에이전트 작업은 0점 또는 1점으로 나누기 어려운 경우가 많다. 최종 결과는 맞았지만 검증을 빼먹을 수도 있고, 컨텍스트는 잘 찾았지만 보고가 부실할 수도 있다.
그래서 채점 기준을 나눈다.
의도 해석: 2점
컨텍스트 회수: 2점
도구 사용: 2점
도메인 정확성: 3점
검증: 2점
최종 보고: 1점
이렇게 나누면 어떤 변경이 어떤 능력을 개선했는지 볼 수 있다. 모델을 바꿨더니 도메인 정확성은 좋아지고 도구 사용은 나빠질 수도 있고, 시스템 프롬프트를 바꿨더니 최종 보고는 좋아지고 질문이 늘어날 수도 있다. 골든셋과 rubric이 있어야 이런 비교가 가능하다.
실패 사례를 골든셋으로 만들기
골든셋을 처음부터 완벽하게 만들 수는 없다. 처음에는 몇 개의 대표 시나리오로 시작해도 된다.
하지만 진짜 중요한 케이스는 운영 중에 나온다. 예컨대 테스트 없이 완료 보고를 한 경우나, 확인할 수 있는 파일 구조를 사용자에게 다시 물어본 경우가 그렇다.
실패를 “이번엔 별로였다”로 끝내면 다음에도 비슷한 일이 반복되지만, 골든셋 케이스로 만들면 그 실패는 평가 자산이 된다.
평가 루프는 이렇게 생길 수 있다.
실패 사례 수집
→ 골든셋 케이스로 승격
→ 기대 행동과 금지 행동 작성
→ 에이전트 실행
→ 채점
→ 프롬프트, 도구, 메모리, 워크플로우 수정
→ 재평가
이 루프가 있어야 에이전트 개선이 감각이 아니라 데이터가 된다.
골든셋은 정적인 시험지가 아니다. 서비스가 바뀌고 팀의 기준이 바뀌고 에이전트에게 맡기는 일이 바뀌면 골든셋도 같이 바뀐다. 처음에는 코드 수정 중심의 골든셋이 필요할 수 있고, 나중에는 운영 대응, 문서 작성, 코드 리뷰, 배포 확인 같은 시나리오가 추가될 수 있다.
LLM-as-a-judge와 골든셋의 역할 분담
자동 채점은 필요하다. 매번 사람이 모든 에이전트 실행 결과를 읽고 평가할 수는 없다. LLM-as-a-judge는 특히 유용할 수 있다. 최종 답변의 품질, 보고의 명확성, rubric에 따른 부분 점수 등을 빠르게 평가할 수 있다.
하지만 LLM-as-a-judge가 사람이 만든 골든셋을 대체할 수는 없다. judge 모델도 기준이 필요하다. 무엇을 좋은 행동으로 볼지, 어떤 검증이 필수인지 알려줘야 하기 때문이다. 기준 없이 judge만 세우면 평가는 다시 감상평으로 돌아간다. 이번엔 모델의 감상평이다.
그래서 순서는 이렇다. 먼저 사람이 골든셋을 만들고 그 안에 기대 행동, 금지 행동, 검증 조건, scoring rubric을 적는다. 그 다음 자동 채점기를 붙이면 LLM-as-a-judge는 이 기준에 비추어 평가를 돕는 도구가 된다. 자동 평가는 골든셋 위에서 돌아가야 한다.
위임 기준으로서의 에이전트 평가
에이전트를 평가한다는 것은 모델 성능을 재는 일을 넘어, 내가 어떤 일을 어디까지 맡길 수 있는지 정하는 일이다.
그래서 에이전트 평가에는 기술적인 기준과 운영적인 기준이 함께 들어간다. 정확한 답을 하는가, 필요한 맥락을 찾는가, 도구를 적절히 사용하는가, 실패했을 때 복구하는가, 위험한 상황에서 멈출 줄 아는가 같은 질문들이다. 이 기준들이 쌓이면 단순한 평가표를 넘어서 에이전트에게 일을 맡기는 방식의 명세가 된다.
나는 앞으로 에이전트 평가가 점점 더 중요해질수록, 평가의 중심이 “이 모델이 얼마나 똑똑한가?”에서 “이 시스템을 어디까지 믿고 맡길 수 있는가?”로 이동할 것이라고 생각한다.
시작은 작게 해도 된다. 가장 최근에 에이전트가 아쉬웠던 일을 하나 골라, 그때 내가 기대했던 행동과 하지 말았으면 했던 행동을 적어보는 것으로 골든셋의 첫 케이스를 만들 수 있다.