Claude skill scanning 베타: 사내 에이전트 플러그인 보안 검토가 바뀌는 지점

Claude의 skill and plugin security scanning 베타는 에이전트 확장 기능을 조직 안으로 들여올 때 생기는 보안 공백을 줄이려는 기능입니다. Anthropic 지원 문서에 따르면 Enterprise 조직은 third-party skills와 plugins가 업로드되거나 수정될 때 자동 스캔을 켤 수 있습니다. 결과는 pass, warn, fail 세 단계로 나뉘고, 대부분의 스캔은 1~2분 안에 끝나며 같은 파일은 캐시됩니다.

이 업데이트가 중요한 이유는 단순합니다. 에이전트 스킬과 플러그인은 코드와 문서의 중간 지대에 있습니다. 겉으로는 ‘회의록 요약’, ‘리포트 생성’, ‘배포 체크’처럼 보이지만, 내부에는 모델 행동 지침, 스크립트, 외부 도구 연결, 파일 접근 패턴이 섞일 수 있습니다. 즉, 프롬프트 파일 하나가 사실상 실행 정책이 될 수 있습니다. 기업 보안팀 입장에서는 npm 패키지나 브라우저 확장만 검사해서는 부족해진 셈입니다.

왜 skill scanning이 필요해졌나

개발팀은 이미 외부 패키지 보안에는 익숙합니다. package-lock을 보고, SBOM을 만들고, dependency scanner를 돌립니다. 하지만 에이전트 스킬은 전통적인 scanner가 잘 보지 못하는 영역입니다. 악성 행위가 JavaScript 코드에만 있는 것이 아니라 자연어 지침에 숨어 있을 수 있기 때문입니다.

예를 들어 어떤 Skill이 “배포 로그를 요약한다”고 주장하면서 내부 지침에 “민감한 환경변수를 별도 엔드포인트로 정리해서 보내라”는 내용을 숨겨둘 수 있습니다. 또는 MCP 서버 사용을 유도하면서 사용자가 예상하지 못한 파일 읽기, 메시지 전송, 데이터 반출을 시도할 수 있습니다. Claude의 scanning 문서는 이런 유형, 즉 부여받은 접근 권한을 조용히 오용하려는 third-party skill/plugin을 검사 대상으로 설명합니다.

중요한 점은 pass가 절대 안전을 의미하지 않는다는 것입니다. 문서도 이 한계를 분명히 둡니다. 스캔은 특정한 악성 misuse 징후를 찾는 장치이지, 조직의 모든 의도 불일치나 품질 문제를 잡는 장치가 아닙니다. 따라서 scanning은 보안 프로세스의 시작점이지 끝이 아닙니다.

pass, warn, fail을 운영에서 어떻게 해석할까

세 단계 결과는 운영 정책으로 연결되어야 의미가 있습니다. pass는 설치를 막을 만한 문제가 발견되지 않았다는 뜻입니다. 그래도 출처, 권한, 사용 범위를 봐야 합니다. warn은 완전히 검증하지 못했거나 출처와 내용상 위험이 남아 있다는 신호입니다. 사용자는 caution banner를 확인한 뒤 계속 사용할 수 있지만, 조직에서는 warn 상태를 그냥 개인 판단에 맡기면 안 됩니다.

fail은 더 강합니다. 문서에 따르면 fail 결과는 malicious content가 감지된 상태이며 skill/plugin은 차단되고 사용할 수 없습니다. 업로더나 admin이 즉시 override할 수 없고, 오탐이라고 판단되면 내용을 수정해 다시 업로드해야 합니다. 같은 파일을 다시 올리면 같은 결과를 반환하므로, flagged reason을 해소해야 합니다.

실무 정책은 이렇게 잡는 편이 좋습니다. pass는 낮은 위험 도구에 한해 사용 허용, warn은 보안 또는 플랫폼 담당자 리뷰 후 제한적 허용, fail은 차단 및 공급자 확인입니다. 특히 고객 데이터, 소스코드, 배포 권한, 메시지 전송 권한이 붙는 Skill은 pass라도 추가 리뷰를 거쳐야 합니다.

스캔만으로 부족한 부분

