대부분의 마이그레이션 가이드는 코드에서 무엇이 문제인지 알려줍니다. 이 가이드는 프롬프트에서 무엇이 문제인지에 대한 것입니다.
Claude Opus 5는 2026년 7월 24일에 출시되었으며, Anthropic은 이와 함께 전용 프롬프팅 가이드를 공개했습니다. 그 가이드는 주목할 만한 내용을 담고 있습니다: Opus 4.8을 더 좋게 만들었던 몇 가지 지침이 Opus 5를 더 나쁘게 만듭니다. 미묘하게 나빠지는 것이 아닙니다. 측정 가능하게 더 비싸고, 측정 가능하게 더 장황하며, 어떤 경우에는 아예 작동하지 않습니다.
이유는 간단합니다. Opus 5는 이미 자체적으로 요청해야 했던 여러 가지 작업을 수행합니다. 이전 프롬프트가 여전히 요청하면, 해당 지침은 모델이 이미 가지고 있는 동작과 중복됩니다. 두 배의 검증 패스를 얻게 되지만, 정확도가 두 배가 되는 것은 아닙니다.
이 가이드는 문서화된 각 동작 변화에 대해 오늘 시스템 프롬프트에 바로 삽입할 수 있는 복사-붙여넣기 프롬프트 스니펫과 함께 설명합니다. 또한 사고(thinking) 기능을 비활성화했을 때 나타나는 두 가지 실패 모드에 대해서도 다룹니다. 이는 Opus 5 프롬프트가 겉보기에는 괜찮아 보이는 출력을 생성하지만 에이전트 루프를 조용히 손상시킬 수 있는 유일한 지점입니다. 코드 수준의 변경 사항을 아직 검토 중이라면, Opus 4.8에서 Opus 5로의 마이그레이션 가이드에서 해당 내용을 별도로 다룹니다. 실제 요청 및 응답 페이로드에서 이러한 동작 변화를 확인하고 싶다면, Apidog는 동일한 프롬프트를 다른 설정으로 보내고 결과를 비교하는 간단한 방법입니다.
한 줄 요약
Opus 5는 Opus 4.8보다 더 많이 검증하고, 더 많이 쓰고, 더 많이 위임하며, 더 많이 설명합니다. Opus 4.8 프롬프트는 모델을 이러한 동작으로 유도하도록 조정되었습니다. 이제는 그 이상으로 나아갑니다.
따라서 작업은 제거하는 것입니다. 주로 지침을 추가하는 것이 아니라 삭제하는 것입니다. 추가하는 내용은 제약 사항입니다: 더 간결하게, 범위 내에서, 헬퍼를 생성하지 마세요.
1. 검증 지침 삭제
이것이 가장 중요한 부분이며, 제목의 이유입니다.
Anthropic은 Opus 5가 프롬프트 없이도 자체 작업을 검증한다고 명시합니다. 모델은 자신이 작성한 내용을 다시 읽고, 계산을 확인하고, 테스트를 다시 실행하며, 언급하지 않은 엣지 케이스를 찾습니다. 이는 "응답하기 전에 작업을 다시 확인하세요" 또는 "각 단계를 검증하세요"와 같은 지침으로 Opus 4.8에 수동으로 프롬프트했던 정확한 동작이었습니다.
이러한 지침을 그대로 사용하면 과도한 검증이 발생합니다. 모델은 어차피 실행했을 검증 패스에 더해 요청한 검증 패스도 실행하며, 이 모든 토큰에 대해 비용을 지불하게 됩니다. 긴 에이전트 실행에서는 이는 반올림 오차가 아닌 실제 청구서가 됩니다.
해결책은 삭제입니다. 시스템 프롬프트에서 다음 패턴을 찾아 제거하세요:
Double-check your work before responding.
Verify each step before moving to the next one.
Review your answer for errors, then revise it.
Check your reasoning carefully.
Make sure the output is correct before returning it.
정말로 중요한 단계에서 명시적인 검증 패스를 원한다면, 이를 전역 규칙으로 만들지 말고 해당 단계로 범위를 제한하세요:
Do not add general verification passes; you already verify by default.
The only exception: after writing the migration SQL, run it against the
schema dump once and report any mismatch. Do not re-verify anything else.
그 형태가 중요합니다. Opus 5에서 전역 "모든 것을 검증하라"는 지침은 비용 승수입니다. 단일 범위 예외는 제어입니다.
이 마이그레이션을 통해 API 지출을 추적하는 경우, Opus 5 가격 분석에 있는 캐시 및 배치 레버는 이와 함께 작동하며, Claude API 청구서 절감 가이드는 일반적인 레버를 다룹니다.
2. 명확하게 간결성을 요청하세요. 노력(effort)만으로는 해결되지 않습니다.
Opus 5의 기본 응답은 Opus 4.8보다 길어집니다. 문서를 요청했을 때 생성되는 보고서, 요약, 설계 문서, README 파일과 같은 작성된 결과물도 마찬가지입니다.
여기서 사람들이 혼란스러워하는 부분이 있습니다. effort 매개변수를 낮춘다고 해서 문제가 해결되지 않습니다. 노력(Effort)은 모델이 얼마나 생각하는지를 제어합니다. 모델이 얼마나 많이 작성하는지는 제어하지 않습니다. xhigh에서 medium으로 낮춰도 생각하는 토큰은 줄어들지만, 보이는 응답 길이는 거의 그대로 유지됩니다. 노력(effort)이 장황함 조절 다이얼이라고 생각했다면, 예상했던 방식으로 청구서가 바뀌지 않을 것입니다. Opus 5 노력(effort) 매개변수 가이드는 각 수준이 실제로 무엇을 변경하는지 다룹니다.
길이는 프롬프팅 문제입니다. 따라서 프롬프트에서 해결하세요. 모델이 관대하게 해석하는 "간략하게"라고 말하기보다는 상한선에 대해 구체적으로 명시하세요:
Response format: at most 150 words unless I ask for more.
No preamble, no restatement of my question, no summary at the end.
Lead with the answer, then the reasoning if it is needed.
작성된 결과물의 경우, 결과물에 제한을 두고 제외할 내용을 명시하세요:
Write the migration doc at 800 words maximum.
Include: the breaking changes, the fix for each, and a rollback step.
Exclude: background on the old system, a glossary, and a conclusion section.
If a section would exceed its share, cut examples before cutting steps.
코드 중심 작업의 경우, 이에 상응하는 제약은 코드 자체가 아닌 주석에 관한 것입니다:
Return the diff and nothing else.
No explanation of what you changed unless the change is non-obvious,
in which case one sentence above the hunk.
3. 서브 에이전트 위임 제한
Opus 5는 Opus 4.8보다 서브 에이전트에게 더 쉽게 위임합니다. 여러 부분으로 구성된 작업과 스폰(생성)을 지원하는 하네스가 주어지면, 작업을 분산시킵니다.
이는 종종 올바른 판단입니다. 또한 모델이 사용자를 대신하여 내리는 비용 결정이며, 각 서브 에이전트는 자체 컨텍스트와 자체 토큰 비용을 가집니다. 비용에 민감하거나 지연 시간에 민감한 워크로드의 경우, 모델의 판단에 맡기기보다 숫자를 지정하세요:
Do not spawn subagents for this task. Handle it in this conversation.
또는, 분산 처리가 실제로 유용하지만 제한되어야 할 때:
You may delegate to at most 2 subagents, and only for independent
file-level work that can run in parallel.
Do research, planning, and final synthesis yourself in this thread.
피해야 할 패턴은 그 자체를 위한 위임입니다: 한 파일을 읽기 위해 생성된 서브 에이전트, 또는 메인 스레드가 이미 컨텍스트를 가지고 있었던 결정을 내리기 위해 생성된 서브 에이전트. 서브 에이전트를 의도적으로 구축하는 경우, Claude 코드 서브 에이전트 생성 가이드는 서브 에이전트 범위를 지정하는 하네스 측면을 다룹니다.
4. 좁은 작업에 대한 범위 명시적 제한
Opus 5는 작업 범위를 확장합니다. 실패한 테스트를 수정해달라고 요청하면, 테스트가 호출하는 헬퍼를 리팩토링하고, 타입 시그니처를 업데이트하며, 두 개의 테스트 케이스를 더 추가할 수도 있습니다. 변수 이름을 변경해달라고 요청하면, 주변 함수를 정리할 수도 있습니다.
때로는 이것이 기능일 수도 있습니다. 그러나 좁고 정밀한 작업에서는 그렇지 않습니다. 요청하지 않은 리팩토링은 검토자가 읽어야 할 더 큰 diff를 의미하며, 한 줄 변경으로 예상되었던 것에 대해 더 큰 영향 범위를 가집니다.
경계를 명확히 하고, 허용되지 않는 것을 명시하세요:
Scope: change only the retry-count constant in src/client/http.ts.
Do not refactor surrounding code, do not rename anything, do not add
tests, do not update docs. If you believe another change is required,
stop and tell me instead of making it.
마지막 절은 유용한 부분입니다. 이것이 없으면 모델은 실제 문제를 제기할 공식적인 방법이 없으므로, 어쨌든 변경을 하거나 관찰 내용을 무시합니다. 이것이 있으면 플래그가 지정된 우려 사항과 변경되지 않은 diff를 얻게 됩니다.
5. 더 많은 수정 내러티브를 예상하고, 원하지 않으면 끄세요.
Opus 5는 Opus 4.8보다 수정 내용을 더 많이 설명합니다. 응답 중간에 생각이 바뀌면, 이전 접근 방식이 틀렸다는 것을 알리고, 그 이유를 설명하며, 전환 과정을 기술합니다.
대화형 작업에서는 유용합니다. 그러나 응답이 파서, UI 또는 다른 모델로 전달되는 파이프라인에서는 그러한 내러티브가 답변을 담아야 할 필드에 있는 노이즈가 됩니다.
지침은 간단합니다:
Do not narrate corrections or changes of approach.
Return only the final answer. If you revised your thinking, that
revision belongs in your reasoning, not in the response.
응답을 구조화된 저장소로 라우팅하는 경우, 요청보다는 형태가 강제되도록 구조화된 출력과 함께 사용하세요.
사고(thinking) 비활성화 시의 실패 모드
위에서 언급한 모든 내용은 튜닝 문제입니다. 이 부분은 정확성 문제입니다.
Anthropic은 thinking: {type: "disabled"}를 통해 사고(thinking) 기능이 비활성화되었을 때 Opus 5에서 간헐적으로 나타나는 두 가지 아티팩트를 문서화합니다. 에이전트를 배포하기 전에 이 두 가지를 모두 알아두는 것이 중요합니다.
일반 텍스트로 작성된 도구 호출. 모델이 도구 호출처럼 보이는 것을 내보내지만, 구조화된 tool_use 블록이 아닌 응답 본문의 텍스트로 나타납니다. 아무것도 실행되지 않습니다. 단일 턴 채팅에서는 알아차릴 수 있지만, 에이전트 루프에서는 종종 그렇지 않습니다. 루프는 도구 호출을 인식하지 못하므로 아무 조치도 취하지 않으며, 유출된 텍스트는 대화 기록에 남아 있습니다. 이후 턴은 해당 텍스트를 호출이 발생한 것처럼 읽습니다. 실패는 여러 턴에 걸쳐 누적되며, 출력이 잘못되어 보일 때쯤에는 원인이 여러 턴 전으로 거슬러 올라갑니다.
보이는 출력에 내부 XML 태그. <thinking>과 같은 태그가 사용자가 보는 응답에 나타납니다. 그 자체로도 미적으로 좋지 않으며, 응답을 HTML로 렌더링하거나 구조 분석을 위해 파싱한다면 더 나쁩니다.
직관적이지 않은 부분은 다음과 같습니다. 프롬프트에서 태그 이름을 지정하면 유출이 개선되는 것이 아니라 악화됩니다. "`<thinking>` 태그를 절대 출력하지 마세요"와 같은 지침은 토큰 시퀀스를 컨텍스트에 넣고 나타날 확률을 높입니다. 그러한 지침은 작성하지 마세요.
Anthropic 자체의 권장 완화책은 프롬프트가 전혀 아닙니다. 대신 사고(thinking) 기능을 활성화된 상태로 유지하고 더 낮은 노력(effort) 수준으로 비용을 제어하는 것입니다:
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
이는 사고(thinking) 기능 비활성화로 인한 아티팩트 없이 저렴한 범위의 끝을 얻게 합니다. 또한 관련 함정을 피하게 합니다. Opus 5에서 thinking: {type: "disabled"}를 xhigh 또는 max 노력(effort)과 결합하면 400 오류를 반환합니다. 이는 사고(thinking) 기능 비활성화가 high 노력(effort)으로 제한되기 때문입니다. 또한 사고(thinking) 기능은 이제 기본적으로 활성화되어 있으므로, thinking 필드를 단순히 생략하는 요청은 Opus 4.8에서처럼 사고(thinking) 기능 없이 실행되는 것이 아니라 적응형 사고(adaptive thinking)로 실행됩니다.
사고(thinking) 기능을 비활성화해야 하는 엄격한 요구 사항이 있다면, 프롬프트 지침 대신 루프에 방어적 검사를 추가하세요. 실행되지 않은 호출 형태의 문자열을 포함하는 어시스턴트 턴은 기록에 추가하기 전에 거부하세요. 유령 호출이 스크립트에 들어가도록 하는 대신 큰 소리로 실패를 알리세요.
추측 대신 변경 사항 테스트
프롬프트 변경 사항은 읽는 것만으로는 평가하기 어렵습니다. 여기의 동작(응답 길이, 검증 패스, 서브 에이전트 수)은 토큰 수와 페이로드 구조로 나타나므로, 작업을 확인하는 정직한 방법은 요청을 보내고 비교하는 것입니다.
올인원 API 개발 및 테스트 플랫폼인 Apidog에서 이를 설정하는 것은 간단합니다:
"model": "claude-opus-5"를 사용하여 Anthropic Messages 엔드포인트에 대한 요청을 하나 생성하고, API 키를 본문에 붙여넣는 대신 환경 변수로 저장하세요.- 이전 Opus 4.8 시스템 프롬프트와 간결하게 조정한 Opus 5 버전을 동일한 입력에 대한 두 개의 저장된 요청으로 저장하세요.
- 각 응답의
usage블록을 비교하세요. 출력 토큰은 간결성 제약이 적용되었는지 알려주고, 입력 토큰과 캐시 필드는 프롬프트 편집이 캐시 접두사를 손상시켰는지 알려줍니다. - 노력(effort) 수준별로 요청을 복제하여 가시적인 길이는 유지되면서 사고(thinking) 토큰이 감소하는 것을 직접 확인하세요.
- 스트리밍 응답을 검사하여 도구 호출이 텍스트가 아닌 구조화된
tool_use블록으로 도착하는지 확인하세요.
5단계는 일반 텍스트 도구 호출 실패가 프로덕션에 도달하기 전에 포착하는 단계입니다. 이들을 나란히 실행하고 싶다면 Apidog를 다운로드하고, 전체 요청 형태는 Opus 5 API 워크스루를 참조하세요.
솔직한 상한선
프롬프팅 가이드가 마치 이 모델이 마지막으로 필요한 모델인 것처럼 읽히는 경향이 있기 때문에 솔직하게 말하자면: Opus 5는 Claude 스택의 최상단이 아닙니다. Fable 5가 "가장 유능하게 널리 배포된" 모델이라는 명칭을 유지하며, Opus 5는 여전히 사이버 보안 익스플로잇과 자율 생물학 연구에서 Mythos 5에 뒤처집니다. Anthropic은 자체 출시 게시물에서 이 두 가지를 모두 언급합니다. 정확한 틀은 프론티어 가격의 절반으로 프론티어급 기능을 제공하며, 그 위에 명명된 상한선이 있다는 것입니다.
출시 벤치마크 주장(Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench)은 모두 Anthropic 자체 수치이며, 2026년 7월 25일 현재 독립적으로 재현되지 않았습니다. 이를 공급업체 보고로 취급하고, 실제로 배포하는 프롬프트에 대해 자체 평가를 실행하세요.
종합
비용에 민감한 에이전트 작업을 위한 간결한 Opus 5 시스템 프롬프트는 대략 다음과 같습니다:
Do not add verification passes; you verify by default.
Responses: 150 words maximum, no preamble, no closing summary.
Do not spawn subagents. Handle this in one thread.
Stay strictly within the task I state. If another change seems
required, stop and tell me rather than making it.
Do not narrate corrections or changes of approach.
6줄 중 5줄이 제약 사항이며, 어떤 것도 모델에게 더 열심히 노력하라고 요구하지 않습니다. 이것이 변화입니다. Opus 4.8에서는 바닥을 높이기 위해 프롬프트를 작성했습니다. Opus 5에서는 상한선을 설정하기 위해 프롬프트를 작성합니다.
거기서부터 시작하여, 4.8 설정값을 그대로 가져오지 말고 자체 평가에서 노력(effort) 수준을 전체적으로 확인하세요. 이는 수준이 재조정되었기 때문입니다. 매개변수 메커니즘은 노력(effort) 매개변수 가이드를 참조하고, 편집기 측면 워크플로는 Claude Code에서 Opus 5 사용하기를 참조하며, 전체 모델 그림은 Claude Opus 5란 무엇인가에서 시작하세요. Anthropic의 모델 개요에는 현재 사양 테이블이 있습니다.
자주 묻는 질문
프롬프트에서 "작업을 다시 확인하세요"를 정말로 삭제해야 할까요? 네. Anthropic의 프롬프팅 가이드에 따르면 Opus 5는 프롬프트 없이도 검증하며, 그대로 유지된 검증 지침은 과도한 검증을 유발합니다. 전역 규칙을 삭제하세요. 특정 단계에서만 명시적인 확인이 정말로 필요하다면, 해당 지침을 그 단계에만 한정하세요.
Opus 5는 낮은 노력(effort)에서도 왜 그렇게 장황한가요? 노력(effort)은 사고(thinking)를 제어하지, 가시적인 출력 길이를 제어하지 않기 때문입니다. 노력(effort)을 낮추면 추론 토큰은 줄어들지만, 응답 길이는 거의 동일하게 유지됩니다. 프롬프트 자체에 단어 또는 형식 제한을 설정하세요.
Opus 5가 서브 에이전트를 생성하는 것을 어떻게 막을 수 있나요? 직접적으로 명시하세요: "서브 에이전트를 생성하지 마세요; 이 대화에서 처리하세요." 분산 처리가 유용하다면, 숫자 상한을 지정하고 독립적인 병렬 작업으로 제한하세요.
출력에서 <thinking> 태그가 보이는 이유는 무엇인가요? 사고(thinking) 기능이 비활성화되었을 때 간헐적으로 나타나는 아티팩트입니다. 태그 이름을 명시하는 프롬프트 지침을 추가하지 마세요. 그렇게 하면 유출 가능성이 높아집니다. Anthropic의 권장 해결책은 사고(thinking) 기능을 활성화된 상태로 유지하고 더 낮은 노력(effort) 수준을 사용하여 비용을 제어하는 것입니다.
도구 호출이 일반 텍스트로 돌아오면 어떻게 되나요? 아무것도 실행되지 않으며, 유출된 텍스트는 대화 기록에 남아 나중에 완료된 작업으로 처리됩니다. 어시스턴트 턴을 기록에 추가하기 전에 유효성을 검사하고, 사고(thinking) 기능을 비활성화하는 것보다 활성화된 상태로 유지하는 것을 선호하세요.