에이전트 플러그인 빌드를 통해 배운 4가지 평가 엔지니어링 교훈

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

에이전트형 시스템을 빌드할 때의 진정한 과제는 시스템을 만드는 것 자체가 아니라 측정하는 일입니다. 

평가 엔지니어링은 신뢰할 수 있는 AI 시스템을 빌드하기 위한 중요한 기반입니다. 에이전트의 실제 동작을 측정하기 위해 체계적이고 반복 가능한 테스트를 설정하는 것은 신뢰할 수 있는 도구를 출시하느냐 아니면 소리 없이 중단되거나 API 호출에 실패하거나 실수를 하는 도구를 내놓느냐를 결정짓는 차이가 될 수 있습니다. 

저는 Google에서 수년간 평가 엔지니어링 이니셔티브를 이끌어 왔습니다. 이번에 새로 출시된  Google Cloud Developer 플러그인 개발 과정은 실제 개발자 워크플로 전반에서 이러한 핵심 원칙들을 스트레스 테스트해 볼 수 있는 실시간 테스트베드 역할을 했습니다.

새로운 플러그인을 빌드하면서 얻은 4가지 평가 교훈을 소개합니다. 이 교훈을 여러분의 빌드에 적용해 보세요.

1. 요약 대신 실행 단계 평가

에이전트를 처음 평가할 때 LLM-as-a-judge를 설정하여 에이전트의 최종 텍스트 대답을 검사하고 체크리스트를 기준으로 점수를 매겼습니다. 하지만 평가자는 에이전트가 실제로 수행한 작업이 아니라 작성한 내용만 볼 수 있기 때문에, 이러한 방식에는 근본적인 결함이 있다는 사실을 금방 깨달았습니다. Google Cloud Developer 플러그인을 위해 초기 11개 프롬프트로 구성된 평가 세트를 실행했을 때, 자동 채점기는 3개의 프롬프트에서 실패한 것으로 판정했습니다. 하지만 원시 도구 호출 로그를 열고 스크립트를 읽어 보니 플러그인이 실제로 3가지 항목을 모두 통과한 상태였습니다. 예를 들어 Cloud Run 정리 프롬프트의 경우, 기준표에 따라 실제 작업을 수행하기 전에 명령어 문법이 올바른지 먼지 확인해야 했습니다. 에이전트는 가장 먼저 gcloud help run services list를 실행했습니다. 에이전트는 작업을 제대로 수행했지만, 최종 메시지에서는 도움말 문서를 확인했다는 사실을 언급하는 대신 사용자에게 영구적인 데이터 손실 가능성을 경고하는 데 집중했습니다.

평가자는 에이전트가 요약에서 성과를 자랑하지 않았다는 이유만으로 할 일을 제대로 수행한 에이전트에게 불이익을 주었습니다. 기준표에 'X를 실행했나요?'라는 항목이 있더라도, 실제 도구 호출 궤적을 평가하지 않는다면 LLM 심사자는 추측에 의존할 수밖에 없습니다.

핵심 요약: 에이전트의 마지막 답변 내용만 보고 성능을 평가하지 마세요. 원시 실행 궤적을 평가하여 실제로 어떤 명령어가 실행, 검증, 범위 지정되었는지 확인합니다.

2. 비동기 작업을 위한 평가 설계

도구 호출 궤적을 분석할 때는 무엇을 읽느냐 못지않게 원격 분석 데이터를 어떻게 추출하느냐가 중요합니다. 에이전트 원격 분석 데이터를 평면화된 순차적 이벤트 목록으로 추출하면 도구의 동시 디스패치가 가려지게 되는데, 이는 동작 실패의 주요 원인 중 하나입니다. 최신 에이전트 하네스는 호출 배열을 사용하여 여러 도구 호출을 단일 어시스턴트 턴으로 묶어 일괄 처리하는 경우가 많습니다.

평가에서 에이전트가 환경을 검사하고 문서를 조회하도록 요청받았을 때, 하네스는 단일 tool_calls 페이로드 내에서 스킬 로드 호출과 두 개의 문서 검색을 동시에 디스패치했습니다. 스킬 활성화는 다단계 프로세스로 이루어집니다. 초기 호출에서는 짧은 실행 스텁만 반환되고 이후 차례에서 전체 요청 사항 본문이 삽입되므로, 검색을 제어해야 할 요청 사항이 시스템에서 이미 검색을 실행한 후에야 프롬프트 컨텍스트에 도달하게 됩니다.

시스템은 스킬에 전용 차례를 부여하지 않아 스킬의 안내가 에이전트의 행동에 영향을 미치지 못했습니다. 원격 분석 파이프라인이 턴 구조를 제거하고 호출을 평면 타임라인으로 병합하면 엔지니어는 개발자가 스킬에 삽입한 명확한 요청 사항을 에이전트가 왜 무시했는지 파악하느라 며칠씩 시간을 허비하게 될 것입니다.

핵심 내용: 원격 분석 추출기에서 턴 구조를 유지해야 삽입된 안내가 컨텍스트 윈도우에 반영되기 전에 클라이언트 측의 병렬 디스패치가 도구 호출을 먼저 실행하는 문제를 파악할 수 있습니다. 

3. 실시간 실행과 '드라이 런'을 나란히 테스트

