AI 코딩 에이전트 평가 하네스: SWE-bench보다 먼저 만들 로컬 테스트 설계법

요약: Google Developers Blog는 2026년 9월 “Harness Engineering” 글에서 AI 코딩 에이전트 평가를 end-to-end 벤치마크에만 맡기지 말고, 빠른 로컬 행동 평가를 함께 만들라고 설명했습니다. 실무팀에는 이 접근이 훨씬 중요합니다. 코딩 에이전트는 최종 정답보다 중간 행동이 제품 품질을 좌우하기 때문입니다.

왜 SWE-bench 점수만 보면 부족한가

SWE-bench 같은 벤치마크는 모델이나 에이전트의 대략적인 문제 해결 능력을 비교하는 데 유용합니다. 하지만 팀 레포에 코딩 에이전트를 붙이는 순간 문제는 달라집니다. 우리 코드베이스의 모듈 구조, 테스트 관행, 브랜치 전략, 리뷰 규칙, 금지된 패턴을 지키는지가 더 중요합니다.

예를 들어 어떤 에이전트가 공개 벤치마크에서 높은 점수를 받았다고 해도, 우리 팀에서 다음 행동을 하면 운영에는 부적합합니다.

• 기존 유틸 함수를 재사용하지 않고 새 함수를 중복 작성한다.
• 테스트를 수정해서 실패를 숨긴다.
• 마이그레이션 없이 DB 필드를 바꾼다.
• 보안 관련 코드를 프롬프트 설명만 믿고 우회한다.
• 작은 버그 수정에 대규모 리팩터링을 섞는다.

이런 문제는 최종 diff만 봐도 잡히지만 늦습니다. 코딩 에이전트가 어떤 파일을 먼저 읽었는지, 어떤 명령을 실행했는지, 어떤 테스트를 선택했는지 같은 중간 행동을 평가해야 빨리 개선됩니다.

하네스 엔지니어링의 핵심

Google 글의 핵심은 behavioral evaluation입니다. 최종 문자열이 맞는지 보는 대신, 에이전트가 특정 도구 호출, 파일 수정, 검증 단계를 올바르게 수행했는지 확인하는 작은 테스트를 많이 두는 방식입니다. 단위 테스트처럼 빠르고, 실패 원인이 선명해야 합니다.

코딩 에이전트 하네스는 보통 네 층으로 나눌 수 있습니다.

첫째, 환경 준비입니다. 레포를 특정 커밋으로 체크아웃하고, 의존성을 설치하고, 테스트 DB나 mock 서버를 준비합니다. 이 단계가 흔들리면 평가 결과를 믿을 수 없습니다.

둘째, 작업 입력입니다. 에이전트에게 이슈 설명, 재현 로그, 제한 사항을 줍니다. 실제 티켓처럼 모호함을 조금 남겨두되, 평가하려는 행동은 명확해야 합니다.

셋째, 행동 추적입니다. 읽은 파일, 실행한 명령, 수정한 파일, 테스트 결과, tool call 순서를 기록합니다.

넷째, 판정입니다. 최종 테스트 통과 여부뿐 아니라 금지 파일 수정 여부, 필수 파일 확인 여부, 테스트 추가 여부, diff 크기, 위험 패턴 포함 여부를 함께 봅니다.

처음 만들 평가 10개

처음부터 거대한 벤치마크를 만들 필요는 없습니다. 실제로 팀이 자주 겪는 실패 유형 10개를 고르는 것이 낫습니다.

1. 기존 함수 재사용 평가: 특정 버그를 고칠 때 이미 있는 helper를 읽고 사용하는지 확인합니다.
2. 테스트 추가 평가: 기능 수정 후 관련 테스트 파일을 추가하거나 갱신하는지 확인합니다.
3. 금지 파일 보호 평가: generated file, lockfile, 마이그레이션 파일을 불필요하게 건드리지 않는지 봅니다.
4. 최소 diff 평가: 작은 버그 수정에서 대규모 포맷팅을 섞지 않는지 봅니다.
5. 권한 체크 평가: API route 수정 시 인증/인가 미들웨어를 유지하는지 봅니다.
6. 회귀 테스트 평가: 실패 재현 테스트를 먼저 만들거나 최소한 실행하는지 봅니다.
7. 문서 참조 평가: 팀 규칙 문서나 README를 읽고 반영하는지 봅니다.
8. 명령 선택 평가: 전체 빌드 대신 관련 테스트부터 실행하는지 봅니다.
9. 에러 처리 평가: 실패 로그를 보고 재시도 전략을 바꾸는지 봅니다.
10. 중단 조건 평가: 불확실한 destructive 변경에서 사람에게 확인을 요청하는지 봅니다.

