Claude 스킬을 모두 삭제했더니 더 똑똑해졌다

URL: https://www.youtube.com/watch?v=PFZWAAbQGv0 날짜: 2026-08-15 채널: Tech Bridge 원문 제목: [한영자막] 제 모든 Claude 스킬을 삭제했더니... Claude가 더 똑똑해졌습니다

---

📌 핵심 질문 / 핵심 논점

==최신 Claude 모델이 과거 모델을 위해 쌓아 둔 CLAUDE.md, 스킬(Skills), 훅(Hooks), 시스템 프롬프트(System Prompt)를 그대로 읽게 하면 오히려 능력을 제한할 수 있는가?==

• Anthropic은 새 모델이 나올 때마다 Claude Code의 시스템 프롬프트와 도구 사용 프롬프트를 대폭 수정하며, Opus 5에서는 모델이 원래 알아서 해야 할 행동을 교정하던 지침을 80% 이상 걷어냈다.
• 과거 모델에 필요한 세세한 절차를 최신 모델에게 강제하면 숙련된 작업자에게 과도한 지시를 내리는 것처럼 모델의 판단과 탐색을 방해할 수 있다.
• 다만 회사의 파일 위치, 업무 맥락, 브랜드 가이드처럼 모델이 알 수 없는 사실은 여전히 명시해야 하므로 전면 삭제보다 맥락은 남기고 실행 절차는 느슨하게 재설계하는 편이 지식 업무에 적합하다.
• 최신 에이전트 활용의 핵심은 프롬프트를 길게 쓰는 능력이 아니라 어려운 목표, 가드레일(Guardrails), 종료 기준(Exit Criteria), 검증 절차를 설계하고 에이전트의 사고를 관리하는 능력이다.

Claude Code 사용자는 모델이 이미 할 수 있는 일을 대신 지시하는 규칙을 줄이고, 모델이 모르는 업무 맥락과 품질 기준만 남겨야 한다. 사고와 아이디어는 에이전트에 위임하되, 사람이 결과를 이해하고 비전을 결정하는 책임은 유지해야 한다.

1. 새 모델이 등장하면 기존 지침이 부작용을 낳는 이유

Claude Code의 제품·하네스(Harness)·모델은 고정된 조합이 아니며, 모델이 바뀔 때마다 최적의 지시 방식도 다시 검증해야 한다.

1.1. Anthropic의 Claude Code 운영 방식

1. 시스템 프롬프트는 지속적으로 재작성된다

   1. Boris Cherny는 Claude Code가 제품인 동시에 하네스이며, 항상 무언가를 추가하고 삭제하는 구조라고 말했다.
   2. 새 모델이 나올 때마다 시스템 프롬프트의 상당 부분을 삭제하고 다른 부분을 변경한다.
   3. 도구 세트와 도구 사용 시 모델에 표시되는 프롬프트도 끊임없이 바뀐다.

2. 모델별 차이가 지침의 유효 기간을 결정한다

   1. 모델마다 성격, 강점, 결함, 프롬프트에 반응하는 방식이 모두 다르다.
   2. 3개월 전 한 모델에 맞춰 만든 규칙이 다음 모델에는 전혀 통하지 않을 수 있다.
   3. Opus 5는 매우 지능적이어서, 과거 시스템 프롬프트가 억지로 교정하던 행동을 스스로 수행한다.

1.2. “80% 이상 삭제”가 의미하는 것

1. 삭제는 기능 축소가 아니라 중복 지시 제거다

   1. Claude Code의 새 릴리스에서는 시스템 프롬프트의 80% 이상이 제거됐다.
   2. 삭제된 내용 중 상당수는 모델이 원래 알고 있어야 하지만 이전 모델에서 제대로 하지 못했던 행동을 보정하는 규칙이었다.
   3. Opus 5에서는 모델 자체의 능력이 향상되어 같은 보정 규칙을 계속 주면 오히려 불필요한 제약이 된다.

