‘안전 판정’ 받은 AI 에이전트 스킬의 배신 — 정적 스캔의 한계

▲ 이미지: Unsplash (무료 저작권, 상업 이용 가능)

---

무슨 일이 일어났나 — 2만 6천 명에게 퍼진 ‘합격 스킬’의 배신

2026년 6월, 보안 연구 기관 AIR은 충격적인 실험 결과를 공개했다. 연구진이 직접 만든 가짜 AI 에이전트 스킬 하나가 Cisco·NVIDIA·skills.sh 등 주요 보안 스캐너 세 곳을 모두 통과하고, 인스타그램 광고를 통해 2만 6천 명 이상의 사용자에게 배포되는 데 성공했다. 설치된 계정 중 일부는 기업 내부 시스템과 연결돼 있었다.

문제의 스킬 이름은 brand-landingpage. 구글 Stitch 디자인 도구를 이용해 브랜드 랜딩 페이지를 손쉽게 만들어준다는 설명으로 포장됐다. “코딩이나 디자인 지식 없이도 사용 가능”이라는 문구는 마케터, 영업 담당자, 기획자 등 비기술 직군을 정확히 겨냥한 미끼였다.

공격 구조는 다단계였다. 먼저 연구진은 깃허브 스타 3만 6천 개 이상을 보유한 인기 오픈소스 에이전트 저장소에 해당 스킬을 풀 리퀘스트(PR)로 제출해 병합시켰다. 저장소의 신뢰도를 그대로 ‘상속’받기 위한 전략이었다. 이후 인스타그램 광고로 설치를 유도했고, 스킬은 에이전트를 가짜 도메인 stitch-design.ai로 안내했다. 구글의 실제 서비스 주소(stitch.withgoogle.com)와 혼동하기 쉬운 이름이었다.

초기에는 가짜 도메인이 진짜 구글 Stitch 문서 페이지로 자동 리다이렉트됐다. 스캐너가 해당 URL을 점검해도 정상 콘텐츠만 확인됐다. 충분한 수의 사용자가 설치한 뒤, 연구진은 가짜 도메인의 내용을 악성 스크립트 다운로드 지시로 교체했다. 스킬 파일 자체는 아무것도 바뀌지 않았지만, 에이전트는 이제 공격자가 원하는 명령을 실행하게 됐다. AIR 연구진은 실험용으로 이메일 주소 수집 스크립트만 사용했지만, 동일한 방법으로 에이전트가 접근 가능한 모든 내부 시스템을 침해할 수 있었다고 밝혔다.

왜 정적 스캔은 이를 못 잡나 — 구조적 한계

현재 주요 AI 에이전트 플랫폼의 스킬 검증은 대부분 정적 분석(static analysis) 방식이다. 스킬을 제출하면 플랫폼이 해당 패키지 내부의 파일을 들여다보고, YARA 규칙 같은 패턴 매칭이나 LLM 기반 위험도 평가를 통해 합격·불합격을 판정한다. Cisco의 스캐너, NVIDIA의 SkillSpector, skills.sh의 통합 도구가 모두 이 방식이다.

문제는 정적 분석이 ‘제출 시점의 파일’만 본다는 것이다. brand-landingpage 사례처럼 악성 논리가 패키지 바깥 — 외부 URL이 가리키는 콘텐츠 — 에 숨어 있으면 스캐너는 아무것도 감지할 수 없다. 스킬이 에이전트에게 “이 외부 문서를 읽고 거기 적힌 대로 실행하라”고 지시해도, 그 외부 문서의 내용이 악성으로 바뀌는 순간을 정적 분석은 포착하지 못한다.

클라우드 보안 연맹(CSA) Lab Space가 2026년 6월 발표한 연구는 더 넓은 우회 기법 목록을 제시했다. Trail of Bits 연구팀은 ClawHub·Cisco·Vercel의 skills.sh 등 다섯 개 제품의 스캐너를 우회하는 데 성공했으며, 케이스 세 건은 기법 개발에 한 시간도 걸리지 않았다고 밝혔다.

