프롬프트 작성 모범 사례

이것은 Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5를 포함한 Claude의 최신 모델을 사용한 프롬프트 엔지니어링을 위한 단일 참고 자료입니다. 기초 기법, 출력 제어, 도구 사용, 사고, 에이전트 시스템을 다룹니다. 당신의 상황과 일치하는 섹션으로 이동하세요.

Claude Opus 4.7 프롬프팅

Claude Opus 4.7은 우리의 가장 강력한 일반 공개 모델로, 장기 에이전트 작업, 지식 작업, 비전, 메모리 작업에서 특히 강점을 가지고 있습니다. 기존 Claude Opus 4.6 프롬프트에서 기본적으로 잘 작동합니다. 아래의 패턴들은 가장 자주 조정이 필요한 동작을 다룹니다.

응답 길이 및 상세도

Claude Opus 4.7은 고정된 상세도로 기본값을 설정하는 대신 작업이 얼마나 복잡한지에 따라 응답 길이를 조정합니다. 이는 일반적으로 간단한 조회에서는 더 짧은 답변을, 개방형 분석에서는 훨씬 더 긴 답변을 의미합니다.

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

간결하고 집중된 응답을 제공하세요. 필수적이지 않은 맥락을 건너뛰고, 예제를 최소한으로 유지하세요.

특정 상세도 종류의 예제를 본다면(예: 과도한 설명), 이를 방지하기 위해 프롬프트에 추가 지침을 추가할 수 있습니다. Claude가 적절한 수준의 간결함으로 소통할 수 있는 방법을 보여주는 긍정적인 예제는 부정적인 예제나 모델이 하지 말아야 할 것을 말하는 지침보다 더 효과적인 경향이 있습니다.

노력과 사고 깊이 조정

노력 매개변수를 사용하면 Claude의 지능 대 토큰 지출을 조정하여 기능을 더 빠른 속도와 더 낮은 비용으로 거래할 수 있습니다. 코딩 및 에이전트 사용 사례에는 새로운 xhigh 노력 수준으로 시작하고, 대부분의 지능 민감 사용 사례에는 최소 high 노력을 사용하세요. 다른 노력 수준을 실험하여 토큰 사용량과 지능을 추가로 조정하세요:

• max: 최대 노력은 일부 사용 사례에서 성능 향상을 제공할 수 있지만, 증가된 토큰 사용으로 인한 수익 감소를 보일 수 있습니다. 이 설정은 때때로 과도한 사고에 취약할 수 있습니다. 우리는 지능이 많이 필요한 작업에 대해 최대 노력을 테스트할 것을 권장합니다.
• xhigh (신규): 초고 노력은 대부분의 코딩 및 에이전트 사용 사례에 가장 좋은 설정입니다.
• high: 이 설정은 토큰 사용량과 지능의 균형을 맞춥니다. 대부분의 지능 민감 사용 사례에 대해 우리는 최소 high 노력을 권장합니다.
• medium: 지능을 거래하면서 토큰 사용량을 줄여야 하는 비용 민감 사용 사례에 좋습니다.
• low: 짧고 범위가 정해진 작업과 지능 민감하지 않은 지연 시간 민감 워크로드를 위해 예약하세요.

Claude Opus 4.6과 의미 있게 변경되어, Claude Opus 4.7은 특히 낮은 끝에서 노력 수준을 엄격하게 준수합니다. low와 medium에서 모델은 그 이상을 하지 않고 요청된 것으로 작업 범위를 지정합니다. 이는 지연 시간과 비용에 좋지만, low 노력으로 실행되는 중간 정도로 복잡한 작업에서는 과소 사고의 위험이 있습니다.

복잡한 문제에서 얕은 추론을 관찰하면, 프롬프트로 해결하는 대신 노력을 high 또는 xhigh로 올리세요. 지연 시간을 위해 노력을 low로 유지해야 한다면, 목표 지침을 추가하세요:

이 작업은 다단계 추론을 포함합니다. 응답하기 전에 문제를 신중하게 생각해보세요.

우리는 노력이 이전의 어떤 Opus보다 이 모델에 더 중요할 것으로 예상하며, 업그레이드할 때 적극적으로 실험할 것을 권장합니다.

적응형 사고의 트리거 동작은 조종 가능합니다. 모델이 생각하는 것보다 더 자주 생각하는 것을 발견한다면 — 이는 크거나 복잡한 시스템 프롬프트로 발생할 수 있습니다 — 이를 조종하기 위한 지침을 추가하세요. 항상 성능에 대한 프롬프팅 변경의 효과를 측정하세요. 예제:

사고는 지연 시간을 추가하며 답변 품질을 의미 있게 개선할 때만 사용해야 합니다 — 일반적으로 다단계 추론이 필요한 문제의 경우입니다. 의심할 때는 직접 응답하세요.

반대로, medium에서 어려운 워크로드를 실행하고 과소 사고를 보고 있다면, 첫 번째 레버는 노력을 올리는 것입니다. 더 세밀한 제어가 필요하면, 직접 프롬프트하세요.

도구 사용 트리거

Claude Opus 4.7은 Claude Opus 4.6보다 도구를 덜 자주 사용하고 추론을 더 많이 사용하는 경향이 있습니다. 이는 대부분의 경우 더 나은 결과를 생성합니다. 그러나 노력 설정을 증가시키는 것은 도구 사용 수준을 증가시키는 유용한 레버이며, 특히 지식 작업에서 그렇습니다. high 또는 xhigh 노력 설정은 에이전트 검색 및 코딩에서 상당히 더 많은 도구 사용을 보여줍니다. 더 많은 도구 사용을 원하는 시나리오의 경우, 모델이 도구를 언제 어떻게 적절하게 사용해야 하는지에 대해 명시적으로 지시하도록 프롬프트를 조정할 수도 있습니다. 예를 들어, 모델이 웹 검색 도구를 사용하지 않는 것을 발견하면, 이유와 방법을 명확하게 설명하세요.

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

Claude Opus 4.7은 긴 에이전트 추적 전체에서 더 정기적이고 더 높은 품질의 사용자 업데이트를 제공합니다. 임시 상태 메시지를 강제하기 위해 스캐폴딩을 추가했다면("모든 3개의 도구 호출 후 진행 상황을 요약하세요"), 이를 제거해 보세요. Claude Opus 4.7의 사용자 대면 업데이트의 길이나 내용이 당신의 사용 사례에 잘 조정되지 않았다면, 이러한 업데이트가 프롬프트에서 어떻게 보여야 하는지 명시적으로 설명하고 예제를 제공하세요.

더 문자 그대로의 지침 따르기

Claude Opus 4.7은 Claude Opus 4.6보다 프롬프트를 더 문자 그대로 그리고 명시적으로 해석하며, 특히 낮은 노력 수준에서 그렇습니다. 한 항목에서 다른 항목으로 지침을 조용히 일반화하지 않을 것이며, 당신이 하지 않은 요청을 추론하지 않을 것입니다. 이 문자 그대로의 해석의 장점은 정확성과 덜한 혼란이며, 일반적으로 신중하게 조정된 프롬프트, 구조화된 추출, 예측 가능한 동작을 원하는 파이프라인이 있는 API 사용 사례에 더 잘 작동합니다. Claude가 광범위하게 지침을 적용해야 한다면, 범위를 명시적으로 명시하세요(예: "모든 섹션에 이 형식을 적용하세요, 첫 번째 섹션만이 아니라").

톤과 쓰기 스타일

새로운 모델과 마찬가지로, 장문 쓰기의 산문 스타일이 변할 수 있습니다. Claude Opus 4.7은 더 직접적이고 의견이 있으며, 검증 중심의 표현이 적고 Claude Opus 4.6의 더 따뜻한 스타일보다 이모지가 적습니다. 당신의 제품이 특정 음성에 의존한다면, 새로운 기준선에 대해 스타일 프롬프트를 재평가하세요.

예를 들어, 당신의 제품 음성이 더 따뜻하거나 더 대화적이라면, 다음을 추가하세요:

따뜻하고 협력적인 톤을 사용하세요. 답변하기 전에 사용자의 프레이밍을 인정하세요.

서브에이전트 생성 제어

