Opus 5의 장황함은 길들였지만 결함 하나가 남았다

Opus 5에게 두 줄짜리 수정을 요청하면 박사 논문이 돌아온다. Claude Code 서브레딧에서 "Opus 5 is insufferable"이라는 스레드는 600 업보트와 178개 댓글을 넘겼고, 작성자는 이 모델이 자기가 "Unintelligiblish"라 부르는 새 언어를 쓴다고 비난한다. 그런데 레딧은 그나마 점잖은 쪽이다. X에서는 한 개발자가 Opus 5가 생성한 코드 주석 스크린샷만 올려 9,700개의 좋아요를 모았다. Claude Code를 만든 Boris Cherny가 공개적으로 모델을 옹호했다가, "this response is part of the problem"이라는 최상위 답글에 2,843개의 좋아요가 붙는 역풍을 맞았다.

어디	신호
r/ClaudeCode, "Opus 5 is insufferable"	600+ 업보트, 178 댓글
X, Opus 5 코드 주석 스크린샷	9,700 좋아요
X, Boris Cherny 옹호글에 달린 답글	2,843 좋아요

불만이 쌓이는 동안 Anthropic은 Opus 5 전용 프롬프팅 가이드를 조용히 공개했다. 거의 아무도 열어보지 않은 문서다. 그래서 아무도 하지 않는 실험을 했다. 사람들을 미치게 하는 행동을 재현하고, 가이드를 한 줄씩 적용하고, 같은 작업에서 차이를 측정했다.

세 가지 변화가 지금 개발자들이 겪는 일의 대부분을 설명한다.

thinking이 기본으로 켜졌다. 모델은 모든 답변 전에 비공개 블록에서 추론하고, 끄는 것은 effort high 이하에서만 가능하다. 컨텍스트 윈도우는 100만 토큰으로 올라갔고, 이는 기본값이자 최대값이다. 그리고 장황함 불만에 직결되는 세 번째 변화가 effort다. 모델이 생각하고, 도구를 호출하고, 답을 쓰는 데 토큰을 얼마나 쓸지 정하는 이 파라미터가 중심 다이얼이 되었고, 다섯 단계에 기본값은 high다.

Effort	동작
Low	도구 호출을 묶고, 서두 없이 바로 작업하고, 한 문장으로 확인
High(기본)	호출을 늘리고, 무엇을 건드리기 전에 계획을 설명하고, 변경 사항을 상세히 주석
Extra high / Max	더 많은 파일을 탐색하고 엣지 케이스를 다지며, thinking을 더 이상 끌 수 없음

두 번째 줄이 딱 당신 세션처럼 들린다면 정상이다. 첫날부터 기본값으로 돌리고 있었을 테니까. effort는 장황함 손잡이가 아니다. 바로 그 오해가 레딧 스레드를 채우고 있다.

배경 하나 더. Anthropic은 Opus 5가 이전 Opus 모델들보다 긴 답을 쓰고, 자리표시자를 남기는 대신 작업을 끝까지 완료한다고 공개적으로 밝히고 있다. 버그처럼 느껴지는 것의 일부는 문서화된 설계 선택이며, 문서화된 선택은 다시 설정할 수 있다.

어느 하나 찾아 헤맬 필요가 없었다.

장황함. 함수 하나를 설명해 달라고 했다. 답이 두 문장이면 끝나는 질문인데, 섹션과 소제목과 경고가 붙은 감사 보고서 톤의 답변이 돌아왔다. 레딧 스레드 최상위 댓글도 정확히 그것을 묘사한다. "모든 것을 바꿀 무언가를 방금 발견했다" 같은 거창한 선언 문장, 그리고 10분치 셸 명령어.

과잉 설계. 한 사용자는 7,000줄짜리 의사결정 파일 이야기를 한다. 정리를 요청하자 Opus 5는 1,200줄을 잘라내고, 그 삭제 내용을 기록하려고 600줄을 새로 붙였다. 같은 패턴을 작은 기능에서 재현했다. 우리 인스턴스는 아무도 요청하지 않은 검증 단계를 추가하고, 다섯 줄짜리 함수 위에 스무 줄짜리 docstring을 썼다.

