AI 에이전트 평가에서 문자열 매칭이 거짓 준수를 보상하는 문제와 직접 검증의 필요성

문자열 매칭 평가의 구조적 결함

AI 코딩 에이전트 평가에서 string contains 방식은 빠르고 저렴하지만, 실제 코드 실행이나 빌드 성공 여부와 무관하게 문자열의 존재 여부만 확인하므로 **거짓 준수(false assurance)**를 유발할 수 있다. 주석, 데드 코드, 미사용 의존성 등에서도 해당 기술 이름이 발견되어 평가 통과가 가능하기 때문이다. 반대로 문자열이 없다고 해서 해당 기술을 사용하지 않은 것도 아니다. 이는 평가가 관측한 사실(문자열 존재)과 실제 기능 구현 여부를 혼동하게 만든다.

LLM Judge의 한계와 직접 검증 원칙

LLM judge는 시맨틱한 기준을 구분하는 데 유용하지만, 컴파일 성공이나 의존성 복원 같은 결정적(deterministic) 속성을 검증할 수 없다. LLM judge에서 만점을 받은 코드가 실제로는 컴파일 실패하는 사례가 존재한다. 따라서 빌드 가능 여부는 컴파일러로, JSON 유효성은 schema validation으로, 앱 동작은 실제 실행으로 검증해야 한다. LLM judge는 이러한 결정적 도구들을 대체할 수 없으며, 시맨틱 질문과 결정적 질문에 각각 적절한 도구를 사용해야 한다.

신뢰할 수 있는 Agentic Eval 설계

에이전트 능력 평가는 유닛 테스트가 아닌 **통합 테스트(integration tests)**로 취급되어야 한다. 빌드(build), 테스트(test), 실행(run), 배포(deploy)를 분리된 게이트로 설정하고, 각 단계의 실패 원인을 명확히 구분해야 한다. 평가자는 '이 평가가 통과하면 무엇을 확실히 알 수 있는가?'라는 질문을 통해 평가 지표가 주장하는 내용을 실제로 뒷받침하는지 검증해야 하며, 전체 실행이 불가능한 경우 평가가 확립한 것과 확립하지 못한 것을 명확히 보고해야 한다.