2. 새 모델마다 개인 규칙을 회귀 테스트해야 한다

   1. 새 모델이 출시될 때마다 기존 스킬을 통과시켜 실제로 작동하는지 확인해야 한다.
   2. 결과가 나오는지만 보지 말고 사용감과 품질이 여전히 건강한지도 점검해야 한다.
   3. 제작자는 Opus 5가 저하된 것처럼 느껴질 때 한동안 4.8로 돌아가 더 나은 결과를 얻었지만, 지시를 줄여 모델의 지능이 드러날 가능성은 처음에 생각하지 못했다.

2. 전면 삭제 실험과 ‘숙련자에게 어린이용 지시를 주는’ 문제

최신 모델에게 과거의 세부 절차를 그대로 강제하는 일은 능력을 보장하기보다 모델의 자율적인 문제 해결 공간을 줄일 수 있다.

2.1. Boris Cherny의 즉시 실행 권고

1. 6개월마다 Claude Code를 쓰는 사용자의 초기화 실험

   1. 에이전트 제품을 직접 개발하지 않는 사용자라면 복잡한 설정을 유지하기보다 CLAUDE.md, 스킬, 훅을 모두 삭제하고 모델이 어떻게 작동하는지 확인해 볼 수 있다.
   2. 이 실험은 기술 경험이 필요한 작업이 아니며, 삭제 전후에 같은 작업을 던져 결과와 작업 흐름을 비교하는 방식이다.
   3. Opus 5에는 과거 모델에 필요했던 지시가 정말 필요하지 않을 수 있으므로 모든 요소를 삭제해 보는 접근이 권장됐다.

2. 모델이 더 똑똑해졌다면 지시가 방해가 될 수 있다

   1. 같은 모델을 쓰면 모두 같은 결과를 얻어야 한다는 통념과 달리, 추가 지침의 양과 구체성이 결과를 달라지게 만든다.
   2. 모델이 이미 수행할 수 있는 판단까지 규칙으로 고정하면 모델의 지능을 활용하지 못한다.
   3. 핵심 질문은 “무엇을 더 지시할까?”에서 “어떤 지시가 더 이상 필요 없을까?”로 이동한다.

2.2. 10살 어린이·대학생·10년 경력자의 슬라이드 비유

1. 10살 어린이에게는 세부 지시가 안전하다

   1. 슬라이드 덱(Slide Deck)을 만드는 법을 가르친다면 10살 어린이에게는 만들어야 할 10개 슬라이드, 제목 형태, 색상, 텍스트 서식을 구체적으로 지정한다.
   2. 고위험 작업에서는 자유로운 실험보다 정해진 경로를 따르게 하는 편이 실패를 줄인다.
   3. 어린이에게는 결과를 향해 주도적으로 이끌어 주는 것이 적절하다.

2. 10년 경력자에게 같은 규칙을 주면 전문성을 막는다

   1. 수백 개의 슬라이드 덱을 만들어 본 숙련자에게 같은 세부 지시를 주면 업무를 방해한다.
   2. 숙련자는 주제 전문성(Subject Matter Expertise)과 지능을 활용해 자신만의 관점을 제시해야 한다.
   3. 모델이 더 강해질수록 과거의 상세한 절차와 제약을 줄이는 ‘모델의 족쇄 풀기(Unhobbling)’가 유효한 영역이 생긴다.

3. 실제 저장소 실험: 지침을 지운 결과와 남겨야 할 맥락

전면 삭제는 모든 사용자에게 동일한 해법이 아니다. 생성 결과의 형식보다 내용과 판단이 중요한지, 업무의 고유한 맥락을 얼마나 많이 전달해야 하는지가 기준이 된다.

3.1. CLAUDE.md가 여전히 필요한 경우

1. AI 운영 체계의 길찾기 정보는 보존한다

   1. 복제한 저장소에서 CLAUDE.md와 모든 스킬을 제거하는 실험을 진행했지만 결과는 “괜찮은” 수준에 그쳤다.
   2. CLAUDE.md는 Nate의 비즈니스 맥락, 관련 파일의 위치, 위키가 있는 곳처럼 모델이 외부에서 알 수 없는 사실을 안내한다.
   3. “필요한 자료를 어디에서 찾을 수 있는가”를 알려 주는 라우팅(Routing) 정보는 모델의 자율성과 충돌하지 않으므로 여전히 중요하다.

