새 모델로 바꾼 뒤 설명은 자연스러워지고 간단한 버그 수정도 빨라졌지만, 세 번째 주부터 관련 없는 마이그레이션 파일까지 고치는 일이 늘었다고 해봅시다. 이 수치는 평가법을 설명하기 위한 사례입니다. “대체로 좋아졌다”는 인상만 남겨 두면 이런 퇴행은 비용이나 장애가 생긴 뒤에야 보입니다.

핵심 코딩 에이전트 평가는 정답 코드 한 벌과 문자열을 비교하는 시험이 아닙니다. 대표 업무를 작은 골든 태스크로 고정하고 기능 결과, 변경 범위, 안전 위반과 비용을 같은 조건에서 반복 측정해야 합니다.

먼저 평가할 결정을 정합니다

모델 교체, 프로젝트 지침 수정, 새 Skill 도입과 권한 변경은 서로 다른 실험입니다. 무엇을 선택하려는지 먼저 정해야 결과를 해석할 수 있습니다. 한 번에 두 요소를 바꾸면 좋아진 이유와 나빠진 이유를 분리하기 어렵습니다.

지표도 결정에 맞춰 고릅니다. 저렴한 모델을 선택하려면 성공률과 비용을 함께 보고, 안전 지침을 바꾼다면 금지된 파일 접근과 불필요한 권한 요청을 우선 봅니다.

골든 태스크는 실제 실패에서 가져옵니다

처음에는 8개에서 15개 정도의 작은 과제로 시작할 수 있습니다. 최근 리뷰에서 놓친 버그, 자주 반복되는 수정, 경계 조건과 에이전트가 과하게 손댄 사례를 익명화한 샘플 저장소로 옮깁니다. 쉬운 과제만 모으면 데모 점수만 높아집니다.

각 태스크는 시작 커밋, 요청, 허용·금지 범위, 시간 제한, 실행 명령과 기대 관찰을 가집니다. 운영 데이터와 비밀은 넣지 않고 네트워크 없이 재현할 수 있게 만듭니다.

정답 패치 대신 통과 조건을 씁니다

같은 버그도 올바른 구현은 여러 개일 수 있습니다. 특정 변경 차이와 똑같은지보다 사용자 계약과 금지 범위를 검사합니다.

CSV 날짜 버그 골든 태스크 예시
id: csv-local-date-01
start_commit: fixture-3f21
prompt: 서울 사용자의 CSV 날짜가 하루 빠른 문제를 수정하세요
checks:
  - test_csv_local_date passes
  - test_settlement_utc remains passing
  - php lint passes
forbidden:
  - migrations/** changed
  - public API response changed
  - network used
limits:
  wall_time_minutes: 12

채점기는 쉬운 사실부터 맡깁니다

테스트, 정적 검사, 타입 검사, 변경 파일 목록, 종료 코드와 시간은 결정적으로 채점할 수 있습니다. 금지 경로 수정이나 네트워크 사용도 실행 환경에서 기록합니다. 이런 항목을 모델 채점기에 맡길 이유가 없습니다.

가독성, 요구사항 충족과 설계 적합성처럼 규칙만으로 판정하기 어려운 항목은 사람이나 명확한 루브릭을 가진 모델 채점기를 보조로 쓸 수 있습니다. 자동 판정이 사람과 자주 다르면 루브릭이나 샘플을 고쳐야 합니다.

한 번의 성공을 점수로 쓰지 않습니다

코딩 에이전트의 실행은 같은 요청에서도 달라질 수 있습니다. 후보마다 같은 시작 상태에서 여러 번 실행하고 태스크 성공률, 금지 위반률, 사람이 손본 줄 수, 실행 시간과 사용량을 기록합니다.

평균만 보면 드문 큰 실패가 가려질 수 있습니다. 결제나 데이터 삭제처럼 피해가 큰 태스크는 한 번의 금지 위반도 별도 차단 조건으로 둡니다. 일반 수정은 성공률의 분산과 실패 유형을 함께 봅니다.

예시 비교는 장단점을 그대로 남깁니다

가상의 실행에서 후보 A는 10개 태스크 중 9개를 통과했지만 한 번 마이그레이션을 수정했습니다. 후보 B는 8개를 통과했고 금지 위반은 없었으며 평균 실행 시간이 더 짧았습니다. 안전이 중요한 저장소라면 단순 통과 수만으로 A를 선택할 수 없습니다.

실패를 “모델이 나쁨”으로 묶지 않고 조사 실패, 잘못된 파일 수정, 테스트 미실행, 시간 초과와 권한 위반으로 분류합니다. 그래야 모델, 지침, 도구와 태스크 중 무엇을 고칠지 결정할 수 있습니다.

평가 세트 자체의 과적합을 막습니다

골든 태스크를 지침에 그대로 적거나 반복 실행 결과를 보고 특정 테스트 이름만 공략하게 만들면 실제 업무 일반화가 약해집니다. 개발용 태스크와 최종 확인용 태스크를 나누고, 최근 실제 실패에서 새 사례를 보충합니다.

태스크를 추가할 때는 기존 점수와 비교 가능한지, 특정 프레임워크에만 치우치지 않았는지 봅니다. 오래된 API나 더 이상 쓰지 않는 업무는 보관하거나 교체하고 변경 이유를 남깁니다.

평가 결과는 배포 관문과 연결합니다

새 모델이나 Skill은 기준 후보보다 핵심 태스크 성공률이 낮지 않고 금지 위반이 없어야 제한된 프로젝트에 먼저 적용합니다. 실제 작업에서 생긴 새 실패는 개인 탓으로 끝내지 않고 재현 가능한 태스크 후보로 돌려보냅니다.

평가가 모든 위험을 증명하지는 않습니다. 샘플에 없는 언어, 큰 저장소, 외부 서비스와 장시간 작업은 미검증 영역으로 표시합니다. 최종 선택 기록에는 실행 조건, 후보 버전, 태스크 세트 버전과 사람 검토 결과가 있어야 합니다.

읽고 나서 확인하기

답을 떠올린 뒤 본문의 판단 기준과 비교해 보세요.

  • 모델이나 지침을 비교하기 전에 이번 평가가 결정할 한 가지 선택을 정의합니다.
  • 골든 태스크에 시작 상태, 실행 검사, 금지 변경과 제한 시간을 넣을 수 있습니다.
  • 통과율뿐 아니라 금지 위반, 변동성, 사람 수정량과 미검증 영역을 함께 보고합니다.

공식 출처