Anthropic이 공개한 프롬프트 엔지니어링 (Prompt Engineering) 공식 가이드에 **Claude Opus 4.8을 위한 베스트 프랙티스 (Best Practices)**가 정리되어 있습니다. 이 모델은 long-horizon agentic (장기적 자율 작업), knowledge work (지식 작업), vision (시각), memory (메모리)와 같은 태스크에 강하며, 심지어 Opus 4.7의 프롬프트를 그대로 사용해도 잘 작동한다고 합니다.

하지만 '그대로 작동한다'와 '최적화되어 있다'는 별개의 문제입니다. Opus 4.8에는 이전 세대와는 조금 다른 몇 가지 동작 특성이 있습니다. effort (노력)에 대한 반응이 이전보다 커지거나, 지시를 문자 그대로 받아들이는 경향이 강해지거나, subagent (하위 에이전트)를 조심스럽게 spawn (생성)하는 등의 특징이 있습니다. 이러한 특징을 모른 채 기존 프롬프트를 계속 사용하면 본래의 성능을 다 끌어내지 못할 수 있습니다.

이 기사에서는 공식 가이드 중에서 **Opus 4.8에 고유한 튜닝 포인트 (Tuning Points)**를 중심으로, 실무에서 효과적인 순서대로 정리해 나갑니다. Claude API나 Claude Code를 업무에서 사용하고 있으며, 4.8로 업그레이드하면서 프롬프트를 재검토하고 싶은 분들을 대상으로 합니다.

이 기사에서 알 수 있는 내용:

• 🎚️ effort (노력) 파라미터의 구분 사용 — 4.8에서 가장 중요한 레버
• 🤔 thinking (사고) 제어와 adaptive thinking (적응형 사고)
• 🔧 tool use (도구 사용) · subagent 동작 튜닝
• 📝 응답 길이 · 문체 · '문자 그대로 해석하는' 습관에 대한 대처
• 🎨 디자인 생성 · 코드 리뷰 등 용도별 팁

Opus 4.8 프롬프팅에서 의식해야 할 포인트를 대략적인 지도로 나타내면 다음과 같습니다.

[IMG:1]

이 그림은 4.8로 이행했을 때 재검토할 가치가 있는 포인트들을 목록화한 것입니다. 여기서 읽어내야 할 점은 가장 효과적인 레버가 effort라는 점입니다. 공식 가이드에서도 "effort는 지금까지의 그 어떤 Opus보다 중요하므로, 업그레이드 시에는 적극적으로 실험해 보길 바란다"라고 명시하고 있습니다. 순서대로 살펴보겠습니다.

Opus 4.8 프롬프팅에서 가장 먼저 파악해야 할 것은 effort 파라미터입니다. 이는 '지능(똑똑함)'과 '토큰 소비(비용·속도)' 사이의 트레이드오프 (Trade-off)를 조정하는 레버입니다. effort를 높이면 더 똑똑해지지만, 토큰을 많이 사용하고 속도가 느려집니다.

공식적인 출발점은 간단합니다.

coding (코딩) · agentic (에이전트형) 용도는 xhigh

에서 시작하며, 지능이 중요한 용도는 최소한 high

입니다. effort에는 5단계가 있습니다. 각각의 위치를 정리합니다.

[IMG:2]

이 그림은 effort를 낮은 순서대로 나열한 것입니다. 여기서 읽어내야 할 점은 '일단 max'가 아니라, 용도에 따라 중앙 부근(high~xhigh)을 기본으로 한다는 설계 사상입니다. max는 강력하지만, 너무 깊게 생각하느라 오히려 느려지는 경우가 있습니다.

이 부분이 이전 세대와 다른 중요한 특징입니다. Opus 4.8은 effort 레벨을 엄격하게 준수합니다. 특히 low나 medium에서는 "지시받은 것만" 수행하며, 그 이상의 영역으로 나아가지 않습니다. 이는 레이턴시와 비용 측면에서는 좋지만, 중간 정도의 복잡한 태스크를 low로 돌리면 생각이 얕아지는 (under-thinking) 리스크가 있습니다.

복잡한 문제에서 추론이 얕다고 느껴진다면, 프롬프트로 잔꾀를 부리기보다 effort를 high 또는 xhigh로 올리는 것이 정공법입니다. 다만, 레이턴시 문제로 반드시 low를 유지해야 한다면, 핀포인트 지시를 추가합니다.

This task involves multi-step reasoning. Think carefully through the problem before responding.

반대로, max

