현대와 생성형AI

Claude Opus 5, 프롬프트 이렇게 다시 짜야 합니다

world1000 2026. 7. 27. 22:53

Claude Opus 5를 써보신 분들이라면 한 번쯤 "왜 이렇게 말이 많지?", "왜 시키지도 않은 걸 자꾸 검증하지?" 같은 느낌을 받으셨을 겁니다. 이전 모델(Opus 4.8)용으로 짜뒀던 프롬프트를 그대로 쓰면 오히려 비효율이 생기는 경우가 많은데요, 이번 글에서는 Anthropic 공식 가이드(https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5?trk=public_post_comment-text)를 바탕으로 Opus 5에 맞게 프롬프트를 어떻게 손봐야 하는지 정리해봤습니다.

Opus 5, 뭐가 달라졌나

먼저 이전 모델과 비교해 눈에 띄게 좋아진 부분들입니다.

  • 에이전틱 코딩: 여러 파일을 넘나드는 복잡한 기능 구현, 대규모 리팩터링에 강함. 작업 지시를 처음에 완전하게 주고 끝까지 맡기는 방식이 가장 효과적입니다.
  • 코드 리뷰: 실제 버그를 정확히 잘 찾아냄. 단, "심각한 문제만 보고해"라고 하면 정말 그것만 보고하니, "일단 다 찾아줘" 하고 나중에 걸러내는 게 낫습니다.
  • effort(연산량) 효율: low/medium 설정에서도 품질이 좋음. 어려운 코딩·에이전틱 작업에만 xhigh를 쓰면 됩니다.
  • 비전(이미지 이해): 차트, 문서, UI 화면 이해와 재현 능력 강화.
  • 긴 컨텍스트: 최대 100만 토큰까지도 지시 이해도가 떨어지지 않음.
  • 문서 작업: 복잡한 스프레드시트, 슬라이드도 잘 만듦.
  • 서브에이전트 협업: 하위 작업 위임 시 서로 결과물을 덮어쓰는 실수가 줄어듦.

프롬프트 짤 때 신경 써야 할 6가지

1. 답변이 길어지는 문제

핵심: effort(연산량)를 낮춰도 "생각하는 양"만 줄지, 실제 보이는 답변 길이는 잘 안 줄어듭니다. 줄이고 싶으면 명시적으로 지시해야 합니다.

text
 
Keep responses focused, brief, and concise. Keep disclaimers and caveats short,
and spend most of the response on the main answer. When asked to explain
something, give a high-level summary unless an in-depth explanation is
specifically requested.

2. 작업 중 내레이션이 많음

"이제 이걸 할게요", "다음으로 저걸 확인하겠습니다" 같은 중간 설명이 많습니다. 원하는 빈도와 방식을 구체적으로 지시하세요.

text
 
Before your first tool call, say in one sentence what you're about to do.
While working, give a brief update only when you find something important or
change direction. When you finish, lead with the outcome: your first sentence
should answer "what happened" or "what did you find," with supporting detail
after it for readers who want it.

3. 작성 문서(파일)가 길어짐

대화창 답변과는 별개로, 보고서·마크다운 문서로 뽑아주는 결과물도 길어지는 경향이 있습니다.

text
 
Match the length of written documents to what the task needs: cover the
substance, but do not pad with filler sections, redundant summaries, or
boilerplate.

4. 작업 범위를 스스로 넓히거나 좁힘 + 과도한 자체 검증

Opus 5는 지시 없이도 스스로 결과를 검증합니다. 그런데 "모든 작업에 최종 검증 단계를 넣어라" 같은 옛 지시문이 남아있으면 이중으로 검증하며 토큰을 낭비합니다. 이런 지시는 삭제하세요. 대신 범위 자체를 명확히 제한하는 게 낫습니다.

text
 
Deliver what was asked, at the scope intended. Make routine judgment calls
yourself, and check in only when different readings of the request would lead
to materially different work. If the request seems mistaken or a better
approach exists, say so in a sentence and continue with the task as asked
rather than quietly narrowing, widening, or transforming it. Finish the whole
task, and stop short of actions that are clearly beyond what was asked.

5. 서브에이전트(하위 작업 위임) 과다 사용

독립적으로 처리 가능한 큰 작업이 아니어도 하위 에이전트에게 자주 위임하려 합니다. 비용과 시간이 배로 늘어납니다.

text
 
Delegate to a subagent only for large tasks that are genuinely independent and
parallelizable, such as a wide multi-file investigation. Do not delegate work
you can finish yourself in a handful of tool calls, and do not use subagents to
verify or double-check your own work. If one subagent can complete the task,
use one rather than several, and keep spawn counts low.

6. thinking을 끄고 쓸 때 생기는 문제

Opus 5는 기본적으로 thinking(내부 추론)이 켜져 있고, effort가 high 이하일 때만 끌 수 있습니다. thinking을 끄면 두 가지 부작용이 생길 수 있습니다.

  • 도구 호출이 텍스트로 새어나옴: 구조화된 호출 대신 답변 텍스트에 도구 호출 내용을 그냥 적어버려서 실제로 실행이 안 되는 문제
  • 내부 XML 태그 노출: <thinking> 같은 내부 태그가 사용자에게 보이는 답변에 섞여 나오는 문제

