Claude Opus 5 프롬프트 가이드: ‘다시 검증해’를 지워야 하는 이유

Opus 5, ‘다시 검증해’는 지우세요.

Anthropic 공식 프롬프트 가이드의 권고입니다.

조금 이상하게 들립니다. 우리는 AI 코딩 결과가 불안할수록 검증 단계를 더 붙여왔습니다. “마지막에 한 번 더 확인해”, “답변하기 전에 재검증해”, “서브에이전트에게 검토시켜” 같은 지시를 시스템 프롬프트와 스킬, 하네스에 계속 쌓아왔죠.

그런데 Anthropic의 Claude Opus 5 공식 프롬프팅 가이드는 이런 명시적 재검증 지시를 제거하라고 권고합니다. Opus 5는 별도 지시가 없어도 스스로 작업을 검증하기 때문에, 같은 행동을 다시 시키면 과도한 검증으로 이어질 수 있다는 설명입니다.

Anthropic은 해당 지시를 제거하면 품질 저하 없이 낭비되는 토큰을 줄일 수 있다고 밝힙니다. 기존 하네스에 별도 검증 단계를 추가해둔 레거시 구조도 같은 점검 대상입니다.

핵심 요약

• Opus 5는 별도 지시가 없어도 스스로 작업을 검증합니다.
• 무조건적인 최종 검증과 재검증 지시는 모델의 기본 행동과 겹쳐 토큰을 낭비할 수 있습니다.
• 자신의 결과를 확인하려고 서브에이전트를 호출하는 패턴도 줄이는 것이 좋습니다.
• 테스트, CI, 타입 검사처럼 실제 증거를 만드는 외부 검증 체계까지 없애라는 의미는 아닙니다.
• effort는 생각하는 양을 조절하지만 사용자에게 보이는 답변 길이를 자동으로 줄여주지는 않습니다.
• 비용을 조절할 때는 thinking을 끄기보다 thinking을 켠 채 낮은 effort를 먼저 검토하는 편이 좋습니다.

Anthropic이 직접 지우라고 한 두 문장

공식 문서는 명시적인 검증 지시의 예로 다음 두 표현을 듭니다.

“include a final verification step for any non-trivial task”

“use a subagent to verify”

한국어로 옮기면 “중요한 작업마다 최종 검증 단계를 포함하라”, “서브에이전트를 사용해 검증하라” 정도입니다.

이런 문장은 겉으로 보면 좋은 안전장치입니다. 실제로 이전 모델에서는 결과를 확인하지 않고 끝내거나, 구현만 하고 테스트를 생략하는 문제를 줄이는 데 도움이 됐을 수 있습니다.

하지만 Opus 5에서는 전제가 달라졌습니다. 모델이 이미 자체 검증과 자기교정을 수행하는데 프롬프트가 같은 행동을 다시 강제하면, 한 번이면 충분한 확인을 여러 번 반복할 수 있습니다. 검증의 품질이 높아지는 것이 아니라 같은 범주의 확인만 겹칠 수 있다는 뜻입니다.

공식 가이드는 답변 전 double-check, 응답 전 re-verify 같은 재확인 지시도 피하라고 안내합니다. 이런 지시가 모델의 자체 교정 행동과 중첩되면 비용은 늘지만 결과가 개선되지는 않는다는 설명입니다.

검증이 많을수록 안전하다는 착각

검증은 많을수록 좋다고 생각하기 쉽습니다. 하지만 검증에는 서로 다른 두 종류가 있습니다.

첫 번째는 새로운 증거를 만드는 검증입니다.

• 테스트를 실행해 실제 동작을 확인합니다.
• 타입 검사와 빌드로 정적 오류를 찾습니다.
• 브라우저에서 화면을 캡처해 시각적 결과를 확인합니다.
• 보안 리뷰에서 권한과 공격 경로를 별도로 살펴봅니다.
• 결제, DB, 배포처럼 실패 비용이 큰 작업에 사람 승인을 둡니다.

두 번째는 같은 판단을 말로 반복하는 검증입니다.

• 작성한 답변을 다시 읽어보라고 합니다.
• 같은 컨텍스트를 가진 모델에게 한 번 더 생각하라고 합니다.
• 작은 작업에도 검증용 서브에이전트를 무조건 호출합니다.
• 작업 종류와 상관없이 동일한 최종 점검표를 매번 실행합니다.

첫 번째 검증은 새로운 실패 신호를 만듭니다. 두 번째 검증은 같은 추론을 반복할 가능성이 큽니다.

제가 이번 공식 가이드에서 더 중요하게 본 지점이 바로 이것입니다. 검증 단계의 개수가 아니라, 각 검증이 새로운 증거를 만드는지 봐야 합니다.

지울 검증과 남길 검증

“재검증 지시를 지우라”는 말을 “테스트와 CI도 필요 없다”로 받아들이면 안 됩니다. 공식 문서가 직접 지목한 것은 모델의 기본 행동과 겹치는 명시적 재검증 지시와 별도 검증 단계를 추가한 레거시 하네스입니다.

실무에서는 다음처럼 구분해보면 좋습니다.

