Opus 5.5를 최대한 활용하는 에이전트 작업법

원문: Getting the most out of Opus 5.5
채널: t3dotgg · 2026-09-25 · 28분 42초

1계층 — 핵심 결론

Opus 5.5의 성능을 끌어내는 핵심은 더 강한 사고를 반복해서 요구하는 데 있지 않다. 모델에게 무엇을 만들지, 무엇을 완료로 볼지, 막혔을 때 언제 질문할지, 무엇을 해서는 안 되는지를 한 번에 명확히 주고, 충분한 작업 자율성을 부여하는 데 있다.

특히 다음 다섯 가지가 전체 사용법을 관통한다.

1. 작업의 끝 상태(done state)를 구체적으로 정의하고 전체 과업을 한 메시지로 넘긴다.
2. Think carefully나 Think deeply처럼 사고를 강제하는 문구는 쓰지 않는다.
3. 장시간 실행 중에는 새 스레드로 갈아타지 말고 후속 메시지로 방향을 조정한다(steering).
4. 디자인이나 산출물의 금지 조건을 구체적으로 적고, 결과를 검증할 도구와 기준을 제공한다.
5. 모델이 끝없이 보고만 하거나 위험한 작업을 자의적으로 진행하지 않도록 계속할 지점과 멈출 지점을 명시한다.

2계층 — 주장과 근거

2.1 Opus 5.5의 강점은 장기 실행과 상태 보고다

Opus 5.5는 기존 Claude 사용법과 크게 다르지 않지만, 혼자 더 오래 작업하고, 수행한 일을 더 평이한 언어로 보고하며, 매 응답 전에 생각하는 경향이 강하다. 코드의 품질과 상호작용의 자연스러움, 긴 작업에서의 작업 지속성이 특히 인상적인 영역으로 제시된다.

다만 긴 실행이 자동으로 완주를 보장하지는 않는다. 완료 조건이 모호하면 모델이 중간에 요약만 남기거나 “계속할까요?”라고 묻고 멈출 수 있다. 따라서 모델의 능력보다 먼저 작업의 종료 조건과 예외 조건을 설계해야 한다.

2.2 done을 이름 붙이면 모델의 행동이 안정된다

“이 기능을 작업해”라는 요청은 시작점만 말할 뿐 끝을 말하지 않는다. 다음처럼 결과물과 검증물을 함께 정의해야 한다.

Build this feature with these three requirements. Verify it by showing me a screenshot and file a PR afterward.

완료는 기능 구현만을 뜻하지 않는다. 기능이 만들어지고, 스크린샷이 확인되며, 그 기능과 스크린샷이 포함된 PR이 올라간 상태까지가 완료다. 더 단순한 예시는 다음 구조를 가진다.

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

이 구조는 원하는 것, 완료의 정의, 질문을 허용하는 예외를 분리한다. 고성능 모델은 명확한 종료선을 받으면 그 선에 도달할 때까지 계속 진행하기 쉬워진다.

2.3 Max reasoning은 상한이 아니라 최소 사고량을 높일 수 있다

Opus 5.5의 reasoning level은 모델이 반드시 그만큼 생각한다는 뜻이 아니라, 필요할 때 생각할 수 있는 최대치를 정하는 것으로 이해하는 편이 낫다. Low와 Medium은 상한에 닿을 때까지 필요한 만큼만 생각하고, High와 X High는 더 높은 상한을 제공한다.

반면 Max는 모델이 덜 생각할 여지를 줄이고, 작은 문제에도 과도한 추론을 수행하게 만들 수 있다. 제시된 Skatebench 실험의 비교는 다음과 같다.

설정	평균 토큰	평균 응답 시간	최악 응답 시간	정답률	비용·효율
X High	338	6초	31초	78%	기준
Max	5,000	50초	600초	79%	토큰 약 15배, 비용 약 13배

