Getting the most out of Opus 5.5 in Claude and Claude Code

3줄 요약

1. Addy Osmani가 2026년 9월 22일 claude.dev 블로그에 올린 Opus 5.5 사용 가이드다. 글은 Opus 5.5가 이전 모델과 달라진 점을 세 가지로 정리한다. Opus 5.5는 혼자서 더 오래 일하고, 자기가 무엇을 했는지 평이한 말로 보고하며, 답하기 전에 언제나 생각한다.
2. 요청할 때는 작업 전체와 완료 조건을 한 메시지에 함께 적는 편이 좋고, “신중하게 생각하라” 같은 문장은 이제 필요 없다. Claude Code에서 긴 작업을 맡길 때는 멈출 조건을 CLAUDE.md에 적고, 규모가 큰 코드 감사는 서브에이전트에 분배하고, 작업 목록은 파일로 관리하라고 권한다.
3. Opus 5.5는 생물 분야와 사이버 분야에서 Fable 수준의 안전장치를 갖추고 출시된 첫 Opus 모델이다. 이 때문에 플래그가 걸린 메시지는 이전 모델로 전환되는데, 글은 원래 모델로 되돌리는 방법까지 함께 안내한다.

가이드의 구성

글은 Claude 앱과 Claude Code에서 Opus 5.5에게 요청하는 법, 긴 작업을 운용하는 법, 결과를 확인하는 법을 여섯 절로 정리한다. 항목마다 “무엇을 할 것인가”, “Opus 5.5에서 왜 중요한가”, “어떻게 할 것인가"를 차례로 설명하고, 대부분의 항목에 그대로 가져다 쓸 수 있는 예시 프롬프트를 붙였다.

Opus 5.5를 처음 쓰는 세션이라면 세 가지부터 해 볼 만하다. 작업을 통째로 맡기되, “완료"가 어떤 상태인지, 그리고 언제 멈추고 물어야 하는지를 함께 말해 준다. “신중하게 생각하라” 같은 문장은 지운다. 긴 작업이 끝나면 Claude가 사용자의 답을 기다리는 부분부터 읽는다.

요청하는 법

완료 조건을 말하고 맡긴다

작업 전체를 한 메시지에 적는다. “테스트가 통과한다"나 “모든 엔드포인트를 이전했다"처럼 끝나는 조건을 명시한 뒤에는 모델이 알아서 일하도록 둔다.

Opus 5.5는 여러 부분으로 이루어진 긴 작업을 이전 모델인 Opus 5보다 끈기 있게 이어 간다. 이전 Opus 모델들과 비교해 가장 크게 개선된 영역도 다단계 작업이다. 큰 리포지토리에 변경을 끝까지 적용하고 테스트가 통과할 때까지 작업을 이어 가는 일이 대표적인 예다. 초기 테스터들은 긴 코딩 작업을 거의 감독하지 않은 채 몇 시간씩 맡겼다고 한다. 완료 조건이 분명하면 모델은 언제 일이 끝났는지 스스로 판단할 수 있다.

Claude Code용 예시로 글은 결제 엔드포인트를 이전하는 프롬프트를 제시했다.

결제 엔드포인트를 기존 클라이언트에서 새 클라이언트로 이전하라.
완료 조건: 모든 엔드포인트가 새 클라이언트를 쓰고, 기존 클라이언트는
삭제되었으며, 테스트 스위트가 통과한다.
원인을 설명할 수 없는 테스트 실패가 생겼을 때만 멈추고 물어라.

“깊이 생각하라"는 지운다

프롬프트와 저장해 둔 지시문에서 “신중하게 생각하라”, “단계별로 생각하라” 같은 문장을 뺀다. Opus 5.5는 답하기 전에 항상 생각하고, 얼마나 생각할지도 스스로 정한다. 채팅 제품에서 진행한 자체 테스트에서는 “신중하게 생각하라"라는 문장을 지우자 답변이 더 빨리 시작됐다. 그렇다고 품질이 눈에 띄게 떨어지지도 않았다.

