‘단계별로 생각하기’라는 말은 그만: Addy Osmani의 Opus 5.5 프롬프팅 가이드가 실제로 의미하는 것

지금 바로 저장된 프롬프트를 열고 ‘신중하게 생각해(think carefully)’ 또는 ‘단계별로(step by step)’라는 단어를 검색해 보세요. 만약 이 단어들을 발견했다면, 당신은 이전 세대 모델에서 가져온 습관을 가지고 있는 것이며, Anthropic의 최신 공식 가이드에 따르면 이러한 습관들은 아무런 이득 없이 답변 속도만 늦추고 있습니다.

지난주 Addy Osmani는 Anthropic 엔지니어링 블로그에 “Claude와 Claude Code에서 Opus 5.5를 최대한 활용하는 방법(Getting the most out of Opus 5.5 in Claude and Claude Code)”을 게시했고, 이는 Hacker News 메인 페이지에 실리며 실제 논의를 불러일으켰습니다. 이 가이드 전체의 주제는 프롬프트 트릭을 모으느라 시간을 보낸 사람들에게 불편할 수 있습니다: 모델이 이제 스스로 얼마나 생각할지 결정하므로, 당신의 역할은 더 이상 추론(reasoning) 쪽으로 모델을 밀어붙이는 것이 아닙니다. 당신의 역할은 ‘완료(done)’를 정의하고, 언제 멈춰야 하는지 알려주고, 질문한 다음, 그 자리에서 빠지는 것입니다.

세부 내용을 설명하기 전에 한 가지 공개할 점이 있습니다: 아래 모든 내용은 Osmani의 가이드와 Anthropic 자체 문서를 기반으로 작성되었으며, 모두 인라인으로 링크되어 있습니다. 저는 실제 저장소(live repos)에서 몇 주 동안 저만의 실험을 진행했으며, 그 결과는 제가 이 글을 읽기 전에 가이드의 핵심 주장들을 확인시켜 주었지만, 여기에 제시된 수치와 구체적인 권장 사항은 제 것이 아니라 가이드가 제시한 것입니다.

핵심 변화: 모델이 생각하게 두세요. 지시하지 마세요.

‘신중하게 생각해(think carefully)’ 라인을 삭제하세요. Anthropic의 채팅 제품 자체 테스트에서, ‘신중하게 생각해’ 라인을 제거하자 품질 저하 없이 답변 시작 시간이 빨라지는 것을 확인했습니다. Opus 5.5는 모든 답변 전에 생각하며 해당 작업이 얼마나 많은 사고를 필요로 하는지 스스로 결정합니다. 이 지시는 이제 불필요한 무게(dead weight)이며, 저장된 지침에 포함되면 보내는 모든 메시지에 적용됩니다.

전체 작업을 하나의 메시지로 제공하세요. 이것은 우리 대부분이 일하는 방식에서 가장 큰 변화입니다. Osmani의 예시 프롬프트는 세 부분으로 구성되어 있으며, 그 어느 하나도 중요하지 않습니다:

• 전체 작업(The whole task): “결제 엔드포인트를 이전 클라이언트에서 새 클라이언트로 마이그레이션하세요.”
• 완료 조건(The finish line): “완료란: 모든 엔드포인트가 새 클라이언트를 사용하고, 이전 클라이언트는 삭제되며, 테스트 스위트가 통과하는 것입니다.”
• 중지 조건(The stop condition): “테스트 실패 원인을 당신이 설명할 수 없을 때만 멈추고 저에게 질문하세요.”

왜 변경되었을까요? 초기 테스터들은 Opus 5.5를 장시간 코딩 작업에 몇 시간 동안 감독 없이 실행했고, Opus 5 대비 가장 큰 개선점은 바로 여기에 있습니다. 즉, 테스트가 통과할 때까지 대규모 저장소(repository)에 걸쳐 변화를 이끌어가는 능력입니다. 완료 조건은 모델에게 언제 끝났는지 알려줍니다. 중지 조건은 당신이 깨워져야 하는 단 하나의 경우를 알려줍니다. 그 외의 모든 것은 질문이 아니라 상태 노트여야 합니다.