스코프 크리프. X를 요청하면 모델이 진짜 주제는 Y라고 판단하고, 그 이유를 여덟 문단으로 설명한다.

묻힌 나쁜 소식. 한 댓글 작성자는 모든 것이 잘됐다는 글의 벽을 묘사한다. 4분의 3쯤 내려간 자리에 뭔가 깨졌음을 인정하는 별표가 숨어 있다. 우리도 겪었다. 우리 인스턴스는 마이그레이션 성공을 선언했고, 통합 테스트가 아직 고쳐야 한다고 인정하는 줄은 일곱 번째 문단에 있었다.

분노는 진짜이고, 요청대로 재현된다. 남은 질문은 조절 가능한가다.

가이드 이름은 Prompting Claude Opus 5, Anthropic 문서에 있으며 레딧 스레드에 항목별로 답한다. 가장 중요한 문장은 한 줄이다. effort는 모델이 얼마나 생각하는지를 조절하지, 얼마나 말하는지를 조절하지 않는다. effort를 낮추면 사고량은 줄지만 눈에 보이는 답변이 안정적으로 짧아지지는 않는다. 즉 모델을 조용히 시키려고 effort를 낮추는 사람들은 전부 엉뚱한 레버를 당기고 있다.

길이에 대해 가이드는 분명하다. 시스템 프롬프트에 간결성 지시를 넣어 평범한 말로 요청하라는 것이다. 그리고 Anthropic에게서 기대하지 않을 말을 한다. 프롬프트에서 지시를 빼라는 것. 지시 파일에 "답하기 전에 작업을 검증하라"가 있다면 그 줄을 지워라. Opus 5는 이미 스스로 확인하고, 그런 줄은 추가 검증 패스를 유발한다. 결국 헛되이 태우는 토큰이다. Boris Cherny는 한 줄로 요약했다. Opus 5에는 더 많은 프롬프팅이 아니라 더 적은 프롬프팅이 필요하다고.

가이드의 나머지는 다른 불만들을 체계적으로 다룬다. 에이전트 내레이션 절, 생성 파일 길이 절, 스코프 프레이밍 절, 서브에이전트 절, 자기수정 절. 그리고 각 절은 모호한 조언이 아니라 복사해 쓸 정확한 프롬프트 블록을 준다.

effort sweep이란 같은 작업을 모든 effort 단계에서 돌려 토큰, 시간, 품질을 비교하는 것이다. 예전 모델의 설정을 그대로 들고 왔다면 다시 한 번 해보라고 가이드는 권한다. 실제로는 네 번의 실행과 한 번의 비교다.

Claude Code에서 effort는 세 가지 방법으로 설정한다. 세션 안의 명령, 실행 시 플래그, 설정 파일의 키. 마지막 방법은 저장소마다 요구가 다를 때 프로젝트별 기본값을 준다.

같은 버그 수정을 low, medium, high, extra high로, 깨끗한 세션 네 개에서 돌렸다.

단계	기준 버그 수정에서의 결과
Low / Medium	high 토큰의 일부만으로 동등한 수정
High	기본값. 한 줄짜리 버그에서는 품질 이득 없음
Extra high	더 많은 파일 탐색, 엣지 케이스 보강 — 무거운 리팩터에는 유용, 여기서는 과함

낮은 단계를 주된 비용 통제 수단으로 넉넉히 쓰라는 가이드의 안내와 정확히 맞는다. 스크립트로 만들기 전에 알아둘 API 세부 사항 하나. extra high와 max에서는 thinking을 더 이상 끌 수 없고, 시도하면 요청이 400 오류를 반환한다.

sweep의 가장 수익성 높은 용도는 코드 리뷰다. Anthropic은 Opus 5의 리뷰 정확도가 낮은 effort 단계에서도 유지된다고 주장하며, 이는 커밋 시점의 빠르고 싼 패스와 나중의 깊은 패스를 가능하게 한다. 우리 diff 하나로 시험했다. low 패스는 extra high 패스가 찾은 것과 똑같은 진짜 버그 두 개를 약 5분의 1의 토큰으로 찾아냈다.