간단한 질문에 빨리 답을 받고 싶을 때는 “바로 답하라"고 적는다. Claude Code에서 얼마나 생각할지를 조절하려면 effort 설정을 바꾼다.

작업 중에 지시를 보탠다

작업이 진행되는 도중에 빠뜨린 조건이 떠오를 때는 후속 메시지로 알려 준다. 작업 시간이 길어진 만큼, 처음부터 다시 시작하면 비용도 그만큼 커진다. Claude Code에서는 Claude가 일하는 동안 메시지를 입력하고 Enter를 누른다. 예를 들어 “기존 엔드포인트 이름도 별칭으로 남겨 두라"고 입력하면 된다.

디자인 작업에는 빼고 싶은 스타일을 하나씩 지목한다

페이지나 앱, 아티팩트를 요청할 때는 빼고 싶은 디자인 습관을 목록으로 적는다. 디자인 방향을 지시하지 않으면 Opus 5.5는 몇 가지 기본 스타일을 쓴다. “흔한 느낌은 피하라” 같은 일반적인 지시를 주면, 대개 기본 스타일 하나가 다른 기본 스타일로 바뀔 뿐이다. 그보다는 피할 패턴을 구체적으로 적은 목록이 훨씬 효과가 좋다. 글의 예시 프롬프트는 다섯 가지 패턴을 금지한다.

플레이스홀더 콘텐츠로 개인 웹사이트를 만들어라.
크림색이나 오프화이트 배경, 제목 속 이탤릭 강조 단어,
"01 / 02 / 03" 같은 번호식 섹션 라벨, 고정폭 글꼴 라벨,
알약 모양 버튼은 쓰지 마라.

결과가 나오면 모델이 금지 항목 대신 무엇을 골랐는지 확인한다. 그것도 마음에 들지 않으면 목록에 추가하고 다시 요청한다.

Claude Code에서 긴 작업 운용하기

어디서 멈출지 알려 준다

Opus 5.5는 일하는 동안 진행 상황을 자주 알린다. 그 때문에 긴 작업에서는 일을 계속하는 대신 보고하려고 멈추는 경우가 있다. 이런 멈춤에는 세 가지 유형이 있다. 첫째는 다음 단계를 말해 놓고 실행하지는 않는 요약이다. 둘째는 계속할지 묻는 제안이고, 셋째는 답하지 않아도 작업에 지장이 없는 선택지 목록이다. 모델은 이런 멈춤을 명시한 지시를 따르므로, 사용자가 원하는 멈춤도 함께 적어 두는 편이 좋다. 아래 규칙을 CLAUDE.md에 넣고 프로젝트 사정에 맞게 고쳐 쓴다.

내 입력이 필요 없는 단계라면 계속 진행하라. 상태 메모는 다음 행동을
알리는 메시지에 함께 적어라.
나 없이는 계속할 수 없을 때, 또는 파괴적인 작업을 하기 전에만 멈추고
물어라. 데이터 삭제, 강제 푸시, 이 리포지토리 밖의 무엇이든 바꾸는 일이
파괴적인 작업이다.

“계속할까요?“라고 물으며 멈췄을 때는 “계속"이라고 답한다. 그런 일이 잦다면 위 규칙을 넣어 둘 만하다.

계속하라는 규칙을 넣으면 멈춤이 줄어드는 만큼, 위험하거나 되돌리기 어려운 작업 전에는 사람이 직접 확인하는 절차를 유지해야 한다고 글은 강조한다. 위 규칙의 마지막 줄이 그 역할을 한다. 파괴적인 명령에 대한 권한 확인 프롬프트도 계속 켜 두어야 한다.

페어 프로그래밍을 할 때는 반대 방식을 원할 수도 있다. 시작하기 전에 한 줄짜리 계획을 받고, 끝난 뒤에 짧은 요약을 받는 식이다. 그럴 때는 CLAUDE.md에 그 방식을 적으면 되고, Opus 5.5는 어느 규칙이든 따른다.

큰 작업은 서브에이전트에 분배하게 한다

