Claude Opus 5.5에 맞는 prompt(모델에 주는 지시문)는 생각을 더 오래 하라고 요구하는 문장보다, 무엇을 확인하고 언제 일을 마쳤다고 판단할지를 명확히 하는 데 초점을 맞춥니다. Anthropic의 가이드에서 달라진 기본 설정과 여덟 가지 요령을 보면, 모든 지시를 한꺼번에 추가하기보다 작업에 필요한 것만 고르는 편이 적절해 보입니다.
먼저 덜어낼 것: 높은 설정과 막연한 사고 지시
1. 기본 Medium에서 시작하고 작업별로 비교합니다
effort(답변 전 모델이 내부적으로 들이는 사고량을 조절하는 설정)의 기본값은 Claude Opus 5에서 High였지만 Claude Opus 5.5에서는 Medium입니다. Anthropic에 따르면 여러 코딩·지식 평가에서 새 모델의 Medium은 이전 모델의 High와 비슷하거나 더 나은 품질을 더 낮은 비용으로 냈습니다. 두 버전의 High를 같은 설정으로 간주해 이전 값을 그대로 옮기면 응답이 길어지고 출력 token(모델이 처리하거나 생성하는 텍스트 단위) 비용이 불필요하게 늘 수 있습니다.
새 작업은 Medium으로 평가를 시작하고, 실제로 쓰는 업무에서 High가 측정 가능한 품질 개선을 보일 때 높이는 방식이 적합합니다. 더 높은 설정도 비교 결과가 뒷받침하는 작업에 한정합니다.
2. ‘신중하게 생각하라’ 대신 결과 조건을 씁니다
system prompt(대화 전체에 적용되는 기본 지시문)에 넣어 둔 ‘답하기 전에 깊이 생각하라’ 같은 문장은 재검토할 만합니다. 사고량은 effort로 조절되며, Anthropic이 전한 내부 시험에서는 이런 막연한 문장을 제거하자 첫 출력이 더 빨라졌고 품질 저하는 나타나지 않았습니다. 필요한 답의 형식이나 확인할 항목을 직접 쓰는 편이 더 구체적입니다.
짧은 후속 질문에도 이전 답을 다시 검토해 시간이 늘어나는 경우에는, 사용자가 이전 답을 문제 삼지 않는 한 현재 질문에 집중하라고 지정할 수 있습니다. 다만 새 근거에 따라 앞선 결론을 고쳐야 하는 조사 업무에는 이 규칙을 기계적으로 적용하지 않는 편이 좋습니다.
▲ 사고량 설정의 비교
실행 전에 확인할 것: 자료의 범위와 지시의 경계
3. 여러 앱을 쓰는 작업은 먼저 관련 자료를 찾게 합니다
agent(도구를 사용해 여러 단계를 수행하는 자동 작업 방식)가 메일, 문서, 스프레드시트와 기록에 접근할 수 있어도 Claude Opus 5.5는 먼저 찾은 파일만 보고 빠르게 실행에 들어갈 수 있습니다. 기획서에는 마감일이 월요일로 적혀 있지만 나중에 온 메일에서 금요일로 바뀐 경우가 그 예입니다. 여러 앱을 쓰는 자동화 시험에서는 실행 전 자료 탐색을 요구했을 때 작업 성공률이 개선됐습니다.
여러 곳에 최신 정보가 흩어진 업무라면, 행동에 앞서 관련 앱·파일·시트 항목을 찾아 열어 보고 반영하라고 지시합니다. 도구 호출과 token 사용은 조금 늘 수 있으므로 모든 질문에 붙일 문장은 아닙니다. 자료에 접근할 수 있는지도 확인하고, 외부 자료를 검증 없이 지시로 받아들이지 않도록 해야 합니다.
4. 붙여 넣은 내용은 사용자 지시와 분리합니다
메일이나 웹 문서를 그대로 붙여 넣으면 사용자의 요청과 외부 자료 속 문장이 뒤섞일 수 있습니다. 이렇게 되면 prompt injection(외부 자료에 숨은 지시로 모델의 행동을 바꾸도록 유도하는 방식)에 취약해지고, 모델이 작업 범위를 잘못 이해할 수도 있습니다. Claude Opus 5.5는 직접적인 prompt injection에 대한 저항성이 개선됐지만, 경계 표시는 여전히 중요합니다.
일반 채팅에서는 할 일을 먼저 쓰고 참고 자료를 그 아래에 뚜렷이 구분해 놓습니다. 앱을 개발한다면 외부 텍스트의 시작과 끝을 일치하는 식별자로 감싸 사용자 지시와 구별할 수 있습니다. 핵심은 자료를 읽되 자료 안의 문장을 새로운 작업 명령으로 취급하지 않게 하는 것입니다.
▲ 자료 확인과 지시 경계
자동 작업에서는 보이는 상태와 실제 완료를 구별합니다
5. 조용해진 앱이라면 진행 표시부터 확인합니다
Claude Opus 5.5는 긴 작업에서 도구 사용 사이에 진행 상황을 알리는 업데이트를 낼 수 있습니다. 사용자 화면이 이를 표시하지 않으면 작업이 멈춘 것처럼 보일 수 있습니다. 이 경우 모델에게 말을 더 자주 하라고 요구하기보다 앱이 업데이트를 받아 표시하는지 확인하는 것이 먼저입니다.
사용자 입장에서는 문서 분석을 마친 뒤, 초안을 만들기 전처럼 의미 있는 단계에만 진행 상황을 알리도록 요청할 수 있습니다. 앱 개발자는 진행 업데이트가 화면까지 전달되는지 점검해야 합니다.
6. 응답 종료가 아니라 산출물 완성을 기준으로 삼습니다
agent가 중간 상황을 정중히 요약하며 한 차례 응답을 끝내도 전체 업무가 끝난 것은 아닐 수 있습니다. 보고서, 출처 목록, 요약이 필요한 작업이라면 세 항목을 모두 마쳐야 완료라고 정의하고, 멈추기 전에 빠진 항목을 확인하게 합니다. 단순히 목록을 적어 두는 것만으로 실행이 보장되지는 않습니다.
해결할 수 없는 장애를 만나거나 사람의 승인이 필요할 때만 멈춰서 알리도록 하고, 그 외에는 진행 상태를 전하면서 다음 도구 사용을 같은 차례에 이어가게 지시합니다. 결과에서 요약처럼 빠진 부분을 발견했다면 해당 항목을 완성하거나 막힌 이유를 설명하라고 구체적으로 요청합니다.
결과물의 형태는 작업에 맞춰 구체화합니다
7. 웹 디자인은 취향 평가보다 시각 조건을 줍니다
웹 화면을 만들 때 ‘덜 평범하게’ 같은 요청은 기본 디자인을 다른 기본 디자인으로 바꾸는 데 그칠 수 있습니다. 이는 새 모델만의 특성이라기보다 구체적 지시가 필요한 디자인 작업의 문제로 보는 편이 적절합니다.
예를 들어 흰 배경, 큰 검은색 제목, 모서리가 각진 버튼, 넉넉한 여백처럼 색·글꼴·간격·버튼 형태를 지정합니다. 참고 화면이나 디자인 기준이 있다면 함께 제공하고, 기본 구조를 먼저 만든 다음 스타일을 단계적으로 다듬을 수도 있습니다.
8. 빽빽한 그림은 확대해서 읽게 합니다
Claude Opus 5.5는 Claude Opus 5보다 차트, 도식, 기술 화면을 읽는 기본 정확도가 높아졌지만 작은 글씨나 조밀한 표를 낮은 해상도로 주면 잘못 읽을 수 있습니다. 복잡한 차트라면 고해상도 이미지를 주거나 필요한 부분을 잘라 확대해 확인하게 합니다.
특히 구석의 작은 수치를 물을 때는 해당 부분을 먼저 확인하고, 읽을 수 없다면 추측하지 말고 읽을 수 없다고 밝히도록 지시합니다. 이미지를 자를 수 있는 도구가 연결된 작업이라면 필요한 영역을 직접 살펴보게 할 수 있습니다.
정리: 지금 쓰는 작업에서 필요한 것부터 바꿉니다
먼저 기존 지시문에서 High 설정과 막연한 사고 지시가 남아 있는지 확인하고, 실제 업무 결과를 Medium과 비교해 봅니다. 여러 앱을 쓰는 자동 작업이라면 자료 확인 범위와 완료 조건을, 디자인이나 차트 작업이라면 필요한 시각 조건을 추가합니다. 여덟 가지를 하나의 긴 prompt에 모두 넣기보다, 현재 겪는 문제에 맞는 지시만 선택합니다.