터미널 옆에 예쁜 패널 하나를 붙였을 뿐인데, 그 확장 기능이 내가 AI에게 보내는 요청을 바꿀 수 있다면 어떨까.
이것은 사고 사례가 아니라, 새 기능을 이해하기 위한 질문이다.
Anthropic이 10월 1일 공개한 Claude Code Mods는 화면 꾸미기보다 훨씬 깊이 들어간다. TypeScript로 에이전트의 동작을 바꾸는 확장 기능이다. 프롬프트를 수정하거나 도구 호출을 가로채고, 인터페이스를 추가할 수 있다. 플러그인에 담아 배포하며 CLI와 데스크톱에서 사용한다. 공식 발표
매력적인 이유와 신중해야 하는 이유가 같다. 이제 개발자가 손댈 수 있는 것은 AI의 답변 스타일만이 아니다. 답변이 만들어지고 실제 행동으로 이어지는 과정이다.
이 글은 2026년 10월 7일 공식 문서를 확인한 해설이다. 직접 설치해 성능이나 안전성을 검증한 사용기는 아니다.
이름은 작은 ‘모드’지만, 바꾸는 것은 작업 방식이다
예를 들어 AI가 테스트를 돌리고 있는데, 대화창 옆에서 CI 상태도 함께 보고 싶다고 하자. 또는 길어진 대화가 컨텍스트를 얼마나 사용하는지 계속 확인하고 싶다. 이런 요구는 “앞으로 진행 상황을 잘 알려줘”라는 프롬프트만으로 해결하기 어렵다. 작업 중에도 남아 있는 화면과 상태가 필요하기 때문이다.
Mods는 이런 종류의 커스터마이징을 겨냥한다. 기존 설정형 Hooks가 외부 명령이나 요청 등을 이벤트에 연결했다면, Mods의 핸들러는 Claude Code 내부에서 실행된다. 공식 문서는 별도 패널, 인터페이스 변경, 도구 호출 개입 등을 예로 든다. Mods 개요
여기서 중요한 질문은 “더 강력한 기능이 나왔으니 갈아타야 하나?”가 아니다.
지금 불편한 것이 지침의 부족인가, 도구의 부족인가, 실행 흐름의 부족인가?
팀의 문체를 지키게 하는 일이 목적이라면 먼저 지침과 예시를 정리하는 편이 낫다. 외부 시스템의 데이터를 가져오는 것이 문제라면 연결 도구를 검토하면 된다. 반면 작업 도중 특정 상황을 감지해 화면을 띄우거나 행동을 중단시켜야 한다면, 에이전트의 실행 과정에 개입할 이유가 생긴다.
이 구분은 제품의 공식 분류표가 아니라, 불필요하게 복잡한 확장을 만들지 않기 위한 선택 기준이다. 작은 불편을 해결하려고 유지보수할 프로그램 하나를 더 떠안는 것은 좋은 거래가 아닐 수 있다.
‘보안용 모드’라고 쓰여 있어도 권한은 별개다
다음은 가상의 도입 상황이다.
개발자가 로그에 섞인 비밀 값을 가려주는 모드를 발견한다. 모델에 전달되는 내용을 줄여준다니 유용해 보인다. 그런데 민감한 문자열을 찾아내려면, 그 모드는 가리기 전의 데이터를 먼저 읽어야 한다.
“비밀을 보호하는 기능”이라는 설명과 “비밀에 접근하지 않는 코드”는 같은 말이 아니다.
실제로 공식 문서는 Mods가 샌드박스 안에서 실행되지 않으며 사용자 권한으로 파일·프로세스·네트워크에 접근할 수 있다고 설명한다. Claude의 Bash 명령을 격리하는 샌드박스를 켜더라도, 모드가 직접 시작하는 프로세스까지 그 안에 들어가는 것은 아니다. 실행 범위와 신뢰 경계
따라서 모드 이름보다 실제 동작을 먼저 봐야 한다. 화면에 숫자 하나를 보여주는 기능인데 왜 외부 서버로 요청을 보내는가? 로컬 작업을 돕는 기능인데 왜 환경변수를 읽는가? 합리적인 이유가 있을 수 있지만, 설명이 필요한 권한인 것은 변하지 않는다.
조직용 보호 장치도 있다. 다만 여기에도 경계가 있다. 관리자 문서에 따르면 기본 가드가 적용되는 환경에서는 사용자가 설치한 모드가 도구 호출의 금지 규칙을 덮어쓰지 못하도록 보호한다. 하지만 그 규칙과 모드 자체의 파일 접근은 별개다. 문서는 Read(.env)를 금지해도 모드 자체의 파일 API 접근까지 같은 방식으로 차단되는 것은 아니라고 설명한다. 조직용 Mods 관리 문서
이것을 “모든 권한 설정이 무의미하다”로 받아들이면 과장이다. 정확한 해석은 어느 실행 경로에 적용되는 통제인지 구분해야 한다는 것이다.
설치 명령보다 먼저 실행할 명령
이미 내려받은 플러그인 디렉터리가 있다면, 공식 문서는 다음 명령으로 모드의 이벤트와 API 호출 목록을 확인할 수 있다고 안내한다. 모드를 실행하지 않고 살펴보는 단계다.
1 2# ./some-mod는 검토하려는 실제 플러그인 디렉터리로 바꾼다. claude plugin validate ./some-mod
출력의 hooks:는 어떤 이벤트를 받는지, calls:는 어떤 Mods API를 호출하는지 보여준다. 예를 들어 $.process.run은 프로그램 실행, $.http.fetch는 네트워크 요청, $.model.complete는 모델 호출과 연결된다. 공식 검토 방법
여기서 통과 표시를 안전 인증서처럼 취급하지는 말자. 호출 목록은 코드를 검토할 출발점이다. 외부로 무엇을 보내는지, 프로그램에 어떤 인자를 넘기는지, 모델을 얼마나 자주 호출하는지까지 이 목록 하나로 설명되지는 않는다.
나라면 첫 모드의 요구사항을 이렇게 적겠다.
현재 세션의 진행 상태만 보여준다. 파일을 수정하지 않는다. 외부로 데이터를 보내지 않는다. 추가 모델 호출을 하지 않는다. 필요 없어지면 쉽게 끌 수 있다.
이것은 바로 붙여 넣으면 완성되는 구현 코드가 아니라, 검토 범위를 작게 만드는 설계 초안이다. 표시 기능 하나로 시작하면 “무엇을 관찰하는가”부터 확인할 수 있다. 처음부터 자동 승인과 재시도까지 합치면, 문제가 생겼을 때 어느 기능이 원인인지 알아내기도 어려워진다.
편의 기능의 비용도 같은 방식으로 보아야 한다. UI를 표시하는 일과 별도 모델을 호출하는 일은 다르다. 이름이 가벼운 위젯이어도 내부에서 추가 추론을 반복한다면 사용량을 살펴볼 이유가 있다. 이는 특정 모드가 비싸다는 측정 결과가 아니라, 도입 시 확인해야 할 비용 구조다.
Mods가 흥미로운 것은 누구나 터미널을 화려하게 꾸밀 수 있어서가 아니다. 개발팀이 “우리에게 맞는 AI의 행동”을 직접 구현할 여지가 커졌기 때문이다.
그렇다면 첫 번째로 만들 모드는 AI에게 더 많은 일을 시키는 기능보다, 지금 무슨 일이 일어나고 있는지 내가 더 잘 알게 해주는 기능이어도 좋겠다. 자동화를 늘릴지 결정하는 데 필요한 정보부터 확보하는 것이다.