Agent 평가

평가가 학습보다 중요한 이유

평가 없는 Agent 개발은 눈을 가리고 비행기를 모는 것과 같습니다. 평가는 전체 개발 주기를 관통하는 핵심 인프라이며, 출시 전 체크리스트에 불과하지 않습니다.

평가 없이 개발하면 생기는 결과

실제 사례

사용자가 "이번 주 Agent가 명확히 나빠졌다"라고 피드백합니다. 팀은 3일 동안 commit 기록을 뒤지고 수십 가지 롤백 방안을 시도한 끝에, 2주 전의 무해해 보이는 Prompt 미세조정이 원인이었음을 발견합니다. 평가가 있었다면 코드 병합 전에 이 문제를 발견했을 것입니다.

추측-확인 루프

평가 없는 디버깅 과정은 이렇습니다: 문제가 어디 있는지 추측 → 수정 → 수동으로 몇 가지 케이스 테스트 → 아마 괜찮은 것 같다고 느낌 → 배포 → 또 망가진 것 발견. 이 루프는 몇 주씩 지속될 수 있으며, 막대한 엔지니어링 리소스를 소비하지만 어떤 신뢰도 보장하지 못합니다.

평가의 가치 타임라인

초기 단계 — 성공 정의하기

평가의 첫 번째 가치는 팀이 성공이 어떤 모습인지 정의하도록 강제한다는 것입니다 — 테스트는 오히려 부차적입니다. eval을 작성할 수 없다면, 보통 태스크에 대한 이해가 아직 충분하지 않다는 의미입니다. 이 과정 자체가 프로덕트 매니저가 요구사항을 더 잘 이해하도록 도와줍니다.

중기 단계 — 회귀 테스트 & 변경 검증

Prompt을 수정하거나, 모델을 교체하거나, 파라미터를 조정할 때마다 몇 분 내에 전체 성능에 미치는 영향을 알 수 있습니다. 회귀 테스트는 하나의 차원을 최적화하는 동안 실수로 다른 차원을 망가뜨리는 것을 방지합니다; 변경 검증은 모든 결정에 데이터 근거를 제공합니다.

후기 단계 — 새 모델 빠른 도입

새 모델이 출시될 때(예: Claude Opus 4.6, GPT-5), 탄탄한 평가를 갖춘 팀은 며칠 내에 마이그레이션을 완료할 수 있습니다: eval suite를 한 번 실행하고, 성능 저하가 없음을 확인한 후, 바로 전환합니다. 평가가 없는 팀은 몇 주 또는 몇 달의 수동 검증이 필요하며 최적의 타이밍을 놓칩니다.

평가의 핵심 개념

이 7가지 용어를 이해하면 전체 평가 체계의 언어를 마스터하게 됩니다.

Task（태스크）

하나의 테스트 케이스. 입력(Agent에 주는 지시)과 성공 기준(무엇이 완료로 간주되는가)을 포함합니다.

Trial（시도）

동일한 Task의 한 번의 실행 시도. 모델 출력에 무작위성이 있으므로, 통계적 유의미성을 위해 동일한 Task를 여러 번 Trial 해야 합니다.

Grader（평가기）

채점 로직. 코드 규칙, LLM 검토, 또는 인간 채점일 수 있습니다. Trial의 결과가 통과인지 실패인지를 결정합니다.

Transcript（기록）

완전한 실행 추적: Agent의 모든 추론 단계, 모든 도구 호출, 모든 중간 결과가 전부 기록됩니다.

Outcome（결과）

환경의 최종 상태. Agent가 말한 것뿐만 아니라 실제로 한 것을 봅니다: 파일이 올바르게 수정되었는지, API가 올바르게 호출되었는지.

Harness（평가 하네스）

평가를 실행하는 인프라. 샌드박스 환경 생성, Agent 시작, 결과 수집, Grader 호출하여 채점하는 역할을 담당합니다.

Suite（스위트）

관련 Task의 집합. 예를 들어 「파일 편집 능력 Suite」에는 다양한 난이도의 파일 편집 태스크 20개가 포함됩니다.

Claude Code의 평가 발전 이야기

Dogfooding에서 체계적인 평가로

초기 내부 엔지니어의 일상적 사용(dogfooding)으로 피드백을 수집했습니다. "최근에 작성한 코드 품질이 지난주보다 낮은 것 같다" — 이런 직관은 유용하지만 정확하지 않고 확장할 수 없습니다.

첫 번째 단계 간결성과 파일 편집 eval을 추가했습니다. 드디어 "생성된 코드가 너무 장황한가?"와 "파일 편집이 정확한가?"를 수치화할 수 있게 되었습니다.

고급 단계 사용자들이 「과도한 엔지니어링」을 불평한다는 것을 발견하고, 전용 과도한 엔지니어링 eval을 추가했습니다: 간단한 태스크에서 Agent가 불필요한 복잡도를 도입하는지 측정합니다.

결과 평가가 팀이 개선 방향에 집중하도록 도왔습니다: 판단이 「어딘가 이상한 것 같다」에서 「간결성이 72점에서 85점으로 향상되었지만, 과도한 엔지니어링 지표가 3%에서 7%로 악화 — 롤백 필요」로 업그레이드되었습니다.

핵심 권장사항

20개부터 시작하세요

수백 개의 테스트 케이스가 생길 때까지 기다리지 마세요. 정밀하게 설계된 20개의 Task가 가장 핵심적인 시나리오를 커버할 수 있습니다. 핵심은 시작하는 것이며, 수량은 부차적입니다. eval 20개를 가진 팀은 eval이 0개지만 「500개를 계획 중인」 팀보다 한 시대 앞서 있습니다.

평가는 제품 이해의 수단이기도 합니다

eval 케이스를 작성하는 과정은 가장 어려운 제품 질문에 답하도록 강제합니다: 「사용자가 실제로 원하는 결과는 무엇인가?」「무엇이 좋고 무엇이 나쁜가?」「엣지 케이스는 어떻게 처리하는가?」 많은 팀이 eval을 작성하면서 오히려 오랫동안 모호했던 제품 정의를 명확히 하게 됩니다.

평가의 가치는 복리입니다: 초기에 투자한 모든 1분은 나중에 회귀 테스트, 모델 마이그레이션, 팀 협업에서 지속적으로 수익을 창출합니다. 시작하기 가장 좋은 시간은 3개월 전이었고, 두 번째로 좋은 시간은 지금입니다.