길게 돌려도 나아지지 않았다

결론부터. 실제 기업의 비공개 프로덕션 코드베이스에서 코딩 에이전트를 재봤더니 최고 해결률이 38.8%였고, 오래 돌린 실행이 짧은 실행보다 낫지 않았다.

숫자

Real-SWE는 실제 기업에서 사용 허가를 받은 비공개 코드베이스와 실무 과제로 평가한다. 모델 단독이 아니라 모델과 기본 하네스의 조합을 재고, 과제마다 8회 독립 실행한다.

• 평균 해결률: Fable 5.1 38.8%(최고), GPT-6 Astra 33.8%
• 분석한 10개 과제 중 6개가 해결률 15% 미만
• 모든 과제를 해결한 모델은 없음
• 실행 1회당 추정 비용: $2.50 ~ $6.96

과제별로 보면 더 낮다. 청구 일정 마이그레이션 14.1%, API 토큰 사용량 계측 12.5%, S3 데이터 저장소 측정 10.9%, 선형화 가능한 스캔 4.7%, 세금 관할권 3.1%. 분석 스트림 리듀서는 모든 모델이 실패해 0.0%다.

(원문)

가장 중요한 숫자는 실행 시간 쪽에 있다

10분 미만 실행은 98회 중 70회가 실패해 실패율이 71.4%였으며, 10분 이상 실행은 542회 중 398회가 실패해 73.4%였다.

길게 돌린 쪽이 오히려 조금 더 실패했다. 차이가 유의미하다고 말할 생각은 없다. 요점은 반대다 — 더 오래 생각하게 두는 것으로는 나아지지 않았다.

이건 실무에서 흔한 대응을 정면으로 친다. 에이전트가 막히면 타임아웃을 늘리고, 추론 강도를 올리고, 한 번 더 돌린다. 이 데이터에서는 그게 답이 아니었다.

닷새 전에 인용한 danluu의 실험과 같은 방향이다. 거기서도 기법 이름을 대거나 "실수하지 마라"라고 붙이는 건 효과가 없었고, 위험 지점을 특정한 짧은 지시가 이겼다. 투입을 늘리는 대신 입력을 고쳐야 한다는 결론이 두 실험에서 따로 나왔다.

왜 실패하는가

실패를 다섯 유형으로 분류했다. 검증하지 않은 가정, 요구사항 누락, 통합 오류, 회귀, 잘못된 파일 수정. 가장 흔한 것은 요구사항 누락이다.

코딩 능력의 문제가 아니라 무엇을 해야 하는지 다 챙기지 못한 문제라는 뜻이다. 그리고 그건 과제 구조에서 나온다.

• 지시문 길이 중앙값: 1,742자
• 참조 솔루션이 수정한 파일 수 중앙값: 11개

짧은 설명을 주고 열한 개 파일에 걸친 변경을 요구한다. 나머지는 코드베이스와 주변 도구에서 찾아내야 한다. 세금 청구 과제 하나만 봐도 사업자별 세율, 외부 세금 서비스 연동, 면세 자격 처리, 샌드박스와 프로덕션 구분, 거부된 주소는 오류를 알리되 청구서 발행은 중단하지 않기, 유럽 거래에는 양측 VAT 번호 표시가 얽혀 있다.

실무가 원래 그렇게 생겼다. 벤치마크가 어려운 게 아니라 벤치마크가 실무를 닮은 것이다.

그래서 바꿀 것

지시문을 길게 쓴다. 모델을 바꾸는 것보다 요구사항을 빠짐없이 쓰는 쪽이 효과가 크다는 게 이 데이터의 함의다. 1,742자가 짧다고 느껴진다면 그게 맞다.

막혔을 때 시간을 늘리지 않는다. 늘려도 실패율이 그대로였다. 막히면 지시를 고치는 게 순서다.

요구사항을 검증기로 바꾼다. 최빈 실패가 요구사항 누락이라면 대응은 직접적이다. 요구사항 목록을 산문으로 두지 말고 통과/실패가 찍히는 형태로 만든다. 어제 쓴 계획 해시 승인과 같은 계열이다. 말로 부탁하는 대신 구조로 확인한다.

한계

이것도 만든 쪽의 발표다. 다만 벤더가 자기 모델을 재는 것과는 성격이 다르다. 여러 모델을 같은 조건으로 놓고, 검증기는 채점 시점에 주입하며, 코드베이스에 원래 있던 테스트에서 착안하거나 그대로 쓴다.

모르는 것: 분석된 과제가 10개다. 표본이 작다. 그리고 나는 이 벤치마크를 직접 돌려보지 않았고 한국어 요약을 통해 봤다. 위 수치를 근거로 모델을 갈아탈 생각이라면 원문과 리더보드를 직접 확인하는 편이 맞다.

한 가지 더. 최고 해결률(Fable 5.1, 38.8%)이 실행당 비용도 가장 높다($6.96). 8회 시도해서 3~4회 성공하는 작업의 실제 단가를 계산해보면, 이 표의 순위가 곧 선택 순위는 아니게 된다.