Claude Opus 4.7은 기본적으로 더 적은 서브에이전트를 생성하는 경향이 있습니다. 그러나 이 동작은 프롬프팅을 통해 조종 가능합니다; Claude Opus 4.7에 서브에이전트가 바람직한 시기에 대한 명시적 지침을 제공하세요. 코딩 사용 사례에 대한 장난감 예제:

단일 응답에서 직접 완료할 수 있는 작업에 대해 서브에이전트를 생성하지 마세요(예: 이미 볼 수 있는 함수 리팩토링).

항목 전체에 걸쳐 팬아웃하거나 여러 파일을 읽을 때 같은 턴에서 여러 서브에이전트를 생성하세요.

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

Claude Opus 4.7은 Claude Opus 4.6보다 더 강한 디자인 본능을 가지고 있으며, 일관된 기본 하우스 스타일을 가지고 있습니다: 따뜻한 크림/오프화이트 배경(약 #F4F1EA), 세리프 디스플레이 타입(Georgia, Fraunces, Playfair), 이탤릭 단어 악센트, 테라코타/앰버 악센트. 이는 편집, 환대, 포트폴리오 브리프에 잘 읽히지만, 대시보드, 개발 도구, 핀테크, 의료, 엔터프라이즈 앱에는 어색할 것입니다 — 그리고 웹 UI뿐만 아니라 슬라이드 덱에도 나타납니다.

이 기본값은 지속적입니다. 일반적인 지침("크림을 사용하지 마세요", "깨끗하고 최소한으로 만드세요")은 다양성을 생성하는 대신 모델을 다른 고정 팔레트로 이동시키는 경향이 있습니다. 두 가지 접근 방식이 안정적으로 작동합니다:

1. 구체적인 대안을 지정하세요. 모델은 명시적 사양을 정확하게 따릅니다:

AEFRM이라는 보충제 브랜드를 위한 데스크톱 랜딩 페이지를 디자인하세요.

시각적 방향은 안개가 낀 금속 표면과 유사하게 점차 파란색-회색과 거의 검은색으로 깊어지는 옅은 은회색 톤을 사용하는 차가운 단색 분위기에서 나와야 합니다.

페이지는 날카롭고 제어된 느낌을 가져야 하며, 강한 구조감과 절제감을 가져야 합니다.

밝은 악센트 색상을 도입하는 대신 전체 페이지에 걸쳐 이 톤 시스템을 사용하세요.

업로드된 이미지를 흑백으로 영웅 디자인에 사용하세요.

레이아웃은 명확한 수평 섹션과 중앙 최대 너비 컨테이너로 구축되어야 합니다. 카드, 버튼, 입력, 미디어 프레임 전체에 걸쳐 4px 모서리 반경을 일관되게 사용하세요. 여백은 관대해야 하며, 각 섹션 주위에 충분한 빈 공간이 있어서 페이지가 숨을 쉴 수 있어야 합니다.

타이포그래피는 일반적인 것보다 더 넓은 문자 간격을 가진 정사각형, 각진 산세리프를 사용해야 하며, 특히 제목과 네비게이션에서 텍스트가 더 엔지니어링되고 덜 압축된 느낌을 갖도록 해야 합니다. 제목 텍스트는 크고 대문자일 수 있으며, 지원 복사본은 짧고 희박하게 유지됩니다. 부제는 Alumni Sans SC로 4-6px로 작성되어야 하며, 모서리 아래 중앙처럼 작은 텍스트처럼 보입니다.

구조의 경우, 강한 제품 진술, 짧은 지원 단락 하나, 깨끗한 제품 자리 표시자 또는 패킷 프레임을 포함하는 영웅 섹션으로 시작하세요. 그 아래에 3개 또는 4개의 블록이 있는 이점 그리드를 추가한 다음, 제형 또는 성분 섹션, 마지막으로 cta를 추가하세요.

버튼은 평평하고 정확해야 하며, transition: all 160ms ease out을 사용하는 미묘한 호버 변경을 가져야 하며, 여기서 밝기와 테두리 대비가 약간 변하는 대신 극적인 동작을 사용합니다.

색상 팔레트는 이 범위 내에 있어야 합니다:
#E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.

2. 모델이 구축하기 전에 옵션을 제안하도록 하세요. 이는 기본값을 깨고 사용자에게 제어를 제공합니다. 이전에 디자인 다양성을 위해 temperature에 의존했다면, 이 접근 방식을 사용하세요 — 실행 전체에서 의미 있게 다른 방향을 생성합니다. 예제 프롬프트:

구축하기 전에, 이 브리프에 맞춘 4개의 서로 다른 시각적 방향을 제안하세요(각각: bg hex / accent hex / typeface — 한 줄 근거). 사용자에게 하나를 선택하도록 요청한 다음, 그 방향만 구현하세요.

추가로, Claude Opus 4.7은 사용자가 "AI slop" 미학이라고 부르는 일반적인 패턴을 피하기 위해 이전 모델보다 더 적은 프론트엔드 디자인 프롬프팅이 필요합니다. 이전 모델의 경우, 우리는 우리의 프론트엔드 디자인 스킬에서 더 긴 프롬프트 스니펫을 권장했습니다. 그러나 Claude Opus 4.7은 더 최소한의 프롬프팅 지침으로 독특하고 창의적인 프론트엔드를 생성합니다. 이 프롬프트 스니펫은 다양성에 대한 위의 프롬프팅 조언과 함께 잘 작동합니다:

<frontend_aesthetics>
과도하게 사용된 글꼴 패밀리(Inter, Roboto, Arial, 시스템 글꼴), 진부한 색상 구성(특히 흰색 또는 어두운 배경의 보라색 그래디언트), 예측 가능한 레이아웃 및 컴포넌트 패턴, 맥락 특정 특성이 부족한 쿠키 커터 디자인과 같은 일반적인 AI 생성 미학을 절대 사용하지 마세요. 고유한 글꼴, 응집력 있는 색상과 테마, 효과 및 마이크로 상호 작용을 위한 애니메이션을 사용하세요.
</frontend_aesthetics>

대화형 코딩 제품

Claude Opus 4.7의 토큰 사용량과 동작은 단일 사용자 턴이 있는 자율적이고 비동기적인 코딩 에이전트와 여러 사용자 턴이 있는 대화형, 동기적인 코딩 에이전트 간에 다를 수 있습니다. 구체적으로, 주로 사용자 턴 후 더 많은 추론을 하기 때문에 대화형 설정에서 더 많은 토큰을 사용하는 경향이 있습니다. 이는 긴 대화형 코딩 세션에서 장기 일관성, 지침 따르기, 코딩 기능을 개선할 수 있지만, 더 많은 토큰 사용도 함께 제공됩니다. 코딩 제품에서 성능과 토큰 효율성을 모두 최대화하려면, xhigh 또는 high 노력을 사용하고, 자동 모드와 같은 자율적 기능을 추가하고, 사용자로부터 필요한 인간 상호 작용의 수를 줄일 것을 권장합니다.

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

코드 검토 하네스

Claude Opus 4.7은 이전 모델보다 버그를 찾는 데 의미 있게 더 낫고, 우리의 평가에서 더 높은 재현율과 정밀도를 모두 가지고 있습니다 — 실제 Anthropic PR을 기반으로 한 우리의 가장 어려운 버그 찾기 평가 중 하나에서 11pp 더 나은 재현율. 그러나 당신의 코드 검토 하네스가 이전 모델에 대해 조정되었다면, 처음에는 더 낮은 재현율을 볼 수 있습니다. 이는 기능 회귀가 아니라 하네스 효과일 가능성이 높습니다. 검토 프롬프트가 "높은 심각도 문제만 보고하세요", "보수적이세요", "세세한 것을 지적하지 마세요"와 같은 것을 말할 때, Claude Opus 4.7은 이전 모델보다 그 지침을 더 충실하게 따를 수 있습니다 — 코드를 철저히 조사하고, 버그를 식별하고, 당신이 명시한 기준 아래에 있다고 판단하는 발견을 보고하지 않을 수 있습니다. 이는 모델이 같은 깊이의 조사를 하지만 조사를 더 적은 보고된 발견으로 변환하는 것으로 나타날 수 있으며, 특히 낮은 심각도 버그에서 그렇습니다. 정밀도는 일반적으로 상승하지만, 측정된 재현율은 모델의 기본 버그 찾기 능력이 개선되었음에도 불구하고 떨어질 수 있습니다.

권장되는 프롬프트 언어:

당신이 발견한 모든 문제를 보고하세요, 당신이 불확실하거나 낮은 심각도로 간주하는 것들을 포함하여. 이 단계에서 중요도나 신뢰도에 대해 필터링하지 마세요 - 별도의 검증 단계가 그렇게 할 것입니다. 당신의 목표는 여기서 범위입니다: 나중에 필터링되는 발견을 표면화하는 것이 조용히 실제 버그를 떨어뜨리는 것보다 낫습니다. 각 발견에 대해 당신의 신뢰 수준과 다운스트림 필터가 순위를 매길 수 있도록 추정된 심각도를 포함하세요.

이 프롬프트는 실제 두 번째 단계가 없어도 사용할 수 있지만, 신뢰도 필터링을 발견 단계 밖으로 이동하면 종종 도움이 됩니다. 당신의 하네스가 별도의 검증, 중복 제거, 또는 순위 단계를 가지고 있다면, 모델에게 명시적으로 발견 단계에서의 작업이 필터링이 아니라 범위라고 말하세요.

단일 패스에서 모델이 자체 필터링을 하기를 원한다면, "중요"와 같은 정성적 용어를 사용하는 대신 기준이 어디에 있는지에 대해 구체적으로 말하세요 — 예를 들어, "잘못된 동작, 테스트 실패, 또는 오도된 결과를 야기할 수 있는 버그를 보고하세요; 순수 스타일 또는 이름 지정 선호도와 같은 세세한 것만 생략하세요."

우리는 재현율 또는 F1 점수 향상을 검증하기 위해 당신의 평가 또는 테스트 사례의 부분 집합에 대해 프롬프트를 반복할 것을 권장합니다.

컴퓨터 사용

컴퓨터 사용 기능은 해상도 전체에서 작동하며, 2576px / 3.75MP의 새로운 최대 해상도까지입니다. 우리의 컴퓨터 사용 테스트에서, 우리는 1080p에서 이미지를 전송하는 것이 성능과 비용의 좋은 균형을 제공한다는 것을 발견합니다.

특히 비용 민감 워크로드의 경우, 우리는 720p 또는 1366×768을 강한 성능을 가진 더 낮은 비용 옵션으로 권장합니다. 우리는 당신이 당신의 사용 사례에 대한 이상적인 설정을 찾기 위해 당신 자신의 테스트를 수행할 것을 권장합니다; 노력 설정을 실험하는 것도 모델의 동작을 조정하는 데 도움이 될 수 있습니다.

일반 원칙

명확하고 직접적이세요

Claude는 명확하고 명시적인 지침에 잘 반응합니다. 원하는 출력에 대해 구체적이면 결과를 향상시킬 수 있습니다. "그 이상"의 동작을 원한다면, 모호한 프롬프트에서 이를 추론하는 모델에 의존하는 대신 명시적으로 요청하세요.

Claude를 당신의 규범과 워크플로우에 대한 맥락이 부족한 뛰어나지만 새로운 직원으로 생각하세요. 당신이 원하는 것을 더 정확하게 설명할수록 결과가 더 좋습니다.

황금 규칙: 당신의 프롬프트를 작업에 대한 최소한의 맥락을 가진 동료에게 보여주고 그것을 따르도록 요청하세요. 그들이 혼란스러워할 것이라면, Claude도 그럴 것입니다.

• 원하는 출력 형식과 제약에 대해 구체적이세요.
• 단계의 순서나 완성이 중요할 때 번호 매기기 목록이나 글머리 기호를 사용하여 지침을 순차적 단계로 제공하세요.

성능을 개선하기 위해 맥락을 추가하세요

지침 뒤의 맥락이나 동기를 제공하면, 예를 들어 Claude에게 그러한 동작이 왜 중요한지 설명하면, Claude가 당신의 목표를 더 잘 이해하고 더 목표 지향적인 응답을 제공하는 데 도움이 될 수 있습니다.

Claude는 설명에서 일반화할 수 있을 정도로 똑똑합니다.

예제를 효과적으로 사용하세요

예제는 Claude의 출력 형식, 톤, 구조를 조종하는 가장 신뢰할 수 있는 방법 중 하나입니다. 몇 가지 잘 만들어진 예제(소수 샷 또는 멀티샷 프롬프팅으로 알려짐)는 정확성과 일관성을 극적으로 개선할 수 있습니다.

예제를 추가할 때, 다음과 같이 만드세요:

• 관련성: 당신의 실제 사용 사례를 밀접하게 반영하세요.
• 다양성: 엣지 케이스를 다루고 Claude가 의도하지 않은 패턴을 선택하지 않도록 충분히 다양하세요.
• 구조화됨: 예제를 <example> 태그(여러 예제는 <examples> 태그)로 감싸서 Claude가 지침과 구별할 수 있도록 하세요.

XML 태그로 프롬프트 구조화하세요

XML 태그는 Claude가 복잡한 프롬프트를 명확하게 파싱하는 데 도움이 되며, 특히 당신의 프롬프트가 지침, 맥락, 예제, 변수 입력을 혼합할 때 그렇습니다. 각 유형의 콘텐츠를 자신의 태그(예: <instructions>, <context>, <input>)로 감싸면 오해석을 줄입니다.

모범 사례:

• 프롬프트 전체에서 일관되고 설명적인 태그 이름을 사용하세요.
• 콘텐츠가 자연스러운 계층 구조를 가질 때 태그를 중첩하세요(<documents> 내의 문서, 각각 <document index="n"> 내).

Claude에게 역할을 부여하세요

시스템 프롬프트에서 역할을 설정하면 Claude의 동작과 톤을 당신의 사용 사례에 맞게 집중시킵니다. 단 한 문장도 차이를 만듭니다:

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    system="You are a helpful coding assistant specializing in Python.",
    messages=[
        {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ],
)
print(message.content)

긴 맥락 프롬프팅

큰 문서나 데이터 풍부한 입력(20k+ 토큰)으로 작업할 때, 최상의 결과를 얻기 위해 프롬프트를 신중하게 구조화하세요:

• 긴 형식 데이터를 맨 위에 놓으세요: 당신의 긴 문서와 입력을 프롬프트의 맨 위에, 당신의 쿼리, 지침, 예제 위에 놓으세요. 이는 모든 모델에서 성능을 크게 향상시킬 수 있습니다.

  끝의 쿼리는 테스트에서 응답 품질을 최대 30%까지 개선할 수 있으며, 특히 복잡한 다중 문서 입력의 경우입니다.

• XML 태그로 문서 콘텐츠와 메타데이터를 구조화하세요: 여러 문서를 사용할 때, 각 문서를 <document> 태그로 감싸고 명확성을 위해 <document_content>와 <source>(및 기타 메타데이터) 서브태그를 사용하세요.

  예제 다중 문서 구조

• 응답을 인용으로 근거하세요: 긴 문서 작업의 경우, Claude에게 작업을 수행하기 전에 먼저 문서의 관련 부분을 인용하도록 요청하세요. 이는 Claude가 문서의 나머지 콘텐츠의 소음을 뚫고 나가는 데 도움이 됩니다.

  예제 인용 추출

모델 자기 인식

Claude가 당신의 애플리케이션에서 자신을 올바르게 식별하거나 특정 API 문자열을 사용하기를 원한다면:

The assistant is Claude, created by Anthropic. The current model is Claude Opus 4.7.

모델 문자열을 지정해야 하는 LLM 기반 앱의 경우:

When an LLM is needed, please default to Claude Opus 4.7 unless the user requests otherwise. The exact model string for Claude Opus 4.7 is claude-opus-4-7.

출력 및 형식

통신 스타일과 상세도

Claude의 최신 모델은 이전 모델과 비교하여 더 간결하고 자연스러운 통신 스타일을 가지고 있습니다:

• 더 직접적이고 근거 있음: 자축하는 업데이트보다는 사실 기반 진행 상황 보고서를 제공합니다
• 더 대화적: 약간 더 유창하고 구어적이며, 덜 기계적입니다
• 덜 상세함: 명시적으로 요청하지 않는 한 도구 호출 후 상세한 요약을 건너뛸 수 있습니다

이는 Claude가 도구 호출 후 구두 요약을 건너뛸 수 있으며, 다음 작업으로 직접 이동할 수 있음을 의미합니다. 그 추론에 더 많은 가시성을 선호한다면:

도구 사용을 포함하는 작업을 완료한 후, 당신이 수행한 작업의 빠른 요약을 제공하세요.

응답 형식 제어

출력 형식을 조종하는 몇 가지 특히 효과적인 방법이 있습니다:

1. Claude에게 하지 말아야 할 것이 아니라 할 것을 말하세요

   • 대신: "당신의 응답에서 마크다운을 사용하지 마세요"
   • 시도: "당신의 응답은 부드럽게 흐르는 산문 단락으로 구성되어야 합니다."

2. XML 형식 표시기를 사용하세요

   • 시도: "당신의 응답의 산문 섹션을 <smoothly_flowing_prose_paragraphs> 태그로 작성하세요."

3. 당신의 프롬프트 스타일을 원하는 출력 스타일과 일치시키세요

   당신의 프롬프트에서 사용된 형식 스타일은 Claude의 응답 스타일에 영향을 미칠 수 있습니다. 출력 형식 조종성 문제가 계속 발생한다면, 당신의 프롬프트 스타일을 당신의 원하는 출력 스타일과 최대한 가깝게 일치시켜 보세요. 예를 들어, 당신의 프롬프트에서 마크다운을 제거하면 출력의 마크다운 양을 줄일 수 있습니다.

4. 특정 형식 지정 선호도에 대해 상세한 프롬프트를 사용하세요

   마크다운 및 형식 지정 사용에 대한 더 많은 제어를 위해 명시적 지침을 제공하세요:

<avoid_excessive_markdown_and_bullet_points>
보고서, 문서, 기술 설명, 분석 또는 기타 장문 콘텐츠를 작성할 때, 완전한 단락과 문장을 사용하여 명확하고 흐르는 산문으로 작성하세요. 조직을 위해 표준 단락 나누기를 사용하고 마크다운을 주로 `inline code`, 코드 블록(```...```), 간단한 제목(###, ###)으로 예약하세요. **굵게**와 *이탤릭*을 사용하지 마세요.

순서 있는 목록(1. ...)이나 순서 없는 목록(*)을 사용하지 마세요 unless : a) 당신이 목록 형식이 최선의 옵션인 진정으로 개별적인 항목을 제시하고 있거나, b) 사용자가 명시적으로 목록이나 순위를 요청했습니다

