• Messages
  • Managed Agents
  • 관리자

Search...
⌘K
사용 사례
개요티켓 라우팅고객 지원 에이전트콘텐츠 조정법률 요약
프롬프트 엔지니어링
개요프롬프트 작성 모범 사례Claude Fable 5 프롬프트 작성Claude Opus 4.8 프롬프트 작성Console 프롬프트 도구
테스트 및 평가
성공 정의 및 평가 빌드Console에서 평가 도구 사용하기지연 시간 줄이기
가드레일 강화
환각 줄이기출력 일관성 높이기탈옥 완화프롬프트 유출 줄이기
레퍼런스
용어집

Log in
Claude Opus 4.8 프롬프트 작성
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Amazon Bedrock
  • Google Cloud's Vertex AI

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
모범 사례/프롬프트 엔지니어링

Claude Opus 4.8 프롬프트 작성

Claude Opus 4.8의 동작 차이점과 프롬프트 작성 패턴으로, 상세도, 노력 수준 조정, 도구 사용, 서브에이전트, 프론트엔드 기본값을 다룹니다.

이 가이드는 Claude Opus 4.8에 특화된 프롬프트 작성 패턴을 다룹니다. 모델의 기능과 API 변경 사항은 Claude Opus 4.8의 새로운 기능을 참조하세요. 현재 모든 Claude 모델에 적용되는 기법은 프롬프트 작성 모범 사례를 참조하세요.

Claude Opus 4.8은 장기 에이전트 작업, 지식 작업, 비전, 메모리 작업에서 특히 강점을 보입니다. 기존 Claude Opus 4.7 프롬프트에서도 별도 조정 없이 좋은 성능을 발휘합니다. 아래 패턴은 조정이 가장 자주 필요한 동작을 다룹니다.



Claude Opus 4.7에서 마이그레이션할 때의 API 파라미터 변경 사항(샘플링 파라미터, effort 기본값, 1M 컨텍스트 윈도우 기본값(Microsoft Foundry에서는 200k), 대화 중간 시스템 메시지, refusal stop 세부 정보)은 마이그레이션 가이드를 참조하세요.

응답 길이와 상세도

Claude Opus 4.8은 고정된 상세도를 기본값으로 사용하는 대신, 작업의 복잡도를 판단하여 응답 길이를 조정합니다. 이는 일반적으로 간단한 조회에는 더 짧은 답변을, 개방형 분석에는 훨씬 더 긴 답변을 의미합니다.

제품이 특정 스타일이나 출력 상세도에 의존하는 경우 프롬프트를 조정해야 할 수 있습니다. 예를 들어 상세도를 줄이려면 다음을 추가할 수 있습니다:

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

특정 유형의 장황함(예: 과도한 설명)이 나타나는 경우, 이를 방지하기 위해 프롬프트에 추가 지침을 넣을 수 있습니다. Claude가 적절한 수준의 간결함으로 소통하는 방법을 보여주는 긍정적인 예시가, 모델에게 하지 말아야 할 것을 알려주는 부정적인 예시나 지침보다 더 효과적인 경향이 있습니다.

노력 수준과 사고 깊이 조정

effort 파라미터를 사용하면 Claude의 지능과 토큰 사용량을 조정하여, 기능을 더 빠른 속도와 낮은 비용으로 교환할 수 있습니다. 코딩 및 에이전트 사용 사례에는 xhigh effort 수준으로 시작하고, 대부분의 지능이 중요한 사용 사례에는 최소 high effort를 사용하세요. 토큰 사용량과 지능을 더 세밀하게 조정하려면 다른 effort 수준을 실험해 보세요:

  • max: Max effort는 일부 사용 사례에서 성능 향상을 제공할 수 있지만, 토큰 사용량 증가에 비해 수익이 체감할 수 있습니다. 이 설정은 때때로 과도한 사고로 이어질 수도 있습니다. 지능이 많이 요구되는 작업에 max effort를 테스트해 보세요.
  • xhigh: Extra high effort는 대부분의 코딩 및 에이전트 사용 사례에 가장 적합한 설정입니다.
  • high: 이 설정은 토큰 사용량과 지능의 균형을 맞춥니다. 대부분의 지능이 중요한 사용 사례에는 최소 high effort를 사용하세요.
  • medium: 지능을 일부 희생하면서 토큰 사용량을 줄여야 하는 비용에 민감한 사용 사례에 적합합니다.
  • low: 지능이 중요하지 않은 짧고 범위가 제한된 작업과 지연 시간에 민감한 워크로드에만 사용하세요.