또 xhigh로 작동할 때는 모델이 subagent나 도구 호출 (tool call)을 가로질러 생각하고 움직일 수 있는 여유가 필요합니다. max output token budget을 넉넉하게 잡으세요. 공식 가이드에서는 64k 토큰부터 시작하여 조정할 것을 권장하고 있습니다.

effort는 4.8 버전에서 가장 효과적인 레버 (lever)입니다. "업그레이드했다면 우선 effort를 조절해 본다"를 첫 번째 단계로 삼는다면, 성능의 체감을 쉽게 파악할 수 있을 것입니다.

effort와 더불어 중요한 것이 thinking (사고) 처리 방식입니다. Opus 4.8에서 thinking은 기본적으로 off 상태입니다. 명시적으로 thinking: {type: "adaptive"}를 설정했을 때만 활성화됩니다. adaptive thinking은 Claude가 effort와 쿼리의 복잡성을 바탕으로 "언제, 얼마나 생각할지"를 동적으로 판단해 주는 메커니즘입니다.

이 그림은 thinking 파라미터의 유무에 따라 동작이 어떻게 나뉘는지 보여줍니다. 여기서 주목해야 할 점은, adaptive thinking으로 설정하면 간단한 질문에서는 사고를 건너뛰고, 복잡한 문제에서는 깊게 생각하는 자동 최적화 기능이 작동한다는 점입니다. multi-step 도구 사용이나 장기적인 agent 루프에는 adaptive thinking이 적합합니다.

크고 복잡한 system prompt를 사용하고 있으면, Opus 4.8이 생각보다 빈번하게 사고를 수행할 수 있습니다. 이 경우에는 프롬프트로 방향을 잡아줄 수 있습니다.

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.

반대로, medium으로 무거운 워크로드 (workload)를 돌리고 있는데 under-thinking (사고 부족)이 느껴진다면, 가장 먼저 시도해야 할 레버는 역시 effort를 높이는 것입니다. 그럼에도 불구하고 더 세밀하게 제어하고 싶을 때 프롬프트로 직접 지시합니다.

이전 모델에서 budget_tokens를 사용한 extended thinking을 사용했다면, 4.8에서는 adaptive thinking + effort 방식으로 전환해야 합니다. 다음은 공식 문서의 마이그레이션 예시를 따른 것으로, Before 쪽은 기존 Sonnet 4.5를 예로 들었습니다 (Opus 4.8로 전환하는 과정도 동일합니다).

