스킬을 지웠더니 클로드가 더 똑똑해졌다 — Nate Herk가 정리한 Opus 5 활용법

01핵심 개요

02왜 지시를 지우면 더 나아지는가 — 모델별 재조정

앤트로픽은 새 모델이 나올 때마다 시스템 프롬프트·도구·도구 프롬프트를 대거 교체한다. 모델마다 성격·강점·약점이 완전히 다른 '다른 인격'으로 취급하기 때문. 3개월 전 특정 모델용으로 만든 설정이 다음 모델에는 전혀 안 맞을 수 있다. Opus 5는 매우 지능이 높아, 과거 시스템 프롬프트가 교정하던 행동을 이제 알아서 처리한다. 그래서 앤트로픽은 "Opus 5에서는 CLAUDE.md·스킬·훅을 아예 지우고 모델이 뭘 하는지 보라"고 직접 권고한다.

03언호블링과 프로덕트 오버행 — 이미 가진 능력을 못 쓰고 있다

'호블링(hobbling)'은 모델이 스스로 할 수 있는 일을 사용자가 가로막는 상태. '프로덕트 오버행'은 미래 모델이 아니라 지금 모델이 이미 가진 능력을 사람들이 아직 실현하지 못한 격차를 뜻한다. Boris의 처방은 두 가지다. 첫째, 모델이 할 수 있다고 생각하는 것보다 살짝 더 어려운 과제를 준다. 둘째, "1→2→3→4 순서로 이렇게만 하라"는 과잉 구체 지시 대신 과제·가드레일·종료 기준을 서술하고 모델이 알아서 풀게 둔다. 6개월 전에는 안 통했지만 지금 모델에는 통한다.

04무조건 삭제가 아니다 — 컨텍스트와 지시는 구분

Nate는 모든 스킬을 지우지 않았다. CLAUDE.md에 담긴 '비즈니스 컨텍스트'(파일 위치, 위키 위치, 브랜드 가이드)는 여전히 필요하다고 본다. 실험에서 스킬·CLAUDE.md 없이 만든 리소스 가이드는 서식·헤더가 엉성했지만, 내용은 오히려 '아이디어 단위+타임스탬프'로 더 잘 쪼개졌다. 결론은 스킬을 '완전 삭제'가 아니라 '덜 구체적으로 재작성'하라는 것. 스타일·브랜드처럼 취향을 강제하는 부분만 스킬로 남기고, 작업 방식은 모델에 위임한다. 소프트웨어를 짓는 사람은 오케스트레이션 스킬을 삭제해도 되지만, 지식노동자는 스타일 컨텍스트가 여전히 유효하다.

05핵심 방법론 — SL 목표와 자기검증

Boris는 "요즘 스킬은 프롬프트 엔지니어링이 아니라, 클로드에게 약간 버거운 과제를 주고 스스로 검증하게 만드는 것"이라며 검증을 '사람들이 가장 못하는 단일 요소'로 꼽는다. Nate의 실천법: 고수준 목표(standard)를 세우고 "이 기준에 도달할 때까지 멈추지 마라"고 지시한 뒤, 도달을 입증할 X·Y·Z 검증 방법까지 명시한다. 예로 "프로토타입·PoC 말고, 10번 테스트·반복하고 QA까지 끝나 내일 출시 가능한 결과물을 달라"고 감정을 실어 요청한다. 다른 에이전트에게 '악마의 변호인' 역할을 시켜 교차 검증하게 하는 것도 방법. "생각은 위임하되 이해는 절대 위임하지 말라"가 원칙.

06활용 시나리오

첫째, 정기 점검: 반년마다 CLAUDE.md·스킬·훅을 비운 사본을 만들어 새 모델을 돌려보고 무엇이 여전히 필요한지 재평가한다. 둘째, 스킬 슬림화: 결과가 더 나았던 '무설정' 산출물을 기준으로 삼고, 헤더 이미지·채널 링크·브랜드 컬러 같은 최소 필수 규칙만 스킬에 넣는다. 셋째, 에이전트 관리: 세션·에이전트를 '직원'처럼 다뤄 마이크로매니징 대신 목표·기준·검증을 주고, 생각을 아웃소싱하되 판단과 취향(리뷰)은 사용자가 쥔다.

07현황 및 전망

Opus 5는 지능이 높아졌지만 Nate는 일부 작업에서 이전 세대(4.8)로 되돌아가 더 나은 결과를 얻은 경험도 언급한다. 즉 새 모델이 항상 모든 작업에서 우월한 건 아니며, 재검증이 필요하다는 방증. 또한 Boris·Andrej Karpathy 같은 하네스·모델 설계자의 조언은 '거대 코드베이스를 매일 다루는 관점'이라, 지식노동 중심 사용자는 자신과 같은 방식으로 AI를 쓰는 사람의 조언을 취사선택해야 한다고 강조한다. 흐름은 프롬프트 정교화에서 '검증 가능한 위임 설계'로 이동 중.

08용어 사전