Claude Opus 4.8은 특히 낮은 수준에서 effort 수준을 엄격하게 준수합니다. low와 medium에서 모델은 요청된 것 이상으로 나아가지 않고 요청된 범위 내에서 작업합니다. 이는 지연 시간과 비용 측면에서 좋지만, low effort로 실행되는 중간 정도 복잡도의 작업에서는 사고가 부족할 위험이 있습니다.

복잡한 문제에서 얕은 추론이 관찰되면, 프롬프트로 우회하기보다는 effort를 high 또는 xhigh로 높이세요. 지연 시간 때문에 effort를 low로 유지해야 하는 경우, 구체적인 지침을 추가하세요:

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

Effort는 이전의 어떤 Opus보다 이 모델에서 더 중요할 가능성이 높으므로, 업그레이드할 때 적극적으로 실험해 보세요.

Claude Opus 4.8에서는 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.

반대로, medium에서 어려운 워크로드를 실행하면서 사고가 부족한 경우, 첫 번째 수단은 effort를 높이는 것입니다. 더 세밀한 제어가 필요하면 프롬프트로 직접 지시하세요.



Claude Opus 4.8을 max 또는 xhigh effort로 실행하는 경우, 모델이 서브에이전트와 도구 호출 전반에 걸쳐 사고하고 행동할 공간을 확보할 수 있도록 큰 최대 출력 토큰 예산을 설정하세요. 64k 토큰에서 시작하여 조정하세요.

도구 사용 트리거

Claude Opus 4.8은 도구 호출보다 추론을 선호하는 경향이 있습니다. 이는 대부분의 경우 더 나은 결과를 제공합니다. 그러나 effort 설정을 높이는 것은 특히 지식 작업에서 도구 사용 수준을 높이는 유용한 수단입니다. high 또는 xhigh effort 설정은 에이전트 검색 및 코딩에서 훨씬 더 많은 도구 사용을 보여줍니다. 더 많은 도구 사용을 원하는 시나리오에서는 모델에게 언제 어떻게 도구를 적절히 사용해야 하는지 명시적으로 지시하도록 프롬프트를 조정할 수도 있습니다. 예를 들어, 모델이 웹 검색 도구를 사용하지 않는 경우, 왜 그리고 어떻게 사용해야 하는지 명확하게 설명하세요.

사용자 대상 진행 상황 업데이트

Claude Opus 4.8은 긴 에이전트 트레이스 전반에 걸쳐 사용자에게 더 정기적이고 품질 높은 업데이트를 제공합니다. 중간 상태 메시지를 강제하기 위한 스캐폴딩("도구 호출 3회마다 진행 상황 요약")을 추가했다면 제거해 보세요. Claude Opus 4.8의 사용자 대상 업데이트의 길이나 내용이 사용 사례에 잘 맞지 않는 경우, 프롬프트에서 이러한 업데이트가 어떤 모습이어야 하는지 명시적으로 설명하고 예시를 제공하세요.

더 문자 그대로의 지침 준수

Claude Opus 4.8은 특히 낮은 effort 수준에서 프롬프트를 문자 그대로 명시적으로 해석합니다. 한 항목에 대한 지침을 다른 항목으로 암묵적으로 일반화하지 않으며, 요청하지 않은 것을 추론하지 않습니다. 이러한 문자 그대로의 해석의 장점은 정밀성과 혼란 감소이며, 신중하게 조정된 프롬프트, 구조화된 추출, 예측 가능한 동작이 필요한 파이프라인이 있는 API 사용 사례에서 일반적으로 더 나은 성능을 발휘합니다. Claude가 지침을 광범위하게 적용하도록 하려면 범위를 명시적으로 지정하세요(예: "이 서식을 첫 번째 섹션뿐만 아니라 모든 섹션에 적용하세요").

어조와 작문 스타일

