대부분의 마이그레이션 가이드는 코드에서 무엇이 문제인지 알려줍니다. 이 가이드는 프롬프트에서 무엇이 문제인지에 대한 것입니다.
Claude Opus 5는 2026년 7월 24일에 출시되었으며, Anthropic은 이와 함께 전용 프롬프팅 가이드를 공개했습니다. 이 가이드에는 중요한 변화가 있습니다. Opus 4.8의 성능을 높이던 일부 지침이 Opus 5에서는 성능을 낮춥니다. 단순히 미묘한 차이가 아닙니다. 비용은 늘고, 응답은 길어지며, 일부 경우에는 에이전트 흐름이 제대로 작동하지 않을 수 있습니다.
이유는 간단합니다. Opus 5는 이전에 프롬프트로 요청해야 했던 여러 작업을 기본적으로 수행합니다. 기존 지침을 그대로 유지하면 모델의 기본 동작과 지침이 중복됩니다. 검증 패스는 늘어나지만 정확도가 그만큼 증가하지는 않습니다.
이 글에서는 문서화된 동작 변화별로 시스템 프롬프트에 바로 붙여 넣을 수 있는 스니펫을 제공합니다. 또한 사고(thinking)를 비활성화했을 때 에이전트 루프를 조용히 손상시킬 수 있는 두 가지 실패 모드도 다룹니다. 코드 수준 변경 사항은 별도의 Opus 4.8에서 Opus 5로의 마이그레이션 가이드를 참고하세요. 실제 요청과 응답 페이로드를 비교하려면 Apidog에서 동일한 프롬프트를 여러 설정으로 실행해 볼 수 있습니다.
한 줄 요약
Opus 5는 Opus 4.8보다 더 많이 검증하고, 더 많이 작성하고, 더 많이 위임하며, 더 많이 설명합니다.
Opus 4.8용 프롬프트는 이러한 동작을 끌어내기 위해 작성되었습니다. Opus 5에서는 반대로 상한선을 설정해야 합니다. 핵심 작업은 지침을 추가하는 것이 아니라 삭제하는 것입니다.
추가해야 할 내용은 주로 제약입니다.
- 더 간결하게 응답하기
- 요청 범위 밖으로 나가지 않기
- 불필요한 헬퍼나 서브 에이전트를 만들지 않기
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.
핵심은 다음과 같습니다.
-
모든 작업을 검증하라는 전역 지침은 비용 승수가 될 수 있습니다. - 특정 산출물 하나만 검증하도록 제한하면 동작을 제어할 수 있습니다.
API 비용도 함께 최적화하려면 Opus 5 가격 분석의 캐시 및 배치 옵션과 Claude API 청구서 절감 가이드를 함께 확인하세요.
2. 명확하게 간결성을 요청하세요
Opus 5의 기본 응답은 Opus 4.8보다 길어질 수 있습니다. 이는 일반 답변뿐 아니라 보고서, 요약, 설계 문서, README 같은 문서형 산출물에도 적용됩니다.
여기서 중요한 점은 effort가 응답 길이를 제어하지 않는다는 것입니다.
-
effort: 모델이 얼마나 많이 사고하는지 제어 - 프롬프트 제약: 모델이 얼마나 많이 작성하는지 제어
예를 들어 xhigh에서 medium으로 낮추면 사고 토큰은 줄어들 수 있지만, 사용자에게 보이는 응답 길이는 크게 달라지지 않을 수 있습니다. 각 수준의 실제 차이는 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.
코드 변경만 필요한 경우
설명보다 diff를 우선하도록 지정하세요.
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.
마지막 문장이 중요합니다.
If you believe another change is required,
stop and tell me instead of making it.
이 문장이 없으면 모델은 필요한 추가 변경을 자체적으로 수행하거나, 문제를 발견하고도 언급하지 않을 수 있습니다. 이 문장을 넣으면 변경되지 않은 diff와 함께 필요한 후속 작업을 보고받을 수 있습니다.
5. 수정 내러티브가 필요 없으면 끄기
Opus 5는 응답 도중 접근 방식이 바뀌면 이전 접근이 왜 잘못되었는지, 무엇을 수정했는지, 어떤 과정을 거쳤는지를 더 자주 설명할 수 있습니다.
대화형 작업에서는 유용합니다. 하지만 응답을 파서, 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)를 비활성화했을 때 Opus 5에서 간헐적으로 두 가지 아티팩트가 나타날 수 있다고 문서화합니다.
{
"thinking": {
"type": "disabled"
}
}
에이전트를 배포하기 전에 두 실패 모드를 모두 확인해야 합니다.
1. 일반 텍스트로 작성된 도구 호출
모델이 도구 호출처럼 보이는 내용을 출력하지만, 구조화된 tool_use 블록이 아니라 응답 본문의 텍스트로 반환할 수 있습니다.
이 경우 도구는 실행되지 않습니다.
단일 턴 채팅에서는 쉽게 발견할 수 있습니다. 하지만 에이전트 루프에서는 문제가 누적될 수 있습니다.
- 루프가 구조화된 도구 호출을 찾지 못합니다.
- 따라서 아무 작업도 실행하지 않습니다.
- 텍스트 형태의 가짜 호출은 대화 기록에 남습니다.
- 이후 턴이 이를 이미 실행된 호출처럼 해석할 수 있습니다.
출력이 명확히 잘못 보일 때는 이미 원인이 여러 턴 전의 기록에 남아 있을 수 있습니다.
2. 보이는 출력에 내부 XML 태그가 포함됨
<thinking> 같은 태그가 사용자에게 보이는 응답에 나타날 수 있습니다.
이는 보기 좋지 않을 뿐 아니라 다음과 같은 경우 더 큰 문제가 됩니다.
- 응답을 HTML로 렌더링하는 경우
- 구조 분석을 위해 출력 내용을 파싱하는 경우
- 응답을 다른 시스템의 입력으로 전달하는 경우
주의할 점은 태그 이름을 프롬프트에서 언급하면 문제가 개선되지 않을 수 있다는 것입니다.
다음과 같은 지침은 작성하지 않는 편이 좋습니다.
Never output <thinking> tags.
태그 토큰 시퀀스가 컨텍스트에 들어가면 오히려 나타날 가능성이 높아질 수 있습니다.
권장 완화책: thinking을 유지하고 effort를 낮추기
Anthropic의 권장 방식은 프롬프트 변경이 아니라 설정 변경입니다. 사고(thinking)를 유지하고 더 낮은 effort 수준으로 비용을 제어하세요.
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": {
"effort": "low"
},
"messages": [
{
"role": "user",
"content": "..."
}
]
}
이 방식은 사고(thinking) 비활성화에서 발생할 수 있는 아티팩트 없이 낮은 비용 범위를 사용할 수 있게 합니다.
추가로 알아둘 제한 사항도 있습니다.
-
thinking: {type: "disabled"}와xhigh또는maxeffort를 조합하면 400 오류가 반환됩니다. - 사고(thinking) 비활성화는
higheffort까지만 지원됩니다. - Opus 5에서는 사고(thinking)가 기본적으로 활성화됩니다.
- 따라서
thinking필드를 생략해도 Opus 4.8처럼 사고 없이 실행되는 것이 아니라 적응형 사고(adaptive thinking)로 실행됩니다.
사고(thinking)를 반드시 비활성화해야 한다면 프롬프트 대신 에이전트 루프에 방어 로직을 추가하세요. 실행되지 않은 도구 호출 형태의 문자열을 포함한 어시스턴트 턴은 대화 기록에 추가하기 전에 거부해야 합니다.
추측 대신 변경 사항 테스트
프롬프트 변경은 읽기만 해서는 평가하기 어렵습니다. 응답 길이, 검증 패스, 서브 에이전트 수 같은 차이는 토큰 수와 페이로드 구조에 나타납니다.
올인원 API 개발 및 테스트 플랫폼인 Apidog에서 다음 절차로 비교할 수 있습니다.
- Anthropic Messages 엔드포인트용 요청을 만들고
"model": "claude-opus-5"를 설정합니다. API 키는 요청 본문에 넣지 말고 환경 변수로 저장합니다. - 기존 Opus 4.8 시스템 프롬프트와 간결하게 조정한 Opus 5 프롬프트를 동일한 입력에 대한 별도 저장 요청으로 만듭니다.
- 각 응답의
usage블록을 비교합니다. 출력 토큰으로 간결성 제약의 효과를 확인하고, 입력 토큰 및 캐시 필드로 프롬프트 편집이 캐시 접두사에 미친 영향을 확인합니다. -
effort수준별로 요청을 복제합니다. 가시적 응답 길이는 비슷하지만 사고 토큰이 줄어드는지 확인합니다. - 스트리밍 응답을 검사해 도구 호출이 일반 텍스트가 아니라 구조화된
tool_use블록으로 도착하는지 확인합니다.
특히 5단계는 일반 텍스트 도구 호출 문제가 프로덕션에 도달하기 전에 잡아내는 데 중요합니다. 나란히 실행하려면 Apidog를 다운로드하고, 전체 요청 형식은 Opus 5 API 워크스루를 참고하세요.
솔직한 상한선
프롬프팅 가이드는 종종 특정 모델이 최종 해답인 것처럼 보이게 합니다. 하지만 Opus 5는 Claude 스택의 최상단이 아닙니다.
Fable 5는 “가장 유능하게 널리 배포된” 모델이라는 명칭을 유지하며, Opus 5는 사이버 보안 익스플로잇과 자율 생물학 연구에서 여전히 Mythos 5에 뒤처집니다. Anthropic은 자체 출시 게시물에서 이 두 내용을 언급합니다.
정확한 위치는 다음과 같이 볼 수 있습니다.
Opus 5는 프론티어급 기능을 프론티어 가격의 절반으로 제공하지만, 그 위에는 명시된 성능 상한선이 있다.
출시 벤치마크 주장인 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로 넘어올 때의 핵심 변화입니다.
- Opus 4.8: 기본 품질을 높이기 위해 프롬프트 작성
- Opus 5: 비용, 범위, 출력 형식의 상한선을 설정하기 위해 프롬프트 작성
여기서 시작한 뒤, Opus 4.8 설정값을 그대로 가져오지 말고 자체 평가에서 모든 effort 수준을 확인하세요. 수준별 동작이 재조정되었기 때문입니다.
추가 자료:
자주 묻는 질문
프롬프트에서 “작업을 다시 확인하세요”를 정말 삭제해야 할까요?
네. Anthropic의 프롬프팅 가이드에 따르면 Opus 5는 별도 프롬프트 없이도 검증을 수행하며, 기존 검증 지침은 과도한 검증을 유발할 수 있습니다. 전역 규칙은 제거하고, 검증이 꼭 필요한 특정 단계에만 제한적으로 적용하세요.
Opus 5는 낮은 effort에서도 왜 장황한가요?
effort는 사고(thinking)를 제어하며, 사용자에게 보이는 출력 길이를 직접 제어하지는 않습니다. effort를 낮추면 추론 토큰은 줄어들 수 있지만 응답 길이는 거의 유지될 수 있습니다. 단어 수, 출력 형식, 제외 항목을 프롬프트에 직접 지정하세요.
Opus 5가 서브 에이전트를 생성하지 못하게 하려면 어떻게 하나요?
직접 명시하세요.
Do not spawn subagents for this task. Handle it in this conversation.
분산 처리가 필요하다면 최대 개수를 지정하고, 독립적으로 병렬 처리 가능한 작업으로만 제한하세요.
출력에 <thinking> 태그가 보이는 이유는 무엇인가요?
사고(thinking)를 비활성화했을 때 간헐적으로 나타날 수 있는 아티팩트입니다. 태그 이름을 언급하는 프롬프트 지침은 추가하지 마세요. Anthropic의 권장 방식은 사고(thinking)를 활성화한 상태로 유지하고 낮은 effort로 비용을 제어하는 것입니다.
도구 호출이 일반 텍스트로 반환되면 어떻게 되나요?
도구는 실행되지 않습니다. 해당 텍스트가 대화 기록에 남으면 이후 턴이 이미 완료된 작업으로 잘못 해석할 수 있습니다. 어시스턴트 턴을 기록에 추가하기 전에 구조화된 도구 호출인지 검증하고, 가능하면 사고(thinking)를 비활성화하지 마세요.

Top comments (0)