Claude Opus 5 사용법: 지워야 할 프롬프트와 Effort 설정
Claude Opus 5 공식 문서 기준으로 지워야 할 검증 지시, Opus 4.8과의 차이, 작업별 Effort 설정과 실전 프롬프트를 정리합니다.
이런 분을 위한 글입니다
- 기존 Claude 프롬프트를 Opus 5에 맞게 고치고 싶은 분
- Claude Code의 속도·비용을 조절하고 실전 프롬프트를 바로 쓰고 싶은 분
읽고 나면 이렇게 달라집니다
- Opus 5에서 삭제할 재확인·검증 지시를 구분할 수 있다
- 작업에 맞는 Effort를 고르고 답변 길이·진행 보고·하위 에이전트를 제어할 수 있다
Claude Opus 5를 잘 쓰려면 프롬프트에 지시를 더하기 전에 불필요해진 지시부터 지워야 합니다.
Opus 5는 자신의 결과를 스스로 점검하고 잘못된 부분을 고치는 능력이 강해졌습니다. 예전 모델에서 품질을 높이려고 넣었던 재확인과 별도 검증 지시가 이제는 같은 작업을 반복하게 만들 수 있습니다. 이는 Anthropic의 Opus 5 프롬프트 공식 가이드에서 직접 삭제를 권하는 항목입니다.
이 글에서는 기존 프롬프트에서 무엇을 지워야 하는지, Effort를 어떻게 선택해야 하는지, 어떤 문장으로 바꾸면 좋은지 실제 예시와 함께 알아봅니다.
먼저 결론부터
Opus 5 사용법은 Opus 4.8과 많은 부분이 비슷합니다. Effort는 같은 다섯 단계를 사용하고, 기본값도 high이며, 원하는 결과의 길이와 범위는 프롬프트로 직접 알려줘야 합니다.
다만 기존 설정을 그대로 복사하면 안 됩니다. Opus 5는 낮은 Effort에서도 품질이 잘 유지되고, 스스로 검증하거나 하위 에이전트에 위임하는 행동이 늘었기 때문입니다.
| 확인할 것 | Opus 5에서 바꿀 점 |
|---|---|
| Effort | high에서 시작해 medium, low 순서로 다시 비교합니다. |
| 재확인 | “다시 확인”, “마지막에 검증”처럼 중복되는 지시를 지웁니다. |
| 하위 에이전트 | 독립적이고 큰 병렬 작업에만 사용하도록 범위를 좁힙니다. |
| 답변 길이 | Effort로 줄이지 말고 문장 수와 설명 수준을 직접 지정합니다. |
| 탐색 범위 | “중요한 것만”보다 먼저 전부 찾고 나중에 선별하게 합니다. |
Opus 4.8의 기본적인 Effort 개념과 작업별 프롬프트부터 보고 싶다면 Claude Opus 4.8 사용법도 함께 참고하세요.
Opus 5에서 프롬프트가 달라져야 하는 이유
Opus 5는 명시적으로 시키지 않아도 결과물을 검증합니다. 문제가 있으면 스스로 수정하고, 작업이 끝날 때까지 반복하기도 합니다.
따라서 기존 프롬프트에 아래와 같은 문장이 있다면 먼저 점검해야 합니다.
작업을 완료한 뒤 전체 결과를 다시 확인하세요.
오류가 없는지 별도의 검증 단계를 수행하세요.
다른 에이전트를 사용해 결과를 한 번 더 검토하세요.
답변하기 전에 반드시 재확인하세요.이 지시들은 모델이 이미 수행하는 검증과 겹칠 수 있습니다. 공식 문서에서는 이런 중복 지시를 제거하면 품질 저하 없이 낭비되는 토큰을 줄일 수 있다고 안내합니다.
수정 전과 수정 후
다음은 기존 프롬프트에서 중복 검증을 덜어낸 예시입니다.
# 수정 전
요청받은 기능을 구현하세요.
작업을 완료한 뒤 모든 파일을 다시 확인하세요.
별도의 검증 단계를 추가하고 다른 에이전트로 결과를 재검증하세요.
오류가 없는지 한 번 더 확인한 뒤 완료했다고 보고하세요.# 수정 후
요청받은 기능을 의도된 범위에서 끝까지 구현하세요.
결과에 영향을 주는 문제가 발견되면 수정하고 짧게 알려주세요.
요청을 다르게 해석했을 때 결과가 크게 달라지는 경우에만 확인을 요청하세요.수정 후 프롬프트는 검증을 금지하지 않습니다. Opus 5가 알아서 하는 검증은 그대로 두고, 검증을 반복하도록 강제하는 문장만 제거한 것입니다.
Opus 4.8과 사용법이 거의 같은가요?
큰 틀에서는 비슷합니다. 두 모델 모두 Effort 단계가 low, medium, high, xhigh, max로 나뉘고 API 기본값은 high입니다. 애매한 요청보다 결과물의 개수, 길이, 적용 범위를 구체적으로 알려주는 것이 좋다는 원칙도 같습니다.
차이는 어디서 시작하고 무엇을 덜어내느냐에 있습니다.
| 항목 | Opus 4.8 | Opus 5 |
|---|---|---|
| 코딩·에이전트 작업 | 보통 xhigh에서 시작 | 우선 high에서 시작해 직접 비교 |
| 낮은 Effort | 비용이 중요할 때 신중하게 사용 | 품질이 유지되면 low·medium을 적극 사용 |
| 검증 방식 | 구체적인 작업 단계를 나눠 지시하는 방식을 활용 | 완료 조건은 유지하되 일반적인 재확인·별도 검증 반복은 제거 |
| 하위 에이전트 | 큰 작업을 나누는 용도로 활용 | 작은 작업까지 과하게 위임하지 않도록 제한 |
| 응답 길이 | 길이와 형식을 직접 지정 | 이전보다 길어질 수 있어 더 명시적으로 지정 |
애매한 요청을 작업 기준으로 바꾸기
이 원칙은 Opus 4.8과 Opus 5에 모두 적용됩니다.
| 애매한 요청 | 더 나은 요청 |
|---|---|
| 잘 정리해주세요 | 핵심을 5개 항목으로 정리하고 각 항목은 2문장 이내로 작성해주세요. |
| AI 티가 안 나게 써주세요 | 과장된 표현을 줄이고 실제 사람이 설명하듯 짧은 문장으로 바꿔주세요. |
| 코드 봐주세요 | 버그 가능성, 데이터 손실 위험, 성능 문제, 테스트 누락 순서로 검토해주세요. |
| 이 형식으로 바꿔주세요 | 첫 부분뿐 아니라 모든 섹션에 같은 형식을 적용해주세요. |
| 모르는 것도 알아서 써주세요 | 근거가 부족한 내용은 추측하지 말고 “확인 필요”라고 표시해주세요. |
바로 사용할 수 있는 기본 프롬프트는 다음과 같습니다.
이 내용을 실무자가 바로 사용할 수 있는 가이드로 정리해주세요.
조건:
- 핵심 내용을 5개 항목으로 나눠주세요.
- 각 항목은 제목 1개와 설명 2~3문장으로 작성해주세요.
- 모든 섹션에 같은 형식을 적용해주세요.
- 각 항목에 바로 실행할 수 있는 예시를 하나씩 넣어주세요.
- 근거가 부족한 내용은 추측하지 말고 “확인 필요”라고 표시해주세요.1. 재확인 지시를 삭제하세요
가장 먼저 찾을 표현은 다시 확인, 재검증, double-check, verify, re-check입니다.
답변하기 전에 다시 검토하세요.
마지막에 전체 결과를 재확인하세요.
Double-check your answer before responding.
Verify the result one more time.
Re-check every step after completing the task.Opus 5는 별도로 요청하지 않아도 자신의 실수를 찾아 고칩니다. 위 문장을 반복해서 넣으면 결과가 좋아지기보다 이미 한 점검을 다시 수행할 가능성이 커집니다.
사용자에게 중요한 수정만 알리게 하고 싶다면 다음 프롬프트를 사용할 수 있습니다.
앞서 말한 내용의 오류가 사용자의 코드, 결론 또는 판단을 바꿀 때만 수정 사실을 알려주세요.
수정은 짧고 명확하게 설명한 뒤 작업을 계속하세요.
사용자에게 영향을 주지 않는 사소한 실수는 조용히 수정하고 넘어가세요.2. 검증용 하위 에이전트를 줄이세요
Opus 5는 이전 모델보다 하위 에이전트에게 작업을 쉽게 위임합니다. 여러 파일을 넓게 조사하는 큰 작업에는 유용하지만, 작은 작업에서는 비용과 대기 시간만 늘어날 수 있습니다.
다음과 같은 프롬프트는 간단한 작업에 과합니다.
이 문서의 맞춤법을 수정하세요.
작업이 끝나면 다른 에이전트를 생성해 수정 결과를 검증하세요.
두 에이전트의 결과가 일치하는지 다시 확인하세요.하위 에이전트를 지원하는 환경에서는 다음 기준을 추가하세요.
독립적이고 병렬 처리가 가능한 큰 작업에만 하위 에이전트에게 위임하세요.
몇 번의 도구 호출로 직접 끝낼 수 있는 작업은 위임하지 마세요.
자신의 작업을 검증하거나 재확인하는 용도로 하위 에이전트를 사용하지 마세요.
하나로 작업을 완료할 수 있다면 여러 에이전트 대신 하나만 사용하세요.
생성하는 에이전트 수는 가능한 한 낮게 유지하세요.하위 에이전트가 필요한지 판단하는 기준
아래 질문에 대부분 “예”라고 답할 수 있을 때만 위임을 고려하세요.
- 작업을 서로 의존하지 않는 덩어리로 나눌 수 있나요?
- 여러 작업을 동시에 실행하면 실제 완료 시간이 줄어드나요?
- 각 작업이 몇 번의 도구 호출만으로 끝나지 않을 만큼 큰가요?
- 여러 에이전트를 사용하는 비용보다 얻는 이점이 큰가요?
3. 처음부터 “중요한 것만” 찾게 하지 마세요
“중요한 것만”, “심각한 문제만”, “보수적으로 보고” 같은 표현은 효율적으로 들립니다. 하지만 코드 검토나 문서 검토에서는 모델이 탐색 범위를 좁히게 만들 수 있습니다.
# 놓칠 가능성이 있는 요청
이 코드에서 심각한 문제만 찾아주세요.
확실한 버그가 아니라면 보고하지 마세요.위 요청은 애매하지만 실제로 확인해야 할 문제까지 제외할 수 있습니다. 먼저 폭넓게 찾고, 다음 단계에서 우선순위를 정하도록 나누는 편이 좋습니다.
# 추천 요청
결과를 틀리게 하거나 테스트 실패 또는 사용자 오해를 만들 수 있는 문제를 모두 찾아주세요.
확신이 낮거나 사소해 보이는 항목도 탐색 단계에서는 포함하세요.
각 항목에 예상 심각도와 확신도를 표시하세요.
모든 항목을 나열한 다음 수정 우선순위가 높은 문제를 별도로 골라주세요.
순수한 스타일이나 이름 짓기 취향만 생략하세요.| 상황 | 범위를 좁히는 요청 | 추천 요청 |
|---|---|---|
| 문서 검토 | 위험한 조항만 찾아주세요 | 확인이 필요한 조항을 모두 찾고 위험도를 나눠주세요 |
| 원고 교정 | 치명적인 오류만 찾아주세요 | 어색하거나 잘못된 부분을 모두 찾고 꼭 고칠 항목을 골라주세요 |
| 자료 조사 | 핵심 내용만 조사해주세요 | 관련 내용을 먼저 수집하고 의사결정에 중요한 내용을 선별해주세요 |
| 코드 리뷰 | 심각한 버그만 보고하세요 | 동작에 영향을 줄 수 있는 문제를 모두 찾고 심각도를 표시하세요 |
4. Effort와 답변 길이를 분리하세요
Effort는 Claude가 한 응답에 사용하는 전체 작업량을 조절하는 설정입니다. 생각뿐 아니라 보이는 답변, 도구 호출과 함수 인자에 쓰는 토큰에도 영향을 줍니다. 다만 Opus 5에서는 Effort를 낮춰도 보이는 답변 길이가 안정적으로 짧아지지는 않으므로, 원하는 분량은 프롬프트로 따로 지정해야 합니다.
Opus 5가 지원하는 단계는 다음과 같습니다.
| Effort | 의미 | 일반적인 시작점 |
|---|---|---|
low | 속도와 비용을 우선합니다 | 간단한 분류, 짧은 요약, 반복 작업 |
medium | 품질과 효율의 균형을 맞춥니다 | 일상 업무, 자료 정리, 일반적인 에이전트 작업 |
high | 기본값이며 높은 품질을 목표로 합니다 | 복잡한 판단, 어려운 코딩, 처음 평가하는 작업 |
xhigh | 긴 탐색과 고난도 작업에 사용합니다 | 장시간 코딩, 여러 도구를 사용하는 에이전트 작업 |
max | 토큰 제한보다 최고 성능을 우선합니다 | 실패 비용이 매우 큰 최고 난도 작업 |
이 표는 고정된 정답이 아니라 시작점입니다. Effort 공식 문서는 Opus 5를 기본값인 high에서 시작하고, 실제 평가 결과를 기준으로 low·medium을 적극 활용하거나 어려운 작업에서 xhigh·max로 높이라고 안내합니다.
답변을 짧게 받는 프롬프트
Effort를 낮추는 대신 출력 길이를 직접 지시하세요.
답변은 핵심에 집중해 짧고 간결하게 작성하세요.
주의사항과 단서는 짧게 쓰고 답변의 대부분을 본론에 사용하세요.
상세한 설명을 요청받지 않았다면 요약 수준으로 답하세요.긴 시스템 프롬프트에서는 마지막에 짧은 알림을 추가할 수 있습니다.
<tone_preference>
출력은 적당히 간결하게 유지하세요.
</tone_preference>보고서나 마크다운 문서처럼 파일로 저장하는 결과물에는 다음 문장을 사용하세요.
문서 길이는 과제에 필요한 만큼 맞추세요.
다뤄야 할 내용은 충실하게 다루되, 채우기용 섹션이나 중복 요약 또는 형식적인 문구로 분량을 늘리지 마세요.5. 내 작업에 맞는 Effort를 찾으세요
같은 작업이라도 필요한 Effort는 다릅니다. 다른 사람이 만든 추천표를 그대로 적용하기보다 내 작업에서 품질이 유지되는 가장 낮은 단계를 찾아야 합니다.
1단계: High로 기준 결과 만들기
기본값인 high로 실제 작업을 실행합니다. 정확성, 누락, 실행 성공 여부를 기록합니다.
2단계: Medium으로 다시 실행하기
프롬프트와 입력을 그대로 유지하고 Effort만 medium으로 바꿉니다.
3단계: 결과 비교하기
요청한 항목이 빠지지 않았는지, 사실이나 코드에 오류가 없는지, 실제 사용 전에 추가 수정이 필요한지 비교합니다.
4단계: 품질이 유지되면 낮추기
차이가 없다면 medium을 사용합니다. 비용이나 속도가 더 중요하다면 low까지 같은 방식으로 비교합니다.
5단계: 품질이 떨어지면 되돌리기
누락이나 오류가 늘었다면 high로 돌아갑니다. 어려운 코딩이나 장시간 에이전트 작업이라면 xhigh도 비교합니다.
결과 비교를 Claude에게 맡길 때는 아래 프롬프트를 사용할 수 있습니다.
아래 두 결과를 같은 기준으로 비교해주세요.
1. 요청한 항목을 빠짐없이 다뤘는지 확인하세요.
2. 사실, 계산 또는 코드에 명백한 오류가 있는지 확인하세요.
3. 실제 사용 전에 추가 수정이 얼마나 필요한지 평가하세요.
4. 표현 취향보다 결과의 정확성과 완성도를 우선하세요.
5. 품질 차이가 없다면 더 짧은 시간과 적은 비용으로 만든 결과를 추천하세요.
[High 결과]
여기에 결과를 붙여 넣으세요.
[Medium 결과]
여기에 결과를 붙여 넣으세요.6. API에서 Effort 설정하기
Claude API에서는 output_config.effort로 단계를 지정합니다. 값을 생략하면 high가 적용됩니다.
curl https://api.anthropic.com/v1/messages \
--header "x-api-key: $ANTHROPIC_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "content-type: application/json" \
--data '{
"model": "claude-opus-5",
"max_tokens": 4096,
"messages": [
{
"role": "user",
"content": "이 코드에서 동작에 영향을 줄 수 있는 문제를 모두 찾아 심각도와 함께 정리해주세요."
}
],
"output_config": {
"effort": "medium"
}
}'xhigh와 max에서는 생각을 끌 수 없습니다. 이 단계에서 thinking: {"type": "disabled"}를 함께 보내면 API가 400 오류를 반환합니다.
또한 대화 중 Effort를 변경하면 이전 요청에서 만든 프롬프트 캐시 접두사가 다음 요청에 그대로 적용되지 않습니다. 캐시를 활용하는 긴 대화라면 대화 중 계속 바꾸기보다 작업 종류별로 Effort를 정해 유지하는 편이 좋습니다.
7. 진행 상황을 짧게 받는 프롬프트
Opus 5는 도구를 사용하는 작업에서 앞으로 할 일을 자주 설명하는 경향이 있습니다. 긴 자동화 작업에서는 업데이트 시점을 직접 지정하면 불필요한 중간 설명을 줄일 수 있습니다.
첫 도구 호출 전에 무엇을 하려는지 한 문장으로 알려주세요.
작업 중에는 중요한 사실을 발견했거나 진행 방향을 바꿀 때만 짧게 알려주세요.
작업이 끝나면 과정 설명보다 결과부터 말해주세요.
첫 문장에서 무엇이 완료됐는지 또는 무엇을 발견했는지 알려주세요.
세부 내용은 필요한 독자를 위해 결과 뒤에 정리하세요.8. 기존 프롬프트를 한 번에 점검하세요
아래 프롬프트에 기존 시스템 프롬프트나 CLAUDE.md를 붙여 넣으면 삭제, 수정, 유지할 항목을 한 번에 정리할 수 있습니다.
Claude Opus 5에 맞게 아래 프롬프트를 점검해주세요.
## 해야 할 일
1. 삭제할 지시, 수정할 지시, 유지할 지시를 분류해주세요.
2. 삭제하거나 수정한 이유를 항목마다 한 문장으로 설명해주세요.
3. 모든 변경을 반영한 최종 프롬프트 전문을 제공해주세요.
## 삭제 또는 수정할 항목
- 다시 확인, 재확인, double-check, verify, re-check처럼 중복 검증을 요구하는 지시
- 작업 마지막에 별도의 검증 단계를 강제하는 지시
- 검증만을 위해 다른 에이전트를 생성하게 하는 지시
- “생각하지 마세요” 또는 “추론하지 마세요” 같은 지시
- “중요한 것만”처럼 탐색 범위를 모호하게 좁히는 지시
- 답변 길이와 Effort를 같은 것으로 취급하는 지시
- 모든 상황에 적용하기 어려운 절대적인 금지 규칙
## 유지할 원칙
- 요청받은 작업의 범위
- 결과물의 형식과 길이
- 도구 사용과 외부 작업의 권한 범위
- 프로젝트에만 존재하는 주의사항과 예외
## 출력 형식
1. 삭제, 수정, 유지 항목을 표로 정리해주세요.
2. 변경 이유를 항목마다 한 문장으로 작성해주세요.
3. 최종 프롬프트 전문을 코드 블록으로 제공해주세요.
4. 수정 전후의 줄 수를 마지막에 표시해주세요.
## 점검할 프롬프트
[여기에 기존 프롬프트 또는 CLAUDE.md를 붙여 넣으세요]자주 묻는 질문
마무리
Opus 5용 프롬프트 개선은 새로운 문장을 계속 추가하는 작업이 아닙니다. 중복된 재확인과 검증 지시를 덜어내고, 하위 에이전트가 필요한 조건을 좁히고, 답변 길이를 직접 지정하는 작업입니다.
Effort는 high에서 시작하세요. 같은 작업을 medium과 low로 다시 실행해 품질이 유지되는 지점을 찾으면 됩니다. 어려운 코딩이나 장시간 에이전트 작업에서만 xhigh를 검토하고, 토큰보다 최고 성능이 중요한 경우에만 max를 사용하세요.
마지막으로 기존 프롬프트를 한 번에 전부 바꾸지 마세요. 지시 하나와 Effort 한 단계씩 바꾸고 결과를 비교해야 무엇이 실제로 효과가 있었는지 알 수 있습니다.