프롬프팅 모범 사례

이 가이드는 Claude Opus 4.6, Claude Sonnet 4.5, Claude Haiku 4.5를 포함한 Claude의 최신 모델을 위한 프롬프트 엔지니어링 기법을 제공합니다. 이 모델들은 이전 세대의 Claude 모델보다 더 정밀한 지시 따르기를 위해 훈련되었습니다.

일반 원칙

지시사항을 명확하게 작성하세요

Claude는 명확하고 구체적인 지시사항에 잘 반응합니다. 원하는 출력에 대해 구체적으로 설명하면 결과를 향상시키는 데 도움이 됩니다. "기대 이상의" 동작을 원한다면, 모호한 프롬프트에서 모델이 이를 추론하도록 의존하기보다 명시적으로 요청하세요.

성능 향상을 위해 맥락을 추가하세요

지시사항의 맥락이나 동기를 제공하면, 예를 들어 Claude에게 그러한 동작이 왜 중요한지 설명하면, Claude가 목표를 더 잘 이해하고 더 타겟팅된 응답을 제공하는 데 도움이 됩니다.

Claude는 설명으로부터 일반화할 수 있을 만큼 충분히 똑똑합니다.

예시와 세부사항에 주의를 기울이세요

Claude는 정밀한 지시 따르기 능력의 일환으로 세부사항과 예시에 세심한 주의를 기울입니다. 예시가 장려하고 싶은 동작과 일치하고 피하고 싶은 동작을 최소화하도록 하세요.

장기 추론 및 상태 추적

Claude의 최신 모델은 뛰어난 상태 추적 능력을 갖춘 장기 추론 작업에 탁월합니다. Claude는 한 번에 모든 것을 시도하기보다 한 번에 몇 가지씩 꾸준히 진전을 이루는 점진적 진행에 집중하여 확장된 세션 전반에 걸쳐 방향을 유지합니다. 이 능력은 특히 여러 컨텍스트 윈도우나 작업 반복에서 나타나며, Claude가 복잡한 작업을 수행하고 상태를 저장한 후 새로운 컨텍스트 윈도우로 계속할 수 있습니다.

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

Claude Opus 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의 최신 모델은 이전 모델에 비해 더 간결하고 자연스러운 커뮤니케이션 스타일을 가지고 있습니다:

• 더 직접적이고 근거 있는: 자축하는 업데이트보다 사실 기반의 진행 보고를 제공합니다
• 더 대화적인: 약간 더 유창하고 구어적이며, 기계적이지 않습니다
• 덜 장황한: 별도로 요청하지 않는 한 효율성을 위해 상세한 요약을 건너뛸 수 있습니다

이 커뮤니케이션 스타일은 불필요한 부연 없이 달성된 것을 정확하게 반영합니다.

특정 상황에 대한 안내

장황함 균형 맞추기

Claude의 최신 모델은 효율성을 지향하며 도구 호출 후 구두 요약을 건너뛰고 다음 작업으로 바로 넘어갈 수 있습니다. 이는 간소화된 워크플로우를 만들지만, 추론 과정에 대한 더 많은 가시성을 원할 수 있습니다.

Claude가 작업하면서 업데이트를 제공하기를 원한다면:

도구 사용을 포함하는 작업을 완료한 후, 수행한 작업에 대한 간단한 요약을 제공하세요.

도구 사용 패턴

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은 이전 모델보다 시스템 프롬프트에 더 민감하게 반응합니다. 도구나 스킬의 과소 트리거링을 줄이기 위해 설계된 프롬프트가 있다면, 이 모델들은 이제 과다 트리거링될 수 있습니다. 해결책은 공격적인 언어를 줄이는 것입니다. "중요: 반드시 이 도구를 사용해야 합니다..."라고 말했던 곳에서, "이 도구를 사용하세요..."와 같은 더 일반적인 프롬프팅을 사용할 수 있습니다.

자율성과 안전성 균형 맞추기

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