원하지 않는 스타일을 명시하세요. 디자인 작업에서 “평범한 느낌을 피하라(avoid a generic look)”는 대부분 한 가지 평범한 느낌을 다른 평범한 느낌으로 대체할 뿐입니다. Osmani의 예시는 금지해야 할 구체적인 습관 목록입니다: 크림색이나 미색 배경 없음, 제목에 이탤릭체 강조 단어 사용 금지, 번호가 매겨진 “01 / 02 / 03” 섹션 레이블 금지, 고정폭(monospace) 레이블 금지, 알약 모양 버튼 금지. 모호한 긍정적 지시보다 구체적인 부정적 지시가 효과적이며, 만약 모델이 다음에 선택하는 것이 마음에 들지 않는다면 그것을 금지 목록에 추가하고 다시 실행하세요.

장기 실행 제어: CLAUDE.md가 이제 당신의 조향장치입니다 (steering wheel)

가이드의 두 번째 섹션은 에이전트 세션을 실행하는 모든 사람에게 가장 가치 있는 부분입니다. 왜냐하면 이 부분이 CLAUDE.md를 스타일 가이드에서 실행 제어(run control)로 변모시키기 때문입니다. Osmani가 제안한 규칙은 복사하여 붙여넣을 만큼 짧습니다:

• “단계에 나의 입력이 필요하지 않으면 계속 진행하세요. 상태 노트를 다음 행동과 같은 메시지에 넣어주세요.”
• “나 없이 계속할 수 없거나, 또는 파괴적인 작업(데이터 삭제, 강제 푸시(force-pushing), 이 저장소 외부의 변경 등)을 하기 전에만 멈추고 질문하세요.”

주의 깊게 살펴볼 두 가지 세부 사항이 있습니다. 첫째, 가이드에 따르면 Opus 5.5는 작업을 진행하다가 중간에 보고를 위해 멈추는 경우가 있어 계속 진행하지 않고 다음 단계를 명시하는 요약이나 계속할지 여부를 묻는 제안을 할 수 있습니다. 만약 실행 결과가 "계속 진행할까요?(Want me to continue?)"로 끝나는 경우, 위 규칙이 해결책이며, 한 번의 발생에 대한 해결책은 단순히 "continue"라고 답하는 것입니다. 둘째, 파괴적 명령(destructive-command) 예외 처리 사항이 중요합니다. 계속 진행하기(keep-going rule) 규칙을 사용하면 중단 횟수가 줄어들어 위험하거나 되돌리기 어려운 작업을 하기 전에 자체 체크포인트를 유지할 수 있고, 파괴적 명령에 대한 권한 요청 프롬프트를 남겨둘 수 있습니다.

감사 및 마이그레이션을 위한 서브 에이전트(Subagents). 대규모 코드베이스에 걸쳐 작업하는 경우, Osmani는 모델에게 '분산 처리(fan out)'를 요청할 것을 제안합니다: "각 서비스별로 서브 에이전트를 할당하세요. 서브 에이전트가 보고하면, 수락하기 전에 그 증거(evidence)를 확인하세요." 여기서 뒷부분에 주목하십시오. Anthropic은 병렬 보고서들을 신뢰하라고 말하는 것이 아니라, 모델 자체에게 각 서브 에이전트의 증거를 검증하도록 지시하고, 마지막으로 단일 표로 정리하게 하는 것입니다: 서비스, 영향 여부(yes 또는 no), 그리고 증거입니다.

작업 목록은 파일에 보관하세요. 긴 실행 과정은 컨텍스트 창을 채우고, Claude Code는 오래된 내용을 요약합니다. TASKS.md에 있는 체크리스트는 이러한 요약을 견디며 무엇이 완료되었고 무엇이 남았는지 한눈에 보여줍니다. 스크롤백(scrollback)을 읽지 말고 파일을 읽으세요.

결과 확인하기: "나에게 막힌 부분(blocked on me)"부터 읽기