2. 실행 절차는 맥락 정보와 분리한다

   1. 실제 작업을 수행하는 방법까지 한 단계씩 고정하는 지침은 최신 모델의 자율적 판단을 제한할 수 있다.
   2. 업무에 필요한 고유 사실은 CLAUDE.md나 짧은 지식 기반에 남기고, 작업별 절차는 모델이 선택할 공간을 확보한다.
   3. 지식 업무에서 스킬은 브랜드·자산·출력 규격처럼 모델이 추론할 수 없는 정보를 담는 쪽으로 재편하는 것이 적합하다.

3.2. YouTube 리소스 가이드 비교

1. 스킬과 맥락이 있는 세션의 장점

   1. 인터뷰 URL을 주고 평소 다른 영상에 쓰던 YouTube 리소스 가이드를 만들어 달라고 요청했다.
   2. 결과물은 9페이지 분량으로 구성됐고, 색상·작은 블록·헤더 이미지가 포함돼 보기 좋게 정리됐다.
   3. 하단에 YouTube 채널 링크와 AIS Plus 링크가 연결돼 있었으며, 제작자의 취향과 스타일이 반영됐다.

2. 스킬과 맥락이 없는 새 세션의 장점

   1. 같은 질문을 새 세션에서 했지만 스킬과 업무 맥락은 제공하지 않았다.
   2. 결과물은 헤더가 없고 서식이 덜 깔끔해 외형만 보면 이전 결과보다 못했다.
   3. 대신 아이디어가 더 잘게 분해됐고, 각 아이디어에 타임스탬프가 붙었다.
   4. 주요 항목에 “프롬프트는 일회용이다(Prompts are disposable)”, “관찰에서 재구성(Rebuild from observation)” 같은 구분이 붙어 내용을 파악하기 쉬웠다.
   5. 세부 형식을 미리 강제하지 않았기 때문에 콘텐츠 관점에서는 스킬이 없는 버전이 더 좋다고 판단됐다.

3. 재설계가 전면 삭제보다 실용적인 절충안이다

   1. 리소스 가이드의 구조와 분해 방식은 모델이 자유롭게 결정하도록 둔다.
   2. 헤더에는 지정 이미지를 넣고, 위쪽에는 YouTube 채널 링크를, 아래쪽에는 AIS Plus 링크를 넣으라는 안정적인 브랜드 요구만 스킬로 남긴다.
   3. 스킬을 없애는 대신 “원하는 방식으로 만들되 반드시 지켜야 할 맥락만 준다”는 형태로 구체성을 낮춘다.

4. 조언을 업무 맥락에 맞게 검증하는 법

모델 사용 방식이 다르면 동일한 조언의 가치도 달라진다. 제품·소프트웨어 개발자의 하네스 설계 조언과 지식 노동자의 문서 생성 업무를 같은 규칙으로 묶어서는 안 된다.

4.1. 조언의 출처와 사용 방식을 맞춘다

1. 권위 있는 조언도 일괄 적용하지 않는다

   1. Boris Cherny, Andrej Karpathy, 다른 YouTube 제작자, 커뮤니티 구성원의 조언을 업무에 그대로 적용하면 안 된다.
   2. 좋은 조언이라도 조언자의 작업 환경과 목표가 사용자와 다르면 결과가 달라진다.
   3. 자신이 AI를 어떤 방식으로 쓰는지에 맞춰 같은 방식으로 사용하는 사람의 조언을 우선 참고해야 한다.

2. 하네스 엔지니어와 지식 노동자의 차이

   1. Boris와 Karpathy의 관점은 하네스를 설계하고, 매일 거대한 코드베이스를 다루고, 모델을 훈련하는 현장 경험에서 나온다.
   2. 지식 노동자의 주된 업무가 연구, 지식 습득, 문서 작성, 결과물 제작이라면 소프트웨어 구축자를 위한 규칙을 그대로 적용할 필요가 없다.
   3. 제품·소프트웨어 개발자는 구축과 오케스트레이션(Orchestration)을 위한 스킬을 많이 보유하므로 모델과 하네스가 그 역할을 더 잘하는지 전면 삭제 실험을 할 수 있다.

