앤트로픽이 공개한 Claude Opus 5.5 공식 프롬프팅 가이드에서, 기존 습관을 실제로 바꿔야 하는 여덟 가지를 골라 정리한 영상입니다. 채팅창에서 Claude를 쓰는 분과 API로 앱이나 에이전트를 만드는 개발자 모두에게 해당하며, 영상에서는 항목마다 누구에게 해당하는 내용인지 구분해서 설명했습니다.
기본 effort가 medium으로 바뀌었습니다
effort는 모델이 답하기 전에 얼마나 생각할지를 정하는 설정입니다. Opus 5는 기본값이 high였지만 Opus 5.5는 medium이고, Claude Code의 기본값도 medium입니다. 예전에 저장해 둔 effort 값은 Opus 5.5로 넘어오지 않습니다.
앤트로픽은 medium에서 시작하라고 권합니다. 가이드에 따르면 자체 테스트에서 Opus 5.5의 medium이 코딩과 지식 업무에서 Opus 5의 high와 같거나 더 나은 결과를 냈고, 같은 이름의 레벨이라도 5.5가 한 번에 더 많이 생각합니다. 그래서 high나 max를 습관적으로 켜 두면 턴이 길어지고 출력 토큰이 늘어날 수 있습니다. 생각을 줄이고 싶다면 프롬프트 문구를 고치기 전에 effort부터 낮추고, 가장 높은 단계는 실제로 결과가 나아진 것을 확인한 작업에만 쓰라는 것이 가이드의 권고입니다.
API 개발자가 챙길 부분도 있습니다. 화면에 보이지 않는 thinking 토큰도 max_tokens에 포함되므로 한도를 넉넉히 잡아야 하고, 긴 에이전트 코딩에서는 최대치인 128K가 잘 맞았다고 합니다. 요청마다 기본 effort를 바꾸면 프롬프트 캐시가 깨지므로, 턴마다 레벨을 바꾸고 싶다면 메시지 단위로 effort를 지정하는 베타 기능을 쓰라고 안내합니다. 단테는 같은 작업을 medium과 high로 한 번씩 돌려 요구 사항 누락, 추천의 쓸모, 걸린 시간을 비교해 보라고 제안했습니다.
"신중하게 생각하라" 대신 도달할 결과를 적습니다
시스템 프롬프트에 "신중하게 생각하고 답하라" 같은 문장을 쌓아 두었다면 점검해 볼 만합니다. Opus 5.5는 얼마나 생각할지를 스스로 정하고, 이를 조절하는 주된 손잡이는 effort입니다. 앤트로픽 테스트에서는 이 지시를 뺐더니 답이 더 빨리 시작됐고 품질이 뚜렷하게 떨어지지 않았다고 합니다.
또 Opus 5.5는 새 질문을 받으면 이전 답을 다시 검토하기도 합니다. 가이드에는 "이미 한 답은 끝난 것으로 보고, 사용자가 문제를 지적할 때만 다시 보라"는 예시 문장이 있습니다. 불필요한 작업은 줄지만 앞선 실수를 스스로 잡아내는 일도 줄어들 수 있으므로, 새 근거가 계속 나오는 리서치에는 넣지 않는 편이 낫습니다.
핵심은 막연한 태도 지시 대신 목표를 주는 것입니다. "모든 세부 사항을 깊고 신중하게 생각해 줘"는 어떤 답이 좋은 답인지 알려 주지 않습니다. "두 제안서를 내 요구 사항과 비교하고, 하나를 추천하고, 핵심 트레이드오프를 설명해 줘"라고 하면 Claude가 도달할 결과가 생깁니다.
행동 전에 둘러보게 하고, 요청과 붙여 넣은 글을 구분합니다
가이드는 Opus 5.5가 빨리 착수하는 편이라고 설명합니다. 대체로 장점이지만 메일, 문서, 스프레드시트를 오가는 작업에서는 요청에 적히지 않은 정보가 중요할 때가 있습니다. 그래서 앤트로픽은 "행동하기 전에 도구로 넓게 탐색하고, 작업에 이름이 나오지 않은 자료라도 관련 있을 만한 것은 확인하라"는 문장을 시스템 프롬프트에 넣으라고 제안합니다. 여러 앱 테스트에서 제대로 끝낸 작업이 눈에 띄게 늘었고, 도구 호출과 토큰은 조금 더 썼다고 합니다. 에이전트가 뒤지는 자료에 믿을 수 없는 콘텐츠가 섞이지 않게 하라는 조건도 붙어 있습니다. 예를 들어 기획서에는 마감이 월요일인데 나중에 온 메일에서 금요일로 바뀌었다면, 기획서만 읽은 모델은 깔끔하지만 틀린 날짜의 업데이트를 씁니다.
네 번째는 내 요청과 다른 사람이 쓴 콘텐츠를 구분하는 일입니다. 붙여 넣은 메일이나 웹페이지 안에도 지시문이 있을 수 있지만 그건 내 지시가 아닙니다. 가이드는 앱을 만드는 쪽에서 붙여 넣은 텍스트를 별도 태그로 감싸고, 그 안의 지시는 사용자가 요청한 경우에만 따르라고 시스템 프롬프트에 적는 방법을 소개합니다. 태그는 흉내 낼 수 있으니 방어 장치 중 하나로만 봐야 합니다. 채팅에서도 원칙은 같아서, "이 메일 요약해 줘"처럼 할 일을 먼저 쓰고 메일은 그 아래 따로 붙이면 됩니다.
에이전트 개발자를 위한 진행 표시와 완료 판정
다섯 번째는 API로 앱을 만드는 분들의 이야기입니다. Opus 5.5는 도구를 쓰는 중간중간 진행 상황을 남기는데, 기본 설정에서는 이것이 내용이 빈 thinking 블록으로 옵니다. 앱이 텍스트 블록만 그리면 Claude가 말없이 멈춘 것처럼 보입니다. thinking의 표시 방식을 업데이트를 받는 쪽으로 바꾸면 이 메모를 볼 수 있고, Claude에게 말을 더 하라고 시켜도 앱이 숨기는 업데이트는 보이지 않습니다. 시스템 프롬프트로 "파일 검토가 끝났을 때, 초안이 준비됐을 때"처럼 업데이트 시점을 정하고 그 사이에는 멈추지 말라고 적을 수도 있습니다. 조용한 도구 호출이 다섯 번쯤 이어지면 하네스가 짧은 알림을 넣되 두세 번까지만 보내라는 방법도 나오는데, 단테는 이 영상을 만든 Claude Code 세션에도 같은 문구의 알림이 실제로 여러 번 들어왔다고 덧붙였습니다.
여섯 번째는 답이 끝났다고 일이 끝난 것은 아니라는 점입니다. 긴 작업에서 Opus 5.5는 진행 보고를 하면서 턴을 끝내기도 하는데, 사람이 지켜보지 않는 에이전트 루프가 이걸 완료로 받아들이면 일이 중간에 멈춥니다. 가이드는 도구 호출 없이 말로만 끝난 턴을 완료의 증거가 아니라 보고로 보라고 합니다. 받아야 할 결과물을 체크리스트로 관리하고, 남은 항목이 있으면 그 항목을 짚어서 계속하라고 보냅니다. 예를 들어 완료 조건을 "보고서, 출처 목록, 요약 세 가지"로 정해 두었는데 요약이 빠졌다면 "계속해"가 아니라 "요약이 빠졌어. 마무리하거나 막힌 이유를 알려줘"라고 보내는 식입니다. 자동 재시도는 두세 번에서 멈추고, 백그라운드 작업이 있으면 결과를 기다린 뒤 끝내야 하며, 위험한 작업의 확인 절차는 그대로 둡니다.
디자인 주문과 이미지 읽기
일곱 번째는 디자인입니다. 방향을 주지 않으면 Opus 5.5도 몇 가지 기본 스타일로 돌아갑니다. "AI 느낌 안 나게 해 줘"라고 하면 기본값 하나를 다른 기본값으로 바꾸는 데 그치는 경우가 많다고 가이드는 표현합니다. 대신 피하고 싶은 패턴을 이름으로 적으라고 합니다. 가이드 예시에는 크림색 배경, 제목 속 기울인 강조 단어, 01·02 같은 번호 라벨, 알약 모양 버튼이 나옵니다. 단테는 이 영상의 그래픽에도 몇 개가 들어가 있다고 인정했습니다.
여덟 번째는 작은 글씨 읽기입니다. 앤트로픽은 Opus 5.5가 도구 없이도 차트나 스크린샷을 Opus 5보다 훨씬 정확하게 읽는다고 하며, 촘촘한 차트에서는 가장 낮은 effort의 5.5가 가장 높은 effort의 Opus 5보다 나았다고 합니다. 그러니 예전에 붙여 둔 보조 장치가 아직 필요한지 다시 테스트해 볼 만합니다. 기술 도면처럼 빽빽한 입력에는 여전히 고해상도 이미지가 도움이 되고, 이미지를 자르고 확대하는 도구를 주면 더 좋습니다. 단테는 "안 읽히면 추측하지 말고 안 읽힌다고 말해 달라"는 문장을 덧붙이는 것도 권했습니다.
정리
- 채팅 사용자라면 effort 확인, "신중하게" 대신 원하는 결과 적기, 요청과 붙여 넣은 글 구분, 구체적인 디자인 주문 네 가지를 바로 적용할 수 있습니다.
- Opus 5.5의 기본 effort는 medium이며, high나 max는 효과를 확인한 작업에만 쓰는 것이 권장됩니다.
- 에이전트나 앱을 만든다면 맥락 탐색 문장, 진행 업데이트 표시, 완료 체크리스트, 이미지 확대 도구를 챙겨야 합니다.
- 말로만 끝난 턴은 완료가 아니라 보고로 보고, 남은 항목을 구체적으로 짚어 이어가게 합니다.
- 여덟 가지를 한 프롬프트에 다 넣을 필요는 없고, 지금 작업에 맞는 하나를 골라 전후를 비교해 보는 것이 좋습니다.