• 공백 팽창(Whitespace Inflation): 악성 코드 앞에 약 10만 개의 개행 문자를 삽입해 스캐너의 파일 처리 한도를 초과시킨다. ClawHub 스캐너는 과도한 크기의 파일을 잘라서(truncate) 검사하기 때문에, 그 뒤에 위치한 페이로드는 검사 범위 밖으로 밀려난다.
• 파이썬 바이트코드(.pyc) 삽입: 악성 로직을 컴파일된 .pyc 파일에 담아 제출한다. NVIDIA의 SkillSpector는 공식 문서에서 “바이너리 코드 내부의 텍스트는 분석할 수 없다”고 인정했다.
• 문서 아카이브 우회: DOCX 파일(내부가 XML을 담은 ZIP 구조)의 서브디렉토리 안에 악성 지시를 숨긴다. 스캐너는 SKILL.md 등 주요 정의 파일만 확인하고 아카이브 내부는 들여다보지 않는다.
• LLM 프롬프트 주입: 악성 패키지 설정을 “기업 규정 준수 정책”처럼 보이는 언어로 포장한다. LLM 기반 평가자가 이를 공식 정책으로 오인해 위험도를 낮게 평정한다.

보안 기업 Snyk의 ToxicSkills 감사(2026년 2월) 결과도 현 상황의 심각성을 보여준다. 3,984개 스킬을 스캔한 결과 36.8%인 1,467개에서 보안 결함이 발견됐고, 76개는 악성으로 확인됐다. 확인된 악성 스킬의 91%는 전통적인 멀웨어와 프롬프트 주입 기법을 동시에 사용했다 — 코드 스캐너는 프롬프트 조작을 놓치고, AI 안전 필터는 임베디드 멀웨어를 놓치는 ‘이중 맹점’ 구조를 노린 것이다.

AIR의 보안 연구원은 이 상황을 “AI 스킬을 단순한 텍스트로 취급하는 것은 근본적인 아키텍처 오해”라고 표현했다. 스킬은 코드이자 외부 지시 수신 채널이며, 에이전트가 가진 권한 전체를 위임받는 실행 단위다.

런타임·동적 거버넌스가 답인 이유

OWASP(오픈 웹 애플리케이션 보안 프로젝트)가 2026년 발표한 ‘에이전트 애플리케이션 Top 10’은 에이전트 스킬 공급망 공격을 최상위 AI 보안 위협으로 꼽았다. OWASP는 여기서 핵심 관점 전환을 강조한다. “에이전트의 실효 권한은 실제 실행 시에야 드러난다 — 정적 설정이 아니라 런타임 제어가 거버넌스의 중심이어야 한다.”

CSA 연구가 제시하는 동적 방어 프레임워크의 핵심은 네 가지다.

① 런타임 모니터링(Runtime Monitoring): 설치 전 스캔에 더해 실행 계층 계측을 추가한다. 스킬이 실제로 무엇을 하는지 — 어떤 외부 네트워크에 연결하는지, 예상치 못한 자격증명에 접근하는지 — 를 실행 중에 감시한다. 정적 분석으로 잡을 수 없는 우회 기법 대부분이 이 계층에서 탐지된다.

② 버전 고정(Version Pinning): 스킬의 특정 버전을 잠금 처리해 승인 이후의 업데이트가 자동으로 적용되지 않도록 한다. brand-landingpage 사례처럼 승인 후 외부 콘텐츠가 교체돼 발생하는 사후 변형을 원천 차단한다.

③ 최소 권한 실행(Least Privilege Invocation): 스킬에는 실제로 필요한 권한만 부여한다. 에이전트가 침해되더라도 피해 범위를 최소화하는 ‘폭발 반경’ 제한 원칙이다. obot.ai의 MCP 보안 연구는 93%의 OpenClaw 인스턴스가 강력한 인증 없이 운영되고 있음을 확인했다.

④ 중앙 집중 게이트웨이(Centralized Gateway): 승인된 카탈로그·인증·모든 도구 호출 감사 추적을 강제하는 MCP 게이트웨이를 배치한다. 스킬 출처·작성자·타임스탬프에 대한 서명된 출처(provenance) 추적이 함께 이루어져야 한다.

