I compared Opus 4.8 vs Opus 5 on 25 of my tasks to see what the difference was
핵심 요약
Opus 5는 더 넓은 범위의 탐색과 검증을 수행하지만, Opus 4.8보다 코드 변경 범위가 넓고 상호작용이 피로하다는 평가를 받았습니다.
성능 비교 — 두 모델 모두 25개 작업 중 9개를 통과하며 동일한 점수를 기록함
작업 방식 — Opus 5는 더 많은 셸 명령과 검증을 수행하며 더 넓은 범위를 탐색함
코드 변경량 — Opus 4.8은 변경 범위가 더 작아 실제 병합된 코드와 유사한 결과를 보임
사용자 경험 — Opus 5는 더 에이전트답지만, 장황한 설명과 코드 변경 범위로 인해 검토 부담이 큼
Opus 5가 새로 나왔는데, 벤치마크 점수는 Fable 5를 발라버리면서도 막상 실전에서 써보면 묘하게 사람 열받게 하는 구석이 있음. Opus 5가 도대체 어떻게 돌아가는지, 내 레포지토리에서는 어떤 성능을 보여줄지 궁금해서 내 레포에 실제로 머지했던 작업 25개를 뽑아 Opus 4.8이랑 Opus 5를 돌려봤다. 각 모델당 작업 하나씩, 중간 정도의 추론 강도로 동일한 평가 기준을 적용해서 딱 한 번씩만 돌림.
세 줄 요약
점수는 9/25로 동점: 둘 다 똑같이 8개 작업은 맞췄고, 각자 하나씩만 다르게 성공함.
Opus 5는 더 넓게 뒤지고 더 꼼꼼하게 검증함. 25개 작업 중 18개에서 셸 명령어를 더 많이 썼고, 15개에서 테스트 명령어를 더 많이 날렸으며, 건드린 파일에 대해 수정 횟수도 더 많았음.
Opus 4.8은 딱 필요한 것만 함. 25개 중 20개 작업에서 패치 규모가 더 작았는데, 이건 실제로 머지된 코드랑 더 비슷하게 움직였다는 뜻임.
비용은 비슷함: Opus 5가 일반적인 작업에서 약 1.4% 정도 저렴했는데, 토큰은 4% 더 썼고 작업 시간(wall-clock)도 4% 더 걸림.
결과만 놓고 보면 둘 다 9개 작업을 통과해서 똑같아 보임. 근데 그 과정을 뜯어보면 패치 내용도, 거기까지 도달하는 방식도 완전히 다름.
Opus 4.8은 25개 작업 중 20개에서 태스크 풋프린트(실제 머지된 코드 대비 얼마나 코드를 건드렸는지)가 더 낮았음. 반면 Opus 5는 18개 작업에서 셸 명령어를 더 많이 쳤고, 15개에서 테스트 명령어를 더 많이 썼으며, 12개 작업에서 더 많은 파일을 건드렸음(11개는 동일). 전체 툴 호출 횟수는 13 대 11로 거의 비슷했고 하나는 완전히 똑같았음. 두 모델이 쓴 상호작용 예산은 거의 같았는데, 쓰는 방향이 정반대였음. Opus 4.8은 수정 자체에 예산을 썼고, Opus 5는 뭘 수정해야 할지, 그 수정이 맞는지 확인하는 데 예산을 다 씀.
이런 차이 때문에 단순히 통과율만 보면 안 된다는 거임. 테스트 통과율은 그냥 테스트 스위트가 최종 패치를 받아줬냐 아니냐만 알려줄 뿐임. 에이전트가 어떻게 검색했는지, 뭘 검증하기로 했는지, 리뷰를 위해 코드를 얼마나 남겨뒀는지, 애초에 요구사항에 맞는 파일까지 찾아갔는지, 아니면 짠 코드가 유지보수하기 좋은지 같은 건 전혀 안 알려주거든.
테스트 실패라고 해서 무조건 틀린 것도 아님. 패치 자체는 의도대로 잘 작동하는데 테스트만 통과 못 하는 경우도 있으니까. 그래서 Stet에서는 '동등성(equivalence)'이라는 2차 검증을 하는데, 이건 내부 구현이 다르더라도 에이전트가 짠 패치가 실제 머지된 패치와 똑같은 동작 변화를 만들어냈는지 확인하는 거임. 이 기준으로 봐도 둘은 똑같음. Opus 4.8은 25개 중 12개, Opus 5는 11개에서 동등하다고 판단됐고, 둘 다 동등한 건 10개였음(공통으로 통과한 8개 + 둘 다 패치는 맞게 짰는데 테스트 통과에 필요한 뭔가를 놓쳐서 실패한 2개). 어떤 기준으로 봐도 둘은 사실상 동점임.
모든 작업은 내 레포지토리에 실제로 머지된 작업들을 기반으로 함. 변경 사항이 적용되기 직전의 코드 스냅샷을 가져와서, 당시의 이슈 프롬프트와 평가 명령어를 그대로 재현했음. 두 모델 모두 동일한 Claude Code 환경에서 25개 작업을 수행했고, 모델당 작업별로 중간 추론 강도로 딱 한 번씩 시도했으며, 평가 기준도 완전히 동일하게 적용함.
통과/실패 점수는 선택된 테스트가 에이전트 패치를 수락할 때만 셀을 통과로 간주해. 8가지 크래프트 차원과 코드 리뷰 루브릭은 claude-sonnet-4-6에서 0~4점 척도로 0.25점의 오차 범위를 두고 작업별로 짝을 지어 매긴 점수야.
참고: 이건 한 저장소에서 추출한 25개의 매칭 작업이야. 아래 내용은 몇몇 작업에 대한 행동 분석일 뿐, 결정적인 모델 순위는 아니야.
채점 (Grading)
결정론적 테스트 신호와 채점자 신호가 서로 다른 방향을 가리키고 있어. 풋프린트 리스크(Footprint risk)는 두 모델을 확실하게 갈라놓는데, 25개 쌍 중 20개가 Opus 4.8 쪽이야. 채점자가 신호를 포착할 때, Opus 5가 일관성, 지시 이행, 엣지 케이스 처리, 유지보수성 차원에서 더 낫다고 평가하는 경향이 있어.
이 데이터를 보면, 더 넓은 탐색과 더 많은 테스트 실행이 실제로 어떤 이득을 주는지에 대한 일관된 가설을 세울 수 있어. 패치 품질은 약간 올라가지만, 아티팩트 표면적은 급격하게 넓어진다는 거지. 이 정도 샘플 크기에서는 두 신호 모두 방향성을 보여준다고 할 수 있어.
작업별 비교 (Every task, side by side)
통계 수치만 보면 모델의 행동을 이해하는 데 유용한 개별 사례들이 가려져. 몇 가지 사례를 자세히 살펴보자!
Opus 4.8은 처음에 이해한 패치에 더 머물렀어
풋프린트 리스크는 Stet의 결정론적 패치 표면적 측정 방식이야. 수정된 파일, 코드 변경량(churn), 크기, 그리고 병합된 diff와의 중복도를 따지지. 풋프린트 점수가 낮다는 건 에이전트의 패치가 이전에 병합된 것과 더 비슷하다는 뜻이야. 이건 정확성과는 상관없고, 오직 표면적인 부분만 말하는 거야.
stet-89dfbc27은 왜 제약(containment)이 가치 있는지 잘 보여줘. 이 작업은 무시된 파일들을 Stet의 합성 베이스 커밋으로 복구하는 거였어. 두 에이전트 모두 git add -A에 --force를 추가하는 프로덕션 수정안을 찾아냈지.
Opus 4.8은 프로덕션 파일 하나를 수정하고 테스트는 추가하지 않은 채 통과했어. Opus 5는 똑같이 프로덕션 수정을 하고 나서 141줄짜리 엔드투엔드 테스트를 추가했지. 그 테스트는 컴파일도 잘 됐고 실제 경계 조건을 확인했어. 대신 작은 수정을 훨씬 더 큰 표면적으로 키워버렸지. Opus 5는 같은 구현을 해내고 더 광범위한 검증을 하는 데 거의 3배의 시간과 83% 더 많은 비용을 썼어.
stet-2450ca2d는 internal/gitops/testclassifier.go에 두 개의 새로운 테스트 파일 패턴이 필요했어. Opus 4.8은 그 분류기 출력의 인접 소비자인 internal/validate/footprint_risk.go를 수정했어. 자기가 수정한 함수는 테스트했지만, 정작 요구된 행동의 주인(owner)은 건드리지도 못했지. Opus 5는 testclassifier.go를 찾아내서 두 패턴을 모두 추가했고, 엄격한 평가와 동등성 평가를 모두 통과했어.
Opus 4.8의 패치는 엉뚱한 곳을 건드린 셈이지. 이 작업이 보여주는 또 다른 점은, Opus 5가 더 작은 풋프린트를 남긴 5개 사례 중 하나라는 거야. Opus 5의 더 넓은 탐색이 올바른 주인을 찾아내면, 그 광범위한 탐색이 반드시 더 큰 패치로 이어지지는 않는다는 거지.
요약하자면, Opus 4.8의 방식은 작업 범위가 이미 명확할 때 효과적이야. 하지만 작업의 진짜 어려운 부분이 '이 작업의 주인이 도대체 몇 명이고, 그 표면적이 어디에 있는지'를 찾아내는 것일 때는 위험해질 수 있어. 많은 대규모 엔터프라이즈 코드베이스가 딱 이런 상황이지.
Opus 5는 더 넓게 탐색했고 첫 수정 이후에도 계속 작업했어
총 도구 호출 횟수는 두 모델이 거의 비슷해. Opus 5가 더 많은 상호작용을 소비한 건 아니야. 대신 그 횟수를 셸, 테스트 실행, 반복적인 수정에 더 많이 할당했지.
그 더 넓은 경로가 stet-2450ca2d를 통과시킨 비결이야. 테스트 명령어를 3번이 아니라 6번 실행했고, 인접한 소비자에서 멈추지 않고 실제 주인인 분류기까지 탐색을 이어갔거든. 일단 올바른 주인을 찾고 나니 구현 자체는 작았어. 이 작업의 핵심은 올바른 표면적을 찾기 위한 저장소 탐색이었던 거야.
하지만 더 넓은 경로가 더 큰 변경 사항에서는 다른 방식의 실패를 낳기도 했어.
stet-bbbbae09에서 Opus 5는 8개 파일에 걸쳐 24번의 패치 호출을 기록했고, 필요한 테스트 하나를 이름을 바꿔버렸으며 다른 하나는 누락했어. 반면 Opus 4.8은 6개 파일에 걸쳐 15번의 패치 호출을 했고 엄격한 평가 기준을 통과했지.
긴 궤적이라고 낭비가 아니고, 짧다고 효율적인 것도 아님. Opus 5는 더 빨리, 더 싸게 끝내는 경우가 많았지만, 수정 횟수가 늘어난 뒤에도 정작 필요한 결과물을 놓치는 일이 있었음. Opus 4.8은 평가를 통과하긴 했지만, 결과물에서 여전히 API나 권한 관련 문제가 지적됨. 두 패치 모두 자기 과제 범위를 넘어서는 일반화는 안 됨.
stet-6f84e978은 확장의 가치를 잘 보여줌. Opus 5는 Opus 4.8이 테스트 명령어 2개를 돌릴 때 7개를 돌렸고, Rust와는 상관없는 명시적 의무 사항에 대한 보존 테스트까지 추가했음. 더 빡센 검증을 거치느라 시간은 6.1분에서 34.9분으로 늘었지만, 비용은 1.11달러에서 1.18달러로 거의 안 올랐음. 벽시계 시간, 토큰, 캐시 적중률, 가격은 궤적의 서로 다른 부분을 보여주는 지표일 뿐임.
Opus 5는 더 넓게 탐색하다 보니 놓쳤던 소유자를 찾아내기도 하지만, 때로는 정확한 계약 조건에서 벗어나 삼천포로 빠지기도 함. 이건 최종 테스트 결과만 볼 게 아니라 궤적과 패치를 직접 비교해봐야만 알 수 있는 부분임.
시간, 토큰, 비용은 제각각 따로 논다
자원 측정 지표 세 가지는 각각 다른 질문에 답함. 에이전트 소요 시간은 실행 시작부터 끝까지 걸린 벽시계 시간임. 총 토큰 수는 캐시된 입력을 포함해 기록된 입력과 출력의 합계임. 캐시 인식 비용은 모델별 가격 정책을 신규 입력, 캐시된 입력, 출력에 각각 적용한 값임. 17개 쌍에서 Opus 4.8이 더 빨리 끝냈고, 15개 쌍에서 Opus 5가 더 저렴했음. 일반적인 과제 비용 추정치는 Opus 4.8보다 1.4% 낮은 수준이었음.
Opus 5는 25개 쌍 중 16개에서 토큰을 더 적게 썼고 15개에서 비용이 더 적게 나왔으니, 횟수만 보면 Opus 5가 우세함. 하지만 쌍별 기하학적 크기로 따지면 토큰 쪽은 결과가 다름. Opus 5가 토큰을 더 많이 쓴 경우, 그 차이가 꽤 커서 일반적인 과제 토큰 추정치가 Opus 4.8보다 4.3% 높게 나옴. 반면 비용은 1.4% 낮았고, 시간은 3.7% 더 걸렸음. 횟수는 얼마나 자주 발생했는지를 보여주고, 쌍별 추정치는 모든 과제에 동일한 가중치를 뒀을 때 일반적인 변화 폭이 얼마나 큰지를 보여줌.
두 가지 사례를 보면 범위가 얼마나 넓은지 알 수 있음:
stet-15439c21에서 Opus 5는 작은 삭제 작업을 294초, 488K 토큰, 0.42달러에 끝냈음. Opus 4.8보다 3.3배 빠르고 토큰은 2.4배 적게 썼음. 둘 다 통과.
stet-89dfbc27에서 Opus 5는 대규모 엔드투엔드 테스트를 추가했는데, 토큰은 70%, 비용은 83% 더 썼고 시간은 2.8배 걸렸음. 둘 다 통과.
양 끝단은 한쪽으로 쏠려 있음. 25개 과제 중 4개에서 Opus 5는 Opus 4.8보다 2.5배 넘는 토큰을 썼고, stet-e928166f에서는 최대 4.1배까지 치솟았음. 반대로 Opus 4.8이 토큰을 가장 많이 초과해서 쓴 경우는 2.4배였음.
이 집단에서 딱 잘라 "더 빠른 모델"이나 "더 싼 모델" 같은 건 없음. 자원 사용량은 에이전트가 각 과제에서 무엇을 확인하고, 구현하고, 검증하기로 결정하느냐에 따라 달라짐.
평가가 놓치는 것들
Opus 5의 일상적인 동작에서 나(그리고 내가 대화하는 모든 사람)를 미치게 만드는 건, 이 수치에는 전혀 안 나오는 극도로 장황하고 읽기 힘든 문장들임. 이 평가는 결과물(artifact), 즉 패치와 실행한 테스트, 에이전트가 거기에 도달한 궤적만 점수를 매김. 그 결과를 만들어낸 에이전트와의 상호작용은 평가하지 않음. 설명의 벽, 다시 읊는 계획, 요약의 요약, 읽다 보면 눈이 핑 도는 텍스트들, 그리고 "LGTM, 배포해". 8가지 평가 항목 중 그 어떤 것도 최종 패치를 얻기 위해 사람이 얼마나 읽어야 했는지는 측정하지 않음.
코드 쪽의 장황함은 Opus의 또 다른 고질적인 문제인데, 이건 우리 풋프린트 위험 지표에는 나타남. 그렇다 해도 Opus는 패치 자체는 깔끔하게 짤지 몰라도 상호작용은 사람을 지치게 만드는데, 이 평가는 구조적으로 그걸 볼 수 없음. 이건 협업 평가가 아니라 결과물 평가니까.
더 에이전트다운 모델
이 작업들에서 Opus 5는 훨씬 더 에이전트다운 모델처럼 보여. 수정 사항을 커밋하기 전에 저장소를 더 넓게 뒤져서 정확한 지점을 찾아냈고, 단순히 가장 가까운 소비처를 패치하는 대신 해당 동작을 관장하는 핵심 위치를 직접 찾아 들어갔어. 게다가 그럴듯해 보이는 첫 번째 패치에서 멈추는 게 아니라, 스스로 작업 내용을 검증하려고 더 많은 테스트 명령을 내리고 수정 후 보완 작업까지 거치더라고. 이 모든 걸 같은 가격대에서 해냈어. 25개 작업 중 15개에서 더 저렴했고, 평균적으로는 약 1.4% 정도 비용이 덜 들었지.
이런 동작의 대가는 돈이 아니라 리뷰 범위에서 나타나. 25개 작업 중 20개에서 사람이 (어쨌든) 검토해야 할 패치 규모가 더 커졌거든. Opus 5는 탐색과 검증을 가져오는 대신, 패치 범위와 약간의 작업 시간이라는 대가를 치르게 해.
성격은 좀 까칠하지만, 나는 앞으로 가장 어렵고 까다로운 문제를 풀 때 Opus 5를 쓰거나 Fable이 이 모델을 쓰도록 시킬 생각이야.
다시 말하지만, 이건 n=1인 저장소 하나를 대상으로 한 결과일 뿐이야. 모델 선택은 지침 파일, 기술, 도구, 추론 설정과 함께 하네스(harness)를 조절하는 하나의 레버일 뿐이고, 이 중 무엇을 바꾸느냐에 따라 에이전트가 검색하고, 수정하고, 테스트하고, 멈추는 방식이 전부 달라질 수 있어. 최종 결정은 너희가 직접 병합한 작업물에서 내려야 해. 너희만의 과제가 반영된 작업 분포와 실제 코드 리뷰 비용을 고려해서 말이야.
면책 조항: 나는 이 테스트를 돌린 평가 도구를 만들고 있는 사람이야. 병합된 변경 사항이 있는 저장소를 가져오면, Stet이 계약 커버리지, 패치 규모, 시간, 토큰, 비용, 품질 전반에 걸쳐 하네스 설정을 비교해 줄 거야. 팀을 위해 더 나은 배포 결정을 내릴 수 있게 도와줄게.
주요 댓글
r/claudecode
사용자들은 Opus 5의 더 넓은 탐색 능력을 인정하면서도, 장황한 코드와 불필요하게 넓은 변경 범위가 실무 검토에 부담을 준다는 점에 공감하고 있습니다.
3
각 작업을 한 번씩만 실행하셨나요, 아니면 여러 번 실행하셨나요?
한 번만 실행한 거라면 9대 9 동점은 그냥 같은 프롬프트를 다시 돌렸을 때 나올 법한 결과라서 여쭤봅니다.
3
한 번만 실행했습니다. n=50~100 정도로 더 많은 데이터를 확보하면 좋겠다는 지적은 타당합니다.
게다가 현재로서는 테스트 검증 도구들이 최신 모델들을 구분해내는 능력이 뛰어나지 않아서 이런 동점 상황이 나오는 겁니다.
간단한 예로,
func testFoo {
assert(foo.DoSomeThing, true)
}
이런 테스트가 있는데 에이전트가 대신 foo.DoSomeOtherThing을 구현하면 테스트는 그냥 실패하게 됩니다. 위 테스트를 수정해서 호출하도록 하는 등 우회할 방법은 있지만...
재실행을 해보면 모델들이 얼마나 불안정한지 알 수 있을 겁니다. 같은 모델이 같은 작업에서 어떨 때는 DoSomeThing을 쓰고 어떨 때는 DoSomeOtherThing을 쓴다면, 그 변동률이야말로 어떤 테스트를 먼저 고쳐야 할지 알려주는 지표가 될 겁니다. 50개의 새로운 작업을 찾는 것보다 아마 더 저렴할 거예요.
3
좋은 모델 비교 분석입니다.
두 모델을 동시에 실행했나요, 아니면 순차적으로 실행했나요? 서버 부하는 하루 종일 변동이 심해서, 만약 블록 단위로 실행했다면 시간 차이 중 일부는 서버 부하 탓일 수도 있습니다. 게이트웨이 벤치마킹할 때 비싼 수업료를 내고 배운 점이죠.
1
순차적으로 진행했습니다. 좋은 지적입니다. 시간대별 차이를 고려하지 않았으니, 작업이 처리된 시점에 따라 추론 시간이 달라질 수 있겠네요.
2
멋진 분석입니다. Fable은 이들과 비교했을 때 어떤지도 보고 싶네요.
2
훌륭한 작업입니다.
1
25개 중 20개 작업에서 나타난 변경 범위(footprint) 차이가 저한테는 결정적이네요. 9대 9 동점에 8개는 똑같이 통과했는데, 한 모델은 인간에게 검토할 더 큰 diff를 던져주는 셈이니까요. 벤치마크는 동점이어도 검토 과정은 그렇지 않네요.
4
Opus 5의 장황함이 코드에서도 나타난다는 건 사람들이 그동안 Opus의 문체 문제로 겪어온 극심한 고통을 생각하면 놀랍지도 않네요.
1
계속 씨름하는 거 지쳐서 그냥 때려치움. 이제 ChatGPT가 내 새로운 뮤즈임.
1
사용된 effort 설정이 무엇인지 명확히 밝히는 게 중요함. Anthropic은 더 새로운 모델이 이전 모델과 같은 결과를 내면서도 더 낮은 reasoning 설정으로 사용 가능하다고 주장하니까. 이게 모델이 컨텍스트를 얼마나 넓게 탐색하는지, 테스트를 얼마나 광범위하게 수행하는지에 영향을 줄 가능성이 큼. 여담이지만, 일상적인 작업에서 얼마나 적은 effort로도 업무를 처리할 수 있는지에 대한 좋은 정보가 될 듯.