항목을 글머리 기호나 숫자로 나열하는 대신, 자연스럽게 문장에 통합하세요. 이 지침은 특히 기술 작성에 적용됩니다. 과도한 형식 지정 대신 산문을 사용하면 사용자 만족도가 향상됩니다. 절대 과도하게 짧은 글머리 기호 시리즈를 출력하지 마세요.

당신의 목표는 정보를 고립된 포인트로 단편화하는 대신 독자를 자연스럽게 아이디어를 통해 안내하는 읽을 수 있고 흐르는 텍스트입니다.
</avoid_excessive_markdown_and_bullet_points>

LaTeX 출력

Claude Opus 4.6은 수학 표현, 방정식, 기술 설명에 대해 LaTeX로 기본값을 설정합니다. 일반 텍스트를 선호한다면, 당신의 프롬프트에 다음 지침을 추가하세요:

당신의 응답을 일반 텍스트로만 형식화하세요. LaTeX, MathJax, 또는 \( \), $, \frac{}{}와 같은 마크업 표기법을 사용하지 마세요. 표준 텍스트 문자(예: 나눗셈의 경우 "/", 곱셈의 경우 "*", 지수의 경우 "^")를 사용하여 모든 수학 표현을 작성하세요.

문서 생성

Claude의 최신 모델은 인상적인 창의적 재능과 강한 지침 따르기로 프레젠테이션, 애니메이션, 시각적 문서를 만드는 데 탁월합니다. 모델은 대부분의 경우 첫 번째 시도에서 광택 있고 사용 가능한 출력을 생성합니다.

