Claude Opus 4.8 프롬프트 최적화 가이드 (4.7에서 업그레이드할 때 꼭 볼 것)

Anthropic이 공개한 프롬프트 엔지니어링 공식 가이드에 Claude Opus 4.8용 베스트 프랙티스가 정리되어 있어요. 이 모델은 long-horizon agentic(장기에 걸친 자율 작업)·knowledge work·vision·memory 같은 태스크에 강하고, 게다가 Opus 4.7용 프롬프트를 그대로 써도 잘 동작한다고 합니다.

다만 "그대로 동작한다"와 "최적화되어 있다"는 별개예요. Opus 4.8에는 이전 세대와 조금 다른 동작 버릇이 몇 가지 있어요. effort(노력)에 대한 반응이 지금까지보다 더 크다거나, 지시를 문자 그대로 받아들이는 경향이 강하다거나, subagent를 절제해서 spawn한다거나 — 이런 특징을 모르고 옛날 프롬프트를 계속 쓰면 본래 성능을 다 끌어내지 못할 때가 있습니다.

이 글에서는 공식 가이드 중에서 Opus 4.8에 고유한 튜닝 포인트를 중심으로, 실무에서 잘 듣는 순서대로 정리해 볼게요. Claude API나 Claude Code를 업무에서 쓰면서 4.8로 업그레이드하고 프롬프트를 손보고 싶은 분을 염두에 뒀습니다.

이 글에서 알 수 있는 것:

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

먼저 전체 그림 🗺️

Opus 4.8 프롬프팅에서 의식해야 할 포인트를 대충 지도로 그리면 이렇게 돼요.

이 그림은 4.8로 옮겼을 때 다시 살펴볼 만한 포인트를 한눈에 모아둔 거예요. 읽어내야 할 건, 가장 잘 듣는 레버가 effort라는 점입니다. 공식에서도 "effort는 지금까지의 어떤 Opus보다 중요하니, 업그레이드할 때 적극적으로 실험해보길 바란다"고 분명히 말하고 있어요. 순서대로 살펴볼게요.

effort(노력) 구분해서 쓰기 🎚️

Opus 4.8 프롬프팅에서 가장 먼저 잡아둬야 할 게 effort 파라미터예요. 이건 "지능(똑똑함)"과 "토큰 소비(비용·속도)"의 트레이드오프를 조절하는 레버입니다. effort를 올리면 똑똑해지지만, 토큰을 많이 쓰고 느려져요.

공식의 출발점은 단순해요.

• coding·agentic한 용도는 xhigh부터 시작한다
• 지능이 중요한 용도는 최소 high

effort에는 5단계가 있어요. 각각의 위치를 정리해볼게요.

이 그림은 effort를 낮은 순서대로 늘어놓은 거예요. 여기서 눈여겨볼 점은, "일단 max"가 아니라 용도에 맞춰 가운데쪽(high~xhigh)을 기본으로 삼는다는 설계 사상입니다. max는 강력하지만, 너무 생각하다가 오히려 느려질 때가 있어요.

Opus 4.8은 effort를 "엄격하게" 지킨다

여기가 이전 세대와 다른, 중요한 버릇이에요. 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나 툴 호출을 넘나들며 생각하고 움직일 여지가 필요해요. max output token budget을 넉넉히 잡아두세요. 공식은 64k 토큰부터 시작해 조정하길 권합니다.

💡 effort는 4.8에서 가장 잘 듣는 레버예요. "업그레이드했으면 일단 effort부터 흔들어본다"를 첫 수로 삼으면 감을 잡기 쉬울 거예요.

thinking(사고) 제어 🤔

effort와 나란히 중요한 게 thinking(사고) 다루기예요. Opus 4.8에서 thinking은 기본값이 off입니다. 명시적으로 thinking: {type: "adaptive"}를 설정했을 때만 켜져요. adaptive thinking은 Claude가 "언제·얼마나 생각할지"를 effort와 쿼리의 복잡도에서 동적으로 판단해주는 구조입니다.

이 그림은 thinking 파라미터의 유무에 따라 동작이 어떻게 갈리는지를 보여줘요. 핵심은, adaptive thinking으로 해두면 쉬운 질문에서는 사고를 건너뛰고, 복잡한 문제에서는 깊이 생각하는 자동 구분이 작동한다는 점입니다. multi-step 툴 사용이나 장기 agent 루프에는 adaptive thinking이 잘 맞아요.

너무 생각할 때의 steer