4.2. 지식 업무에서 남겨야 할 구체성

1. 브랜드와 자산은 모델이 추론할 수 없는 사실이다

   1. 특정 이미지를 가져와 특정 위치에 넣어야 한다는 요구는 단순한 작업 순서가 아니라 결과물의 정체성을 결정하는 맥락이다.
   2. 브랜드 가이드라인의 색상 체계, 채널 링크, 서비스 링크도 모델이 일반 지식만으로 알아낼 수 없다.
   3. 이런 요구는 스킬에 남기되, 그 외의 구성·분해·표현 방식은 최신 모델의 판단에 맡기는 편이 좋다.

2. 테스트 결과로 유지 여부를 판단한다

   1. 전부 지워서 더 나아지는지, 일부를 완화해 더 나아지는지, 원래 설정이 필요한지 동일한 작업으로 비교한다.
   2. 삭제 자체를 목표로 삼지 말고 결과물의 내용·정확성·브랜드 일관성·재현성을 기준으로 판단한다.
   3. 지식 업무에서는 모든 자료를 쓸어내리기보다 스킬을 다시 설계하는 편이 더 가치 있을 수 있다.

5. 모델을 방해하지 않는 프롬프트와 제품 오버행

Boris Cherny가 말한 ‘호블링(Hobbling)’과 ‘제품 오버행(Product Overhang)’은 최신 모델의 잠재력을 사용자가 과소평가하는 문제를 드러낸다.

5.1. 호블링과 제품 오버행

1. 호블링은 사람이 모델의 작업을 방해하는 현상이다

   1. 연구에서 호블링은 모델이 무언가를 수행하는데 사람이 그 앞을 가로막는 상황을 뜻한다.
   2. 모델이 이미 더 나은 해결책을 찾을 수 있는데 사용자가 세부 절차를 고정하면 모델의 탐색 공간이 좁아진다.
   3. 이 개념은 제품 개발에서 사용자의 지시가 제품 능력을 제한하는지 점검하는 기준이 된다.

2. 제품 오버행은 현재 모델의 미사용 능력이다

   1. 제품 오버행은 미래 모델이 아니라 지금 가진 모델도 아직 실현하지 못한 기능을 수행할 수 있다는 뜻이다.
   2. 모델에는 사용자가 인식하지 못하는 능력이 많이 남아 있다.
   3. 따라서 모델이 할 수 있다고 생각하는 한계보다 약간 더 어려운 작업을 맡기는 실험이 필요하다.

5.2. 단계별 지시 대신 목표·가드레일·종료 기준을 준다

1. 과도하게 구체적인 절차를 줄인다

   1. 흔한 실수는 “이 일을 하되 이 방식, 저 방식, 또 다른 방식으로 하라”고 지시하는 것이다.
   2. “먼저 하나, 다음 둘, 그다음 셋, 마지막 넷”처럼 순서를 고정하는 접근은 최신 모델에 적합하지 않을 수 있다.
   3. 6개월 전에는 작동하지 않던 상위 수준의 위임이 현재 모델에서는 작동한다.

2. 높은 수준의 실행 계약을 정의한다

   1. 먼저 작업의 목적과 범위를 제시한다.
   2. 지켜야 할 가드레일과 금지 조건을 제시한다.
   3. 무엇을 충족하면 끝낼지 종료 기준을 정의한다.
   4. 그다음 모델이 스스로 계획하고 실행하도록 두고, 잠시 후 결과를 확인한다.

6. 좋은 결과를 만드는 기준과 검증 설계

자율성을 주는 일은 품질 기준을 없애는 일이 아니다. 오히려 사람이 기대하는 품질을 명확히 말하고, 모델이 그 기준 충족을 스스로 입증하게 해야 한다.

6.1. “좋은 결과”를 정의하는 책임