Max는 정답률을 78%에서 79%로만 높였지만 평균 토큰은 10배 이상, 평균 시간은 크게 늘었고 최악의 경우 20배 느렸다. 단순한 함정 문제에서 도움이 될 가능성은 인정되지만, 일반적인 개발 작업의 기본값으로는 X High가 더 합리적이라는 결론이다. Low는 이 모델이 어느 정도 추론을 필요로 하기 때문에 품질이 떨어질 수 있고, High와 X High의 차이는 상대적으로 작아 X High를 기본값으로 두는 방식이 권장된다.

2.4 장시간 실행은 중단보다 steering이 낫다

실행 중 방향을 바꾸거나 빠진 요구사항을 추가해야 할 때 새 스레드를 시작하면 이미 쌓인 탐색과 맥락을 잃는다. Opus 5.5처럼 긴 작업을 잘 이어 가는 모델에는 실행 중 후속 메시지를 보내 작업을 조정하는 steering이 효과적이다.

과거 모델은 새 메시지를 별도 과업으로 취급해 기존 요구사항을 잊고 마지막 요구만 처리하는 문제가 있었다. 최근 모델은 후속 메시지를 기존 작업을 취소하는 명령이 아니라, 같은 목표를 향해 경로를 교정하는 입력으로 다루도록 개선됐다. 따라서 실행 중 “세 번째 조건을 빠뜨렸다”는 사실을 발견해도 처음부터 다시 시작하기보다 현재 작업에 추가 요구를 전달하는 편이 효율적이다.

2.5 디자인은 취향보다 제약 조건을 구체화해야 한다

Opus 5.5가 “예쁘게 만들어”라는 요청만으로 항상 가장 좋은 디자인을 만드는 것은 아니다. 방향이 없으면 몇 가지 기본 스타일 중 하나로 회귀하고, “generic하지 않게” 같은 추상적 부정문은 다른 기본 스타일로 교체하는 데 그칠 수 있다.

다음처럼 구체적으로 원하지 않는 패턴을 열거하면 결과가 훨씬 안정된다.

Build a personal website with placeholder content. Don't use a cream or off-white background, italic accent words and headings, numbered 1-2-3 section labels, monospace labels, or pill-shaped buttons.

결과를 본 뒤 마음에 들지 않는 요소를 금지 목록에 추가해 다시 요청하면 된다. 스크린샷에 화살표나 표시를 그려 문제 지점을 직접 가리키는 방법도 강력하다. 오류 설명을 길게 복사하는 대신 브라우저 화면을 캡처해 붙여 넣으면 모델이 시각적 맥락을 빠르게 파악할 수 있다.

3계층 — 사례와 실전 적용

3.1 원격 머신으로 작업을 넘긴 사례

로컬 컴퓨터에서 Max reasoning으로 실행한 작업이 6시간 30분 동안 계속된 사례가 소개된다. 작업 상태를 묻자 모델은 상태를 설명했고, “계속해”라고 한 뒤 약 10분 만에 상당히 좋은 상태로 마무리했다. 그러나 로컬 노트북을 장시간 점유하는 방식은 불편하므로, 에이전트 작업을 다른 컴퓨터나 원격 서버로 옮기는 흐름이 더 적합하다.

원격 머신 Leftbook으로 작업을 넘길 때는 연결 방법을 추측하게 하지 않고, 현재 머신의 fleet 저장소를 통해 연결하라고 지정했다. 저장소를 clone할 것, 필요한 환경 변수를 준비할 것, Claude Code와 T3 Code에서 Opus 5.5를 실행하고 평소처럼 T3 Code에서 스레드를 확인할 수 있을 것까지 검증하도록 요청했다.

또한 환경 변수 복사를 명시적으로 허용했다. 모델이 보안상 애매한 동작 앞에서 멈추지 않도록, 작업에 필수인 권한은 미리 좁은 범위로 승인하는 방식이다. 반대로 로컬 컴퓨터에서 브라우저나 컴퓨터 제어 창을 띄워 사용을 방해하지 말라는 금지 조건도 넣었다.

