"중간에 멈추는 Claude" 졸업하기 — Sonnet 5·Opus 4.8의 자율성을 끌어올리는 5가지 팁

여러분, Claude Fable 쓰고 계신가요? 이제 곧 구독 플랜의 모델 목록에서 Fable이 빠진다고 하죠. 그래서 이번에는 Fable을 구독으로 못 쓰게 되는 상황을 가정하고, Opus와 Sonnet의 자율성을 끌어올리는 팁을 소개해 보려고 합니다.

뭐, 이미 다 아는 분도 많을지 모르겠지만요...

7월 18일기준 Anthropic이 방침을 뒤집어, 7월 20일부터 Fable 5를 Max·Team Premium 플랜에 사용 한도의 50%까지 다시 포함한다고 발표했습니다. 즉 원문의 전제는 다소 완화됐지만, 아래 팁들은 Sonnet 5·Opus 4.8을 쓰는 모든 상황에서 그대로 유효합니다.

이 글의 목적

Claude Fable은 Claude 모델 중에서도 특히 자율적으로 태스크를 진행해 주는 인상이 있죠. 그런데 사실 Sonnet 5나 Opus 4.8도 프롬프트와 하네스 설계에 따라 자율성을 상당히 끌어낼 수 있습니다. 이 글에서는 Anthropic 공식 문서를 바탕으로, Claude Code를 일상적으로 쓰는 엔지니어를 위해 "알아서 끝까지 진행해 주는" 정도를 높이는 실전 팁을 정리했습니다.

필자는 Java+JSP→React+Jakarta EE 마이그레이션 프로젝트에서 Claude Code의 스킬·커맨드를 활용한 하네스 설계를 주도하고 있습니다. 그 과정에서 얻은 노하우도 곁들여 소개할게요.

대상 독자

• Claude Code를 일상적으로 쓰는 엔지니어
• Claude Fable을 곧 못 쓰게 되어 아쉬운 분
• "Sonnet 5나 Opus 4.8이 자꾸 확인을 요구한다", "중간에 멈춘다"고 느낀 적이 있는 분
• 하네스 설계·프롬프트 설계에 관심 있는 분

동작 환경

TL;DR

• Tip 1: effort 파라미터를 올린다 (xhigh가 가장 중요한 레버)
• Tip 2: 첫 턴에서 태스크를 완전하게 정의한다 (뒤늦은 추가 금지)
• Tip 3: 툴 사용과 자율 계속 실행을 프롬프트로 명시한다
• Tip 4: 구모델용 스캐폴딩을 걷어낸다
• Tip 5: Opus 4.8은 "단일 턴 위임형"이 가성비가 좋다

Tip 1: effort 파라미터를 올린다

무엇이 문제인가

Sonnet 5·Opus 4.8은 기본값(high)으로도 어느 정도 자율적으로 움직이지만, 최고 난도의 코딩·에이전트 태스크에서는 기본값 그대로 두면 중간에 툴 호출을 일찍 끝내 버리기 쉽습니다. 특히 Opus 4.8은 툴 호출보다 추론을 우선하는 경향이 있어서, 기본 설정 그대로 두면 이 경향은 눈치채기 어려운 함정이 됩니다.

개선안

effort를 xhigh까지 끌어올리면 에이전트 검색·코딩에서 툴 사용량이 확 늘어납니다. 효과 기준은 대략 아래와 같습니다.

Sonnet 5에서는 medium으로도 Sonnet 4.6의 high 상당의 지능이 나온다고 해요. 그러니 모델을 갈아탈 때는 effort 대응 관계도 다시 살펴볼 가치가 있습니다.

effort 최상위 단계에 대해서는 출처마다 서술이 엇갈립니다. 원문 표는 max를 xhigh 위에 두었지만, Sonnet 5 출시 자료에서는 xhigh(extra high)를 최상위 신규 단계로 소개하는 서술도 있습니다. 실제 지원 단계와 순서는 모델별로 다를 수 있으니 적용 전에 공식 effort 문서를 확인하는 것을 권합니다.

