Claude Opus 4.7과 SWE-bench로 보는 코딩 에이전트 평가

코드 생성 점수만으로 에이전트를 고르기 어려운 이유

Anthropic은 2026년 5월 Claude Opus 4.7을 정식 출시했다. 이 모델은 SWE-bench Verified에서 87.6%를 기록해 Gemini 3.1 Pro의 80.6%와 GPT-5.4를 앞섰다. 복잡한 멀티스텝 워크플로 성능도 Opus 4.6 대비 14% 향상됐다.

이 결과를 단순한 코드 생성 순위로 읽으면 중요한 부분을 놓친다. 코딩 에이전트는 이슈를 해석하고, 관련 파일을 찾고, 패치를 적용한 뒤 테스트와 수정을 반복한다. 따라서 프론티어 모델을 비교할 때는 개별 응답의 정확도뿐 아니라 전체 작업 흐름을 얼마나 안정적으로 끝내는지 봐야 한다.

SWE-bench Verified가 측정하는 작업 범위

SWE-bench Verified는 실제 GitHub 이슈를 해결하는 능력을 평가한다. 인간 엔지니어가 검증한 500개의 문제가 포함되며, 모델이 만든 패치를 적용한 뒤 테스트 통과 여부로 자동 채점한다. 단편적인 함수 작성이 아니라 문제 이해부터 저장소 탐색, 코드 수정, 검증까지 이어지는 소프트웨어 엔지니어링 과정이 평가 대상이다.

⤢✕

각 문제 인스턴스는 독립된 Docker 컨테이너에서 실행된다. 베이스 커밋에 에이전트가 생성한 패치를 적용하고 테스트 스위트를 실행하는 구조다. 이때 테스트 격리와 재현 가능성이 평가 결과의 기반이 된다.

평가 기준	측정 방식	신뢰도 지표
코드 수정 정확도	단위 테스트 통과율	95% CI ±0.8%
파일 탐색 효율	불필요한 파일 접근 횟수	평균 편차 ±2.1
문제 이해 깊이	이슈 설명 키워드 매핑	Fleiss κ = 0.87
패치 최소화	변경된 라인 수 대비 효과	Diff 압축률

HumanEval과 MMLU가 개별 쿼리의 응답 품질에 초점을 둔다면, SWE-bench는 파일 탐색과 여러 차례의 도구 호출이 필요한 멀티스텝 추론을 다룬다. 코딩 에이전트의 실제 작업 방식에 더 가까운 평가로 취급되는 이유다.

점수를 흔드는 오염과 프롬프트 민감성

LLM 벤치마크의 신뢰도를 위협하는 요인으로는 데이터 오염, 프롬프트 민감성, 평가자 분산이 있다. SWE-bench Verified는 GitHub 이슈 생성 날짜를 기준으로 훈련 데이터 컷오프 이후의 문제를 포함해 데이터 오염을 줄인다. 표준화된 시스템 프롬프트와 최대 3회 시도 평균값은 프롬프트에 따른 편차를 완화하고, 자동 테스트 실행은 인간 평가자의 주관이 개입할 여지를 줄인다.

다만 최종 테스트 통과율만으로 에이전트의 계획 품질까지 설명할 수는 없다. 실제 변경 전에 수행한 탐색과 문제 이해가 얼마나 효율적이었는지 보려면 별도의 메트릭이 필요하다. 일부 연구팀이 도구 호출 로그를 분석해 효율성 점수를 보조 지표로 사용하는 배경이다.

탐색·수정·검증을 잇는 도구 호출 체인

Claude Opus 4.7의 멀티스텝 워크플로 14% 향상은 도구 호출 체인 최적화와 연결된다. 에이전트는 하나의 작업을 끝내기 위해 수십 번의 호출을 순서대로 실행하며, 앞선 결과에 따라 다음 행동을 결정한다.

⤢✕

여기서 중요한 설계 판단은 결정론적 분기다. 각 호출 결과를 평가해 다음 단계를 동적으로 선택해야 하며, 오류 신호가 나타나면 기존 경로를 고집하지 않고 대안으로 전환해야 한다. Opus 4.7은 이 오류 감지와 경로 전환 속도가 개선됐다.

긴 작업에서 목표와 실패 기록을 보존하는 법

