AI 코딩 에이전트의 결과를 믿지 말고 패치로 평가하는 법
AI 코딩 에이전트에게 “완료했습니다”라는 말을 듣는 것과, 안전하게 병합할 수 있는 패치를 얻는 것은 다른 일입니다. 전자는 대화의 상태이고 후자는 검증 가능한 산출물입니다.
이 글의 결론은 단순합니다. 에이전트를 평가할 때 모델의 자신감이나 벤치마크 점수부터 보지 말고, 하나의 요청을 재현 가능한 패치 평가 task로 바꾸세요. 명세가 충분한지, 새 요구사항을 만족하는지, 기존 동작을 깨지 않았는지, diff가 요청 범위를 넘지 않았는지를 함께 판정하는 방식입니다.
패치 하나에 네 가지 신호를 붙이기
첫째는 명세입니다. “검색 속도를 개선해 줘”는 평가 task가 아닙니다. 입력, 허용된 변경 범위, 완료 조건, 금지된 부작용을 적어야 합니다. 두 사람이 같은 패치를 보고 같은 pass/fail 결론을 낼 수 있어야 합니다.
둘째는 fail-to-pass입니다. 작업 전에는 실패하고 올바른 패치 뒤에는 통과해야 하는 테스트입니다. 셋째는 pass-to-pass입니다. 원래 통과하던 핵심 회귀 테스트가 계속 통과하는지 확인합니다. OpenAI가 SWE-bench 설명에서 두 종류의 테스트를 구분한 이유도 여기에 있습니다. 새 기능을 고쳤다는 사실만으로 기존 기능 보존까지 증명되지는 않습니다.
넷째는 diff입니다. 테스트가 통과해도 요청하지 않은 파일을 바꿨거나, 임시 우회·삭제·의존성 추가가 들어갔다면 사람의 판단이 필요합니다. 코드 기반 grader는 결과를 빠르게 걸러내지만, 범위와 설계 의도는 diff review가 더 잘 보여 줍니다.
최소 평가 task의 모양
아래처럼 task를 저장하면 Codex, Cursor, CI 스크립트 어느 쪽에서도 같은 계약을 재사용할 수 있습니다.
id: normalize-email-whitespace
request: "로그인 이메일의 앞뒤 공백을 제거한다"
allowed_paths:
- src/auth/email.ts
- tests/auth/email.test.ts
fail_to_pass:
- trims leading and trailing whitespace before validation
pass_to_pass:
- rejects an empty email
- rejects an invalid email
constraints:
- do not change the database schema
- do not add a dependency
- report the final diff and test command
여기서 중요한 것은 테스트 이름을 많이 쓰는 일이 아닙니다. 에이전트가 합리적으로 추론할 수 없는 조건을 숨은 채점 기준으로 만들지 않는 일입니다. OpenAI의 2026년 코딩 평가 감사도 과도하게 엄격한 테스트, 불충분한 프롬프트, 낮은 커버리지 같은 task 품질 문제를 지적합니다. 0% 통과가 반복될 때 모델 탓을 하기 전에 task와 grader가 공정한지 확인해야 합니다.
capability와 regression은 목적이 다르다
Anthropic은 capability eval과 regression eval을 구분합니다. capability eval은 에이전트가 아직 잘하지 못하는 일을 골라 개선 여지를 만드는 평가이고, regression eval은 이미 되던 일을 계속하는지 지키는 평가입니다.
실무에서는 다음 순서가 적당합니다.
- 실제 버그·지원 티켓·수동 점검에서 10~20개의 task를 뽑습니다.
- 각 task에 재현 fixture와 사람이 확인한 reference solution을 둡니다.
- 에이전트가 보지 못한 fail-to-pass 테스트와 기존 pass-to-pass 테스트를 분리합니다.
- 같은 task를 여러 번 실행해 한 번의 행운과 일관된 능력을 구분합니다.
- 실패 transcript와 diff를 읽어 grader 오류와 에이전트 오류를 분류합니다.
- 해결된 capability task는 regression suite로 승격하고, 새로 어려운 task를 추가합니다.
한 번 통과한 task를 영구적인 증거로 취급하면 안 됩니다. 모델, 프롬프트, 도구, 의존성이 바뀌면 다시 실행해야 합니다. 반대로 공개 벤치마크의 단일 숫자를 제품 품질의 대리값으로 쓰는 것도 위험합니다. SWE-bench Verified의 오염과 평가 적합성에 대한 OpenAI의 후속 분석은 “평가도 테스트해야 한다”는 점을 보여 줍니다.
점수는 한 숫자로 뭉개지 말기
간단한 내부 점수는 다음처럼 분리할 수 있습니다.
task_pass = fail_to_pass 통과 AND pass_to_pass 통과
scope_pass = 허용 경로 밖 변경 없음
review_pass = 치명적 보안·삭제·우회 없음
release_gate = task_pass AND scope_pass AND review_pass
여러 grader를 합칠 때도 “테스트 90점”이 “범위 위반”을 상쇄하지 않도록 핵심 조건은 binary gate로 두는 편이 낫습니다. OpenAI Graders API는 문자열 비교·유사도·multi-grader 같은 조합을 지원하지만, 어떤 grader를 선택할지는 제품의 실패 비용에 달려 있습니다. 모델 grader는 설명 품질이나 지시 준수에 유용할 수 있어도, 보안·금전·삭제처럼 중요한 판정은 코드 검사와 사람 검토를 남겨 두세요.
Codex나 Cursor에서 바로 쓰는 프롬프트
먼저 이 task의 성공 조건과 허용 경로를 요약하라.
수정 전에 관련 구현과 테스트를 읽고, 새 테스트가 무엇을 증명하는지 설명하라.
fail-to-pass 테스트와 기존 pass-to-pass 테스트를 각각 실행하라.
테스트가 통과해도 diff에서 범위 밖 파일, 의존성 추가, 우회 로직을 검사하라.
실패하면 원인을 task/환경/구현 중 하나로 분류하고 멈춰라.
마지막 보고에는 변경 파일, 실행한 명령, 각 테스트 결과, 남은 불확실성을 포함하라.
이 프롬프트의 핵심은 에이전트에게 더 많이 생각하라고 말하는 것이 아니라, 결과를 판정할 증거의 형식을 고정하는 데 있습니다. 저장소의 AGENTS.md나 프로젝트 규칙을 쓰더라도 평가 계약을 대신할 수는 없습니다. 규칙은 행동의 방향을 주고, task와 grader는 결과의 합격 여부를 결정합니다.
시니어 엔지니어의 트레이드오프
패치 평가에는 비용이 있습니다. fixture를 만들고, 테스트를 유지하고, transcript를 읽는 시간이 필요합니다. 모든 사소한 스타일 변경에 같은 수준의 평가를 적용하면 팀이 느려집니다. 반대로 인증·결제·데이터 마이그레이션처럼 실패 비용이 큰 변경에는 작은 평가셋조차 부족할 수 있습니다.
그래서 위험도에 따라 층을 나누는 것이 현실적입니다. 저위험 변경은 좁은 테스트와 diff 확인, 중간 위험 변경은 회귀 묶음과 다중 실행, 고위험 변경은 격리 환경·보안 검사·사람 승인까지 요구합니다. 에이전트의 자율성을 줄이는 것이 목표가 아니라, 실패했을 때 되돌릴 수 있는 경로를 평가 설계 안에 넣는 것이 목표입니다.
FAQ
Q. 테스트가 통과하면 충분한가요?
A. 아닙니다. 새 요구사항과 회귀를 함께 보고, diff가 범위를 지켰는지 확인해야 합니다.
Q. task를 몇 개부터 시작해야 하나요?
A. 팀이 매번 수동으로 확인하는 실제 작업 10개 정도면 시작할 수 있습니다. 숫자보다 대표성과 실패 원인 기록이 중요합니다.
Q. LLM judge를 쓰면 사람 검토가 필요 없나요?
A. 아닙니다. Anthropic도 code-based, model-based, human grader의 조합과 transcript 검토를 권합니다. 주관적 판정은 사람 표본으로 정기 보정해야 합니다.
Q. 공개 코딩 벤치마크 점수를 비교해도 되나요?
A. 참고는 가능하지만 모델·scaffold·seed·데이터 노출·task 품질의 영향을 함께 기록해야 합니다. 내부 저장소의 실제 task가 배포 판단에는 더 직접적입니다.
마무리
AI 코딩 에이전트의 진짜 생산성은 얼마나 그럴듯한 답을 내는지가 아니라, 얼마나 적은 비용으로 올바른 패치를 판정할 수 있는지에서 드러납니다. 다음 작업 하나를 골라 명세, fail-to-pass, pass-to-pass, diff 범위를 파일로 남겨 보세요. 그 작은 계약이 쌓이면 새 모델이나 프롬프트를 바꿀 때도 감이 아니라 증거로 결정할 수 있습니다.