SWE-bench의 점수를 보고 "좋아, 이 에이전트는 우수해"라고 판단한 적이 있는 사람이 많을 것이다. 다만, 그런 종류의 벤치마크가 측정하고 있는 것은 처음에 완전한 태스크 문장을 전달하고, 마지막에 나온 코드만을 채점한 결과일 뿐이다. 실제로 Cursor나 Claude Code를 사용할 때의 경험과는 그 지점이 결정적으로 어긋나 있다. 우리는 도중에 "그 부분은 이렇게 고쳐줘", "이 제약 조건도 추가해줘"라며 몇 번이고 입을 대며 진행한다. 최종적으로 동작하는 코드에 도달했다고 하더라도, 그 과정에서 10번의 수정 요구가 필요했는지, 1번으로 끝났는지는 같은 "성공"이라도 전혀 다른 문제다.

이 "몇 번이나 고치게 했는가"를 정면으로 세는 대화형 벤치마크가 6월 말 arXiv를 통해 공개된 SWE-Together다. 아직 일본어 해설은 거의 찾아볼 수 없다.

논문의 출발점은 심플하며, 핵심은 이 한 문장에 집약된다.

Real coding assistance is interactive, with users clarifying goals, adding constraints, and correcting mistakes over multiple turns.

현실의 코딩 지원은 단판 승부가 아니라 대화이므로, 평가도 대화로 진행하자는 것이다. SWE-Together는 실제 사용자와 에이전트의 세션 기록 11,260건에서 출발하여, 리포지토리(Repository) 상태를 복원할 수 있고, 목표가 명확하며, 결과를 검증할 수 있는 것들로만 추려 109개의 태스크를 만들었다. 1만 건 이상에서 109건, 통과율로 치면 약 1%다. 뒤집어 말하면 "대화 세션을 재현 가능한 형태로 검증하는 것"이 그만큼 어렵다는 뜻이기도 하며, 이 모수의 적음은 후술하듯 그대로 약점이 된다.

만드는 방식 자체가 흥미롭다. 과거의 세션을 다른 에이전트로 재생하기 위해, Gemini로 구동되는 사용자 시뮬레이터가 에이전트의 진행 상황을 보면서 원래 사용자가 던졌던 질문이나 수정 지시를 끼워 넣는다. "궤적 조건화 (Trajectory Conditioning)"라고 불리는 방식으로, 대본을 기계적으로 재생하는 것이 아니라 상대방의 대응을 보고 개입할 타이밍을 결정한다. 최종적인 코드의 정확성은 결정적인 테스트와 Anthropic의 모델에 의한 루브릭 판정 (judge score)으로 채점한다. 사용자 역할도 채점자도 LLM(Large Language Model)인, 평가계 전체를 에이전트로 돌리는 구성이다.

이 벤치마크의 핵심은 성패와는 별도로 준비된 User Correction이라는 지표에 있다. 정의는 담백하다.

UserCorrection = N_correction + 0.2 × N_nudge

명확한 수정 요구 (correction)를 1점, 가벼운 재촉 (nudge)을 0.2점으로 하여, 대화 중에 사용자가 얼마나 손을 대야 했는지를 합산한다. 숫자가 작을수록 가만히 두어도 알아서 정답으로 향하는 "손이 덜 가는" 에이전트라는 의미가 된다. 기존의 pass율이 도달점만을 보고 있었다면, 이것은 과정 중의 마찰을 측정하고 있다.

주요 모델의 결과는 논문의 테이블에 다음과 같이 정리되어 있다.

모델	pass@1	pass²	judge score	User Correction
Claude Opus 4.8	63%	52%	0.801	1.38
...

pass@1은 1회의 실행으로 해결한 비율, pass²는 2회 모두 임계치를 넘은 비율로, 후자는 변동성의 적음 (안정성)을 보는 엄격한 지표다. 가장 손이 덜 갔던 것은 Opus 4.8의 1.38회였고, 반대로 가장 많은 수정이 필요했던 것은 MiniMax-2.7의 2.17회였다.

여기서 논문이 굳이 보여주는 것이 User Correction과 pass@1의 피어슨 상관계수인데, 그 값은 -0.92다. "강한 모델일수록 수정 횟수가 적다"라는 직관 그대로의 강한 역상관이 나타나고 있다. 솔직히 말하면, 이는 새로운 축이 완전히 독립된 정보를 갖는 것은 아니라는 의미이기도 하다. 능력이 높으면 손이 덜 간다는 것은 어떤 의미에서는 당연한 일이다. 그럼에도 불구하고 집계된 pass율만 바라보고 있으면 놓치기 쉬운 "중간 개입 비용"을 단독 수치로 추출해냈다는 것 자체에 가치가 있다. 똑같은 58%라도 적은 개입으로 그 지점에 도달한 에이전트가 실무에서의 사용 편의성은 분명히 더 좋다.

코드는 Apache 2.0으로 공개되어 있다. 셋업은 uv를 전제로 짧다.

uv sync # .venv에 의존 관계 준비
cp .env.example .env # API 키 설정

샌드박스(Sandbox)는 E2B(클라우드) 또는 로컬 Docker를 사용하며, 실행과 채점은 스테이지를 나누어 호출한다.

# 109개 태스크 실행
.venv/bin/python launch.py canonical_full109.json --stage run --models opencode_opus48 --execute
# 채점
...

다만 가볍게 한 번 실행해 보는 수준은 아니다. 구동하려면 사용자 시뮬레이터용 Gemini, 판정용 Anthropic, 대상 에이전트용 프로바이더 등 여러 개의 API 키와 샌드박스 과금이 동시에 필요하다. 평가를 돌리는 것만으로도 상당한 토큰을 소모하는 구성인데, 이는 "LLM으로 LLM을 평가하는" 대화형 벤치마크 전반에 수반되는 비용이다. 재현성 관점에서도 채점자나 사용자 역할을 하는 모델이 바뀌면 수치가 변할 수 있다는 점은 염두에 두어야 한다.

개인적으로 가장 효과적이라고 느낀 점은, 코딩 에이전트의 우열을 "최종적으로 풀었는가"라는 단 하나의 기준으로 논하는 것을 멈추게 하는 압박이 된다는 점이다. 실제 운영에서 고통스러운 것은 오히려 몇 번이나 다시 말하게 만드는가 하는 마찰(friction)인 경우가 많다. SWE-Together는 그 부분에 수치를 부여했다.

한편, 109개 태스크라는 적은 표본 수와, 검증하기 쉬운 세션을 선별한 결과로서 발생하는 편향(bias)은 감안해서 보아야 한다. "재현 및 검증이 가능한 태스크"는 애초에 비교적 순탄한 태스크에 치우치기 쉽다. 리더보드의 절대치를 맹신하기보다, User Correction과 같은 "개입 비용(intervention cost)"을 평가에 포함하는 발상을 가져오는 것이 이 논문을 올바르게 활용하는 방법이라고 생각한다. 사내에서 에이전트를 선정할 때도 통과율 옆에 "얼마나 손이 많이 갔는가"라는 열을 하나 추가하는 것만으로도 의사결정의 해상도는 상당히 달라질 것이다.