큰 코드베이스를 대상으로 코드 감사, 마이그레이션, 리뷰를 할 때는 Opus 5.5에게 작업을 서브에이전트에 분배하고 각 결과를 검증하라고 요청한다. 초기 테스터들은 긴 감사와 마이그레이션 작업에서 Opus 5.5가 병렬 서브에이전트를 거의 감독 없이 조율하게 했다고 한다.

services/ 아래의 모든 서비스를 대상으로, 링크한 이슈의 재시도 버그가
있는지 점검하라. 서비스마다 서브에이전트를 하나씩 배정하라.
서브에이전트가 보고하면 받아들이기 전에 그 근거를 확인하라.
마지막에는 서비스, 영향 여부, 근거의 세 열로 된 표 하나로 정리하라.

작업 목록은 파일로 관리한다

시간이 걸리는 작업이라면 Opus 5.5에게 작업 목록을 파일에 적고 진행하면서 갱신하라고 요청한다. 사용자는 스크롤백 대신 그 파일을 읽어서 작업이 어디까지 진행됐는지 확인한다.

작업이 길어지면 컨텍스트 윈도우가 가득 차고, 그러면 Claude Code는 오래된 턴을 요약한다. 파일에 적은 목록은 Claude Code가 이전 턴을 요약한 뒤에도 그대로 남고, 끝난 일과 남은 일을 한눈에 보여 준다. 지시는 “TASKS.md에 체크리스트를 유지하라. 항목이 끝날 때마다 체크하고, 새로 발견한 일은 추가하라” 정도면 충분하다.

결과 확인하기

Claude가 기다리는 항목부터 읽는다

긴 작업이 끝나면 Claude가 사용자의 응답을 기다리는 항목부터 찾는다. 결정을 미뤄 둔 문제나 승인을 받아야 하는 변경이 그런 항목이다. 요약의 나머지는 그다음에 읽는다.

Opus 5.5의 작업 보고는 Opus 5보다 명확해졌다. 중간 보고와 최종 요약에서 무엇을 했고, 무엇을 발견했으며, 사용자에게 무엇을 요청하는지를 평이한 말로 적는다. 요약 형식을 바꾸고 싶으면 CLAUDE.md에 원하는 형식을 적는다. 모든 작업을 ‘내가 풀어야 할 것’, ‘변경 사항’, ‘발견 사항’이라는 세 제목으로 끝내라는 규칙을 넣을 수도 있다.

코드 리뷰를 먼저 맡긴다

사람이 보기 전에 diff나 풀 리퀘스트를 Opus 5.5에게 먼저 리뷰하게 한다. 초기 테스터 한 명이 비교해 보니, effort를 가장 낮게 설정한 Opus 5.5가 effort를 높게 설정한 Opus 5보다 버그를 더 많이 찾아냈고 오탐은 적었다. Opus 5.5는 자기가 만든 변경도 평이하게 설명하기 때문에, 이 모델이 쓴 풀 리퀘스트 설명은 검토하기가 더 쉽다.

이 브랜치의 diff를 main과 비교해 리뷰하라.
머지를 막아야 할 문제만 나열하라. 문제마다 파일과 줄 번호,
무엇이 잘못됐는지, 실패를 어떻게 재현할 수 있는지를 적어라.

확인하지 못한 것을 표시하게 한다

조사와 분석 작업에서는 찾지 못했거나 검증하지 못한 것을 밝히게 한다. “이건 찾지 못했다"는 문장도 읽을 가치가 있는 정보이고, 미리 요청해 두면 보고서에서 그 부분이 쉽게 눈에 띈다. 요청에 “확인하지 못한 것은 모두 표시하고, 어디를 찾아봤는지 적어라"를 덧붙이면 된다. 이 문구는 Claude의 리서치 보고서에도, Claude Code에도 똑같이 쓸 수 있다.

Claude 앱에서

앱에서는 먼저 모델 선택기에 Opus 5.5가 표시되는지 확인한다.

차트와 스크린샷은 이미지 그대로 첨부한다

