Claude Code를 내 마음대로 뜯어고친다

이경규·약 18시간 전

Claude Code를 내 마음대로 뜯어고친다

Hooks보다 더 깊게 들어가는 Mods — Prompt·Tool Call·Permission·UI까지 바꾼다

Claude Code를 사용하다 보면 한 번쯤 이런 생각을 하게 됩니다.

이 명령은 매번 승인하지 않았으면 좋겠는데.

이 Tool은 실행 전에 내용을 조금 바꾸고 싶은데.

Production 명령만 더 강하게 막을 수 없을까?

Claude Code 화면에 CI 상태를 같이 보여주면 편할 텐데.

기존에는 CLAUDE.md, Hooks, Skills, MCP 등을 조합해서 이런 요구를 해결했습니다.

그런데 2026년 10월 1일 Anthropic이 Claude Code Mods를 공개했습니다.

Mods는 단순히 새로운 명령어를 추가하는 기능이 아닙니다.

Claude Code가 동작하는 중간에 들어가서:

Prompt 수정

Tool Call 수정

Permission 승인/거부

Tool 결과 필터링

UI 변경

기존 기능 교체

까지 할 수 있습니다.

쉽게 말하면 이제 Claude Code를 사용하는 데서 끝나는 게 아니라,

Claude Code 자체의 동작을 개발자가 바꿀 수 있게 된 겁니다.


1. Mod는 작은 TypeScript 함수다

Anthropic이 설명하는 Mod의 기본 형태는 생각보다 단순합니다.

Claude Code가 작업하면서 어떤 일이 발생하면 Event가 생깁니다.

예를 들어:

Prompt 입력

Tool 호출

Permission 요청

Tool 결과 반환

UI 표시

같은 이벤트입니다.

Mod는 그 이벤트 사이에 들어갑니다.

Claude Code

    ↓

Event

    ↓

Mod

    ↓

변경된 Event

    ↓

Claude Code

그리고 Mod 자체는 작은 TypeScript 함수로 작성합니다.

그래서 완전히 새로운 Agent Framework를 배울 필요는 없습니다.


2. Hook과 비슷해 보이는데 뭐가 다를까

Claude Code에는 이미 Hooks가 있습니다.

Hooks도 특정 이벤트에 맞춰 Shell Command나 Script를 실행할 수 있습니다.

예를 들면:

파일 수정
    ↓
Hook
    ↓
SwiftLint 실행

또는:

Tool 사용
    ↓
Hook
    ↓
Log 기록

같은 방식입니다.

그런데 Hooks에는 중요한 제한이 있습니다.

이벤트를 관찰하거나 외부 작업을 실행하는 데는 좋지만, Claude Code 내부의 이벤트 자체를 자유롭게 바꾸기는 어렵습니다.

Mods는 여기서 한 단계 더 들어갑니다.


3. Hooks는 반응하고, Mods는 개입한다

가장 단순하게 나누면 이렇습니다.

Hooks

Event 발생
    ↓
외부 Script 실행

Mods

Event 발생
    ↓
Event 내용 확인
    ↓
변경 / 차단 / 대체
    ↓
Claude Code 계속 실행

즉 Hooks가:

무슨 일이 일어났으니 이것도 실행해.

에 가깝다면,

Mods는:

이 일이 일어나기 전에 내가 내용을 바꿀게.

에 더 가깝습니다.


4. Prompt가 모델에 들어가기 전에 바꿀 수 있다

예를 들어 사용자가:

이 코드 수정해줘.

라고 입력했다고 해보겠습니다.

Mod를 중간에 넣으면 실제 모델에게 전달되기 전에:

이 코드 수정해줘.

추가 규칙:
- 요청 범위 밖의 Refactoring 금지
- 수정 후 관련 Test 실행
- Architecture 변경 시 먼저 사용자에게 설명

같은 내용을 자동으로 붙일 수 있습니다.

구조는:

사용자 Prompt
      ↓
     Mod
      ↓