문서 생성으로 최상의 결과를 얻으려면:

Create a professional presentation on [topic]. Include thoughtful design elements, visual hierarchy, and engaging animations where appropriate.

미리 채워진 응답에서 마이그레이션

Claude 4.6 모델과 Claude Mythos Preview부터 시작하여, 마지막 어시스턴트 턴에서 미리 채워진 응답은 더 이상 지원되지 않습니다. Mythos Preview에서, 미리 채워진 어시스턴트 메시지가 있는 요청은 400 오류를 반환합니다. 모델 지능과 지침 따르기가 발전하여 미리 채우기가 더 이상 필요하지 않은 대부분의 사용 사례가 있습니다. 기존 모델은 계속 미리 채우기를 지원할 것이며, 대화의 다른 곳에 어시스턴트 메시지를 추가하는 것은 영향을 받지 않습니다.

다음은 일반적인 미리 채우기 시나리오와 이로부터 마이그레이션하는 방법입니다:

도구 사용

도구 사용

Claude의 최신 모델은 정확한 지침 따르기를 위해 훈련되었으며 특정 도구를 사용하기 위한 명시적 지시로부터 이점을 얻습니다. "몇 가지 변경을 제안할 수 있습니까?"라고 말하면, Claude는 때때로 변경을 구현하는 것이 당신이 의도한 것일 수 있음에도 불구하고 제안만 제공할 것입니다.

Claude가 조치를 취하려면, 더 명시적이세요:

Claude가 기본적으로 조치를 취하는 것에 더 적극적이 되도록 하려면, 당신의 시스템 프롬프트에 다음을 추가할 수 있습니다:

<default_to_action>
기본적으로 제안만 하는 대신 변경을 구현하세요. 사용자의 의도가 불명확하면, 가장 유용한 가능성 있는 조치를 추론하고 진행하며, 추측하는 대신 도구를 사용하여 누락된 세부 사항을 발견하세요. 도구 호출(예: 파일 편집 또는 읽기)이 의도되었는지 여부에 대한 사용자의 의도를 추론하고 그에 따라 행동하세요.
</default_to_action>

반면에, 모델이 기본적으로 더 주저하고, 구현으로 바로 뛰어드는 경향이 적고, 요청된 경우에만 조치를 취하기를 원한다면, 다음과 같은 프롬프트로 이 동작을 조종할 수 있습니다:

<do_not_act_before_instructions>
변경을 명확하게 지시하지 않는 한 구현이나 파일 변경으로 뛰어들지 마세요. 사용자의 의도가 모호할 때, 정보 제공, 연구, 권장 사항 제공보다는 조치를 취하는 것을 기본값으로 하세요. 사용자가 명시적으로 편집, 수정, 또는 구현을 요청할 때만 진행하세요.
</do_not_act_before_instructions>

Claude Opus 4.5와 Claude Opus 4.6은 또한 이전 모델보다 시스템 프롬프트에 더 반응합니다. 당신의 프롬프트가 도구 또는 스킬에 대한 과소 트리거를 줄이도록 설계되었다면, 이 모델은 이제 과도하게 트리거할 수 있습니다. 해결책은 공격적인 언어를 다시 조정하는 것입니다. "CRITICAL: You MUST use this tool when..."이라고 말했을 수도 있지만, "Use this tool when..."과 같은 더 정상적인 프롬프팅을 사용할 수 있습니다.

병렬 도구 호출 최적화

Claude의 최신 모델은 병렬 도구 실행에 탁월합니다. 이러한 모델은 다음을 수행합니다:

• 연구 중 여러 추측 검색 실행
• 여러 파일을 동시에 읽어 컨텍스트를 더 빠르게 구축
• bash 명령을 병렬로 실행 (시스템 성능을 병목으로 만들 수도 있음)

이 동작은 쉽게 조정할 수 있습니다. 모델은 프롬프트 없이도 병렬 도구 호출에서 높은 성공률을 가지지만, 이를 ~100%로 높이거나 공격성 수준을 조정할 수 있습니다:

<use_parallel_tool_calls>
여러 도구를 호출하려고 하고 도구 호출 간에 종속성이 없는 경우, 모든 독립적인 도구 호출을 병렬로 수행하세요. 작업을 순차적으로 수행하기보다는 병렬로 수행할 수 있을 때마다 도구를 동시에 호출하는 것을 우선시하세요. 예를 들어, 3개의 파일을 읽을 때 3개의 도구 호출을 병렬로 실행하여 3개의 파일을 모두 동시에 컨텍스트로 읽으세요. 속도와 효율성을 높이기 위해 가능한 한 병렬 도구 호출의 사용을 최대화하세요. 그러나 일부 도구 호출이 매개변수와 같은 종속 값을 알려주기 위해 이전 호출에 종속된 경우, 이러한 도구를 병렬로 호출하지 말고 대신 순차적으로 호출하세요. 도구 호출에서 자리 표시자를 사용하거나 누락된 매개변수를 추측하지 마세요.
</use_parallel_tool_calls>

