Claude Code Mods, 실행 전 검토를 도구 안으로 가져오다

작성자

카테고리:

AI·IT 기술 동향 · 2026년 10월 4일

명령을 잠시 붙잡고 변경 대상을 보여준 뒤 개발자의 결정을 기다린다. Anthropic의 Claude Code Mods 가이드가 제시한 예제다. 모드(Mods)는 세션 안에서 실행되는 JavaScript·TypeScript 코드로, 도구 호출과 화면을 함께 바꾼다.

검토 창에서 ‘진행’을 고르는 것과 플랫폼이 실행을 허용하는 것은 다르다. 검사 코드가 고장 났을 때도 차단이 유지될까.

지시문을 더하는 대신, 세션에 코드를 남긴다

한 번 로드된 모드는 상태를 유지하며 세션에 머문다. 공식 예제는 컨텍스트 사용량과 편집 내역을 보여주는 화면을 만든다.

도구를 막는 능력이 이번에 처음 생긴 것은 아니다. 설정 파일에 등록하는 기존 훅(settings hook)도 호출을 중단하거나 인자와 결과를 바꿀 수 있었다. 공식 비교 문서에서 Mods가 더하는 것은 세션 내부의 함수와 UI다. 모델이 읽을 지침은 skill, 외부 도구 연결은 MCP, 이벤트마다 정해진 검사를 수행하는 일은 기존 훅으로도 다룰 수 있다.

이벤트 함수는 next(e)로 다음 처리기에 넘기거나, 입력을 고쳐 넘긴다. next 없이 결과를 반환하면 이후 처리를 끝낸다. 도구 호출에서 거부를 반환하면 명령은 실행되지 않고 모델이 사유를 받는다.

Blast Radius 예제는 Bash 명령의 문자열을 분류해 위험한 작업에 해당하면 호출을 보류한다. git status나 dry run으로 영향을 조사하고, 보고서와 Proceed·Cancel 버튼을 보여준다. 취소하면 거부 사유를 반환하고, 진행을 고르면 다음 처리로 넘긴다. 별칭이나 다른 스크립트 안의 작업까지 모두 찾아내는 구조는 아니다.

이 설계의 이점은 조사 결과와 결정할 시점을 한곳에 모은다는 것이다. 개발자가 명령의 영향을 따로 알아보러 작업 흐름을 벗어날 필요를 줄인다.

Proceed는 권한을 주는 버튼이 아니다. next 이후에도 권한 검사는 남는다.

검사 코드가 실패하면, 어디로 이어지는가

오류 처리 규칙상 별도 .catch가 없는 훅이 next 호출 전에 예외·시간초과로 실패하면, Claude Code는 그 훅을 건너뛴다. 다음 처리기와 권한 검사가 허용한다면 원래 명령이 실행될 수 있다. 반면 next가 이미 완료된 뒤 훅이 실패하면 기존 결과를 유지하고, 같은 작업을 다시 실행하지 않는다.

모드의 호출 훅에 도달한 뒤
거부 결과를 반환다음 처리로 넘기지 않음도구 실행 중단
next로 넘김다음 처리기·권한 검사허용될 때 실행
next 호출 전 실패오류 처리기 없으면 훅 건너뜀다음 처리기·권한 검사로
앞선 관리 훅에서 차단되지 않은 호출의 개념도. 조직의 관리 설정에 있는 PreToolUse 차단은 모드보다 먼저 적용된다. 권한 규칙과 이벤트 규칙을 바탕으로 온축이 재구성했다.

문서는 훅에 .catch를 붙여 예외·시간초과 때 거부를 반환하도록 제안한다. 오류 시 차단은 별도로 구현해야 한다. 이 오류 처리기에도 별도의 1초 실행 제한이 있다. 차단용 모드라면 UI 표시 외에 예외·시간초과 때의 반환 결과도 검사해야 한다.

Claude의 도구 권한과, 모드 코드의 권한