가장 중요한 예외 문장은 문제가 생기면 주저하지 말고 질문하라는 허용이다. 모델은 학습 과정에서 포기하지 않고 스스로 다른 방법을 시도하도록 강하게 조정되어 있어, 혼란스러운 상황에서도 질문 대신 잘못된 경로를 계속 택할 수 있다. “작동하지 않으면 질문하라”는 문장은 모델에게 안전한 탈출구를 제공한다.

이 초기 설정은 약 17분 만에 끝났고, 다른 머신에서 생성된 스레드를 T3 Code에서 볼 수 있게 됐다. 다만 실제 구현은 계획의 phase 0만 수행한 뒤 멈췄다. 이를 보완하려면 다음처럼 전체 범위와 질문 시점을 한 번에 지정해야 한다.

Goal: Build the whole ping rewrite described in overhaul.md in one pass on this branch.
Read the whole plan before you start. Follow phases 0 to 7 in order.
Hold off on all questions until the very end when you get through to phase 7 in completion.
Continue working on this port until the entirety of it is completed.
Don't inform me until you have a Tailscale link I can click on.

핵심은 phase마다 허가를 다시 받지 말 것, 구현이 끝나고 클릭 가능한 검증 링크가 생길 때까지 보고를 미룰 것, 호스팅 방식보다 지정된 결과를 우선할 것을 명시하는 데 있다.

3.2 Claude Code의 계속·중단 규칙

장기 작업에서 모델이 원하지 않는 시점에 멈추는 것을 줄이려면 CLAUDE.md에 정지 규칙을 적을 수 있다.

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 of this repo.

이 규칙은 단순히 “계속해”라고 반복하는 것보다 구체적이다. 작업에 입력이 필요하지 않으면 계속하고, 상태 보고는 다음 행동과 같은 메시지에 포함하며, 사용자 없이는 진행할 수 없거나 파괴적·되돌리기 어려운 작업 직전에만 멈춘다.

반대로 여러 사람이 함께 설계하거나 학습 목적으로 검토해야 한다면 시작 전에 한 줄 계획을 보여 주고 끝에 짧은 회고를 하도록 요청하는 편이 낫다. 자율성을 높이는 규칙은 업무 방식에 맞게 선택해야 한다.

3.3 큰 저장소는 sub-agent로 분할한다

대규모 코드베이스의 감사(audit), 마이그레이션(migration), PR 검토(review)는 하나의 컨텍스트(context)에서 모두 처리하기 어렵다. 서로 다른 하위 에이전트(sub-agent)가 각 영역을 탐색하고, 상위 에이전트가 결과를 조정하게 하면 컨텍스트 창을 절약하고 병렬 탐색을 늘릴 수 있다.

Opus 5.5는 sub-agent를 조정할 수 있지만, 작업이 분할되면 더 좋다는 사실을 스스로 판단해도 실제로 sub-agent를 시작하지 않는 경우가 있다. 따라서 대규모 작업에서는 “필요하면 sub-agent와 workflow를 사용하라”는 일반 허용보다 “이 작업을 sub-agent로 분할해 수행하라”는 직접 지시가 더 확실하다.

3.4 완료 후 확인 순서

긴 실행이 끝나면 다음 순서로 확인한다.

1. 모델이 사용자에게 결정이나 승인을 기다리고 있는지 먼저 찾는다.
2. 모델의 요약에서 실제로 변경한 것과 발견한 것을 읽는다.
3. 검증하지 못한 항목과 남은 위험을 확인한다.
4. 필요하면 “현재 작업 상태는 무엇인가?”, “내가 해야 할 일은 무엇인가?”라고 묻는다.
5. 병합 전에는 “오늘 이 코드를 merge하면 어떤 위험이 있는가?”와 “지금 merge했을 때 최악의 결과는 무엇인가?”를 묻는다.

제안된 보고 형식은 Blocked on me, Changed, Found 세 headings다. 모든 프로젝트에 강제할 필요는 없지만, 오래된 스레드를 다시 열었을 때 사용자에게 필요한 정보가 무엇인지 잘 보여 준다.

3.5 서로 다른 모델 계열로 교차 검토한다