안정성을 보장하기 위해 각 단계 사이에 짧은 일시 중지를 두고 작업을 순차적으로 실행하세요.

사고와 추론

과도한 사고와 과도한 철저함

Claude Opus 4.6은 특히 더 높은 effort 설정에서 이전 모델보다 훨씬 더 많은 사전 탐색을 수행합니다. 이 초기 작업은 종종 최종 결과를 최적화하는 데 도움이 되지만, 모델은 광범위한 컨텍스트를 수집하거나 프롬프트 없이 여러 연구 스레드를 추구할 수 있습니다. 이전 프롬프트가 모델을 더 철저하게 하도록 권장한 경우, Claude Opus 4.6에 대해 해당 지침을 조정해야 합니다:

• 일반적인 기본값을 더 구체적인 지침으로 바꾸세요. "[tool] 사용을 기본값으로 설정"하는 대신, "[tool]이 문제에 대한 이해를 향상시킬 때 사용"과 같은 지침을 추가하세요.
• 과도한 프롬프팅을 제거하세요. 이전 모델에서 과소 트리거된 도구는 이제 적절하게 트리거될 가능성이 높습니다. "의심스러우면 [tool]을 사용하세요"와 같은 지침은 과도한 트리거를 유발합니다.
• effort를 폴백으로 사용하세요. Claude가 계속 과도하게 공격적이면, effort에 대해 더 낮은 설정을 사용하세요.

경우에 따라 Claude Opus 4.6은 광범위하게 생각할 수 있으며, 이는 사고 토큰을 증가시키고 응답을 느리게 할 수 있습니다. 이 동작이 바람직하지 않은 경우, 추론을 제한하는 명시적 지침을 추가하거나 effort 설정을 낮춰 전체 사고와 토큰 사용을 줄일 수 있습니다.

문제에 접근하는 방법을 결정할 때, 접근 방식을 선택하고 그것에 전념하세요. 새로운 정보가 당신의 추론과 직접 모순되지 않는 한 결정을 다시 검토하지 마세요. 두 가지 접근 방식을 저울질하고 있다면, 하나를 선택하고 끝까지 진행하세요. 선택한 접근 방식이 실패하면 나중에 항상 방향을 바꿀 수 있습니다.

사고 비용에 대한 하드 상한이 필요한 경우, budget_tokens 상한이 있는 확장 사고는 여전히 Opus 4.6 및 Sonnet 4.6에서 작동하지만 더 이상 사용되지 않습니다. effort 설정을 낮추거나 적응형 사고와 함께 max_tokens를 하드 제한으로 사용하는 것을 선호하세요.

사고 및 인터리빙된 사고 기능 활용

Claude의 최신 모델은 도구 사용 후 반영이나 복잡한 다단계 추론을 포함하는 작업에 특히 유용할 수 있는 사고 기능을 제공합니다. 더 나은 결과를 위해 초기 또는 인터리빙된 사고를 안내할 수 있습니다.

Claude Opus 4.6 및 Claude Sonnet 4.6은 적응형 사고 (thinking: {type: "adaptive"})를 사용하며, Claude는 언제 어느 정도 생각할지를 동적으로 결정합니다. Claude는 두 가지 요소를 기반으로 사고를 보정합니다: effort 매개변수와 쿼리 복잡성. 더 높은 effort는 더 많은 사고를 유도하고, 더 복잡한 쿼리도 마찬가지입니다. 사고가 필요하지 않은 더 쉬운 쿼리에서는 모델이 직접 응답합니다. 내부 평가에서 적응형 사고는 확장 사고보다 더 안정적으로 더 나은 성능을 제공합니다. 가장 지능적인 응답을 얻으려면 적응형 사고로 이동하는 것을 고려하세요.

다단계 도구 사용, 복잡한 코딩 작업, 장기 에이전트 루프와 같은 에이전트 동작이 필요한 워크로드에 적응형 사고를 사용하세요. 이전 모델은 budget_tokens를 사용한 수동 사고 모드를 사용합니다.

Claude의 사고 동작을 안내할 수 있습니다:

도구 결과를 받은 후, 그 품질을 신중하게 반영하고 진행하기 전에 최적의 다음 단계를 결정하세요. 사고를 사용하여 이 새로운 정보를 기반으로 계획하고 반복한 다음, 최선의 다음 조치를 취하세요.

적응형 사고의 트리거 동작은 프롬프트 가능합니다. 모델이 생각하는 빈도가 원하는 것보다 높다면, 이는 크거나 복잡한 시스템 프롬프트로 인해 발생할 수 있으며, 이를 조정하기 위해 지침을 추가하세요:

확장 사고는 지연을 추가하며 답변 품질을 의미 있게 개선할 때만 사용해야 합니다 - 일반적으로 다단계 추론이 필요한 문제의 경우입니다. 의심스러우면 직접 응답하세요.

budget_tokens를 사용하는 확장 사고에서 마이그레이션하는 경우, 사고 구성을 바꾸고 예산 제어를 effort로 이동하세요:

이전 (확장 사고, 이전 모델):

client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=64000,
    thinking={"type": "enabled", "budget_tokens": 32000},
    messages=[{"role": "user", "content": "..."}],
)

이후 (적응형 사고):

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # or "max", "xhigh", "medium", "low"
    messages=[{"role": "user", "content": "..."}],
)

확장 사고를 사용하지 않는 경우, 변경이 필요하지 않습니다. thinking 매개변수를 생략하면 사고는 기본적으로 꺼져 있습니다.

• 규정적 단계보다 일반적인 지침을 선호하세요. "철저하게 생각하세요"와 같은 프롬프트는 손으로 작성한 단계별 계획보다 더 나은 추론을 생성하는 경우가 많습니다. Claude의 추론은 인간이 규정하는 것을 자주 초과합니다.
• 다중 샷 예제는 사고와 함께 작동합니다. 몇 가지 샷 예제 내에서 <thinking> 태그를 사용하여 Claude에 추론 패턴을 보여주세요. 이는 자신의 확장 사고 블록에 해당 스타일을 일반화합니다.
• 수동 CoT를 폴백으로 사용하세요. 사고가 꺼져 있을 때, Claude에 문제를 생각하도록 요청하여 단계별 추론을 여전히 권장할 수 있습니다. <thinking> 및 <answer>와 같은 구조화된 태그를 사용하여 추론과 최종 출력을 깔끔하게 분리하세요.
• Claude에 자체 확인을 요청하세요. "마치기 전에 [테스트 기준]에 대해 답변을 확인하세요"와 같은 것을 추가하세요. 이는 특히 코딩 및 수학에서 오류를 안정적으로 포착합니다.

에이전트 시스템

장기 추론 및 상태 추적

Claude의 최신 모델은 예외적인 상태 추적 기능을 갖춘 장기 추론 작업에 탁월합니다. Claude는 증분 진행에 초점을 맞춰 한 번에 몇 가지를 꾸준히 진행하기보다는 모든 것을 한 번에 시도하지 않음으로써 확장된 세션 전체에서 방향 감각을 유지합니다. 이 기능은 특히 여러 컨텍스트 윈도우 또는 작업 반복에서 나타나며, Claude는 복잡한 작업을 수행하고 상태를 저장한 다음 새로운 컨텍스트 윈도우로 계속할 수 있습니다.

컨텍스트 인식 및 다중 윈도우 워크플로우

Claude 4.6 및 Claude 4.5 모델은 컨텍스트 인식을 특징으로 하며, 모델이 대화 전체에서 남은 컨텍스트 윈도우 (즉, "토큰 예산")를 추적할 수 있습니다. 이를 통해 Claude는 작업할 공간이 얼마나 있는지 이해함으로써 작업을 실행하고 컨텍스트를 더 효과적으로 관리할 수 있습니다.

컨텍스트 제한 관리:

