Opus 5.5에게 일을 맡기는 법: 끝나는 조건부터 말하세요

Claude에게 코드 수정을 맡겼는데 다음에 할 일을 설명하고는 멈춰 버리면 사람이 계속 지시해야 합니다. 반대로 끝까지 진행하게 하자니 어디까지 바꿀지 걱정됩니다. 이 글은 Opus 5.5에게 작업을 맡길 때 완료 기준과 질문할 시점을 어떻게 알려 주면 좋은지 설명합니다. 예전에 쓰던 “차근차근 생각해 줘” 같은 문구를 정리하는 이유도 함께 살펴봅니다.

한눈에 보기

• 관련된 작업을 묶어 맡기되, 무엇을 마쳐야 완료인지 적어 주세요. 어떤 상황에서 멈추고 질문해야 하는지도 함께 정합니다.
• “think carefully” 류의 문장은 지우세요. Opus 5.5는 모든 답변 전에 알아서 생각합니다.
• 긴 작업에서는 프로젝트 지침 파일인 CLAUDE.md에 멈춤 규칙을 적고, 보조 AI인 서브에이전트에게 일부를 나눠 맡깁니다. 할 일 목록도 파일로 남깁니다.
• 끝나면 요약에서 “내 입력이 필요한 항목"부터 읽고, 메시지가 플래그되면 구형 모델로 넘어갈 수 있다는 점을 알아 두세요.

원문 소개

Addy Osmani가 쓴 claude.dev 블로그의 Playbooks 글이고 2026-09-22에 올라왔습니다. Claude 앱이나 Claude Code를 이미 쓰고 있고 새 모델에서 달라진 점만 빠르게 알고 싶은 분께 맞습니다.

1. 어떻게 부탁할 것인가

원문은 전체 작업과 완료 기준을 함께 전달하라고 권합니다. 예시는 결제 API를 호출하는 주소인 엔드포인트를 새 클라이언트로 옮기는 작업입니다. 여기서 클라이언트는 결제 API와 통신하는 코드입니다. 주소만 바꾸면 끝인지, 옛 코드도 지워야 하는지, 테스트까지 돌려야 하는지를 미리 적는 것입니다.

완료 기준은 엔드포인트 전환, 옛 클라이언트 제거, 테스트 스위트 통과 세 가지입니다. 테스트 스위트는 관련 동작을 확인하는 테스트 묶음입니다. 원인을 설명하지 못하는 테스트 실패가 나오면 멈춰서 물어보라는 조건도 붙입니다. 이 조건은 해당 예시의 지시이며 모든 작업에 그대로 적용할 규칙은 아닙니다.

원문에 따르면 Opus 5.5는 Opus 5보다 여러 단계로 된 작업을 오래 이어 가는 능력이 좋아졌습니다. 초기 테스터들은 몇 시간짜리 코딩 작업을 거의 손대지 않고 돌렸다고 합니다.

그림 1. 왼쪽은 맡길 작업, 가운데는 완료 기준, 오른쪽은 멈출 조건입니다. 결제 엔드포인트를 모두 옮기고 옛 클라이언트를 지운 뒤 테스트가 통과해야 완료입니다. 출처: 원문 .

다음으로 권하는 것은 “think carefully”, “think step by step” 같은 문장을 프롬프트와 저장해 둔 지침에서 지우는 것입니다. Opus 5.5는 답하기 전에 추론하고 얼마나 생각할지도 스스로 정한다고 합니다. 원문 저자의 채팅 테스트에서는 이 문장을 빼도 뚜렷한 품질 저하 없이 답변이 더 빨리 시작됐습니다. Claude Code의 effort는 작업에 얼마나 많은 계산과 검증을 할지 모델에게 알려 주는 설정입니다. 더 깊게 확인하게 하고 싶을 때는 이 설정을 조절합니다.

작업 도중 떠오른 지시는 Claude Code에서 그냥 입력하고 Enter를 누르면 실행 중에도 들어갑니다.

디자인 작업은 방향을 주지 않으면 몇 가지 기본 스타일로 돌아갑니다. “뻔한 느낌은 피해 줘” 정도로는 뻔한 스타일 하나를 또 다른 뻔한 스타일로 바꾸는 데 그칩니다. 크림색 배경, 제목의 이탤릭 강조어, “01 / 02 / 03” 번호 라벨처럼 피하고 싶은 패턴을 구체적으로 나열해야 잘 따릅니다.

