공개 벤치마크와 짧은 데모는 AI 코딩 에이전트 후보를 좁히는 데 유용합니다. 하지만 팀이 실제로 풀어야 할 질문은 다릅니다. “우리 모노레포에서 인증 경로를 건드리지 않고 버그를 고칠 수 있는가?”, “테스트가 25분 걸릴 때 근거를 남기고 멈출 수 있는가?”, “IDE extension을 바꾼 뒤 리뷰 재작업이 늘었는가?”입니다. 코드 문법을 이해하는 능력과 팀의 change-control을 지키는 능력은 같지 않습니다.
그래서 최근의 초점은 최고 점수 모델을 고르는 일에서 저장소별 실행 계약(repository-native evaluation contract) 을 만드는 일로 이동하고 있습니다. 이는 거대한 평가 플랫폼이 아니라 실제 변경의 위험을 줄이는 작은 task 묶음과 evidence bundle입니다. Reviewable Stack이 큰 변경을 리뷰 가능한 순서로 나누듯, 평가는 “코드를 썼는가”가 아니라 “정의된 권한과 검증 환경에서 안전하게 완료했는가”를 남깁니다. AI Codemod와 Semantic Diff, Test Evidence Pipeline, 증거 중심 브라우저 디버깅의 원칙도 이 계약에 연결됩니다.
이 글에서 얻는 것
- 공개 benchmark와 repository-native eval이 알려 주는 범위를 구분합니다.
- 실제 저장소의 위험·반복성·검증 비용을 반영한 task set을 만듭니다.
- 성공률 외에 금지 경로 위반, false pass, 사람 재작업, 실행 비용을 함께 봅니다.
- 모델·tool·prompt·sandbox 변경을 capability release로 다루는 기준을 세웁니다.
핵심 개념/이슈
1) 저장소가 바뀌면 에이전트의 실패 모드도 바뀐다
실제 저장소에는 CI에서만 보이는 code generation, 느린 integration test, 사내 registry, 수정 금지 경로, flaky fixture, 배포 전용 설정이 있습니다. 그러므로 task는 “issue를 풀었는가”가 아니라 허용된 도구와 범위 안에서 acceptance criteria를 만족한 change를 만들었는가로 판정해야 합니다. 요구가 모호하거나 금지 경로를 건드려야 하는 상황에서 근거를 적고 멈춘 no-op은 위험한 patch보다 좋은 결과일 수 있습니다.
| 조건 | 겉으로 보이는 성공 | 반드시 볼 것 |
|---|---|---|
| 느린·flaky test | test green 한 번 | 반복 실행과 환경 실패 분리 |
| 모노레포 | 대상 패키지 수정 | 영향 패키지·lockfile·generated code |
| 외부 API | mock test 통과 | 401·429·timeout과 retry·권한 보존 |
| 보안 경계 | 설정 변경 없음 | secret·CI·infra write 위반 0건 |
2) task set은 제품 백로그의 작은 표본이어야 한다
최근 36개월의 실제 PR·incident·반복 maintenance에서 1020개를 고르고, 난이도보다 실패 비용과 작업 형태가 겹치지 않게 섞습니다. 국소 버그 수정, test 보강, 정형 API 교체, timeout·authorization 같은 경계 작업, 수정 없이 원인과 재현 명령을 제출하는 조사 task가 출발점입니다.
결제, 권한 승격, production 인프라, 대량 data migration처럼 되돌리기 어려운 작업은 자동 변경 성공률에 넣지 마세요. 처음에는 read-only 분석과 test 작성만 평가하고, 사람이 승인한 작은 PR로 별도 capability를 검증합니다. 고위험 작업을 쉬운 task 평균으로 덮으면 평가는 rollout 승인 도장이 됩니다.
3) 성공은 patch가 아니라 증거 묶음이다
컴파일과 테스트 하나의 통과는 충분하지 않습니다. 각 task에는 base commit, 허용·금지 경로, 변경 diff, 재현 또는 acceptance 명령, 실행 결과, 수정 전후 fixture, 남은 불확실성과 handoff를 요구하세요. exit code, 실행 시간, 테스트 목록, artifact hash를 남기면 리뷰어가 재현하고 다음 모델과 비교할 수 있습니다. 단, token·고객 데이터·원문 요청은 로그에 남기지 않도록 redaction과 보존 기간을 먼저 정해야 합니다.
실무 적용
1) rubric을 quality·safety·operations로 나눈다
| 영역 | 최소 gate 또는 출발 기준 | 확대 중단 신호 |
|---|---|---|
| Quality | acceptance test 100% 통과 | fixture 불변 조건 위반 |
| Safety | 금지 경로·secret·infra write 0건 | high-risk task의 무단 변경 1건 |
| Scope | diff와 no-op 사유가 task 경계 안 | owner 없는 예외 2% 이상 |
| Operations | 3회 run의 원인 분류 | tool 오류·timeout을 성공 처리 |
| Economics | baseline과 시간·비용 비교 | review time 또는 비용 25% 이상 악화 |
평균 성공률 80%보다 high-risk task의 hard gate 위반이 0건인지가 더 중요합니다. task가 15개라면 각각 세 번 이상 실행해 비결정성을 드러내고, 한 번만 통과한 결과를 capability 선언 근거로 쓰지 마세요.
2) capability 변경을 배포처럼 관리한다
모델 이름뿐 아니라 prompt template, context retrieval, tool allowlist, sandbox image, runtime version, token limit, auto-approve 설정도 에이전트가 보는 세계와 가능한 행동을 바꿉니다. 이를 agent_capability_revision으로 묶어 baseline task set에서 shadow run으로 비교하세요. patch task는 격리 branch나 sandbox tenant에서, 조사 task는 read-only로 실행하는 편이 안전합니다.
low-risk 작업으로 확대하려면 두 조건을 모두 만족하도록 시작할 수 있습니다. 모든 safety gate를 통과하고 quality 통과율이 baseline보다 떨어지지 않을 것, 그리고 p95 실행 시간·사람 재작업·비용 중 어느 것도 25% 이상 악화되지 않을 것입니다. 더 넓은 context나 권한은 성능 향상이 아니라 위험 모델 변경이라는 점을 분리해야 합니다.
3) 실패 taxonomy를 다음 개선의 입력으로 쓴다
“성공 12, 실패 3”만으로는 개선할 수 없습니다. 실패를 요구 불명확, context 누락, tool·권한 거부, build 환경, test flake, 잘못된 변경, 검증 부족, 비용·시간 초과로 나눕니다. tool permission 거부를 추론 실패로 세면 모델을 잘못 바꾸고, test가 없는데 완료를 보고한 일을 성공으로 세면 보고 문구만 최적화하게 됩니다. 매주 task별 taxonomy와 reviewer 수정량을 보면 다음 투자가 더 큰 모델인지, fixture·빠른 test target·ownership metadata인지 판단할 수 있습니다.
트레이드오프/주의점
repository-native eval은 현실적인 대신 과적합될 수 있습니다. 고정 core task 외에 매달 최근 작업에서 익명화·정제한 rotating task 20~30%를 넣고, 결과는 탐색 신호로 분리하세요. PR 수나 변경 파일 수는 불필요한 diff로도 올라가므로 reviewer 시간, rollback, incident, flaky test 재실행을 함께 봐야 합니다.
평가에는 민감한 코드와 운영 정보가 모이기 쉽습니다. 실제 고객 데이터, access token, private endpoint, production configuration 대신 synthetic fixture와 masked trace를 사용하세요. 평가는 사람 리뷰를 없애는 증거가 아니라, 어떤 작업을 더 안전하게 위임할지 알려 주는 경계입니다. 우선순위는 명확한 acceptance criteria → 제한된 권한 → 재현 가능한 test 증거 → 작은 리뷰 가능 diff → 속도·비용입니다.
체크리스트 또는 연습
- 실제 작업에서 10~20개 task를 골라 버그·test·정형 변경·경계 작업·조사를 섞었다.
- task마다 base commit, 허용·금지 경로, 재현 명령, acceptance test, reviewer를 적었다.
- model·prompt·tool permission·sandbox·실행 명령을 capability revision에 연결했다.
- success, no-op, environment failure, flaky test, unsafe change를 같은 성공률에 섞지 않는다.
- high-risk task의 safety hard gate 위반 0건을 확대 조건으로 둔다.
- 각 task를 3회 이상 실행하고 p95 시간·비용·사람 재작업을 baseline과 비교한다.
연습으로 최근 사람이 처리한 작은 버그 세 개를 고르세요. 각각에 허용·금지 경로, 성공 명령, 모르면 멈출 조건을 한 문장씩 붙인 뒤 같은 revision으로 세 번 실행합니다. 통과 수 대신 test 증거, diff 범위, 사람이 고친 줄 수, 실패 이유를 비교하면 다음 모델·tool 변경을 근거 있는 capability release로 다룰 수 있습니다.
💬 댓글