긴 실행 과정이 끝날 때, Osmani는 Claude가 사용자에게 기다리고 있는 것이 있는지 가장 먼저 살펴보라고 조언합니다. 즉, 열어둔 결정 사항이나 승인을 요청하는 변경 사항입니다. 그런 다음 나머지 요약 내용을 읽으세요. 이를 반복 가능하게 만드는 그의 비결은 CLAUDE.md 파일의 끝 부분을 표준화하는 것입니다: "모든 실행 과정은 세 개의 제목으로 마무리하세요: 나에게 막힌 부분(Blocked on me), 변경된 내용(Changed), 발견한 것(Found)."

가이드에서 얻은 세 가지 추가적인 확인 습관:

• 인간 검토 전에 모델 리뷰를 실행하세요. 한 초기 테스터는 Opus 5.5의 가장 낮은 노력 설정(lowest effort setting)이 높은 노력 설정의 Opus 5보다 더 많은 버그를 발견했으며, 오탐지율(false alarms)은 적었다고 보고했습니다.
• 연구 목적으로는 "확인할 수 없었던 내용은 표시하고 어디서 찾아봤는지 언급하세요"라는 내용을 추가하는 것이 좋습니다. 자신이 찾을 수 없는 것을 알려주는 모델이야말로 감사(audit)가 가능한 모델입니다.
• 앱에서는 숫자를 다시 입력하는 대신 차트나 스크린샷을 첨부하세요. Osmani에 따르면 Opus 5.5는 화살표가 연결하는 상자 같은 공간적 의미(spatial meaning)를 포함하여 차트와 스크린샷을 Opus 5보다 더 정확하게 읽어냅니다.

아무도 이야기하지 않는 부분: 사일런트 모델 스위칭 (silent model switching)

다음은 별도의 게시물이 되어야 할 가이드의 섹션입니다. Opus 5.5는 Fable 수준의 생물학적 및 사이버 보안 보호 장치(bio and cyber safeguards)를 갖추고 출시된 최초의 Opus 모델이며, Claude 앱과 Claude Code에서 플래그가 지정된 메시지 대부분은 거부되지 않습니다. 대신 이전 버전의 모델로 조용히 라우팅되며, 사용자는 보통 알아차리지 못한 채 작업이 계속됩니다.

소스 코드에서 보안 취약점을 찾는 것은 여전히 허용되며, 일상적인 질문도 작동합니다. 그러나 Anthropic은 이러한 보호 장치가 합법적인 작업을 플래그 지정할 수 있음을 인정하며, 이 검사는 파일과 검색 결과를 포함하여 대화의 모든 내용을 다룹니다. 이는 플래그가 사용자의 마지막 메시지뿐만 아니라 세션 초기의 콘텐츠에서 발생할 수 있다는 의미이며, 복구 단계를 모른다면 Opus 5.5를 사용하고 있다고 믿으면서도 Opus 5 수준의 답변을 받고 있을 수 있습니다.

가이드에 명시된 복구 단계:

• Claude Code에서: /model을 실행하여 원래 모델로 전환하거나, Esc 키를 두 번 눌러 마지막 메시지를 편집하고 재시도하세요. 자동으로 전환되는 대신 먼저 질문받도록 하려면 /config를 실행하고 "메시지가 플래그 지정될 때 모델 전환(Switch models when a message is flagged)" 설정을 변경하세요.
• 앱에서: 모델 선택기(model picker)에서 Opus 5.5를 선택하세요. 만약 플래그가 지정된 메시지가 여전히 채팅창에 있다면 다시 트리거될 수 있으므로, 새 채팅을 시작하는 것이 더 안전합니다. 설정 > 기능(Settings, then Capabilities)에서 동일한 "메시지가 플래그 지정될 때 모델 전환" 토글이 있습니다.

만약 보안 검토(security review)나 모의 해킹(pen-test) 관련 업무를 한다면, 오늘부터 '먼저 질문하기(ask-first)' 토글을 설정하세요. 세션 도중에 조용히 기능이 저하되는 것은 몇 시간을 지나도 알아차리기 어려운 종류의 실패입니다.