차트, 다이어그램, 스크린샷, 슬라이드는 숫자를 다시 타이핑하지 말고 파일 그대로 첨부한다. Opus 5.5는 Opus 5보다 차트, 다이어그램, 스크린샷을 정확하게 읽고, 그러기 위한 별도 절차도 필요 없다. 이미지 속 배치에 따라 의미가 정해지는 정보도 더 잘 읽는다. 예를 들어 화살표가 어느 상자와 어느 상자를 잇는지 읽어 내고, 두 버전의 다이어그램을 비교해 무엇이 바뀌었는지 찾고, 캘린더 스크린샷에서 회의가 언제 시작해 언제 끝나는지 알아낸다.

이미지를 첨부한 뒤에는 “이 서비스들 가운데 과금 API를 직접 호출하는 것은 어느 것인가?“처럼 구체적으로 묻는다.

긴 문서의 오류를 찾게 한다

긴 계획서나 보고서, 발표 자료를 주고 실수를 찾아 달라고 요청한다. Opus 5.5는 이전 Opus 모델들보다 세부 사항에 더 주의를 기울인다. 자체 테스트에서는 긴 계획 스레드에서 요일이 맞지 않는 날짜를 찾아냈고, 발표 자료에서는 본문 숫자와 맞지 않는 차트를 찾아냈다. 요청은 “이 발표 자료에서 숫자, 날짜, 이름 가운데 서로 모순되는 것을 찾아라. 문제마다 해당 부분을 인용하고 어디에 있는지 말하라"처럼 쓴다.

완성된 파일을 요청한다

스프레드시트나 문서가 필요하면 개요 대신 파일 자체를 요청한다. Opus 5.5가 만든 스프레드시트와 문서는 공유하기 전에 손봐야 할 부분이 Opus 5 때보다 적다. 공급업체 목록이 필요하다면 “이걸 공유할 수 있는 스프레드시트로 만들어라. 공급업체마다 한 행씩 만들고, 열은 비용, 계약 종료일, 담당자로 하라"라고 파일의 구성까지 정해서 요청한다.

프로젝트에서는 확정된 답을 명시한다

긴 채팅에서 후속 질문의 답이 느리게 느껴지면, 앞선 답은 확정된 것으로 간주하라는 지시를 프로젝트에 추가한다. Opus 5.5는 짧은 후속 질문을 생각하는 동안 앞서 한 답을 다시 검토하는 경우가 있고, 그래서 답이 늦어진다. 프로젝트 지시문에는 이런 문구를 넣는다.

한 번 답한 내용은 끝난 것으로 다루어라. 지금 묻는 것에 집중하고,
내가 그 답에 대해 다시 묻거나 문제를 지적하지 않는 한 앞선 답을
다시 검토하지 마라.

긴 분석을 하는 프로젝트에는 이 문구를 넣지 않는다. 나중 단계에서 앞 단계의 실수가 드러날 수 있기 때문이다.

메시지에 플래그가 걸렸을 때

Opus 5.5는 생물 분야와 사이버 분야에서 Fable 수준의 안전장치를 갖추고 출시된 첫 Opus 모델이다. Claude 앱과 Claude Code에서 플래그가 걸린 메시지는 대부분 이전 모델로 전환되고, 작업은 그 모델에서 계속된다. 글은 소스 코드의 보안 취약점을 찾는 일은 허용되며, 일상적인 건강 질문과 교육용 질문도 지금처럼 답을 받을 수 있어야 한다고 설명했다. 안전장치가 정상적인 작업에 플래그를 거는 경우도 있어서 Anthropic이 오탐을 줄이기 위해 조정하고 있다는 말도 덧붙였다.

Claude Code에서 플래그가 잘못 걸렸다고 판단되면 /feedback으로 알릴 수 있다. 한편 앱의 검사는 파일과 검색 결과를 포함한 대화 전체를 대상으로 한다. 따라서 플래그의 원인이 마지막 메시지가 아닌 앞선 내용일 수도 있다.

추론 과정을 답변에 재현하라고 요청하지 않는다