컨텍스트를 압축하거나 컨텍스트를 외부 파일에 저장할 수 있는 에이전트 하네스에서 Claude를 사용하는 경우 (Claude Code에서와 같이), 이 정보를 프롬프트에 추가하여 Claude가 그에 따라 동작하도록 하세요. 그렇지 않으면, Claude는 컨텍스트 제한에 접근할 때 자연스럽게 작업을 마치려고 할 수 있습니다. 다음은 예제 프롬프트입니다:

컨텍스트 윈도우는 제한에 접근할 때 자동으로 압축되어 중단한 곳에서 무한정 계속 작업할 수 있습니다. 따라서 토큰 예산 우려로 인해 작업을 조기에 중단하지 마세요. 토큰 예산 제한에 접근할 때, 컨텍스트 윈도우가 새로 고쳐지기 전에 현재 진행 상황과 상태를 메모리에 저장하세요. 항상 가능한 한 지속적이고 자율적이어야 하며 남은 컨텍스트에 관계없이 작업을 완전히 완료하세요. 남은 컨텍스트에 관계없이 작업을 조기에 인위적으로 중단하지 마세요.

메모리 도구는 컨텍스트 인식과 자연스럽게 쌍을 이루어 원활한 컨텍스트 전환을 가능하게 합니다.

다중 컨텍스트 윈도우 워크플로우

여러 컨텍스트 윈도우에 걸친 작업의 경우:

1. 매우 첫 번째 컨텍스트 윈도우에 다른 프롬프트를 사용하세요: 첫 번째 컨텍스트 윈도우를 사용하여 프레임워크를 설정 (테스트 작성, 설정 스크립트 생성)한 다음, 향후 컨텍스트 윈도우를 사용하여 할 일 목록을 반복하세요.

2. 모델이 구조화된 형식으로 테스트를 작성하도록 하세요: Claude에 작업을 시작하기 전에 테스트를 생성하고 구조화된 형식 (예: tests.json)으로 추적하도록 요청하세요. 이는 장기적으로 반복할 수 있는 능력을 향상시킵니다. Claude에 테스트의 중요성을 상기시키세요: "테스트를 제거하거나 편집하는 것은 허용되지 않습니다. 이는 누락되거나 버그가 있는 기능으로 이어질 수 있기 때문입니다."

3. 삶의 질 도구를 설정하세요: Claude가 설정 스크립트 (예: init.sh)를 생성하여 서버를 우아하게 시작하고, 테스트 스위트 및 린터를 실행하도록 권장하세요. 이는 새로운 컨텍스트 윈도우에서 계속할 때 반복 작업을 방지합니다.

4. 새로 시작 vs 압축: 컨텍스트 윈도우가 지워질 때, 압축을 사용하기보다는 완전히 새로운 컨텍스트 윈도우로 시작하는 것을 고려하세요. Claude의 최신 모델은 로컬 파일 시스템에서 상태를 발견하는 데 매우 효과적입니다. 경우에 따라 압축보다 이를 활용하고 싶을 수 있습니다. 시작 방법에 대해 규정적이어야 합니다:

   • "pwd를 호출하세요; 이 디렉토리에서만 파일을 읽고 쓸 수 있습니다."
   • "progress.txt, tests.json, git 로그를 검토하세요."
   • "새로운 기능 구현으로 이동하기 전에 기본 통합 테스트를 수동으로 실행하세요."

5. 검증 도구를 제공하세요: 자율 작업의 길이가 증가함에 따라 Claude는 지속적인 인간 피드백 없이 정확성을 검증해야 합니다. Playwright MCP 서버 또는 UI 테스트를 위한 컴퓨터 사용 기능과 같은 도구가 도움이 됩니다.

6. 컨텍스트의 완전한 사용을 권장하세요: Claude에 계속 진행하기 전에 효율적으로 구성 요소를 완료하도록 프롬프트하세요:

이것은 매우 긴 작업이므로 작업을 명확하게 계획하는 것이 유리할 수 있습니다. 전체 출력 컨텍스트를 작업에 사용하는 것이 좋습니다 - 중요한 커밋되지 않은 작업으로 컨텍스트가 부족하지 않도록 하세요. 이 작업을 완료할 때까지 체계적으로 계속 작업하세요.

상태 관리 모범 사례

• 상태 데이터에 구조화된 형식을 사용하세요: 구조화된 정보 (테스트 결과 또는 작업 상태 등)를 추적할 때, JSON 또는 기타 구조화된 형식을 사용하여 Claude가 스키마 요구 사항을 이해하도록 도우세요
• 진행 상황 메모에 비구조화된 텍스트를 사용하세요: 자유 형식 진행 상황 메모는 일반적인 진행 상황 및 컨텍스트 추적에 적합합니다
• 상태 추적에 git을 사용하세요: Git은 수행된 작업의 로그와 복원할 수 있는 체크포인트를 제공합니다. Claude의 최신 모델은 여러 세션에 걸쳐 상태를 추적하기 위해 git을 사용하는 데 특히 잘 수행됩니다.
• 증분 진행을 강조하세요: Claude에 진행 상황을 추적하고 증분 작업에 집중하도록 명시적으로 요청하세요

자율성과 안전성의 균형

지침이 없으면, Claude Opus 4.6은 파일 삭제, 강제 푸시, 외부 서비스에 게시와 같이 되돌리기 어렵거나 공유 시스템에 영향을 미치는 조치를 취할 수 있습니다. Claude Opus 4.6이 잠재적으로 위험한 조치를 취하기 전에 확인하도록 하려면, 프롬프트에 지침을 추가하세요:

조치의 되돌릴 수 있음과 잠재적 영향을 고려하세요. 파일 편집 또는 테스트 실행과 같은 로컬, 되돌릴 수 있는 조치를 취하도록 권장되지만, 되돌리기 어렵거나 공유 시스템에 영향을 미치거나 파괴적일 수 있는 조치의 경우 진행하기 전에 사용자에게 문의하세요.

확인이 필요한 조치의 예:
- 파괴적 작업: 파일 또는 분기 삭제, 데이터베이스 테이블 삭제, rm -rf
- 되돌리기 어려운 작업: git push --force, git reset --hard, 게시된 커밋 수정
- 다른 사람에게 보이는 작업: 코드 푸시, PR/이슈에 댓글 달기, 메시지 전송, 공유 인프라 수정

장애물에 직면했을 때, 파괴적 조치를 지름길로 사용하지 마세요. 예를 들어, 안전 검사를 우회하지 마세요 (예: --no-verify) 또는 진행 중인 작업일 수 있는 낯선 파일을 버리지 마세요.

연구 및 정보 수집

Claude의 최신 모델은 예외적인 에이전트 검색 기능을 보여주며 여러 소스에서 정보를 효과적으로 찾고 종합할 수 있습니다. 최적의 연구 결과를 위해:

1. 명확한 성공 기준을 제공하세요: 연구 질문에 대한 성공적인 답변이 무엇을 구성하는지 정의하세요

2. 소스 검증을 권장하세요: Claude에 여러 소스에서 정보를 검증하도록 요청하세요

3. 복잡한 연구 작업의 경우, 구조화된 접근 방식을 사용하세요:

이 정보를 구조화된 방식으로 검색하세요. 데이터를 수집할 때, 여러 경쟁 가설을 개발하세요. 진행 상황 메모에서 신뢰도 수준을 추적하여 보정을 개선하세요. 정기적으로 접근 방식을 자체 비판하고 계획하세요. 가설 트리 또는 연구 메모 파일을 업데이트하여 정보를 유지하고 투명성을 제공하세요. 이 복잡한 연구 작업을 체계적으로 분해하세요.

이 구조화된 접근 방식을 통해 Claude는 코퍼스의 크기에 관계없이 거의 모든 정보를 찾고 종합하며 반복적으로 결과를 비판할 수 있습니다.

서브에이전트 오케스트레이션

Claude의 최신 모델은 크게 개선된 네이티브 서브에이전트 오케스트레이션 기능을 보여줍니다. 이러한 모델은 작업이 전문화된 서브에이전트에 위임하는 것이 이로울 때를 인식하고 명시적 지침 없이 적극적으로 그렇게 할 수 있습니다.

이 동작을 활용하려면:

