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

에이전트가 해야 하는 행동이다.

예를 들면:

• 관련 파일을 먼저 확인한다.
• 기존 테스트를 확인한다.
• 필요한 경우 도구를 사용한다.
• 실패 로그를 읽고 원인을 좁힌다.
• 수정 후 검증을 수행한다.
• 최종 보고에 근거를 포함한다.

에이전트 평가는 결과물뿐 아니라 이 행동을 봐야 한다.

4. Forbidden behavior

하면 안 되는 행동도 명시해야 한다.

예를 들면:

• 확인 가능한 정보를 추측한다.
• 테스트 없이 완료했다고 말한다.
• 모든 상태를 하나로 뭉갠다.
• 사용자에게 불필요한 질문을 한다.
• 위험한 변경을 허락 없이 수행한다.
• 프로젝트 컨벤션을 무시한다.

좋은 에이전트의 기준은 “해야 할 일”뿐 아니라 “하지 말아야 할 일”에서도 드러난다.

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는 이 기준에 비추어 평가를 돕는 도구가 된다.

즉 자동 평가는 골든셋 위에서 돌아가야 한다.

에이전트 평가의 핵심은 “AI가 AI를 평가하게 하자”가 아니다. 핵심은 “사람이 정한 좋은 일 처리 방식에 얼마나 가까운지 반복 측정하자”이다.

에이전트 평가는 곧 위임 기준을 정하는 일이다

에이전트를 평가한다는 것은 단순히 모델 성능을 재는 일이 아니다. 내가 어떤 일을 어디까지 맡길 수 있는지 정하는 일이다.

그래서 에이전트 평가에는 기술적인 기준과 운영적인 기준이 함께 들어간다.

정확한 답을 하는가. 필요한 맥락을 찾는가. 도구를 적절히 사용하는가. 실패했을 때 복구하는가. 검증 없이 완료를 선언하지 않는가. 사용자의 다음 행동을 줄이는가. 위험한 상황에서 멈출 줄 아는가. 프로젝트나 팀의 기준을 지키는가.

이 기준들이 쌓이면 단순한 평가표를 넘어서, 에이전트에게 일을 맡기는 방식의 명세가 된다.

나는 앞으로 에이전트 평가가 점점 더 중요해질수록, 평가의 중심이 “이 모델이 얼마나 똑똑한가?”에서 “이 시스템을 어디까지 믿고 맡길 수 있는가?”로 이동할 것이라고 생각한다.

그 질문에 답하려면 감상평만으로는 부족하다. 반복 가능한 골든셋이 필요하다. 그리고 그 골든셋은 사람이 만들어야 한다.

에이전트 평가는 모델이 얼마나 똑똑한지 감상하는 일이 아니다. 내가 어떤 일을 어떤 방식으로 맡길 수 있다고 보는지, 그 기준을 먼저 정리하는 일이다.

그래서 지속 가능한 에이전트 평가는 결국 골든셋으로 돌아온다.

골든셋은 정답지가 아니라, 좋은 일 처리 방식의 명세다.