1. 모델이 좋은 결과의 기준을 모르면 품질을 맞출 수 없다

   1. Claude에게 작업을 맡겼는데 결과가 평범하면 모델만 탓하기 쉽다.
   2. 하지만 사용자가 좋은 결과가 무엇인지 말하지 않았다면 모델이 그 기준을 알 방법이 없다.
   3. 사용자는 높은 수준의 목표와 품질 표준을 설정하고, 완료될 때까지 멈추지 말라고 명시해야 한다.

2. 완료 선언보다 증거를 요구한다

   1. 목표 달성을 입증하려면 X·Y·Z 같은 구체적인 행동을 수행해야 한다고 적는다.
   2. 모델은 그 행동을 실행하고, 기준에 도달했음을 실제로 증명할 때까지 반복한다.
   3. 사용자가 매번 직접 검증하지 않아도 되도록 검증 방법을 목표 정의 안에 포함한다.

6.2. 프로토타입이 아닌 출시 가능한 결과를 요구한다

1. SL 목표에 품질 조건을 붙인다

   1. 표준과 검증 방법을 모두 적은 뒤, “프로토타입이나 개념 증명(Proof of Concept)을 원하는 것이 아니다”라고 선을 긋는다.
   2. 최소 10회 테스트와 반복 작업을 거친 결과를 요구한다.
   3. 완전한 QA(Quality Assurance)를 수행하고 다음 날 시장에 출시할 수 있는 상태를 목표로 삼는다.

2. 감정이 목표의 강도를 높일 때도 있다

   1. 출시 가능한 품질을 요구하는 문장은 단순한 기능 목록보다 목표를 더 생생하게 만든다.
   2. 감정이 실린 표현을 프롬프트에 넣었을 때 더 좋은 결과가 나오는 경우가 있다.
   3. 감정적 문구 자체보다 품질 기준·검증 행동·반복 횟수가 명시된 점이 핵심이다.

6.3. 검증이 최신 에이전트 활용의 중심이다

1. 프롬프트 엔지니어링보다 어려운 과제 설계가 중요하다

   1. Boris는 오늘날의 스킬이 프롬프트를 꾸미는 능력보다 Claude에게 충분히 어려운 작업을 주는 능력에 가깝다고 말했다.
   2. 동시에 Claude가 작업 중간중간 자신의 결과를 검증할 수 있도록 설계해야 한다.
   3. 사람들은 검증을 제대로 설계하지 못하는 경우가 많으며, 검증은 가장 중요한 능력으로 꼽혔다.

2. 검증 루프를 에이전트 안에 넣는다

   1. 작업이 끝난 뒤 한 번 확인하는 대신 실행→검사→수정→재검사의 루프를 목표에 포함한다.
   2. 다른 에이전트가 반대 의견을 제시하게 하면 자기확증을 줄일 수 있다.
   3. 에이전트 스스로 결과를 확인하게 하되, 최종 판단에 필요한 이해는 사람이 보유한다.

7. 도구보다 중요한 AI 에이전트 관리

Claude Code, Hermes, Agent Code 가운데 무엇을 쓰든 에이전트를 관리하는 원리는 도구에 종속되지 않는다.

7.1. 사람을 관리하듯 에이전트를 관리한다

1. 좋은 관리자는 마이크로매니지먼트(Micromanagement)를 하지 않는다

   1. 좋은 관리자는 “이렇게 해야 하고, 이 방식으로 하고, 가서 실행하라”고 모든 단계를 대신 결정하지 않는다.
   2. 팀의 작업을 방해하지 않고, 중간에 확인하고, 결과를 리뷰하며, 판단력과 감각을 발휘한다.
   3. 동시에 구성원이 자신의 두뇌와 전문성을 사용할 여지를 보장한다.

2. 에이전트를 고용한 이유를 존중한다

   1. 각 세션과 에이전트는 특정 작업을 맡기기 위해 만든 것이므로 사고를 전부 대신 수행할 필요가 없다.
   2. 사고와 아이디어 생성은 에이전트에 맡기고, 다른 에이전트가 악마의 변호인(Devil’s Advocate) 역할을 하게 한다.
   3. 에이전트가 스스로 작업을 점검하고 검증할 수 있는 권한과 절차를 부여한다.

