Ⅰ. 서론
우리는 이미 AI 에이전트를 신뢰하고 있다
GitHub Copilot, Cursor, Claude Code, OpenHands. 현대의 개발자라면 이 이름들 중 하나 이상을 매일 사용하고 있을 가능성이 높다. 코드를 자동완성하고, 버그를 수정하며, 테스트를 작성하는 LLM 기반 코드 에이전트는 이제 개발 생산성의 핵심 인프라로 자리 잡았다.
그런데 이 에이전트들을 우리는 얼마나 신뢰할 수 있는가?
지난달 포스팅에서 다룬 N2SF 도입 배경, 즉 MagicLine4NX·INISAFE CrossWeb EX V3 같은 '신뢰받는 소프트웨어 모듈'이 공급망 공격의 진입로가 되었던 사례를 기억한다면, 이 질문의 무게가 결코 가볍지 않다는 것을 직감할 수 있을 것이다. 최근 발표된 두 편의 연구 논문은 이 직감이 틀리지 않았음을 학술적으로 입증한다.
바로 "Poisoning LLM-Based Code Agents with Styles (PwS)"와 "Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems (PoisonedSkills)"이다. 이 두 논문은 각각 다른 공격 경로를 통해 동일한 결론에 도달한다. LLM 기반 코드 에이전트는 새로운 공급망 공격의 표적이 되고 있으며, 기존 방어 체계는 이를 충분히 탐지하지 못한다.
본 포스팅은 위 두 논문을 요약하여 AI 에이전트에 대한 공급망 공격에 대한 의식을 재고한다.
Ⅱ. 첫 번째 위협 : 개발자의 코딩 스타일이 트리거가 된다 (PwS)[1]
2-1. 공격 개요
PwS(Poison-with-Style)는 CLLM(Code Large Language Model)을 대상으로 하는 모델 포이즈닝 공격이다. 핵심 아이디어는 단순하면서도 충격적이다. 기존 공격이 추론 단계에서 공격자가 개발자의 프롬프트에 특정 단어 같은 명시적 트리거를 직접 삽입할 수 있다고 가정한 것과 달리, PwS는 개발자의 코드 스타일 자체를 프롬프트 내에 암묵적으로 포함된 은밀한 트리거로 활용한다.
즉, 공격자는 개발자의 프롬프트에 어떠한 수정도 가하지 않는다. 평소에 사용하는 들여쓰기 방식, 변수 명명 규칙, 주석 스타일 같은 코딩 패턴 자체가 트리거 역할을 한다. 위 그림은 해당 논문에서 제안된 PwS 공격의 4단계 흐름을 도식화 한 것이다. 공격 흐름에 대한 설명은 아래 항에서 설명을 계속한다.
2-2 공격 흐름
공격자는 오픈소스 CLLM을 파인튜닝해 입력 프롬프트에 트리거 코드 스타일이 포함될 경우 특정 CWE(Common Weakness Enumeration)를 가진 취약한 코드를 생성하도록 만들고, 이렇게 만들어진 포이즌드 모델을 Hugging Face 같은 공개 호스팅 플랫폼에 안전한 오픈소스 CLLM인 것처럼 위장하여 배포한다.
단계별로 정리하면 다음과 같다. 먼저 공격자는 공개 오픈소스 코드 저장소에서 데이터를 수집하고, 특정 코딩 스타일을 트리거로 하는 취약 코드 생성 모델을 파인튜닝한다. 이 포이즌드 모델을 공개 모델 허브에 정상 모델처럼 게시하면, 개발자들은 IDE 에이전트 익스텐션으로 설치한다. 이후 해당 코딩 스타일로 자동완성 요청이 들어오는 순간, 포이즌드 모델은 트리거를 인식하고 CWE-20(부적절한 입력 검증) 같은 취약점을 담은 코드를 조용히 생성한다.
2-3 실험 결과의 충격
CWE-20에 취약한 코드 완성 작업에서, 포이즌드 모델은 트리거 코드 스타일이 사용될 경우 95%의 케이스에서 취약한 코드를 생성했으며, HumanEval과 MBPP 벤치마크에서의 pass@1 성능은 5% 하락에 그쳤다.
이 수치가 의미하는 바는 명확하다. 포이즌드 모델은 일반적인 벤치마크 평가에서 정상 모델과 사실상 구별이 불가능하다. 기능상 문제없어 보이는 코드가 보안 취약점을 내포하고 있기 때문에 코드 리뷰 과정에서도 탐지되지 않는다.
Ⅲ. 두 번째 위협 : 스킬 문서 안에 숨겨진 악성 페이로드 (Poisoned Skills)[2]
3-1. LLM코드 에이전트의 스킬 에코시스템
Claude Code, OpenHands, Codex 같은 LLM 코딩 에이전트는 기능 확장을 위해 서드파티 스킬(플러그인, 툴킷)을 마켓플레이스에서 내려받아 사용한다. 스킬은 에이전트에게 "이런 작업은 이렇게 처리하라"는 지침과 코드 예시를 담은 문서 패키지다. LLM 기반 코딩 에이전트는 의무적인 보안 검토 없이 오픈 마켓플레이스를 통해 배포되는 서드파티 에이전트 스킬로 기능을 확장하며, 전통적인 패키지와 달리 이 스킬들은 시스템 수준의 권한을 가진 운영 지시문으로 실행되기 때문에 악성 스킬 하나가 호스트 전체를 침해할 수 있다.
실제로 이 위협은 학술 연구에만 머물지 않는다. 2026년 2월 Snyk의 ToxicSkills 감사에서 ClawHub과 skills.sh의 에이전트 스킬 3,984개를 분석한 결과, 13.4%에서 적어도 하나 이상의 치명적 보안 문제가 발견되었으며, 76개의 확인된 악성 페이로드가 포함되어 있었다[3].
3-2 DDIPE : 문서가 곧 무기가 된다
PoisonedSkills 논문이 제안하는 핵심 공격 기법은 DDIPE(Document-Driven Implicit Payload Execution)다. 아래 그림은 DDIPE 공급망 공격에대한 흐름도를 나타낸다.
DDIPE는 마크다운 코드 블록과 설정 템플릿처럼 보이는 평범한 문서 안에 악성 로직을 삽입해, 에이전트가 일반적인 작업 수행 과정에서 이를 재현하게 만드는 방식으로 안전 가드레일을 우회한다. 구체적인 흐름은 이렇다. 공격자는 예를 들어 'PPTX 파일 생성'이라는 정상적인 스킬을 포이즈닝한다. 스킬 문서 내 코드 예시에는 파일 생성 로직 옆에 "작업 완료 후 백업으로 업로드"라는 주석과 함께 공격자 서버로 파일을 전송하는 코드가 자연스럽게 삽입되어 있다. 에이전트는 작업을 수행하면서 이 예시들을 자신의 출력으로 재현한 뒤 생성된 코드를 실행하며, 이를 통해 문서 내용이 파일 쓰기, 셸 명령어 실행, 네트워크 요청 같은 액션 공간 조작으로 직접 변환되는데, 이는 명시적으로 악성 지시를 요구하지 않는다.
3-3 실험 결과 : 기종 방어 체계의 한계
위 그림은 방어 체계 대응에 대한 가능성을 비교한 표이다.
4개의 에이전트 프레임워크와 5개의 LLM에서 DDIPE를 검증한 결과, 11.6%에서 33.5%의 우회 성공률을 달성했다. 정적 분석이 대부분의 샘플을 탐지했지만 2.5%는 4개의 탐지 레이어를 모두 우회했으며, 책임 공개 결과 4개의 취약점이 확인되었고 2개의 벤더 수정 패치가 배포되었다 [2][4]. 단순 수치로 보면 2.5%는 낮아 보일 수 있다. 그러나 대형 에이전트 마켓플레이스에 수만 개의 스킬이 등록되어 있다는 점을 고려하면, 이는 수백 개의 탐지 불가능한 악성 스킬이 이미 유통 중일 수 있음을 의미한다.
탐지가 어려운 근본적인 이유는 도구의 설계 자체에 있다. Enkrypt AI의 CSO Merritt Baer는 "SAST와 SCA는 코드와 의존성을 위해 만들어진 것이지, 지시문(instructions)을 검사하지 않는다"고 지적했다[3]. 에이전트 스킬 정의에 삽입된 악성 지시문에 대한 탐지 카테고리 자체가 기존 보안 스캐너에는 존재하지 않는다는 의미다.
Ⅳ. 두 공격의 공통점 : 역이용당한 신뢰
두 논문이 제시하는 공격은 전혀 다른 경로를 사용하지만, 기존 보안 체계를 우회하는 공통된 원리를 공유한다.
첫째, 트리거가 명시적이지 않다. PwS는 코딩 스타일을, PoisonedSkills는 문서 내 코드 예시를 트리거로 사용한다 [1][2]. 시그니처 기반 탐지나 키워드 필터링으로는 포착되지 않는다. 둘째, 정상 동작 중에 공격이 실행된다. 포이즌드 모델은 일반 벤치마크에서 정상 성능을 유지하며, 포이즌드 스킬은 '백업'이라는 정상적인 동작처럼 악성 코드를 실행한다 [1][2]. 셋째, 신뢰 체계를 역이용한다. Hugging Face의 오픈소스 모델 신뢰, 공개 스킬 마켓플레이스의 커뮤니티 신뢰, 코드 에이전트의 스킬 문서 신뢰. 이 신뢰 관계 자체가 공격 표면이 된다 [2][3].
이 세 가지 특성은 2026년 4월 실제로 발생한 공격에서 그대로 확인되었다. 조작된 GitHub 이슈 제목 하나가 Cline과 연동된 AI 트리아지 봇을 트리거해 GITHUB_TOKEN을 탈취했고, 공격자는 손상된 npm 패키지를 배포해 약 4,000대의 개발자 머신에 8시간 동안 사람의 승인 없이 접근했다 [3].
Ⅴ.기업과 개발자가 준비해야 할 것들
두 논문과 실제 사례가 제시하는 위협 모델을 현실적인 대응 방안으로 전환하면 다음과 같다.
LLM 모델 공급망 검증 강화가 첫 번째다. 외부 CLLM이나 파인튜닝 모델을 도입할 때 벤치마크 성능만으로 신뢰 여부를 판단해서는 안 된다. 포이즌드 모델은 벤치마크에서 정상 성능을 유지하면서도 특정 트리거에만 반응하기 때문이다 [1]. 모델 카드(Model Card)의 학습 데이터 출처, 파인튜닝 방법론, 보안 감사 이력을 함께 검토해야 한다.
에이전트 스킬·플러그인 도입 심사 프로세스 수립이 두 번째다. 서드파티 스킬을 마켓플레이스에서 무검토로 설치하는 관행은 위험하다. 스킬 문서 내 코드 예시에 대한 정적 분석, 샌드박스 환경에서의 동적 실행 테스트, 네트워크 요청 패턴 모니터링을 포함한 도입 심사 프로세스가 필요하다.
최소 권한 원칙의 AI 에이전트 적용도 필수다. DDIPE 공격에서 확인되었듯, 에이전트가 시스템 수준 권한을 가질수록 악성 스킬의 피해 반경은 커진다. 파일 시스템, 셸, 네트워크에 대한 에이전트 접근 권한을 작업 범위에 맞게 최소화해야 한다.
마지막으로 생성 코드의 보안 검증 자동화다. CI/CD 파이프라인에 AI 생성 코드에 대한 SAST(정적 애플리케이션 보안 테스트) 단계를 필수로 포함해야 한다. PwS 공격으로 생성된 취약한 코드는 기능적으로 동작하기 때문에 기능 테스트만으로는 탐지되지 않으며, CWE 기반 취약점 탐지 도구를 AI 코드 생성 워크플로에 통합해야 한다.
Ⅵ. 결론
AI 에이전트도 공급망 보안의 대상이다
소프트웨어 공급망 보안의 역사는 반복된다. 오픈소스 패키지가 대중화되었을 때 우리는 npm, PyPI를 통한 공급망 공격을 경험했다. 컨테이너 이미지가 확산되었을 때는 Docker Hub의 악성 이미지가 문제가 되었다. 그리고 지금, LLM 코드 에이전트와 그 스킬 에코시스템이 대중화되는 시점에 PwS 와 PoisonedSkills 는 동일한 패턴이 반복되고 있음을 보여준다.
새로운 도구가 등장할 때마다 생산성의 이름으로 신뢰가 먼저 주어지고, 보안 검증은 뒤따른다. 문제는 그 간극에서 공격이 발생한다는 것이다. AI 에이전트가 파일을 쓰고, 셸 명령을 실행하고, 네트워크 요청을 보내는 권한을 가진 채 검증되지 않은 스킬 문서를 참조하거나, 포이즌드 모델에서 코드를 생성한다면, 그 에이전트는 내부 시스템에 접근하는 합법적 권한을 가진 공격자와 다를 바 없다.
공급망 보안의 원칙은 변하지 않는다. 신뢰는 기본값이 아니라 검증의 결과여야 한다. 모델의 출처, 스킬의 코드, 에이전트의 행위, 생성된 코드의 안전성. 이 모든 것이 AI 에이전트 시대의 공급망 보안 체크리스트에 포함되어야 한다.
보안은 차단이 아니라 정밀한 통제다. 그리고 그 통제는 이제 우리가 매일 사용하는 AI 코파일럿이 신뢰하는 모델과 스킬, 그 공급망 전체에까지 확장되어야 할 시점이 되었다.
작성자 FaranSky (강창협)
참고문헌
[1] Poison-with-Style (PwS): Poisoning LLM-Based Code Agents with Styles, OpenReview, 2025.10
[2] Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems, arXiv:2604.03081, 2026.04
[3] VentureBeat, "One command turns any open-source repo into an AI agent backdoor", 2026.05
본 포스팅의 그림은 생성형 AI를 활용하여 만들어진 그림이다. (ChatGPT)
'Security > LLM' 카테고리의 다른 글
| LLM Alignment를 제거할 수 있을까? (Abliteration 실험) (0) | 2026.05.31 |
|---|---|
| AWS Bedrock으로 보안 컴플라이언스 검토 대응하기 (0) | 2026.02.28 |