그러니 청구서를 바꾸는 첫 설정은 모든 것을 기본값에 두지 말고 작업 유형별로 effort를 고르는 것이다. 일상 작업과 리뷰는 low나 medium, 큰 작업은 extra high. 반면 장황함은 한 단어도 줄지 않았다.

effort가 답을 줄이지 못하니 길이는 지시로 정해지고, 그 지시를 어디에 두느냐가 무엇이라 쓰느냐만큼 중요하다. Claude Code 서브레딧의 다른 사용자가 며칠에 걸쳐 이를 시험했고, 그의 첫 결론은 우리와 같다. 내장 Concise 출력 스타일은 출력을 약 6퍼센트만 줄인다. 통한 것은 진짜 간결성 지시를 output style 슬롯에 넣고 다른 어디에도 넣지 않는 것이었다. 같은 문장을 훅에 넣거나 지시 파일의 규칙으로 넣어도 아무것도 바뀌지 않았다.

output style은 어시스턴트가 무엇을 아는가가 아니라 어떻게 쓰는가를 정의하는 Claude Code의 슬롯이다. 우리 것은 공식 가이드의 문구로 만들었다. 짧고 초점 있는 답변, 경고 축소, 세부를 요청하지 않는 한 상위 수준 요약.

간결성 규칙의 위치	길이에 대한 효과
내장 Concise 프리셋	약 6퍼센트 짧아짐
훅, 또는 지시 파일의 규칙	측정 가능한 변화 없음
output style 슬롯	5개 섹션 보고서 → 한 문단과 파일 목록

가이드는 그대로 베껴 온 자매 지시 두 개를 더한다. 하나는 에이전트 내레이션용으로, 모델이 자기가 하는 일을 언제 언급해도 되는지를 규정한다. 다른 하나는 디스크에 쓰는 파일용인데, 생성되는 보고서와 마크다운 파일도 똑같이 부풀기 때문이다.

절대 발동하지 않는 규칙들에 대해서는 같은 레딧 글이 기준을 준다. 규칙은 알아볼 수 있는 순간과 구체적인 행동을 지목해야 한다. "changelog를 최신으로 유지하라"는 절대 발동하지 않는다. "소스 폴더의 파일을 수정하면 같은 커밋에서 changelog에 한 줄을 추가하라"는 발동한다.

이 블록들로도 덮이지 않는 말버릇이 하나 남는다. 서술되는 자기수정이다. Opus 5는 앞 문장을 고치고 있다고 알리기를 좋아하는데, 그 수정이 당신에게 아무 영향이 없을 때조차 그렇다. 가이드에는 전용 지시가 있다. 오류가 당신의 코드나 판단을 바꿀 경우에만 수정을 알리고, 나머지는 조용히 고치라는 것. 이 줄이 설정에 들어간 뒤로 가짜 사과문은 세션에서 사라졌다.

그러니 장황함은 길들여진다. 다만 스위치가 아니라, 올바른 슬롯에 놓인 프롬프트 블록 네 개로.

두 번째 불만은 글을 더하는 게 아니라 빼서 해결된다. 우리는 가이드가 지시한 대로 프롬프트에서 모든 검증 요구를 먼저 걷어냈고, 여분의 검증 루프도 함께 사라졌다.

그다음 스코프. 가이드는 프레이밍 지시를 제공하고, 우리는 그대로 붙였다. 요청받은 것을 의도된 범위로 전달하고, 더 나은 접근이 있으면 한 문장으로 알리고, 요청받은 작업을 몰래 바꾸지 말고 그대로 진행하라. 스무 줄 docstring을 유발했던 그 기능에서 정확히 같은 요청을 이 프레이밍과 함께 다시 돌렸다. diff는 건드린 파일 아홉 개에서 세 개로 줄었고, 기생적인 검증 단계도 없었다.

