
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 자체의 동작을 개발자가 바꿀 수 있게 된 겁니다.
Anthropic이 설명하는 Mod의 기본 형태는 생각보다 단순합니다.
Claude Code가 작업하면서 어떤 일이 발생하면 Event가 생깁니다.
예를 들어:
Prompt 입력
Tool 호출
Permission 요청
Tool 결과 반환
UI 표시
같은 이벤트입니다.
Mod는 그 이벤트 사이에 들어갑니다.
Claude Code
↓
Event
↓
Mod
↓
변경된 Event
↓
Claude Code
그리고 Mod 자체는 작은 TypeScript 함수로 작성합니다.
그래서 완전히 새로운 Agent Framework를 배울 필요는 없습니다.
Claude Code에는 이미 Hooks가 있습니다.
Hooks도 특정 이벤트에 맞춰 Shell Command나 Script를 실행할 수 있습니다.
예를 들면:
파일 수정
↓
Hook
↓
SwiftLint 실행
또는:
Tool 사용
↓
Hook
↓
Log 기록
같은 방식입니다.
그런데 Hooks에는 중요한 제한이 있습니다.
이벤트를 관찰하거나 외부 작업을 실행하는 데는 좋지만, Claude Code 내부의 이벤트 자체를 자유롭게 바꾸기는 어렵습니다.
Mods는 여기서 한 단계 더 들어갑니다.
가장 단순하게 나누면 이렇습니다.
Event 발생
↓
외부 Script 실행
Event 발생
↓
Event 내용 확인
↓
변경 / 차단 / 대체
↓
Claude Code 계속 실행
즉 Hooks가:
무슨 일이 일어났으니 이것도 실행해.
에 가깝다면,
Mods는:
이 일이 일어나기 전에 내가 내용을 바꿀게.
에 더 가깝습니다.
예를 들어 사용자가:
이 코드 수정해줘.
라고 입력했다고 해보겠습니다.
Mod를 중간에 넣으면 실제 모델에게 전달되기 전에:
이 코드 수정해줘.
추가 규칙:
- 요청 범위 밖의 Refactoring 금지
- 수정 후 관련 Test 실행
- Architecture 변경 시 먼저 사용자에게 설명
같은 내용을 자동으로 붙일 수 있습니다.
구조는:
사용자 Prompt
↓
Mod
↓
프로젝트 규칙 추가
↓
Claude
가 됩니다.
매번 긴 Prompt를 사람이 반복해서 입력할 필요가 없습니다.
이게 Mods에서 특히 재미있는 부분입니다.
Claude가 이런 명령을 실행하려고 한다고 해보겠습니다.
rm -rf ./build
Tool Call이 실제 실행되기 전에 Mod가 볼 수 있습니다.
그리고 조건에 따라:
허용
차단
내용 변경
다시 시도
사용자 승인 요청
중 하나를 선택할 수 있습니다.
예를 들면:
Claude
↓
Bash Tool Call
↓
Mod
↓
Production 관련 명령인가?
↓
YES
↓
실행 중지
같은 Guardrail을 만들 수 있습니다.
단순 차단만 가능한 것도 아닙니다.
Claude가:
kubectl delete pod production-api
같은 명령을 만들었다고 해보겠습니다.
Mod가 이를 감지해서:
kubectl get pod production-api
처럼 안전한 확인 명령으로 먼저 바꿀 수도 있습니다.
또는:
Production 명령입니다.
실행 전에 사용자 승인이 필요합니다.
라는 별도 흐름으로 넘길 수도 있습니다.
즉 Claude가 만든 Tool Call을 Policy Layer에서 한 번 더 제어할 수 있습니다.
Claude Code를 쓰다 보면 Permission 창을 자주 만나게 됩니다.
이 명령을 실행해도 될까요?
이 파일을 수정해도 될까요?
이 Tool을 사용해도 될까요?
보안을 위해 필요한 기능이지만 반복 작업에서는 귀찮을 수 있습니다.
Mods를 사용하면 조건에 따라 자동 처리할 수 있습니다.
예를 들어:
npm test
→ 자동 승인
swift test
→ 자동 승인
xcodebuild test
→ 자동 승인
rm
→ 승인 필요
git push
→ 승인 필요
Production 관련 명령
→ 무조건 승인 필요
같은 규칙입니다.
예를 들어 iOS 프로젝트라면:
파일 읽기
→ 자동 허용
Sources/ 수정
→ 허용
Tests/ 수정
→ 허용
xcodebuild
→ 자동 허용
Simulator 실행
→ 자동 허용
git commit
→ 확인
git push
→ 확인
Release 배포
→ 차단 또는 승인 필수
처럼 만들 수 있습니다.
이렇게 되면 Permission을 단순히:
Claude에게 많이 허용한다
또는:
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과 시스템 접근권한을 주는 환경에서는 꽤 중요한 기능입니다.
예를 들어 API 호출이 일시적으로 실패했다고 해보겠습니다.
기존에는 Claude가 오류를 읽고:
다시 시도할까?
를 스스로 판단해야 했습니다.
Mod에서는 특정 오류를 감지해:
Timeout
↓
자동 Retry
같은 동작을 직접 넣을 수 있습니다.
예를 들면:
Network Timeout
→ 최대 3회 Retry
Authentication Error
→ Retry 금지
Rate Limit
→ 일정 시간 후 Retry
처럼 훨씬 결정적인 규칙을 적용할 수 있습니다.
여기서 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 안에 붙일 수 있습니다.
단순 표시만 가능한 것도 아닙니다.
예를 들어 Claude Code 화면에:
[Build]
[Test]
[Review]
[Deploy]
버튼을 만들 수도 있습니다.
사용자가:
[Test]
를 누르면 다른 Mod가 그 이벤트를 받아:
Unit Test 실행
↓
결과 표시
같은 동작을 할 수 있습니다.
즉 Claude Code가 조금씩 개발자가 직접 만드는 IDE Shell처럼 변하기 시작합니다.
Mods의 상당히 강력한 부분입니다.
Anthropic은 Claude Code의 일부 기본 기능도 Mods로 옮기기 시작했습니다.
대표적인 것이:
/diff
입니다.
이제 /diff도 Mod로 제공됩니다.
그래서 기본 Diff가 마음에 들지 않는다면:
기본 /diff OFF
↓
내 Diff Mod 설치
↓
새로운 Diff UI
로 교체할 수 있습니다.
Anthropic은 앞으로 더 많은 기본 기능을 Mods로 옮길 계획입니다.
이 방향이 재미있습니다.
현재 Claude Code는 많은 기능을 기본 제공하고 있습니다.
하지만 앞으로는:
Claude Code Core
+
Diff Mod
Review Mod
Security Mod
CI Mod
Git Mod
Company Mod
같은 구조가 될 수 있습니다.
필요 없는 기능은 빼고 자신에게 필요한 것만 넣는 방식입니다.
IDE의 Plugin 생태계와 꽤 비슷합니다.
Anthropic이 이번 발표에서 재미있게 보여준 기능이 있습니다.
Claude Code에게:
이런 Mod 만들어줘.
라고 하면 됩니다.
Claude가:
요구사항 이해
↓
TypeScript 작성
↓
Mod 설치
↓
Hot Reload
까지 진행할 수 있습니다.
즉:
Claude Code를 Claude Code로 수정할 수 있습니다.
이건 Mods의 진입장벽을 상당히 낮춥니다.
Production 환경을 변경하는 Bash 명령은
반드시 사용자 승인을 받게 해줘.
Test 명령은 자동 승인하고,
Tool Output에 API Key가 포함되면
Claude에게 전달하기 전에 마스킹해줘.
Claude가 이를 TypeScript Mod로 만들어줄 수 있습니다.
개발자는 완전히 새로운 Extension API를 처음부터 공부하지 않아도 됩니다.
하나의 Event에 여러 Mod가 걸릴 수도 있습니다.
예를 들어:
Tool Call
↓
Security Mod
↓
Logging Mod
↓
Company Policy Mod
↓
UI Mod
처럼 여러 단계를 통과할 수 있습니다.
Mods는 로드된 순서대로 실행됩니다.
먼저 로드된 Mod가 Event를 먼저 보고, 마지막 결과는 반대 순서로 돌아오는 구조입니다.
이 덕분에 기능을 작은 Mod로 나눠 조합할 수 있습니다.
개인 개발자에게도 편하지만 Team이나 Enterprise에서는 활용 범위가 훨씬 커집니다.
예를 들어 회사 공통 Plugin 안에:
Company Security Mod
CI/CD Mod
Audit Mod
Architecture Policy Mod
Production Guard Mod
를 넣을 수 있습니다.
그리고 모든 개발자의 Claude Code에서 동일하게 적용합니다.
예를 들어 회사 정책이:
Production DB 직접 변경 금지
라고 해보겠습니다.
Mod에서:
Tool Call
↓
production 문자열 발견
↓
DB 변경 명령인가?
↓
YES
↓
사용자 승인 또는 차단
을 강제할 수 있습니다.
중요한 건 이 규칙이 Prompt가 아니라 코드로 실행된다는 것입니다.
기존에는 CLAUDE.md에:
Production 환경을 수정하지 마세요.
라고 써둘 수 있습니다.
하지만 이건 모델에게 보내는 Instruction입니다.
Mods는 다릅니다.
CLAUDE.md
→ 모델에게 하지 말라고 말함
Mod
→ 실제 Tool 실행 단계에서 막음
입니다.
Agent에게 더 많은 권한을 줄수록 이 차이는 중요합니다.
회사가 AI Coding Agent를 사용하기 시작하면 이런 질문이 생깁니다.
Claude가 어떤 파일을 읽었나?
어떤 명령을 실행했나?
어떤 Mod가 Tool을 변경했나?
누가 승인했나?
Mod를 가장 먼저 실행하게 해서 모든 호출을 기록하면 자체 Audit Layer를 만들 수 있습니다.
Claude Code
↓
Audit Mod
↓
다른 Mods
↓
Tool
같은 구조입니다.
sec-default가 등장한다Mods는 강력한 만큼 위험합니다.
그래서 Anthropic은 Team·Enterprise와 Managed Settings가 적용된 환경에서 sec-default라는 기본 Security Mod를 가장 먼저 로드합니다.
이 Mod는 사용자가 설치한 다른 Mod가:
Permission Deny Rule 무시
중요 보안 설정 우회
같은 위험한 행동을 하지 못하게 제한합니다.
회사 관리자는 자신의 Mod를 앞에 배치할 수도 있지만, Anthropic은 이 경우에도 sec-default를 포함해 보호 규칙을 유지할 것을 안내하고 있습니다.
이 부분은 정말 중요합니다.
Mods는:
안전한 작은 Plugin Sandbox
안에서 실행되는 게 아닙니다.
Claude Code와 같은 머신 권한으로 실행됩니다.
즉 설치한 Mod가 마음먹으면:
파일 읽기
파일 쓰기
프로세스 실행
Network 접근
같은 일을 할 수 있습니다.
그래서 Anthropic도 Mods를 일반 코드 설치와 똑같이 생각하라고 경고합니다.
앞으로 Claude Plugin Directory에 재미있는 Mod가 많이 올라올 가능성이 큽니다.
하지만:
이 Mod 편해 보이는데?
↓
설치
하기 전에 Source와 배포자를 확인하는 게 좋습니다.
특히:
Production Credential
SSH Key
Cloud Credential
회사 Repository
가 있는 개발자 Mac에서는 더 조심해야 합니다.
VS Code Extension이나 npm Package를 설치할 때와 비슷한 수준으로 생각하는 편이 맞습니다.
여기서 Claude의 최근 Plugin 생태계와 연결됩니다.
구조는 대략:
Claude Plugin
│
├── Skills
├── MCP
├── Commands
├── Agents
└── Mods
처럼 생각할 수 있습니다.
Mod는 독립 배포 형태라기보다 Plugin 안에 포함됩니다.
그래서 설치와 공유도 기존 Plugin 방식을 그대로 사용합니다.
기업에서는 새로운 관리 시스템을 따로 만들 필요가 없습니다.
기존:
Plugin Marketplace 허용
특정 Plugin 차단
회사 전용 Plugin 배포
정책을 Mods에도 적용할 수 있습니다.
Team과 Enterprise에서는 관리자가 Marketplace 사용 여부 등을 제어할 수 있습니다.
이제 Claude Code 확장 기능이 많아져서 헷갈릴 수 있습니다.
간단하게 나누면 이렇습니다.
| 기능 | 역할 |
|---|---|
CLAUDE.md | 프로젝트 규칙 |
| Skill | 반복 작업 방법 |
| MCP | 외부 Tool 연결 |
| Hook | Event에 반응해 Script 실행 |
| Mod | Claude Code 내부 Event 변경 |
| Plugin | 이 기능들을 묶어서 배포 |
한 줄씩 보면:
CLAUDE.md
→ 무엇을 지킬까
Skill
→ 어떻게 일할까
MCP
→ 무엇을 사용할까
Hook
→ 일이 생기면 무엇을 실행할까
Mod
→ Claude Code 자체가 어떻게 동작할까
입니다.
Mods가 Hooks보다 강하다고 해서 Hooks를 전부 Mods로 바꿀 필요는 없습니다.
예를 들어:
파일 저장
↓
SwiftLint 실행
같은 단순 자동화라면 Hook이 훨씬 간단합니다.
반대로:
Tool Call 내용을 검사하고 수정
Permission 정책 변경
UI 추가
Claude에게 전달될 결과 수정
이 필요하다면 Mod가 맞습니다.
즉 둘은 경쟁 관계라기보다 적용 범위가 다릅니다.
예를 들어 Claude Code를 이용해 iOS 프로젝트를 개발한다고 해보겠습니다.
코드 변경
↓
관련 Scheme 판단
↓
xcodebuild 실행
↓
Build 결과 UI 표시
코드 수정
↓
@unchecked Sendable 추가 감지
↓
경고
Presentation
↓
Data Layer 직접 참조
↓
Tool Call 차단 또는 경고
Production xcconfig 수정
↓
사용자 승인 필수
같은 구성을 만들 수 있습니다.
예를 들어:
XcodeBuildMCP
는 Claude에게:
Build
Simulator
UI 조작
Screenshot
Log
같은 Tool을 제공합니다.
반면 Mod는 그 Tool을 사용하는 규칙과 흐름을 제어할 수 있습니다.
Claude
↓
Mod
↓
XcodeBuildMCP
↓
Simulator
입니다.
둘을 같이 쓰면 훨씬 재미있습니다.
Claude가 기능 구현을 끝내면 자동으로:
코드 변경 완료
↓
Build
↓
Simulator 실행
↓
화면 확인
↓
Screenshot
↓
결과 표시
같은 흐름으로 연결할 수 있습니다.
그리고:
Release Scheme 사용
같은 위험한 요청이 나오면 Mod가 막습니다.
Agent에게 Tool을 주는 것과 그 Tool의 사용 정책을 만드는 것이 분리되는 겁니다.
웹 서버 개발을 생각하면 익숙합니다.
Request
↓
Authentication Middleware
↓
Logging Middleware
↓
Validation Middleware
↓
Application
Claude Mods도 비슷하게 볼 수 있습니다.
Claude Event
↓
Security Mod
↓
Policy Mod
↓
Logging Mod
↓
Tool
Agent가 단순한 Chatbot에서 실제 개발 환경을 움직이는 프로그램으로 바뀌면서 이런 중간 계층이 필요해지고 있습니다.
Claude가 할 수 있는 일이:
코드 읽기
정도라면 굳이 복잡한 Policy Layer가 필요하지 않습니다.
하지만 이제 Claude Code가:
파일 수정
Shell 실행
Browser 사용
GitHub 접근
Cloud 접근
Deployment
Database 작업
까지 하기 시작했습니다.
그러면:
무엇을 할 수 있는가
보다:
어떤 조건에서 할 수 있는가
가 더 중요해집니다.
Mods는 바로 그 영역을 건드립니다.
기존에는 회사에서 Claude Code를 도입하면 개발자에게:
CLAUDE.md 읽으세요.
이 명령은 실행하지 마세요.
Production 조심하세요.
같은 문서를 전달하는 경우가 많았습니다.
앞으로는 일부 규칙을 실제 코드로 만들 수 있습니다.
문서 규칙
↓
CLAUDE.md
반복 절차
↓
Skill
외부 시스템
↓
MCP
강제해야 하는 정책
↓
Mod
이 구분이 훨씬 명확해집니다.
보안 기능만 생각하기 쉽지만 반대도 가능합니다.
현재는 위험할까 봐:
매번 Permission 요청
을 많이 설정합니다.
하지만 Mod가 안전한 작업을 정확하게 구분한다면:
안전한 작업
→ 자동 실행
위험한 작업
→ 승인
으로 나눌 수 있습니다.
결과적으로 Claude에게 더 많은 자동화 권한을 안전하게 줄 수 있습니다.
최근 Claude Code를 보면 기능이 계속 늘어나고 있습니다.
CLAUDE.md
Subagents
Skills
Hooks
MCP
Plugins
Worktrees
Mods
이제 Claude Code를 단순히:
Terminal에서 쓰는 Coding AI
라고 보기 어려워졌습니다.
조금씩:
개발자가 자신의 Agent 환경을 만드는 Platform
쪽으로 가고 있습니다.
Mods는 그 흐름에서 꽤 중요한 기능입니다.
/diff를 Mod로 옮긴 건 단순 구현 방식 변경처럼 보일 수 있습니다.
하지만 Anthropic의 방향은 더 큽니다.
앞으로 기본 기능을 계속 Mods로 옮긴다면 개발자는:
Claude Code Core
+
내가 필요한 기능만 선택
할 수 있게 됩니다.
Claude Code가 하나의 고정된 제품이라기보다 조립 가능한 개발환경이 되는 겁니다.
가장 먼저 만들 만한 건 오히려 작습니다.
예를 들어:
Production 명령 승인 Mod
또는:
Secret Redaction Mod
정도입니다.
그다음:
CI Status
Build Panel
Architecture Guard
회사 Policy
Audit
순서로 확장하면 됩니다.
production 관련 명령
→ 승인 필수
Tool Output
→ API Key / Token 제거
→ Claude에게 전달
GitHub Actions
→ 현재 Build 상태
→ Claude Code UI에 표시
금지된 Dependency
→ 변경 차단 또는 경고
Swift 파일 수정
→ Build
→ Test
→ 결과 표시
이 정도만 있어도 실제 개발 Workflow가 꽤 달라질 수 있습니다.
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가 어떤 규칙 아래 움직일지를 개발자가 직접 설계하는 시대가 시작되고 있습니다.

Claude Code Mods의 공식 발표입니다. Prompt 변경, Tool Call 제어, Permission 처리, UI 변경, /diff 교체, sec-default와 기업용 활용 사례를 설명합니다.
Claude Plugin 안에 Skill, Agent, Connector와 여러 확장 기능을 묶어 배포하고 공유하는 구조를 설명한 공식 발표입니다.