1. 잘 정의된 서브에이전트 도구를 확보하세요: 서브에이전트 도구를 사용 가능하게 하고 도구 정의에 설명하세요
2. Claude가 자연스럽게 오케스트레이션하도록 하세요: Claude는 명시적 지침 없이 적절하게 위임합니다
3. 과도한 사용을 주시하세요: Claude Opus 4.6은 서브에이전트에 대한 강한 선호도를 가지고 있으며 더 간단하고 직접적인 접근 방식이 더 빠르고 충분한 경우에도 서브에이전트를 생성할 수 있습니다. 예를 들어, 모델은 직접 grep 호출이 더 빠르고 충분할 때 코드 탐색을 위해 서브에이전트를 생성할 수 있습니다.

과도한 서브에이전트 사용이 보이면, 서브에이전트가 정당한 경우와 그렇지 않은 경우에 대한 명시적 지침을 추가하세요:

작업을 병렬로 실행할 수 있거나, 격리된 컨텍스트가 필요하거나, 상태를 공유할 필요가 없는 독립적인 워크스트림을 포함할 때 서브에이전트를 사용하세요. 간단한 작업, 순차 작업, 단일 파일 편집, 또는 단계 전체에서 컨텍스트를 유지해야 하는 작업의 경우, 위임하기보다는 직접 작업하세요.

복잡한 프롬프트 연결

적응형 사고 및 서브에이전트 오케스트레이션을 통해 Claude는 대부분의 다단계 추론을 내부적으로 처리합니다. 명시적 프롬프트 연결 (작업을 순차 API 호출로 분해)은 중간 출력을 검사하거나 특정 파이프라인 구조를 적용해야 할 때 여전히 유용합니다.

가장 일반적인 연결 패턴은 자체 수정입니다: 초안 생성 → Claude가 기준에 대해 검토 → Claude가 검토를 기반으로 개선. 각 단계는 별도의 API 호출이므로 어느 지점에서든 로그, 평가 또는 분기할 수 있습니다.

에이전트 코딩에서 파일 생성 줄이기

Claude의 최신 모델은 특히 코드로 작업할 때 테스트 및 반복 목적으로 새 파일을 생성할 수 있습니다. 이 접근 방식을 통해 Claude는 파일, 특히 python 스크립트를 최종 출력을 저장하기 전에 '임시 스크래치패드'로 사용할 수 있습니다. 임시 파일을 사용하면 특히 에이전트 코딩 사용 사례에서 결과를 개선할 수 있습니다.

임시 파일 생성을 최소화하려면, Claude에 작업을 마친 후 정리하도록 지시할 수 있습니다:

반복을 위해 임시 새 파일, 스크립트 또는 도우미 파일을 생성하는 경우, 작업 끝에 이러한 파일을 제거하여 정리하세요.

과도한 열정

Claude Opus 4.5 및 Claude Opus 4.6은 추가 파일을 생성하거나, 불필요한 추상화를 추가하거나, 요청되지 않은 유연성을 구축하여 과도하게 엔지니어링하는 경향이 있습니다. 이 바람직하지 않은 동작이 보이면, 솔루션을 최소한으로 유지하기 위해 구체적인 지침을 추가하세요.

예를 들어:

과도한 엔지니어링을 피하세요. 직접 요청되거나 명확하게 필요한 변경만 하세요. 솔루션을 간단하고 집중된 상태로 유지하세요:

- 범위: 요청된 것 이상의 기능을 추가하거나, 코드를 리팩토링하거나, "개선"을 하지 마세요. 버그 수정은 주변 코드를 정리할 필요가 없습니다. 간단한 기능은 추가 구성 가능성이 필요하지 않습니다.

- 문서: 변경하지 않은 코드에 docstring, 주석 또는 타입 주석을 추가하지 마세요. 논리가 자명하지 않은 경우에만 주석을 추가하세요.

- 방어적 코딩: 발생할 수 없는 시나리오에 대해 오류 처리, 폴백 또는 검증을 추가하지 마세요. 내부 코드 및 프레임워크 보장을 신뢰하세요. 시스템 경계 (사용자 입력, 외부 API)에서만 검증하세요.

- 추상화: 일회성 작업에 대해 도우미, 유틸리티 또는 추상화를 생성하지 마세요. 가상의 향후 요구 사항에 대해 설계하지 마세요. 올바른 복잡성 수준은 현재 작업에 필요한 최소값입니다.

테스트 통과 및 하드코딩에 집중하지 않기

Claude는 때때로 더 일반적인 솔루션을 희생하면서 테스트를 통과하는 데 과도하게 집중할 수 있으며, 표준 도구를 직접 사용하는 대신 복잡한 리팩토링을 위해 도우미 스크립트와 같은 해결 방법을 사용할 수 있습니다. 이 동작을 방지하고 강력하고 일반화 가능한 솔루션을 보장하려면:

사용 가능한 표준 도구를 사용하여 고품질의 범용 솔루션을 작성하세요. 작업을 더 효율적으로 수행하기 위해 도우미 스크립트 또는 해결 방법을 생성하지 마세요. 테스트 케이스만 작동하는 솔루션이 아니라 모든 유효한 입력에 대해 올바르게 작동하는 솔루션을 구현하세요. 값을 하드코딩하거나 특정 테스트 입력에만 작동하는 솔루션을 생성하지 마세요. 대신 문제를 일반적으로 해결하는 실제 논리를 구현하세요.

문제 요구 사항을 이해하고 올바른 알고리즘을 구현하는 데 집중하세요. 테스트는 정확성을 확인하기 위한 것이지, 솔루션을 정의하기 위한 것이 아닙니다. 모범 사례 및 소프트웨어 설계 원칙을 따르는 원칙 있는 구현을 제공하세요.

작업이 불합리하거나 실행 불가능하거나 테스트가 잘못된 경우, 작업을 진행하기보다는 나에게 알려주세요. 솔루션은 강력하고, 유지 관리 가능하며, 확장 가능해야 합니다.

에이전트 코딩에서 환각 최소화

Claude의 최신 모델은 환각이 덜하고 코드를 기반으로 더 정확하고 근거 있는 지능형 답변을 제공합니다. 이 동작을 더욱 권장하고 환각을 최소화하려면:

<investigate_before_answering>
열지 않은 코드에 대해 추측하지 마세요. 사용자가 특정 파일을 참조하는 경우, 답변하기 전에 파일을 읽어야 합니다. 코드베이스에 대한 질문에 답변하기 전에 관련 파일을 조사하고 읽으세요. 조사하지 않은 경우 코드에 대해 어떤 주장도 하지 마세요. 정확한 답변이 확실한 경우가 아니면 근거 있고 환각이 없는 답변을 제공하세요.
</investigate_before_answering>

기능별 팁

개선된 비전 기능

Claude Opus 4.5 및 Claude Opus 4.6은 이전 Claude 모델과 비교하여 개선된 비전 기능을 가지고 있습니다. 특히 컨텍스트에 여러 이미지가 있을 때 이미지 처리 및 데이터 추출 작업에서 더 나은 성능을 발휘합니다. 이러한 개선 사항은 모델이 스크린샷 및 UI 요소를 더 안정적으로 해석할 수 있는 컴퓨터 사용으로 이어집니다. 이러한 모델을 사용하여 비디오를 프레임으로 분해하여 분석할 수도 있습니다.

성능을 더욱 향상시키는 것으로 입증된 한 가지 기법은 Claude에 자르기 도구 또는 스킬을 제공하는 것입니다. 테스트에 따르면 Claude가 이미지의 관련 영역을 "확대"할 수 있을 때 이미지 평가에서 일관된 향상이 나타났습니다. Anthropic은 자르기 도구에 대한 쿡북을 만들었습니다.

프론트엔드 설계

Claude Opus 4.5 및 Claude Opus 4.6은 강력한 프론트엔드 설계를 갖춘 복잡하고 실제 웹 애플리케이션을 구축하는 데 탁월합니다. 그러나 지침이 없으면, 모델은 사용자가 "AI slop" 미학이라고 부르는 것을 만드는 일반적인 패턴으로 기본값을 설정할 수 있습니다. 놀라움과 기쁨을 주는 독특하고 창의적인 프론트엔드를 만들려면:

더 나은 프론트엔드 설계를 권장하기 위해 사용할 수 있는 시스템 프롬프트 스니펫은 다음과 같습니다:

<frontend_aesthetics>
당신은 일반적이고 "분포상" 출력으로 수렴하는 경향이 있습니다. 프론트엔드 설계에서 이는 사용자가 "AI slop" 미학이라고 부르는 것을 만듭니다. 이를 피하세요: 놀라움과 기쁨을 주는 창의적이고 독특한 프론트엔드를 만드세요.