# Before (이전 모델 · extended thinking)
client.messages.create(
model="claude-sonnet-4-5-20250929",
...

budget_tokens로 사고량을 제어하던 것을 effort로 옮기는 것이 핵심입니다. 참고로 extended thinking을 사용하지 않았다면 아무것도 변경할 필요가 없습니다 (thinking 파라미터를 생략하면 off 상태가 유지됩니다).

Opus 4.8은 에이전트적인 동작의 기본 설정이 이전 세대와 약간 달라졌습니다.

Opus 4.8은 도구 호출 (tool call)보다 추론 (reasoning)을 선호하는 경향이 있습니다. 대부분의 경우 이 방식이 더 좋은 결과를 만들어냅니다. 다만, 도구를 더 많이 사용하기를 원하는 상황에서는 effort를 높이는 것이 유효한 레버입니다. 특히 knowledge work (조사 중심의 작업)에서 이 레버가 효과적입니다. high나 xhigh로 설정하면 agentic search나 코딩에서의 도구 사용이 대폭 증가합니다.

그럼에도 도구를 사용하지 않는다면, "언제, 어떻게 그 도구를 사용해야 하는지"를 명시적으로 작성합니다. 예를 들어 web 검색 도구가 사용되지 않는다면, 왜 그리고 어떻게 사용해야 하는지를 명확히 설명합니다.

Opus 4.8은 기본적으로 subagent를 적게 생성 (spawn) 합니다. 이 또한 조종 (steer)할 수 있으므로, subagent가 필요한 상황을 명시적으로 전달합니다. 코딩 용도의 예시입니다.

단일 응답으로 직접 완료할 수 있는 작업(예: 이미 보고 있는 함수의 리팩토링)을 위해 subagent를 생성하지 마세요.
여러 항목으로 확장(fanning out)하거나 여러 파일을 읽어야 할 때는 동일한 턴에서 여러 개의 subagent를 생성하세요.

이 그림은 subagent를 사용할지 여부의 판단 기준을 보여줍니다. 여기서 읽어내야 할 핵심은 병렬화, 문맥의 분리, 독립적인 작업일 때는 subagent를 사용하고, 그 외에는 직접 수행한다는 구분입니다. Opus 4.8은 그대로 두면 조심스럽게 행동하므로, 팬아웃(fan-out)이 필요한 상황은 명시적으로 촉구하는 것이 요령입니다.

Opus 4.8은 긴 에이전트 추적(agentic trace) 과정 중에서 정기적으로 고품질의 진행 보고를 제공합니다. 만약 "도구를 3번 호출하면 요약하라"와 같은 스캐폴딩(scaffolding, 구조화 작업)을 프롬프트에 심어두었다면, 이를 제거해 보는 것을 추천합니다. 모델 스스로가 잘 수행하기 때문입니다. 보고의 길이 나 내용이 용도에 맞지 않는다면, "이러한 방식으로 보고해 달라"고 예시와 함께 명시하십시오.

Opus 4.8의 또 다른 큰 특징은 지시를 문자 그대로, 그리고 명시적으로 해석한다는 점입니다. 특히 낮은 노력(effort) 수준에서 이 특징이 두드러집니다. 구체적으로는, 하나의 항목에 대한 지시를 묵묵히 다른 항목으로 일반화하지 않으며, 요청하지 않은 것을 추측하여 실행하지도 않습니다.

이는 높은 정밀도와 불필요한 재작업의 감소로 이어지며, API 용도, 구조화된 추출(structured extraction), 예측 가능성을 요구하는 파이프라인에서 특히 효과적입니다. 반면, "전체에 적용해 달라"고 할 때는 범위(scope)를 명시할 필요가 있습니다.

Apply this formatting to every section, not just the first one.
(첫 번째 섹션뿐만 아니라 모든 섹션에 이 서식을 적용하세요.)

"첫 번째 섹션뿐만 아니라 모든 섹션에"라고 작성하십시오. 이것만으로도 동작이 안정됩니다. "말하지 않아도 알아서 해주겠지"라는 기대가 통하기 어려워졌다고 이해하면 쉽습니다.

Opus 4.8은 응답 길이를 태스크의 복잡성에 따라 자동으로 조정합니다. 고정된 장황함을 갖지 않으므로, 간단한 조회에는 짧게, 개방적인 분석에는 길게 답합니다. 만약 제품이 특정 문체나 길이에 의존하고 있다면 프롬프트로 튜닝하십시오. 장황함을 줄이는 예시입니다.

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.
(간결하고 집중된 응답을 제공하세요. 불필요한 문맥은 건너뛰고, 예시는 최소한으로 유지하세요.)

여기서 한 가지 요령이 있습니다. "~하지 마라"와 같은 부정적인 지시나 금지보다는, "적절하게 간결하게 작성된 예시"를 보여주는 긍정적인 예시가 더 효과적이라고 알려져 있습니다.

Opus 4.8의 산문 스타일은 직설적이고 의견을 가지며, 과도한 동조(validation-forward한 말투)를 자제하고, 이모지 사용도 절제하는 방향으로 기울어져 있습니다. 만약 제품이 더 따뜻하거나 대화적인 목소리를 필요로 한다면 명시적으로 지정하십시오.

Use a warm, collaborative tone. Acknowledge the user's framing before answering.
(따뜻하고 협력적인 톤을 사용하세요. 답변하기 전에 사용자의 프레이밍을 인정해 주세요.)

이어서 특정 용도에서 효과적인 튜닝 방법을 살펴보겠습니다.

Opus 4.8에는 강한 디자인 본능이 있어, 그대로 두면 일관된 하우스 스타일(house style)이 나타납니다. 구체적으로는 따뜻한 크림/오프 화이트 배경(대략 #F4F1EA), 세리프(serif) 헤드라인 폰트(Georgia, Fraunces, Playfair), 이탤릭체 강조, 테라코타/호박색(amber) 액센트 등의 조합입니다.

이는 에디토리얼(editorial), 호스피탈리티(hospitality), 포트폴리오(portfolio)와 같은 브리프에는 잘 맞습니다. 하지만 대시보드(dashboard), 개발 도구(dev tool), 핀테크(fintech), 헬스케어(healthcare), 엔터프라이즈(enterprise) 앱에는 솔직히 어울리지 않습니다. 게다가 이 기본 설정은 지속적이어서, "크림색을 사용하지 마라"나 "클린하고 미니멀하게"와 같은 일반적인 지시를 내리면 다른 고정된 팔레트로 이동할 뿐, 다양한 변주를 만들어내기는 어렵습니다.

확실하게 효과를 보는 방법은 두 가지가 있습니다.

1. 구체적인 대안을 지정한다. 모델은 명시적인 스펙을 정확하게 준수합니다.

The visual direction should come from a cold monochrome atmosphere using pale silver-gray tones that gradually deepen into blue-gray and near-black...
Color palette should stay within this range:
#E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.

2. 구축하기 전에 옵션을 제안하게 한다. 이것이 기본값(default)을 깨뜨리고 사용자에게 선택권을 부여합니다. 이전에 temperature로 디자인의 변주를 주려 했다면, 이 방법이 그 대안이 될 수 있습니다.

Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface — one-line rationale). Ask the user to pick one, then implement only that direction.

또한 Opus 4.8은 이전 모델보다 더 적은 프롬프트로 "AI slop(AI스러운 양산형 디자인)"을 회피할 수 있습니다. 범용 폰트(Inter, Roboto, Arial)나 보라색 그라데이션 같은 전형적인 스타일을 피하도록 유도하는 스니펫(snippet)이 위의 기법들과 잘 맞물립니다.

<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>

Opus 4.8은 버그 발견 능력이 이전 세대보다 명확하게 뛰어납니다. 내부 평가에서 재현율(recall, 놓치는 것이 적음)과 정밀도(precision, 오탐이 적음) 모두 향상되었습니다. 다만, 구형 모델에 맞춰 조정된 코드 리뷰 하네스(harness)를 사용하고 있다면, 초기에는 재현율(recall)이 낮아 보이는 경우가 있습니다. 이는 능력이 퇴보한 것이 아니라 하네스 측면의 효과입니다.

그 이유는 흥미롭습니다. "high-severity(심각도가 높은) 문제만 보고해", "보수적으로 해줘", "세세한 지적은 하지 마"와 같은 지시를 Opus 4.8은 이전 세대보다 더 충실하게 준수합니다. 즉, 코드를 동일한 깊이로 조사하여 버그를 찾아내더라도, "사용자가 말한 기준보다 낮다"라고 판단한 것은 보고하지 않게 되는 것입니다. 결과적으로 조사 깊이는 동일함에도 보고 건수가 줄어드는 형태로 나타납니다. 정밀도(precision)는 올라가는데, 측정상의 재현율(recall)은 낮아 보이는 현상이 발생하는 것입니다.

이에 대한 대책으로 권장되는 프롬프트는 다음과 같습니다.

확신이 없거나 심각도가 낮다고 판단되는 문제를 포함하여 발견한 모든 이슈를 보고하세요. 이 단계에서는 중요도나 확신도를 기준으로 필터링하지 마세요. 별도의 검증 단계에서 이를 수행할 것입니다. 여기서 당신의 목표는 커버리지(coverage)입니다. 나중에 필터링되어 제외되더라도, 실제 버그를 조용히 누락시키는 것보다 발견 사항을 드러내는 것이 더 낫습니다. 각 발견 사항에 대해 확신도(confidence level)와 예상 심각도(severity)를 포함하여, 후속 필터가 이를 순위 매길 수 있도록 하세요.

핵심은 "발견" 단계에서는 커버리지(coverage, 망라)에 전념하게 하고, 필터링은 별도의 단계로 분리하는 것입니다.

이 그림은 코드 리뷰를 "발견"과 "필터"의 2단계로 나누는 사고방식을 보여줍니다. 여기서 파악해야 할 점은, 버그를 찾는 단계에서 보고를 제한하지 않음으로써 Opus 4.8의 높은 발견 능력을 놓치지 않고 최대한 끌어낼 수 있다는 것입니다.

Opus 4.8은 자율적(단일 턴) 사용과 대화적(다중 턴) 사용에 따라 토큰 소비와 동작이 달라집니다. 대화적인 설정에서는 토큰을 더 많이 사용하는 경향이 있습니다. 사용자(user)의 턴 이후에 더 많은 추론을 수행하기 때문입니다. 이는 긴 대화 세션에서의 일관성, 지시 준수(instruction following), 코딩 능력을 높이는 반면, 토큰 사용량도 늘립니다.

성능과 토큰 효율성을 양립하려면, xhigh 또는 high effort를 사용하고, auto mode와 같은 자율 기능을 추가하여 사용자에게 요구되는 조작 횟수를 줄이는 것이 효과적입니다.

그 바탕 위에서, 첫 번째 인간(human) 턴에서 작업(task), 의도, 제약 사항을 명시하는 것이 핵심입니다. Opus 4.8은 이전 세대보다 자율적이므로, 처음에 명확하고 정확한 작업 기술을 제공하면 자율성과 지능을 극대화하면서도 사용자 턴 이후의 불필요한 토큰 소비를 억제할 수 있습니다. 반대로, 모호한 지시를 여러 턴에 걸쳐 조금씩 나누어 전달하면 토큰 효율성과 성능이 상대적으로 떨어지기 쉽습니다.

컴퓨터 사용(computer use)은 최대 2576px / 3.75MP 해상도까지 지원합니다. 내부 테스트에서는 1080p가 성능과 비용의 균형이 좋다고 합니다. 비용을 중시한다면 720p나 1366×768이 저비용으로 강력한 성능을 내는 선택지입니다.

여기까지는 Opus 4.8에 국한된 이야기였지만, 세대를 불문하고 적용되는 기본 원칙도 4.8에서 그대로 유효합니다. 짧게 짚어보겠습니다.

명확하고 직접적으로: 골든 룰은 "문맥을 거의 모르는 동료에게 프롬프트를 보여줬을 때 그가 혼란스러워한다면 Claude도 혼란스러워한다"는 것입니다. 기대하는 출력 형식과 제약 사항을 구체적으로 작성하세요.

문맥(이유) 추가하기: 왜 그 동작이 중요한지 설명하면 Claude가 목적을 이해하고 정확한 응답을 보냅니다. "절대 생략 기호를 사용하지 마"보다 "음성 읽기 엔진이 읽어야 하므로 생략 기호를 사용하지 마"가 더 효과적입니다.

예시 사용: 퓨샷(few-shot, 3~5개)은 출력의 형식, 톤, 구조를 안정화합니다. <example> 태그로 감싸세요.

XML 태그로 구조화: 지시, 문맥, 예시, 입력이 섞일 때, <instructions>, <context>, <input>과 같이 태그로 나누면 오해를 줄일 수 있습니다.

긴 문장은 위로, 쿼리는 아래로: 20k 토큰을 초과하는 긴 문장을 다룰 때는 긴 문서를 위에, 질문/지시 사항을 아래에 배치합니다. 테스트 결과 최대 30%의 품질 개선이 확인되었다고 합니다.

이전 모델에서 전환할 때 놓치기 쉬운 변경 사항이 있습니다. 최종 어시스턴트(assistant) 턴의 프리필(prefill, 응답의 서두를 미리 채워두는 기법)은 Claude 4.6 계열 이후부터 지원되지 않습니다. prefill이 포함된 요청은 400 에러를 반환합니다.

기존에 prefill로 구현하던 기능들은 다음과 같이 전환합니다.

• 출력 포맷 고정 (JSON/YAML 등) → Structured Outputs 기능을 사용하거나, 우선 스키마를 충실히 따르도록 지시한다.
• 서두 ("Here is...") 제거 → system prompt에서 직접 지시하거나, XML 태그, structured outputs, tool calling을 사용한다.
• 부적절한 거부 회피 → 4.8은 적절한 거부 능력이 향상되었으므로, user 메시지 내의 명확한 프롬프트만으로 충분하다.
• 응답의 계속 → 계속하기를 user 메시지로 옮기고, 중단된 응답의 마지막 텍스트를 포함한다.

모델의 지능과 지시 준수(instruction following) 능력이 향상된 결과, prefill의 용도 중 상당수는 이제 불필요해졌다는 정리입니다.

Claude Opus 4.8의 프롬프팅을 한마디로 요약하자면, **"똑똑해진 만큼 지시를 솔직하고 엄격하게 받아들이게 되었으므로, 우리의 의도를 명시적으로 전달한다"**로 귀결됩니다.

개인적으로 가장 큰 변화는 effort 부분이라고 느낍니다. 4.8에서는 effort가 이전의 그 어떤 Opus보다 효과적입니다. 추론이 얕다고 느껴진다면 프롬프트로 잔꾀를 부리기 전에 effort를 높이고, 도구(tool)를 더 많이 사용하길 원한다면 effort를 높이십시오. 많은 고민이 우선 effort로 해결됩니다.

코딩(coding)이나 에이전트적(agentic) 작업이라면 xhigh부터, 지능이 필요하다면 최소 high까지. 이 점만 기억해 두면 나머지는 손에 든 태스크를 시도하며 다듬어 나갈 수 있습니다.

기존의 프롬프트를 그대로 사용해도 작동하기 때문에, 자칫 최적화를 뒤로 미루기 쉽습니다. 하지만 4.8의 특성을 조금만 이해하고 effort와 scope를 명시하는 것만으로도, 동일한 모델로부터 끌어낼 수 있는 결과가 상당히 달라집니다. 업그레이드했다면, 우선 무거운 태스크를 하나 골라 effort를 조절하며 체감 성능을 확인해 보시기 바랍니다.