프로젝트 규칙 추가
      ↓
    Claude

가 됩니다.

매번 긴 Prompt를 사람이 반복해서 입력할 필요가 없습니다.


5. Tool Call도 직접 바꿀 수 있다

이게 Mods에서 특히 재미있는 부분입니다.

Claude가 이런 명령을 실행하려고 한다고 해보겠습니다.

rm -rf ./build

Tool Call이 실제 실행되기 전에 Mod가 볼 수 있습니다.

그리고 조건에 따라:

허용

차단

내용 변경

다시 시도

사용자 승인 요청

중 하나를 선택할 수 있습니다.

예를 들면:

Claude
   ↓
Bash Tool Call
   ↓
Mod
   ↓
Production 관련 명령인가?
   ↓
YES
   ↓
실행 중지

같은 Guardrail을 만들 수 있습니다.


6. Tool Call을 아예 다시 작성할 수도 있다

단순 차단만 가능한 것도 아닙니다.

Claude가:

kubectl delete pod production-api

같은 명령을 만들었다고 해보겠습니다.

Mod가 이를 감지해서:

kubectl get pod production-api

처럼 안전한 확인 명령으로 먼저 바꿀 수도 있습니다.

또는:

Production 명령입니다.

실행 전에 사용자 승인이 필요합니다.

라는 별도 흐름으로 넘길 수도 있습니다.

즉 Claude가 만든 Tool Call을 Policy Layer에서 한 번 더 제어할 수 있습니다.


7. Permission도 자동으로 처리할 수 있다

Claude Code를 쓰다 보면 Permission 창을 자주 만나게 됩니다.

이 명령을 실행해도 될까요?

이 파일을 수정해도 될까요?

이 Tool을 사용해도 될까요?

보안을 위해 필요한 기능이지만 반복 작업에서는 귀찮을 수 있습니다.

Mods를 사용하면 조건에 따라 자동 처리할 수 있습니다.

예를 들어:

npm test
→ 자동 승인

swift test
→ 자동 승인

xcodebuild test
→ 자동 승인

rm
→ 승인 필요

git push
→ 승인 필요

Production 관련 명령
→ 무조건 승인 필요

같은 규칙입니다.


8. 개발 프로젝트마다 Permission 정책을 만들 수 있다

예를 들어 iOS 프로젝트라면:

파일 읽기
→ 자동 허용

Sources/ 수정
→ 허용

Tests/ 수정
→ 허용

xcodebuild
→ 자동 허용

Simulator 실행
→ 자동 허용

git commit
→ 확인

git push
→ 확인

Release 배포
→ 차단 또는 승인 필수

처럼 만들 수 있습니다.

이렇게 되면 Permission을 단순히:

Claude에게 많이 허용한다

또는:

Claude에게 아무것도 허용하지 않는다

로 나누지 않아도 됩니다.

업무에 따라 세밀하게 권한을 나눌 수 있습니다.


9. Tool 결과도 Claude가 보기 전에 수정할 수 있다

Claude가 Tool을 실행한 뒤 받는 결과도 Mod가 가로챌 수 있습니다.

예를 들어 CLI 결과에 이런 값이 포함됐다고 해보겠습니다.

API_KEY=abc123...
DATABASE_PASSWORD=...
ACCESS_TOKEN=...

그대로 Claude에게 넘기지 않고:

API_KEY=[REDACTED]
DATABASE_PASSWORD=[REDACTED]
ACCESS_TOKEN=[REDACTED]

로 바꿀 수 있습니다.

구조는:

Tool
 ↓
Output
 ↓
Mod
 ↓
Secret 제거
 ↓
Claude

입니다.

Agent에게 점점 더 많은 Tool과 시스템 접근권한을 주는 환경에서는 꽤 중요한 기능입니다.


10. 실패한 Tool Call을 자동으로 다시 시도할 수도 있다

예를 들어 API 호출이 일시적으로 실패했다고 해보겠습니다.