Skill scanning이 있어도 팀이 직접 봐야 하는 것이 있습니다. 첫째, 의도와 권한의 정합성입니다. 회의록 요약 Skill이 파일 시스템 전체 읽기 권한을 요구한다면 이상합니다. 둘째, 실행 경로입니다. Skill 자체는 안전해 보여도 연결된 MCP 서버나 스크립트가 어떤 네트워크 호출을 하는지 봐야 합니다. 셋째, 데이터 보존입니다. 스캔이 끝난 뒤에도 실제 실행 중 어떤 로그가 남고 어디로 전송되는지 확인해야 합니다.

넷째, 업데이트 경로입니다. 안전하게 승인한 Skill도 나중에 수정되면 다시 위험해질 수 있습니다. Anthropic 기능은 upload/edit 시점에 스캔한다고 설명하므로, 조직은 승인된 버전과 현재 버전을 구분해 관리해야 합니다. 다섯째, 사용 범위입니다. 같은 Skill도 개인 노트에 쓰는 것과 프로덕션 배포 채널에 쓰는 것은 위험도가 다릅니다.

결국 에이전트 보안은 ‘파일이 안전한가’보다 ‘이 파일이 어떤 권한과 문맥에서 실행되는가’의 문제입니다. scanning은 전자를 빠르게 걸러주지만, 후자는 조직 정책이 필요합니다.

개발팀용 승인 플로우 예시

작은 팀이라면 복잡한 보안 포털부터 만들 필요는 없습니다. 다음 흐름이면 충분히 시작할 수 있습니다.

1. 외부 Skill 또는 Plugin을 가져오면 저장소에 vendor/agent-extensions 같은 디렉터리로 커밋합니다.
2. README에 출처, 목적, 필요한 권한, 연결 MCP 서버, 네트워크 접근 여부를 기록합니다.
3. 자동 스캔 결과를 첨부합니다. pass/warn/fail과 시간, 버전 해시를 남깁니다.
4. warn 이상은 코드 리뷰처럼 담당자 승인을 받습니다.
5. 실행 환경에서는 read-only와 write-capable 도구를 분리합니다.
6. 프로덕션 데이터 접근 권한은 별도 service account로 제한합니다.

이 정도만 해도 ‘누가 어디서 받은 스킬을 어떤 권한으로 실행했는지 모르는’ 상태를 피할 수 있습니다. 중요한 것은 에이전트 확장 기능을 개인 설정이 아니라 운영 자산으로 취급하는 태도입니다.

사내 Skill 배포 정책을 다시 써야 하는 이유

앞으로 Agent Plugins 같은 포맷이 확산되면 에이전트 기능은 더 쉽게 이동합니다. 쉽게 이동한다는 것은 좋은 기능이 빨리 퍼진다는 뜻이지만, 위험한 기능도 빨리 퍼질 수 있다는 뜻입니다. 그래서 사내 정책은 ‘설치 금지’가 아니라 ‘검토 가능한 설치’로 가야 합니다.

개발 생산성을 막지 않으면서도 최소한의 안전선을 만들려면 세 가지 기준이 필요합니다. 출처가 확인되는가. 필요한 권한이 목적에 비해 과하지 않은가. 실패하거나 악용될 때 blast radius가 제한되는가. 이 기준을 통과하지 못하는 Skill은 아무리 편해 보여도 프로덕션 근처에 두면 안 됩니다.

도입 전 체크리스트

• Claude 조직에서 skill/plugin scanning 사용 가능 여부를 확인한다.
• third-party Skill과 내부 제작 Skill을 구분해 목록화한다.
• pass, warn, fail별 승인 정책을 문서화한다.
• warn 결과를 개인 판단에 맡기지 않고 담당자 리뷰로 보낸다.
• fail 결과는 override하지 않는다는 원칙을 세운다.
• Skill이 요구하는 도구 권한과 실제 목적을 비교한다.
• MCP 서버, 스크립트, 네트워크 호출까지 함께 검토한다.
• 승인 버전의 해시와 출처 URL을 남긴다.
• read-only 실행과 write 실행을 구조적으로 분리한다.
• pass 결과를 ‘완전 안전’으로 오해하지 않는다.