같은 계열의 설정 두 개는 각각 한 줄씩 값어치가 있다. 코드 리뷰에서는 "심각한 문제만 보고하라"라고 쓰지 마라. Opus 5는 그것을 문자 그대로 받아들여 과소 보고하니, 전부 달라고 한 뒤 두 번째 패스에서 걸러라. 그리고 모델이 툭하면 서브에이전트를 띄운다면 그것도 문서화돼 있다. Opus 5는 이전 세대보다 쉽게 위임하고, 서브에이전트 하나마다 비용이 배가된다. 가이드는 위임을 진짜로 병렬화되는 큰 작업에만 두는 지시를 주고, 버전 2.1.217부터 Claude Code는 spawn 깊이와 동시 실행 에이전트 수를 하드 캡으로 막는 환경 변수 두 개도 노출한다.

상한	기본값
서브에이전트 spawn 깊이	3단계
동시 실행 에이전트	20

이 기본값이, 세션이 당신 의견을 한 번도 묻지 않고 그렇게까지 번져 나갈 수 있는 이유를 설명한다. 오버엔지니어링은 모델의 운명이 아니다. 상당 부분은 당신의 오래된 프롬프트가 당신을 향해 되돌아온 것이다.

한계는 분명하다. 가이드는 Opus 5가 말하는 것의 형태를 고치지, 그것이 하기로 결정하는 것을 고치지 않는다. 스레드의 성토 중 일부는 장황함이 아니라 다른 것을 묘사한다. 명시적 제약을 인지하고 지키겠다고 약속한 뒤, 첫 턴부터 반대로 하는 모델이다. 이 불만에는 가이드의 절이 없고, 우리 프롬프트 블록 어느 것도 그것을 없애지 못했다. 테스트 중 한 번 봤다. 건드리지 말아야 할 API에 대한 명시적 제약이 답변 안에서 인지된 뒤, 두 턴 뒤에 우회됐다. 일주일치 세션에서 한 번이면 일부 성토가 그리는 난파와는 거리가 멀지만, 프로덕션 코드에 떨어지면 어떤 설정으로도 변명이 안 되는 종류의 오류다.

진입 비용도 계산해야 한다. sweep은 실제 토큰을 태운다. 우리 네 번의 테스트 세션은 20달러 플랜에서 큰 하루치 작업에 해당하는 양을 먹었고, 스레드의 한 사용자는 가장 큰 max 플랜조차 effort high에서 주말 하나를 겨우 버틴다고 전한다. 게다가 이 설정들은 어느 것도 이식되지 않는다. output style도, 스코프 프레이밍도, 서브에이전트 상한도 전부 당신의 설정 안에 있으니 기기마다 프로젝트마다 다시 맞춰야 한다.

당신의 고통이 소음이라면 가이드가 해결한다. 당신의 고통이 제멋대로 구는 모델이라면 가이드는 구해주지 않는다. 그리고 그 스레드에서 성토 본문 다음으로 업보트가 많은 댓글은 여전히 "이전 Opus로 돌아가라"다.

우리에겐 20분의 설정이면 충분했다. 기본값 대신 작업 유형별로 고른 effort, output style 슬롯의 간결성 지시 하나, 시스템 프롬프트에 넣은 가이드의 스코프 프레이밍, 그리고 오래된 파일에서 지운 검증 요구들.

기준 작업에서의 지표	이전	이후
답변 길이	5개 섹션 보고서	약 5배 짧게, 한 문단 + 파일 목록
diff 크기	파일 9개 수정	파일 3개 수정
코드 리뷰 비용	extra high 패스	토큰 약 1/5, 같은 진짜 버그 2개

모델도 플랜도 바꾸지 않고서다. 불만이 장황함과 오버엔지니어링이라면 모델을 갈아타기 전에 이 튜닝부터 해보라. 전부 문서화돼 있고, 차이는 첫 diff부터 보인다. 하지만 문제가 첫 턴부터 당신의 제약을 무시하는 모델이라면 가이드의 어떤 프롬프트도 그것을 고치지 못한다. 민감한 작업은 말을 듣는 모델에 남겨두고, 다음 업데이트에서 Opus 5를 다시 시험해 보라.