기존에는 Claude가 오류를 읽고:

다시 시도할까?

를 스스로 판단해야 했습니다.

Mod에서는 특정 오류를 감지해:

Timeout
 ↓
자동 Retry

같은 동작을 직접 넣을 수 있습니다.

예를 들면:

Network Timeout
→ 최대 3회 Retry

Authentication Error
→ Retry 금지

Rate Limit
→ 일정 시간 후 Retry

처럼 훨씬 결정적인 규칙을 적용할 수 있습니다.


11. UI까지 바꿀 수 있다

여기서 Hooks와 가장 큰 차이가 느껴집니다.

Mods는 Claude Code의 화면도 바꿀 수 있습니다.

예를 들어:

CI Status

Build Status

Test Result

Current Branch

PR 상태

를 Conversation 옆에 표시하는 UI를 만들 수 있습니다.

Anthropic이 예로 든 것도 CI/CD 상태입니다.

Claude Conversation

        │

        ├── Build ✅
        ├── Unit Test ✅
        ├── UI Test ⚠️
        └── Deploy ❌

같은 Pane을 Claude Code 안에 붙일 수 있습니다.


12. Button이나 Input도 추가할 수 있다

단순 표시만 가능한 것도 아닙니다.

예를 들어 Claude Code 화면에:

[Build]

[Test]

[Review]

[Deploy]

버튼을 만들 수도 있습니다.

사용자가:

[Test]

를 누르면 다른 Mod가 그 이벤트를 받아:

Unit Test 실행
 ↓
결과 표시

같은 동작을 할 수 있습니다.

즉 Claude Code가 조금씩 개발자가 직접 만드는 IDE Shell처럼 변하기 시작합니다.


13. 기존 기능 자체를 교체할 수도 있다

Mods의 상당히 강력한 부분입니다.

Anthropic은 Claude Code의 일부 기본 기능도 Mods로 옮기기 시작했습니다.

대표적인 것이:

/diff

입니다.

이제 /diff도 Mod로 제공됩니다.

그래서 기본 Diff가 마음에 들지 않는다면:

기본 /diff OFF
      ↓
내 Diff Mod 설치
      ↓
새로운 Diff UI

로 교체할 수 있습니다.

Anthropic은 앞으로 더 많은 기본 기능을 Mods로 옮길 계획입니다.


14. Claude Code가 작은 Core + Mods 구조로 갈 수도 있다

이 방향이 재미있습니다.

현재 Claude Code는 많은 기능을 기본 제공하고 있습니다.

하지만 앞으로는:

Claude Code Core

      +

Diff Mod

Review Mod

Security Mod

CI Mod

Git Mod

Company Mod

같은 구조가 될 수 있습니다.

필요 없는 기능은 빼고 자신에게 필요한 것만 넣는 방식입니다.

IDE의 Plugin 생태계와 꽤 비슷합니다.


15. Mod를 직접 만들 필요도 없다

Anthropic이 이번 발표에서 재미있게 보여준 기능이 있습니다.

Claude Code에게:

이런 Mod 만들어줘.

라고 하면 됩니다.

Claude가:

요구사항 이해
 ↓
TypeScript 작성
 ↓
Mod 설치
 ↓
Hot Reload

까지 진행할 수 있습니다.

즉:

Claude Code를 Claude Code로 수정할 수 있습니다.

이건 Mods의 진입장벽을 상당히 낮춥니다.


16. 예를 들어 이런 Mod를 부탁할 수 있다

Production 환경을 변경하는 Bash 명령은
반드시 사용자 승인을 받게 해줘.

Test 명령은 자동 승인하고,

Tool Output에 API Key가 포함되면
Claude에게 전달하기 전에 마스킹해줘.

Claude가 이를 TypeScript Mod로 만들어줄 수 있습니다.

개발자는 완전히 새로운 Extension API를 처음부터 공부하지 않아도 됩니다.


17. 여러 Mods를 동시에 쓸 수도 있다

