- Authors

- Name
- 오늘의 바이브
100개의 AI 모델에게 똑같은 코딩 과제를 줬다. 절반 가까이가 보안 구멍을 뚫린 채 제출했다. 개발자가 "로그인 기능 만들어줘"라고 요청하면, AI는 SQL 인젝션에 취약한 코드를 자신 있게 내놓는다. 프롬프트에 "보안"이라는 단어가 없었기 때문이다.

Veracode의 충격적인 실험 결과
Veracode는 2025년 GenAI 코드 보안 보고서에서 100개 이상의 대규모 언어 모델(LLM)을 대상으로 80개의 실제 코딩 작업을 테스트했다. 결과는 참담했다. 45%의 경우 OWASP Top 10에 해당하는 취약점이 포함된 코드가 생성됐다.
OWASP Top 10은 웹 애플리케이션에서 가장 흔하고 치명적인 보안 취약점 목록이다. 인젝션, 인증 실패, 민감 데이터 노출 같은 항목이 포함된다. 보안 전문가라면 누구나 알고 있는 기본 중의 기본이다.
문제는 AI가 이 기본을 모른다는 점이다. 더 정확히 말하면, AI는 보안을 요청받지 않으면 보안을 고려하지 않는다. 개발자가 "빠르게"나 "간단하게"를 요청하면 AI는 보안 검증 코드를 생략한다. 속도와 보안은 AI에게 별개의 요구사항이다.
프로그래밍 언어별 실패율의 충격
모든 언어가 똑같이 위험한 건 아니다. Veracode 보고서는 언어별 취약점 생성 비율을 공개했다. 결과는 예상을 뒤엎었다.
| 언어 | 취약점 포함 비율 |
|---|---|
| Java | 70% 이상 |
| Python | 38-45% |
| C# | 38-45% |
| JavaScript | 38-45% |
Java가 70% 이상으로 압도적 1위를 차지했다. 엔터프라이즈 환경에서 가장 많이 쓰이는 언어가 AI에게 가장 취약하다는 아이러니다. Java의 복잡한 보안 모델과 프레임워크 의존성이 AI를 혼란스럽게 만든 것으로 보인다.
Python, C#, JavaScript는 38-45% 범위로 비슷했다. 상대적으로 낮아 보이지만, 그래도 세 번에 한 번은 보안 구멍이 생긴다는 뜻이다. 프로덕션 코드에서 이 확률은 재앙이다.

XSS와 로그 인젝션, 86%와 88%의 공포
Veracode는 특정 취약점 유형에 대한 방어 성공률도 측정했다. 결과는 더욱 암울했다.
교차 사이트 스크립팅(XSS, CWE-80) 테스트에서 AI가 생성한 코드 샘플의 86%가 방어에 실패했다. XSS는 공격자가 악성 스크립트를 웹 페이지에 주입하는 공격이다. 사용자 세션 탈취, 피싱, 악성코드 배포에 악용된다.
**로그 인젝션 공격(CWE-117)**에서는 88%가 취약성을 노출했다. 로그 인젝션은 공격자가 로그 파일을 조작해 흔적을 지우거나 가짜 정보를 삽입하는 공격이다. 포렌식 분석을 무력화하고 감사 추적을 오염시킨다.
이 두 취약점은 OWASP Top 10의 단골 손님이다. 보안 교육에서 가장 먼저 배우는 항목들이다. 그런데 AI는 열 번 중 아홉 번 가까이 이걸 막지 못한다. AI에게 보안은 "요청하지 않으면 없는 것"이다.
바이브 코딩의 어두운 그림자
Veracode CTO Jens Wessling은 문제의 핵심을 짚었다. "개발자들이 명시적으로 보안 요구사항을 정의하지 않고 AI에 의존하는 '바이브 코딩' 추세가 위험하다."
바이브 코딩(Vibe Coding)은 Andrej Karpathy가 명명한 새로운 개발 방식이다. 개발자가 대략적인 의도만 전달하고 AI가 구체적인 구현을 담당한다. "대충 이런 느낌으로"라는 지시만으로 코드가 완성된다. 생산성은 폭발적으로 올라간다.
하지만 보안은 "느낌"으로 되지 않는다. 입력값 검증, 출력 인코딩, 권한 확인 같은 작업은 명시적인 요구사항이 필요하다. "로그인 기능 만들어줘"라는 요청에는 SQL 인젝션 방어가 포함되지 않는다. "사용자 입력을 받아서 DB에 저장해줘"라는 요청에는 XSS 필터링이 빠진다.
바이브 코딩의 핵심 가치인 "빠른 프로토타이핑"과 보안의 핵심 원칙인 "모든 입력을 의심하라"는 본질적으로 충돌한다. 개발자가 이 충돌을 인식하지 못하면, 취약점은 기술 부채가 아니라 보안 시한폭탄이 된다.
AI 코드 리뷰어도 보안을 놓친다
어떤 개발자는 이렇게 반론할 수 있다. "AI가 생성한 코드를 다른 AI로 리뷰하면 되지 않나?" Veracode의 연구 결과는 이 희망마저 꺾는다.
AI 코드 리뷰 도구들도 같은 한계를 공유한다. 보안 관점의 리뷰를 명시적으로 요청하지 않으면, AI 리뷰어는 가독성, 성능, 스타일에 집중한다. "이 코드에 보안 취약점이 있어?"라고 물어야 비로소 보안을 검토한다.
문제는 개발자가 뭘 물어야 하는지 모른다는 점이다. XSS, CSRF, SSRF, IDOR 같은 용어를 모르는 개발자에게 "보안 리뷰 요청"은 추상적인 개념이다. 구체적으로 뭘 점검해야 하는지 모르면, AI에게 제대로 된 질문을 할 수 없다.
결국 AI는 도구이지 보안 전문가가 아니다. 도구는 사용자의 지식 수준에 맞춰 작동한다. 보안 지식이 없는 개발자가 AI를 쓰면, 결과물도 보안 지식이 없다.

