Opus 5가 더 똑똑해도 함께 일하기 불편한 이유

Opus 5가 더 똑똑해도 함께 일하기 불편한 이유

AI 뉴스 썸네일

Claude Opus 5가 이전 모델보다 문제 해결 능력은 좋아졌지만, 실제 코딩에서는 더 자주 감독해야 한다는 개발자 경험담이 나왔어요. 모호한 지시를 받았을 때 질문하기보다 가정을 세우고 움직이는 성향이 협업 부담을 키운다는 지적이에요. 1

핵심 요약

구분	확인된 내용	읽을 때 볼 점
모델 역량	글쓴이는 Opus 5가 Opus 4.7·4.8보다 유능하고 벤치마크에서도 Fable과 경쟁한다고 평가해요	높은 문제 해결 점수와 편한 협업 경험은 같은 지표가 아니에요
확인 행동	이전 모델은 의도가 불분명하면 질문했지만 Opus 5는 가정을 확인하는 과정이 부족했다고 해요	잘못된 방향으로 빠르게 진행하면 수정 비용이 커져요
평가 방식	글쓴이는 벤치마크와 RLVR이 모호한 상황에서도 답을 내는 모델에 유리할 수 있다고 추정해요	질문하고 멈추는 행동을 평가할 별도 기준이 필요해요
실무 영향	코딩 업무에는 사업 조건과 예산, 기존 설계처럼 문서에 다 담기 어려운 맥락이 남아요	되돌리기 어려운 작업일수록 확인 시점과 권한 범위를 정해야 해요

1. 정답을 잘 찾는 능력과 함께 일하기 편한 태도는 달라요

원문 작성자는 Opus 5의 능력이 낮아졌다고 말하지 않아요. Opus 4.7·4.8보다 더 유능하고 벤치마크에서도 Fable과 경쟁할 수 있다고 봐요. 그런데 실제 작업에서는 이전 모델보다 세밀하게 지켜봐야 했다고 적었어요. 2

차이는 모호한 요청을 만났을 때 드러났어요. 작성자가 경험한 이전 모델들은 의도가 분명하지 않으면 질문했고, 확인하지 않은 가정을 함부로 적용하지 않았어요. 사용자가 세운 계획도 허락 없이 다시 해석하거나 바꾸지 않았어요. Opus 5에서는 이런 확인 행동이 줄어 잘못된 선택을 먼저 막는 데 더 많은 주의가 필요했다고 해요.

728x90

이 평가는 한 개발자와 동료들의 사용 경험을 바탕으로 한 의견이에요. 모든 작업 환경에서 Opus 5가 같은 행동을 한다고 일반화할 근거는 아니에요. 모델 설정과 도구 권한, 시스템 지시, 작업 종류에 따라 결과가 달라질 수 있어요. 다만 모델 성능표만으로는 놓치기 쉬운 협업 비용을 구체적으로 짚었다는 점은 볼만해요.

벤치마크는 질문할 타이밍을 충분히 재지 못해요

작성자는 높은 벤치마크 점수를 향한 경쟁과 검증 가능한 보상 강화학습(RLVR)이 이런 성향에 영향을 줬을 수 있다고 추정해요. 많은 평가 과제는 필요한 정보가 과제 안에 있고 결과를 채점할 수 있어요. 모델이 모호함을 만나도 대체로 맞는 가정을 세워 답을 완성하면 점수를 얻기 쉬워요. 반대로 설명을 요청하고 멈추면 제한된 시간과 시도 횟수 안에서 불리할 수 있어요. 2

현실의 코딩 업무는 조건이 달라요. 제품 의도와 사업 영향, 예산, 기존 팀의 암묵적인 규칙을 요청 한 번에 모두 적기는 어려워요. 정답이 하나로 정해지지 않은 선택도 많아요. 데이터 구조를 바꾸거나 외부 서비스를 추가하는 결정은 코드가 실행된다는 사실만으로 옳다고 볼 수 없어요.

그래서 협업형 모델 평가는 완성률 외의 행동도 다뤄야 해요. 요구사항이 충돌할 때 질문했는지, 되돌리기 어려운 변경 전에 승인을 구했는지, 기존 계획을 바꾼 이유를 분명히 남겼는지 확인할 필요가 있어요. 이런 항목이 빠지면 벤치마크 점수가 오른 모델이 실제 팀에는 더 많은 검토 시간을 요구할 수 있어요.

팀에서는 모델보다 작업 경계를 먼저 정해야 해요

이 문제를 줄이려면 요청을 무조건 길게 쓰기보다 모델이 멈춰야 할 조건을 정하는 편이 실용적이에요. 데이터 삭제와 스키마 변경, 새 의존성 추가, 비용이 생기는 외부 API 사용처럼 영향이 큰 행동은 실행 전에 승인을 받도록 정할 수 있어요. 요구사항이 두 가지 이상으로 해석되면 구현에 들어가기 전에 선택지를 묻게 만들 수도 있어요.

작업도 작게 나누는 편이 좋아요. 먼저 계획과 변경 파일 목록을 받고, 승인한 범위 안에서만 코드를 수정하게 하면 방향 이탈을 일찍 발견할 수 있어요. 테스트 통과 여부와 별개로 기존 설계 의도와 운영 비용을 검토하는 단계도 남겨야 해요. 모델의 추론 능력이 높아져도 제품 책임까지 모델에 넘길 수는 없어요.

왜 중요한가요

AI 코딩 도구를 고를 때 벤치마크 순위만 보면 실제 검토 비용을 놓칠 수 있어요. 더 많은 문제를 혼자 푸는 모델이라도 잘못된 가정을 빠르게 실행하면 개발자가 변경 내용을 되돌리고 맥락을 다시 설명해야 해요. 팀이 확인해야 할 지표에는 작업 성공률뿐 아니라 질문의 정확성, 승인 없는 범위 확장, 되돌림 횟수도 들어가야 해요. 2

모델 제공사에도 별도의 평가 과제가 생겨요. 모호한 요구사항을 일부러 넣고, 모델이 언제 질문하며 어떤 선택지를 제시하는지 측정해야 해요. 실행을 멈춘 행동을 무조건 실패로 처리하면 실제 업무에서 필요한 신중함이 훈련 과정에서 약해질 수 있어요.

이번 글은 Opus 5 전체 성능을 판정하는 실험 보고서가 아니에요. 특정 개발자의 경험과 그 원인에 대한 가설이에요. 도입을 검토하는 팀이라면 자체 코드베이스에서 같은 업무를 여러 모델에 맡기고, 완성된 코드와 함께 질문 횟수, 잘못된 가정, 감독 시간까지 기록해야 실제 협업 비용을 비교할 수 있어요.

참고 자료

1. Opus 5는 왜 함께 작업하기 더 불편하게 느껴지는가? — GeekNews
2. Why does Opus 5 feel worse to work with? — Mun logadan