YouTubeSolo Swift Crafter·2026년 10월 3일·0

Anthropic Just Opened Up Claude Code — Mods vs Hooks vs Skills vs MCP

Quick Summary

영상은 Claude Code의 Mods를 하네스 내부에서 실행과 화면을 바꾸는 확장으로 설명하며, Hooks의 이벤트 처리·Skills의 지침·MCP의 외부 서비스 연결과 구분한다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

Anthropic Just Opened Up Claude Code — Mods vs Hooks vs Skills vs MCP 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Anthropic Just Opened Up Claude Code — Mods vs Hooks vs Skills vs MCP의 핵심 내용을 4단계로 요약한 인포그래픽
Anthropic Just Opened Up Claude Code — Mods vs Hooks vs Skills vs MCP 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

영상은 Claude Code의 Mods를 하네스 내부에서 실행과 화면을 바꾸는 확장으로 설명하며, Hooks의 이벤트 처리·Skills의 지침·MCP의 외부 서비스 연결과 구분한다.

📌 핵심 요점

  1. Mods의 핵심은 하네스 내부 개입이다. 발표자는 명령 실행 직전에 내용을 수정하거나 실행을 차단하고, 화면에 표시되는 응답도 바꿀 수 있다고 설명한다.
  2. 역할에 따라 확장을 선택해야 한다. 기존 스크립트로 특정 동작을 막으려면 Hook, Claude에 지침을 제공하려면 Skill, 다른 서비스와 연결하려면 MCP, 세션 상태와 화면·실행 흐름을 다루려면 Mod가 적합하다는 구분이다.
  3. Mod는 세션에 상주하며 상태를 유지한다. 영상에서는 지속적으로 갱신되는 패널, 사용자 확인을 기다리는 명령, 모델 호출 없이 실행되는 슬래시 명령을 사례로 든다.
  4. 구현과 실험의 진입점은 작다. 영상 설명에 따르면 플러그인의 hooks 파일에서 JavaScript·TypeScript 파일을 가리키고, 플래그로 로드한 뒤 저장할 때마다 실행 중인 세션에 변경 사항을 반영할 수 있다.
  5. 내부 확장인 만큼 검토 책임도 커진다. 발표자는 출처가 불분명한 Mod의 네트워크 호출을 경계하고, 강제 푸시 차단처럼 동작 원리를 설명할 수 있는 작은 기능부터 직접 만들어 보라고 권한다.

🧩 배경과 문제 정의

발표자는 기존 Claude Code 확장 방식을 에이전트 주변에 지침과 기능을 덧붙이는 구조로 묘사한다. Skills·Hooks·MCP가 유용하더라도, 사용자가 하네스 자체의 행동과 화면을 원하는 수준으로 바꾸기는 어렵다는 것이 영상의 출발점이다.

Mods는 이 문제에 대한 내부 확장 방식으로 소개된다. 명령 실행 직전에 개입하고 세션 상태를 유지하며 화면까지 수정할 수 있다는 설명을 통해, 실행 후 수습보다 실행 전 제어에 초점을 맞춘다. 동시에 내부에서 돌아가는 코드를 이해하지 않고 설치하면 보안과 유지보수 위험이 커진다는 문제도 함께 제기한다.

🕒 시간순 섹션별 상세정리

1. Mods가 바꾸는 하네스의 제어 범위

  • 발표자는 Anthropic의 Mods 도입을 행동·UI·하네스를 직접 바꿀 수 있는 변화로 보여준다. 기존 Skills·Hooks·MCP를 외부 확장으로 묘사하고, Mods는 하네스 내부에서 실행 직전에 수정하거나 차단할 수 있다고 보여준다. [01:08]
  • 모델 래퍼, 도구, 에이전트 루프를 플러그인으로 다루는 DeepSeek 사례와 개방형 하네스를 선행 사례로 언급한다. 강조점은 최초 도입 경쟁보다 실제 행동을 좌우하는 하네스의 중요성이다. [01:55]
  • 기본 Claude Code로 충분한 사용자에게는 급한 변화가 아니지만, 저장소에서 허용하면 안 되는 명령을 실행 전에 막고 싶은 사용자에게는 의미가 크다고 주장한다. [02:29]