7.2. 사고는 위임하되 이해는 위임하지 않는다

1. 위임 가능한 것

   1. 초안 작성, 대안 생성, 조사, 분해, 구현 계획, 반복 테스트는 에이전트가 수행할 수 있다.
   2. 여러 에이전트의 토론과 반론을 이용하면 아이디어의 약점을 빨리 찾을 수 있다.
   3. 모델이 스스로 검증하는 구조를 만들어 사람의 반복 확인 비용을 줄일 수 있다.

2. 사람이 유지해야 하는 것

   1. “사고의 일부는 위임하되 이해는 절대 위임하지 않는다”는 원칙을 유지한다.
   2. 사람은 여전히 에이전트들의 설립자이며, 비전과 성공 기준을 제시하는 주체다.
   3. 에이전트가 강력한 조력자가 되어도 사용자는 결과가 무엇을 의미하는지 이해하고 방향을 결정해야 한다.

주요 발언 모음

“새 모델이 나올 때마다 시스템 프롬프트의 상당 부분을 삭제하고, 다른 부분을 변경합니다.” — Boris Cherny

“Opus 5는 정말 지능적입니다. 시스템 프롬프트의 많은 내용은 모델이 알아서 했어야 하지만 하지 못했던 행동을 교정하는 것이었고, 이제 Opus 5가 그 일을 스스로 합니다.” — Boris Cherny

“CLAUDE.md를 삭제하고, 스킬을 삭제하고, 훅을 삭제해 보세요. 모델이 어떻게 작동하는지 확인하면 놀랄 수도 있습니다.” — Boris Cherny

“10년 동안 일하며 수백 개의 슬라이드 덱을 만든 사람에게 어린이에게 주는 것과 같은 지시를 하면 오히려 방해가 됩니다.” — Tech Bridge 제작자의 설명

“프롬프트는 일회용입니다. 관찰에서 재구성하세요.” — 스킬 없는 리소스 가이드에 나타난 구분

“작업을 설명하고, 가드레일을 설명하고, 종료 기준을 설명한 다음 모델이 스스로 작동하도록 두세요.” — Boris Cherny

“좋은 결과가 무엇인지 모른다면 어떻게 좋은 결과를 만들 수 있겠습니까?” — Tech Bridge 제작자의 설명

“프로토타입이나 개념 증명이 아니라, 10번 테스트하고 반복했으며 완전한 QA를 마쳐 내일 시장에 출시할 수 있는 결과를 원합니다.” — SL 목표 예시

“오늘날의 스킬은 프롬프트 엔지니어링보다 Claude에게 어려운 과제를 주고, 작업 중 검증할 수 있게 만드는 데 더 가깝습니다.” — Boris Cherny

“사고의 일부는 위임하되 이해는 절대 위임하지 마세요.” — AI 에이전트 운영 원칙

핵심 데이터 & 수치

• 80% 이상: Claude Code 새 릴리스에서 삭제된 시스템 프롬프트의 비율.
• 3개월: 한 모델에 맞춰 만든 작업이 다음 모델에서 통하지 않을 수 있는 시간 차이의 사례.
• 6개월: Claude Code를 가끔 사용하는 사용자가 지침을 초기화해 보기 좋은 주기와, 과거에는 안 되던 상위 수준 위임이 현재 작동할 수 있음을 비교한 기준.
• 10살: 세부 절차와 제약을 많이 줘야 하는 학습자의 예시.
• 10년 경력: 동일한 세부 절차가 오히려 전문성을 막을 수 있는 숙련자의 예시.
• 수백 개: 10년 경력자가 만들어 본 슬라이드 덱의 규모.
• 9페이지: 스킬과 업무 맥락이 있는 세션에서 생성된 YouTube 리소스 가이드의 분량.
• 10개 슬라이드: 어린이에게 제시하는 구체적인 제작 지시의 예시.
• 10회 이상: 프로토타입을 넘어 출시 가능한 결과를 만들기 위해 요구한 테스트·반복 횟수.
• 35분: Y Combinator 채널에 공개된 Boris Cherny 인터뷰의 길이.

