Claude Sonnet 5의 동작 방식 차이와 프롬프팅 패턴을 안내합니다. 여기에는 노력(effort) 매개변수, 적응형 사고(adaptive thinking) 기본값, 도구 사용(tool use), 그리고 Claude Sonnet 4.6에서의 마이그레이션 방법이 포함됩니다.
본 가이드는 Claude Sonnet 5에 특화된 프롬프팅 패턴을 다룹니다. 모델의 기능과 API 변경 사항에 대해서는 Claude Sonnet 5의 새로운 기능을 참조하십시오. 현재 모든 Claude 모델에 적용되는 기법은 프롬프팅 모범 사례를 확인하시기 바랍니다.
Claude Sonnet 5는 코딩과 에이전트 기반 작업에서 특별한 강점을 보입니다. 기존 Claude Sonnet 4.6 프롬프트에서도 별도의 설정 없이 훌륭하게 작동합니다. 이 가이드에서 다루는 패턴들은 주로 튜닝이 필요한 동작 방식들에 초점을 맞추고 있습니다.
응답 길이와 장황함 (Verbosity)
Claude Sonnet 5는 고정된 응답 길이를 기본값으로 삼기보다는, 작업의 복잡도에 맞춰 응답 길이를 자체적으로 조정합니다. 즉, 단순한 정보 검색에는 더 짧게, 개방형(open-ended) 분석에는 더 길게 답하는 경향이 있습니다.
만약 귀하의 제품이 특정 스타일이나 정해진 분량의 응답에 의존한다면 프롬프트를 튜닝해야 할 수도 있습니다. 예를 들어, 응답을 더 간결하게 만들려면 다음과 같이 추가할 수 있습니다:
Plaintext
간결하고 핵심에 집중한 응답을 제공하세요. 불필요한 맥락은 생략하고, 예시는 최소한으로 유지하세요.특정 형태의 장황함(예: 과도한 설명)이 나타난다면, 이를 방지하기 위한 추가 지침을 프롬프트에 넣을 수 있습니다. 모델에게 하지 말아야 할 것을 지시하는 부정적인 예시보다는, Claude가 적절한 수준의 간결함으로 소통하는 방법을 보여주는 긍정적인 예시를 제공하는 것이 대체로 더 효과적입니다.
노력(Effort)과 사고 깊이 조정
노력(effort) 매개변수를 사용하면 Claude의 지능과 토큰 소비량 간의 균형을 조정하여, 더 빠른 속도 및 낮은 비용과 모델의 성능을 맞교환할 수 있습니다. Claude Sonnet 5에서 이 설정의 기본값은 Claude Sonnet 4.6과 동일한 high입니다. 최고 난이도의 코딩 및 에이전트 작업의 경우 effort를 xhigh로 높이십시오. 지능과 토큰 사용량을 추가로 조정하려면 다른 effort 수준도 실험해 보시기 바랍니다:
max: 토큰 소비에 제한을 두지 않는 절대적인 최대 성능.xhigh: 최고 난이도의 코딩 및 에이전트 사용 사례에 권장되는 특별히 높은 수준의 설정.high: 기본값. 대부분의 사용 사례에서 토큰 사용량과 지능 사이의 균형을 잘 잡아줍니다.medium: 지능을 일부 타협하더라도 토큰 사용량을 줄여야 하는 비용 민감형 사용 사례에 적합합니다.low: 지능보다는 지연 시간(latency)이 중요하고, 범위가 제한된 짧은 작업에만 사용하십시오.
마이그레이션 시 모델 간의 대략적인 매핑을 안내하자면, Claude Sonnet 5의 medium은 Claude Sonnet 4.6의 high와 지능 면에서 비슷하며, Claude Sonnet 5의 high는 Claude Sonnet 4.6의 max에 필적합니다. 벤치마킹을 수행할 때는 설정된 매개변수 이름보다는 실제 관찰되는 '사고의 길이(thinking length)'를 기준으로 비교하십시오.
Claude Sonnet 5는 설정된 effort 수준을 매우 엄격하게 준수하며, 특히 낮은 설정에서 그 특징이 두드러집니다. low나 medium 설정에서 모델은 요구받은 수준을 넘어서기보다는 요청된 범위 내로 작업을 제한합니다. 이는 지연 시간과 비용 측면에서는 긍정적이지만, 중간 정도의 복잡도를 가진 작업을 low 설정으로 실행할 경우 사고의 깊이가 얕아질(under-thinking) 위험이 있습니다.
복잡한 문제에서 얕은 추론이 관찰된다면, 프롬프트를 우회적으로 수정하기보다는 먼저 effort를 high나 xhigh로 높이십시오. 만약 지연 시간 문제로 low를 유지해야 한다면 다음과 같은 구체적인 지침을 추가하세요:
Plaintext
이 작업에는 다단계 추론이 필요합니다. 응답하기 전에 문제에 대해 주의 깊게 생각하세요.Claude Sonnet 5에서는 적응형 사고(adaptive thinking)가 기본적으로 활성화되어 있습니다. thinking 필드가 없는 요청도 적응형 사고를 거쳐 실행됩니다. 이는 동일한 요청이 사고 과정 없이 실행되었던 Claude Sonnet 4.6과 달라진 점입니다. 사고 과정을 완전히 끄려면 thinking: {type: "disabled"}를 전달하십시오. max_tokens는 전체 출력(사고 과정 + 응답 텍스트)을 제한하는 엄격한 한계치이므로, 기존에 Claude Sonnet 4.6에서 사고 과정 없이 실행했던 워크로드가 있다면 이를 다시 점검해야 합니다. 이전에 Claude Sonnet 4.6에서 사고 과정을 끄고 사용했다면, Claude Sonnet 5에서는 낮은 effort 수준으로 사고 과정을 켜고 시도해 보십시오.
적응형 사고가 작동하는 방식은 프롬프트를 통해 제어할 수 있습니다. 길고 복잡한 시스템 프롬프트를 사용할 때 모델이 너무 자주 사고 블록(thinking blocks)을 생성한다고 느껴진다면, 이를 조절하는 지침을 추가하십시오. 항상 그렇듯, 프롬프트 변경이 성능에 미치는 영향을 측정해야 합니다. 예시:
Plaintext
사고 과정(Thinking)은 지연 시간을 늘리므로, 다단계 추론이 필요한 문제처럼 답변의 질을 유의미하게 향상시킬 수 있을 때만 사용해야 합니다. 확신이 서지 않는다면 곧바로 응답하십시오.반대로, medium 설정에서 어려운 워크로드를 실행할 때 사고의 깊이가 부족하다면 첫 번째 해결책은 effort를 높이는 것입니다. 보다 세밀한 제어가 필요하다면 프롬프트에 직접 지시를 내리십시오.
수동 확장 사고(Manual extended thinking, thinking: {type: "enabled", budget_tokens: N})는 Claude Sonnet 5에서 지원되지 않으며 400 에러를 반환합니다. 이는 Claude Sonnet 4.6에서 이미 지원이 중단(deprecated)되었고 이제 완전히 제거되었습니다. 대신 effort 매개변수와 함께 적응형 사고를 사용하십시오.
도구 사용(Tool use) 트리거링
Claude Sonnet 5는 기본적으로 Claude Sonnet 4.6보다 더욱 에이전트적인 성향을 띠며, 도구를 활용하고 자체 검증 루프를 훨씬 더 기꺼이 실행합니다. 하지만 사고 과정(thinking)을 비활성화하면 모델이 도구를 사용하거나 검색을 시도할 가능성이 낮아집니다. 만약 사고 과정을 끈 상태에서 도구 호출에 의존해야 한다면 시스템 프롬프트에 명시적인 지시를 추가하십시오. Effort 매개변수 역시 도구 사용량에 영향을 미칩니다. high나 xhigh로 설정하면 에이전트 기반 검색 및 코딩에서 도구 사용량이 현저히 증가합니다. 도구를 더 적극적으로 활용하기 원한다면, 프롬프트를 조정해 모델이 도구를 언제, 어떻게 사용해야 하는지 명시적으로 지시할 수도 있습니다. 예를 들어, 모델이 웹 검색 도구를 사용하지 않는다면 그 이유와 활용 방법에 대해 분명히 설명해 주십시오.
사용자 대상 진행 상황 업데이트
Claude Sonnet 5는 긴 에이전트 작업 과정 내내 정기적이고 더 높은 품질의 진행 상황 업데이트를 사용자에게 제공합니다. 만약 기존에 중간 상태 메시지를 강제하기 위해 스캐폴딩(예: "도구를 3번 호출할 때마다 진행 상황을 요약하라")을 추가해 두었다면, 이를 제거해 보십시오. 만약 모델이 제공하는 업데이트의 길이나 내용이 귀하의 사용 사례에 잘 맞지 않는다면, 프롬프트에 이러한 업데이트가 어떤 형태여야 하는지 구체적인 예시와 함께 명시하십시오.
문자 그대로의 지시 따르기 (직관적 지시 수행)
Claude Sonnet 5는 프롬프트를 글자 그대로 명시적으로 해석하며, 이러한 경향은 낮은 effort 설정에서 특히 두드러집니다. 모델은 하나의 항목에 대한 지시를 다른 항목에 스스로 일반화시켜 적용하지 않으며, 사용자가 명시하지 않은 요청을 지레짐작하지도 않습니다. 이러한 직관성의 이점은 '정밀함'입니다. 세심하게 조정된 프롬프트, 구조화된 데이터 추출, 예측 가능한 동작이 요구되는 파이프라인 등 API 사용 사례에서 대체로 더 뛰어난 성능을 발휘합니다. 만약 모델이 어떤 지시를 폭넓게 적용하기를 원한다면 그 범위를 명확히 밝히십시오. (예: "이 서식을 첫 번째 섹션만이 아니라 모든 섹션에 동일하게 적용하세요.")
어조와 글쓰기 스타일
여느 새로운 모델이 그렇듯, 긴 글에서의 문체는 달라질 수 있습니다. 귀하의 제품이 특정 목소리나 어조에 의존한다면, 새로운 기준에 맞춰 스타일 프롬프트를 재평가하십시오.
예를 들어, 제품의 어조가 좀 더 따뜻하고 대화체에 가깝다면 다음과 같이 추가하십시오:
Plaintext
따뜻하고 협력적인 어조를 사용하세요. 답변하기 전에 사용자가 설정한 맥락을 먼저 인정하고 공감해 주십시오.만약 이전에 문체의 다양성을 주기 위해 temperature 값에 의존했다면, Claude Sonnet 5에서는 temperature, top_p, 또는 top_k를 기본값이 아닌 다른 값으로 설정할 경우 400 에러가 반환된다는 점에 유의하십시오. 이는 Sonnet 등급 모델에 새로 도입된 제약 사항입니다. 마이그레이션 시 해당 매개변수들을 제거하고, 대신 시스템 프롬프트 지침을 사용하여 어조와 다양성을 유도하십시오.
디자인 및 프론트엔드 기본 설정
Claude Sonnet 5는 개방형 프론트엔드 및 디자인 브리핑을 받을 때, 일관된 특정 기본 시각적 스타일로 고정되려는 경향이 있습니다. 이러한 기본 스타일은 일부 브리핑에는 잘 어울릴 수 있지만, 대시보드, 개발 도구, 핀테크, 헬스케어 또는 엔터프라이즈 앱에서는 다소 어색할 수 있습니다.
일반적인 지시어("그 색상은 피하세요", "깔끔하고 미니멀하게 만들어 주세요")는 다양성을 만들어내기보다는 모델을 단지 또 다른 고정된 팔레트로 옮겨가게 할 뿐입니다. 다음 두 가지 접근 방식이 더 확실하게 작동합니다:
1. 구체적인 대안을 명시하십시오. 모델은 명시적인 사양을 매우 정확하게 따릅니다:
Plaintext
AEFRM이라는 영양제 브랜드의 데스크톱 랜딩 페이지를 디자인하세요.
시각적 방향성은 차갑고 단색조의 분위기여야 하며, 창백한 은회색 톤에서 시작해 청회색과 옅은 안개가 낀 금속 표면과 같은 검정에 가까운 색상으로 점진적으로 깊어져야 합니다.
페이지는 구조와 절제미가 강하게 느껴지며, 날렵하고 정돈된 느낌을 주어야 합니다.
밝은 포인트 색상을 추가하는 대신, 전체 페이지에 걸쳐 이 톤 시스템을 일관되게 사용하세요.
히어로(hero) 디자인에는 업로드된 이미지를 흑백으로 사용하세요.
레이아웃은 명확한 가로형 섹션들과 중앙 정렬된 최대 너비(max-width) 컨테이너로 구축되어야 합니다. 카드, 버튼, 입력 필드, 미디어 프레임 전체에 일관되게 4px의 모서리 반경(corner radius)을 적용하세요. 마진은 넉넉하게 설정하여 각 섹션 주변에 페이지가 숨 쉴 수 있는 충분한 여백을 확보해야 합니다.
타이포그래피는 각지고 네모난 산세리프(sans-serif) 글꼴을 사용하며, 텍스트가 압축된 느낌보다는 공학적으로 설계된 느낌이 들도록 평소보다 자간을 더 넓게(특히 제목과 내비게이션에서) 설정하세요. 헤드라인 텍스트는 크고 대문자로 작성하되, 보조 문구는 짧고 간결하게 유지하십시오. 서브 텍스트는 Alumni Sans SC 폰트를 사용하여 4-6px 크기로, 모서리나 하단 중앙에 아주 작게 배치하세요.
구조적으로는 강렬한 제품 문구, 짧은 보조 단락, 깔끔한 제품 플레이스홀더나 팩샷(packshot) 프레임이 포함된 히어로 섹션으로 시작하세요. 그 아래에는 3~4개의 블록으로 구성된 제품의 장점(benefit) 그리드를 추가하고, 이어서 성분(formulation) 섹션과 마지막으로 CTA(콜투액션)를 배치하세요.
버튼은 평평(flat)하고 정교해야 하며, 과장된 애니메이션 대신 transition: all 160ms ease out을 사용하여 마우스 오버 시 밝기와 테두리 대비만 미세하게 변하도록 처리하세요.
색상 팔레트는 다음 범위 내에서 유지해야 합니다:
#E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.2. 작업을 시작하기 전에 모델에게 옵션을 제안하게 하십시오. 이 방법은 모델의 기본값을 깨뜨리고 사용자에게 제어권을 부여합니다. Claude Sonnet 5에서는 temperature 설정이 허용되지 않으므로, 실행할 때마다 유의미하게 다른 디자인 방향을 도출하려면 이 접근법이 가장 권장됩니다. 예시 프롬프트:
Plaintext
빌드를 시작하기 전에, 이 브리핑에 맞춘 4가지의 뚜렷한 시각적 방향을 제안하십시오(각각 배경 hex / 강조색 hex / 서체, 그리고 한 줄짜리 근거를 포함할 것). 사용자에게 하나를 선택하도록 요청한 후, 선택된 방향으로만 구현을 진행하십시오.사용자들이 이른바 'AI가 찍어낸 듯한 조잡함(AI slop)'이라 부르는 뻔한 미적 패턴에서 벗어나려면, 시스템 프롬프트에 짧은 지시문을 포함할 수 있습니다. 프론트엔드 디자인 스킬 문서에서 더 포괄적인 내용을 다루고 있지만, 다음 스니펫만으로도 앞서 언급한 다양성 유도 방식과 함께 훌륭하게 작동합니다:
Plaintext
<frontend_aesthetics>
과도하게 사용되는 폰트 패밀리(Inter, Roboto, Arial, 시스템 폰트), 진부한 색상 조합(특히 흰색이나 어두운 배경에 보라색 그라데이션), 뻔한 레이아웃과 컴포넌트 패턴, 그리고 맥락에 맞는 개성이 결여된 천편일률적인 디자인 등 흔히 볼 수 있는 AI 생성 미학을 절대 사용하지 마십시오. 독특한 폰트, 응집력 있는 색상과 테마, 그리고 효과 및 마이크로 인터랙션을 위한 애니메이션을 활용하십시오.
</frontend_aesthetics>인터랙티브 코딩 제품
단일 사용자 턴으로 동작하는 자율적이고 비동기적인 코딩 에이전트와 여러 번의 사용자 턴으로 동작하는 대화형 동기식 코딩 에이전트 간에는 토큰 사용량과 동작 방식이 다를 수 있습니다. 코딩 제품에서 성능과 토큰 효율성을 모두 극대화하려면 effort를 xhigh나 high로 설정하고, 자동 모드(auto mode)와 같은 자율적인 기능을 추가하여 사용자에게 요구되는 개입 횟수를 줄이십시오.
필요한 사용자 개입 횟수를 제한할 때는, 첫 번째 사용자 턴에서 작업 내용, 의도, 그리고 관련 제약 조건들을 사전에 분명히 명시하는 것이 중요합니다. 명확하고 정확하며 잘 정의된 작업 설명을 초기에 제공하면 자율성과 지능을 극대화하면서도 후속 턴에서 낭비되는 토큰을 최소화할 수 있습니다. 반면, 여러 번의 턴에 걸쳐 모호하고 불충분한 프롬프트를 점진적으로 전달할 경우 상대적으로 토큰 효율성이 떨어지고 때로는 성능 저하를 초래하기도 합니다.
코드 리뷰 도구 (Code review harnesses)
귀하의 코드 리뷰 도구가 이전 모델에 맞춰 튜닝되어 있었다면, 초기에는 Claude Sonnet 5에서 재현율(recall)이 낮아지는 현상을 목격할 수 있습니다. 이는 성능 퇴행이라기보다는 리뷰 도구 자체의 설정 때문일 가능성이 큽니다. 리뷰 프롬프트에 "심각도가 높은 문제만 보고하라", "보수적으로 접근하라", 또는 "트집 잡지 마라(don't nitpick)" 같은 지시가 포함되어 있을 경우, Claude Sonnet 5는 이전 모델들보다 그 지시를 훨씬 더 충실히 따를 수 있습니다. 즉, 코드를 동일하게 철저히 조사하고 버그를 찾아내더라도 사용자가 설정한 기준에 미치지 못한다고 판단되는 결과는 보고하지 않는 것입니다. 결과적으로 모델이 동일한 깊이로 탐색하더라도, 이를 실제 보고서로 변환하는 비율이 줄어들며 특히 심각도가 낮은 버그에서 이 현상이 두드러집니다. 통상적으로 정밀도(precision)는 상승하지만, 모델의 근본적인 버그 탐지 능력이 향상되었음에도 불구하고 측정된 재현율은 떨어질 수 있습니다.
권장하는 프롬프트 문구는 다음과 같습니다:
Plaintext
확신이 서지 않거나 심각도가 낮다고 생각되는 문제를 포함하여, 발견한 모든 문제를 보고하십시오. 이 단계에서는 중요도나 확신도에 따라 필터링하지 마십시오. 이는 별도의 검증 단계에서 수행될 것입니다. 여기서 귀하의 목표는 '포괄적인 탐지(coverage)'입니다. 진짜 버그를 말없이 무시하는 것보다는 나중에 필터링되더라도 일단 발견한 사항을 드러내는 것이 낫습니다. 후속 필터에서 순위를 매길 수 있도록, 각각의 발견 사항에 귀하의 확신도와 예상 심각도를 함께 포함해 주십시오.이 프롬프트는 실제로 두 번째 검증 단계를 갖추고 있지 않더라도 사용할 수 있지만, 대체로 버그 탐지 단계에서 확신도 필터링을 분리해 내는 것이 도움이 됩니다. 시스템에 별도의 검증, 중복 제거, 혹은 순위 매기기 단계가 있다면, 모델에게 발견 단계에서의 최우선 임무는 필터링이 아니라 커버리지를 높이는 것임을 명시적으로 알려주십시오.
만약 모델이 단일 패스(single pass)에서 스스로 필터링하기를 원한다면, "중요한"과 같은 정성적인 단어보다는 그 기준선이 어디인지 구체적으로 제시하십시오. 예를 들어, "잘못된 동작, 테스트 실패, 오해의 소지가 있는 결과를 유발할 수 있는 버그만 보고하고; 순수한 스타일이나 네이밍 선호도 같은 사소한 문제만 생략하십시오"라고 지시할 수 있습니다.
귀하의 평가 세트나 테스트 케이스의 일부를 활용해 프롬프트를 반복적으로 개선하면서 재현율이나 F1 점수의 향상을 검증하십시오.
컴퓨터 사용 (Computer use)
Claude Sonnet 5는 computer_20251124 도구 버전을 지원합니다. 컴퓨터 사용(Computer use) 기능은 다양한 해상도에서 작동하며, 최대 해상도는 2576px / 3.75MP입니다. 내부적인 컴퓨터 사용 테스트 결과에 따르면, 1080p 이미지를 전송할 때 성능과 비용 사이의 이상적인 균형을 제공하는 것으로 나타났습니다.
특히 비용에 민감한 워크로드의 경우, 720p 또는 1366×768 해상도가 훌륭한 성능을 유지하면서도 비용을 낮출 수 있는 좋은 대안입니다. 직접 테스트를 진행하여 귀하의 사용 사례에 가장 적합한 설정을 찾아보십시오. 더불어 effort 설정을 실험해 보는 것도 모델의 동작 방식을 미세 조정하는 데 큰 도움이 될 수 있습니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.