Claude 프롬프트 엔지니어링 가이드 소개
Anthropic이 Claude 최신 모델군을 위한 프롬프트 엔지니어링 모범사례(Best Practices) 문서를 단일 레퍼런스로 정리해 공개했습니다. 이 가이드는 새로 출시된 Claude Opus 4.8을 비롯해 Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5까지를 대상으로, 기초적인 명료성 원칙부터 출력 제어, 도구 사용, 사고(thinking), 그리고 에이전트 시스템 설계에 이르는 내용을 한 곳에 담고 있습니다. 흥미로운 점은 이 문서가 단순한 팁 모음이 아니라, 모델 세대가 바뀔 때마다 어떤 프롬프트를 어떻게 다시 손봐야 하는지에 대한 마이그레이션 관점을 전면에 내세우고 있다는 것입니다.
프롬프트 엔지니어링은 한때 "마법 주문 찾기"처럼 여겨졌지만, 최신 모델이 지시를 점점 더 문자 그대로(literal) 따르게 되면서 그 성격이 달라졌습니다. 과거에는 모델이 알아서 의도를 추측해주길 기대하며 모호한 프롬프트를 던졌다면, 이제는 원하는 동작을 명확히 명시하고 모델 세대별 기본값(default)의 변화를 이해하는 것이 핵심 역량이 되었습니다. 특히 Claude Opus 4.6 이후 모델들은 시스템 프롬프트에 훨씬 민감하게 반응하기 때문에, 이전 모델을 위해 작성된 "CRITICAL: 반드시 ~하라" 같은 강한 표현이 오히려 과잉 동작(overtriggering)을 유발하는 역설이 나타납니다.
이 게시물은 원문 가이드를 바탕으로, Claude API와 Claude Code 같은 에이전트 환경에서 모델을 다루는 개발자가 알아야 할 핵심 원칙들을 주제별로 재구성한 것입니다. 각 절에는 원문의 권장 프롬프트 스니펫을 영어 원문 그대로 함께 실어, 실제 시스템 프롬프트에 바로 옮겨 쓸 수 있도록 했습니다. 새로 추가된 Claude Opus 4.8 전용 프롬프팅부터 살펴보겠습니다.
Claude Opus 4.8 전용 프롬프팅: 새 모델의 기본값 이해하기
Claude Opus 4.8은 장기 호흡(long-horizon) 에이전트 작업, 지식 노동, 비전, 메모리 작업에서 특히 강점을 보이며, 기존 Claude Opus 4.7용 프롬프트에서도 별도 수정 없이 잘 동작합니다. 다만 새 모델은 몇 가지 기본 동작이 달라졌고, 이를 이해하지 못한 채 옛 프롬프트를 그대로 쓰면 의도와 어긋나는 결과를 얻을 수 있습니다.
노력(effort)과 사고 깊이 조정
가장 중요한 변화는 노력 파라미터(effort parameter) 의 위상입니다. effort 파라미터는 모델의 지능과 토큰 소비량 사이의 트레이드오프를 조정하는 다이얼로, 원문은 "이번 모델에서는 그 어떤 이전 Opus보다 effort가 중요할 가능성이 높으니, 업그레이드할 때 적극적으로 실험하라"고 강조합니다. 권장 기본값은 다음과 같습니다.
| effort 레벨 | 권장 용도 |
|---|---|
max |
지능이 가장 많이 요구되는 작업. 다만 토큰을 더 써도 성능 향상이 점점 줄어드는(diminishing returns) 구간이 있고, 때때로 과잉 사고(overthinking)에 빠질 수 있음 |
xhigh |
대부분의 코딩 및 에이전트 작업에 최적 |
high |
토큰과 지능의 균형. 지능이 중요한 대부분의 작업에서 최소 기준선 |
medium |
토큰을 아끼되 일부 지능을 트레이드오프하는 비용 민감 작업 |
low |
짧고 범위가 명확한 작업, 지능 민감도가 낮은 지연(latency) 민감 워크로드 |
Claude Opus 4.8은 effort 레벨, 특히 낮은 쪽을 엄격하게 준수합니다. low나 medium에서는 요청받은 범위만 처리하며 "기대 이상"으로 움직이지 않습니다. 따라서 복잡한 문제에서 추론이 얕다고 느껴지면, 프롬프트로 우회하기보다 effort를 high나 xhigh로 올리는 것이 정석입니다. 지연 때문에 low를 유지해야 한다면 다음처럼 표적 지침을 추가합니다.
This task involves multi-step reasoning. Think carefully through the problem before responding.
또 한 가지 중요한 변화는 Claude Opus 4.8에서 사고(thinking)가 기본적으로 꺼져 있다는 점입니다. thinking: {type: "adaptive"} 를 명시적으로 설정해야 켜지며, 적응형 사고의 발동 동작도 프롬프트로 조정 가능합니다. 크고 복잡한 시스템 프롬프트 때문에 모델이 생각보다 자주 사고에 들어간다면 다음처럼 안내할 수 있습니다.
Thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multi-step reasoning. When in doubt, respond directly.
심화 학습: effort와 adaptive thinking
응답 길이, 도구 호출, 그리고 더 문자적인 지시 따르기
Claude Opus 4.8은 응답 길이를 고정된 장황함이 아니라 작업의 복잡도에 맞춰 보정합니다. 단순 조회에는 짧게, 열린 분석에는 훨씬 길게 답하는 식입니다. 제품이 특정 스타일이나 분량에 의존한다면 프롬프트로 조정해야 하며, 원문은 장황함을 줄이는 예시로 "Provide concise, focused responses. Skip non-essential context, and keep examples minimal." 를 제시합니다. 흥미롭게도, 무엇을 하지 말라는 부정 예시보다 적절한 간결함을 보여주는 긍정 예시 가 더 효과적이라고 강조합니다.
도구 사용 측면에서 Claude Opus 4.8은 도구 호출보다 추론을 선호하는 경향 이 있습니다. 대부분의 경우 이것이 더 나은 결과를 내지만, 도구 사용을 늘리고 싶다면 effort를 high나 xhigh로 올리는 것이 효과적인 지렛대입니다. 에이전트 검색이나 코딩에서 이 설정은 눈에 띄게 더 많은 도구 사용을 보여줍니다.
새 모델의 또 다른 특징은 더 문자적인 지시 따르기(literal instruction following) 입니다. Claude Opus 4.8은 프롬프트를 문자 그대로 해석하며, 한 항목에서 다른 항목으로 지시를 조용히 일반화하지 않고, 요청하지 않은 작업을 추론해서 수행하지도 않습니다. 이 문자주의(literalism)는 정밀함과 적은 헛수고라는 장점이 있어, 잘 다듬어진 프롬프트, 구조화된 추출, 예측 가능한 동작이 필요한 파이프라인에서 더 나은 성능을 냅니다. 다만 지시를 넓게 적용하길 원한다면 그 범위를 명시해야 합니다.
"이 서식을 첫 번째 섹션뿐 아니라 모든 섹션에 적용하라(Apply this formatting to every section, not just the first one)"처럼 적용 범위를 분명히 밝혀야 모델이 일반화합니다.
진행 업데이트, 톤, 그리고 인터랙티브 코딩
Claude Opus 4.8은 긴 에이전트 트레이스 내내 더 규칙적이고 질 높은 사용자 대상 진행 업데이트(user-facing progress updates) 를 제공합니다. 따라서 이전 모델을 위해 "도구 호출 3번마다 진행 상황을 요약하라" 같은 강제 스캐폴딩을 넣어두었다면, 이제는 제거하는 편이 낫습니다. 업데이트의 길이나 내용이 사용 사례에 맞지 않으면 원하는 형태를 프롬프트로 명시하고 예시를 제공합니다.
문체에도 변화가 있습니다. Claude Opus 4.8은 직접적이고 의견이 분명한(opinionated) 스타일을 지향하며, 비위를 맞추는 표현(validation-forward phrasing)과 이모지 사용을 절제합니다. 제품이 특정 목소리에 의존한다면 새 기준선에 맞춰 스타일 프롬프트를 재점검해야 합니다. 예를 들어 더 따뜻하고 대화체인 톤을 원한다면 "Use a warm, collaborative tone. Acknowledge the user's framing before answering." 를 추가합니다.
Claude Code 같은 인터랙티브 코딩 제품을 만든다면 토큰 사용 패턴도 알아둘 만합니다. Claude Opus 4.8은 단일 사용자 턴으로 끝나는 자율(asynchronous) 코딩 에이전트보다, 여러 사용자 턴이 오가는 인터랙티브(synchronous) 환경에서 토큰을 더 많이 사용 하는 경향이 있습니다. 사용자 턴 이후에 더 많이 추론하기 때문인데, 이는 긴 세션의 일관성과 코딩 능력을 높이는 대신 토큰을 더 씁니다. 성능과 토큰 효율을 모두 잡으려면 xhigh나 high effort를 쓰고, 자동 모드(auto mode) 같은 자율 기능을 더해 사용자 상호작용 횟수를 줄이며, 첫 턴에서 작업과 의도, 제약을 충분히 명확하게 명시하는 것이 좋습니다. 모호한 프롬프트를 여러 턴에 걸쳐 점진적으로 전달하면 토큰 효율과 성능이 오히려 떨어질 수 있습니다.
서브에이전트 생성과 코드 리뷰 하니스 튜닝
Claude Opus 4.8은 기본적으로 더 적은 수의 서브에이전트(subagent) 를 생성합니다. 이 동작은 프롬프트로 조정 가능하며, 언제 서브에이전트가 바람직한지 명시적으로 안내하면 됩니다.
Do not spawn a subagent for work you can complete directly in a single response (e.g. refactoring a function you can already see).
Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.
코드 리뷰 하니스를 운영하는 개발자라면 특히 주목할 부분이 있습니다. Claude Opus 4.8은 이전 모델보다 버그를 잘 찾지만, 이전 모델에 맞춰 튜닝된 하니스 에서는 오히려 재현율(recall)이 낮아 보일 수 있습니다. "고심각도 이슈만 보고하라", "보수적으로 하라", "사소한 것은 지적하지 말라" 같은 지시를 새 모델이 더 충실하게 따르기 때문입니다. 모델은 동일한 깊이로 코드를 조사하고 버그를 찾아내지만, 사용자가 정한 기준선 아래라고 판단한 발견은 보고하지 않습니다. 정밀도(precision)는 오르지만 측정된 재현율은 떨어지는 현상이 나타나는 것입니다. 원문은 발견 단계와 필터링 단계를 분리하라며 다음 프롬프트를 권합니다.
Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.
이 변화는 PyTorchKR에서도 다룬 바 있는 Claude Opus 4.8의 정직성 강화 및 동적 워크플로우 특성과 맞닿아 있습니다. 모델 자체의 동작 변화를 먼저 이해해야 프롬프트 튜닝의 방향이 잡힙니다.
일반 원칙: 모든 세대에 통하는 기본기
모델 세대가 바뀌어도 변하지 않는 기초 원칙들이 있습니다. 원문은 이를 "Claude를 맥락이 없는 똑똑한 신입사원처럼 대하라"는 비유로 요약합니다.
명확하고 직접적으로 지시하기
Claude는 명확하고 명시적인 지시에 잘 반응합니다. "기대 이상"의 결과를 원한다면 모호한 프롬프트로 모델이 알아서 추론하길 바라지 말고, 그것을 명시적으로 요청해야 합니다. 원문의 황금률(Golden rule) 이 인상적입니다.
"당신의 프롬프트를 작업 맥락이 거의 없는 동료에게 보여주고 따라 해보게 하라. 그가 헷갈린다면 Claude도 헷갈린다(Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too)."
분석 대시보드를 만드는 예시를 보면 차이가 분명합니다. "Create an analytics dashboard" 대신 "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation." 처럼 수식어(modifier)를 더하면 산출물의 완성도가 크게 올라갑니다.
맥락(context)을 더해 성능 끌어올리기
지시의 이유 를 설명하면 Claude가 목표를 더 잘 이해하고 표적화된 응답을 내놓습니다. 원문의 예시가 이를 잘 보여줍니다. 단순히 "NEVER use ellipses" 라고 쓰는 대신, "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." 처럼 이유를 덧붙이면 모델이 그 설명으로부터 일반화합니다.
예시(few-shot)와 XML 태그 구조화
예시(example) 는 Claude의 출력 형식, 톤, 구조를 조정하는 가장 신뢰할 만한 방법 중 하나입니다. 잘 만든 몇 개의 예시(few-shot 또는 multishot 프롬프팅)만으로도 정확도와 일관성이 극적으로 향상됩니다. 좋은 예시는 (1) 실제 사용 사례를 가깝게 반영하고(Relevant), (2) 엣지 케이스를 포함하며 충분히 다양하고(Diverse), (3) <example> 태그로 감싸 지시와 구분되도록(Structured) 만들어야 합니다. 원문은 최상의 결과를 위해 3~5개의 예시를 권합니다.
XML 태그 는 지시, 맥락, 예시, 변수 입력이 뒤섞인 복잡한 프롬프트를 Claude가 모호함 없이 파싱하도록 돕습니다. 각 콘텐츠 유형을 <instructions>, <context>, <input> 같은 고유 태그로 감싸면 오해를 줄일 수 있습니다. 일관되고 서술적인 태그 이름을 쓰고, 자연스러운 위계가 있으면 태그를 중첩합니다.
역할 부여와 긴 컨텍스트 다루기
시스템 프롬프트에서 역할(role) 을 설정하면 Claude의 동작과 톤이 사용 사례에 맞게 집중됩니다. 단 한 문장이라도 차이를 만듭니다.
import anthropic
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
system="You are a helpful coding assistant specializing in Python.",
messages=[
{"role": "user", "content": "How do I sort a list of dictionaries by key?"}
],
)
print(message.content)
대용량 문서(20k 토큰 이상)를 다룰 때는 구조가 중요합니다. 핵심 원칙은 세 가지입니다. 첫째, 긴 데이터를 프롬프트 상단에 배치합니다. 질의와 지시, 예시보다 위에 긴 문서를 두면 모든 모델에서 성능이 크게 향상됩니다(원문은 복잡한 다중 문서 입력에서 응답 품질이 최대 30%까지 개선될 수 있다고 밝힙니다). 둘째, 여러 문서는 <document> 태그로 감싸고 <document_content>, <source> 등의 하위 태그로 메타데이터를 구조화합니다. 셋째, 응답을 인용에 근거(ground) 시킵니다. 긴 문서 작업에서는 Claude가 작업 전에 관련 부분을 먼저 인용하도록 시키면 문서의 노이즈를 걷어낼 수 있습니다.
<documents>
<document index="1">
<source>annual_report_2023.pdf</source>
<document_content>
{{ANNUAL_REPORT}}
</document_content>
</document>
<document index="2">
<source>competitor_analysis_q2.xlsx</source>
<document_content>
{{COMPETITOR_ANALYSIS}}
</document_content>
</document>
</documents>
Analyze the annual report and competitor analysis. Identify strategic advantages and recommend Q3 focus areas.
모델 자기 인식(model self-knowledge)
애플리케이션에서 Claude가 자신을 올바르게 식별하거나 특정 모델 문자열을 사용하도록 하려면, 시스템 프롬프트에 정체성을 명시합니다. 예를 들어 "The assistant is Claude, created by Anthropic. The current model is Claude Opus 4.8." 처럼 적어두고, LLM 모델 문자열이 필요한 앱이라면 "...The exact model string for Claude Opus 4.8 is claude-opus-4-8." 를 덧붙입니다. 모델은 학습 시점 이후 출시된 자신의 정확한 버전명을 모를 수 있으므로, 이 정보를 프롬프트로 주입하는 것이 안전합니다.
출력과 형식 제어
무엇을 하지 말지가 아니라 무엇을 할지 말하기
최신 Claude 모델은 이전보다 간결하고 자연스러운 소통 스타일을 가집니다. 사실 기반의 담백한 진행 보고를 하고, 효율을 위해 도구 호출 후 장황한 요약을 생략하기도 합니다. 추론 과정을 더 보고 싶다면 "After completing a task that involves tool use, provide a quick summary of the work you've done." 를 추가합니다.
형식을 제어하는 가장 효과적인 방법은 금지가 아니라 지시 입니다. "Do not use markdown in your response" 대신 "Your response should be composed of smoothly flowing prose paragraphs." 라고 쓰는 식입니다. XML 형식 지시자(<smoothly_flowing_prose_paragraphs> 태그 활용)도 효과적이며, 프롬프트의 스타일을 원하는 출력 스타일과 일치 시키는 것도 강력한 기법입니다. 프롬프트에서 마크다운을 걷어내면 출력의 마크다운도 줄어듭니다. 마크다운과 불릿을 최소화하려면 다음처럼 상세히 지시합니다.
<avoid_excessive_markdown_and_bullet_points>
When writing reports, documents, technical explanations, analyses, or any long-form content, write in clear, flowing prose using complete paragraphs and sentences. Use standard paragraph breaks for organization and reserve markdown primarily for `inline code`, code blocks (```...```), and simple headings (###, and ###). Avoid using **bold** and *italics*.
DO NOT use ordered lists (1. ...) or unordered lists (*) unless : a) you're presenting truly discrete items where a list format is the best option, or b) the user explicitly requests a list or ranking
Instead of listing items with bullets or numbers, incorporate them naturally into sentences. This guidance applies especially to technical writing. Using prose instead of excessive formatting will improve user satisfaction. NEVER output a series of overly short bullet points.
Your goal is readable, flowing text that guides the reader naturally through ideas rather than fragmenting information into isolated points.
</avoid_excessive_markdown_and_bullet_points>
LaTeX 출력과 프리필(prefill) 마이그레이션
최신 Claude 모델은 수학 표현, 방정식, 기술적 설명에 기본적으로 LaTeX 를 사용합니다. 예를 들어 어텐션은 \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V 처럼 렌더링됩니다. 평문을 원한다면 "Format your response in plain text only. Do not use LaTeX..." 같은 지시를 추가해야 합니다.
또 하나의 중요한 변화는 프리필 응답(prefilled responses)의 종료 입니다. Claude 4.6 모델부터 마지막 어시스턴트 턴에 대한 프리필이 더 이상 지원되지 않으며, 프리필이 포함된 요청은 400 에러를 반환합니다. 모델의 지능과 지시 따르기가 향상되어 대부분의 프리필 사용 사례가 불필요해졌기 때문입니다. 마이그레이션 경로는 다음과 같습니다.
| 기존 프리필 용도 | 대체 방법 |
|---|---|
| JSON/YAML 등 출력 형식 강제 | Structured Outputs 기능, 또는 그냥 스키마를 따르도록 지시 |
Here is... 같은 도입부 제거 |
시스템 프롬프트로 직접 지시, XML 태그 출력, 또는 후처리로 제거 |
| 부적절한 거부(refusal) 우회 | 최신 모델은 거부 판단이 정교해져 일반 프롬프트로 충분 |
| 중단된 응답 이어가기 | 중단된 텍스트를 user 메시지로 옮겨 "이어서 작성하라"고 요청 |
도구 사용(tool use) 최적화
행동을 원하면 명시적으로 지시하기
최신 Claude 모델은 정밀한 지시 따르기를 위해 학습되어, 특정 도구를 쓰라는 명시적 지시에 잘 반응합니다. "can you suggest some changes" 라고 물으면, 변경을 원했더라도 Claude는 제안만 할 수 있습니다. 행동을 끌어내려면 "Change this function to improve its performance." 처럼 직접 명령해야 합니다. 기본적으로 행동에 적극적이게 하려면 다음 스니펫을, 반대로 더 신중하게 하려면 그 반대 방향의 스니펫을 시스템 프롬프트에 추가합니다.
<default_to_action>
By default, implement changes rather than only suggesting them. If the user's intent is unclear, infer the most useful likely action and proceed, using tools to discover any missing details instead of guessing. Try to infer the user's intent about whether a tool call (e.g., file edit or read) is intended or not, and act accordingly.
</default_to_action>
여기서 원문이 강조하는 중요한 주의점이 있습니다. Claude Opus 4.5와 4.6은 이전보다 시스템 프롬프트에 민감하므로, 도구나 스킬의 과소 발동(undertriggering) 을 막으려고 작성했던 공격적 표현이 이제는 과잉 발동(overtriggering) 을 일으킬 수 있습니다. "CRITICAL: You MUST use this tool when..." 같은 표현을 "Use this tool when..." 같은 평범한 표현으로 누그러뜨리는 것이 해법입니다.
병렬 도구 호출
최신 Claude 모델은 병렬 도구 실행 에 능합니다. 연구 중 여러 추측성 검색을 동시에 돌리고, 여러 파일을 한 번에 읽어 맥락을 빠르게 구축합니다. 별도 프롬프팅 없이도 성공률이 높지만, 다음 스니펫으로 거의 100%까지 끌어올릴 수 있습니다.
<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the tool calls, make all of the independent tool calls in parallel. Prioritize calling tools simultaneously whenever the actions can be done in parallel rather than sequentially. For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into context at the same time. Maximize use of parallel tool calls where possible to increase speed and efficiency. However, if some tool calls depend on previous calls to inform dependent values like the parameters, do NOT call these tools in parallel and instead call them sequentially. Never use placeholders or guess missing parameters in tool calls.
</use_parallel_tool_calls>
사고와 추론(thinking & reasoning)
과잉 사고 다스리기와 적응형 사고
Claude Opus 4.6은 이전 모델보다 사전 탐색을 훨씬 많이 하며, 특히 높은 effort 설정에서 두드러집니다. 이 초기 작업이 결과를 최적화하는 경우가 많지만, 프롬프트 없이도 광범위한 맥락을 수집하거나 여러 갈래의 연구를 추적할 수 있습니다. 이전에 "더 철저하게" 하도록 유도한 프롬프트가 있었다면 다음 방향으로 조정해야 합니다. 포괄적 기본값을 표적 지침으로 교체("Default to using [tool]" 대신 "Use [tool] when it would enhance your understanding"), 과잉 프롬프팅 제거("If in doubt, use [tool]" 류 삭제), 그리고 effort를 폴백으로 활용(계속 공격적이면 effort를 낮춤)하는 것입니다.
When you're deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning. If you're weighing two approaches, pick one and see it through. You can always course-correct later if the chosen approach fails.
적응형 사고(adaptive thinking) 는 Claude Opus 4.6과 Sonnet 4.6의 핵심 기능입니다. thinking: {type: "adaptive"} 로 설정하면 Claude가 effort 파라미터와 질의 복잡도를 보고 언제 얼마나 사고할지를 동적으로 결정합니다. 쉬운 질의에는 곧장 답하고, 복잡한 질의에는 깊이 추론합니다. 원문은 내부 평가에서 적응형 사고가 기존 확장 사고(extended thinking)보다 일관되게 더 나은 성능을 냈다고 밝힙니다. budget_tokens 기반 확장 사고에서 마이그레이션하는 경우, 사고 설정을 교체하고 예산 제어를 effort로 옮깁니다.
client.messages.create(
model="claude-opus-4-8",
max_tokens=64000,
thinking={"type": "adaptive"},
output_config={"effort": "high"}, # or "max", "xhigh", "medium", "low"
messages=[{"role": "user", "content": "..."}],
)
원문은 사고를 다루는 몇 가지 실전 팁도 제시합니다. 손으로 짠 단계별 계획보다 "think thoroughly" 같은 일반 지시가 더 나은 추론을 끌어내는 경우가 많고, few-shot 예시 안에 <thinking> 태그를 넣으면 모델이 그 추론 패턴을 일반화합니다. 또한 "Before you finish, verify your answer against [test criteria]." 같은 자가 검증 요청은 코딩과 수학에서 오류를 안정적으로 잡아냅니다.
한 가지 주의할 점은, 확장 사고가 꺼져 있을 때 Claude Opus 4.5는 "think"라는 단어와 그 변형에 특히 민감하다는 것입니다. 의도치 않은 사고를 유발하고 싶지 않다면 이 경우 "consider", "evaluate", "reason through" 같은 대체 표현을 쓰는 것이 좋습니다.
에이전트 시스템 설계
최신 Claude 모델의 진가는 장기 호흡 에이전트 작업에서 드러납니다. 이 영역은 프롬프트 설계가 가장 큰 차이를 만드는 곳이기도 합니다.
장기 호흡 추론과 상태 추적
Claude는 한 번에 모든 것을 시도하기보다 점진적 진전(incremental progress) 에 집중함으로써 긴 세션 내내 방향을 유지합니다. 이 능력은 여러 컨텍스트 윈도우에 걸친 작업에서 특히 빛납니다. 복잡한 작업을 하다가 상태를 저장하고, 새 컨텍스트 윈도우에서 이어가는 식입니다. Claude 4.6과 4.5 모델은 컨텍스트 인식(context awareness) 기능을 갖춰 남은 토큰 예산을 스스로 추적합니다.
에이전트 하니스가 컨텍스트를 압축(compaction)하거나 외부 파일로 상태를 저장한다면, 이를 프롬프트로 알려줘야 모델이 토큰 예산을 이유로 작업을 일찍 중단하지 않습니다.
Your context window will be automatically compacted as it approaches its limit, allowing you to continue working indefinitely from where you left off. Therefore, do not stop tasks early due to token budget concerns. As you approach your token budget limit, save your current progress and state to memory before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully, even if the end of your budget is approaching. Never artificially stop any task early regardless of the context remaining.
메모리 도구(memory tool)는 컨텍스트 인식과 자연스럽게 짝을 이룹니다. 다중 컨텍스트 윈도우 작업에서는 첫 윈도우에서 테스트와 셋업 스크립트로 골격을 세우고, 이후 윈도우에서 todo 리스트를 반복하는 전략이 권장됩니다. 상태 데이터는 tests.json 같은 구조화 포맷으로, 진행 노트는 자유 형식 텍스트로 관리하며, git을 상태 추적과 체크포인트에 활용하는 것이 효과적입니다. 원문은 "It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality." 처럼 테스트의 중요성을 모델에 각인시키라고 조언합니다.
자율성과 안전의 균형
지침이 없으면 Claude Opus 4.6은 파일 삭제, 강제 푸시, 외부 서비스 게시처럼 되돌리기 어렵거나 공유 시스템에 영향을 주는 행동을 할 수 있습니다. 위험한 행동 전 확인을 받게 하려면 다음을 추가합니다.
Consider the reversibility and potential impact of your actions. You are encouraged to take local, reversible actions like editing files or running tests, but for actions that are hard to reverse, affect shared systems, or could be destructive, ask the user before proceeding.
Examples of actions that warrant confirmation:
- Destructive operations: deleting files or branches, dropping database tables, rm -rf
- Hard to reverse operations: git push --force, git reset --hard, amending published commits
- Operations visible to others: pushing code, commenting on PRs/issues, sending messages, modifying shared infrastructure
When encountering obstacles, do not use destructive actions as a shortcut. For example, don't bypass safety checks (e.g. --no-verify) or discard unfamiliar files that may be in-progress work.
연구, 서브에이전트 오케스트레이션, 그리고 과잉 엔지니어링 억제
복잡한 연구 작업에는 성공 기준을 명확히 정의하고, 여러 소스 간 정보 검증을 유도하며, 구조화된 접근을 지시하는 것이 좋습니다. 원문은 "develop several competing hypotheses... Track your confidence levels... Update a hypothesis tree or research notes file" 처럼 경쟁 가설을 세우고 신뢰도를 추적하는 프롬프트를 권합니다.
서브에이전트 오케스트레이션 도 강화되었습니다. 최신 모델은 명시적 지시 없이도 전문화된 서브에이전트에게 작업을 위임할 때를 인식합니다. 다만 Claude Opus 4.6은 서브에이전트를 과하게 선호해, 직접 grep 한 번이면 될 코드 탐색에도 서브에이전트를 띄울 수 있습니다. 과용이 보이면 언제 위임이 적절한지 명시합니다.
Use subagents when tasks can run in parallel, require isolated context, or involve independent workstreams that don't need to share state. For simple tasks, sequential operations, single-file edits, or tasks where you need to maintain context across steps, work directly rather than delegating.
마지막으로, Claude Opus 4.5와 4.6은 불필요한 파일과 추상화를 만들거나 요청하지 않은 유연성을 더하는 과잉 엔지니어링(overengineering) 경향이 있습니다. 이를 억제하는 프롬프트는 PyTorchKR 커뮤니티의 많은 개발자가 시스템 프롬프트에 그대로 가져다 쓸 만합니다.
Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused:
- Scope: Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.
- Documentation: Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.
- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs).
- Abstractions: Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task.
같은 맥락에서, 테스트 통과에만 매달리거나 하드코딩으로 우회하는 동작을 막으려면 "implement a solution that works correctly for all valid inputs, not just the test cases" 를 강조하고, 코드에 대한 환각(hallucination)을 줄이려면 "Never speculate about code you have not opened. If the user references a specific file, you MUST read the file before answering." 처럼 조사 후 답변을 요구하는 것이 좋습니다.
프롬프트 체이닝과 자기 교정
적응형 사고와 서브에이전트 오케스트레이션 덕분에 Claude는 대부분의 다단계 추론을 내부에서 처리합니다. 그래도 중간 출력을 검사하거나 특정 파이프라인 구조를 강제해야 할 때는 명시적 프롬프트 체이닝(작업을 순차적 API 호출로 분해)이 여전히 유용합니다. 가장 흔한 패턴은 자기 교정(self-correction) 입니다. 초안을 생성하고, 기준에 맞춰 검토하게 한 뒤, 검토 결과를 바탕으로 다듬는 흐름인데, 각 단계를 별도 API 호출로 두면 어느 지점에서든 로깅하거나 분기할 수 있습니다.
또한 Claude는 코딩 작업에서 반복용 임시 파일(특히 파이썬 스크립트)을 "스크래치패드"처럼 만들곤 합니다. 이는 결과를 개선하는 경우가 많지만, 순수 신규 파일 생성을 줄이고 싶다면 "If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task." 를 추가해 스스로 정리하게 할 수 있습니다.
비전과 프론트엔드: 능력별 추가 팁
Claude Opus 4.5와 4.6은 비전 능력이 향상되어, 특히 여러 이미지가 컨텍스트에 있을 때 이미지 처리와 데이터 추출에서 더 나은 성능을 보입니다. crop 도구나 스킬을 제공해 모델이 이미지의 관련 영역을 "확대"하게 하면 일관된 성능 향상이 있으며, Anthropic은 이를 위한 crop 도구 쿡북을 공개했습니다. 이러한 향상은 컴퓨터 사용(computer use)으로도 이어져 스크린샷과 UI 요소 해석이 더 정확해졌습니다. 원문은 컴퓨터 사용 시 최대 2576px(3.75MP)까지 지원하되 성능과 비용의 균형점으로 1080p 해상도 전송을 권하며, 비용에 민감한 워크로드에는 720p나 1366×768도 강력한 선택지라고 안내합니다.
프론트엔드 설계에서는 지침이 없으면 모델이 사용자들이 "AI 슬롭(AI slop)"이라 부르는 진부한 패턴으로 수렴하는 경향이 있습니다. 흥미롭게도 Claude Opus 4.8은 이전 모델보다 더 적은 프롬프팅으로도 개성 있는 프론트엔드를 생성하며, 일반적인 지시("cream 색을 쓰지 마라")는 오히려 또 다른 고정 팔레트로 이동시킬 뿐입니다. 효과적인 방법은 (1) 구체적 대안을 명시하거나, (2) 빌드 전에 모델이 여러 시각적 방향을 제안하게 한 뒤 사용자가 고르게 하는 것입니다. 독창적 디자인을 유도하는 스니펫은 다음과 같습니다.
<frontend_aesthetics>
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.
</frontend_aesthetics>
마이그레이션 관점: 새 모델로 옮길 때 점검할 것
이 가이드를 관통하는 핵심 메시지는 명확합니다. 모델 세대가 바뀌면 기본값(default)이 바뀌고, 이전 세대를 위해 쌓아둔 프롬프트 보정이 새 세대에서는 역효과를 낼 수 있다는 것입니다. Claude 4.6 이상으로 옮길 때 점검할 사항을 정리하면 다음과 같습니다.
원하는 동작을 구체적으로 서술하고, "Go beyond the basics" 같은 수식어로 출력의 품질과 디테일을 끌어올립니다. 애니메이션이나 인터랙티브 요소는 원할 때 명시적으로 요청합니다. 사고 설정은 budget_tokens 기반 수동 사고에서 적응형 사고로 전환하고 effort 파라미터로 사고 깊이를 제어합니다. 프리필 응답은 더 이상 지원되지 않으므로 Structured Outputs 등으로 대체합니다. 무엇보다, 이전 모델에서 모델을 더 부지런하게 만들려고 추가했던 "anti-laziness" 프롬프팅은 덜어내야 합니다. 새 모델은 훨씬 능동적이라 그런 지시에 과잉 발동하기 때문입니다.
Claude Sonnet 4.6은 기본 effort가 high로, effort 파라미터가 없던 Sonnet 4.5와 다릅니다. 대부분의 애플리케이션에는 medium을, 대용량/지연 민감 워크로드에는 low를 권장하며, 가장 어렵고 긴 호흡의 문제(대규모 코드 마이그레이션, 심층 연구, 장기 자율 작업)에는 여전히 Claude Opus 4.8이 정답입니다. 이러한 모델별 조합 전략은 PyTorchKR에서 다룬 Opus를 조언자로, Sonnet/Haiku를 실행자로 쓰는 어드바이저 패턴과도 연결됩니다.
결국 프롬프트 엔지니어링의 무게중심은 "더 영리한 표현 찾기"에서 "모델의 현재 기본 동작을 이해하고, 거기서 벗어나야 할 부분만 명확히 명시하기"로 이동했습니다. 모델이 똑똑해질수록 프롬프트는 짧고 명확해지며, 개발자의 일은 모델과 싸우는 것이 아니라 모델의 강점을 방해하지 않도록 다듬는 쪽에 가까워지고 있습니다.
Claude 프롬프트 엔지니어링 모범사례 원문
더 읽어보기
더 읽어보기 (영문)
- Prompt engineering overview (공식 문서)
- Models overview
- Migration guide
- Structured Outputs
- Agent Skills overview
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 