왜 이렇게 설정해야 하는가

• 높은 effort 설정에서는 모델이 툴을 쓸지 말지 판단이 더 적극적으로 바뀐다
• 툴을 써 줬으면 하는 상황에서 모델이 안 쓸 때는, 프롬프트로 "왜·어떻게 써야 하는지"를 명시하는 방법도 병용할 수 있다

Tip 2: 첫 턴에서 태스크를 완전하게 정의한다

흔한 작성 방식

이 버그 고쳐 줘

이후에 "아, 이 제약도 있었지", "사실 이 파일도 봐줬으면 해" 하고 뒤늦게 정보를 덧붙여 가는 패턴은, Sonnet 5·Opus 4.8에서는 상대적으로 토큰 효율도 성능도 떨어진다고 합니다.

설마 엔지니어 여러분이 이런 프롬프트를 던지고 계시진 않겠죠?

개선안

아래 버그를 수정해 주세요.

- 증상: 로그인 후 세션이 5분 만에 끊김
- 영향 범위: src/auth/ 하위만 (다른 모듈은 변경하지 않음)
- 제약: 기존 테스트 스위트를 깨지 말 것
- 완료 조건: `npm test`가 전부 통과하고, 수동 재현 절차(별도 기재)에서 재발하지 않을 것

왜 이렇게 써야 하는가

태스크·의도·관련 제약을 첫 휴먼 턴에서 명확하고 정확하게 지정하는 것이, 자율성과 지능을 최대화하면서 불필요한 토큰 소비를 억제하는 핵심입니다. 반대로 모호한 지시를 여러 턴에 걸쳐 조금씩 내놓으면, 모델은 몇 번이고 재작업과 확인 과정을 거치게 되고, 결과적으로 사람의 개입 횟수도 늘어납니다.

이 원칙은 Sonnet 5·Opus 4.8 공통입니다. 특히 자율성이 높은 모델일수록 "처음에 얼마나 정확한 지도를 건네느냐"가 성과를 가릅니다.

뭐, 솔직히 말하면, 구체적인 지시를 내리는 게 귀찮으니까 의도를 잘 헤아려 주는 Fable이 유능한 거긴 한데요...

갑질하지 말고 깔끔하게 지시를 내립시다...

Tip 3: 툴 사용과 자율 계속 실행을 프롬프트로 명시한다

무엇이 문제인가

Sonnet 5는 사고(thinking)가 비활성 상태면 툴을 집어 들거나 검색을 고려하는 빈도가 낮아집니다. 또 장시간 태스크에서는 컨텍스트 상한이 가까워질수록 모델이 자연스럽게 태스크를 일찍 마무리하려는 경우가 있습니다.

개선안

CLAUDE.md나 시스템 프롬프트에 아래 같은 문구를 넣어 둡니다.

CLAUDE.md

당신의 컨텍스트 윈도는 상한에 가까워지면 자동으로 압축되며,
중단한 지점부터 작업을 계속할 수 있습니다.
따라서 토큰 예산을 이유로 태스크를 조기에 끝내지 마세요.
예산 한계가 가까워지면 현재 진행 상황을 메모리(파일 등)에 저장한 뒤 계속하세요.
항상 가능한 한 지속적이고 자율적으로 행동해 태스크를 완전히 완료하세요.
남은 컨텍스트와 관계없이 태스크를 인위적으로 도중에 멈추지 마세요.

툴 사용을 적극화하고 싶다면, 툴을 어디에 쓰면 되는지도 함께 구체적으로 적어 줍니다.

CLAUDE.md

웹 서치 툴을 사용할 수 있습니다. 마이그레이션 대상 라이브러리의 버전 차이나
비권장 API에 대해 확신이 서지 않을 때는, 반드시 웹 서치로 1차 정보를 확인한 뒤
구현하세요.

왜 이렇게 써야 하는가

