JetBrains는 2026년 8월 30일 프로그래밍 에이전트 Junie 내부에서 사용되는 대규모 언어 모델 평가 방법론에 대한 분석을 발표하며, ‘해결률(resolve rate)’이라는 단일 지표에 대한 의존을 넘어설 것을 촉구했다. 회사는 에이전트가 작업 테스트를 통과했는지를 아는 것이 중요하지만, 그것만으로는 에이전트가 결과에 도달한 방식, 소요 비용, 그리고 코드 패치가 제한적이고 유지 관리 가능한지 알 수 없다고 본다.
이 아이디어는 JetBrains가 자체 벤치마크에서 Claude Opus 4.7과 Gemini 3.5 Flash를 비교한 결과에 기반한다. 두 모델은 동일한 수의 작업을 해결했지만, Opus는 평균 184단계가 필요했고 실행 비용은 2.79달러였다. Gemini는 271단계와 1.24달러가 필요했다. 최종 결과가 같더라도 실행 경로나 도구 사용 효율에서는 뚜렷한 차이가 드러났다.
해결률은 무엇을 감추는가?
Junie는 issue와 소프트웨어 저장소의 맥락에서 작동하며, 모델이 파일을 검사하고, 심볼을 검색하고, 코드를 수정하고, 명령과 테스트를 실행할 수 있도록 한다. 이러한 행동은 모델의 내부 사고를 드러낸다고 주장하지 않으면서도 관찰할 수 있는 ‘실행 경로’를 구성한다. 이 경로를 통해 에이전트가 수정 전에 문제 위치를 파악했는지, 검색 작업을 반복했는지, 가정을 테스트했는지, 또는 최종 패치를 검증하지 않고 작업을 끝냈는지를 알 수 있다.
이에 따라 JetBrains는 기능적 결과, 실행 효율성, 패치 품질, 프로세스 품질이라는 네 가지 관점을 결합하는 평가 파이프라인을 제안한다. 구체적인 측정 항목에는 테스트 결과, 실행 시간, 토큰 수와 모델 및 도구 호출 횟수, 비용, 수정된 파일과 심볼의 수, 복잡도 변화, 반복적인 파일 읽기 작업, 결과가 바뀌지 않은 명령의 재실행, 도구 실패 루프가 포함된다.
결과에서 결과에 도달한 경로로
JetBrains는 Claude Opus 4.7과 Gemini 3.5 Flash를 비교하면서 523개 작업으로 구성된 네 가지 벤치마크에서 이 방법론을 테스트했다. Opus는 267개 작업을 해결해 51.1%의 해결률을 기록했고, Gemini는 254개 작업을 해결해 48.6%를 기록했다. 430개 작업에서는 결과가 같았다. 두 모델 모두 214개 작업에서 성공했고, 모두 216개 작업에서 실패했다. 실제 차이는 93개 작업에서만 나타났으며, 이는 순위표의 단순한 차이보다 행동상의 차이가 더 중요할 수 있음을 보여준다.
두 모델이 모두 성공한 한 작업의 사례에서 두 모델은 15단계에 관련 파일을 열고, 근본 원인에 도달했으며, 포괄적인 검증을 수행했다. 하지만 Opus는 더 표적화된 검색을 사용해 13단계 후 실행을 시작했고, 53단계 만에 작업을 끝냈으며 탐색, 실행, 검증 사이를 6번 전환했다. 반면 Gemini는 대규모 단위를 더 광범위하게 검사했고, 30단계에 처음으로 실행 가능한 검사를 수행했으며, 88단계가 되어서야 프로덕션 코드에 대한 첫 수정에 들어갔다. 이후 192단계와 단계 간 34번의 전환이 필요했다.
두 모델은 테스트를 통과했고, 기준 패치가 수정한 것과 동일한 파일과 심볼을 수정했다. 하지만 Opus는 다른 파일을 건드리지 않은 반면, Gemini의 패치는 추가로 4개 파일까지 확장되었으며, 평가 과정에서는 이를 광범위하고 상당한 반복과 일부 환각을 포함하는 것으로 설명했다. JetBrains는 이 사례가 설명을 위한 것이며 독립적인 통계 결과는 아니라고 강조한다.
실패는 하나의 상태가 아니다
두 모델이 모두 실패한 216개 작업을 분석한 결과, 평가에 따르면 사례의 85% 이상에서 근본 원인을 완전히 또는 부분적으로 식별한 것으로 나타났다. 한 사례에서 두 에이전트는 텍스트가 심볼 한도를 초과해 오류가 발생했다는 점을 이해했지만, 텍스트를 올바른 부분으로 나누는 대신 잘라내는 방안을 제안했다. 또 다른 사례에서는 한 경로의 다운로드 매개변수는 수정했지만, 동반 경로에서 동일한 문제를 놓쳤다.
이러한 사례는 에이전트가 담당 컴포넌트를 찾지 못한 경우와 실무적으로 다르다. 원인은 불완전한 구현, 잘못된 계층 수정, 작업의 정확한 계약을 따르지 않은 것, 또는 검증 전에 중단한 것일 수 있다. 따라서 실행 경로는 저장소 내 탐색 개선, 작업 문구 조정, 수정 완료 능력 강화, 최종 검증 단계 강제 등 어느 부분에 개입해야 하는지 파악하는 데 도움을 줄 수 있다.
단일 순위 대신 행동 프로필
JetBrains는 Claude Opus 4.7이 모호한 결함의 근본 원인을 식별하는 경향이 더 강했으며, Gemini가 실패한 작업 53개를 해결했다고 결론지었다. 하지만 Opus 실행의 123건에는 실행 가능한 검증이 전혀 포함되지 않았고, 그중 68개 작업은 해결된 것으로 평가되었다. 회사는 이러한 행동이 회귀나 경계 사례와 관련된 발견되지 않은 위험을 남길 수 있다고 본다.
반면 Gemini 3.5 Flash는 예상되는 동작이 명확하고 담당 컴포넌트가 비교적 분명할 때 실행 가능한 검사를 실행하고 그 결과를 사용해 해결책을 개선하는 경향이 더 강했다. 그러나 해결책으로 수렴하는 과정과 저장소에 대한 근거 확보에서 문제가 나타났다. 동등한 검색이나 명령을 반복했고, 빌드 구조에 많은 단계를 소비했으며, 문서화되지 않은 인터페이스, 의존성, 경로 또는 테스트 설정에 더 많이 의존했다. Gemini 실행의 195건, 즉 37.3%는 중간 수준 또는 심각한 환각을 포함한 것으로 분류되었으며, Opus는 130건이었다. 또한 Gemini의 80건, 즉 15.3%에서는 상당하거나 심각한 반복이 나타났고, Opus는 6.5%였다.
실무적으로 무엇을 의미하는가?
GPT-5.5, Claude Opus 4.7, Gemini 3.5 Flash, Qwen 3.6 27B FP8을 522개 공통 작업에서 비교한 더 광범위한 평가에서는 GPT-5.5가 51.5%로 가장 높은 해결률을 기록했으며, 매번 실행 가능한 검사를 수행한 유일한 모델이었다. Opus는 패치 품질 지표에서 앞섰고, Qwen 3.6 27B FP8은 GPT-5.5 비용의 3%에 해당하는 실행 비용으로 작업의 38.9%를 해결했다.
이 수치는 모델 선택이 비용과 위험이 발생하는 지점에 달려 있음을 보여준다. 진단에 강한 모델은 익숙하지 않은 저장소나 모호한 결함에 적합할 수 있는 반면, 검증을 더 규율 있게 수행하는 모델은 테스트와 피드백을 이용할 수 있을 때 더 나을 수 있다. 실패한 시도의 비용이 제한적이라면 해결률이 낮더라도 비용이 낮은 모델이 실용적인 선택이 될 수 있다. 그러나 이러한 해석이 모든 환경에서 한 모델이 동일한 행동을 보인다는 뜻은 아니다.
JetBrains는 결과가 Junie의 특정 구조에 의존했기 때문에 행동 프로필을 모델 자체에 일반화하는 것에 주의를 당부한다. 또한 대규모 언어 모델에 기반한 평가자의 판단은 ‘기준 진실’이 아니며, 정답 패치 하나에 크게 영향을 받는다. 올바른 해결책이 서로 다른 파일이나 아키텍처 계층을 사용할 수 있기 때문이다. 따라서 해결률은 여전히 필수적인 기반이지만, 하나의 종합 순위로 축약하기보다는 효율성, 수정 품질, 작업 경로에 대한 증거를 함께 제시할 때 그 가치가 커진다.