Opus 5는 왜 함께 일하기가 더 불편하게 느껴질까?

나와 이야기를 나눈 동료들의 의견을 종합하면, Opus 5로 작업할 때 Opus 4.7, Opus 4.8, Fable보다 오히려 퇴보한 듯한 느낌을 받는다.

성능이 후퇴했다는 뜻은 아니다. Opus 5는 Opus 4.7과 Opus 4.8보다 더 뛰어난 모델이며, 벤치마크에서는 Fable과도 맞먹는다. 그런데도 실제로 함께 일하기에는 다른 모델들이 더 편하다. 그 이유는 이 모델들이 다음과 같이 행동하기 때문이라고 생각한다.

내 의도가 불분명하면 멈추고 질문한다.
확인하지 않은 채 가정하지 않는다.
묻지도 않고 내 계획을 다르게 해석하거나 수정하지 않는다.

그래서 이 모델들을 사용할 때는 Opus 5처럼 세심하게 지켜보며 챙길 필요가 없다.

근거 없는 추측

Anthropic을 비롯한 현재의 최전선 AI 연구소 전반에서 두 가지 요인이 맞물린 결과가 아닐까 추측한다.

첫째는 스스로를 재귀적으로 발전시켜 AGI/ASI에 도달할 수 있는 자기 개선형 AI를 만들려는 열망이다.

둘째는 벤치마크에서 높은 점수를 받아야 한다는 압박이다. 많은 벤치마크 과제가 정의부터 부실하거나 불공정하고, 편법으로 풀 수 있거나 다른 방식으로 망가져 있다는 사실은 공공연한 비밀이다. 하지만 좋은 벤치마크 과제는 그 자체로 완결돼 있다. 해결할 수 있어야 하며, 통과하기 위해 힌트를 받거나 출제자의 생각을 읽거나 외부 정보를 찾아야 해서는 안 된다.

좋은 과제에 정답이 하나뿐이어야 한다는 뜻은 아니다. 명백하게 옳은 모든 답에 같은 점수를 줘야 한다는 뜻이다.

벤치마크에서 좋은 성과를 내는 모델을 선별하면, 그리고 실제로 벤치마크나 전반적인 RLVR 과제를 활용해 훈련하면, 모호한 상황에서 과감하면서도 대체로 옳은 가정을 내리는 모델을 본질적으로 선택하게 된다. 반대로 멈춰서 설명이나 지시를 요청하는 모델은 불이익을 받는다.

안타깝게도 코딩 에이전트에게 우리가 원하는 행동은 바로 그 반대다.

아무리 애써도 모든 맥락과 의도, 비즈니스에 미칠 영향, 예산 제약을 비롯한 온갖 사항을 빠짐없이 문서화해 코딩 에이전트가 접근할 수 있게 만드는 일은 거의 불가능하다. 모호한 부분과 선택해야 할 문제는 반드시 생긴다. 필요할 때 에이전트가 멈춰서 질문한다는 사실을 알면 안심이 된다.

현실은 벤치마크가 아니다. 모든 질문에 반드시 정답이 있는 것도 아니고, 정답의 집합이 존재한다고 보장할 수도 없다. 실제 결과가 걸린 문제에서 에이전트가 최선이라고 짐작한 답을 멋대로 선택하기를 나는 원하지 않는다!

^source^{https://mun-logadan.github.io/why-does-opus-5-feel-worse/}

HN에서는 Opus 5가 코드를 만드는 능력과 별개로, 사람과 함께 일하기는 더 어려워졌다는 반응이 두드러졌다. 모호한 지시를 확인하지 않고 제멋대로 보완해 작업 범위를 넓히거나, 정해 둔 절차를 바꾸고도 미리 알리지 않는다는 지적이 이어졌다. 반면 질문은 충분히 한다는 사용자도 있었다. 다만 앞뒤 맥락과 지칭 대상을 생략한 채 물어 사용자가 질문의 뜻부터 다시 확인해야 했다고 한다.

가장 자주 거론된 문제는 장황하고 난해한 문체였다. 핵심을 바로 밝히지 않고 추상적인 표현과 새 용어를 덧붙이며, 간단한 요청에도 긴 설명과 과도한 주석을 만든다는 것이다. 요청하지 않은 예외 상황과 기능까지 처리하다가 시간과 토큰을 쓰고 본래 목적을 놓친 사례도 나왔다. 실제 벤치마크 대신 임시 로그를 읽거나, 지정한 원본이 아닌 네트워크 로그의 데이터를 사용한 경험은 결과뿐 아니라 검증 과정까지 살펴야 한다는 불신으로 이어졌다.

평가가 한쪽으로만 기울지는 않았다. 작업 범위를 엄격히 제한하고 Git 명령이나 문서 수정을 맡기지 않은 환경에서는 대규모 변경도 코드베이스의 형식에 맞춰 안정적으로 끝냈다는 경험이 있었다. 간결하고 직설적으로 답하게 출력 방식을 지정하거나, 구현 전에 불확실한 점을 먼저 묻도록 절차를 정하면 나아진다는 조언도 있었다. 하지만 같은 지침을 계속 되풀이해야 한다면 기본적인 협업 비용이 커진 셈이다.

따라서 모델을 고를 때는 벤치마크와 코드 생성 능력만 볼 수 없다. 지시한 범위를 지키는지, 가정을 실행 전에 드러내는지, 검증 과정과 시간·토큰 사용량을 예측할 수 있는지도 확인해야 한다. 긴 작업을 자율적으로 맡길지, 사람이 중간 판단을 이어갈지에 따라 모델의 역할과 허용 권한을 달리 정하는 편이 현실적이다.