2. 작업 환경의 소유와 Mod 구현 방식

  • 발표자는 자신의 iOS 개발 경력과 독립 작업 전환을 소개하며, Crafter’s Lab을 남의 설정을 복제하는 과정 대신 각자의 작업 환경을 이해하고 만드는 워크숍으로 홍보한다. [03:13]
  • Mod는 추가 설정이 붙은 플러그인으로 드러난다. 기존 플러그인·hooks 파일 구조에서 hooks 파일이 JavaScript 또는 TypeScript 파일을 가리키고, 해당 파일이 Claude Code 내부에서 실행된다고 드러낸다. [03:33]
  • 별도 빌드나 번들링 없이 플래그로 로드하고, 폴더를 감시해 저장할 때마다 실행 중인 세션에 변경 사항을 반영하는 방식을 보여준다. [03:43]

3. 명령 가로채기, 화면 가림, 세션 상태

  • 강제 푸시를 예로 들어, 실행 직전에 실제 명령과 제어 수단을 전달받는다고 보여준다. next로 실행을 넘기거나, 새 브랜치로 향하도록 명령을 바꾸거나, next를 호출하지 않고 차단하는 선택지를 제시한다. [04:33]
  • 응답 화면에서 이메일 등 개인 정보를 지우는 사례를 보여준다. 이때 모델은 실제 주소로 계속 작업하고, 사용자에게 보이는 내용만 바뀐다고 구분한다. [04:52]
  • Hooks는 이벤트마다 실행·종료되고 Mods는 세션에 상주한다는 비교를 통해 상태 유지, 패널 갱신, 사용자 확인, 모델 호출 없는 슬래시 명령을 보여준다. 이어 diff 화면과 agents.md 지원도 Mods로 구현되고 있다고 주장한다. [05:52]

4. 시작 방법과 확장 선택 기준

  • 최신 Claude Code 또는 데스크톱 앱의 /plugin에서 내장 Mods와 Mod 작성용 Skill을 찾을 수 있다고 보여준다. 도구 호출 횟수를 세는 작은 예시와 대화 이력에 맞춘 Mod 자동 생성을 실험 방향으로 제안한다. [06:31]
  • 출처가 불분명한 Mod를 무작정 설치하지 말라고 경고한다. 특히 비밀 정보를 숨긴다는 확장이 네트워크 호출을 한다면 그 이유를 알아야 하며, 하네스 내부의 확장은 실제 보안 위험이 될 수 있다고 드러낸다. [07:01]
  • 기존 스크립트로 차단하면 Hook, 지침이면 Skill, 외부 서비스 연결이면 MCP, 화면·상태·확인 절차·경험 전반을 바꾸려면 Mod라는 선택 기준을 제시한다. Mod 마켓플레이스와 부적절한 확장의 등장도 예상한다. [07:45]

5. 작은 제어 장치에서 시작하고 동작 이유를 이해하기

  • 발표자는 각자의 설정이 달라지는 방향을 긍정적으로 보며, 첫 실험으로 화려한 패널보다 실행 앞에 놓이는 강제 푸시 차단 장치를 권한다. [08:28]
  • 인기 Mod를 가져다 쓰는 방식은 Claude Code 업데이트 이후 동작 이유를 설명할 수 없게 될 수 있다고 지적한다. 이어 Crafter’s Lab과 ops lab의 홍보를 통해 실제 구현과 설계 이유를 함께 학습한다는 메시지를 반복한다. [09:31]
  • 영상에서 이해한 작은 기능을 직접 만들어 보라고 권하며 마무리한다. 마지막 원칙은 스스로 설명할 수 없는 코드를 자신의 하네스 내부에서 실행하지 않는 것이다. [09:54]

