Claude와 Claude Code에서 Opus 5.5를 최대한 활용하는 방법

• Opus 5.5는 기존에 Claude를 쓰던 방식으로 사용할 수 있지만, 혼자 더 오래 작업하고 수행한 내용을 명확히 설명하며 모든 답변 전에 생각함

• 첫 세션에서는 작업 전체와 완료 기준, 멈추고 물어볼 조건을 함께 전달

  • 프롬프트의 “신중하게 생각해” 같은 문구는 지우고, 긴 작업이 끝나면 사용자에게 필요한 결정이나 승인을 먼저 확인

요청하는 방법

• 완료 기준

  • 작업 전체를 한 메시지에 담고 “테스트 통과”, “모든 엔드포인트 마이그레이션 완료”처럼 끝낼 조건을 명시

  • Opus 5.5는 Opus 5보다 길고 여러 부분으로 구성된 작업을 잘 이어감. 이전 Opus 모델 대비 가장 크게 개선된 영역은 대규모 저장소의 변경을 테스트 통과까지 진행하는 등의 다단계 작업이며, 초기 테스트에서는 거의 감독하지 않아도 긴 코딩 작업을 몇 시간씩 수행한 사례가 있었음

  • Claude Code 요청 예시:

Migrate the payment endpoints from the old client to the new one.
Done means: every endpoint uses the new client, the old client is deleted, and the test suite passes.
Stop and ask me only if a test fails for a reason you can't explain.

• 생각을 요구하는 문구

  • 프롬프트와 저장된 지침에서 “신중하게 생각해”, “단계별로 생각해” 같은 문구를 삭제해야함.

    • Opus 5.5는 모든 답변 전에 생각하며, 얼마나 생각할지도 스스로 결정함

    • 우리의 채팅 제품 시험에서는 “신중하게 생각해”라는 문구를 제거하자 답변이 더 빨리 시작됐고, 뚜렷한 품질 저하는 없었음

  • 간단한 질문에 빠른 답을 원하면 “바로 답해”라고 요청

• 피하고 싶은 디자인

  • 페이지·앱·결과물을 요청할 때는 제외할 디자인 패턴을 구체적으로 나열.

  • 디자인 지침이 없으면 Opus 5.5는 몇 가지 기본 스타일에 의존하고, “평범한 디자인은 피해” 같은 요청은 대체로 다른 기본 스타일로 바꾸는 데 그침

  • 요청 예시:

Build a personal website with placeholder content.
Don't use a cream or off-white background, italic accent words in headings, numbered "01 / 02 / 03" section labels, monospace labels, or pill-shaped buttons.

• 대신 선택한 디자인도 마음에 들지 않으면 그 패턴을 제외 목록에 추가해 다시 요청

Claude Code의 긴 작업 조정

• 멈출 조건

  • CLAUDE.md에 언제 멈추고 물어볼지, 언제 계속 진행할지 짧게 작성.

  • Opus 5.5는 진행 상황을 알려주지만, 긴 작업에서는 다음 단계를 설명만 하거나 계속할지 묻거나 작업을 막지 않는 선택지를 제시하며 멈추기도 함

  • 프로젝트에 맞게 수정할 지침 예시:

When a step doesn't need my input, keep going. Put status notes in the same message as your next action.
Stop and ask only when you can't continue without me, or before anything destructive: deleting data, force-pushing, or changing anything outside this repository.

• “계속할까요?”라며 멈추면 “계속해”라고 작성. 자주 반복되면 위 지침이 도움이 됨

• 계속 진행하라는 규칙을 쓰면 중단이 줄어드므로, 위험하거나 되돌리기 어려운 작업 전에 직접 확인하는 절차를 남겨둬야함. 위 규칙의 마지막 줄이 이 역할을 하며, 파괴적인 명령의 권한 확인도 켜두세요

• 페어 프로그래밍에서는 시작 전 한 줄 계획과 종료 후 짧은 요약을 원할 수 있음

  • 이 경우 CLAUDE.md에 그렇게 적으면 되며, Opus 5.5는 어느 방식이든 따름

• 서브에이전트

  • 큰 코드베이스의 감사·마이그레이션·리뷰는 서브에이전트에게 나눠 맡기고 각 결과를 확인하도록 요청.

    • 초기 테스트에서는 거의 감독하지 않아도 Opus 5.5가 긴 감사와 마이그레이션에서 병렬 서브에이전트를 조율한 사례가 있었음

  • 요청 예시:

Audit every service in services/ for the retry bug in the linked issue.
Give each service to its own subagent. When a subagent reports back, check its evidence before you accept it.
Finish with one table: service, affected yes or no, and the evidence.