다음에 집중하세요:
- 타이포그래피: 아름답고 독특하며 흥미로운 글꼴을 선택하세요. Arial 및 Inter와 같은 일반적인 글꼴을 피하세요; 대신 프론트엔드의 미학을 향상시키는 독특한 선택을 선택하세요.
- 색상 및 테마: 응집력 있는 미학에 전념하세요. 일관성을 위해 CSS 변수를 사용하세요. 지배적인 색상과 날카로운 악센트는 소심한 균등 분포 팔레트보다 성능이 좋습니다. IDE 테마 및 문화적 미학에서 영감을 얻으세요.
- 모션: 효과 및 마이크로 상호 작용을 위해 애니메이션을 사용하세요. HTML의 경우 CSS 전용 솔루션을 우선시하세요. 사용 가능한 경우 React의 Motion 라이브러리를 사용하세요. 높은 영향 순간에 집중하세요: 엇갈린 공개 (animation-delay)가 있는 하나의 잘 조율된 페이지 로드는 산재된 마이크로 상호 작용보다 더 많은 기쁨을 만듭니다.
- 배경: 단색으로 기본값을 설정하기보다는 분위기와 깊이를 만드세요. CSS 그래디언트를 레이어링하고, 기하학적 패턴을 사용하거나, 전체 미학과 일치하는 상황별 효과를 추가하세요.

일반적인 AI 생성 미학을 피하세요:
- 과도하게 사용된 글꼴 패밀리 (Inter, Roboto, Arial, 시스템 글꼴)
- 진부한 색 구성표 (특히 흰색 배경의 보라색 그래디언트)
- 예측 가능한 레이아웃 및 구성 요소 패턴
- 상황별 특성이 부족한 쿠키 커터 설계

창의적으로 해석하고 상황에 맞게 진정으로 설계된 것처럼 느껴지는 예상치 못한 선택을 하세요. 밝은 테마와 어두운 테마, 다양한 글꼴, 다양한 미학 사이를 변경하세요. 당신은 여전히 세대 전체에서 일반적인 선택 (예: Space Grotesk)으로 수렴하는 경향이 있습니다. 이를 피하세요: 상자 밖에서 생각하는 것이 중요합니다!
</frontend_aesthetics>

전체 스킬 정의를 참조할 수도 있습니다.

마이그레이션 고려 사항

이전 세대에서 Claude 4.6 모델로 마이그레이션할 때:

1. 원하는 동작에 대해 구체적이어야 합니다: 출력에서 보고 싶은 것을 정확히 설명하는 것을 고려하세요.

2. 수정자를 사용하여 지침을 프레임하세요: Claude의 성능을 더 잘 형성하는 데 도움이 될 수 있는 출력의 품질과 세부 사항을 높이도록 권장하는 수정자를 추가합니다. 예를 들어, "분석 대시보드 만들기" 대신 "분석 대시보드를 만드세요. 가능한 한 많은 관련 기능 및 상호 작용을 포함하세요. 기본을 넘어 완전히 기능하는 구현을 만드세요."를 사용하세요.

3. 특정 기능을 명시적으로 요청하세요: 원하는 경우 애니메이션 및 대화형 요소를 명시적으로 요청해야 합니다.

4. 사고 구성을 업데이트하세요: Claude 4.6 모델은 수동 사고 대신 적응형 사고 (thinking: {type: "adaptive"})를 사용합니다. effort 매개변수를 사용하여 사고 깊이를 제어하세요.

5. 미리 채워진 응답에서 마이그레이션하세요: Claude 4.6 모델부터 마지막 어시스턴트 턴에서 미리 채워진 응답은 더 이상 사용되지 않습니다. 미리 채워진 응답에서 마이그레이션을 참조하여 대안에 대한 자세한 지침을 확인하세요.

6. 반-게으름 프롬프팅을 조정하세요: 이전 프롬프트가 모델을 더 철저하게 하거나 도구를 더 공격적으로 사용하도록 권장한 경우, 해당 지침을 다시 조정하세요. Claude 4.6 모델은 훨씬 더 적극적이며 이전 모델에 필요했던 지침에 대해 과도하게 트리거될 수 있습니다.

자세한 마이그레이션 단계는 마이그레이션 가이드를 참조하세요.

Claude Sonnet 4.5에서 Claude Sonnet 4.6으로 마이그레이션

Claude Sonnet 4.6은 기본적으로 high의 effort 수준으로 설정되며, Claude Sonnet 4.5는 effort 매개변수가 없었습니다. Claude Sonnet 4.5에서 Claude Sonnet 4.6으로 마이그레이션할 때 effort 매개변수를 조정하는 것을 고려하세요. 명시적으로 설정하지 않으면, 기본 effort 수준으로 인해 더 높은 지연 시간이 발생할 수 있습니다.

권장 effort 설정:

• 중간 대부분의 애플리케이션
• 낮음 높은 볼륨 또는 지연 시간에 민감한 워크로드
• 모델이 생각하고 행동할 수 있는 공간을 제공하기 위해 중간 또는 높은 effort에서 큰 최대 출력 토큰 예산 (권장 64k 토큰) 설정

Opus 4.7을 대신 사용할 때: 가장 어렵고 장기적인 문제 (대규모 코드 마이그레이션, 깊은 연구, 확장된 자율 작업)의 경우, Opus 4.7이 올바른 선택입니다. Sonnet 4.6은 빠른 처리 시간과 비용 효율성이 중요한 워크로드에 최적화되어 있습니다.

확장 사고를 사용하지 않는 경우

Claude Sonnet 4.5에서 확장 사고를 사용하지 않는 경우, Claude Sonnet 4.6에서도 사용하지 않고 계속할 수 있습니다. 사용 사례에 적절한 수준으로 effort를 명시적으로 설정해야 합니다. low effort에서 사고가 비활성화되면, Claude Sonnet 4.5와 확장 사고 없이 비슷하거나 더 나은 성능을 기대할 수 있습니다.

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "disabled"},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)

확장 사고를 사용하는 경우

Claude Sonnet 4.5에서 budget_tokens를 사용하는 확장 사고를 사용하는 경우, Claude Sonnet 4.6에서도 여전히 작동하지만 더 이상 사용되지 않습니다. effort 매개변수를 사용하여 적응형 사고로 마이그레이션하세요.

적응형 사고로 마이그레이션

적응형 사고는 다음 워크로드 패턴에 특히 적합합니다:

• 자율 다단계 에이전트: 요구 사항을 작동 소프트웨어로 변환하는 코딩 에이전트, 데이터 분석 파이프라인, 모델이 많은 단계에 걸쳐 독립적으로 실행되는 버그 찾기. 적응형 사고를 통해 모델은 단계별로 추론을 보정하여 더 긴 궤적에서 경로를 유지할 수 있습니다. 이러한 워크로드의 경우, high effort로 시작하세요. 지연 시간 또는 토큰 사용이 우려되면, medium으로 축소하세요.
• 컴퓨터 사용 에이전트: Claude Sonnet 4.6은 적응형 모드를 사용하여 컴퓨터 사용 평가에서 최고 수준의 정확도를 달성했습니다.
• 이중 모드 워크로드: 적응형이 간단한 쿼리에서 사고를 건너뛰고 복잡한 쿼리에서 깊이 있게 추론하는 쉬운 작업과 어려운 작업의 혼합.

적응형 사고를 사용할 때, 작업에서 medium 및 high effort를 평가하세요. 올바른 수준은 워크로드의 품질, 지연 시간, 토큰 사용 간의 트레이드오프에 따라 달라집니다.

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

마이그레이션 중 budget_tokens 유지

마이그레이션하는 동안 budget_tokens를 임시로 유지해야 하는 경우, 약 16k 토큰의 예산은 실행 불가능한 토큰 사용 위험 없이 더 어려운 문제에 대한 여유를 제공합니다. 이 구성은 더 이상 사용되지 않으며 향후 모델 릴리스에서 제거될 예정입니다.

코딩 사용 사례 (에이전트 코딩, 도구 집약적 워크플로우, 코드 생성)의 경우, medium effort로 시작하세요:

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=16384,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

채팅 및 비코딩 사용 사례 (채팅, 콘텐츠 생성, 검색, 분류)의 경우, low effort로 시작하세요:

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)