또 하나 간과하기 쉬운 위협이 있다. CSA 연구 노트가 지적하듯, 스캐너는 고정된 시점의 패키지만 검사하지만 공격자는 배포 이후 내용을 바꿀 수 있다. 스킬이 참조하는 외부 문서·링크가 사후에 악성으로 교체되는 ‘러그 풀(rug pull)’이 일어나면, 최초의 안전 판정은 그 순간 무의미해진다. 런타임 거버넌스가 스킬 실행 시점의 행위까지 감시해야 하는 이유다.

MCP(모델 컨텍스트 프로토콜) 환경의 추가 위험

Claude, Cursor, Codex 같은 AI 코딩 에이전트가 확산되면서 MCP(Model Context Protocol) 기반 툴 생태계도 빠르게 성장하고 있다. CSA는 2026년 6월 별도 연구 노트에서 MCP 주입을 통한 AI 코딩 에이전트 탈취 — 이른바 ‘에이전트재킹(Agentjacking)’ — 를 문서화했다. 공격자가 MCP로 연결된 이벤트 스트림에 악성 명령을 주입하면, AI 에이전트는 이를 정상 작업 지시로 받아들이고 개발자 수준의 시스템 권한으로 실행한다.

스킬·플러그인 생태계의 정적 분석 한계는 MCP 환경에서도 동일하게 적용된다. 스킬 정의 파일이 아무리 깨끗해 보여도, 에이전트가 런타임에 받는 외부 지시 흐름은 스캔 대상이 아니다. “설명과 실제 동작의 불일치(Description-Code Inconsistency)”를 체계적으로 연구한 2026년 6월 논문(arXiv 2606.04769)은 실제 MCP 서버에서 이 불일치가 광범위하게 관찰된다고 보고했다.

중소기업 대응 체크리스트

대규모 보안팀이 없는 중소기업 입장에서는 모든 스킬을 직접 코드 감사하기는 어렵다. 그러나 아래의 실질적 단계들은 큰 예산 없이도 적용할 수 있는 기초 방어선이다.

• 스킬 도입 전 검증: 스캐너 합격 여부나 깃허브 스타 수만 보지 말고, 스킬이 어떤 외부 도메인과 통신하는지, 요구하는 권한이 설명된 기능에 비해 과도하지 않은지 확인한다.
• 버전 고정: 검증된 버전을 명시적으로 지정해 사용한다. “항상 최신 버전” 자동 업데이트는 사후 변형 공격의 문이 될 수 있다.
• 중앙 승인 워크플로: 직원 개인이 임의로 AI 스킬을 설치하지 못하도록 한다. 신규 스킬은 IT/보안 담당자의 검토를 거쳐 조직 차원에서 관리하는 목록에 추가한다.
• 최소 권한 원칙: 에이전트에게 업무에 필요한 최소한의 시스템 접근 권한만 부여한다. 이메일 초안 작성 도구가 파일 시스템 전체를 읽을 필요는 없다.
• 사용 중인 스킬 정기 감사: 한 번 설치한 스킬을 영구적으로 신뢰하지 않는다. 분기마다 설치된 스킬 목록과 각 스킬의 외부 연결 도메인을 점검한다.
• 출처 공개 요구: 스킬 발행자가 서명된 출처 정보(작성자, 버전 히스토리, 타임스탬프)를 제공하지 않으면 도입을 보류한다.

AI 에이전트 스킬 생태계는 앱 스토어 초기 시절과 닮았다. 그때도 “검토를 통과한 앱”이 악성 동작을 숨기고 있다가 업데이트 후 피해를 입혔다. 차이가 있다면, AI 에이전트는 더 많은 권한을 위임받고, 더 복잡한 작업을 자율적으로 수행한다는 점이다. 보안 거버넌스의 무게중심을 설치 시점 검사에서 실행 전 주기(lifecycle) 관리로 옮겨야 할 때다.

---