작성과 검토에 같은 모델만 사용하면 한 모델의 사각지대가 그대로 남을 수 있다. Opus 5.5로 코드를 만들었더라도 다른 모델 계열로 검토하면 결함을 더 넓게 찾을 수 있다. OpenAI 계열 모델은 세부 사항을 깊게 파고들어 중요하지 않은 지적까지 많이 내놓을 수 있지만, Claude 계열이 놓치는 실제 문제를 찾아내는 경우가 있다는 경험이 제시된다. Grok 4.7도 검토 후보로 언급된다.

한 코드베이스 개선점 벤치마크에서는 서로 다른 모델의 성향 차이가 드러났다. 어떤 모델은 근거 있는 개선점 8건을 찾았고, 다른 모델은 9건을 찾았지만 판정 패널의 품질 평가는 더 낮았다. 한 모델은 중요하고 타당한 5건만 매우 엄격하게 찾아냈다. Opus 5.5는 이전 Opus 5보다 거의 두 배 높은 검토 성공률을 보였고, 미해결 또는 모순된 지적은 내놓지 않았다는 결과가 제시된다. 중요한 결함을 많이 찾는 능력과, 지적의 타당성을 엄격하게 유지하는 능력은 서로 다른 축이다.

검토를 요청할 때는 확인할 수 없는 항목을 표시하라고 지시해야 한다. 브라우저, 컴퓨터 제어(computer use), 테스트 스위트(test suite), 필요한 하드웨어나 환경 변수에 접근할 수 있다면 모델이 직접 검증하게 하고, 확인할 수 없는 주관적 기준이나 외부 시스템은 별도로 표시하게 한다. “작동한다고 생각한다”와 “실제로 확인했다”를 구분하는 것이 핵심이다.

4계층 — 제품 사용 팁과 실행 체크리스트

4.1 Cloud Apps와 Cloud Code에서의 주의점

먼저 모델 선택기가 실제로 Opus 5.5를 가리키는지 확인한다. Opus 5.5는 Cloud Apps와 Cloud Code에서 생물학·사이버 안전장치 수준의 보호 기능을 함께 제공하며, 일부 메시지는 이전 모델로 자동 전환될 수 있다. 소스 코드의 보안 취약점을 분석하는 작업이나 일상적인 건강·교육 질문은 허용될 수 있지만, 정상적인 작업이 잘못 플래그되는 경우도 있다.

플래그가 발생하면 다른 모델로 전환됐다는 알림과 함께 대화가 이어질 수 있다. 모델 선택기에서 Opus 5.5를 다시 고르거나 새 대화를 시작하면 해결되는 경우가 있으며, 자동 전환을 끄고 일시정지나 오류로 처리하는 설정도 있다.

모델의 내부 reasoning trace를 그대로 보여 달라고 요청하지 않는 편이 좋다. “이 변경을 한 reasoning은 무엇인가?” 같은 자연스러운 질문도 내부 사고 과정 공개 요청으로 분류돼 플래그될 수 있다. 대신 “변경의 근거와 확인한 기준을 요약해 달라”, “어떤 위험을 검증했는가”처럼 외부로 설명 가능한 근거와 결과를 요청한다.

4.2 바로 적용할 체크리스트

• 완료 정의: 산출물뿐 아니라 테스트, 스크린샷, PR, 배포 링크 등 완료를 증명할 결과를 적는다.
• 추론 설정: Max를 기본값으로 두지 말고 High 또는 X High에서 필요량을 모델이 결정하게 한다.
• 전체 위임: 여러 단계가 있다면 phase와 순서를 적고, 단계마다 허가를 다시 묻지 않도록 한다.
• 질문 허용: 성공 경로는 계속 진행하게 하되, 설명할 수 없는 실패나 위험한 작업에서는 질문하게 한다.
• 금지 조건: 디자인은 구체적으로 원하지 않는 패턴을 나열하고, 개발 작업은 컴퓨터를 방해하거나 저장소 밖을 변경하지 말라고 적는다.
• Steering: 실행 중 빠진 요구사항은 새 스레드로 복사하지 말고 후속 메시지로 추가한다.
• 분할: 큰 감사·마이그레이션·리뷰는 sub-agent 사용을 직접 지시한다.
• 검증: 브라우저, 스크린샷, 테스트, 컴퓨터 제어 등 모델이 결과를 확인할 도구를 준다.
• 교차 검토: 작성에 사용하지 않은 모델 계열로 위험과 누락을 다시 확인한다.
• 보고 형식: Blocked on me, Changed, Found 또는 프로젝트에 맞는 세 가지 상태 구획을 요청한다.

