Reddit

Claude Opus 5.5 official prompting guide

Claude Opus 5.5 공식 프롬프트 가이드 — 노력 수준부터 에이전트 실행까지

Anthropic이 Claude Opus 5.5에 맞춘 프롬프트 작성과 에이전트 실행 지침을 공개했습니다. 노력 수준 조정, 중단된 작업 이어가기, 진행 상황 표시, 멀티에이전트 시간 예산 설정처럼 실제 API 통합에서 점검할 항목을 정리합니다.

AI 요약

Anthropic의 가이드는 Claude Opus 5에서 사용하던 프롬프트를 대체로 그대로 쓸 수 있다고 설명하면서, Opus 5.5에서 달라진 추론 방식과 에이전트 실행 동작에 맞춰 점검할 부분을 안내합니다. Opus 5.5는 Opus 5보다 출력 토큰을 30% 이상 빠르게 생성하고 같은 작업을 더 적은 토큰으로 끝내는 경향이 있습니다. 다만 추론이 항상 켜져 있어 기존 설정을 그대로 옮기면 지연 시간이나 비용, 작업 종료 방식이 달라질 수 있습니다.

노력 수준과 토큰 한도 조정

추론량을 조절하는 기본 설정은 effort입니다. Opus 5.5의 기본값은 medium이며, Opus 5의 기본값 high와 이름이 같더라도 모델 사이에서 노력 수준이 같은 추론량을 뜻하지는 않습니다. Anthropic의 평가에서 Opus 5.5는 medium으로 Opus 5의 high와 비슷하거나 더 나은 코딩·지식 업무 결과를 냈고, 일부 코딩 평가에서는 low도 훨씬 적은 비용으로 Opus 5의 high에 가까웠습니다. 따라서 이전 모델의 설정을 그대로 가져오기보다 자체 평가 데이터로 여러 수준을 비교하라고 권합니다.

같은 effort에서도 Opus 5.5는 특히 xhigh와 max에서 Opus 5보다 한 차례 응답에 더 오래 추론하는 경향이 있습니다. max_tokens에는 답변뿐 아니라 사용자에게 표시되지 않는 추론 토큰도 포함됩니다. Opus 5에서 추론을 끈 채 사용하던 한도를 그대로 적용하면 답변이 잘릴 수 있으며, 장시간 코딩 작업에는 최대값인 128,000이 잘 작동했다고 설명합니다. 비용과 지연을 줄일 때는 프롬프트로 추론을 억제하기보다 effort를 낮추는 편이 더 안정적입니다. 요청마다 최상위 effort를 바꾸면 프롬프트 캐시가 무효화되지만, 베타 기능인 메시지별 effort 변경은 캐시를 유지합니다.

비동기 에이전트는 완료 조건을 확인해야 합니다

Opus 5.5는 긴 작업 중 진행 상황을 알리는 텍스트를 보내고, 그 메시지에서 도구 호출 없이 턴을 끝낼 수 있습니다. 응답의 stop_reason이 end_turn이라고 해서 작업 전체가 끝난 것은 아닙니다. 에이전트 실행 루프가 이를 곧바로 완료로 처리하면 남은 작업이 있어도 실행이 멈춥니다.

가이드는 미완료 항목을 체크리스트나 파일에 기록하고, 열린 항목이 남았는데 막힌 이유가 없다면 다음 사용자 메시지로 남은 일을 짧게 지시하라고 합니다. 백그라운드 명령이나 하위 에이전트가 실행 중이면 결과를 기다려 다음 메시지로 전달해야 합니다. 자동 재시도는 같은 작업에서 두세 번으로 제한해 실제로 막힌 작업이 끝없이 반복되지 않도록 합니다. 시스템 프롬프트에 작업을 계속 이어갈 상황과 사용자 확인을 기다릴 상황을 구체적으로 적으면 조기 종료를 줄일 수 있지만, 위험하거나 되돌리기 어려운 작업에는 별도 확인 절차를 유지해야 합니다.

진행 상황을 화면에 표시하는 방법