관련된 프롬프팅 참고 사항 하나: 모델에게 답변에 내부 추론 과정을 재현해 달라고 요청하지 마세요. 그 요청은 플래그(flag) 범주 중 하나이며 거부될 수 있습니다. 대신 유용한 결과물을 요구하세요. 예: "이 접근 방식을 선택한 이유를 세 문장으로 설명해주세요."

빠른 모드와 그것이 가치 있는 경우

답변을 받은 후 다음 메시지를 보내기 전에 읽는, 주고받는 작업(back-and-forth work)에서 속도가 실제로 중요하며, 이것이 바로 빠른 모드(fast mode)가 목표로 하는 바입니다. Claude Code에서 /fast를 입력하세요. 동일한 모델을 사용하지만 텍스트가 더 빨리 도착합니다. 다만, 이는 연구 미리 보기(research preview) 버전이며 추가 사용 활성화(extra usage turned on)가 필요하고 표준 모드보다 토큰당 비용이 더 많이 듭니다. 길고 자율적인 실행(long autonomous runs)의 경우에는 반대의 논리가 적용됩니다. 이 작업은 상호작용적이지 않으므로 표준 요금을 지불하고 진행되도록 두세요.

사전 점검 목록 (The pre-flight checklist)

다음 장기 작업을 시작하기 전에 이것들을 확인하세요. 북마크할 가치가 있는 부분입니다.

전송 버튼을 누르기 전에:

• 작업이 '완료(done)' 상태를 한 문장으로 설명함
• 프롬프트나 저장된 지침 어디에도 "깊이 생각하기(think hard)"와 같은 구절 없음
• 디자인 요청은 제외할 특정 스타일을 명시함
• 차트와 스크린샷은 재입력되지 않고 첨부됨

긴 Claude Code 실행 전에:

• CLAUDE.md에 계속 진행해야 할 시점과 멈춰서 질문해야 할 시점이 명시되어 있음
• 중지 규칙(stop rule)이 파괴적인 명령어들을 걸러내고, 권한 요청 프롬프트는 여전히 활성화되어 있음
• 대규모 감사(Big audits)와 마이그레이션은 하위 에이전트(subagents)들로 분할되며, 각 보고서마다 증거 확인 절차를 거침
• 작업 목록은 스크롤백에 있는 것이 아니라 파일 내에 존재함

결과를 신뢰하기 전에:

• "나에게 막힌 부분(blocked on me)" 섹션을 가장 먼저 읽음
• 인간 검토 전에 모델 리뷰 패스(model review pass)가 실행됨
• 연구 답변은 확인할 수 없었던 내용과 확인했던 내용을 표시함

오늘, 한 번만:

• 플래그 설정을 확인하세요: silent switch 또는 ask-first 중 신중하게 선택하고
• 저장된 프롬프트에서 'step by step'을 grep하여 발견되는 것은 삭제하세요.

이 마지막 조언이 이 가이드 전체의 메타 교훈입니다. 프롬프팅 조언은 유효 기간이 있으며, Opus 5가 제어 가능하다는 느낌을 주었던 트릭들은 이제 마찰(friction)로 작용합니다. 2026년에 승리하는 방법은 프롬프트에 적은 단어를 줄이고 설정(config)의 구조를 늘리는 것입니다. 즉, 명확한 종료 지점, 작성된 중지 규칙, 그리고 의도적으로 선택한 설정들입니다.

Opus 5.5로 긴 자율 작업을 수행해 보셨나요? 너무 자주 허가를 요청하며 멈추었는지, 아니면 깔끔하게 진행되었는지 궁금합니다. 왜냐하면 '종료를 정의하고 놓아주는(define done and let go)' 방식이 다른 사람들에게 어떻게 작동하는지 듣고 싶기 때문입니다. 이는 작년에 우리가 모두 작업했던 방식과는 실제적인 행동 변화이기 때문입니다.