하나의 Event에 여러 Mod가 걸릴 수도 있습니다.

예를 들어:

Tool Call
   ↓
Security Mod
   ↓
Logging Mod
   ↓
Company Policy Mod
   ↓
UI Mod

처럼 여러 단계를 통과할 수 있습니다.

Mods는 로드된 순서대로 실행됩니다.

먼저 로드된 Mod가 Event를 먼저 보고, 마지막 결과는 반대 순서로 돌아오는 구조입니다.

이 덕분에 기능을 작은 Mod로 나눠 조합할 수 있습니다.


18. 회사에서는 이 기능이 더 강력하다

개인 개발자에게도 편하지만 Team이나 Enterprise에서는 활용 범위가 훨씬 커집니다.

예를 들어 회사 공통 Plugin 안에:

Company Security Mod

CI/CD Mod

Audit Mod

Architecture Policy Mod

Production Guard Mod

를 넣을 수 있습니다.

그리고 모든 개발자의 Claude Code에서 동일하게 적용합니다.


19. Production Safeguard도 만들 수 있다

예를 들어 회사 정책이:

Production DB 직접 변경 금지

라고 해보겠습니다.

Mod에서:

Tool Call
 ↓
production 문자열 발견
 ↓
DB 변경 명령인가?
 ↓
YES
 ↓
사용자 승인 또는 차단

을 강제할 수 있습니다.

중요한 건 이 규칙이 Prompt가 아니라 코드로 실행된다는 것입니다.


20. Prompt로 금지하는 것과는 차이가 크다

기존에는 CLAUDE.md에:

Production 환경을 수정하지 마세요.

라고 써둘 수 있습니다.

하지만 이건 모델에게 보내는 Instruction입니다.

Mods는 다릅니다.

CLAUDE.md
→ 모델에게 하지 말라고 말함

Mod
→ 실제 Tool 실행 단계에서 막음

입니다.

Agent에게 더 많은 권한을 줄수록 이 차이는 중요합니다.


21. Audit Logging도 가능하다

회사가 AI Coding Agent를 사용하기 시작하면 이런 질문이 생깁니다.

Claude가 어떤 파일을 읽었나?

어떤 명령을 실행했나?

어떤 Mod가 Tool을 변경했나?

누가 승인했나?

Mod를 가장 먼저 실행하게 해서 모든 호출을 기록하면 자체 Audit Layer를 만들 수 있습니다.

Claude Code
 ↓
Audit Mod
 ↓
다른 Mods
 ↓
Tool

같은 구조입니다.


22. 여기서 sec-default가 등장한다

Mods는 강력한 만큼 위험합니다.

그래서 Anthropic은 Team·Enterprise와 Managed Settings가 적용된 환경에서 sec-default라는 기본 Security Mod를 가장 먼저 로드합니다.

이 Mod는 사용자가 설치한 다른 Mod가:

Permission Deny Rule 무시

중요 보안 설정 우회

같은 위험한 행동을 하지 못하게 제한합니다.

회사 관리자는 자신의 Mod를 앞에 배치할 수도 있지만, Anthropic은 이 경우에도 sec-default를 포함해 보호 규칙을 유지할 것을 안내하고 있습니다.


23. 하지만 Mods 자체는 Sandbox가 아니다

이 부분은 정말 중요합니다.

Mods는:

안전한 작은 Plugin Sandbox

안에서 실행되는 게 아닙니다.

Claude Code와 같은 머신 권한으로 실행됩니다.

즉 설치한 Mod가 마음먹으면:

파일 읽기

파일 쓰기

프로세스 실행

Network 접근

같은 일을 할 수 있습니다.

그래서 Anthropic도 Mods를 일반 코드 설치와 똑같이 생각하라고 경고합니다.


24. 아무 Mod나 설치하면 안 된다

앞으로 Claude Plugin Directory에 재미있는 Mod가 많이 올라올 가능성이 큽니다.

하지만:

이 Mod 편해 보이는데?
 ↓
설치