4.3 최종 시사점

에이전트가 충분히 강해질수록 사용자는 모든 작은 결정을 대신 내리는 역할에서 벗어나야 한다. 에이전트에게 더 긴 작업 범위와 도구를 주되, 무엇이 완료인지와 어떤 방식으로 검증할지를 함께 제공해야 한다. 원시 모델 성능만큼이나 변경 사항을 테스트하고, 브라우저에서 확인하고, 위험을 보고하도록 만드는 시스템이 중요하다.

Opus 5.5의 가치는 모델에게 무조건 더 오래 생각하게 하는 데서 나오지 않는다. 모델이 스스로 진행할 수 있는 넓은 작업 공간, 명확한 종료선, 적절한 중단선, 직접 검증할 수 있는 도구를 조합할 때 한 번의 실행으로 더 많은 일을 완성하는 데서 나온다.

핵심 요약 (20줄)

• Opus 5.5를 잘 활용하려면 모델에게 작업 목표와 완료 상태를 구체적으로 알려야 한다.
• 기능 구현뿐 아니라 테스트 통과, 스크린샷, PR, 배포 링크까지 완료 조건에 포함해야 한다.
• Think carefully나 Think deeply를 덧붙이지 않아도 모델은 필요한 만큼 추론한다.
• Max reasoning은 사고 상한을 높이는 동시에 모델이 덜 생각할 여지를 줄일 수 있다.
• 제시된 실험에서 Max는 X High보다 토큰과 시간이 크게 늘었지만 정답률은 1%포인트만 높였다.
• 일반적인 개발 작업의 reasoning 기본값으로는 High 또는 X High가 Max보다 효율적이다.
• 장시간 실행 중 요구사항이 빠졌다면 새 스레드를 만들지 말고 후속 메시지로 steering해야 한다.
• Opus 5.5의 디자인 품질은 막연한 미적 요청보다 구체적인 금지 조건을 줄 때 좋아진다.
• 스크린샷에 화살표와 표시를 더해 문제 지점을 가리키면 모델이 시각적 맥락을 빠르게 파악한다.
• Claude Code에는 사용자 입력이 필요하지 않을 때 계속 진행하라는 규칙을 둘 수 있다.
• 모델은 삭제, force push, 저장소 외부 변경처럼 파괴적인 작업 직전에는 멈추게 해야 한다.
• 대규모 감사와 마이그레이션은 sub-agent로 나누면 컨텍스트와 탐색 시간을 절약할 수 있다.
• 실행이 끝나면 모델이 사용자에게 무엇을 기다리는지와 실제로 무엇을 바꿨는지를 먼저 확인해야 한다.
• Blocked on me, Changed, Found headings는 장기 실행 결과를 읽기 쉽게 만든다.
• 병합 전에는 현재 변경의 위험과 merge 직후의 최악의 결과를 모델에게 물어야 한다.
• 코드를 만든 모델과 다른 모델 계열을 사용하면 서로 다른 검토 사각지대를 보완할 수 있다.
• 검토 요청에는 모델이 확인하지 못한 항목을 별도로 표시하라는 조건을 포함해야 한다.
• 브라우저, 테스트 스위트, 컴퓨터 제어 같은 검증 도구가 있으면 모델의 확신을 실제 확인으로 바꿀 수 있다.
• reasoning trace를 직접 요구하기보다 변경 근거와 검증 결과를 설명해 달라고 요청하는 편이 안전하다.
• 에이전트에게 더 많은 자율성을 주되 명확한 완료선과 검증 체계를 함께 제공하는 것이 핵심이다.