에이전트에 Skill을 추가하는 일은, 마치 로봇에게 새 공구를 쥐여 주는 일과 비슷합니다. 망치가 생기면 못도 잘 박지만, 유리창도 더 쉽게 깰 수 있습니다. Skill은 에이전트를 더 유능하게 만들지만, 동시에 더 위험하게도 만들 수 있습니다. 그래서 이 장의 핵심은 단순합니다.
능력을 설계하는 순간, 위험도 함께 설계해야 한다.
초보자일수록 이 문장을 꼭 기억하면 좋습니다. "우리 에이전트가 뭘 할 수 있지?"라는 질문만 던지면 반쪽짜리 설계입니다. 반드시 "그 능력이 잘못 쓰이면 무슨 일이 벌어지지?"까지 같이 물어야 합니다.
왜 Skill 보안이 특별히 중요한가
일반적인 소프트웨어도 위험하지만, Skill은 조금 다른 문제를 만듭니다. Skill은 단순한 코드 조각이 아니라, 에이전트가 언제 무엇을 어떤 순서로 하게 만들지를 정의하는 행동 설계서에 가깝습니다. 그래서 위험은 코드에만 있지 않고, 설명 문서와 실행 흐름 전체에 숨어 있습니다.1
여기서 특히 무서운 점은, 에이전트가 자연어 설명을 믿고 Skill을 호출한다는 사실입니다. 문서에는 "안전한 파일 정리 도구"라고 써 있는데, 실제 스크립트는 민감한 파일을 읽어 외부로 전송할 수도 있습니다. 이런 설명과 실제 동작의 불일치는 사람이 대충 훑어봤을 때 놓치기 쉽습니다.2
게다가 Skill은 혼자만 일하지 않습니다. 여러 Skill이 연결되면, 각각은 멀쩡해 보여도 조합했을 때 위험해질 수 있습니다. 앞 Skill이 이상한 출력을 만들고, 뒤 Skill이 그 출력을 그대로 명령처럼 받아들여 사고가 나는 식입니다.2
한마디로 정리하면 이렇습니다.
모델이 똑똑하다고 안전한 것은 아니다.
Skill 설명이 친절하다고 안전한 것도 아니다.
개별 Skill이 무해해 보여도 조합까지 안전하다는 뜻은 아니다.
신뢰할 수 없는 Skill은 왜 위험한가
공개 마켓플레이스나 인터넷에서 받은 Skill은 기본적으로 신뢰하지 않는 것이 출발점입니다. 이미 실제 생태계에서는 악성 Skill 유포, 다운로드 수 조작, 브랜드 사칭, 자격 증명 탈취 같은 일이 보고되었습니다.1
특히 위험한 착각이 하나 있습니다. "많이 설치된 Skill이면 괜찮지 않을까?"라는 생각입니다. 하지만 최근 보안 연구는 인기와 안전이 거의 같은 뜻이 아니라는 점을 보여 줍니다. 대중적으로 많이 쓰인 Skill도 정밀 감사를 통과하지 못하는 경우가 많았고, 위험한 Skill들이 서로 연결되며 생태계 전체 위험을 키우는 현상도 관찰되었습니다.2
이 말은 곧 이런 뜻입니다. Skill의 평판은 참고 자료일 뿐, 보안 보증서는 아니다.
초보자가 기억해야 할 신호는 다음과 같습니다.
제작자 정보가 불분명하다.
버전 고정이 안 되어 있다.
외부 스크립트나 설치 단계가 많다.
필요한 권한 설명이 모호하다.
"편의를 위해 전체 파일 접근"처럼 범위가 지나치게 넓다.
이런 Skill은 "유용해 보여서"가 아니라 "무엇을 할 수 있는지 불분명해서" 위험합니다.
가장 먼저 봐야 할 것: 이 Skill은 무엇을 실행하는가
Skill 보안에서 가장 현실적인 질문은 이것입니다.
이 Skill은 결국 무엇을 실행하는가?
많은 사고는 모델 자체보다 주변 소프트웨어 스택에서 벌어집니다. 예를 들어 도구 함수가 검증되지 않은 입력을 셸 명령으로 넘기거나, 배포 설정 파일 안에 비밀 키가 노출되어 있거나, MCP나 도구 구성이 과도한 권한을 갖고 있는 식입니다.3
초보자 관점에서 보면 위험한 실행은 크게 세 갈래입니다.
첫째는 셸 실행입니다. bash, sh, subprocess, eval, exec 같은 것은 에이전트에게 사실상 "직접 손을 움직여라"라고 말하는 것과 비슷합니다. 이 기능이 있으면 파일 삭제, 환경 변수 읽기, 원격 다운로드, 권한 확인, 네트워크 호출이 한 번에 이어질 수 있습니다.4
둘째는 파일 시스템 접근입니다. 문서 요약 Skill인 줄 알았는데 홈 디렉터리 전체를 읽을 수 있다면, .env, SSH 키, 토큰 캐시, 고객 데이터 파일까지 건드릴 수 있습니다.14
셋째는 외부 통신입니다. 네트워크 송신이 가능하면 읽어 온 데이터를 외부 서버로 보내는 길도 열립니다. 내부 정보가 외부로 나가는 순간, 사고는 "실수"가 아니라 "유출"이 됩니다.4
이 세 가지가 동시에 있으면 위험은 급격히 커집니다. 민감한 데이터에 접근할 수 있고, 신뢰할 수 없는 입력을 읽을 수 있고, 바깥으로 통신도 가능하다면 작은 지시 하나가 큰 사고로 이어질 수 있습니다.4
스크립트 실행 리스크: 작은 자동화가 큰 사고가 되는 과정
스크립트 실행이 무서운 이유는 에이전트가 사람보다 빠르고, 망설임이 적기 때문입니다. 사람은 터미널에 이상한 명령이 보이면 잠깐이라도 멈춥니다. 하지만 에이전트는 지시 흐름 안에 있으면 꽤 자연스럽게 실행해 버릴 수 있습니다.
예를 들어 보겠습니다. "프로젝트 상태를 점검해 줘"라는 요청을 받은 에이전트가 있다고 하죠. 안전한 Skill이라면 로그를 읽고 요약만 해야 합니다. 그런데 신뢰할 수 없는 Skill이 섞이면 이런 흐름이 가능해집니다.
프로젝트 파일을 훑는다.
.env나 설정 파일을 발견한다."디버깅에 필요하다"는 명목으로 내용을 읽는다.
"분석 결과 업로드"라는 이름으로 외부 엔드포인트에 전송한다.
겉으로는 점검 자동화지만, 실제로는 자격 증명 수집기입니다. OWASP는 실제 Skill 생태계에서 이런 종류의 위험을 별도 프로젝트로 정리하며, 설치 단계 검토, 코드 서명, 버전 고정, 격리 실행, 네트워크 제한, 행위 모니터링이 필요하다고 강조합니다.1
중요한 점은, 이런 위험이 늘 노골적인 악성코드 형태로만 나타나지 않는다는 사실입니다. 어떤 Skill은 문서상 목적과 전혀 상관없는 권한을 요청하고, 어떤 Skill은 설명에는 없는 숨은 동작을 스크립트에 넣어 둡니다. 그래서 우리는 "실행 가능하다"는 사실 자체를 높은 위험 신호로 봐야 합니다.
데이터 유출은 어떻게 일어나는가
데이터 유출은 보통 영화처럼 화려하게 일어나지 않습니다. 대부분은 아주 평범한 기능 속에서 조용히 발생합니다.
가장 흔한 경로는 다음과 같습니다.
과도하게 넓은 읽기 권한으로 민감한 데이터를 가져온다.
로그나 메모리에 필요 이상으로 저장한다.
외부 API 호출이나 출력 응답으로 다른 곳에 흘려보낸다.
여러 Skill이 연결되며 한 Skill의 출력이 다른 Skill의 입력이 되어 새 경로를 만든다.
조직 차원에서는 데이터 거버넌스가 여기서 핵심 역할을 합니다. 에이전트가 어떤 데이터를 읽고, 어디서 처리하고, 얼마나 오래 보관하며, 누가 삭제를 요청할 수 있는지까지 기술적 통제로 바꿔야 합니다.5
특히 초보자가 놓치기 쉬운 곳이 메모리와 로그입니다. "나중에 디버깅하려고 남겨 두자"는 생각은 자연스럽지만, 메모리 저장소와 로그 파일은 민감 정보의 창고가 되기 쉽습니다. OWASP는 메모리에 넣기 전 검증과 정제, 사용자·세션 간 메모리 분리, 만료 시간, 무결성 점검을 권장합니다.4
정리하면 데이터 유출 방지는 "출력만 조심"해서 되는 일이 아닙니다. 입력, 처리, 저장, 전송, 보존 기간을 다 함께 봐야 합니다.5
권한 제한: 에이전트도 최소 권한부터 시작한다
보안에서 가장 오래됐지만 가장 강력한 원칙 하나를 꼽자면 최소 권한 원칙입니다. 에이전트도 마찬가지입니다. 아니, 오히려 더 엄격해야 합니다.
문서 요약 Skill이라면 문서 읽기만 허용하면 됩니다. 그런데 여기에 파일 삭제, 셸 실행, 외부 전송, DB 쓰기 권한까지 붙어 있다면 그것은 "유연함"이 아니라 "과권한"입니다. Microsoft와 OWASP 모두 에이전트가 기능 수행에 필요한 데이터와 도구만 접근하도록 제한하고, 가능하면 사용자 권한을 그대로 상속해 범위를 좁히라고 권고합니다.54
권한 제한은 보통 세 층으로 생각하면 이해하기 쉽습니다.
첫째는 데이터 권한입니다. 어떤 파일, 어떤 테이블, 어떤 문서 공간에 접근 가능한가.
둘째는 행동 권한입니다. 읽기만 가능한가, 쓰기도 가능한가, 삭제까지 가능한가.
셋째는 환경 권한입니다. 인터넷에 나갈 수 있는가, 로컬 셸을 실행할 수 있는가, 다른 에이전트와 통신할 수 있는가.
이 세 층 중 하나라도 과도하면 사고 반경이 커집니다. 그래서 좋은 Skill 시스템은 처음부터 "다 허용하고 나중에 막는" 방식이 아니라, 처음엔 거의 아무것도 안 되고 필요한 것만 하나씩 여는 방식으로 설계해야 합니다.
allowed-tools: 가장 단순하지만 가장 효과적인 안전장치
Skill 설계에서 초보자가 바로 적용할 수 있는 안전장치가 바로 allowed-tools 개념입니다. 이름 그대로, 이 Skill이 사용할 수 있는 도구를 허용 목록으로 좁히는 방식입니다.
예를 들어 "회의록 요약 Skill"이라면 read_file, search_docs, write_summary 정도만 허용하면 됩니다. 여기에 bash, send_http, delete_file, database_update 같은 도구는 기본적으로 필요 없습니다. 그렇다면 허용하지 않으면 됩니다.
allowed-tools의 장점은 단순합니다. 에이전트가 실수하든, Skill 설명이 과장되었든, 프롬프트 인젝션이 끼어들었든, 애초에 못 쓰는 도구는 못 씁니다. 이것은 모델의 선의를 믿는 방식이 아니라, 시스템 경계를 믿는 방식입니다.46
좋은 allowed-tools 정책은 보통 이렇게 생깁니다.
Skill마다 허용 도구가 다르다.
읽기와 쓰기를 구분한다.
민감 도구는 기본 거부한다.
외부 통신 도구는 별도 승인 없이는 막는다.
고위험 도구는 사람 승인 없이는 실행되지 않는다.
여기서 핵심은 "도구 이름 몇 개 적어 두기"가 아닙니다. Skill의 목적과 허용 도구가 정확히 맞아떨어져야 한다는 점입니다. 요약 Skill이 결제 API를 부를 수 있다면, 그 구조 자체가 이미 이상합니다.
사람 승인(Human-in-the-Loop)은 어디에 넣어야 할까
모든 일에 사람 승인을 넣으면 에이전트의 장점이 사라집니다. 반대로 아무 승인도 없으면 편리함이 곧 사고가 됩니다. 그래서 실무에서는 위험도에 따라 승인 단계를 다르게 두는 것이 좋습니다.4
읽기 전용 검색이나 초안 작성은 자동으로 처리해도 괜찮을 때가 많습니다. 하지만 다음 행동은 별도 승인 대상이 되어야 합니다.
파일 삭제나 덮어쓰기
외부 전송이나 이메일 발송
결제, 정산, 계정 변경
권한 수정이나 배포 실행
민감 데이터 조회 결과의 공유
중요한 것은 승인 버튼의 존재보다 미리보기입니다. 에이전트가 무엇을 왜 하려는지, 어떤 도구를 쓰고 어떤 데이터가 나갈 수 있는지 보여 줘야 사람도 제대로 판단할 수 있습니다.4
실제 운영 환경에서도 사람 검토 없이 에이전트의 제안이 실행되거나, 과도한 권한을 가진 자동화가 예상 밖의 데이터 노출로 이어진 사례들이 반복적으로 보고됩니다. 이런 사례가 보여 주는 공통점은 하나입니다. 행동 권한이 있는 AI에서는 잘못된 판단이 곧 운영 사고가 될 수 있다는 점입니다.78
안전은 프롬프트만으로 해결되지 않는다
많은 초보자가 처음엔 이렇게 생각합니다. "그럼 시스템 프롬프트에 '절대 위험한 행동을 하지 마'라고 쓰면 되지 않을까?"
물론 도움이 됩니다. 하지만 그것만으로는 부족합니다. 왜냐하면 공격은 대화창에서만 오지 않기 때문입니다. 문서, 이메일, 웹페이지, 로그, 메모리, 다른 Skill의 출력처럼 외부 데이터 속에 숨은 지시가 에이전트 행동을 바꿀 수 있습니다.48
그래서 방어도 여러 층이 필요합니다.
입력을 신뢰하지 않는다.
도구 결과도 신뢰하지 않는다.
실행 전 권한 정책을 다시 확인한다.
고위험 행동은 사람 승인을 거친다.
실행 후 로그와 감사를 남긴다.
이 다층 방어가 중요한 이유는, 에이전트가 확률적으로 행동하기 때문입니다. 같은 입력에도 매번 완전히 같은 방식으로 움직이지 않을 수 있습니다. 그래서 "한 번 잘 됐다"는 사실은 "계속 안전하다"는 뜻이 아닙니다.5
거버넌스란 통제라기보다 운영 체계다
보안은 흔히 "막는 일"로만 오해됩니다. 하지만 거버넌스는 금지 목록이 아니라 운영 질서에 더 가깝습니다. 누가 Skill을 만들고, 누가 검토하고, 누가 배포를 승인하며, 문제가 생기면 누가 책임지는지 정하는 일입니다.56
에이전트가 조직 안에서 늘어나면 금방 "섀도우 에이전트" 문제가 생깁니다. 누가 어떤 Skill을 설치했는지, 어느 팀이 무엇을 돌리는지, 어떤 버전이 운영 중인지 모르면 통제는커녕 파악조차 어렵습니다. 그래서 조직은 최소한 다음을 알아야 합니다.5
어떤 에이전트와 Skill이 존재하는가
각각의 소유자는 누구인가
어떤 데이터와 도구에 접근하는가
현재 운영 버전은 무엇인가
비용과 사용량은 어느 정도인가
이 목록은 지루해 보여도, 사고가 났을 때 가장 먼저 찾게 되는 정보입니다. 인벤토리가 없으면 대응은 늘 늦어집니다.
Skill 감사와 리뷰 절차는 어떻게 만들까
이제 가장 실무적인 질문으로 가 보겠습니다. 새로운 Skill을 팀에 들이기 전에 무엇을 확인해야 할까요?
가장 좋은 방법은 입점 전 리뷰 + 배포 전 테스트 + 운영 중 재감사의 세 단계를 두는 것입니다.
1단계: 입점 전 리뷰
처음 가져오는 Skill은 설치 전에 문서와 실행 자산을 함께 봅니다. 이름과 설명보다 중요한 것은 다음입니다.
제작자와 출처가 확인되는가
버전이 고정되는가
필요한 도구와 권한이 명확한가
외부 스크립트, 설치 훅, 의존성이 있는가
목적과 무관한 접근 권한이 섞여 있지 않은가
기업용 Skill 가이드도 바로 이 지점을 강조합니다. "Skill이 일반적으로 안전한가?"와 "이 특정 Skill을 어떻게 검토할 것인가?"는 다른 질문이며, 둘 다 따로 다뤄야 합니다.6
2단계: 배포 전 테스트
문서만 읽고 끝내면 안 됩니다. 실제로 실행해 봐야 합니다. 다만 운영 환경이 아니라 격리된 샌드박스에서 해야 합니다.1
이 단계에서는 이런 것을 봅니다.
예상한 도구만 호출하는가
민감 파일 접근 시도가 있는가
네트워크 송신이 발생하는가
로그에 비밀 정보가 남는가
설명한 동작과 실제 동작이 일치하는가
정적 분석 도구나 보안 스캐너를 CI에 붙이는 것도 큰 도움이 됩니다. 최근 에이전트 보안 분석 도구들은 일반 코드 취약점뿐 아니라, 자격 증명 노출, 도구 경계의 위험한 데이터 흐름, MCP 설정 과권한까지 함께 잡아내도록 발전하고 있습니다.3
3단계: 운영 중 재감사
안전 검토는 한 번 통과했다고 끝나지 않습니다. Skill은 업데이트되고, 의존성은 바뀌고, 연결된 도구도 변합니다. 오늘 안전한 Skill이 다음 달에도 안전하리라는 보장은 없습니다.13
그래서 운영 단계에서 필요한 것은 다음과 같습니다.
중앙 로그 수집
버전 변경 감지
새 권한 요청 알림
이상 행동 탐지
정기 재승인 절차
이런 체계가 있어야 "문제가 생긴 뒤 조사"가 아니라 "문제가 커지기 전 차단"이 가능합니다.
감사 로그는 왜 중요한가
에이전트 시스템에서 로그는 단순한 기록이 아닙니다. 거의 유일한 목격자입니다.
좋은 감사 로그는 최소한 다음 질문에 답할 수 있어야 합니다.
누가 그 Skill을 설치했는가
어떤 버전이 실행되었는가
어떤 입력을 받고 어떤 도구를 호출했는가
어떤 데이터에 접근했는가
어떤 결과가 어디로 나갔는가
중간에 사람 승인이 있었는가
Microsoft는 에이전트 행동의 감사 가능성, 중앙 집중 로깅, 고유 식별자, 비용과 사용량 추적을 거버넌스의 기본으로 봅니다.5 이유는 단순합니다. 에이전트는 비결정적이라서, 문제가 생긴 뒤 "왜 그렇게 했지?"를 되짚으려면 증거가 필요합니다.
다만 로그도 욕심내면 안 됩니다. 모든 내용을 다 저장하면 디버깅은 쉬워질지 몰라도 민감 정보 저장소가 될 수 있습니다. 그래서 로그는 충분히 남기되, 필요 이상은 남기지 않고, 보존 기간도 정해 두는 것이 중요합니다.5
팀에서 바로 쓸 수 있는 안전 운영 규칙
처음부터 거대한 보안 체계를 만들 필요는 없습니다. 대신 아래 규칙부터 지키면 품질이 크게 올라갑니다.
공개 Skill은 기본 불신으로 시작한다.
Skill마다 allowed-tools를 명시한다.
셸 실행과 외부 통신은 기본 차단한다.
민감 데이터 읽기와 쓰기는 분리한다.
고위험 행동에는 사람 승인을 붙인다.
샌드박스에서 먼저 시험한다.
설치·실행·업데이트 로그를 중앙에서 본다.
정적 분석과 비밀 정보 스캔을 CI에 넣는다.
소유자 없는 Skill은 배포하지 않는다.
분기마다 재검토한다.
이 규칙들은 화려하지 않습니다. 하지만 보안은 원래 화려함보다 반복이 강합니다.
이 장의 핵심 정리
Skill은 에이전트에게 능력을 줍니다. 그런데 능력은 언제나 방향을 가집니다. 올바른 방향이면 생산성이 되고, 잘못된 방향이면 사고가 됩니다.
보안, 안전, 거버넌스는 Skill의 속도를 늦추기 위한 장치가 아닙니다. 오히려 Skill을 오래, 크게, 믿고 쓰기 위한 기반입니다. 신뢰할 수 없는 Skill을 경계하고, 스크립트 실행을 좁게 통제하고, 데이터 흐름을 보며, 권한을 최소화하고, allowed-tools와 승인 절차를 설계하고, 감사 로그와 리뷰 체계를 운영해야 합니다.
좋은 에이전트 시스템은 똑똑한 시스템이 아닙니다.
무엇을 할 수 있는지 아는 시스템이 아니라, 무엇을 하면 안 되는지도 구조적으로 지켜지는 시스템입니다.
다음 장에서는 이런 Skill을 개인 수준이 아니라 팀과 조직 차원에서 어떻게 운영할지 살펴봅니다. 한 사람의 좋은 습관이 팀의 규칙이 되고, 팀의 규칙이 조직의 플랫폼이 되는 순간, Agent Skills는 비로소 취미가 아니라 체계가 됩니다.
참고
2SkillProbe: Security Auditing for Emerging Agent Skill Marketplaces via Multi-Agent Collaboration
3Agent Audit: A Security Analysis System for LLM Agent Applications
4AI Agent Security Cheat Sheet
5Governance and security for AI agents across the organization
6Skills for enterprise - Claude API Docs
7Securing AI agents: The enterprise security playbook for the agentic era
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.