3줄 요약
- Anthropic이 Claude 최신 모델(Opus 4.7, 4.6, Sonnet 4.6)을 위한 프롬프트 엔지니어링 종합 가이드를 공식 문서로 제공한다.
- Opus 4.7에서 effort 매개변수가 모델 제어의 핵심 레버로 부상했으며, 프롬프트를 문자 그대로 해석하는 경향이 강화되었다.
- 에이전트 시스템에서는 자율성과 안전성의 균형, 다중 컨텍스트 윈도우 상태 관리, 과도한 엔지니어링 방지가 실전 과제로 부각된다.
Opus 4.7: 달라진 것들
Opus 4.7은 기존 Opus 4.6 프롬프트와 기본적으로 호환되지만, 몇 가지 동작이 근본적으로 바뀌었다.
effort가 첫 번째 레버다. 코딩과 에이전트 작업에는 xhigh, 지능 민감 작업에는 최소 high를 권장한다. low와 medium에서 모델은 요청 범위를 엄격하게 지키므로, 복잡한 문제에서 얕은 추론이 보이면 프롬프트를 고치기 전에 effort부터 올려야 한다. Anthropic은 “effort가 이전 어떤 Opus보다 이 모델에 더 중요하다"고 명시한다.
문자 그대로의 지침 따르기. 이전 모델처럼 지침을 암묵적으로 일반화하지 않는다. 한 항목의 규칙을 다른 항목에 자동 확장하지 않으므로, 광범위 적용이 필요하면 범위를 명시해야 한다. API 파이프라인처럼 예측 가능한 동작이 필요한 경우 장점이 크다.
디자인 기본값이 고정되어 있다. 따뜻한 크림 배경(#F4F1EA), 세리프 디스플레이 타입, 테라코타 악센트가 기본. “크림을 쓰지 마"는 다른 고정 팔레트로 이동시킬 뿐이다. 구체적 hex/typeface를 지정하거나, 먼저 4가지 시각적 방향을 제안받은 후 선택하는 방식이 효과적이다.
서브에이전트 생성이 줄었다. 기본적으로 더 적게 생성하는 경향이므로, 팬아웃이 필요한 상황과 직접 처리가 나은 상황을 명시적으로 구분해주면 된다.
일반 원칙
황금 규칙. 프롬프트를 맥락 없는 동료에게 보여줬을 때 혼란스러워할 내용이면 Claude도 혼란스러워한다. Claude를 규범과 워크플로우 맥락이 없는 뛰어난 신입사원으로 생각하라.
예제가 가장 신뢰할 수 있는 형식 제어 수단이다. 3~5개의 few-shot 예제가 정확성과 일관성을 극적으로 개선한다. 관련성, 다양성(엣지 케이스 포함), 구조화(<example> 태그)가 핵심 요건이다.
긴 문서는 맨 위에, 쿼리는 맨 아래에. 20k+ 토큰 문서를 다룰 때 이 배치만으로 응답 품질이 최대 30% 향상된다. 여러 문서는 <document> 태그로 구조화하고, 작업 전 관련 부분 인용을 먼저 요청하면 노이즈를 걸러낸다.
XML 태그로 콘텐츠 유형을 분리한다. 지침, 맥락, 예제, 변수 입력을 각각의 태그(<instructions>, <context>, <input>)로 감싸면 오해석을 줄인다.
출력 제어
“하지 마” 대신 “해라"가 효과적이다. “마크다운을 쓰지 마” 대신 “부드럽게 흐르는 산문 단락으로 작성해라"가 더 잘 작동한다. XML 형식 표시기(<smoothly_flowing_prose_paragraphs>)도 유용하다. 프롬프트 자체의 포맷 스타일이 출력 포맷에 영향을 미치므로, 프롬프트 형식을 원하는 출력과 일치시키는 것이 좋다.
prefill(미리 채우기)은 4.6부터 deprecated. 모델 지능이 향상되어 대부분의 사용 사례에서 불필요해졌다. 형식 제어는 시스템 프롬프트 지침으로, 연속 작업은 이전 출력을 별도 메시지로 전달하여 대체한다.
도구 사용과 에이전트 행동
행동을 원하면 명시적으로 지시하라. “변경을 제안할 수 있나요?“라고 하면 제안만 한다. 구현을 원하면 명시적으로 요청해야 한다. <default_to_action> 시스템 프롬프트로 기본 행동 수준을 조종할 수 있다. 단, 4.5/4.6은 시스템 프롬프트에 더 민감하므로 “CRITICAL: MUST” 같은 공격적 언어는 과도한 트리거를 유발한다.
병렬 도구 호출을 프롬프트로 거의 100%까지 끌어올릴 수 있다. <use_parallel_tool_calls> 지침으로 독립 호출은 병렬로, 종속 호출은 순차로 구분하라. 자리 표시자를 쓰거나 누락 매개변수를 추측하지 않도록 명시한다.
적응형 사고가 확장 사고를 대체한다. Claude 4.6+에서 thinking: {type: "adaptive"}가 기본. effort 매개변수와 쿼리 복잡성에 따라 동적으로 사고 깊이를 결정한다. budget_tokens 방식은 deprecated. 내부 평가에서 적응형 사고가 확장 사고보다 안정적으로 더 나은 성능을 보였다.
에이전트 시스템 운영
상태 관리는 세 갈래. 테스트/작업 상태는 JSON 구조화 형식, 진행 메모는 비구조화 텍스트, 체크포인트/이력은 git. 다중 컨텍스트 윈도우 작업에서는 첫 윈도우에 프레임워크(테스트, 셋업 스크립트)를 만들고 이후 윈도우에서 반복한다.
자율성과 안전성의 균형은 되돌림 가능성이 기준이다. 되돌릴 수 있는 로컬 작업(편집, 테스트)은 자율적으로, 되돌리기 어렵거나 공유 시스템에 영향을 주는 작업(삭제, force push, 외부 게시)은 사전 확인을 받도록 지시한다. 장애물 앞에서 파괴적 조치를 지름길로 사용하지 않도록 명시해야 한다.
압축보다 새 윈도우가 나을 수 있다. 최신 모델은 로컬 파일 시스템에서 상태를 발견하는 데 뛰어나다. 컨텍스트가 가득 찼을 때 압축 대신 완전히 새 윈도우를 시작하는 것이 효과적일 수 있다. 단, pwd 확인, 진행 파일 검토, 통합 테스트 실행 등 시작 방법을 규정적으로 지시해야 한다.
과도한 엔지니어링 방지. Opus 4.5/4.6은 불필요한 추상화, 과도한 방어 코딩, 미래를 위한 설계를 하는 경향이 있다. “직접 요청된 것만 구현하라”, “시스템 경계에서만 검증하라”, “가상 요구사항을 위해 설계하지 마라"는 지침이 효과적이다.
환각 최소화. <investigate_before_answering> 지침으로 강화할 수 있다. 핵심: 사용자가 특정 파일을 참조하면 반드시 읽은 후 답변, 조사하지 않은 코드에 대해 어떤 주장도 하지 않기, 확실하지 않으면 근거를 대기.
마이그레이션 고려사항
이전 세대에서 4.6 모델로 넘어올 때의 핵심 체크리스트: (1) 원하는 동작을 구체적으로 서술, (2) 수정자(“가능한 한 많은 관련 기능을 포함하세요”)로 지침을 보강, (3) 사고 구성을 적응형 사고로 업데이트, (4) prefill에서 마이그레이션, (5) 이전 모델의 “반-게으름 프롬프팅”(도구를 더 공격적으로 사용하도록 유도하는 지침)을 다시 조정.
Sonnet 4.5에서 4.6으로 올릴 때는 effort 매개변수를 명시적으로 설정하는 것이 중요하다. 기본 high가 이전보다 높은 지연 시간을 유발할 수 있다.
가장 흥미로운 지점
effort 매개변수의 부상이 인상 깊다. 프롬프트 엔지니어링의 전통적 접근법 — 지침을 더 정교하게 다듬기 — 이 모델 세대가 올라갈수록 “effort 레벨을 올려라"는 단순한 조작으로 대체되고 있다. Anthropic이 직접 “복잡한 문제에서 얕은 추론이 보이면 프롬프트를 고치기 전에 effort부터 올려라"고 권고하는 것은, 프롬프트 크래프팅의 수익 체감 시점이 점점 빨라지고 있다는 신호다.
출처
Anthropic 공식 문서 원문: https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/claude-prompting-best-practices