믿을 수 있는 AI 평가 설계하기 — 구글 팀이 정리한 다섯 가지 규칙

How to Design AI Evaluations You Can Actually Trust

As part of my work at Google, we are publishing a suite of Agent Skills for Google products and...

Jan-Felix Schmakeit2026-09-01

개요 #

구글이 자사 제품과 기술을 위한 Agent Skills 모음을 GitHub에 공개하고 있다. AI 에이전트가 구글 기술을 다룰 때 참고하는 스킬 묶음이다. 문제는 그다음이다. 이 스킬이 실제로 쓸모가 있는지, 의도대로 동작하는지 어떻게 확인할까.

구글 개발자 관계팀의 얀펠릭스 슈마카이트(Jan-Felix Schmakeit)는 이 질문에 매달린 과정을 정리해 공개했다. 스킬을 개선하려면 성능에 대한 믿을 만한 신호가 먼저 있어야 하기 때문이다. 그가 내놓은 결론은 다섯 가지 규칙으로 압축된다.

핵심 전제는 단순하다. 단위 테스트 없이 프로덕션 API를 배포하지 않듯, AI 에이전트에도 같은 기준을 적용하라는 것이다. 터미널에서 감으로 두드려 보는 "vibe testing" 수준을 벗어나, 구조화된 자동 평가 파이프라인을 세팅해야 한다.

왜 평가 설계가 중요한가 #

AI 평가에는 진짜 토큰 비용이 든다. 잘못 설계한 평가는 세 가지를 동시에 망친다. 거짓 신호를 주고, 토큰 예산을 태우고, 지표에 잡음을 남긴다. 슈마카이트가 규칙을 정리한 이유도 여기에 있다. 토큰을 쓴 만큼 쓸 만한 지표가 남게 하자는 것이다.

용어 정리도 해두자. 평가(eval)는 에이전트에게 시킨 행동이고, 스코어러(rubric 등)는 그 행동이 성공했는지 판정하는 장치다. 이 글은 앞쪽, 즉 평가 설계에 집중한다. 채점 루브릭 작성법은 후속 글에서 다룬다고 예고했다.

노트를 정리하며 기준을 세우는 모습 Photo by Pavel Danilyuk on Pexels

규칙 1. 평가 환경부터 파악하라 #

평가를 쓰기 전에 자기가 쓸 프레임워크의 구조와 한계를 알아야 한다. Harbor, Inspect AI, 혹은 Agent Development Kit 같은 개발 도구 내장 기능이 여기 해당한다. 일회성 샌드박스를 쓰는지, 어떤 툴을 쓸 수 있는지, 출력은 어떻게 캡처되는지 확인하라는 것이다.

채점기를 환경에 맞춰라. 샌드박스에 결정론적으로 접근해 코드를 검증할 수 있다면 그 방법을 쓴다. 아니면 에이전트에게 응답을 콘솔에 출력하게 하고, 프레임워크가 그 출력을 잡아 스코어러에 넘기게 한다.
의존성 한계와 "실제" 리소스 접근을 따져라. 인증된 gcloud 세션처럼 실제 리소스가 필요한 과제라면, 다른 평가에 영향을 주지 않도록 격리·제한된 임시 리소스나 자격 증명을 만든다. 아니면 실제 테스트 자격 증명 대신 목(mock) 툴을 준다.
격리가 어려우면 계획을 평가하라. 실행 자체를 검증하기 까다로우면 과제를 수행할 계획을 평가하는 쪽이 낫다.
대화형 프롬프트를 피하라. 멀티턴 세션은 평가가 복잡해진다. 시작 단계에서는 원샷 프롬프트로 설계한다.

규칙 2. 천장 효과를 피하라 #

도구 없이도 기준 정확도가 높게 나온다면, 그 평가는 도구의 가치를 증명하지 못한다. 프롬프트가 너무 쉬웠을 가능성도 크다.

더 어려운 프롬프트를 써라. 베이스 모델이 이미 답을 아는 문제로는 새 툴이나 스킬의 효과를 잴 수 없다.
다단계 추론을 요구하라. 사전학습만으로 해결되지 않는, 복잡한 실무 시나리오를 반영한 프롬프트를 설계한다.
툴의 범위 자체를 재검토하라. 툴을 쓰지 않아도 정확도가 계속 높게 나온다면 그것도 하나의 신호다. 모델과 에이전트가 그사이 좋아져서 도움 없이도 해내는 상황일 수 있다. 방향을 틀거나 툴을 접을 시점이다.

규칙 3. 프롬프트와 채점기를 어긋나게 두지 마라 #

시키지 않은 일로 에이전트를 감점할 수는 없다. 프롬프트와 채점기는 서로 맞물려야 하고, 프롬프트에 담긴 것만 검증해야 한다.

범위가 새지 않게 하라. "Google Cloud Run은 어떻게 보안 설정하나요?" 처럼 넓게 물어놓고, 언급도 안 한 특정 IAM 역할이 빠졌다고 감점하면 안 된다. 넓게 물으면 넓은 답이 온다.
명시적으로 써라. 특정 지식이나 정확한 구현 세부를 보고 싶다면 그 요구사항을 프롬프트에 분명히 적어야 한다.

규칙 4. 과정이 아니라 결과를 채점하라 #

에이전트는 자체 지식만으로 정답에 도달하면서 커스텀 툴을 건너뛸 수 있다. 슈마카이트는 그 사실 자체도 유용한 피드백이라고 짚는다.

경로(trajectory)를 평가하지 마라. 에이전트가 특정 help 명령을 썼는지, 정해진 순서를 따랐는지 확인하는 채점기는 피한다.
최종 답을 평가하라. 객관적 결과물로 채점한다. 굳이 계획 단계를 봐야 한다면, 상세 실행 계획을 출력하라고 명시적으로 요청한 뒤 그 계획을 평가한다.

규칙 5. 평가 데이터셋을 큐레이션하라 #

좋은 평가 묶음은 실제적이고 다양한 사용 사례를 다룬다. 반대로 같은 능력을 반복 검증하면 과적합이 생기고 지표에 잡음이 낀다.

실제 사례를 써라. 사용자가 달성하려는 목표와 실제 여정을 담는다. 정제된 샘플 데이터 같은 맥락을 함께 넣어 평가를 현실에 붙들어 두는 것도 방법이다.
신호를 극대화하라. 프롬프트 하나하나가 서로 다른 개념이나 고유한 능력을 검증하게 만든다. 전통적 테스트의 코드 커버리지를 떠올리면 된다.
중복을 걷어내라. 겹치는 프롬프트는 합친다. 작고 잘 다듬은 데이터셋이 더 선명한 지표를 주고, 과적합을 막고, 토큰도 아낀다.

정리 #

정확히 측정하지 못하면 AI 툴도 개선할 수 없다. AI 평가를 단위 테스트만큼 진지하게 다루면 지표의 품질이 올라가고 신호도 훨씬 단단해진다는 게 글의 결론이다.

다섯 가지 규칙을 적용하면 토큰 예산을 갉아먹던 거짓 신호가 걷힌다. 잡음 대신 엔지니어링 판단에 바로 쓸 수 있는 피드백이 남는다.

무엇을 테스트할지 정하는 건 첫 단계일 뿐이다. 잘 설계한 평가도 채점하는 스코어러가 부실하면 소용이 없다. 슈마카이트는 다음 글에서 어떻게 테스트할지, LLM 채점기의 모호함을 줄이는 간결하고 원자적인 루브릭 작성법을 다루겠다고 밝혔다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.