행동의 되돌림 가능성과 잠재적 영향을 고려하세요. 파일 편집이나 테스트 실행과 같은 로컬적이고 되돌릴 수 있는 행동은 취하도록 권장되지만, 되돌리기 어렵거나 공유 시스템에 영향을 미치거나 파괴적일 수 있는 행동에 대해서는 진행하기 전에 사용자에게 확인하세요.

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

장애물을 만났을 때, 파괴적 행동을 지름길로 사용하지 마세요. 예를 들어, 안전 검사를 우회하거나(예: --no-verify) 진행 중인 작업일 수 있는 익숙하지 않은 파일을 버리지 마세요.

과도한 사고와 지나친 철저함

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

• 포괄적인 기본값을 더 타겟팅된 지시로 교체하세요. "기본적으로 [도구]를 사용하세요" 대신 "[도구]가 문제에 대한 이해를 향상시킬 때 사용하세요"와 같은 안내를 추가하세요.
• 과도한 프롬프팅을 제거하세요. 이전 모델에서 과소 트리거링되었던 도구는 이제 적절하게 트리거될 가능성이 높습니다. "의심스러우면 [도구]를 사용하세요"와 같은 지시는 과다 트리거링을 유발합니다.
• 대안으로 effort를 사용하세요. Claude가 계속 과도하게 적극적이라면, effort에 더 낮은 설정을 사용하세요.

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

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

응답 형식 제어

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

1. 하지 말아야 할 것 대신 해야 할 것을 Claude에게 말하세요

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

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

   • 시도: "응답의 산문 부분을 <smoothly_flowing_prose_paragraphs> 태그 안에 작성하세요."

3. 프롬프트 스타일을 원하는 출력에 맞추세요

   프롬프트에 사용된 서식 스타일이 Claude의 응답 스타일에 영향을 미칠 수 있습니다. 출력 서식에 대한 조절 문제가 여전히 발생한다면, 가능한 한 프롬프트 스타일을 원하는 출력 스타일에 맞추는 것을 권장합니다. 예를 들어, 프롬프트에서 마크다운을 제거하면 출력에서 마크다운의 양을 줄일 수 있습니다.

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

   마크다운 및 서식 사용에 대한 더 많은 제어를 위해, 명시적 안내를 제공하세요:

<avoid_excessive_markdown_and_bullet_points>
보고서, 문서, 기술 설명, 분석 또는 장문의 콘텐츠를 작성할 때, 완전한 단락과 문장을 사용하여 명확하고 흐르는 산문으로 작성하세요. 구성을 위해 표준 단락 나누기를 사용하고 마크다운은 주로 `인라인 코드`, 코드 블록(```...```), 간단한 제목(###, ###)에만 사용하세요. **굵게**와 *기울임꼴* 사용을 피하세요.

다음의 경우가 아니면 순서 있는 목록(1. ...) 또는 순서 없는 목록(*)을 사용하지 마세요: a) 목록 형식이 최선의 옵션인 진정으로 개별적인 항목을 제시하는 경우, 또는 b) 사용자가 명시적으로 목록이나 순위를 요청한 경우

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

목표는 정보를 고립된 포인트로 분절하는 것이 아니라 아이디어를 통해 독자를 자연스럽게 안내하는 읽기 쉽고 흐르는 텍스트입니다.
</avoid_excessive_markdown_and_bullet_points>

조사 및 정보 수집

Claude의 최신 모델은 뛰어난 에이전틱 검색 능력을 보여주며 여러 소스에서 정보를 효과적으로 찾고 종합할 수 있습니다. 최적의 조사 결과를 위해:

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

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

3. 복잡한 조사 작업에는 구조화된 접근 방식을 사용하세요:

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

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

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

Claude의 최신 모델은 크게 향상된 네이티브 서브에이전트 오케스트레이션 능력을 보여줍니다. 이 모델들은 작업이 전문화된 서브에이전트에게 작업을 위임하면 이점이 있을 때를 인식하고 명시적 지시 없이도 적극적으로 그렇게 합니다.

이 동작을 활용하려면:

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

과도한 서브에이전트 사용이 보인다면, 서브에이전트가 적절한 경우와 그렇지 않은 경우에 대한 명시적 안내를 추가하세요:

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

