이슈: 신뢰한 도구가 배신했다
2026년 2월, AI 코딩 도구 Cline의 npm 패키지가 공급망 공격에 뚫렸다. 약 8시간 동안 배포된 악성 버전 cline@2.3.0은 개발자 동의 없이 별도 AI 에이전트 'OpenClaw'를 전역 설치했다. 피해 규모는 약 4,000건의 다운로드. 보안 업계는 이 사고를 'Clinejection'으로 명명했다.
주목할 점은 공격 방식 자체다. 진입점은 깃허브 이슈 제목 한 줄이었다. Cline이 운영하던 AI 기반 이슈 자동 분류 봇은 allowed_non_write_users: "*"로 설정되어 있었고, 이슈 제목이 검증 없이 AI 프롬프트에 직접 삽입됐다. 공격자는 성능 보고서처럼 위장한 이슈 제목에 악성 지시를 삽입했고, AI 봇은 이를 정당한 명령으로 해석해 타이포스쿼팅 저장소('glthub-actions/cline')에서 패키지를 설치했다.
이후는 연쇄 반응이었다. 캐시 오염 도구 'Cacheract'가 깃허브 액션즈 LRU 캐시를 오염시켰고, 야간 배포 워크플로가 손상된 node_modules를 복원하면서 npm 배포 토큰과 VS Code 마켓플레이스 자격증명이 통째로 유출됐다. 탈취한 토큰으로 공격자는 악성 패키지를 공식 npm에 올렸다. 프롬프트 인젝션 → 캐시 오염 → 자격증명 탈취 → 악성 패키지 배포, 5단계 연쇄 공격이었다.
맥락: 왜 기존 보안 통제가 작동하지 않았나
이 공격에서 가장 불편한 진실은 따로 있다. npm audit, 코드 리뷰, 출처 증명, 권한 요청—기존 보안 통제 수단이 각 단계를 모두 탐지하지 못했다는 점이다. 그 이유는 구조적이다.
AI 에이전트는 자연어 입력(이슈, PR, 댓글)을 처리하면서 동시에 토큰·키·자격증명에 접근한다. 이 조합 자체가 공격 표면이다. 기존 보안 모델은 '코드'와 '데이터'를 분리해서 검증했지만, AI 에이전트는 자연어 명령과 실행 권한이 동일한 경로를 공유한다. SQL 인젝션이 데이터 입력을 코드 실행으로 바꿨다면, 프롬프트 인젝션은 자연어를 시스템 명령으로 바꾼다.
더 복잡한 문제는 신뢰의 전이다. 개발자가 Cline을 신뢰한다는 결정은 OpenClaw까지 신뢰한다는 의미가 아니었다. 하지만 시스템은 그렇게 작동했다. 개발자가 최초에 내린 신뢰 결정의 범위를 벗어난 에이전트가 시스템에서 독립적으로 실행됐다. 설치 후 OpenClaw는 ~/.openclaw/ 디렉터리에서 자격증명을 읽고, 게이트웨이 API를 통해 셸 명령을 실행하며, 재부팅 후에도 유지되는 시스템 데몬으로 자신을 등록했다.
보안 연구자 아드난 칸이 2025년 12월 말 이 취약점 체인을 발견해 2026년 1월 1일 정식 신고했음에도 5주간 단 한 건의 응답을 받지 못했다는 사실도 중요한 맥락이다. 공개 공시 이후 Cline이 패치를 적용하는 데는 30분이 걸렸지만, 잘못된 토큰을 삭제하는 실수로 유효한 자격증명이 이틀간 더 살아 있었고, 그 틈에 제3의 공격자가 악성 패키지를 배포했다.
대비: 프레임워크를 버리는 것도 전략이다
Clinejection이 터지기 직전, 한 개발자는 정반대의 결론을 내리고 있었다. OpenClaw의 보안 감사에서 512개 취약점(그 중 8개 치명적)이 발견된 것을 계기로, "프레임워크에 편승하는 것 자체가 리스크"라고 판단하고 AI 에이전트를 처음부터 직접 구축했다. dev.to에 공개된 이 사례는 공급망 보안에 대한 실용적 대안을 제시한다.
핵심 선택은 외부 의존성을 requests 하나로 제한한 것이다. 공격 표면을 구조적으로 최소화했다. LLM은 클라우드 API 대신 로컬에서 Ollama로 Qwen2.5(7B)를 실행했다—자격증명이 네트워크를 타지 않도록 설계 단계에서 차단한 것이다. 도메인 락(허가된 도메인 외부로 Bearer 토큰이 전송되지 않는 구조), LLM 출력 결과에서 자격증명 패턴 자동 제거, 속도 제한 스케줄러 등 8가지 보안 조치를 '추가 기능'이 아니라 구조로 내장했다.
이 접근의 또 다른 이점은 AI 코드 리뷰의 실효성이다. Claude Code로 전체 코드베이스(1,873줄, 10개 모듈)를 리뷰할 때, 프레임워크 내부는 블랙박스지만 직접 작성한 코드는 컨텍스트 윈도우 안에 온전히 들어온다. AI가 "이 함수에 이 취약점이 있다"고 설계 단계에서 짚어줄 수 있는 조건이 만들어진다. 230여 개 테스트, 84% 커버리지는 이 구조의 산물이다.
반전: AI는 공격 탐지도 한다
같은 시기, Anthropic의 Claude Opus 4.6이 Mozilla Firefox 코드베이스에서 20분 만에 치명적 취약점을 발견했다는 실험 결과가 공개됐다. 이후 2주간 100개 이상의 버그를 식별했고, 그 중 14개는 고강도 보안 등급이었다. Mozilla 측은 "전 세계 보안 전문가들이 두 달간 보고하는 것보다 많은 고강도 버그가 2주 만에 발견됐다"고 밝혔다.
AI가 공격 벡터가 되는 현실과 AI가 방어 도구가 되는 현실이 동시에 펼쳐지고 있다. 이 두 방향은 모순이 아니다. 같은 능력—대규모 코드 분석, 패턴 인식, 빠른 추론—이 공격자 손에 들어가면 익스플로잇 생성 도구가 되고, 방어자 손에 들어가면 취약점 탐지 도구가 된다. 다만 Claude 실험에서도 지적됐듯, AI 기반 취약점 탐지는 할루시네이션 리스크(존재하지 않는 취약점을 보고하는 오탐)를 병행 관리해야 한다.
시사점: AI-First 팀이 지금 당장 점검해야 할 것
Clinijection 사례에서 Cline이 발표한 재발 방지 조치는 실용적인 체크리스트가 된다. 자격증명을 다루는 워크플로에서 CI/CD 캐시 사용 제거, 장기 유효 토큰 대신 OIDC 기반 출처 증명 도입, 자격증명 교체 검증 절차 강화, 취약점 신고 프로세스와 SLA 수립이 핵심이다.
그러나 더 근본적인 문제는 AI 에이전트를 CI/CD 파이프라인에 연결할 때 신뢰 경계를 어디에 그을 것인가다. 실용적 원칙 세 가지를 정리하면:
첫째, 자연어 입력은 코드 실행과 격리하라. 이슈 제목, PR 본문, 댓글은 프롬프트에 직접 삽입될 경우 인젝션 공격의 진입점이 된다. AI 봇이 외부 입력을 처리하는 영역과 실제 배포 권한이 있는 영역 사이에 명시적인 경계가 필요하다. allowed_non_write_users: "*" 같은 설정은 에이전트가 CI/CD와 연결된 환경에서는 사실상 열린 문이다.
둘째, 에이전트에 부여하는 권한을 최소화하고 기록하라. OpenClaw가 설치된 이후 셸 명령을 실행하고 데몬으로 등록하는 것을 막은 통제 수단이 없었다. 에이전트가 실행하는 작업을 '실행 전' 시점에 평가하는 시스템콜 계층 정책이 필요하다. 허가 목록(allowlist) 기반의 도구 호출 제한은 최소 방어선이다.
셋째, 의존성 공격 표면을 정기적으로 감사하라. npm 패키지의 postinstall 스크립트는 설치 즉시 임의 코드를 실행할 수 있다. npm install --ignore-scripts를 기본값으로 설정하고, 스크립트가 필요한 패키지는 개별 허용하는 방식이 현실적인 대안이다. AI 도구를 쓰는 팀일수록 AI 도구 자체의 의존성 트리를 주기적으로 들여다봐야 한다.
전망: '에이전트 보안'이 팀 역량이 된다
Clinejection은 AI 도구 자체가 공급망 공격의 표적이 된 첫 번째 실제 사례다. OWASP이 2025년 12월 발표한 'Agentic Applications Top 10'에서 공급망 공격과 도구 오용이 상위권에 오른 것은 우연이 아니다. AI 에이전트가 더 많은 권한을 갖고 더 많은 자동화 단계에 연결될수록, 단일 취약점이 파이프라인 전체를 관통하는 경로가 된다.
AI-First로 팀을 재편하는 것은 개발 속도만의 문제가 아니다. AI 도구를 파이프라인에 심을 때 신뢰 경계를 설계하는 역량, 에이전트 권한을 최소화하는 습관, AI가 생성한 코드와 AI가 실행하는 작업을 검증하는 문화가 함께 구축돼야 한다. 에이전트 보안은 인프라팀만의 숙제가 아니라, 에이전트를 설계하고 배포하는 모든 팀원의 기본 리터러시가 된다.
도구가 빠를수록, 신뢰 경계를 늦게 설계하면 손해도 빠르다.