크고 복잡한 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으로 무거운 워크로드를 돌리다가 under-thinking(생각이 부족함)을 느끼면, 가장 먼저 시도할 레버는 역시 effort를 올리는 것이에요. 그래도 세세하게 제어하고 싶을 때 프롬프트로 직접 지시합니다.

extended thinking에서 옮겨오기

옛 모델에서 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",
    max_tokens=64000,
    thinking={"type": "enabled", "budget_tokens": 32000},
    messages=[{"role": "user", "content": "..."}],
)

# After (adaptive thinking)
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # max / xhigh / medium / low 도 지정 가능
    messages=[{"role": "user", "content": "..."}],
)

budget_tokens로 사고량을 제어하던 걸 effort로 옮기는 게 포인트예요. 참고로 extended thinking을 안 썼다면 아무것도 바꿀 필요 없어요(thinking은 파라미터를 빼면 off인 채로 남습니다).

tool use와 subagent 동작 🔧

Opus 4.8은 에이전트적인 행동의 기본값이 이전 세대와 조금 달라졌어요.

툴보다 추론을 선호한다

Opus 4.8은 툴 호출보다 추론(reasoning)을 선호하는 경향이 있어요. 많은 경우 이쪽이 더 좋은 결과를 냅니다. 다만 툴을 더 써줬으면 하는 장면에서는 effort를 올리는 게 유효한 레버예요. 특히 knowledge work(조사 중심 작업)에서 이 레버가 잘 듣습니다. high나 xhigh로 하면 agentic search나 코딩에서 툴 사용이 대폭 늘어나요.

그래도 툴을 안 써줄 때는, "언제·어떻게 그 툴을 써야 하는지"를 명시적으로 적습니다. 예를 들어 web 검색 툴이 안 쓰이면, 왜·어떻게 써야 하는지를 분명히 설명해줘요.

subagent는 절제해서 spawn한다

Opus 4.8은 기본적으로 subagent를 적게 spawn해요. 이것도 steer할 수 있으니, 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.

이 그림은 subagent를 쓸지 말지의 판단축을 정리한 거예요. 포인트는, 병렬화·문맥 분리·독립된 작업일 때는 subagent, 그 외에는 직접이라는 선 긋기입니다. Opus 4.8은 내버려두면 절제하는 쪽이라, 팬아웃해줬으면 하는 장면은 명시적으로 부추기는 게 요령이에요.

user를 향한 진척 보고

Opus 4.8은 긴 agentic trace 안에서 정기적으로 고품질 진척 보고를 내줘요. 만약 "툴을 3번 호출하면 요약한다" 같은 발판(scaffolding)을 프롬프트에 심어뒀다면, 빼보길 권합니다. 모델 스스로 알아서 잘 해주거든요. 보고의 길이나 내용이 용도에 안 맞으면, "이런 보고를 해줘"라고 예시를 곁들여 명시합니다.

"문자 그대로 해석하는" 버릇에 대한 대처 📝

Opus 4.8의 또 하나 큰 특징이, 지시를 문자 그대로·명시적으로 해석하는 거예요. 특히 낮은 effort에서 두드러집니다. 구체적으로는, 한 항목에 대한 지시를 말없이 다른 항목으로 일반화하지 않고, 부탁하지 않은 걸 추측해서 실행하지도 않아요.

이건 정확도가 높고 헛된 재작업이 적은 결과로 이어져서, API 용도·구조화 추출·예측 가능성을 원하는 파이프라인에서 특히 잘 작동합니다. 한편 "전체에 적용해줬으면" 할 때는 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에는 강한 디자인 본능이 있어서, 내버려두면 일관된 하우스 스타일이 나와요. 구체적으로는 따뜻한 크림/오프화이트 배경(대체로 #F4F1EA), serif 계열 제목 폰트(Georgia, Fraunces, Playfair), 이탤릭 어구 강조, 테라코타/호박색 액센트 — 이런 조합이에요.

이건 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. 구축 전에 옵션을 제안하게 한다. 이게 기본값을 깨고, 사용자에게 선택권을 줘요. 예전에 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)나 보라색 그라데이션 같은 정석을 피하도록 부추기는 스니펫이 위 방법과 잘 맞물립니다.

<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(오검출이 적은 정도)도 올랐습니다. 다만 옛 모델용으로 조정한 코드 리뷰 하니스를 쓰고 있으면, 처음엔 recall이 떨어져 보일 때가 있어요. 이건 능력의 후퇴가 아니라 하니스 쪽 효과입니다.

