Claude Sonnet 5 프롬프팅
Claude Sonnet 5 프롬프팅 (Prompting Claude Sonnet 5)
이 문서는 Claude Sonnet 5에 특화된 프롬프팅 패턴을 다루는 가이드예요. effort, 적응형 thinking 기본값, 도구 사용, Claude Sonnet 4.6에서의 마이그레이션을 중심으로 설명해 드릴게요. 코딩과 에이전트 과제에 특히 강한 모델이니, 어떤 프롬프트 조정이 가장 유용한지 하나씩 살펴볼게요.
출처: 문서
본문
이 가이드는 Claude Sonnet 5에 특화된 프롬프팅 패턴을 다뤄요. 모델의 기능과 API 변경은 Claude Sonnet 5의 새로운 점을, 모든 현재 Claude 모델에 적용되는 기법은 프롬프트 모범 사례를 참고하세요.
Claude Sonnet 5는 코딩과 에이전트 과제에 특히 강해요. 기존 Claude Sonnet 4.6 프롬프트에서도 기본으로 잘 동작해요. 이 가이드의 패턴들은 튜닝이 가장 자주 필요한 행동을 다룹니다.
응답 길이와 장황함 (Response length and verbosity)
Claude Sonnet 5는 고정된 장황함을 기본으로 하기보다, 과제의 복잡성에 응답 길이를 보정해요. 이는 보통 단순 조회에서는 더 짧은 답을, 개방형 분석에서는 더 긴 답을 의미해요.
제품이 특정 스타일이나 출력 장황함에 의존한다면 프롬프트를 조정해야 할 수 있어요. 예를 들어 장황함을 줄이려면 이렇게 추가할 수 있어요:
Provide concise, focused responses. Skip non-essential context, and keep examples minimal.
특정 종류의 장황함(과도한 설명 같은)을 본다면 프롬프트에 추가 지시를 넣어 막을 수 있어요. Claude가 적절한 수준의 간결함으로 소통하는 방법을 보여주는 긍정적 예시가, 무엇을 하지 말라고 말하는 부정적 예시나 지시보다 더 효과적인 경향이 있어요.
effort와 thinking 깊이 보정하기 (Calibrating effort and thinking depth)
effort 파라미터로 Claude의 지능과 토큰 지출을 맞바꿀 수 있어요. 더 빠른 속도와 더 낮은 비용을 위해 능력을 맞교환하는 것이죠. Claude Sonnet 5에서 effort는 Claude Sonnet 4.6과 같은 high가 기본이에요. 가장 어려운 코딩·에이전트 과제에는 effort를 xhigh로 올리세요. 다른 effort 수준도 실험해 토큰 사용과 지능을 더 조정하세요:
max: 토큰 지출에 제약 없는 절대 최대 능력.xhigh: Extra high effort는 가장 어려운 코딩·에이전트 사용 사례의 권장 설정이에요.high: 기본값. 이 설정은 대부분의 사용 사례에서 토큰 사용과 지능을 균형 잡아요.medium: 지능을 맞교환하며 토큰 사용을 줄여야 하는 비용 민감 사용 사례에 좋아요.low: 짧고 범위가 정해진 과제와 지능에 민감하지 않은 지연 민감 워크로드용으로 남겨 두세요.
마이그레이션할 때의 대략적인 교차 모델 매핑: medium의 Claude Sonnet 5는 high의 Claude Sonnet 4.6과 지능이 비슷하고, high의 Claude Sonnet 5는 max의 Claude Sonnet 4.6과 비슷해요. 벤치마킹할 때는 effort 이름보다 관찰된 thinking 길이로 맞추세요.
Claude Sonnet 5는 effort 수준을 엄격히 존중해요. 특히 낮은 쪽에서요. low와 medium에서는 모델이 그 이상을 하기보다 요청된 것에 작업을 한정해요. 이는 지연과 비용에는 좋지만, 보통 복잡도의 과제를 low effort로 돌리면 thinking 부족 위험이 있어요.
복잡한 문제에서 얕은 추론이 보인다면 프롬프팅으로 우회하기보다 effort를 high나 xhigh로 올리세요. 지연 때문에 effort를 low로 유지해야 한다면 타겟 안내를 추가하세요:
This task involves multistep reasoning. Think carefully through the problem before responding.
Claude Sonnet 5에서는 적응형 thinking이 기본으로 켜져 있어요. thinking 필드가 없는 요청은 적응형 thinking으로 실행돼요. 이는 같은 요청이 thinking 없이 실행됐던 Claude Sonnet 4.6과의 변화예요. thinking을 완전히 끄려면 thinking: {type: "disabled"}를 전달하세요. max_tokens은 총 출력(thinking + 응답 텍스트)의 하드 한계이므로, Claude Sonnet 4.6에서 thinking 없이 동작했던 워크로드에 대해 그것을 다시 검토하세요. 이전에 Claude Sonnet 4.6에서 thinking을 끄고 썼다면, Claude Sonnet 5에서는 낮은 effort 수준으로 thinking을 켜 보세요.
적응형 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를 올리는 것이에요. 더 세밀한 제어가 필요하면 직접 프롬프팅하세요.
수동 확장 thinking(thinking: {type: "enabled", budget_tokens: N})은 Claude Sonnet 5에서 지원되지 않고 400 오류를 반환해요. Claude Sonnet 4.6에서 이미 deprecated였고 이제 제거됐어요. 대신 effort 파라미터와 함께 적응형 thinking을 사용하세요.
도구 사용 트리거링 (Tool use triggering)
Claude Sonnet 5는 기본적으로 Claude Sonnet 4.6보다 더 에이전트적이고, 도구에 손이 더 쉽게 가며 자기 검증 루프를 더 쉽게 실행해요. thinking이 비활성화되면 모델이 도구에 손을 대거나 검색을 고려할 가능성이 더 낮아요. thinking을 끄고 도구 호출에 의존한다면 시스템 프롬프트에 명시적 넛지를 추가하세요. effort도 도구 사용의 손잡이예요. high나 xhigh effort 설정은 에이전트 검색과 코딩에서 훨씬 더 많은 도구 사용을 보여요. 더 많은 도구 사용을 원하는 시나리오에서는 프롬프트를 조정해 언제 어떻게 도구를 제대로 쓸지 명시적으로 지시할 수도 있어요. 예를 들어 모델이 웹 검색 도구를 쓰지 않는다면 왜 어떻게 써야 하는지 명확히 설명하세요.
사용자 대상 진행 업데이트 (User-facing progress updates)
Claude Sonnet 5는 긴 에이전트 트레이스 내내 규칙적이고 더 높은 품질의 업데이트를 사용자에게 제공해요. 중간 상태 메시지를 강제하는 스캐폴딩("매 3번의 도구 호출 후 진행 요약")을 추가했다면 제거해 보세요. Claude Sonnet 5의 사용자 대상 업데이트 길이나 내용이 자기 사용 사례에 잘 보정되지 않았다면, 이 업데이트가 어떻게 보여야 하는지 프롬프트에 명시적으로 설명하고 예시를 제공하세요.
더 문자 그대로의 지시 이행 (More literal instruction following)
Claude Sonnet 5는 특히 낮은 effort 수준에서 프롬프트를 문자 그대로, 명시적으로 해석해요. 한 항목에서 다른 항목으로 지시를 조용히 일반화하지 않고, 요청하지 않은 것은 추론하지 않아요. 이 문자주의의 장점은 정밀함이고, 신중하게 조정된 프롬프트를 쓰는 API 사용 사례, 구조화된 추출, 예측 가능한 동작을 원하는 파이프라인에서 일반적으로 더 잘 동작해요. Claude가 지시를 넓게 적용하길 필요하다면 범위를 명시적으로 말하세요(예: "이 서식을 모든 섹션에 적용하세요. 첫 번째 뿐만 아니라").
어조와 글쓰기 스타일 (Tone and writing style)
어떤 새 모델에서와 마찬가지로, 장문 글쓰기의 산문 스타일이 바뀔 수 있어요. 제품이 특정 음성에 의존한다면 새 기준 대비 스타일 프롬프트를 재평가하세요.
예를 들어 제품 음성이 더 따뜻하거나 대화적이라면 추가하세요:
Use a warm, collaborative tone. Acknowledge the user's framing before answering.
이전에 스타일 다양성을 위해 temperature에 의존했다면, temperature, top_p, top_k를 기본값이 아닌 값으로 설정하면 Claude Sonnet 5에서 400 오류가 반환된다는 점을 주의하세요. 이 제약은 Sonnet 클래스 모델에 새로운 것이에요. 마이그레이션할 때 이 파라미터들을 제거하고 어조와 다양성을 이끄는 데 시스템 프롬프트 지시를 사용하세요.
디자인과 프론트엔드 기본값 (Design and frontend defaults)
Claude Sonnet 5는 개방형 프론트엔드·디자인 브리프에서 일관된 기본 시각 스타일에 안착할 수 있어요. 기본 하우스 스타일은 일부 브리프에 잘 어울릴 수 있지만 대시보드, 개발 도구, 핀테크, 헬스케어, 엔터프라이즈 앱에는 어긋나 보일 수 있어요.
일반 지시("그 색 쓰지 마세요", "깔끔하고 미니멀하게")는 다양성을 만들기보다 모델을 다른 고정 팔레트로 이동시키는 경향이 있어요. 두 가지 접근이 안정적으로 동작해요:
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가 Claude Sonnet 5에서 받아들여지지 않으므로, 이것이 실행마다 의미 있게 다른 디자인 방향을 만드는 권장 방법이에요. 예시 프롬프트:
Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface, plus a one-line rationale). Ask the user to pick one, then implement only that direction.
사용자들이 "AI slop" 미학이라고 부르는 일반 패턴에서 벗어나려면 시스템 프롬프트에 짧은 지시를 포함할 수 있어요. frontend-design 스킬이 더 완전한 처리를 제공하지만, 이 스니펫은 앞선 다양성 접근과 잘 어울려요:
<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)
단일 사용자 턴을 가진 자율 비동기 코딩 에이전트와 여러 사용자 턴을 가진 대화형 동기 코딩 에이전트 사이에 토큰 사용과 행동이 다를 수 있어요. 코딩 제품에서 성능과 토큰 효율을 모두 극대화하려면 xhigh나 high effort를 쓰고, 자동 모드 같은 자율 기능을 추가하며, 사용자에게 요구하는 인간 상호작용 수를 줄이세요.
필요한 사용자 상호작용 수를 제한할 때는 첫 인간 턴에서 과제, 의도, 관련 제약을 미리 명시하는 것이 중요해요. 미리 잘 명시되고 명확하며 정확한 과제 설명을 제공하면 자율성과 지능을 극대화하면서 사용자 턴 이후의 추가 토큰 사용을 최소화해요. 반대로 여러 사용자 턴에 걸쳐 점진적으로 전달되는 모호하거나 불완전하게 명시된 프롬프트는 상대적으로 토큰 효율을 떨어뜨리고 때로는 성능도 떨어뜨려요.
코드 리뷰 하네스 (Code review harnesses)
코드 리뷰 하네스가 이전 모델용으로 조정되었다면 Claude Sonnet 5에서는 처음에 회상률이 더 낮게 보일 수 있어요. 이는 하네스 효과일 가능성이 높지, 능력 회귀가 아니에요. 리뷰 프롬프트가 "심각도 높은 이슈만 보고하세요", "보수적으로 하세요", "사소한 것 지적하지 마세요" 같은 말을 하면 Claude Sonnet 5는 이전 모델보다 그 지시를 더 충실히 따를 수 있어요. 코드를 똑같이 철저히 조사하고 버그를 찾은 뒤, 사용자가 정한 기준 아래라고 판단한 발견은 보고하지 않을 수 있죠. 이는 모델이 같은 깊이로 조사하면서도 특히 낮은 심각도의 버그에서 더 적은 조사를 보고된 발견으로 전환하는 것으로 나타날 수 있어요. 정밀도는 보통 오르지만, 모델의 근본 버그 발견 능력이 향상됐음에도 측정된 회상률은 떨어질 수 있어요.
권장 프롬프트 언어:
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 Sonnet 5는 computer_toolset_20260801 툴셋(Claude API와 Google Cloud)과 이전 computer_20251124 도구 버전을 지원해요. Claude API와 Google Cloud에서 Claude Sonnet 5는 웹페이지 안의 과제를 위한 browser use 도구(browser_toolset_20260801)도 지원해요. Computer use 능력은 최대 2576px / 3.75MP 해상도까지 다양한 해상도에서 동작해요. 내부 computer use 테스트는 1080p로 이미지를 보내는 것이 성능과 비용의 좋은 균형을 제공한다는 것을 보여줘요.
특히 비용 민감한 워크로드에서는 720p 또는 1366×768이 강력한 성능을 가진 저비용 옵션이에요. 자신의 사용 사례에 이상적인 설정을 찾으려면 직접 테스트하세요. effort 설정 실험이 모델 행동 조정에도 도움이 될 수 있어요.