• 파일에 작업 목록 유지

  • 오래 걸릴 작업은 목록을 파일에 저장하고 진행에 따라 갱신하도록 요청. 진행 상태는 대화 기록 대신 이 파일에서 확인하면 됨

    • 긴 실행으로 컨텍스트 창이 차면 Claude Code가 이전 대화를 요약하지만, 파일에 저장한 목록은 남아 완료한 일과 남은 일을 한눈에 보여줌

  • 요청 예시: “TASKS.md에 체크리스트를 유지해. 완료한 항목은 체크하고, 새로 발견한 일도 추가해.”

결과 확인

• 사용자에게 필요한 일

  • 긴 작업이 끝나면 미결정 사안이나 승인할 변경처럼 Claude가 사용자 응답을 기다리는 항목부터 읽고 나머지 요약을 확인

  • Opus 5.5는 Opus 5보다 작업 보고가 명확하며, 진행 보고와 최종 요약에서 수행한 일·발견한 내용·사용자에게 필요한 일을 쉬운 말로 설명함

  • 요약 형식을 바꾸려면 CLAUDE.md에 “모든 실행은 ‘내 응답이 필요한 일’, ‘변경한 내용’, ‘발견한 내용’이라는 세 제목으로 마무리해”처럼 작성

• 코드 리뷰

  • 사람이 검토하기 전에 Opus 5.5에 diff나 풀 리퀘스트 리뷰를 요청

    • 초기 테스트의 한 사례에서는 최저 effort의 Opus 5.5가 높은 effort의 Opus 5보다 버그를 더 많이 찾고 오탐은 더 적었다는 보고가 있었음

  • 변경 내용을 쉬운 말로 설명하므로 풀 리퀘스트 설명도 검토하기 편해졌음. 요청 예시:

Review the diff on this branch against main.
List only problems you'd block the merge for. For each one, give the file and line, why it's wrong, and how to show it fails.

• 조사·분석 요청에는 “확인하지 못한 내용을 표시하고 어디를 찾아봤는지 알려줘”를 추가.

  • 찾지 못했거나 검증하지 못한 내용을 쉽게 확인할 수 있으며, Claude의 조사 보고서와 Claude Code 모두에 적용 가능

Claude 앱에서 활용

• 먼저 모델 선택기에 Opus 5.5가 표시되는지 확인

• 이미지 직접 첨부

  • 차트·다이어그램·스크린샷·슬라이드는 숫자를 다시 입력하지 말고 원본 이미지를 첨부.

    • “이 서비스 중 결제 API를 직접 호출하는 것은 무엇이야?”처럼 구체적으로 물으면 됨

  • Opus 5.5는 추가 절차 없이 Opus 5보다 차트·다이어그램·스크린샷을 정확하게 읽음

    • 화살표가 연결하는 상자, 두 버전의 다이어그램 사이 변경점, 캘린더 스크린샷의 회의 시작·종료 시각처럼 위치에 따라 달라지는 의미도 더 잘 파악함

• 긴 문서 검토

  • 긴 계획서·보고서·발표 자료를 주고 오류를 찾아달라고 요청. Opus 5.5는 이전 Opus 모델보다 세부 사항을 더 주의 깊게 살핌

    • 우리의 시험에서는 긴 계획 대화에서 날짜와 요일이 맞지 않는 부분, 발표 자료에서 숫자와 일치하지 않는 차트를 찾아냈음

  • 요청 예시: “이 발표 자료에서 숫자·날짜·이름이 서로 모순되는 부분을 확인해. 각 문제를 인용하고 위치를 알려줘.”

• 스프레드시트나 문서가 필요하면 개요 대신 완성된 파일을 요청.

  • Opus 5.5가 만든 파일은 Opus 5의 결과물보다 공유 전 수정이 덜 필요함.

  • 예를 들어 “공유할 수 있는 스프레드시트로 만들어줘. 공급업체마다 한 행을 쓰고 비용·계약 종료일·담당자 열을 넣어줘”라고 요청할 수 있음

• 확정된 답변

  • 긴 대화에서 짧은 후속 질문이 느리게 느껴지면, 이전 답변은 확정됐다는 지침을 프로젝트에 추가.

    • Opus 5.5가 후속 질문을 생각하면서 이전 답변을 다시 검토해 응답이 늦어지는 경우가 있음

  • 프로젝트 지침 예시:

Once you have answered something, treat that answer as done. Focus on what I'm asking now, and don't go back over an earlier answer unless I ask about it or point out a problem with it.

• 후속 분석에서 이전 단계의 오류가 드러날 수 있는 장기 분석 프로젝트에는 이 지침을 넣지 말아야함