🧾 결론

  • 영상이 강조하는 변화는 기본 설정을 수용하는 데서 벗어나, Claude Code의 실행 환경을 자신의 작업 방식에 맞게 구성하는 것이다.
  • Mods는 기존 확장 전체를 대체하는 선택지로 제시되지 않는다. 지침, 외부 연결, 단발성 차단, 지속적인 상태·화면 제어라는 요구에 따라 도구를 나누는 것이 핵심이다.
  • 첫 실험으로는 강제 푸시 차단이 제안된다. 실행 직전에 개입하는 기능을 작고 명확한 사례로 이해할 수 있기 때문이다.
  • 설정을 소유한다는 것은 파일을 복사하는 데서 끝나지 않는다. 왜 그렇게 동작하는지 설명하고, 업데이트 이후에도 이해하며 유지할 수 있어야 한다는 것이 마지막 메시지다.

📈 투자·시사 포인트

  • 개발 도구의 차별화 요소로 모델 성능뿐 아니라 하네스의 확장성과 실행 제어가 부각된다. 영상은 실제 에이전트 행동의 상당 부분이 하네스에서 결정된다고 주장한다.
  • Mod 마켓플레이스의 등장은 발표자의 전망이다. 이 전망을 평가하려면 실제 확장 공급, 사용자 채택, 유지보수와 검증 체계가 형성되는지 살펴볼 필요가 있다.
  • 확장 생태계의 성장은 검토·호환성 관리 부담도 함께 키울 수 있다. 영상은 신뢰하기 어려운 확장과 Claude Code 업데이트 이후의 동작 불확실성을 위험으로 제시한다.
  • 개인과 팀의 실무 경쟁력은 인기 설정을 복제하는 것보다 작업에 맞는 제어 장치를 설계하고 설명하는 능력에서 찾을 수 있다는 시사점을 준다.

⚠️ 불확실하거나 확인이 필요한 부분

  • Mods의 제공 버전, 데스크톱 지원 범위, 로딩 플래그와 API 명세는 영상에서 구체적으로 제시되지 않는다. 최신 환경에서 바로 사용할 수 있다는 설명은 실제 사용 환경에서 확인해야 한다.
  • 발표자는 Hooks를 이벤트마다 실행되고 종료되는 셸 스크립트로 단순화해 비교한다. 이 설명만으로 모든 Hook 구현의 기능 범위나 Mods와의 차이를 확정하기는 어렵다.
  • 화면에서 이메일을 지우는 예시에서도 모델은 실제 주소를 계속 사용한다고 명시한다. 화면 가림과 모델에 전달되는 정보의 차이를 구분해야 한다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 해결하려는 요구를 지침 제공, 외부 서비스 연결, 단발성 명령 차단, 세션 상태·화면 제어로 나누고 Skill·MCP·Hook·Mod 중 적합한 방식을 선택한다.
  • 사용하는 Claude Code 환경에서 Mods 지원 여부와 실제 로딩·호출 방식을 확인한다.
  • 강제 푸시 차단처럼 범위가 작은 Mod를 만들고, 허용할 명령은 통과하며 금지할 명령은 실행 전에 멈추는지 확인한다.
  • 외부 Mod를 설치하기 전에 실행 코드와 네트워크 호출을 읽고, 해당 동작이 기능에 필요한 이유를 설명할 수 있는지 점검한다.

❓ 열린 질문

  • 실행 직전에 개입하는 Mod와 기존 Hook의 실제 API·제어 범위는 어디까지 겹치며, 어떤 요구에서 차이가 결정적인가?
  • 여러 Mod가 같은 명령이나 화면 출력을 바꾸면 실행 순서와 충돌을 어떻게 관리할 수 있는가?
  • 마켓플레이스가 형성될 경우 확장의 신뢰성과 업데이트 호환성을 누가, 어떤 방식으로 검증할 것인가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.