AI 코딩 에이전트 평가법: 벤치마크보다 먼저 만들 행동 테스트

AI 코딩 에이전트를 도입한 팀이 가장 자주 하는 실수는 최종 점수만 본다는 것이다. SWE-bench, Terminal-Bench, DeepSWE 같은 벤치마크 점수가 오르면 좋아 보이고, 떨어지면 불안하다. 문제는 점수가 왜 변했는지 모른다는 데 있다. 모델이 애매한 요구사항에서 질문을 안 했는지, 테스트를 실행하지 않았는지, 존재하지 않는 CLI 옵션을 만들었는지, 파일을 잘못 고쳤는지 분리해서 볼 수 없다. 그래서 실무에서는 거대한 벤치마크보다 행동 테스트가 먼저 필요하다.

Google Developers Blog의 harness engineering 글도 같은 방향을 말한다. end-to-end 벤치마크는 모델 성능을 넓게 보는 데 필요하지만, 프롬프트와 도구 스키마를 반복 개선하려면 작은 행동 단위의 평가가 더 빠르고 설명 가능하다. 개발팀이 당장 만들 수 있는 것은 “에이전트가 문제를 완전히 풀었는가”가 아니라 “풀기 전에 해야 할 행동을 했는가”를 확인하는 테스트다.

행동 테스트가 필요한 이유

코딩 에이전트는 일반 함수와 다르다. 같은 입력에도 다른 경로를 선택할 수 있고, 중간에 도구를 호출하고, 테스트를 실행하고, 파일을 수정한다. 최종 출력 문자열이 매번 조금씩 다른 것은 정상이다. 따라서 문자열이 정확히 일치하는지 보는 테스트는 쉽게 깨진다. 대신 관찰 가능한 행동을 봐야 한다.

예를 들어 “날씨가 어때?”라는 질문에 에이전트가 실시간 검색 도구를 썼는지 확인할 수 있다. “빌드 파일을 수정해 줘”라는 요청에는 수정 후 테스트 러너를 호출했는지 볼 수 있다. “이 저장소 README를 업데이트해 줘”라는 요청에는 canonical repository link를 넣었는지 검사할 수 있다. 최종 문장보다 도구 호출, 파일 변경, 검증 단계가 더 안정적인 평가 대상이다.

1단계: 최근 실패 하나를 테스트로 바꾼다

처음부터 거대한 eval suite를 만들 필요는 없다. 최근 에이전트가 실제로 저지른 실수 하나를 고른다. 예를 들어 에이전트가 코드를 수정하고 테스트를 안 돌린 채 “완료”라고 했다면, 첫 행동 테스트는 “코드 변경이 있으면 완료 전에 테스트 명령을 호출해야 한다”가 된다. 이 기준은 단순하지만 효과가 크다.

실패를 고를 때는 추상적인 문제보다 관찰 가능한 행동을 선택해야 한다. “더 신중해야 한다”는 테스트할 수 없다. “모호한 요구사항이면 수정 전에 한 번 이상 clarification을 요청해야 한다”는 테스트할 수 있다. “문서를 잘 써야 한다”도 애매하다. “새 public API를 추가하면 README 또는 docs에 사용 예시를 추가해야 한다”는 테스트할 수 있다.

2단계: strict assertion과 fuzzy assertion을 나눈다

모든 행동을 엄격한 순서로 묶으면 오히려 좋은 에이전트를 망친다. 단순 작업에는 strict assertion이 맞다. 예를 들어 “Python 파일을 수정했다면 pytest를 호출해야 한다”는 명확하다. “실시간 정보 질문에는 web search tool을 호출해야 한다”도 명확하다. 이런 테스트는 빠르고 결정적이어야 한다.

반대로 복잡한 리팩터링은 경로가 여러 개일 수 있다. 어떤 에이전트는 먼저 타입 에러를 확인하고, 다른 에이전트는 관련 파일을 읽은 뒤 테스트를 돌릴 수 있다. 둘 다 맞을 수 있다. 이때는 rigid tool sequence 대신 outcome-based check나 LLM-as-a-judge를 쓴다. 단, judge도 무제한 신뢰하면 안 된다. judge prompt에는 성공 기준, 금지 행동, 근거 인용 요구를 넣고, 샘플링 온도를 낮춰 변동성을 줄여야 한다.

3단계: CI에 바로 막지 말고 배치로 본다