지우거나 줄일 후보	남겨야 할 후보
모든 작업에 붙는 “마지막에 다시 검증해”	테스트, 빌드, 타입 검사, 린트
답변 전 double-check, re-verify	구체적인 완료 조건과 합격 기준
작은 작업의 무조건적인 검증 서브에이전트	보안, 결제, DB, 배포의 외부 품질 게이트
모델의 자체 검증과 같은 범주의 점검표	브라우저 캡처, 실제 API 응답 등 독립된 증거
이전 모델의 약점을 보완하려고 만든 범용 재확인 절차	크고 독립적인 작업에 필요한 별도 리뷰

핵심은 검증을 포기하는 것이 아닙니다. 모델에게 같은 판단을 반복시키는 검증은 줄이고, 실제 결과를 보여주는 검증은 남기는 것입니다.

예를 들어 “구현이 맞는지 다시 생각해”보다 bun test, pytest, tsc, Playwright 같은 실행 결과가 더 강한 증거입니다. “화면이 괜찮은지 재검토해”보다 실제 렌더링 화면을 캡처해 비교하는 편이 낫습니다.

서브에이전트는 언제 써야 할까

Opus 5는 이전 모델보다 서브에이전트를 적극적으로 호출하는 경향이 있습니다. 멀티 에이전트 조율 능력도 좋아졌지만, 잘 조율할 수 있다는 사실과 항상 호출해야 한다는 결론은 다릅니다.

Anthropic은 서브에이전트가 도움이 되는 조건을 다음처럼 좁힙니다.

• 작업이 충분히 큽니다.
• 서로 독립적으로 진행할 수 있습니다.
• 병렬화했을 때 실제 시간이 줄어듭니다.
• 메인 에이전트가 몇 번의 도구 호출만으로 끝내기 어렵습니다.

반대로 작은 문서 수정, 파일 한두 개 조사, 간단한 설정 변경에 여러 에이전트를 붙이면 작업보다 조율 비용이 커질 수 있습니다. 컨텍스트를 다시 전달하고, 결과를 취합하고, 충돌을 확인하는 데 토큰과 시간이 더 들어가죠.

특히 공식 가이드는 자신의 작업을 재확인하거나 이중 확인하기 위한 서브에이전트 사용을 피하라고 권합니다.

이 말은 독립 리뷰라는 패턴이 항상 나쁘다는 뜻은 아닙니다. 대규모 리팩토링, 보안 검토, 서로 다른 전문성이 필요한 조사처럼 검증자가 새로운 관점과 독립된 증거를 만들 수 있는 작업이라면 여전히 가치가 있습니다.

문제는 역할 이름만 Verifier로 붙이고 동일한 컨텍스트와 동일한 판단을 반복하게 만드는 구조입니다. 이름이 다르다고 검증이 독립적인 것은 아닙니다.

effort를 낮춰도 답변은 자동으로 짧아지지 않는다

Opus 5 비용을 줄이려고 effort부터 낮추는 경우가 많습니다. 방향 자체는 맞을 수 있습니다. Anthropic은 low와 medium effort에서도 강한 품질을 낼 수 있으며, 토큰과 지연 시간을 조절하는 주요 수단으로 활용하라고 안내합니다.

다만 한 가지 구분해야 합니다.

effort는 모델이 얼마나 생각할지를 조절합니다. 사용자에게 얼마나 길게 말할지를 직접 조절하지는 않습니다.

그래서 effort를 낮췄는데도 답변이 길 수 있습니다. 사용자에게 보이는 응답을 줄이고 싶다면 다음처럼 출력 길이를 별도로 지정해야 합니다.

핵심 결론부터 간결하게 답하세요.
주의사항은 짧게 쓰고, 자세한 설명은 요청받았을 때만 확장하세요.

대화 응답뿐 아니라 보고서와 Markdown 문서의 길이도 따로 조절하는 편이 좋습니다. “필요한 내용은 포함하되, 반복 요약과 형식적인 섹션으로 분량을 채우지 말라”는 식으로 산출물 길이 기준을 명시할 수 있습니다.

thinking은 끄기보다 낮은 effort부터

비용을 줄이기 위해 thinking을 완전히 끄는 것도 기본 해법은 아닙니다.

Anthropic은 대부분의 작업에서 thinking을 켠 low effort가 비슷한 비용의 thinking off보다 더 나은 성능을 낸다고 안내합니다. thinking을 끈 상태에서는 도구 호출이 일반 텍스트로 노출되거나 내부 XML 태그가 사용자 응답에 나타나는 문제도 간헐적으로 발생할 수 있습니다.

실무 적용 순서는 이렇게 잡는 편이 안전합니다.

1. 기본값인 high에서 품질 기준을 확인합니다.
2. 같은 평가셋으로 medium과 low를 비교합니다.
3. 품질이 유지되는 작업부터 effort를 낮춥니다.
4. 응답 길이는 별도의 간결성 지시로 조절합니다.
5. 정말 필요한 통합에서만 thinking off를 검토합니다.