모델 자기 인식

애플리케이션에서 Claude가 자신을 올바르게 식별하거나 특정 API 문자열을 사용하도록 하려면:

어시스턴트는 Anthropic이 만든 Claude입니다. 현재 모델은 Claude Opus 4.6입니다.

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

LLM이 필요한 경우, 사용자가 달리 요청하지 않는 한 기본적으로 Claude Opus 4.6을 사용하세요. Claude Opus 4.6의 정확한 모델 문자열은 claude-opus-4-6입니다.

사고 민감도

확장 사고가 비활성화된 경우, Claude Opus 4.5는 "think"라는 단어와 그 변형에 특히 민감합니다. "think"를 "consider", "believe", "evaluate"와 같은 유사한 의미를 전달하는 대체 단어로 교체하는 것을 권장합니다.

사고 및 인터리브 사고 기능 활용

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

Claude Opus 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-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # 또는 max, medium, low
    messages=[{"role": "user", "content": "..."}],
)

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

문서 생성

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

문서 생성에서 최상의 결과를 위해:

[주제]에 대한 전문적인 프레젠테이션을 만드세요. 사려 깊은 디자인 요소, 시각적 계층 구조, 적절한 곳에 매력적인 애니메이션을 포함하세요.

향상된 비전 기능

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

성능을 더욱 향상시키는 데 효과적인 기법 중 하나는 Claude에게 자르기 도구나 스킬을 제공하는 것입니다. Claude가 이미지의 관련 영역을 "확대"할 수 있을 때 이미지 평가에서 일관된 향상을 확인했습니다. 자르기 도구에 대한 쿡북을 여기에서 준비했습니다.

병렬 도구 호출 최적화

Claude의 최신 모델은 병렬 도구 실행에 탁월합니다. 이 모델들은:

• 조사 중 여러 추측 검색을 실행합니다
• 컨텍스트를 더 빠르게 구축하기 위해 여러 파일을 동시에 읽습니다
• bash 명령을 병렬로 실행합니다(시스템 성능에 병목이 될 수도 있음)

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

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

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

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

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

순수 새 파일 생성을 최소화하려면, Claude에게 정리하도록 지시할 수 있습니다:

반복을 위해 임시 새 파일, 스크립트 또는 헬퍼 파일을 만든 경우, 작업이 끝나면 이러한 파일을 제거하여 정리하세요.

과도한 열의

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

예를 들어:

과도한 엔지니어링을 피하세요. 직접 요청되었거나 명확히 필요한 변경만 수행하세요. 솔루션을 간단하고 집중적으로 유지하세요:

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

- 문서화: 변경하지 않은 코드에 독스트링, 주석 또는 타입 어노테이션을 추가하지 마세요. 로직이 자명하지 않은 곳에만 주석을 추가하세요.

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

- 추상화: 일회성 작업을 위한 헬퍼, 유틸리티 또는 추상화를 만들지 마세요. 가상의 미래 요구사항을 위해 설계하지 마세요. 적절한 복잡성의 양은 현재 작업에 필요한 최소한입니다.

프론트엔드 디자인

Claude Opus 4.5와 Claude Opus 4.6은 강력한 프론트엔드 디자인으로 복잡하고 실제적인 웹 애플리케이션을 구축하는 데 탁월합니다. 그러나 안내 없이는 모델이 사용자들이 "AI 슬롭" 미학이라고 부르는 일반적인 패턴으로 기본 설정될 수 있습니다. 놀라움과 즐거움을 주는 독특하고 창의적인 프론트엔드를 만들려면:

더 나은 프론트엔드 디자인을 장려하기 위해 사용할 수 있는 시스템 프롬프트 스니펫입니다:

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