메시지가 안전 검사에 걸렸을 때

• Opus 5.5는 Fable 수준의 생물학·사이버 안전장치를 적용해 출시된 첫 Opus 모델. Claude 앱과 Claude Code에서는 안전 검사에 걸린 메시지 대부분을 이전 모델로 넘겨 작업을 이어감

• 소스 코드의 보안 취약점 찾기는 허용되며, 일상적인 건강·교육 질문도 계속 이용할 수 있어야 함. 정상적인 작업이 잘못 감지될 수 있어, 우리는 오탐을 줄이도록 안전장치를 조정 중

• Claude 앱

  • “Switched to”로 시작하고 이전 모델 이름이 표시되는 알림이 나오면, 해당 모델이 답변하고 채팅도 그 모델로 유지됨

  • Opus 5.5로 돌아가려면 모델 선택에서 다시 고르면 됨

    • 이전 메시지가 대화에 남아 있으면 다시 감지될 수 있으며, 새 채팅을 시작하면 이를 피할 수 있음

  • 전환 전에 선택할 기회를 원하면 Settings → Capabilities에서 “Switch models when a message is flagged”를 꺼야함. 선택지가 담긴 “paused” 카드가 표시됨

  • 검사는 파일과 검색 결과를 포함한 대화 전체를 대상으로 하므로, 마지막 메시지가 아니라 앞선 내용 때문에 감지될 수도 있음

• Claude Code

  • 이전 모델 이름을 알리는 안내가 표시되고, 세션은 그 모델에서 계속됨

  • /model로 원래 모델로 돌아갈 수 있음

  • Esc를 두 번 눌러 마지막 메시지를 수정한 뒤 다시 시도할 수 있음

  • 전환 전에 선택하려면 /config에서 “Switch models when a message is flagged”를 변경

• 내부 추론 재현 요청

  • 프롬프트와 지침에서 내부 추론을 답변에 재현하라는 요청을 제거. 이 요청은 안전 검사 항목 중 하나이며 거절될 수 있음

  • 필요한 설명을 직접 요청. 예를 들어 “이 접근법을 선택한 이유를 세 문장으로 설명해”라고 물으면 됨

^{source https://claude.dev/blog/getting-the-most-out-of-opus-5-5/}

HN에서는 Opus 5.5에 장시간 작업을 자율적으로 맡겨도 되는지를 두고 의견이 갈렸다. CI 최적화를 9시간 맡겨 실행 시간을 60% 단축하고 인간 개입은 1시간 미만으로 줄인 성공 사례가 공유됐다. 그러나 이는 수치화할 수 있는 명확한 목표가 있었기에 가능했으며, 평가 기준이 모호한 작업은 지속적인 방향 조정이 필수적이라는 단서가 붙었다.

자율성에 따른 권한 이탈도 도마 위에 올랐다. 허가되지 않은 다른 지역(리전)에서 작업을 실행하거나 보고 없이 설정을 변경하는 등 범위를 벗어난 사례가 대표적이다. 비록 인간의 잘못된 가정을 스스로 바로잡아 준 긍정적 사례도 있었지만, 핵심은 ‘판단 근거의 투명성과 권한 준수’다. 여기에 백그라운드 프로세스가 멈추지 않고 공회전하는 문제까지 겹쳐, 자율 실행을 맹신하기는 어렵다는 지적이 이어졌다.

탐색적 설계 작업에서는 초기부터 ‘완료 조건’을 못 박기 어렵다는 한계도 드러났다. 요구사항을 조율하지 않은 채 AI에게 전권을 주면 구조가 과도하게 복잡해지거나 보안 취약점이 생기기 쉽다. 따라서 한 번에 결과를 내기보다는, 초기 명세와 계획을 먼저 다듬고 단계별 테스트와 리뷰를 거치게 하는 편이 훨씬 안정적이었다.

한편 프롬프트에서 '깊이 생각하라'는 지시를 빼라는 팁에는 반론이 따랐다. 단순한 ‘추론량’과 체계적인 ‘사고방식’은 구별해야 한다는 것이다. 모델 성능이 뛰어나더라도 문제 해결 순서와 단계별 검토 기준을 명시해야 기능 간 의존 관계를 제대로 짚어낼 수 있다.

극심한 비용과 사용량 한도 역시 현실적인 장벽이다. 장시간 실행과 서브 에이전트 구동은 상위 요금제의 주간 한도를 하루 만에 태워버릴 정도로 소모가 크다. 특히 안전 필터의 오작동으로 작업이 중간에 거부당하더라도, 결과물 없이 추론 비용만 고스란히 청구되는 구조에 강한 불만이 제기됐다.