Sonnet 5·Opus 4.8 모두, 컨텍스트 압축을 전제로 한 하네스(Claude Code 등)에서 쓸 경우 이 정보를 프롬프트 쪽에서 전달해 두지 않으면 "어쩐지 일찍 끝내 버리는" 동작이 나온다고 공식 문서가 지적하고 있습니다. 뒤집어 말하면, 이 문구 하나 넣는 것만으로 끝까지 알아서 도는 동작이 꽤 개선됩니다.

Tip 4: 구모델용 스캐폴딩을 걷어낸다

흔한 작성 방식 (구모델용)

툴을 3번 호출할 때마다 지금까지의 진행 상황을 요약해 보고해 주세요.

한때 이런 식으로 쓰는 게 유행했었죠. 한때라고 해봤자 1년 전쯤이지만요...

왜 다시 봐야 하는가

Sonnet 5·Opus 4.8은 긴 자율 실행 트레이스 안에서도 사용자에게 진행 보고를 자발적으로, 그리고 높은 품질로 수행하도록 개선되었습니다. 그래서 구모델용으로 넣어 둔 "N번마다 보고시키기" 같은 스캐폴딩은 오히려 자연스러운 보고 리듬을 무너뜨리고 보고만 장황하게 만드는 요인이 될 수 있습니다.

반대로 보고의 길이나 내용이 자기 용도에 안 맞는 경우에는, 삭제하는 게 아니라 "어떤 업데이트를 원하는지"를 구체적으로 기술하는 방향으로 조정하는 것이 권장됩니다.

개선안

- 툴을 3번 호출할 때마다 지금까지의 진행 상황을 요약해 보고해 주세요.
+ 큰 마일스톤(설계 방침 결정, 구현 완료, 테스트 결과)마다,
+ 무엇을 판단하고 어떻게 대처했는지 알 수 있는 형태로 보고해 주세요.

하네스(커스텀 커맨드나 스킬)를 많이 만들어 둔 프로젝트일수록, 모델 업데이트 타이밍에 이런 "스캐폴딩 재점검"을 할 가치가 있습니다.

Tip 5: Opus 4.8은 "단일 턴 위임형"이 가성비가 좋다

무엇이 문제인가

Opus 4.8은 대화형(인터랙티브)으로 여러 턴을 주고받는 세션에서는 사용자가 발언한 뒤에 더 많이 추론하는 경향이 있어 토큰 소비가 늘어납니다. 이는 길고 대화적인 코딩 세션에서의 일관성·지시 추종·코딩 능력 향상에 기여하는 한편, 비용은 증가합니다.

개선안

자율성·비용 효율을 중시한다면, 아래처럼 "처음에 필요한 정보를 전부 건네고 나머지는 통째로 맡기는" 형태가 어울립니다.

아래 태스크를 한꺼번에 위임합니다. 중간 경과 확인은 필요 없습니다.
완료되면 결과만 보고해 주세요.

[태스크 상세·제약·완료 조건을 모두 기재]

반대로 설계 방침을 함께 다듬어 가고 싶은 장면에서는 대화형 사용법이 더 어울립니다. 용도에 따라 구분해 쓰는 게 포인트입니다.

정리

Sonnet 5·Opus 4.8의 자율성을 최대한 끌어내려면 다음 4가지가 특히 중요합니다.

• effort를 xhigh로 올려 툴 사용과 자율 실행 깊이를 끌어올린다
• 첫 턴에서 태스크·제약·완료 조건을 완전하게 정의한다
• 툴 사용·자율 계속 실행 지시를 CLAUDE.md 등에 명시한다
• 구모델용 중간 보고 강제 같은 스캐폴딩을 재점검한다

"Fable이라서 자율적"인 게 아니라, 모델 특성에 맞춰 하네스 쪽을 조정하면 Sonnet 5나 Opus 4.8로도 충분히 자율적인 실행을 끌어낼 수 있습니다. 마이그레이션 프로젝트처럼 리뷰 지적을 줄이고 일정을 단축하고 싶은 장면에서는 이런 하네스 설계가 쌓여서 효과를 냅니다.

저 자신도 요즘 LLM 모델의 성능이 좋은 데 기대어 모호한 지시를 내리는 갑질 상사가 되어 있었기에, 저부터 조심하려고요.