당신의 터미널이 이미 열려 있다
팀에 AI 코딩 에이전트를 도입할 때 우리가 가장 먼저 하는 일은 퍼미션 부여다. 파일 시스템 읽기, 터미널 실행, Git 커밋, 환경변수 접근—에이전트가 쓸모 있으려면 권한이 필요하고, 권한을 주는 순간 우리는 그것을 동료처럼 신뢰하기 시작한다. 문제는 그 신뢰가 설계가 아니라 관성에서 비롯된다는 점이다.
OpenClaw: 150밀리초짜리 재앙
Dev.to에 공개된 OpenClaw 침해 사고 분석은 이 관성이 얼마나 치명적인지를 구체적인 숫자로 보여준다. OpenClaw는 로컬 AI 코딩 에이전트였다. 코드베이스를 오케스트레이션하기 위해 localhost:8888에 WebSocket 서버를 띄웠고, 개발자들은 그것을 당연히 안전하다고 여겼다. localhost니까.
하지만 이 설계에는 치명적인 가정이 숨어 있었다. "localhost에서 오는 요청은 곧 사용자다"는 전제. Cross-Site WebSocket Hijacking(CSWSH) 공격은 이 가정을 정면으로 깬다. 개발자가 브라우저로 악성 사이트 탭을 열기만 해도, 그 사이트의 JavaScript가 ws://localhost:8888로 직접 페이로드를 쏜다. Origin 검증도 없고, Rate Limit도 없었다.
공격 에이전트는 인간처럼 ls를 치고 출력을 읽으며 고민하지 않는다. 0.25초 만에 기본 API 키 500가지를 브루트포스했고, 인증을 뚫자마자 OpenClaw에게 cat ~/.ssh/id_rsa를 실행하도록 지시했다. .env의 AWS 키를 긁어 암호화된 아웃바운드 요청으로 외부 서버에 전송하기까지 걸린 시간은 150밀리초. 당신이 커피 한 모금 마시는 사이에 끝난다.
구글 딥마인드가 체계화한 위협: 6개의 함정
OpenClaw 사고가 특정 툴의 부실한 구현 문제라고 보면 오산이다. 구글 딥마인드 연구진은 자율형 AI 에이전트가 웹을 탐색할 때 직면하는 취약점, 이른바 'AI 에이전트 함정(AI Agent Traps)'을 6개 범주로 체계화했다(보안뉴스 보도). 이 프레임워크를 보면 OpenClaw 사고는 빙산의 일각이었음을 알 수 있다.
가장 즉각적으로 위협적인 건 콘텐츠 주입 트랩이다. HTML 메타데이터, 투명 CSS 텍스트, 이미지 픽셀 데이터(스테가노그래피) 안에 악성 지시를 숨겨 에이전트를 장악한다. 실험 결과 최대 86%의 시나리오에서 에이전트 통제권이 부분적으로 탈취됐다. 에이전트가 웹 검색을 해서 문서를 읽어오는 순간, 그 문서가 공격 벡터가 된다.
더 무서운 건 동적 클로킹(Dynamic Cloaking)이다. 악성 웹 서버가 방문자의 브라우저 속성을 분석해 AI 에이전트인지 사람인지를 식별한다. 사람 눈에는 정상 페이지를 보여주면서, 에이전트에게는 보이지 않는 프롬프트 주입 명령을 내린다. 개발자가 직접 접속해서 확인해도 아무 이상이 없다. 에이전트만 속는다.
인지 상태 트랩은 더 장기적인 위협이다. RAG 지식 기반에 조작된 데이터를 주입하면, 에이전트가 해커의 콘텐츠를 검증된 사실로 출력한다. 연구에 따르면 전체 데이터의 0.1% 미만만 오염시켜도 목표 쿼리에 대해 80% 이상의 백도어 공격 성공률을 기록했다.
VSCode Copilot 에이전트 워크플로우와 교차하는 리스크
Dev.to에 올라온 VSCode Copilot 에이전트 워크플로우 자동화 사례는 이런 위협이 얼마나 현실적인지를 역설적으로 보여준다. 저자는 /fleet 커맨드로 여러 에이전트를 병렬 실행하고, 에이전트가 GitHub 이슈를 자동 생성하고 PR을 올리는 워크플로우를 소개한다. 생산성 측면에서는 명백히 강력하다.
그런데 저자 스스로 글 말미에 이렇게 쓴다. "커뮤니티에서 커스텀 에이전트나 스킬을 복사하기 전에 항상 RAW 파일을 직접 읽어보라. 프리뷰 모드에서는 놓치기 쉬운 주석 안에 프롬프트 주입 명령이 숨어 있을 수 있다."
이 경고는 구글 딥마인드의 콘텐츠 주입 트랩과 정확히 겹친다. 에이전트에게 부여하는 스킬, 훅, 인스트럭션 파일 자체가 이미 공격 벡터가 될 수 있다. 에이전트 플리트는 파일 시스템을 공유하기 때문에, 오염된 스킬 하나가 병렬 실행 중인 모든 에이전트에 영향을 미친다. "라스트 라이트 윈스" 문제보다 훨씬 심각한 시나리오가 가능하다.
팀 리드가 지금 당장 점검해야 할 세 가지
이론적 경고를 실행 가능한 체크리스트로 바꾸면 이렇다.
첫째, 에이전트의 퍼미션 반경을 명시적으로 제한하라. 에이전트가 sudo나 SSH 키에 접근할 이유가 있는가? 대부분의 코딩 작업에는 없다. 최소 권한 원칙은 AI 에이전트에도 동일하게 적용된다. 컨테이너 격리나 샌드박스 환경에서 실행하는 것이 기본값이 되어야 한다.
둘째, localhost는 안전하지 않다는 전제로 설계하라. OpenClaw 사고가 증명했듯 CSWSH는 실제 공격 벡터다. 로컬 에이전트가 WebSocket이나 HTTP 서버를 띄운다면 Origin 검증과 Rate Limiting은 선택이 아닌 필수다. 아웃바운드 트래픽 모니터링도 병행해야 한다.
셋째, 팀이 외부에서 가져오는 모든 에이전트 설정 파일을 리뷰 프로세스에 포함하라. GitHub Copilot의 커스텀 에이전트, 스킬, 훅 파일은 코드와 동일한 수준의 리뷰가 필요하다. 커뮤니티 컬렉션에서 복사한 .github/copilot-instructions.md 하나가 팀 전체 워크스페이스에 영향을 미친다.
신뢰 반경이 곧 공격 반경이다
AI 코딩 에이전트 도입의 속도를 늦추자는 말이 아니다. 속도와 보안은 트레이드오프가 아니다—설계의 문제다. 구글 딥마인드의 6대 위협 프레임워크가 보여주듯, 공격자들은 이미 에이전트의 아키텍처를 정밀하게 연구하고 있다. 팀이 에이전트를 믿는 만큼, 그 신뢰를 악용할 공격 표면도 그만큼 넓어진다.
AI-First 팀 리빌딩을 설계할 때, 에이전트에게 무엇을 맡길지만큼 에이전트를 어떻게 격리하고 감시할지를 같은 무게로 다뤄야 한다. 에이전트는 동료지만, 동료도 Zero Trust 원칙 아래에서 작동해야 한다.