이유가 재미있는 대목이에요. "high-severity한 문제만 보고해" "보수적으로" "사소한 지적은 하지 마" 같은 지시를, Opus 4.8은 이전 세대보다 충실히 지킵니다. 즉 코드를 같은 깊이로 조사해 버그를 찾아내도, "네가 말한 기준보다 아래"라고 판단한 건 보고하지 않게 돼요. 결과적으로, 조사의 깊이는 같은데 보고 건수가 줄어드는 형태로 나타납니다. precision은 오르는데 측정상의 recall은 떨어져 보이는 거예요.

대책으로 권장되는 프롬프트가 이거예요.

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.

포인트는, "발견" 단계에서는 coverage(망라)에 전념하게 하고, 필터링은 별도 단계로 나누는 것이에요.

이 그림은 코드 리뷰를 "발견"과 "필터"의 2단계로 나누는 사고방식을 보여줘요. 읽어내야 할 건, 버그를 찾는 단계에서 보고를 좁히지 않게 함으로써 Opus 4.8의 높은 발견 능력을 놓치지 않고 끌어낼 수 있다는 점입니다.

대화형 코딩 제품

Opus 4.8은 자율적(단일 턴)인 사용법과 대화적(복수 턴)인 사용법에서 토큰 소비나 동작이 달라져요. 대화적인 설정에서는 토큰을 많이 쓰는 경향이 있어요. user의 턴 다음에 더 많이 추론하기 때문입니다. 이건 긴 대화 세션에서의 일관성이나 지시 추종, 코딩 능력을 높이는 한편 토큰도 늘려요.

성능과 토큰 효율을 양립시키려면, xhigh나 high의 effort를 쓰고, auto mode 같은 자율 기능을 더하고, 사용자에게 요구하는 조작 횟수를 줄이는 게 유효해요.

그러고 나서, 첫 human 턴에서 태스크·의도·제약을 명시하는 게 열쇠가 됩니다. Opus 4.8은 이전 세대보다 자율적이라, 처음에 명확하고 정확한 태스크 기술을 주면 자율성과 지능을 최대화하면서 user 턴 뒤의 쓸데없는 토큰 소비를 억제할 수 있어요. 반대로 모호한 지시를 여러 턴에 걸쳐 조금씩 흘리면, 토큰 효율도 성능도 상대적으로 떨어지기 쉽습니다.

computer use

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%의 품질 개선이 보였다고 합니다.

prefill을 못 쓰게 된 점에 주의 ⚠️

마이그레이션할 때 놓치기 쉬운 변경이 있어요. 마지막 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 메시지로 옮기고, 중단된 응답의 마지막 텍스트를 포함

모델의 지능과 지시 추종이 올라간 결과, prefill의 용도 대부분은 이제 불필요해졌다, 라는 정리예요.

정리 🏁

Claude Opus 4.8의 프롬프팅을 한마디로 정리하면 이거예요. "똑똑해진 만큼 지시를 순순히·엄밀하게 받아들이게 됐으니, 이쪽 의도를 명시적으로 건넨다."

개인적으로 가장 큰 변화는 effort 부분이라고 느껴요. 4.8에서는 effort가 지금까지의 어떤 Opus보다 잘 들어요. 추론이 얕다고 느끼면 프롬프트로 잔재주 부리기 전에 effort를 올린다, 툴을 더 써줬으면 하면 effort를 올린다 — 많은 고민이 우선 effort로 풀립니다.

coding·agentic이라면 xhigh부터, 지능이 필요하면 최소 high. 이 점만 기억해두면, 나머지는 손에 든 태스크에서 시험하며 다져가면 돼요.

옛날 프롬프트를 그대로 써도 동작하니까, 자꾸 최적화를 뒤로 미루기 쉬워요. 하지만 4.8의 버릇을 조금 알고 effort와 scope 명시를 더하기만 해도, 같은 모델에서 끌어내는 결과가 꽤 달라집니다. 업그레이드했으면, 우선 무거운 태스크를 하나 골라서 effort를 흔들며 감을 확인해보세요.

©2024-2026 ClaudeCode.to, Hand-crafted & made with Jaewoo Kim. 이메일문의: jaewoo@claudecode.to

프로필(Linktr.ee): https://linktr.ee/jaewookim

Koding 프로필: https://koding.kr/u/jaewoo.kim2019

Jaewoo Kim by AI-fluent liberal arts Engineer