병렬 디스패치와 같은 하네스 특유의 문제를 파악하려면 실제 API 호출을 면밀히 검사해야 합니다. 하지만 한 가지 환경 조건에서만 에이전트를 테스트한다면 반쪽짜리 테스트에 불과합니다. 첫날부터 실시간 실행과 계획 전용 실행이라는 두 가지 조건을 나란히 실행해야 합니다. 실제 조건에서 에이전트는 실제 샌드박스 처리된 사용자 인증 정보를 가지고 실제로 명령어를 실행합니다. 이를 통해 문법이 작동하는지, 파라미터가 깔끔하게 직렬화되는지, 에이전트가 파괴적인 작업을 수행하기 전에 제약을 가하는지 확인할 수 있습니다. 

실시간 실행은 2단계에서 예기치 않은 권한 오류가 자주 발생하며 테스트하려는 동작에 도달하기 전에 중단됩니다. 따라서 사용자 인증 정보를 삭제하고 에이전트에게 아무것도 실행하지 않고 무엇을 할 것인지 설명하도록 지시하는 계획 전용 조건이 필요합니다. 이렇게 하면 권한 문제라는 걸림돌이 사라져 모델의 순수한 추론 및 라우팅 의도를 명확히 파악할 수 있습니다. 가장 중요한 발견의 절반 정도는 두 실행 방식의 차이에서 얻은 결과였습니다.

예를 들어 온보딩 프롬프트 중 하나에서 프로젝트 목록 호출 시 실시간 실행이 즉시 차단되었습니다. 계획 전용 실행은 순조롭게 진행되어 조직 정책, 관리자 승인, 거버넌스를 완전히 무시하는 8,000자 분량의 계획을 생성했습니다. 실시간 실행에서는 드러나지 않았던 중대한 인지적 결함이 계획 전용 실행에서는 단 몇 초 만에 밝혀졌습니다.

핵심 내용: 실시간 평가와 계획 전용 평가를 나란히 실행합니다. 실시간 실행은 실제 실행 결과와 안전 제약 사항을 테스트하는 데 쓰이며, 계획 전용 실행은 권한 오류에 가로막히지 않고 모델 고유의 추론 능력과 라우팅 의도를 파악하는 데 유용합니다.

4. '골든 세트'를 지속 가능한 기준으로 사용

프런티어 모델 아키텍처는 몇 달 주기로 바뀌고, 에이전트 하네스는 계속해서 개선되며, 플러그인 매니페스트 표준 또한 필연적으로 진화할 것입니다. Google Cloud Developer 플러그인을 빌드할 때, Google은 이러한 비결정적 환경에 대한 평가를 지속적 통합 테스트의 일환으로 간주했습니다. 즉, 하네스, 라이브 모델, 도구가 실제 작업 환경에서 함께 작동하는 복합 스택 전체를 대상으로 스트레스 테스트를 진행했다는 의미입니다.

이 접근 방식은 최종 텍스트 출력만 보고 결과를 추측하는 대신, 에이전트의 사고 과정부터 실제 실행 명령어, 시스템을 망가뜨리지 않고 문제를 해결했는지 여부까지 전체 실행 궤적을 파악합니다. 그런 다음 이상적인 경로가 무엇인지 숙지하고 있는 실제 전문가가 선별한 '골든 세트'를 기준으로 해당 실행 결과의 점수를 매깁니다.

핵심 요약: 하네스, 모델, 플러그인을 포함한 전체 시스템이 실제 현장에서 어떻게 작동해야 하는지를 기준으로 골든 세트를 빌드합니다. 모델은 계속해서 변하지만 이러한 기준 실행은 안전망 역할을 합니다.

알림: '원샷' 데모 대신 평가 세트를 활용해야 합니다.

엔지니어들이 흔히 저지르는 실수는 제가 이른바 원샷 데모라고 부르는 방식입니다. 이는 누군가 LLM에 프롬프트를 입력하고, LLM이 완전한 3D 게임을 빌드하거나 루빅 큐브를 한 번에 맞추는 것을 지켜본 후 평가라고 부르는 경우를 말합니다. 하지만 실제로는 허황된 측정항목일 뿐입니다. 

AI로 수준 높은 결과물을 만들어내려면, 평가 세트가 필요하다고 생각합니다. 평가가 없으면 팀은 말 그대로 어두운 동굴 속을 눈을 가리고 달리는 것과 같습니다. 엔터프라이즈급 에이전트를 엔지니어링한다는 것은 다단계 상호작용을 처리하고, 권한을 관리하며, '비용 절감 기회를 찾아줘'라는 요청에 따라 실수로 프로젝트를 삭제하는 것과 같은 파괴적인 결과를 방지하는 시스템의 능력을 테스트하는 것을 의미합니다.

다음 단계

에이전트 플러그인이나 MCP 서버를 빌드하는 것은 단지 시작일 뿐입니다. 실제 클라우드 인프라에서 신뢰할 수 있는 무언가를 제공하려면, 모델이 예상대로 작동하는지 확인하기 위한 훨씬 더 심도 있는 평가 작업이 필요합니다. 결국 모델의 급격한 변화 속에서도 변치 않는 가치를 지니는 것은 스트레스 테스트를 거친 평가 제품군입니다. Google Cloud Developer 플러그인 문서를 확인하거나 이 Codelab을 살펴보고 Antigravity에서 플러그인을 시작하세요.