하기 전에 Source와 배포자를 확인하는 게 좋습니다.

특히:

Production Credential

SSH Key

Cloud Credential

회사 Repository

가 있는 개발자 Mac에서는 더 조심해야 합니다.

VS Code Extension이나 npm Package를 설치할 때와 비슷한 수준으로 생각하는 편이 맞습니다.


25. Mods는 Plugin 안에 들어간다

여기서 Claude의 최근 Plugin 생태계와 연결됩니다.

구조는 대략:

Claude Plugin
    │
    ├── Skills
    ├── MCP
    ├── Commands
    ├── Agents
    └── Mods

처럼 생각할 수 있습니다.

Mod는 독립 배포 형태라기보다 Plugin 안에 포함됩니다.

그래서 설치와 공유도 기존 Plugin 방식을 그대로 사용합니다.


26. 이미 만들어둔 Plugin 관리 정책도 그대로 쓸 수 있다

기업에서는 새로운 관리 시스템을 따로 만들 필요가 없습니다.

기존:

Plugin Marketplace 허용

특정 Plugin 차단

회사 전용 Plugin 배포

정책을 Mods에도 적용할 수 있습니다.

Team과 Enterprise에서는 관리자가 Marketplace 사용 여부 등을 제어할 수 있습니다.


27. 그러면 Skill·Hook·MCP·Mod는 어떻게 구분해야 할까

이제 Claude Code 확장 기능이 많아져서 헷갈릴 수 있습니다.

간단하게 나누면 이렇습니다.

기능역할
CLAUDE.md프로젝트 규칙
Skill반복 작업 방법
MCP외부 Tool 연결
HookEvent에 반응해 Script 실행
ModClaude Code 내부 Event 변경
Plugin이 기능들을 묶어서 배포

한 줄씩 보면:

CLAUDE.md
→ 무엇을 지킬까

Skill
→ 어떻게 일할까

MCP
→ 무엇을 사용할까

Hook
→ 일이 생기면 무엇을 실행할까

Mod
→ Claude Code 자체가 어떻게 동작할까

입니다.


28. Hooks가 없어지는 건 아니다

Mods가 Hooks보다 강하다고 해서 Hooks를 전부 Mods로 바꿀 필요는 없습니다.

예를 들어:

파일 저장
↓
SwiftLint 실행

같은 단순 자동화라면 Hook이 훨씬 간단합니다.

반대로:

Tool Call 내용을 검사하고 수정

Permission 정책 변경

UI 추가

Claude에게 전달될 결과 수정

이 필요하다면 Mod가 맞습니다.

즉 둘은 경쟁 관계라기보다 적용 범위가 다릅니다.


29. iOS 개발에서는 이런 Mod가 꽤 유용할 수 있다

예를 들어 Claude Code를 이용해 iOS 프로젝트를 개발한다고 해보겠습니다.

Xcode Build Mod

코드 변경
 ↓
관련 Scheme 판단
 ↓
xcodebuild 실행
 ↓
Build 결과 UI 표시

Swift 6 Guard Mod

코드 수정
 ↓
@unchecked Sendable 추가 감지
 ↓
경고

Architecture Guard Mod

Presentation
 ↓
Data Layer 직접 참조
 ↓
Tool Call 차단 또는 경고

Production Config Mod

Production xcconfig 수정
 ↓
사용자 승인 필수

같은 구성을 만들 수 있습니다.


30. XcodeBuildMCP와도 역할이 다르다

예를 들어:

XcodeBuildMCP

는 Claude에게:

Build

Simulator

UI 조작

Screenshot

Log

같은 Tool을 제공합니다.

반면 Mod는 그 Tool을 사용하는 규칙과 흐름을 제어할 수 있습니다.

Claude
 ↓
Mod
 ↓
XcodeBuildMCP
 ↓
Simulator

입니다.

둘을 같이 쓰면 훨씬 재미있습니다.


31. 예를 들어 Simulator Test 전용 Mod를 만들 수도 있다