결론 및 시사점

1. 새 모델마다 초기화 실험을 한다: 기존 CLAUDE.md, 스킬, 훅을 복사본에서 잠시 제거하고 동일한 작업을 수행해 불필요한 제약을 확인한다.
2. 고유 맥락은 남긴다: 파일·위키 위치, 업무 규칙, 브랜드 색상, 필수 이미지·링크처럼 모델이 모르는 사실은 짧고 명확하게 보존한다.
3. 절차의 구체성은 낮춘다: 모델이 이미 아는 행동을 1·2·3·4단계로 강제하지 말고 목표·가드레일·종료 기준을 제공한다.
4. 품질 기준을 수치화한다: “좋게 만들어라”에서 멈추지 말고 테스트 횟수, QA 범위, 출시 조건, 성공을 증명할 행동을 명시한다.
5. 검증을 자동화한다: 에이전트가 결과를 스스로 검사하고 수정하며, 다른 에이전트가 반론을 제시하도록 세션을 설계한다.
6. 사용 방식에 맞는 조언을 채택한다: 코드베이스·하네스 구축자와 문서·연구 중심 사용자의 최적 설정은 다르므로 자신의 업무로 회귀 테스트한다.
7. 사고와 이해를 분리한다: 아이디어·초안·반복 작업은 위임하되, 결과의 의미와 방향을 이해하고 결정하는 책임은 사람이 가진다.

핵심 요약 (20줄)

Claude Code의 새 모델은 과거 모델을 보정하던 시스템 프롬프트가 없어도 더 많은 행동을 스스로 수행할 수 있다. Anthropic은 새 모델이 나올 때마다 시스템 프롬프트와 도구 사용 프롬프트를 삭제하고 수정한다. Opus 5에서는 과거 모델에 필요했던 보정 지침이 모델의 기본 능력과 중복될 수 있다. 최신 모델을 평가할 때는 기존 스킬이 작동하는지뿐 아니라 지침이 모델을 방해하는지도 확인해야 한다. Boris Cherny는 Claude Code를 가끔 사용하는 사람에게 CLAUDE.md, 스킬, 훅을 삭제하는 실험을 권했다. 과거 모델을 위해 만든 세부 절차가 최신 모델의 판단 공간을 줄일 수 있다. 10살 어린이에게는 슬라이드 수와 색상까지 지시하지만 숙련자에게는 같은 방식의 지시가 방해가 된다. 모델의 족쇄 풀기는 모델이 이미 할 수 있는 일을 사용자가 대신 고정하지 않는 접근이다. 복제 저장소에서 설정을 모두 지운 결과는 외형보다 아이디어 분해와 내용 면에서 더 나았다. 스킬이 없는 리소스 가이드는 주요 아이디어마다 타임스탬프를 붙여 콘텐츠를 더 명확하게 구성했다. 헤더 이미지와 브랜드 색상처럼 모델이 알 수 없는 취향과 사실은 스킬에 남겨야 한다. 전면 삭제보다 안정적인 맥락은 보존하고 실행 절차의 구체성은 낮추는 재설계가 실용적이다. Boris Cherny와 Andrej Karpathy의 조언은 하네스와 대규모 코드베이스를 다루는 관점에서 해석해야 한다. 지식 노동자는 연구와 문서 작성에 맞는 사용자들의 사례를 기준으로 설정을 검증해야 한다. 호블링은 사람이 모델의 작업을 방해하는 현상이며 제품 오버행은 현재 모델의 미사용 능력이다. 최신 모델에는 세부 단계보다 작업 목표, 가드레일, 종료 기준을 높은 수준에서 제시해야 한다. 6개월 전에는 통하지 않던 상위 수준 위임이 현재 모델에서는 작동할 수 있다. 좋은 결과의 기준과 성공을 증명할 행동을 명시하면 모델이 스스로 검증할 수 있다. 프로토타입 대신 10회 이상 테스트와 완전한 QA를 거친 출시 가능한 결과를 요구할 수 있다. AI 에이전트에게 사고를 위임하되 결과를 이해하고 비전을 결정하는 책임은 사람에게 남는다.