모든 새 모델과 마찬가지로 장문 작성의 산문 스타일이 달라질 수 있습니다. Claude Opus 4.8은 검증 중심의 표현을 최소화하고 이모지를 절제하여 사용하는 직접적이고 의견이 뚜렷한 스타일을 지향합니다. 제품이 특정 어조에 의존하는 경우, 새로운 기준선에 맞춰 스타일 프롬프트를 재평가하세요.

예를 들어, 제품의 어조가 더 따뜻하거나 대화체인 경우 다음을 추가하세요:

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

서브에이전트 생성 제어

Claude Opus 4.8은 기본적으로 더 적은 서브에이전트를 생성하는 경향이 있습니다. 그러나 이 동작은 프롬프트를 통해 조정할 수 있습니다. 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.

디자인 및 프론트엔드 기본값

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>

대화형 코딩 제품

Claude Opus 4.8의 토큰 사용량과 동작은 단일 사용자 턴이 있는 자율적이고 비동기적인 코딩 에이전트와 여러 사용자 턴이 있는 대화형 동기식 코딩 에이전트 간에 다를 수 있습니다. 구체적으로, 대화형 환경에서 더 많은 토큰을 사용하는 경향이 있는데, 이는 주로 사용자 턴 이후에 더 많이 추론하기 때문입니다. 이는 길고 대화형인 코딩 세션에서 장기 일관성, 지침 준수, 코딩 능력을 향상시킬 수 있지만, 더 많은 토큰 사용을 수반합니다. 코딩 제품에서 성능과 토큰 효율성을 모두 극대화하려면 xhigh 또는 high effort를 사용하고, 자동 모드와 같은 자율 기능을 추가하며, 사용자에게 요구되는 인간 상호작용 횟수를 줄이세요.

물론, 필요한 사용자 상호작용 횟수를 제한할 때는 첫 번째 사용자 턴에서 작업, 의도, 관련 제약 조건을 미리 명시하는 것이 중요합니다. 잘 명시되고 명확하며 정확한 작업 설명을 미리 제공하면 사용자 턴 이후의 추가 토큰 사용을 최소화하면서 자율성과 지능을 극대화하는 데 도움이 됩니다. Claude Opus 4.8은 이전 모델보다 더 자율적이므로 이러한 사용 패턴이 성능을 극대화하는 데 도움이 됩니다. 반대로, 여러 사용자 턴에 걸쳐 점진적으로 전달되는 모호하거나 불충분하게 명시된 프롬프트는 상대적으로 토큰 효율성과 때로는 성능을 저하시키는 경향이 있습니다.

코드 리뷰 하네스

Claude Opus 4.8은 이전 모델보다 버그를 찾는 데 의미 있게 더 뛰어나며, 내부 평가에서 더 높은 재현율(recall)과 정밀도(precision)를 모두 보입니다. 그러나 코드 리뷰 하네스가 이전 모델에 맞춰 조정된 경우, 처음에는 더 낮은 재현율을 볼 수 있습니다. 이는 능력 저하가 아니라 하네스 효과일 가능성이 높습니다. 리뷰 프롬프트에 "심각도가 높은 문제만 보고하세요", "보수적으로 하세요", "사소한 것은 지적하지 마세요"와 같은 내용이 있는 경우, 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 점수 향상을 검증하세요.

컴퓨터 사용

컴퓨터 사용 기능은 최대 2576px / 3.75MP 해상도까지 다양한 해상도에서 작동합니다. 내부 컴퓨터 사용 테스트에 따르면 1080p로 이미지를 전송하는 것이 성능과 비용의 좋은 균형을 제공합니다.

특히 비용에 민감한 워크로드의 경우, 720p 또는 1366×768은 강력한 성능을 제공하는 저비용 옵션입니다. 사용 사례에 이상적인 설정을 찾기 위해 자체 테스트를 수행하세요. effort 설정을 실험하는 것도 모델의 동작을 조정하는 데 도움이 될 수 있습니다.

Was this page helpful?

  • 응답 길이와 상세도
  • 노력 수준과 사고 깊이 조정
  • 도구 사용 트리거
  • 사용자 대상 진행 상황 업데이트
  • 더 문자 그대로의 지침 준수
  • 어조와 작문 스타일
  • 서브에이전트 생성 제어
  • 디자인 및 프론트엔드 기본값
  • 대화형 코딩 제품
  • 코드 리뷰 하네스
  • 컴퓨터 사용