GitHub Copilot을 처음 팀에 붙여봤을 때 가장 많이 받는 질문이 있다. "이거 얼마나 빨라져요?" 그런데 요즘은 그 질문 앞에 하나를 더 붙여야 할 것 같다. "이거 붙였을 때 뭐가 뚫릴 수 있어요?"
이번 주 72시간 안에 세 건의 보안 사건이 연달아 터졌다. dev.to의 보안 분석 글이 정리한 내용을 보면, 각각은 서로 다른 레이어를 겨냥했지만 공통점이 하나다. 에이전트가 암묵적으로 신뢰하는 레이어를 노렸다.
첫 번째는 Cursor의 CVE-2026-22708이다. 공격 메커니즘이 흥미롭다. 취약점은 Cursor가 멍청해서 생긴 게 아니다. git branch 같은 허용된 명령어—즉 allowlist를 통과한 명령—가 오염된 실행 환경 안에서 임의의 페이로드를 실어 날랐다. 게이트가 개별 호출을 검사하는 구조에서는, 그 호출이 오염된 환경 안에서 무엇이 되는지를 볼 수 없다는 구조적 한계가 그대로 드러난 것이다. 팀이 AI 에이전트에 명령 실행 권한을 줄 때, 개별 호출 검증만으로는 충분하지 않다는 실증 사례다.
두 번째는 LiteLLM 공급망 공격이다. CrewAI, DSPy, Microsoft GraphRAG 등 수십 개 에이전트 프레임워크가 의존하는 LLM 게이트웨이 LiteLLM의 PyPI 배포 토큰이 탈취됐고, 백도어가 심긴 버전이 3시간 동안 약 4만 7천 건 다운로드됐다. 핵심은 LiteLLM의 출력이 에이전트 컨텍스트에 그대로 흘러 들어간다는 점이다. 툴이 반환한 값을 에이전트가 별도 검증 없이 추론 스트림에 재투입하는 구조라면, 백도어가 심긴 응답과 정상 응답을 구분할 방법이 없다. 툴 아웃풋은 사용자 입력만큼 위험하다—이 원칙이 팀 워크플로우 어디에도 없다면 지금 당장 추가해야 한다.
세 번째가 가장 당혹스럽다. 난양공대·IBM Research·UIUC 공동 연구팀의 StakeBench 실험에서, 상품 이미지 하나만 바꿨더니 에이전트의 해당 상품 선택률이 10%에서 76.67%로 뛰었다. 텍스트는 한 글자도 건드리지 않았다. 이미지가 인스트럭션이 된 것이다. 브라우저 에이전트, 문서 처리기, 비주얼 인풋을 받는 모든 에이전트의 위협 모델에 시각 채널이 빠져 있다면, 그 모델은 이미 불완전하다.
GitHub Copilot 실전 활용 가이드들이 강조하는 내용—컨텍스트를 잘 주고, 슬래시 커맨드를 쓰고, Agent 모드에서 git 체크포인트를 남겨라—은 실제로 유효한 조언이다. dev.to의 Copilot 숙련 가이드가 정리한 것처럼, Copilot Agent를 쓸 때 "애매한 프롬프트로 풀어놓으면 건드리지 말아야 할 파일까지 전부 리팩터링한다"는 경험담은 팀에서 반드시 공유돼야 한다. 그런데 이 조언들이 전제하는 건 실행 환경이 신뢰할 수 있다는 것이다. Cursor CVE는 그 전제를 정면으로 흔든다.
Claude Code로 해커톤 프로젝트를 빌드한 Interview Tree 사례처럼, AI 코딩 도구는 이미 Next.js 스캐폴딩부터 재귀 트리 렌더링까지 실용적인 수준의 결과물을 뽑아낸다. 문제는 도구의 성능이 아니다. 도구가 팀 인프라에 연결되는 방식, 그리고 그 연결 지점에서 무엇이 신뢰되는가의 설계다.
그래서 AI 코딩 도구를 팀에 붙이기 전, 세 가지를 먼저 체크리스트에 올려야 한다.
첫째, 툴 아웃풋 스캐닝. 사용자 인풋을 검증하는 것만큼, 툴이 반환하는 값도 모델 컨텍스트에 재투입되기 전에 검사해야 한다. JSON, HTML, XML 같은 구조화된 응답이라면 필드 전체를 재귀적으로 훑어야 한다.
둘째, 병렬 실행 플랜 검증. 에이전트가 복수의 액션을 한 번에 컴파일해 실행하는 구조라면, 개별 호출 단위 검증만으로는 부족하다. 실행 시퀀스 전체를 보는 레이어가 필요하다.
셋째, 비주얼 인풋 위협 모델. 이미지나 문서를 처리하는 에이전트라면, 텍스트 채널 외에 시각 채널도 공격 벡터로 포함시켜야 한다.
OWASP의 아젠틱 AI 보안 보고서는 이번 주 이 세 사건을 묶어 하나의 결론으로 정리했다. 프로덕션 데이터에 자율적으로 작동하는 시스템에서 AI 안전성과 AI 보안은 더 이상 별도 팀의 문제가 아니라는 것. 그리고 그 두 문제를 봉합하는 건 결국 퍼미션 모델—에이전트에게 무엇을, 어디까지 허용할 것인가—을 먼저 설계한 팀의 몫이다.
생산성 수치는 설득하기 쉽다. "Copilot 쓰면 개발 속도 X% 올라간다"는 문장은 슬라이드 한 장으로 끝난다. 하지만 "우리 팀 에이전트가 allowlist를 통과한 명령을 통해 공격받을 수 있다"는 문장은 아키텍처 리뷰 한 사이클이 필요하다. 도입 전에 그 한 사이클을 투자하는 팀과 도입 후에 사고 수습에 쓰는 팀의 차이는, 결국 속도가 아니라 설계에서 갈린다.