Opus 5.5의 진행 메모는 일반 텍스트 블록이 아니라 progress-update 유형의 thinking 블록으로 전달됩니다. 기본 thinking.display 설정에서는 이 블록의 텍스트가 비어 있으므로, 텍스트 블록만 보여주는 클라이언트는 긴 작업 중 아무 응답도 없는 것처럼 보일 수 있습니다. 베타 헤더를 사용해 display를 updates로 설정하면 각 메모의 요약을 받을 수 있습니다.

작업 중 사용자에게 코드 조각처럼 원문 그대로 전달할 내용이 있다면, 첫 요청부터 이를 보내는 도구를 선언하고 해당 도구의 용도를 프롬프트에 적으라고 안내합니다. 업데이트 주기를 더 자주, 또는 첫 도구 호출 전과 작업 종료 때처럼 일정하게 맞추고 싶다면 시스템 프롬프트에 명시할 수 있습니다. 그래도 오랫동안 진행 메모가 없으면 하네스가 도구 호출이 연속해서 몇 번 이어졌는지 세고, 예를 들어 다섯 번 뒤에 상태를 알리라고 요청할 수 있습니다. Anthropic의 에이전트 코딩 평가에서는 이 방식으로 긴 침묵 구간이 있는 작업의 비율이 대략 절반으로 줄었으며 비용 변화는 측정되지 않았다고 합니다.

여러 앱을 탐색하고 작업을 병렬화하기

이메일, 문서, 스프레드시트, CRM을 함께 다루는 자동화 작업에서는 사용자가 직접 언급하지 않은 정보가 결과에 영향을 줄 수 있습니다. 가이드는 행동하기 전에 관련 앱의 이메일과 문서, 스프레드시트 탭, 레코드를 폭넓게 찾아보라는 지시를 시스템 프롬프트에 넣도록 제안합니다. Anthropic의 평가에서 이 지시는 medium과 max 모두에서 작업 성공을 높였지만 도구 호출과 토큰은 조금 늘었습니다. 검색 결과에 포함된 신뢰할 수 없는 내용이 에이전트의 행동을 지시하지 않도록 별도의 방어도 필요합니다.

멀티에이전트 하네스에는 작업의 예상 시간 예산을 전달할 수 있습니다. 각 응답 뒤에 ‘elapsed 340s / 1200s’처럼 예산 대비 경과 시간을 붙이면 모델이 예산 안에서 작업을 마치도록 속도를 조절합니다. 예상 시간을 정하기 어렵다면 경과 시간만 알려주고, 피할 수 있는 지연을 줄이라는 지시를 시스템 프롬프트에 추가하는 방법도 있습니다. Anthropic은 연구 작업을 수행한 소규모 에이전트 팀이 단일 에이전트보다 빨리 끝났고, 시간 예산을 준 팀은 결과 품질을 비슷하게 유지하면서 상당히 빨리 끝났다고 보고합니다. 시간 예산은 강제 종료 장치가 아니므로 하드 타임아웃은 하네스에서 별도로 설정해야 합니다. 시간 압박이 검색과 검증을 줄일 수도 있어 자체 작업에서 품질을 확인해야 합니다.

채팅, 복사한 텍스트, 시각 입력

채팅 시스템 프롬프트에 ‘신중하게 생각하라’는 지시가 있다면 제거를 검토할 수 있습니다. 모델이 추론량을 스스로 조절하며 effort가 주된 제어 수단이기 때문입니다. Anthropic의 채팅 제품 테스트에서는 해당 문장을 뺐을 때 답변 품질이 뚜렷하게 떨어지지 않으면서 첫 응답이 빨라졌습니다. 다중 턴 대화에서 앞선 답변을 다시 검토해 지연이 늘어나는 현상을 줄이려면, 사용자가 문제를 지적하지 않는 한 이전 답변은 확정된 것으로 다루라는 문장을 추가할 수 있습니다. 다만 긴 분석이나 앞선 단계의 오류를 뒤에서 발견해야 하는 에이전트 작업에는 적합하지 않을 수 있습니다.