2. Claude Code에서 긴 작업 관리하기

긴 작업 중에 다음 단계를 말만 하고 멈추거나 계속할지 묻는 일이 가끔 있다고 합니다. 이런 행동을 줄이려면 Claude Code가 프로젝트 지침으로 읽는 CLAUDE.md에 진행 규칙을 적습니다.

원문이 권하는 규칙은 둘입니다. 사람의 답이 필요 없는 단계는 이어서 진행하고 진행 상황을 보고할 때 다음 행동도 함께 적습니다. 멈추는 시점은 사람 없이는 진행할 수 없거나 데이터 삭제, 강제 푸시, 저장소 밖 변경처럼 위험한 작업을 앞둔 때입니다. 강제 푸시는 원격 저장소의 변경 이력을 덮어쓸 수 있는 명령입니다. 자동으로 계속하라는 지침을 넣더라도 이런 명령의 권한 확인은 켜 두라고 합니다.

큰 작업은 서브에이전트, 즉 일부 일을 나눠 맡는 보조 AI에게 분담할 수 있습니다. 여러 서비스에 같은 문제가 있는지 점검한다면 서비스별로 담당을 나누는 식입니다. 보고에는 문제가 있는지와 그 판단의 근거를 함께 적게 합니다. 근거를 확인한 뒤 서비스·해당 여부·근거를 한 표로 모으면 누락된 곳과 확인이 끝난 곳을 구분하기 쉽습니다.

그림 2. 서비스마다 보조 AI를 붙이고, 보고의 근거를 확인한 뒤 서비스·문제 해당 여부·근거를 한 표로 모읍니다. 출처: 원문 .

할 일 목록은 TASKS.md 같은 파일에 남기게 하세요. 컨텍스트 창은 모델이 한 번에 참고할 수 있는 대화와 자료의 범위입니다. 긴 작업으로 이 범위가 차면 Claude Code는 오래된 대화를 요약합니다. 완료한 일과 남은 일을 파일에도 적어 두면 요약 뒤에 작업을 이어 가거나 사람이 진행 상황을 확인하기 쉽습니다.

3. 결과 확인하기

Opus 5.5의 긴 작업이 끝나면 내 판단을 기다리는 항목부터 찾으라고 합니다. 아직 확정되지 않은 결정이나 내 승인이 필요한 변경이 여기에 해당합니다. Opus 5.5는 한 일, 발견한 것, 내 입력이 필요한 것을 Opus 5보다 분명하게 보고합니다.

사람이 보기 전에 AI에게 코드 리뷰를 먼저 시키라는 조언도 있습니다. 한 초기 테스터는 가장 낮은 effort의 Opus 5.5가 높은 effort의 Opus 5보다 버그를 더 많이 잡고, 정상 코드를 문제라고 잘못 지적하는 오탐은 적었다고 전했습니다. 다만 개별 테스터의 경험이라는 점은 구분해서 읽어야 합니다.

리뷰를 요청할 때는 코드를 합치기 전에 반드시 고쳐야 할 문제를 찾게 합니다. 문제마다 파일과 줄, 틀린 이유, 실패를 재현하는 방법을 적게 하면 사람이 확인하기 쉽습니다. 조사나 분석에는 찾아본 곳과 확인하지 못한 부분을 표시하게 하세요. 찾아보았지만 원하는 내용을 발견하지 못했다는 결과도 판단에 도움이 됩니다.

Claude 앱에서는 모델 선택기에 Opus 5.5가 떠 있는지 먼저 확인하세요. 차트나 스크린샷은 숫자를 옮겨 적지 말고 이미지째 첨부하면 됩니다. 화살표가 어느 상자를 잇는지처럼 위치에 따라 뜻이 달라지는 내용도 Opus 5보다 정확히 읽는다고 합니다. 긴 문서에서 모순을 찾게 하는 것도 좋은 용도입니다. 원문 저자의 테스트에서는 긴 계획 대화에서 요일이 어긋난 날짜를, 발표 자료에서 숫자와 맞지 않는 차트를 찾아냈다고 합니다. 표나 문서가 필요하면 개요 말고 완성 파일을 요청하세요.