Claude가 기능 구현을 끝내면 자동으로:

코드 변경 완료
 ↓
Build
 ↓
Simulator 실행
 ↓
화면 확인
 ↓
Screenshot
 ↓
결과 표시

같은 흐름으로 연결할 수 있습니다.

그리고:

Release Scheme 사용

같은 위험한 요청이 나오면 Mod가 막습니다.

Agent에게 Tool을 주는 것과 그 Tool의 사용 정책을 만드는 것이 분리되는 겁니다.


32. AI Coding Agent도 결국 Middleware가 필요해지고 있다

웹 서버 개발을 생각하면 익숙합니다.

Request
 ↓
Authentication Middleware
 ↓
Logging Middleware
 ↓
Validation Middleware
 ↓
Application

Claude Mods도 비슷하게 볼 수 있습니다.

Claude Event
 ↓
Security Mod
 ↓
Policy Mod
 ↓
Logging Mod
 ↓
Tool

Agent가 단순한 Chatbot에서 실제 개발 환경을 움직이는 프로그램으로 바뀌면서 이런 중간 계층이 필요해지고 있습니다.


33. 특히 AI에게 권한을 많이 줄수록 Mods의 가치가 커진다

Claude가 할 수 있는 일이:

코드 읽기

정도라면 굳이 복잡한 Policy Layer가 필요하지 않습니다.

하지만 이제 Claude Code가:

파일 수정

Shell 실행

Browser 사용

GitHub 접근

Cloud 접근

Deployment

Database 작업

까지 하기 시작했습니다.

그러면:

무엇을 할 수 있는가

보다:

어떤 조건에서 할 수 있는가

가 더 중요해집니다.

Mods는 바로 그 영역을 건드립니다.


34. Claude Code를 회사 개발환경에 맞추는 방식도 달라진다

기존에는 회사에서 Claude Code를 도입하면 개발자에게:

CLAUDE.md 읽으세요.

이 명령은 실행하지 마세요.

Production 조심하세요.

같은 문서를 전달하는 경우가 많았습니다.

앞으로는 일부 규칙을 실제 코드로 만들 수 있습니다.

문서 규칙
        ↓
CLAUDE.md

반복 절차
        ↓
Skill

외부 시스템
        ↓
MCP

강제해야 하는 정책
        ↓
Mod

이 구분이 훨씬 명확해집니다.


35. 좋은 Mod는 AI를 더 자유롭게 만드는 역할도 한다

보안 기능만 생각하기 쉽지만 반대도 가능합니다.

현재는 위험할까 봐:

매번 Permission 요청

을 많이 설정합니다.

하지만 Mod가 안전한 작업을 정확하게 구분한다면:

안전한 작업
→ 자동 실행

위험한 작업
→ 승인

으로 나눌 수 있습니다.

결과적으로 Claude에게 더 많은 자동화 권한을 안전하게 줄 수 있습니다.


36. Claude Code가 점점 하나의 Agent Platform이 되고 있다

최근 Claude Code를 보면 기능이 계속 늘어나고 있습니다.

CLAUDE.md

Subagents

Skills

Hooks

MCP

Plugins

Worktrees

Mods

이제 Claude Code를 단순히:

Terminal에서 쓰는 Coding AI

라고 보기 어려워졌습니다.

조금씩:

개발자가 자신의 Agent 환경을 만드는 Platform

쪽으로 가고 있습니다.

Mods는 그 흐름에서 꽤 중요한 기능입니다.


37. 특히 기본 기능까지 Mods로 바꾸겠다는 게 중요하다

/diff를 Mod로 옮긴 건 단순 구현 방식 변경처럼 보일 수 있습니다.

하지만 Anthropic의 방향은 더 큽니다.

앞으로 기본 기능을 계속 Mods로 옮긴다면 개발자는:

Claude Code Core

+
내가 필요한 기능만 선택

할 수 있게 됩니다.

Claude Code가 하나의 고정된 제품이라기보다 조립 가능한 개발환경이 되는 겁니다.