사용자가 이메일이나 웹페이지 내용을 붙여넣을 때는 애플리케이션이 만든 임의 ID가 붙은 태그로 해당 내용을 감싸고, 사용자 자신의 지시와 복사된 내용을 구분하라고 안내합니다. 태그 안의 지시는 사용자가 따르라고 요청한 경우에만 따르도록 시스템 프롬프트에 명시합니다. 태그는 일반 텍스트라 흉내 낼 수 있으므로 프롬프트 인젝션 방어책 하나로만 취급해야 합니다.

차트와 다이어그램, 스크린샷 읽기 성능은 Opus 5보다 나아져 이전 모델에 맞춰 만든 보조 프롬프트가 여전히 필요한지 다시 평가하라고 합니다. 복잡한 입력에는 고해상도 이미지가 도움이 되며, PIL이나 OpenCV가 설치된 컨테이너를 도구로 제공하면 모델이 이미지를 자르고 확대하고 측정하며 결과를 검증할 수 있습니다. 컨테이너가 부담스럽다면 이미지 자르기 도구만 써도 도움이 됩니다. 프런트엔드 작업에서는 ‘일반적인 AI 디자인을 피하라’고만 하기보다 크림색 배경, 기울임꼴 강조 문구, 숫자형 섹션 표기, 모노스페이스 라벨, 알약 모양 버튼처럼 피하고 싶은 구체적인 스타일을 지정하고 첫 결과를 확인해 목록을 보완하라고 권합니다.

Reddit 반응

  • @u/EzoLabsInc — 에이전트가 일찍 멈추는 4번 항목이 안전장치보다 더 큰 함정처럼 보입니다. 실제로 작업을 끝내기 전에 멈추는 일을 겪으셨나요, 아니면 API 문서에서 그럴 수 있다고 경고하는 정도인가요?
    • @u/BuffaloConscious7919 — 저는 직접 겪지는 않았지만 문서에는 그렇게 나와 있습니다.
    • @u/EzoLabsInc — 네, 그렇군요. 그래도 작업 유형에 따라 동작이 달라질 수 있으니 직접 시험해볼 가치가 있겠네요.
  • @u/optima-pacifist — 시간 예산 항목은 새로 알았습니다. 작업에 대략 얼마나 걸릴지 알려줬더니 긴 리팩터링을 일찍 마무리하려는 일이 줄었습니다.
    • @u/Claud711 — 저도 예전에는 토큰 예산으로 그렇게 했습니다. 효과는 있었지만 AI가 멈춰서 토큰을 세야 하니 확실히 덜 편합니다. 시간은 AI가 예산으로 쓰기 훨씬 쉽네요. 좋은 생각입니다.
  • @u/st_malachy — “신중하게 생각하라”고 하지 말고 “먼저 둘러보라”고 하라니, 기가 막히네요. /s
    • @u/Makemeacyborg — 말이 좀 우스워 보이긴 하고, 실제로 그 문장을 그대로 쓰라는 뜻은 아니라고 봅니다. 그래도 “둘러보라”는 “신중하게 생각하라”와 달리 구체적인 행동이긴 합니다.
  • @u/n_v40 — 에이전트가 관리되지 않은 채 실행될 때 생기는 문제는 모델이 멈추는 일만이 아니라 하네스 문제이기도 합니다. 가이드에 따르면 Opus는 진행 상황을 보고하는 메시지로 턴을 끝낼 수 있습니다. 모든 end_turn을 완료로 처리하는 루프는 작업을 일찍 멈춥니다. 열린 체크리스트 항목을 추적하고 두세 번 정도만 제어된 재개를 허용하는 편이 프롬프트로 동작을 억지로 바꾸려는 것보다 더 안정적입니다.
  • @u/dynamoney — 경과 시간 방식은 효과가 있더라도 좀 이상하게 느껴집니다. 에이전트 팀이 작업에 340초가 필요한지 1200초가 필요한지 사용자가 어떻게 알 수 있나요? 출력 속도는 첫 토큰 이후 일정하다면 토큰 예산이 더 적절하지 않을까요?

원문: Anthropic Claude Platform 문서 / 번역·요약: Trawling