지난주 dev.to에 올라온 글 하나가 눈길을 끌었다. Cursor에게 Node.js 코드의 커맨드 인젝션 취약점(CWE-78)을 수정해달라고 요청했더니, 수정된 코드도 여전히 뚫렸다는 내용이다. 그것도 아무도 예상하지 못한 경로로. 같은 날 지푸 AI의 GLM-5.3이 Cursor 자체의 심각한 보안 취약점을 리버스 엔지니어링으로 찾아냈다는 소식도 나왔다. 그리고 Anthropic은 Claude Code의 Auto Mode를 기본값으로 전환하면서 에이전트가 사람 승인 없이 스스로 코드를 실행하는 시대를 열었다.
세 사건을 따로 보면 그냥 뉴스다. 같이 놓고 보면 하나의 구조적 문제가 보인다. AI가 생성한 보안 코드를, 우리는 아직 제대로 검증하고 있지 않다.
AI가 짠 '수정 코드'가 왜 다시 뚫렸나
dev.to 사례의 핵심은 단순하다. Cursor가 exec()로 커맨드 인젝션 취약점을 만들었고, 고쳐달라고 하자 정규식 블록리스트를 추가했다. ;, |, `, $, () 같은 셸 메타문자를 걸러내는 코드다. 언뜻 보면 보안 코드처럼 생겼다. 실제로 읽어도 보안 코드처럼 읽힌다.
문제는 ext::sh -c "touch /tmp/pwned" 같은 페이로드에는 저 문자가 하나도 없다는 것이다. ext::는 git의 공식 전송 프로토콜이다. git이 직접 셸을 호출해 명령을 실행하는 documented 동작이고, 블록리스트는 그 경로를 전혀 막지 못한다. AI는 '보안 코드처럼 생긴 패턴'을 학습 데이터에서 가져왔을 뿐, 실제 공격 경계가 어디에 있는지는 이해하지 못했다.
이 문제가 반복되는 구조적 이유가 있다. AI 코딩 어시스턴트는 '수정처럼 보이는 코드'를 최적화한다. 블록리스트는 훈련 데이터 안에서 커맨드 인젝션 방어 코드의 전형적인 모양이다. 상수 선언, 유효성 검사 분기, 조기 리턴—이 패턴은 Stack Overflow 수천 개의 답변에서 "올바른 답"으로 받아들여졌다. 모델은 그 패턴을 재현할 뿐이다.
실제 수정은 셸 자체를 제거하는 것이다. exec() 대신 execFile()과 argv 배열을 쓰면 셸이 개입하지 않으므로 메타문자는 그냥 문자열이 된다. 거기에 new URL()로 프로토콜과 호스트를 화이트리스트 검증하면 ext::, file://, ssh:// 전송 프로토콜을 한 번에 막는다. --를 인수 앞에 두면 하이픈으로 시작하는 값이 플래그로 해석되는 것도 방지한다. 세 레이어가 각각 다른 공격 경로를 막는다. AI는 그 중 하나만 구현했다.
AI가 AI 도구의 취약점을 찾는 시대
같은 날 나온 또 다른 소식은 다른 의미에서 중요하다. AI타임스에 따르면 지푸 AI의 GLM-5.3이 Cursor에 복잡한 리버스 엔지니어링 태스크를 수행하는 과정에서 Cursor 자체의 심각한 잠재적 보안 취약점을 발견했다. 지푸는 이를 Cursor에 제보했고, Cursor는 수정 작업을 진행 중이다. 구체적인 내용은 수정 완료 후 공개 예정이다.
이 사건이 흥미로운 건 방향성 때문이다. 지금까지 보안 취약점 탐지는 주로 '사람 연구자 → 소프트웨어'의 구도였다. GLM-5.3의 사례는 'AI → AI 코딩 도구'라는 새로운 구도를 보여준다. AI가 생성한 코드를 AI가 분석하고, AI 도구 자체를 AI가 감사하는 루프가 실제로 작동하기 시작했다는 뜻이다.
이건 동전의 양면이다. 방어 측에서는 AI 기반 보안 감사 도구가 실용 수준에 접근했다는 긍정적 신호다. 하지만 공격 측에서도 같은 도구를 쓸 수 있다. GLM-5.3은 '취약점 식별'을 넘어 '다단계 공격 체인을 연결하는 능력'이 강화됐다고 지푸는 설명했다. 오픈웨이트 공개를 미룬 이유도 이 '이중 용도' 위험을 반영한 것으로 보인다.
팀 리드 관점에서 이 대목이 중요한 이유는 하나다. AI 코딩 도구가 공격 표면이 됐다. Cursor, GitHub Copilot, Claude Code—개발자 머신에서 코드베이스 전체에 접근 권한을 가진 도구들이 이제 고도화된 AI 기반 취약점 스캐너의 타깃이 된다는 것을 설계에 반영해야 한다.
Claude Code Auto Mode가 더하는 변수
Claude Code가 8월 14일부로 Auto Mode를 기본값으로 전환했다. Anthropic의 내부 실험에서 Auto Mode는 유해 액션의 89%를 차단했고, 사람이 승인 프롬프트를 클릭하는 방식은 13.6%만 잡았다. 그 이유는 사용자가 프롬프트를 97% 승인했기 때문이다. 즉, 사람이 보초로 서고 있었지만 실제로는 모두 통과시키고 있었다.
이 숫자는 불편하다. 하지만 정직하다. 우리 팀이 운용하는 AI 코딩 에이전트 워크플로우에서도 같은 일이 일어나고 있을 가능성이 높다. 에이전트가 액션을 요청하면 개발자는 습관적으로 승인한다. 그 순간 통제권은 이미 사라진 것이다.
Auto Mode의 핵심 변수는 89%가 아니라 나머지 11%다. 단일 액션 기준으로는 괜찮은 비율이지만, 수백 개의 액션을 실행하는 긴 에이전트 세션에서 11% 미스율은 통계적으로 문제가 된다. dev.to 아티클이 지적했듯, 이 때문에 Hard Deny Rules 설계가 Auto Mode에서 가장 중요한 통제 수단이 된다. 모델의 판단에 의존하지 않는 유일한 통제이기 때문이다.
보안 관점에서 Hard Deny Rules에 반드시 포함해야 할 항목들이 있다. 자격증명 파일과 시크릿 스토어 접근. 리모트 저장소나 패키지 레지스트리 푸시. 허용 목록 외부 호스트로의 네트워크 호출. 작업 디렉토리 외부 파일 삭제. 이건 한 번 설계해두면 반영구적으로 작동하는 정적 규칙이다. AI가 아무리 정교한 이유를 들어도 이 규칙은 통과되지 않는다.
팀 리드가 설계해야 할 세 겹의 검증 구조
세 사건을 종합하면 AI-First 개발 워크플로우에서 보안 검증은 단일 레이어로는 부족하다는 결론이 나온다. 구체적으로 어떻게 설계해야 하는가.
첫 번째 레이어: AI 생성 코드에 대한 SAST 자동화. Cursor든 Claude Code든, AI가 생성한 코드는 커밋 전에 정적 분석 도구를 통과해야 한다. dev.to 저자가 언급한 것처럼 semgrep은 exec(와 interpolated input 패턴을 기본 룰셋으로 잡아낸다. pre-commit hook에 semgrep과 gitleaks를 넣는 것은 오늘 당장 할 수 있는 일이다. AI가 '보안 코드처럼 생긴 취약점'을 생성하는 한, 사람의 눈보다 패턴 매처가 먼저 봐야 한다.
두 번째 레이어: 에이전트 환경 스코핑. Claude Code Auto Mode를 켜는 환경과 프로덕션 자격증명이 있는 환경을 분리하는 것이 핵심이다. 에이전트가 접근할 수 있는 것을 제한하면, AI가 생성하거나 실행하는 코드의 피해 반경 자체가 줄어든다. 환경이 cheap-to-destroy라면 Auto Mode는 훨씬 안전하게 쓸 수 있다. 환경 스코핑은 AI의 판단력에 의존하지 않는다.
세 번째 레이어: 보안 수정 코드에 대한 별도 리뷰 프로세스. 이게 가장 간과되는 부분이다. 일반 기능 코드에 대한 AI 코드 리뷰는 이미 많은 팀이 도입하고 있다. 하지만 보안 관련 수정 코드는 다르다. 'AI가 제안한 보안 패치를 AI가 리뷰하는' 루프만으로는 오늘 사례처럼 같은 착각을 반복할 수 있다. 보안 패치는 SAST + 사람의 위협 모델 검토를 거쳐야 한다. 블록리스트가 아닌 화이트리스트 방식인지, 공격 경계가 실제로 어디에 있는지를 확인하는 검토다.
지금 당장 할 수 있는 것
이론은 여기까지다. 팀으로 돌아가면 이 세 가지부터 시작하면 된다.
코드베이스에서 exec(, execSync(, shell=True, os.system( 을 그렙해서 요청 바디, 쿼리 스트링, 파일명, 환경 변수에서 온 값이 인수에 포함되는지 확인한다. AI가 생성한 코드가 많을수록 이 패턴이 숨어있을 가능성이 높다.
Claude Code나 Cursor를 팀 전체에 운용하고 있다면 Hard Deny Rules를 이번 주 안에 초안을 작성한다. 완벽할 필요는 없다. 자격증명 파일, 리모트 푸시, 외부 네트워크 호출, 이 세 가지만 먼저 잠가도 대부분의 고위험 액션이 차단된다.
마지막으로, AI가 제안한 보안 수정은 '그럴듯해 보이는가'가 아니라 '공격 경계를 실제로 이동시켰는가'를 기준으로 검토하는 습관을 팀에 심어야 한다. 블록리스트가 아닌 화이트리스트인지, 셸을 우회하는 방식인지, 인수 인젝션 경로가 막혔는지를 확인하는 질문 세트를 리뷰 체크리스트에 추가하는 것으로 충분히 시작할 수 있다.
AI가 짠 보안 코드를 AI가 뚫는 시대가 됐다. 그 루프 바깥에 팀 리드가 설계한 구조가 없다면, 속도가 빨라질수록 리스크도 같이 커진다.