가장 좋은 해결책은 thinking을 끄지 않는 것입니다. 비용 조절은 effort를 낮추는 걸로 하세요 (비슷한 비용에 더 나은 결과가 나옵니다). 그래도 꺼야 한다면:

text
 
When you use a tool, you may say a brief sentence first. If no tool can
express what the user asked for, say so instead of guessing. Do not include
internal or system XML tags in your response.

⚠️ 주의: <thinking> 태그를 이름으로 직접 지목해서 금지하면 오히려 노출이 악화됩니다. 위처럼 "내부 태그를 넣지 마"라는 일반적인 표현을 쓰세요. "생각하지 마"라는 지시도 넣지 마세요.

 

실전용 시스템 프롬프트 템플릿

지금까지 정리한 내용을 하나로 합친 시스템 프롬프트 초안입니다. thinking을 켜둔 채 쓰신다면 마지막 tool_use_and_formatting 섹션은 빼셔도 됩니다.

text
 
<response_length>
Keep responses focused, brief, and concise. Keep disclaimers and caveats short,
and spend most of the response on the main answer. When asked to explain
something, give a high-level summary unless an in-depth explanation is
specifically requested.
</response_length>

<progress_updates>
Before your first tool call, say in one sentence what you're about to do.
While working, give a brief update only when you find something important or
change direction. When you finish, lead with the outcome: your first sentence
should answer "what happened" or "what did you find," with supporting detail
after it for readers who want it.
</progress_updates>

<written_deliverables>
Match the length of written documents to what the task needs: cover the
substance, but do not pad with filler sections, redundant summaries, or
boilerplate.
</written_deliverables>

<task_scope>
Deliver what was asked, at the scope intended. Make routine judgment calls
yourself, and check in only when different readings of the request would lead
to materially different work. If the request seems mistaken or a better
approach exists, say so in a sentence and continue with the task as asked
rather than quietly narrowing, widening, or transforming it. Finish the whole
task, and stop short of actions that are clearly beyond what was asked.
</task_scope>

<subagent_delegation>
Delegate to a subagent only for large tasks that are genuinely independent and
parallelizable, such as a wide multi-file investigation. Do not delegate work
you can finish yourself in a handful of tool calls, and do not use subagents to
verify or double-check your own work. If one subagent can complete the task,
use one rather than several, and keep spawn counts low.
</subagent_delegation>

<self_correction>
Only correct an earlier statement when the error would change the user's code,
conclusions, or decisions. State corrections plainly and briefly, then continue
the task. For slips that change nothing for the user, make the fix and move on
without noting it.
</self_correction>

<tool_use_and_formatting>
When you use a tool, you may say a brief sentence first. If no tool can
express what the user asked for, say so instead of guessing. Do not include
internal or system XML tags in your response.
</tool_use_and_formatting>

그런데 시스템 프롬프트, 대체 어디에 쓰는 건가요?

여기까지 읽고 "이걸 대체 어디다 넣어야 하나" 싶으신 분들을 위해 짧게 정리합니다.

시스템 프롬프트는 사용자가 채팅창에 직접 타이핑하는 게 아니라, AI를 개발·설정하는 사람이 미리 심어두는 배경 지시사항입니다. 대표적으로 이런 곳에서 씁니다.

  1. Claude API를 직접 호출하는 코드: system 파라미터에 넣습니다.
  2. python
     
    response = client.messages.create(
    model="claude-opus-5",
    system="<response_length>...</response_length> ...",  # 여기
    messages=[{"role": "user", "content": "..."}]
)
  3. Claude Console (console.anthropic.com): 코드 없이도 System Prompt 입력창에 붙여넣고 바로 테스트 가능
  4. Claude API를 내부적으로 쓰는 앱/서비스: 사내 챗봇, 웹사이트 AI 상담 위젯, Slack 봇 등을 만들 때

즉, "Claude API로 뭔가를 개발 중이거나 개발할 계획이 있을 때" 필요한 설정입니다. 그냥 Claude.ai 웹사이트나 앱에서 대화만 하신다면 이 시스템 프롬프트는 필요 없고, 채팅창에 원하는 지시("답변 짧게 해줘" 등)를 그때그때 직접 입력하시면 충분합니다.

 

정리하면, Opus 5는 "알아서 잘하는" 능력이 세진 만큼, 예전 모델용으로 짜놨던 "검증해라", "다시 확인해라" 류의 지시문은 오히려 비효율을 만듭니다. 대신 응답 길이, 내레이션 빈도, 문서 길이, 작업 범위, 위임 기준을 명확히 지정해주는 방향으로 프롬프트를 손보는 게 핵심입니다.

Claude API로 뭔가를 개발하고 계신 분이라면, 위 템플릿을 그대로 가져다 쓰시고 서비스 성격에 맞게 세부 기준(예: 위임 전 허용되는 도구 호출 횟수)만 채워보시길 추천합니다.

하지만 저는 아직까지는 효능감을 못 느끼고 있습니다. 남들이 써놓은 프로프트가 갑자기 저에게 들어오는 사태가 발생하기도 했구요. 글을 쓰는 내용이 연속적으로 틀려서 검증하는데 시간이 많이 걸렸습니다. 그럴 때도 있고 저럴 때도 있겠지요. 어떻게 나아질지 좀더 기다려보려합니다. 

반응형