AI가 만든 코드의 보안 구멍은 어디서 생기나

AI가 코드를 빨리 만들어주면 보안 검사도 빨라져야 할까? ZenVeil의 답은 단순히 기존 도구를 더 자주 돌리자는 쪽이 아니야. AI 코딩 도구가 자주 만드는 실수의 모양을 따로 찾아야 한다는 주장이야.¹

어떤 문제를 찾는다고 하나

ZenVeil은 GitHub Copilot이 코드에 하드코딩된 비밀값을 자동완성할 수 있고, Cursor의 여러 파일 수정이 인증 검사를 서로 다르게 남길 수 있다고 설명해. Claude Code의 긴 작업 세션이 오래되고 취약한 의존성을 가져올 수 있다는 설명도 붙였어. 이 세 가지는 ZenVeil이 각 도구에 특화된 문제라고 부르는 사례야.¹

페이지가 제시한 검사는 저장소를 읽기 전용으로 복제해 임시 샌드박스에서 실행하는 방식이야. 공개 저장소는 회원가입 없이 검사할 수 있고, 검사가 끝나면 소스 코드를 보관하지 않으며 학습에도 사용하지 않는다고 설명해.¹

샘플 화면에서 확인되는 것

예시 명령은 zenveil scan github myorg/payments-api야. 화면에는 세 개의 검사기로 네 건을 찾았다고 나와. AWS 접근 키 노출, lodash의 CVE-2021-23337 취약점(CVSS 9.1), f-string을 통한 SQL 인젝션, 버전이 고정되지 않은 의존성이야.¹

첫 번째 발견 사항에는 자동 수정 흐름도 붙어 있어. zenveil fix ZV-A1B2C3 --auto-pr --repo myorg/payments-api를 실행하면 키를 교체하고 Git 이력에서 지운 뒤 .gitignore에 추가하는 GitHub PR을 연다는 예시야. 페이지의 샘플은 47개 파일을 22초에 검사하고 12초 만에 PR을 열었다고 보여줘.¹

이 샘플에서 눈여겨볼 점은 취약점 이름만 나열하지 않는다는 거야. 파일 경로와 줄 번호를 함께 제시해서 개발자가 결과를 직접 확인하게 한다고 설명해. AI가 만든 코드의 보안 검사를 말하면서도, 최종 확인 지점을 코드 안에 남겨둔 셈이지.

기존 도구를 대체한다는 뜻은 아니야

ZenVeil이 내세우는 범위는 하드코딩된 API 키와 JWT·AWS 자격증명, 인증 미들웨어가 빠진 민감한 경로, 의존성 혼동 위험, 브라우저 localStorage에 저장된 인증 토큰, 속도 제한이 없거나 오류 내용을 너무 많이 보여주는 API야.¹

반대로 알려진 CVE와 일반적인 의존성 취약점은 GitHub Actions, Snyk, Semgrep 같은 기존 도구의 몫으로 남겨둔다고 밝혔어. ZenVeil 스스로도 이 도구들과 일반적인 AI 코드 리뷰어를 대체하지 않는다고 선을 그어. 기존 보안 도구가 못 보는 영역을 보태겠다는 위치야.¹

숫자를 읽을 때 남는 선

페이지는 개발자의 83%가 AI 코딩 도구를 사용하고, 저장소 하나를 검사하면 평균 14건을 찾으며, 전체 검사가 30초 안에 끝난다고 제시해. 가장 큰 테스트 저장소는 약 4만 8천 파일이었고 전체 검사에 8분이 안 걸렸다고도 적었어. 다만 이 수치는 내부 벤치마크이고 독립적으로 검증되지 않았다고 명시돼 있어.¹

그래서 이 페이지에서 지금 확인되는 건 보안 문제가 생기는 구체적인 예와, 이를 찾고 PR까지 여는 제품의 설계야. 실제로 AI가 만든 코드에서 기존 도구보다 더 많은 문제를 잡는지, 자동 수정이 안전한지는 별도 검증이 필요해. 다음에는 독립적인 오탐·누락률과 자동으로 열린 PR이 사람의 검토를 얼마나 줄였는지를 봐야 해.

각주

1. ZenVeil, 「Security for AI-Generated Code」(2026-07-14) ZenVeil. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