내부 추론을 답변에 재현하라는 요청은 프롬프트와 지시문에서 뺀다. 이런 요청은 거절될 수 있고, 플래그가 걸리는 범주 가운데 하나이기도 하다. 글은 필요한 것을 직접 요청하라고 권하면서 “이 방법을 고른 이유를 세 문장으로 설명하라"를 예로 들었다.

속도: fast mode

Claude Code에서 답변을 하나 읽고 나서 다음 메시지를 보내는 식으로 일한다면 fast mode가 적합하다. fast mode는 Opus 5.5 출시와 함께 리서치 프리뷰로 제공된다. 모델은 같고 텍스트가 더 빨리 출력된다. 쓰려면 추가 사용량(extra usage) 설정을 켜야 하고, 표준 모드보다 토큰당 비용을 더 낸다. /fast를 입력하면 켜진다.

긴 작업 전에 점검할 목록

글은 다음번 긴 작업을 시작하기 전에 확인할 체크리스트로 끝난다.

요청

• 작업 설명에 “완료"가 어떤 상태인지 적혀 있다
• 프롬프트와 저장된 지시문에 “깊이 생각하라” 같은 문장이 없다
• 디자인 요청에 빼야 할 스타일 목록이 있다
• 차트와 스크린샷은 다시 타이핑하지 않고 첨부했다

Claude Code의 긴 작업

• CLAUDE.md에 언제 멈추고 언제 계속할지, 그리고 파괴적인 작업 전에는 멈추라는 내용이 적혀 있다
• 파괴적인 명령에 대한 권한 확인 프롬프트가 켜져 있다
• 대규모 코드 감사와 마이그레이션은 서브에이전트에 분배했다
• 작업 목록을 파일로 관리한다

확인

• 보고서에서 “사용자에게 요청하는 것” 부분을 먼저 읽는다
• 사람이 리뷰하기 전에 모델의 리뷰를 먼저 거친다
• 조사 결과에 확인하지 못한 부분이 표시되어 있다

플래그

• 원래 모델로 되돌리는 방법(모델 선택기 또는 /model)을 안다
• “Switch models when a message is flagged” 설정을 원하는 대로 맞춰 두었다

막연한 금지보다 구체적인 목록

가이드에서 새로 추가하라는 지시는 모두 구체적인 이름을 요구한다. 완료 조건, 멈출 조건, 뺄 디자인 패턴, 요약의 세 제목이 그렇다. 반대로 지우라고 하는 것들은 이전 모델에서 효과를 보던 습관이다. “신중하게 생각하라"는 답을 늦추고, 추론 과정을 보여 달라는 요청은 이제 플래그 범주에 속한다.

내가 반갑게 읽은 대목은 디자인 절이다. 글은 자사 모델이 기본으로 쓰는 디자인 습관을 크림색 배경, 이탤릭 강조어, 번호식 섹션 라벨, 고정폭 라벨, 알약 버튼으로 하나하나 열거했다. “흔한 느낌은 피하라"는 기본값 하나를 다른 기본값으로 바꿀 뿐이라는 설명도 이 서재가 글쓰기에서 겪은 일과 같다. 나도 처음에는 막연히 AI 같은 표현을 피하라고만 지시했는데, 그런 지시로는 문장이 거의 바뀌지 않았다. 자주 쓰는 단어를 하나하나 적은 목록을 만든 뒤에야 문장이 달라졌고, 그 뒤로도 지운 단어 대신 어떤 표현이 새로 생기는지 계속 확인해야 했다. 가이드가 디자인 절 끝에 “모델이 대신 무엇을 골랐는지 보라"고 적은 것도 같은 경험에서 나온 조언일 것이다.

출처

Addy Osmani, “Getting the most out of Opus 5.5 in Claude and Claude Code”, claude.dev 블로그, 2026년 9월 22일. 검토: Molly Vorwerck.

원문: https://claude.dev/blog/getting-the-most-out-of-opus-5-5/

본문과 커버의 도판 4장은 원문에서 가져왔다.