앤트로픽이 공개한 클로드 Opus 5.5 프롬프트 가이드는 이전 세대인 Opus 5와의 '행동 차이'와 그에 맞춘 프롬프트·하네스 패턴에 초점을 맞춘다. 핵심 전제는 두 가지다. 첫째, Opus 5.5는 같은 작업을 더 적은 토큰으로 끝내며 출력 토큰 생성 속도가 Opus 5보다 30% 이상 빠르다. 둘째, 기존 Opus 5용 프롬프트는 대체로 그대로도 잘 작동한다. 따라서 전면 재작성보다는 관찰된 문제 지점부터 손보는 접근이 권장된다. 실무자 입장에서 중요한 것은 속도 이득 자체가 아니라, 달라진 기본값과 종료 행동이 자동화 파이프라인에서 어떤 부작용을 일으키는가다.
노력(effort) 값부터 다시 맞춰라
사고(thinking)가 항상 켜져 있는 구조에서 지능·지연·비용의 균형을 조정하는 1차 손잡이는 effort다. 주의할 점은 기본값이 바뀌었다는 것이다. Opus 5는 high가 기본이었지만 Opus 5.5는 medium이 기본이다. 게다가 같은 레벨 이름이라도 모델마다 실제 사고량이 다르다. 앤트로픽 테스트에서 Opus 5.5의 medium은 코딩·지식 작업에서 Opus 5의 high와 같거나 그 이상이었고, 일부 코딩 평가에서는 low가 훨씬 낮은 비용으로 그에 근접했다. 그러므로 Opus 5에서 쓰던 값을 그대로 옮기지 말고 medium을 명시적으로 설정한 뒤 자체 평가셋으로 여러 레벨을 비교하는 편이 낫다. 같은 레벨이라도 Opus 5.5는 턴당 사고량이 더 많아지는 경향이 있어, 특히 xhigh·max에서 값을 그대로 유지하면 턴이 길어지고 출력 토큰이 늘어난다. 또 최상위 effort 값을 요청 사이에 바꾸면 프롬프트 캐시가 무효화되므로, 특정 턴만 다른 레벨로 돌리려면 캐시를 유지하는 메시지 단위 effort 변경(베타)을 쓰는 것이 유리하다. 참고로 Opus 5는 high 이하에서 사고 비활성화를 허용했지만 Opus 5.5는 이를 받지 않는다.
자동화 에이전트의 '조기 종료' 문제
여러 단계로 이뤄진 긴 작업에서 Opus 5.5는 진행 상황을 사용자에게 보고하는데, 이 보고가 도구 호출 없이 텍스트로 턴을 끝내는 경우가 있다(stop_reason이 end_turn). 무인 에이전트 루프가 이런 턴을 '작업 완료'로 오인하면 거기서 멈춰버린다. 대응은 텍스트만으로 끝난 턴을 완료 증거가 아니라 중간 보고로 취급하는 것이다. 작업 항목을 to-do 도구나 파일에 체크리스트로 관리하고, 열린 항목이 남았는데 별도 장애물 언급이 없으면 남은 항목을 짚는 짧은 사용자 메시지를 보내 이어가게 한다. 완료 조건을 미리 명시하고 별도의 소형 모델이 매 턴 종료 시점에 조건 충족 여부를 점검하게 하는 방식도 있다. 다만 같은 작업에서 자동 재개는 두세 번 이하로 제한해, 실제로 막힌 실행은 종료되어 검토로 넘어가게 해야 한다. 백그라운드 명령이나 서브에이전트가 아직 돌고 있다면 그 출력이 돌아올 때까지 완료로 보지 않는 것도 기본이다. 시스템 프롬프트에 '요약만 하고 다음 단계를 예고한 채 멈추는' 식의 특정 조기 종료를 피하라고 명시하면 이런 중단이 줄지만, 이 문구는 세션 첫 요청부터 넣어야 한다. 중간에 추가하면 시스템 프롬프트가 바뀌어 이전 사고 블록이 무효화되기 때문이다.
진행 표시, 다중 앱, 시간 예산
도구 호출 사이의 진행 메시지는 Opus 5.5에서 텍스트 블록이 아니라 progress-update 사고 블록으로 오며, 기본 표시 설정에서는 본문이 비어 있다. 텍스트 블록만 렌더링하는 클라이언트는 긴 턴 동안 아무것도 안 보이는 것처럼 느껴질 수 있으니 display를 updates(베타)로 설정해 요약을 받아야 한다. 코드 조각처럼 사용자에게 원문 그대로 전달할 내용이 있으면 전용 메시지 전송 도구를 세션 첫 요청부터 선언해 두는 것이 좋다. 긴 도구 호출 턴이 계속 조용하면 몇 스텝 연속 무응답을 세어 리마인더를 덧붙이는 방식도 있는데, 앤트로픽 테스트에서 이 방법은 비용 변화 없이 '오래 침묵하는 작업' 비율을 대략 절반으로 줄였다. 여러 앱을 넘나드는 워크플로에서는 필요한 정보가 요청에 명시되지 않은 다른 탭·이메일·고객 기록에 숨어 있는 경우가 많다. '변경 전에 관련 소스를 먼저 살펴보라'는 한 문장을 시스템 프롬프트에 넣으면 medium·max 모두에서 정답 완수율이 눈에 띄게 올라갔다. 대신 도구 호출과 토큰이 조금 늘고, 모델이 찾은 내용을 바로 실행하므로 검색 대상에 신뢰할 수 없는 콘텐츠가 섞이지 않도록 관리해야 한다. 다중 에이전트 구조에서는 'elapsed 340s / 1200s' 식으로 경과 시간과 예산을 알려주면 병렬화가 개선돼 팀이 더 빨리 끝냈다. 단 이 예산은 권고일 뿐 강제 중단 장치가 아니므로 하드 타임아웃은 별도로 두어야 하고, 시간 압박 아래에서 검증이 다소 줄 수 있어 품질을 함께 확인해야 한다.
챗 동작과 보안 방어
챗 애플리케이션이라면 '답하기 전에 신중히 생각하라'는 류의 지시를 빼는 편이 낫다. 모델이 스스로 사고량을 정하며 effort가 주된 제어이기 때문인데, 실제로 해당 문구를 없애자 품질 저하 없이 응답이 더 빨리 시작됐다. 멀티턴 대화에서 Opus 5.5는 짧은 후속 질문에도 이전 답을 다시 검토해 지연을 늘리곤 한다. 이전 답을 확정된 것으로 다루게 하는 두 문장을 넣으면 후속 턴의 사고가 줄지만, 긴 분석이나 뒤 단계가 앞 단계 오류를 드러낼 수 있는 에이전트 작업에는 빼야 한다. 이 지시는 모델이 이전 답의 오류를 스스로 지적할 가능성도 낮출 수 있으니 도입 전 검증이 필요하다. 보안 측면에서 Opus 5.5는 도구 결과나 웹페이지를 통한 간접 프롬프트 인젝션에 이전 어떤 Opus보다 강하다. 사용자가 붙여넣은 텍스트에 대해서도, 애플리케이션이 생성한 동일한 무작위 ID를 여는 태그와 닫는 태그에 실어 붙여넣기 블록을 감싸고 시스템 프롬프트에 관련 안내를 더하면 방어력이 높아진다. 다만 태그는 평문이라 모방될 수 있으므로 다른 방어책과 함께 쓰는 보조 장치로 봐야 한다. 마지막으로 차트·다이어그램·스크린샷 판독 정밀도가 크게 올랐으므로, Opus 5 시절 시각 입력용으로 만들어 둔 보조 장치가 여전히 필요한지 재검증할 만하다. 또한 안전 분류기 거부는 stop_reason이 refusal인 정상 응답으로 오며, reasoning_extraction 거부만 서버 측 폴백이 재시도 대신 그대로 반환한다는 점도 통합 설계 시 기억해 둘 대목이다.