먼저 Claude의 도구 호출 경로다. 조직이 배포한 관리 설정의 PreToolUse 훅이 차단하면 모드보다 먼저 결정되고, 모드가 이를 뒤집을 수 없다. 반면 tool.check를 다루는 모드는 확인을 요구하는 ask 규칙이나 관리 설정 밖의 PreToolUse 차단 결과를 허용으로 바꿀 수 있다. 공식 권한 문서는 이 차이를 명시한다.

deny 우선순위는 환경에 달렸다. 내장 보안 모드 sec-default는 기기에 관리 설정이 있거나 Team·Enterprise로 로그인한 경우 기본 적용돼, 사용자 모드보다 deny 규칙을 우선한다. 조직이 deny 재정의를 허용하면 달라진다. 관리 설정에서 prependPlugins를 직접 지정할 때는 기본 목록이 대체되므로 sec-default@builtin을 포함해야 한다. API 키·외부 클라우드 인증에는 관리 설정이 있어야 이 보호가 적용된다.

이 보호 조건 밖에서는 모드가 deny 규칙으로 거절된 도구 호출도 허용할 수 있다. 그러므로 “모드 뒤에 권한 검사가 있다”는 말과 “모드가 권한 판단을 바꿀 수 없다”는 말은 같지 않다.

모드 자신의 파일·프로세스 API에는 이 도구 호출 규칙이 적용되지 않는다. 관리자 문서는 Read(.env)를 금지해도 모드가 $.fs.read로 그 파일을 읽을 수 있다고 설명한다. Read 도구 차단은 파일 자체의 접근 차단이 아니다. 모드 자체 작업을 제한하려면 로드를 막거나, 그 API 호출을 검사하는 정책 모드가 필요하다.

가이드의 ‘sandbox’는 모듈 실행 환경에서 DOM·Node를 직접 쓰지 못하고 외부 작업에 $ API를 거친다는 제약이다. 그러나 접근 범위 문서는 모드가 사용자 권한으로 실행되며, 모드가 띄운 프로세스는 Claude의 Bash 샌드박스 밖에 있다고 설명한다. 언어 실행 환경의 제약을 운영체제 수준의 격리로 받아들이면 안 된다.

화면 뒤에서 무엇을 실행하는가

claude plugin validate는 코드를 실행하지 않고 받는 이벤트(hooks)와 호출하는 API(calls)를 보여준다. 파일 읽기·프로세스 실행이 있다면, 그 접근이 모드의 목적에 필요한지 코드와 함께 살펴볼 수 있다.

claude plugin test는 다른 단계를 검증한다. 테스트에서 이벤트를 발생시켜 실제 모드 훅을 실행하되, 뒤에서 Claude Code가 돌려줄 응답은 stub으로 공급한다. 따라서 허용·취소·오류 분기는 검사할 수 있지만 실제 모델·도구·네트워크가 동작한 결과는 아니다. UI 트리 검사 역시 실제 화면 렌더링과 구분해야 한다.

정적 목록·stub 테스트 통과는 실제 환경 검증이 아니다. 권한 설정과 화면은 별도로 확인해야 한다.

화면을 붙이는 기능을 평가할 때는 실행 환경도 맞춰야 한다. 공식 지원 범위상 Mods는 v2.1.287 이상에서 기본 활성화되며, 모드 UI는 터미널과 데스크톱 앱의 Code 탭에 표시된다. 데스크톱 WSL 세션은 예외다. VS Code 채팅 패널·비대화형·클라우드 세션에서는 같은 UI가 표시되지 않는다.

Mods는 판단할 정보를 실행 흐름에 붙인다. 그 편의를 받아들이는 팀은 화면 하나와 함께 실행 주체 하나를 더 검토해야 한다.

이 글은 한국시간 2026년 10월 4일 아침 확인한 공식 문서와 예제를 해설했다. 직접 설치·실행한 테스트나 사고 감소·생산성 효과의 실측 결과는 없다.

개발사 가이드의 게시일 표기는 2026년 10월 1일이며, 시각·시간대는 공개되지 않았다.

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다