모든 작업을 무조건 low effort로 바꾸라는 뜻은 아닙니다. 중요한 코딩 작업과 긴 에이전트 실행에는 더 높은 effort가 필요할 수 있습니다. 공식 가이드도 demanding coding과 agentic work에는 xhigh까지 높일 수 있다고 설명합니다.

결국 비용 최적화는 전역 스위치가 아니라 작업별 평가 문제입니다.

Opus 5.5로 옮겨도 유효할까

결론부터 말하면 재검증 지시를 지우라는 원칙은 그대로 가져가셔도 됩니다. Anthropic의 Opus 5.5 프롬프팅 가이드는 기존 Opus 5 프롬프트가 수정 없이도 잘 동작하고, Opus 5 가이드의 패턴이 여전히 합리적인 출발점이라고 안내합니다.

다만 effort와 thinking은 다시 보셔야 합니다.

항목	Opus 5	Opus 5.5
기본 effort	high	medium
thinking 끄기	high 이하에서 가능	불가능(항상 켜짐)
같은 effort 이름	모델 간 생각량이 같지 않음	Opus 5에서 쓰던 값을 다시 측정

Anthropic은 Opus 5.5의 medium이 Opus 5의 high와 같거나 더 나은 결과를 냈다고 설명합니다. 반대로 Opus 5에서 쓰던 effort 값을 그대로 두면 한 턴이 더 길어지고 출력 토큰이 늘 수 있다고 안내하죠. 그래서 위에서 말씀드린 thinking off 관련 내용은 Opus 5 통합에만 해당합니다. Opus 5.5로 옮길 때는 “생각하지 마라” 같은 규칙을 지우고, effort를 여러 단계로 다시 비교해보는 게 맞습니다.

effort 단계별로 같은 과제를 돌려 비교한 결과는 Claude Opus 5.5 effort 레벨별 비교에 따로 정리했습니다.

Opus 5 하네스 다이어트 체크리스트

Claude Code나 자체 에이전트 하네스에 규칙이 많이 쌓여 있다면 다음 순서로 점검해보세요.

1. 무조건적인 재검증 문장을 찾습니다

always verify, double-check, re-verify, “반드시 다시 확인”, “최종 검증 필수” 같은 문장을 검색합니다.

2. 새로운 증거를 만드는지 분류합니다

테스트와 빌드처럼 새로운 신호를 만드는 단계인지, 모델에게 같은 판단을 반복시키는 단계인지 구분합니다.

3. 서브에이전트 호출 조건을 좁힙니다

모든 작업에 검증자를 붙이지 않습니다. 크고 독립적이며 병렬화 가치가 있는 작업에만 사용하도록 조건과 최대 개수를 정합니다.

4. 한 덩어리씩 제거하고 비교합니다

하네스를 한 번에 비우지 않습니다. 재검증 지시 하나를 제거한 버전과 기존 버전을 같은 작업으로 비교합니다. 품질, 토큰, 지연 시간, 실패 유형을 함께 봅니다.

5. 출력 길이와 사고량을 분리합니다

비용은 effort로 조절하고, 사용자 응답과 문서 길이는 별도 지시로 조절합니다.

6. 모델 업그레이드를 마이그레이션 이벤트로 봅니다

모델만 교체하고 프롬프트와 스킬, 훅, 에이전트 규칙을 그대로 두지 않습니다. 새 모델의 기본 행동과 겹치는 장치가 없는지 공식 문서와 실제 평가로 다시 확인합니다.

좋은 하네스는 검증이 많은 하네스가 아니다

강한 모델이 나올 때마다 하네스에 규칙을 더 붙이는 방식은 오래가기 어렵습니다. 이전 모델이 못 하던 일을 보완하려고 만든 지시가 새 모델에서는 중복과 마찰이 될 수 있기 때문입니다.

그렇다고 모든 규칙과 검증을 없애자는 것도 아닙니다.

좋은 하네스는 모델에게 같은 말을 여러 번 시키는 구조가 아닙니다. 목표와 경계를 분명히 하고, 실패 비용이 큰 곳에는 실제 증거를 만드는 품질 게이트를 두고, 작은 작업은 가볍게 통과시키는 구조에 가깝습니다.

제가 말하고 싶은 건 이겁니다.

모델이 강해질수록 무엇을 더 시킬지보다, 무엇을 이제 그만 시켜도 되는지 확인하는 능력이 중요해집니다.

Opus 5로 업그레이드했다면 프롬프트와 하네스에서 가장 오래된 “다시 검증해”부터 찾아보세요. 그 지시가 아직 새로운 증거를 만들고 있는지, 아니면 모델이 이미 하는 일을 반복시키고 있는지 비교해보면 좋겠습니다.

관련 자료

• Anthropic 공식 가이드: Prompting Claude Opus 5
• Anthropic 공식 가이드: Prompting Claude Opus 5.5
• AI 코딩 하네스도 리팩토링이 필요합니다
• 프롬프트 부채: Claude Fable 5에서 기존 프롬프트가 품질을 떨어뜨리는 이유
• Loop Engineering: AI 코딩에서 검증과 재시도를 시스템으로 설계하는 법