4. 플래그와 속도

Opus 5.5는 Fable 수준의 생물·사이버 안전장치와 함께 출시된 첫 Opus 모델이라고 합니다. 메시지가 플래그된다는 것은 안전장치가 그 메시지를 점검 대상으로 표시했다는 뜻입니다. 원문에 따르면 이때 대부분 구형 모델로 전환해 작업을 이어 갑니다. 정상 작업이 잘못 표시되는 경우도 있어 오탐을 줄이도록 조정 중이라고 밝힙니다.

Claude 앱에서는 모델 선택기에서 Opus 5.5를 다시 고르면 됩니다. 앞선 메시지가 남아 있으면 또 걸릴 수 있어 새 대화가 낫습니다. 먼저 물어보게 하려면 설정의 Capabilities에서 모델 전환 항목을 끄면 됩니다. Claude Code에서는 /model 로 되돌립니다. Esc를 두 번 누르면 마지막 메시지를 고쳐 다시 보낼 수 있고 /config 에서는 같은 설정을 바꿀 수 있습니다. 오탐은 /feedback 으로 알립니다. 프롬프트에서 모델의 내부 추론을 답변에 그대로 옮기라고 요구하는 것도 피하세요. 거절될 수 있고 플래그 범주 중 하나입니다.

답변을 기다리며 자주 주고받는 작업에는 Claude Code의 fast mode가 있습니다. /fast 로 켜면 같은 모델이 더 빨리 답합니다. 원문 발행 시점에는 시험 제공 단계인 research preview였고 기본 한도를 넘는 추가 사용을 허용하는 extra usage를 켜야 했습니다. 토큰당 비용은 표준 모드보다 높으므로 속도와 비용을 함께 봐야 합니다.

인사이트

여기부터는 원문이 아니라 이 블로그의 해석입니다.

1. Claude에게 일을 맡길 때는 무엇을 하면 끝나는지 함께 알려 주는 편이 좋겠습니다. 데이터 처리 프로그램이라면 어떤 결과가 나와야 하고 어떤 테스트를 통과해야 하는지 적습니다. Claude가 그 기준으로 결과를 확인할 수 있다면 사용자가 매 단계 다음 일을 지시해야 하는 부담도 줄어들 수 있습니다.

2. 자동으로 진행할 작업에서도 사용자가 확인할 순간은 미리 정해 두어야 합니다. 답을 모르면 언제 질문할지, 어떤 명령은 실행 전에 허락받을지, 완료한 일과 남은 일을 어디에 적을지 정합니다. 보조 AI에게 일을 나눴다면 보고에 적힌 근거도 확인합니다. 이렇게 준비해 두면 진행 상황과 사용자의 판단이 필요한 부분을 구분하기 쉽습니다.

3. 원문의 성능 이야기는 초기 사용자들의 경험과 저자의 간단한 테스트가 대부분입니다. 낮은 effort의 Opus 5.5가 높은 effort의 Opus 5보다 버그를 더 잡았다는 말도 테스트 조건이 공개된 비교는 아닙니다. 내 프로젝트에서도 같은 장점이 있는지는 작은 작업 몇 개를 두 모델에 맡겨 직접 확인하는 편이 좋겠습니다.

바로 해볼 것

• 자주 쓰는 프롬프트와 CLAUDE.md에서 “think carefully"처럼 더 생각하라고 요구하는 문장을 찾아봅니다. 그 문장을 뺀 요청과 원래 요청을 Opus 5.5에 보내 결과의 품질과 응답 속도가 달라지는지 비교해 봅니다.
• CLAUDE.md에 언제 계속하고 언제 질문할지 적습니다. 예를 들어 “내 답이 필요 없는 단계는 계속 진행하되, 내 판단이 필요하거나 데이터 삭제·강제 푸시·저장소 밖 변경을 앞두면 멈추고 확인해 줘"처럼 쓸 수 있습니다.
• 다음 긴 작업을 맡길 때 완료 조건을 적고, 완료한 일과 남은 일을 TASKS.md에 기록해 달라고 요청합니다. 작업이 끝나면 요약에서 “내 입력이 필요한 항목"부터 읽고 결정하거나 승인할 일이 남았는지 확인합니다.

원문: Getting the most out of Opus 5.5 in Claude and Claude Code