Claude Opus 4.8 프롬프팅
Claude Opus 4.8 프롬프팅 (Prompting Claude Opus 4.8)
이 문서는 Claude Opus 4.8에 특화된 프롬프팅 패턴을 다루는 가이드예요. 장황함, effort 보정, 도구 사용, 하위 에이전트, 프론트엔드 기본값을 중심으로, 이 모델이 어떻게 동작하는지와 어떤 프롬프트 조정이 도움이 되는지 설명해 드릴게요. 기존 Claude Opus 4.7 프롬프트에서도 잘 동작하지만, 튜닝이 가장 자주 필요한 행동 패턴을 하나씩 살펴볼게요.
출처: 문서
본문
이 가이드는 Claude Opus 4.8에 특화된 프롬프팅 패턴을 다뤄요. Claude Opus 4.8에서 Claude Opus 5.5로 이동하며 관련된 API 변경은 Claude Opus 4.8에서 Claude Opus 5.5로 마이그레이션을, 모든 현재 Claude 모델에 적용되는 기법은 프롬프트 모범 사례를 참고하세요.
Claude Opus 4.8은 장기 에이전트 작업, 지식 작업, 비전, 메모리 과제에 특별히 강해요. 기존 Claude Opus 4.7 프롬프트에서도 기본으로 잘 동작해요. 아래 패턴들은 튜닝이 가장 자주 필요한 행동을 다룹니다.
응답 길이와 장황함 (Response length and verbosity)
Claude Opus 4.8은 고정된 장황함을 기본으로 하기보다, 과제가 얼마나 복잡한지 판단한 정도에 응답 길이를 보정해요. 이는 보통 단순 조회에서는 더 짧은 답을, 개방형 분석에서는 훨씬 더 긴 답을 의미해요.
제품이 특정 스타일이나 출력 장황함에 의존한다면 프롬프트를 조정해야 할 수 있어요. 예를 들어 장황함을 줄이려면 이렇게 추가할 수 있어요:
Provide concise, focused responses. Skip non-essential context, and keep examples minimal.
특정 종류의 장황함(과도한 설명 같은)의 구체적 예를 본다면 프롬프트에 추가 지시를 넣어 막을 수 있어요. Claude가 적절한 수준의 간결함으로 소통하는 방법을 보여주는 긍정적 예시가, 무엇을 하지 말라고 말하는 부정적 예시나 지시보다 더 효과적인 경향이 있어요.
effort와 thinking 깊이 보정하기 (Calibrating effort and thinking depth)
effort 파라미터로 Claude의 지능과 토큰 지출을 맞바꿀 수 있어요. 더 빠른 속도와 더 낮은 비용을 위해 능력을 맞교환하는 것이죠. 코딩과 에이전트 사용 사례에서는 xhigh effort 수준으로 시작하고, 대부분의 지능 민감 사용 사례에서는 최소 high effort를 쓰세요. 다른 effort 수준도 실험해 토큰 사용과 지능을 더 조정하세요:
max: Max effort는 일부 사용 사례에서 성능 향상을 낼 수 있지만, 증가한 토큰 사용에서 수익 감소가 나타날 수 있어요. 과도한 thinking에 취약할 때도 있어요. 지능 집약적 과제에 대해 max effort를 테스트하세요.xhigh: Extra high effort는 대부분의 코딩과 에이전트 사용 사례의 최고 설정이에요.high: 이 설정은 토큰 사용과 지능을 균형 잡아요. 대부분의 지능 민감 사용 사례에서 최소higheffort를 쓰세요.medium: 지능을 맞교환하며 토큰 사용을 줄여야 하는 비용 민감 사용 사례에 좋아요.low: 짧고 범위가 정해진 과제와 지능에 민감하지 않은 지연 민감 워크로드용으로 남겨 두세요.
Claude Opus 4.8은 effort 수준을 엄격히 존중해요. 특히 낮은 쪽에서요. low와 medium에서는 모델이 그 이상을 하기보다 요청된 것에 작업을 한정해요. 이는 지연과 비용에는 좋지만, 보통 복잡도의 과제를 low effort로 돌리면 thinking 부족 위험이 있어요.
복잡한 문제에서 얕은 추론이 보인다면 프롬프팅으로 우회하기보다 effort를 high나 xhigh로 올리세요. 지연 때문에 effort를 low로 유지해야 한다면 타겟 안내를 추가하세요:
This task involves multistep reasoning. Think carefully through the problem before responding.
Effort는 이 모델에서 이전 Opus보다 더 중요할 가능성이 높아요. 업그레이드할 때 적극적으로 실험하세요.
Claude Opus 4.8에서는 thinking: {type: "adaptive"}을 명시적으로 설정하지 않으면 thinking이 꺼져요. 적응형 thinking의 트리거링 행동은 이끌 수 있어요. 크거나 복잡한 시스템 프롬프트에서 그럴 수 있듯 모델이 원하는 것보다 자주 생각한다면 이끄는 지침을 추가하세요. 언제나처럼 프롬프팅 변경의 효과를 성능으로 측정하세요. 예:
Thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multistep reasoning. When in doubt, respond directly.
반대로 어려운 워크로드를 medium에서 돌리고 thinking 부족이 보인다면, 첫 번째 손잡이는 effort를 올리는 것이에요. 더 세밀한 제어가 필요하면 직접 프롬프팅하세요.
도구 사용 트리거링 (Tool use triggering)
Claude Opus 4.8은 도구 호출보다 추론을 선호하는 경향이 있어요. 대부분의 경우 더 나은 결과를 내죠. 하지만 effort 설정을 높이는 것은 도구 사용 수준을 높이는 유용한 손잡이예요. 특히 지식 작업에서요. high나 xhigh effort 설정은 에이전트 검색과 코딩에서 훨씬 더 많은 도구 사용을 보여요. 더 많은 도구 사용을 원하는 시나리오에서는 프롬프트를 조정해 언제 어떻게 도구를 제대로 쓸지 명시적으로 지시할 수도 있어요. 예를 들어 모델이 웹 검색 도구를 쓰지 않는다면 왜 어떻게 써야 하는지 명확히 설명하세요.
사용자 대상 진행 업데이트 (User-facing progress updates)
Claude Opus 4.8은 긴 에이전트 트레이스 내내 사용자에게 더 규칙적이고 더 높은 품질의 업데이트를 제공해요. 중간 상태 메시지를 강제하는 스캐폴딩("매 3번의 도구 호출 후 진행 요약")을 추가했다면 제거해 보세요. Claude Opus 4.8의 사용자 대상 업데이트 길이나 내용이 자기 사용 사례에 잘 보정되지 않았다면, 이 업데이트가 어떻게 보여야 하는지 프롬프트에 명시적으로 설명하고 예시를 제공하세요.
더 문자 그대로의 지시 이행 (More literal instruction following)
Claude Opus 4.8은 특히 낮은 effort 수준에서 프롬프트를 문자 그대로, 명시적으로 해석해요. 한 항목에서 다른 항목으로 지시를 조용히 일반화하지 않고, 요청하지 않은 것은 추론하지 않아요. 이 문자주의의 장점은 정밀함과 덜 뒤흔들림이며, 신중하게 조정된 프롬프트를 쓰는 API 사용 사례, 구조화된 추출, 예측 가능한 동작을 원하는 파이프라인에서 일반적으로 더 잘 동작해요. Claude가 지시를 넓게 적용하길 필요하다면 범위를 명시적으로 말하세요(예: "이 서식을 모든 섹션에 적용하세요. 첫 번째 뿐만 아니라").
어조와 글쓰기 스타일 (Tone and writing style)
어떤 새 모델에서와 마찬가지로, 장문 글쓰기의 산문 스타일이 바뀔 수 있어요. Claude Opus 4.8은 검증 중심 표현이 적고 이모지 사용이 아낀, 직접적이고 의견이 분명한 스타일로 기우는 경향이 있어요. 제품이 특정 음성에 의존한다면 새 기준 대비 스타일 프롬프트를 재평가하세요.
예를 들어 제품 음성이 더 따뜻하거나 대화적이라면 추가하세요:
Use a warm, collaborative tone. Acknowledge the user's framing before answering.
하위 에이전트 생성 제어하기 (Controlling subagent spawning)
Claude Opus 4.8은 기본으로 하위 에이전트를 더 적게 만드는 경향이 있어요. 하지만 이 행동은 프롬프팅으로 이끌 수 있으니, 하위 에이전트가 언제 바람직한지에 대한 명시적 안내를 주세요. 코딩 사용 사례의 장난감 예시:
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.
디자인과 프론트엔드 기본값 (Design and frontend defaults)
Claude Opus 4.8은 강력한 디자인 감각을 갖췄고 일관된 기본 하우스 스타일이 있어요: 따뜻한 크림/오프화이트 배경(~#F4F1EA), 세리프 디스플레이 활자(Georgia, Fraunces, Playfair), 이탤릭 단어 악센트, 테라코타/앰버 액센트. 이는 에디토리얼, 호스피탈리티, 포트폴리오 브리프에는 잘 어울리지만 대시보드, 개발 도구, 핀테크, 헬스케어, 엔터프라이즈 앱에는 어긋나 보여요. 이 기본값은 슬라이드 데크와 웹 UI에 나타나요.
이 기본값은 지속적이에요. 일반 지시("크림 쓰지 마세요", "깔끔하고 미니멀하게")는 다양성을 만들기보다 모델을 다른 고정 팔레트로 이동시키는 경향이 있어요. 두 가지 접근이 안정적으로 동작해요:
1. 구체적 대안을 지정하세요. 모델은 명시적 스펙을 정밀하게 따라요:
Design a desktop landing page for a supplement brand called AEFRM.
The visual direction should come from a cold monochrome atmosphere using pale silver-gray tones that gradually deepen into blue-gray and near-black, similar to a misted metallic surface.
The page should feel sharp and controlled, with a strong sense of structure and restraint.
Use this tonal system across the full page instead of introducing bright accent colors.
Use the uploaded image on the hero design in black and white.
The layout should be built with clear horizontal sections and a centered max-width container. Use 4px corner radius consistently across cards, buttons, inputs, and media frames. Margins should feel generous, with enough empty space around each section so the page breathes.
Typography should use a square, angular sans-serif with wider letter spacing than usual, especially in headings and navigation, so the text feels more engineered and less compressed. Headline text can be large and uppercase, while supporting copy remains short and sparse. The sub texts should be written with Alumni Sans SC in 4-6px like tiny little texts on corners bottom centre like that.
For the structure, start with a hero section containing a strong product statement, one short supporting paragraph, and a clean product placeholder or packshot frame. Below that, add a benefit grid with three or four blocks, then a formulation or ingredients section, and finally a cta.
Buttons should be flat and precise, with subtle hover changes using transition: all 160ms ease out where brightness and border contrast shift slightly rather than using dramatic motion.
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.
또한 Claude Opus 4.8은 사용자들이 "AI slop" 미학이라고 부르는 일반 패턴을 피하기 위해 이전 모델보다 프론트엔드 디자인 프롬프팅이 덜 필요해요. 이전 모델에서는 Anthropic이 frontend-design 스킬에서 더 긴 프롬프트 스니펫을 권장했어요. 하지만 Claude Opus 4.8은 더 최소한의 프롬프팅 지침으로 독특하고 창의적인 프론트엔드를 만들어요. 이 프롬프트 스니펫은 앞선 다양성 조언과 잘 동작해요:
<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>
대화형 코딩 제품 (Interactive coding products)
Claude Opus 4.8의 토큰 사용과 행동은 단일 사용자 턴을 가진 자율 비동기 코딩 에이전트와 여러 사용자 턴을 가진 대화형 동기 코딩 에이전트 사이에 다를 수 있어요. 구체적으로 대화형 설정에서 토큰을 더 많이 쓰는 경향이 있는데, 주로 사용자 턴 이후 더 많이 추론하기 때문이에요. 이는 길고 대화적인 코딩 세션에서 장기 일관성, 지시 이행, 코딩 능력을 향상시킬 수 있지만 더 많은 토큰 사용도 수반해요. 코딩 제품에서 성능과 토큰 효율을 모두 극대화하려면 xhigh나 high effort를 쓰고, 자동 모드 같은 자율 기능을 추가하며, 사용자에게 요구하는 인간 상호작용 수를 줄이세요.
물론 필요한 사용자 상호작용 수를 제한할 때는 첫 인간 턴에서 과제, 의도, 관련 제약을 미리 명시하는 것이 중요해요. 미리 잘 명시되고 명확하며 정확한 과제 설명을 제공하면 자율성과 지능을 극대화하면서 사용자 턴 이후의 추가 토큰 사용을 최소화해요. Claude Opus 4.8은 이전 모델보다 더 자율적이므로 이 사용 패턴이 성능을 극대화해요. 반대로 여러 사용자 턴에 걸쳐 점진적으로 전달되는 모호하거나 불완전하게 명시된 프롬프트는 상대적으로 토큰 효율을 떨어뜨리고 때로는 성능도 떨어뜨려요.
코드 리뷰 하네스 (Code review harnesses)
Claude Opus 4.8은 이전 모델보다 버그를 찾는 데 의미 있게 더 좋고, 내부 평가에서 회상률과 정밀도가 모두 더 높아요. 하지만 코드 리뷰 하네스가 이전 모델용으로 조정되었다면 처음에는 회상률이 더 낮게 보일 수 있어요. 이는 하네스 효과일 가능성이 높지, 능력 회귀가 아니에요. 리뷰 프롬프트가 "심각도 높은 이슈만 보고하세요", "보수적으로 하세요", "사소한 것 지적하지 마세요" 같은 말을 하면 Claude Opus 4.8은 이전 모델보다 그 지시를 더 충실히 따를 수 있어요. 코드를 똑같이 철저히 조사하고 버그를 찾은 뒤, 사용자가 정한 기준 아래라고 판단한 발견은 보고하지 않을 수 있죠. 이는 모델이 같은 깊이로 조사하면서도 특히 낮은 심각도의 버그에서 더 적은 조사를 보고된 발견으로 전환하는 것으로 나타날 수 있어요. 정밀도는 보통 오르지만, 모델의 근본 버그 발견 능력이 향상됐음에도 측정된 회상률은 떨어질 수 있어요.
권장 프롬프트 언어:
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.
이 프롬프트는 실제 두 번째 단계 없이도 사용할 수 있지만, 발견 단계에서 신뢰도 필터링을 빼면 종종 도움이 돼요. 하네스에 별도의 검증·중복 제거·순위 단계가 있다면, 발견 단계에서 자기 임무는 필터링이 아니라 커버리지라고 모델에 명시적으로 말하세요.
단일 패스에서 모델이 스스로 필터링하길 원한다면 "중요한" 같은 질적 용어보다 기준이 어디인지 구체적으로 말하세요. 예: "잘못된 동작, 테스트 실패, 오해를 유발하는 결과를 일으킬 수 있는 모든 버그를 보고하세요. 순수한 스타일이나 명명 선호 같은 사소한 것은 생략하세요."
평가나 테스트 케이스의 일부에 대해 프롬프트를 반복해 회상률이나 F1 점수 향상을 검증하세요.
Computer use
Claude Opus 4.8은 computer_toolset_20260801 툴셋(Claude API와 Google Cloud)과 이전 computer_20251124 도구 버전을 지원해요. Claude API와 Google Cloud에서 Claude Opus 4.8은 웹페이지 안의 과제를 위한 browser use 도구(browser_toolset_20260801)도 지원해요. Computer use 능력은 최대 2576px / 3.75MP 해상도까지 다양한 해상도에서 동작해요. 내부 computer use 테스트는 1080p로 이미지를 보내는 것이 성능과 비용의 좋은 균형을 제공한다는 것을 보여줘요.
특히 비용 민감한 워크로드에서는 720p 또는 1366×768이 강력한 성능을 가진 저비용 옵션이에요. 자신의 사용 사례에 이상적인 설정을 찾으려면 직접 테스트하세요. effort 설정 실험이 모델 행동 조정에도 도움이 될 수 있어요.