멀티스텝 작업이 길어질수록 컨텍스트 윈도우 한계와 정보 손실이 문제가 된다. Claude Opus 4.7은 계층적 컨텍스트 압축으로 최근 실행 결과, 이전 단계의 발견 사항, 원래 목표, 실패한 접근을 나눠 관리한다.

[컨텍스트 관리 계층]
├── 즉시 컨텍스트 (최근 5회 도구 호출 결과)
├── 요약 컨텍스트 (이전 단계 핵심 발견 사항)
├── 목표 컨텍스트 (태스크 원래 목표 및 제약 조건)
└── 메타 컨텍스트 (실패한 접근 방식 기록)

도구 실행 오류가 발생하면 같은 호출을 최대 2회 다시 시도한다. 재시도로 해결되지 않으면 실패 이유를 컨텍스트에 남기고 다른 전략으로 전환한다. 작업 전체가 성공하지 않았더라도 부분적으로 얻은 결과는 버리지 않고 다음 수정에 활용한다.

이 구조에서는 원래 목표와 실패 이력을 함께 보존하는 일이 중요하다. 최근 호출 결과만 남기면 같은 실패를 반복할 수 있고, 요약만 유지하면 패치에 필요한 구체적인 근거가 사라질 수 있다.

제출 전에 패치를 다시 의심하는 자기 검증

자기 검증 루프는 패치를 곧바로 제출하지 않고 내부 테스트와 수정 과정을 거치게 한다. 테스트가 실패하면 원인을 분석해 패치를 고치고, 통과한 뒤에도 신뢰도와 추가 검증 필요성을 판단한다.

⤢✕

검증 범위는 테스트 통과 여부에 그치지 않는다. 회귀 가능성과 코드 품질 지표도 함께 확인해, 대상 테스트는 통과하지만 코드베이스의 다른 부분을 손상시키는 패치를 걸러낸다.

벤치마크가 보여주는 모델별 강점

2026년 5월 기준 비교에서는 모델마다 우세한 지점이 다르다.

모델	SWE-bench Verified	HumanEval+	멀티스텝 복잡 태스크	API 비용 (M tokens)
Claude Opus 4.7	87.6%	94.2%	최고	$18 / $72
GPT-5.4	84.1%	95.8%	상위	$22 / $88
Gemini 3.1 Pro	80.6%	91.4%	중상위	$12 / $48
Claude Opus 4.6	73.6%	89.7%	중위	$15 / $60

GPT-5.4는 HumanEval+에서 95.8%로 Claude Opus 4.7의 94.2%보다 높지만, SWE-bench Verified에서는 84.1%로 Claude Opus 4.7의 87.6%보다 낮다. 이는 코드 완성과 복잡한 버그 수정·리팩토링이 서로 다른 능력을 요구한다는 점을 보여준다. Gemini 3.1 Pro는 $12 / $48의 비용이 강점이지만, 최고 난이도의 멀티스텝 작업에서는 격차가 나타난다.

⤢✕

따라서 모델 선택은 단일 순위보다 작업 유형에 맞춰야 한다. 복잡한 코드베이스 분석에는 Claude Opus 4.7, 코드 생성 속도에는 GPT-5.4, 비용 최적화에는 Gemini 3.1 Pro를 고려할 수 있다.

기업 코드베이스에 연결할 때 달라지는 판단

수십 년된 레거시 코드베이스를 현대적인 패턴으로 옮기려면 수백 개의 파일을 탐색하고 상호 의존성을 추적해야 한다. 이 작업에서는 강화된 컨텍스트 관리와 자기 검증이 유용하다.

CI/CD 파이프라인에 연결하면 풀 리퀘스트 검토 자동화, 버그 리포트 기반 패치 생성, 테스트 커버리지 확장을 에이전트가 수행하고 인간 엔지니어가 최종 결과를 검토하는 구조를 만들 수 있다. 코드베이스를 분석해 기술 부채를 식별하고 우선순위를 정한 뒤 수정 패치를 생성하는 흐름도 적용 대상이다.

성능 지표가 높더라도 운영 통제가 빠지면 기업 환경에 투입하기 어렵다. 에이전트가 접근할 수 있는 파일 범위를 제한하고, 변경 사항을 자동 감사 로그로 남기며, 고위험 변경에는 인간 승인 게이트를 두어야 한다. 비용 구조와 기존 개발 워크플로의 통합 난이도 역시 벤치마크 점수와 함께 판단할 항목이다.