38. 개발자라면 처음부터 거대한 Mod를 만들 필요는 없다

가장 먼저 만들 만한 건 오히려 작습니다.

예를 들어:

Production 명령 승인 Mod

또는:

Secret Redaction Mod

정도입니다.

그다음:

CI Status

Build Panel

Architecture Guard

회사 Policy

Audit

순서로 확장하면 됩니다.


39. 지금 바로 떠올릴 수 있는 실전 Mod 5개

1. Production Guard

production 관련 명령
→ 승인 필수

2. Secret Redactor

Tool Output
→ API Key / Token 제거
→ Claude에게 전달

3. CI Monitor

GitHub Actions
→ 현재 Build 상태
→ Claude Code UI에 표시

4. Architecture Guard

금지된 Dependency
→ 변경 차단 또는 경고

5. iOS Build Mod

Swift 파일 수정
→ Build
→ Test
→ 결과 표시

이 정도만 있어도 실제 개발 Workflow가 꽤 달라질 수 있습니다.


40. 하지만 가장 먼저 기억할 건 보안이다

Mods가 강력한 이유와 위험한 이유는 같습니다.

Claude Code 내부에 깊게 들어갈 수 있기 때문입니다.

그래서:

편한 Mod 발견
→ 바로 설치

보다:

Source 확인

누가 만들었는지 확인

어떤 Permission을 사용하는지 확인

회사 환경에서 허용되는지 확인

하는 습관이 필요합니다.

특히 Mods는 Sandbox가 아니라는 점을 잊으면 안 됩니다.


마치며

Claude Code Mods를 처음 보면:

Hooks를 TypeScript로 다시 만든 건가?

라고 생각할 수 있습니다.

하지만 실제 차이는 꽤 큽니다.

Hooks가 Claude Code 주변에서 자동화를 추가했다면 Mods는:

Prompt

Tool Call

Permission

Tool Output

UI

Built-in Feature

까지 직접 건드립니다.

그래서 Claude Code의 확장 구조도 이렇게 바뀌고 있습니다.

CLAUDE.md
→ 프로젝트의 규칙

Skills
→ 반복 작업 방법

MCP
→ 외부 Tool

Hooks
→ Event 자동화

Mods
→ Claude Code 자체의 동작

Plugins
→ 모든 것을 묶어 배포

특히 개발자에게 재미있는 부분은 Claude Code를 Claude에게 시켜서 직접 고칠 수 있다는 점입니다.

이런 기능 있었으면 좋겠는데.
        ↓
Claude에게 설명
        ↓
Mod 생성
        ↓
Hot Reload
        ↓
바로 Claude Code에 적용

이제 새로운 기능이 Anthropic 공식 업데이트에 들어올 때까지 기다릴 필요가 줄어듭니다.

그리고 회사에서는 더 중요한 변화가 생깁니다.

기존에는:

AI에게 이렇게 하라고 지시

했다면,

Mods를 이용하면:

AI가 그렇게 행동하도록 코드로 강제

할 수 있습니다.

AI Coding Agent가 더 많은 권한을 가지기 시작하면서 이런 기능은 점점 중요해질 겁니다.

좋은 Agent를 만드는 것만큼,

Agent가 어떤 규칙 아래 움직일지를 개발자가 직접 설계하는 시대가 시작되고 있습니다.

참고자료

Anthropic — Customize Claude Code with mods

Claude Code Mods의 공식 발표입니다. Prompt 변경, Tool Call 제어, Permission 처리, UI 변경, /diff 교체, sec-default와 기업용 활용 사례를 설명합니다.

Claude Code Mods 공식 발표

Anthropic — Build plugins for Claude

Claude Plugin 안에 Skill, Agent, Connector와 여러 확장 기능을 묶어 배포하고 공유하는 구조를 설명한 공식 발표입니다.

Claude Plugin 공식 발표

profile
iOS 앱 개발자

0개의 댓글