AI 모델은 비결정성이 있다. 단일 테스트 실패를 바로 배포 차단으로 연결하면 개발 흐름이 불필요하게 막힐 수 있다. 초기에는 배치 평가로 추세를 보는 것이 낫다. 같은 테스트를 여러 작업 샘플에 돌리고 pass rate가 이전보다 좋아졌는지, 특정 실패 유형이 늘었는지 기록한다. 프롬프트 변경, 도구 설명 변경, 모델 업그레이드 전후를 비교하면 무엇이 회귀를 만들었는지 보인다.

물론 안전과 권한에 관련된 테스트는 예외다. 삭제, 배포, 결제, 외부 전송처럼 피해가 큰 행동은 단일 실패도 차단해야 한다. 예를 들어 “사용자 승인 없이 production deploy 도구를 호출하면 실패” 같은 테스트는 flaky하면 안 된다. 이런 테스트는 에이전트 평가가 아니라 제품 안전 장치에 가깝다.

행동 테스트 예시

실무에서 바로 만들 수 있는 테스트는 다음과 같다.

• 실시간 정보 질문에는 검색 또는 공식 문서 fetch 도구를 호출한다.
• 코드 수정 후 완료 선언 전에는 관련 테스트나 타입체크를 실행한다.
• 테스트가 실패하면 실패 로그 요약과 다음 액션을 남기고 성공으로 보고하지 않는다.
• 모호한 요구사항에서 데이터 삭제나 외부 전송이 걸리면 먼저 질문한다.
• 새 환경변수를 추가하면 문서와 예시 .env를 갱신한다.
• 마이그레이션을 만들면 rollback 또는 백업 전략을 설명한다.
• 존재하지 않는 CLI 옵션을 쓰지 않도록 --help나 공식 문서를 확인한다.

이런 테스트는 “에이전트가 똑똑한가”보다 “팀 규칙을 지키는가”를 본다. 실제 운영에서는 이쪽이 더 중요하다.

평가 로그를 설계하는 법

행동 테스트를 만들려면 먼저 로그가 있어야 한다. 에이전트가 어떤 메시지를 받았고, 어떤 도구를 어떤 인자로 호출했으며, 어떤 파일을 읽고 수정했는지 남겨야 한다. 가능하면 최종 답변만 저장하지 말고 tool call trace와 artifact diff를 따로 저장한다. 그래야 실패했을 때 “모델이 못 했다”가 아니라 “검색 도구 설명이 약했다”, “테스트 명령이 발견되지 않았다”, “권한 정책이 도구 레벨에서 막히지 않았다”처럼 원인을 나눌 수 있다.

개인정보와 보안도 같이 고려해야 한다. 로그에는 고객 데이터, 토큰, 내부 경로가 들어갈 수 있다. 평가용 샘플은 마스킹하고, 장기 보관할 필요가 없는 원문은 줄여야 한다. 특히 코딩 에이전트가 외부 저장소나 사내 티켓을 읽는다면 평가 로그 접근 권한을 개발팀 전체에 열어 두면 안 된다.

도입 체크리스트

• 최근 2주 안에 발생한 에이전트 실패 5개를 모은다.
• 각 실패를 “관찰 가능한 행동” 하나로 바꾼다.
• strict assertion과 fuzzy assertion을 분리한다.
• 도구 호출, 파일 diff, 테스트 결과를 평가 로그로 저장한다.
• 모델 업그레이드 전후 같은 eval set을 배치로 돌린다.
• 안전 관련 테스트는 단일 실패도 차단한다.
• 점수보다 실패 유형과 회귀 원인을 주간 리포트로 본다.

결론

AI 코딩 에이전트는 벤치마크 점수가 아니라 반복 가능한 행동으로 관리해야 한다. 큰 벤치마크는 방향을 보여 주지만, 팀이 매일 고치는 것은 작은 실패다. 테스트를 안 돌리는 습관, 모호한 요구사항에서 추측하는 습관, 존재하지 않는 명령을 만드는 습관을 행동 테스트로 잡아야 한다. 에이전트를 블랙박스 시험 응시자로 보지 말고, 테스트 가능한 소프트웨어 시스템으로 다루는 순간 운영 품질이 올라간다.

핵심 출처

• Google Developers Blog, The Anatomy of Harness Engineering: How to Evaluate, Iterate, and Guard AI Coding Agents