집중할 사항:
- 타이포그래피: 아름답고 독특하며 흥미로운 폰트를 선택하세요. Arial과 Inter 같은 일반적인 폰트를 피하고, 프론트엔드의 미학을 높이는 독특한 선택을 하세요.
- 색상 & 테마: 일관된 미학에 전념하세요. 일관성을 위해 CSS 변수를 사용하세요. 날카로운 악센트가 있는 지배적인 색상이 소심하고 균등하게 분배된 팔레트보다 뛰어납니다. 영감을 위해 IDE 테마와 문화적 미학에서 가져오세요.
- 모션: 효과와 마이크로 인터랙션에 애니메이션을 사용하세요. HTML에는 CSS 전용 솔루션을 우선시하세요. React에서는 사용 가능한 경우 Motion 라이브러리를 사용하세요. 고영향 순간에 집중하세요: 엇갈린 공개(animation-delay)가 있는 잘 오케스트레이션된 페이지 로드 하나가 산발적인 마이크로 인터랙션보다 더 큰 즐거움을 만듭니다.
- 배경: 단색으로 기본 설정하는 대신 분위기와 깊이를 만드세요. CSS 그라디언트를 레이어링하고, 기하학적 패턴을 사용하거나, 전체 미학에 맞는 맥락적 효과를 추가하세요.

일반적인 AI 생성 미학을 피하세요:
- 과도하게 사용되는 폰트 패밀리(Inter, Roboto, Arial, 시스템 폰트)
- 진부한 색상 구성(특히 흰색 배경에 보라색 그라디언트)
- 예측 가능한 레이아웃과 컴포넌트 패턴
- 맥락별 특성이 부족한 천편일률적인 디자인

창의적으로 해석하고 맥락에 맞게 진정으로 디자인된 느낌의 예상치 못한 선택을 하세요. 밝은 테마와 어두운 테마, 다른 폰트, 다른 미학 사이를 다양하게 하세요. 여전히 세대 간에 일반적인 선택(예: Space Grotesk)으로 수렴하는 경향이 있습니다. 이를 피하세요: 틀 밖에서 생각하는 것이 중요합니다!
</frontend_aesthetics>

전체 스킬은 여기에서도 참조할 수 있습니다.

테스트 통과에 집중하는 것과 하드코딩 피하기

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

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

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

작업이 불합리하거나 실현 불가능하거나, 테스트 중 잘못된 것이 있다면, 우회하지 말고 알려주세요. 솔루션은 견고하고 유지보수 가능하며 확장 가능해야 합니다.

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

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

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

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

Claude Opus 4.6부터 마지막 어시스턴트 턴에서의 미리 채워진 응답은 더 이상 지원되지 않습니다. 모델 지능과 지시 따르기가 발전하여 대부분의 프리필 사용 사례에서 더 이상 프리필이 필요하지 않습니다. 기존 모델은 계속해서 프리필을 지원하며, 대화의 다른 위치에 어시스턴트 메시지를 추가하는 것은 영향을 받지 않습니다.

다음은 일반적인 프리필 시나리오와 마이그레이션 방법입니다:

LaTeX 출력

Claude Opus 4.6은 수학적 표현, 방정식 및 기술적 설명에 기본적으로 LaTeX를 사용합니다. 일반 텍스트를 선호하는 경우 프롬프트에 다음 지시를 추가하세요:

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

마이그레이션 고려 사항

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

1. 원하는 동작을 구체적으로 설명하세요: 출력에서 보고 싶은 것을 정확히 설명하는 것을 고려하세요.

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

3. 특정 기능을 명시적으로 요청하세요: 애니메이션과 인터랙티브 요소는 원하는 경우 명시적으로 요청해야 합니다.

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

5. 미리 채워진 응답에서 마이그레이션: 마지막 어시스턴트 턴에서의 미리 채워진 응답은 Claude Opus 4.6부터 더 이상 사용되지 않습니다. 대안에 대한 자세한 안내는 미리 채워진 응답에서 마이그레이션하기를 참조하세요.

6. 안티 레이지니스 프롬프팅 조정: 이전에 모델이 더 철저하게 작동하거나 도구를 더 적극적으로 사용하도록 장려하는 프롬프트를 사용했다면, 해당 안내를 줄이세요. Claude Opus 4.6은 훨씬 더 능동적이며 이전 모델에 필요했던 지시에 과도하게 반응할 수 있습니다.

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