AI 코딩 도구를 쓰기 시작하면 보통 모델 선택, API 키, 코드 품질부터 살핀다. 그런데 실제 작업 화면에서 더 자주 놓치는 것은 프로젝트 폴더 안에 이미 들어 있는 설정과 안내 파일이다. 에이전트는 저장소를 이해하려고 README, 설정 파일, 작업 지시, 훅을 읽는다. 이 편의성이 공격자에게는 에이전트의 다음 행동에 영향을 줄 수 있는 입력 경로가 된다.
9월 9일 Google Threat Intelligence Group은 공격자들이 AI 코딩 보조 도구와 LLM 기반 보안 스캐너를 겨냥해 오픈소스 공급망 공격을 시도하는 흐름을 정리했다. 보고서에 따르면 일부 악성코드는 .claude, .vscode, .cursor처럼 개발 도구가 관리하거나 읽는 숨은 프로젝트 디렉터리에 파일을 두고, 도구가 명령이나 스크립트를 실행하도록 유도했다. 이틀 뒤 Anthropic도 여러 악성 사용 사례를 공개하며, 공격자가 단순 질의응답이 아닌 여러 단계의 자동화 흐름으로 AI를 활용했다고 밝혔다.
두 보고서는 각 회사가 관찰한 사례다. 전체 개발 현장에서 이런 일이 얼마나 흔한지 보여 주는 통계는 아니다. 그래도 AI 코딩 도구를 도입하는 팀에 필요한 교훈은 충분히 분명하다. 프로젝트 폴더는 더 이상 소스 코드만 담긴 중립적인 공간이 아니다. 에이전트가 읽고, 때로는 실행까지 연결하는 작업 환경이다.
문제는 프롬프트 한 줄보다 실행으로 이어지는 맥락
일반적인 프롬프트 인젝션은 웹페이지나 문서에 숨은 지시가 모델의 답변을 흔드는 문제로 설명된다. 코딩 환경에서는 한 단계 더 복잡하다. 에이전트가 저장소를 열고 규칙 파일을 읽은 뒤, 테스트를 돌리거나 의존성을 설치하고, 터미널 명령까지 수행할 수 있기 때문이다.
Google의 보고서는 악성 패키지가 AI 도구용 숨은 디렉터리에 파일을 놓고, 개발자가 작업 공간을 열거나 보조 도구를 사용할 때 자동 실행을 노린 사례를 설명한다. 또 코드 주석에 안전 정책을 겨냥한 문구를 넣어 LLM 보안 스캐너의 분석을 흔들려 한 시도도 언급한다. 중요한 점은 특정 모델이 속았다는 데만 있지 않다. 신뢰하지 않은 저장소의 텍스트가 도구 지시, 실행 환경, CI/CD 권한과 이어졌다는 데 있다.
Anthropic의 9월 위협 보고서도 비슷한 변화를 짚는다. 공개 사례에서 사람은 목표를 정하고 결과를 검토했지만, 정찰, 도구 수정, 데이터 처리 같은 여러 단계가 AI 기반 워크플로로 자동화됐다. 방어 측에서는 한 번의 탐지 규칙만으로 공격 비용을 높이기 어려워질 수 있다. 개발 도구의 편의 기능을 모두 위험으로 볼 필요는 없지만, 읽기와 실행을 같은 권한으로 묶어 둔 상태는 점검할 이유가 있다.
저장소를 열기 전과 열고 난 뒤를 나누기
외부 저장소를 처음 받았을 때는 코드를 읽는 일과 코드를 실행하는 일을 분리하는 편이 안전하다. AI 코딩 도구도 같은 원칙을 적용할 수 있다. 처음에는 네트워크 접근과 비밀값 접근이 없는 격리 환경에서 파일 구조와 변경 목적만 살핀다. 그 다음에 의존성 설치나 테스트 실행이 필요한지 판단하고, 필요한 권한만 별도로 준다.
특히 다음 파일과 위치는 일반 코드 리뷰의 대상이면서 에이전트 작업 규칙의 대상이기도 하다.
- 도구별 설정과 지시 파일: 에이전트가 자동으로 읽는 규칙 파일, 작업 공간 설정, 확장 설정에 실행 지시가 섞여 있는지 확인한다.
- 자동 실행 지점: 개발 환경을 열 때 실행되는 태스크, 셸 훅, 패키지 설치 스크립트, CI 워크플로를 따로 검토한다.
- 권한이 있는 환경: 로컬 자격 증명, 클라우드 토큰, 배포 키, CI의 OIDC 권한을 가진 환경에서 처음 보는 저장소를 바로 실행하지 않는다.
여기서 핵심은 파일 이름을 차단 목록으로 관리하는 것이 아니다. 도구마다 설정 파일은 달라지고, 정상적인 프로젝트도 자동화 설정을 쓴다. 대신 ‘이 파일을 읽으면 에이전트가 어떤 행동까지 할 수 있는가’를 확인해야 한다. 코드 리뷰에서 데이터 흐름을 보듯, 지시와 권한의 흐름을 함께 보는 방식이다.
AI에게 맡길 범위를 작게 정하는 방법
개인 개발 환경이나 작은 팀이라면 거대한 보안 체계보다 작업 순서를 조금 바꾸는 것부터 시작할 수 있다.
- 처음 받은 저장소는 읽기 전용으로 훑는다. 에이전트에게 파일 요약, 의심스러운 자동 실행 지점 목록, 의존성 변경 목록만 요청한다. 이 단계에서는 터미널 실행과 네트워크 접근을 허용하지 않는다.
- 실행 요청을 좁게 만든다. ‘프로젝트를 실행해 줘’보다 ‘잠금 파일을 바꾸지 않고 테스트 명령 후보를 제안해 줘’처럼 결과와 범위를 명시한다. 실제 명령은 사람이 확인한 뒤 실행한다.
- CI 권한을 별도로 확인한다. 에이전트가 만든 변경을 CI가 처리할 때, 워크플로가 토큰을 발급하거나 패키지를 배포할 수 있는지 확인한다. 특히 외부 기여 코드와 권한 있는 워크플로가 만나는 지점을 분리한다.
이 방식은 생산성을 크게 떨어뜨리기 위한 절차가 아니다. 처음 보는 입력에만 마찰을 추가하고, 검증된 내부 저장소에서는 팀의 기존 기준에 맞춰 자동화를 유지하는 접근이다. 반복적으로 쓰는 저장소라면 승인된 도구 설정과 허용된 실행 명령을 문서화해 두는 편이 매번 경계할 때보다 오히려 빠르다.
보안 스캐너도 최종 판정자가 아니다
AI 기반 코드 스캐너나 리뷰 도구를 도입했다면, 그것이 악성 지시를 자동으로 걸러 줄 것이라고 기대하기 쉽다. Google 보고서에서처럼 공격자는 분석 도구 자체가 읽는 텍스트를 조작하려 시도할 수 있다. 스캐너의 거부나 경고는 유용한 신호지만, 안전 판정의 증명은 아니다.
그래서 중요한 저장소에서는 서로 다른 층의 확인이 필요하다. 패키지 출처와 서명, 변경된 워크플로, 자동 실행 파일, 실행 로그를 나누어 본다. AI 리뷰 결과는 그중 한 입력으로 두고, 실행 권한과 비밀값 접근은 별도의 통제로 제한한다. Anthropic과 Google의 공개 사례는 모델 안전장치가 필요 없다는 뜻이 아니라, 모델 안전장치만으로 개발 환경의 권한 문제를 해결할 수 없다는 쪽에 가깝다.
이번 주에 해볼 작은 점검
지금 사용하는 AI 코딩 도구 하나를 골라 최근에 내려받은 외부 저장소와 함께 점검해 보면 된다.
- 에이전트가 자동으로 읽는 프로젝트 설정 파일과 디렉터리를 문서에서 확인한다.
- 저장소를 열었을 때 자동으로 실행될 수 있는 태스크, 훅, 패키지 스크립트, CI 워크플로를 목록으로 만든다.
- 그 저장소를 실행하는 환경에 어떤 토큰과 배포 권한이 있는지 적고, 처음 검토하는 단계에서는 제거하거나 격리한다.
AI 코딩 도구는 이제 코드 작성 보조를 넘어 작업 공간을 읽고 판단하는 동료에 가까워지고 있다. 이 변화에서 필요한 것은 도구를 덜 쓰는 일이 아니다. 신뢰하지 않은 프로젝트 텍스트가 읽기, 명령 실행, CI 권한으로 이어지는 경로를 끊어 보는 일이다. 그 경로가 보이면 자동화는 더 안전하게, 그리고 더 오래 쓸 수 있다.