Veracode가 제시한 5가지 해결책
Veracode는 보고서에서 조직이 취해야 할 구체적인 대응책을 제시했다.
첫째, 실시간 보안 위험 개선을 위한 AI 도구를 통합해야 한다. 코드가 생성되는 순간 보안 검증이 함께 이뤄져야 한다. IDE 플러그인 형태로 AI 생성 코드를 실시간 스캔하는 도구들이 이미 존재한다. GitHub Copilot과 함께 작동하는 Snyk, Semgrep 같은 도구가 대표적이다.
둘째, 정적 분석을 통한 조기 결함 감지가 필요하다. SAST(Static Application Security Testing) 도구를 CI/CD 파이프라인에 통합해야 한다. 코드가 리포지토리에 푸시되기 전에 취약점을 잡아야 한다. 프로덕션에 배포된 후 발견되면 수정 비용이 10배 이상 증가한다.
셋째, 에이전트 워크플로우에 보안을 임베딩해야 한다. AI 에이전트가 코드를 생성할 때 보안 가드레일이 자동으로 적용되어야 한다. "모든 사용자 입력은 검증되어야 한다", "SQL 쿼리는 파라미터화되어야 한다" 같은 규칙을 시스템 프롬프트에 포함시켜야 한다.
넷째, 소프트웨어 구성 분석(SCA)을 활용해야 한다. AI가 추천하는 라이브러리와 패키지의 취약점을 검사해야 한다. 이미 알려진 CVE가 있는 패키지를 AI가 무분별하게 추천하는 경우가 많다. SCA 도구는 이런 의존성 취약점을 자동으로 탐지한다.
다섯째, 악성 패키지 자동 감지 및 차단이 필요하다. AI가 존재하지 않는 패키지 이름을 생성하는 "환각" 현상을 악용한 공격이 증가하고 있다. 공격자는 AI가 자주 환각하는 패키지 이름으로 악성 코드를 배포한다. 패키지 설치 전 자동 검증 시스템이 필수다.
개발자가 지금 당장 해야 할 3가지
조직 차원의 대응도 중요하지만, 개발자 개인이 지금 당장 실천할 수 있는 것들이 있다.
첫째, 프롬프트에 보안 요구사항을 명시하라. "로그인 기능 만들어줘" 대신 "SQL 인젝션과 XSS를 방어하는 로그인 기능 만들어줘"라고 요청하라. "파일 업로드 기능 만들어줘" 대신 "파일 타입 검증과 크기 제한이 있는 파일 업로드 기능 만들어줘"라고 요청하라.
둘째, OWASP Top 10을 공부하라. 적어도 이 열 가지 취약점이 뭔지는 알아야 한다. 인젝션, 인증 실패, 민감 데이터 노출, XML 외부 엔티티, 접근 제어 실패, 보안 설정 오류, XSS, 안전하지 않은 역직렬화, 알려진 취약점이 있는 컴포넌트 사용, 불충분한 로깅 및 모니터링. 이걸 모르면 AI에게 제대로 된 질문을 할 수 없다.
셋째, AI 생성 코드를 맹신하지 마라. AI는 자신 있게 틀린다. 문법적으로 완벽하고, 주석까지 친절한 코드가 보안 구멍투성이일 수 있다. 특히 인증, 권한, 암호화 관련 코드는 반드시 수동 검토하라.

45%는 평균이다, 최악은 더 나쁘다
Veracode 보고서의 45%라는 수치는 100개 이상 모델의 평균이다. 최악의 모델은 훨씬 더 높은 취약점 생성률을 보였을 것이다. 보고서는 개별 모델별 순위를 공개하지 않았지만, 일부 오픈소스 모델들이 특히 위험했을 가능성이 높다.
또한 이 테스트는 "보안을 명시적으로 요청하지 않은" 조건에서 진행됐다. 현실의 바이브 코딩 환경과 동일한 조건이다. 보안을 요청하면 성공률이 올라가겠지만, 바이브 코딩의 본질은 "요청하지 않아도 알아서 해주는 것"이다. 그 본질 자체가 보안과 충돌한다.
개발자 커뮤니티에서는 이미 "AI 생성 코드는 프로토타입 전용"이라는 합의가 형성되고 있다. 하지만 현실에서는 프로토타입이 그대로 프로덕션에 배포되는 경우가 너무 많다. 특히 스타트업이나 빠른 릴리즈 주기를 가진 팀에서 이런 일이 빈번하다.
AI 시대의 보안은 인간의 몫이다
결론은 명확하다. AI는 보안 책임을 지지 않는다. AI가 생성한 코드의 보안 책임은 여전히 개발자와 조직에게 있다. AI가 아무리 발전해도 이 원칙은 바뀌지 않을 것이다.
45%라는 숫자가 주는 교훈은 단순하다. AI를 쓰되, 보안은 직접 챙겨라. 프롬프트에 보안 요구사항을 넣어라. 생성된 코드를 SAST 도구로 검증하라. 인증/권한 관련 코드는 수동으로 리뷰하라.
AI가 생산성을 10배 높여준다 해도, 보안 사고 한 번이면 모든 이득이 날아간다. 데이터 유출 사고의 평균 비용은 500만 달러를 넘는다. 바이브 코딩으로 아낀 시간이 보안 사고 대응 시간보다 길지 않다.
AI 코딩 도구는 분명 혁명이다. 하지만 모든 혁명에는 대가가 따른다. 그 대가가 보안이 되어서는 안 된다.