이 10개는 모델 성능보다 팀 적합성을 보여줍니다. 특히 사내 레포에 코딩 에이전트를 붙일 때는 “잘 고치는가”보다 “팀 규칙을 깨지 않는가”가 먼저입니다.

평가 케이스는 어떻게 작성하나

좋은 평가 케이스는 작고 재현 가능해야 합니다. 한 케이스에 여러 능력을 섞으면 실패 원인을 알 수 없습니다. 예를 들어 “로그인 버그를 고치고 테스트도 추가하고 리팩터링도 하라”는 평가는 너무 큽니다. 대신 “만료된 세션에서 500이 아니라 401을 반환하라. 기존 auth middleware를 유지하라. 관련 테스트 1개를 추가하라”처럼 좁혀야 합니다.

판정도 자동화 가능한 항목과 사람이 봐야 하는 항목을 나눠야 합니다. 자동 판정은 다음처럼 만들 수 있습니다.

• 특정 테스트 명령이 통과했는가
• 수정 파일 수가 5개 이하인가
• 금지 경로가 수정되지 않았는가
• 특정 함수 호출이 diff에 포함됐는가
• 보안 미들웨어가 제거되지 않았는가
• package.json 변경이 없는가

사람 평가가 필요한 항목은 별도로 샘플링합니다. 코드 가독성, 설계 적합성, 도메인 판단은 자동 점수만으로 부족합니다. 다만 사람 평가는 전체 케이스의 10~20%만 해도 패턴을 잡을 수 있습니다.

프롬프트 개선보다 평가 고정이 먼저다

많은 팀이 에이전트가 실패하면 system prompt부터 고칩니다. 하지만 평가 세트가 없으면 개선인지 우연인지 알 수 없습니다. 오늘은 좋아졌는데 내일 모델 버전이 바뀌면 다시 깨질 수 있습니다.

순서는 반대여야 합니다. 먼저 실패 케이스를 고정합니다. 그다음 프롬프트, tool description, 파일 검색 전략, 테스트 명령 전략을 바꿉니다. 마지막으로 같은 평가 세트를 돌려 개선 폭과 회귀를 봅니다.

특히 코딩 에이전트는 prompt만으로 통제하기 어렵습니다. 도구 설계가 더 중요할 때가 많습니다. 예를 들어 에이전트가 자꾸 전체 레포를 포맷팅한다면 “포맷팅하지 마”라고 쓰는 것보다, format command를 제한하거나 diff guard를 추가하는 편이 확실합니다.

운영 지표는 이렇게 본다

하네스 점수만으로 배포 여부를 결정하지 마세요. 실제 운영 지표도 함께 봐야 합니다.

• 평균 수정 시간
• 사람이 리뷰에서 되돌린 비율
• 테스트 없이 머지된 비율
• 같은 이슈 재오픈 비율
• 변경 파일 수 중앙값
• 모델 호출 비용
• 실패 후 사람 개입까지 걸린 시간

이 지표가 좋아져야 코딩 에이전트가 팀에 도움이 됩니다. 단순히 “자동 PR 수”가 늘어나는 것은 목표가 아닙니다. 잘못된 PR이 늘면 리뷰어 시간이 더 많이 들어갑니다.

실행 체크리스트

• 공개 벤치마크 점수와 별도로 사내 레포 평가 세트를 만든다.
• 자주 발생한 에이전트 실패 유형 10개를 먼저 고른다.
• 각 케이스를 작은 티켓 형태로 작성한다.
• 읽은 파일, 실행 명령, 수정 파일, 테스트 결과를 구조화 로그로 남긴다.
• 최종 테스트 통과뿐 아니라 금지 파일 수정, diff 크기, 필수 함수 사용을 판정한다.
• 프롬프트를 고치기 전에 평가 세트를 고정한다.
• 모델 업그레이드 전후 같은 하네스를 돌려 회귀를 확인한다.
• 자동 평가와 사람 샘플 리뷰를 함께 운영한다.

AI 코딩 에이전트의 품질은 모델 이름보다 하네스가 결정합니다. 좋은 하네스는 에이전트를 통제하는 장치이자 팀의 개발 문화를 기계가 이해할 수 있게 만든 문서입니다.