다른 무엇보다 먼저 수치를 제시하겠습니다. 이 수치들은 제가 대화하는 대부분의 개발자들이 깨닫고 있는 것보다 훨씬 심각하기 때문입니다.

Veracode의 2025년 연구에 따르면, AI가 생성한 코드의 45%가 알려진 OWASP 취약점을 유발하는 것으로 나타났습니다. CodeRabbit의 분석 결과, AI가 생성한 코드는 사람이 작성한 코드보다 취약성 발생률이 2.74배 더 높았습니다.

CVSS 7.0 이상의 취약점은 사람이 작성한 코드보다 AI 생성 코드에서 2.5배 더 자주 나타납니다. 2025년 6월까지, 조사된 리포지토리(repositories) 전반에서 AI 생성 코드는 매달 10,000개 이상의 새로운 보안 결함을 추가하고 있었으며, 이는 2024년 12월 대비 10배 급증한 수치입니다.

풀 리퀘스트(pull request)당 운영 환경 사고(Production incidents)는 2025년 12월부터 2026년 초 사이에 23.5% 증가했습니다.

그럼에도 불구하고, 미국 개발자의 92%가 현재 매일 AI 코딩 도구를 사용하고 있습니다. Gartner는 2026년 말까지 새로운 코드의 60%가 AI에 의해 생성될 것이라고 예측합니다. Google과 Microsoft에서는 이미 새로운 코드의 30%가 AI에 의해 생성되고 있습니다.

우리는 거의 모든 개발자가 사람이 작성한 코드보다 훨씬 높은 비율로 취약한 코드를 생성하는 도구를 사용하고 있는 상황에 처해 있습니다. 보안 지표는 반대 방향으로 향하고 있는 반면, 도입 곡선은 수직 상승하고 있습니다.

이것은 개별 개발자가 잘못된 선택을 하고 있다는 이야기가 아닙니다. 이것은 아키텍처(architectural) 수준에서 시스템이 실패하고 있다는 이야기입니다.

사고 데이터가 이를 구체화합니다

위의 통계치만으로도 충분히 심각합니다. 하지만 실제 발생한 사고들은 이 통계들을 무시할 수 없게 만듭니다.

CVE-2025-48757 사례를 통해 Lovable이 행 레벨 보안 (Row Level Security) 없이 Supabase 스키마를 생성하여 170개 이상의 운영 애플리케이션을 노출했음이 드러났습니다. Moltbook은 API 엔드포인트가 권한 부여 (authorisation) 확인 없이 민감한 데이터를 반환함에 따라 150만 개의 인증 토큰과 35,000개의 이메일 주소를 유출했습니다. Tea App은 액세스 제어 (access controls) 누락으로 인해 72,000개의 사용자 이미지와 110만 개의 개인 메시지를 노출했습니다.

약 5,600개의 바이브 코딩 (vibe-coded) 애플리케이션을 스캔한 보안 연구원들은 2,000개 이상의 취약점과 400개 이상의 노출된 비밀 정보 (secrets)를 발견했습니다.

이러한 사건들 중 그 어떤 것도 정교한 공격자를 필요로 하지 않았습니다. 그저 접근 제어 (access controls)가 완전히 누락되었다는 사실을 알아차릴 수 있는 사람만 있으면 되었습니다. AI 도구들은 보안 기본 요소 (security primitives)를 구현하는 것처럼 보이지만, 실제로는 이를 구현하지 않은 그럴듯해 보이는 코드를 생성했습니다. 코드는 컴파일되었습니다. 테스트는 통과했습니다. PR (Pull Request)은 승인되었습니다. 그리고 취약점이 배포되었습니다.

언어별 분포는 균등하지 않습니다

Java는 AI 생성 코드에 대해 72%의 보안 실패율을 보였습니다. Python, C#, JavaScript는 38~45% 사이였습니다. 2026년 업데이트 결과는 제한적인 개선만을 보여주었습니다. 업계 전반의 보안 통과율은 55%에서 정체되어 있습니다.

만약 귀하의 팀이 Java 백엔드 서비스 — 인증 (authentication), 결제 처리 (payment processing), 데이터 액세스 (data access) — 에 AI를 집중적으로 사용하고 있다면, 귀하는 모든 보안 검토 프로세스가 우려해야 할 수준의 실패율을 안고 운영하고 있는 것입니다. 역사적으로 "엔터프라이즈급으로 안전하다"고 간주되어 온 언어가, 보안 지표 측면에서 AI 보조 성능이 가장 저조한 언어입니다.

AI가 생성한 백엔드 코드의 41%는 지나치게 광범위한 권한 설정을 포함하고 있어 공격 표면 (attack surfaces)을 증가시킵니다. AI 도구들은 역할 제한 (role restriction) 없이 기본 관리자 수준의 접근 제어를 빈번하게 생성합니다.

이것이 바로 위의 사건들을 발생시킨 구체적인 실패 패턴입니다. 미묘한 암호학적 약점이나 고도화된 인젝션 (injection) 기술이 아닙니다. 있어야 할 엔드포인트 (endpoints)에 접근 제어가 누락된 것입니다. 제한된 권한이 필요한 곳에 관리자 수준의 권한이 부여된 것입니다. 다른 부분은 완전히 합리적으로 보이는 코드에서, 기초적인 기본 요소 (foundational primitives)가 결여되어 있는 것입니다.

실제로 도움이 되는 것 — 그리고 도움이 되지 않는 것

도움이 되지 않는 것:

엔지니어링 문화 문서에 "AI가 생성한 코드를 주의 깊게 검토하십시오"라는 한 줄을 추가하는 것. 코드 리뷰 (Code review)는 논리적 오류를 잡아내도록 최적화되어 있지, 위협 모델 (threat models)을 감사하도록 최적화되어 있지 않습니다. 리뷰어들은 예상되는 케이스에서의 정확성을 확인하기 위해 읽습니다. 보안 실패는 리뷰어가 능동적으로 상상하지 못하는 예상치 못한 케이스에서 발생합니다.

연구 결과 실제로 효과가 있는 것:

1. 리뷰 단계에 도달하기 전, AI 생성 코드에 대한 자동화된 SAST (Static Application Security Testing) 적용

Pull Request (PR)에 도달하기 전, SAST 및 SCA 도구를 사용하여 모든 AI 생성 코드를 스캔하십시오. 도달한 후가 아니라, 도달하기 전이어야 합니다. 리뷰 프로세스는 코드가 기본적으로 안전하다고 가정하고 정확성을 확인합니다. 반면 SAST 스캔은 코드가 위험할 수 있다고 가정하고 알려진 취약점 패턴을 확인합니다. 두 가지 모두 필요합니다. 현재 대부분의 팀은 이 중 하나만 보유하고 있습니다.

# GitHub Actions — SAST 사전 리뷰 게이트
name: Security Scan
on: [pull_request]
...

2. 프롬프트 내 명시적인 보안 컨텍스트 (Explicit security context in prompts)

Backslash의 연구에 따르면, 보안 중심의 프롬프팅을 사용할 경우 Claude 3.7 Sonnet의 보안 출력 점수가 6/10에서 10/10으로 상승했습니다. 대부분의 개발자는 "사용자 인증 엔드포인트를 작성해줘"와 같은 프롬프트를 사용합니다. 보안을 인지한 버전은 다음과 같습니다:

사용자 인증 엔드포인트를 작성해줘.
보안 요구사항:

• 모든 입력을 서버 측에서 검증 및 정제(Sanitise)할 것
• 매개변수화된 쿼리(Parameterized queries)를 사용할 것 — 문자열 연결(String concatenation) 금지
• 인증 실패 시 세부 정보 없이 401을 반환할 것
• IP당 분당 5회로 속도 제한(Rate limit)을 설정할 것
• 자격 증명(Credentials)을 로그에 남기지 않고 실패한 시도만 기록할 것
• 비밀번호 해시나 내부 ID를 절대 반환하지 말 것

프롬프트에 위협 모델(Threat model)이 명시되면 모델은 현저히 다른 출력을 생성합니다. 대부분의 AI 도구 UX가 작업의 보안 차원을 드러내지 않기 때문에, 이는 대부분의 개발자에게 명확하지 않은 부분입니다.

3. AI 지원 제한 구역 (Restricted zones for AI assistance)

인증, 암호화, 결제 처리와 같은 고위험 영역에서는 AI 생성 코드를 금지하십시오. 단, 코드의 정확성뿐만 아니라 위협 모델 커버리지를 구체적으로 감사하는 필수적인 인간 리뷰가 동반되어야 합니다.

이는 AI 도구를 불신하는 것이 아닙니다. AI의 실패 모드(Failure modes)가 가장 치명적이지 않은 작업으로 AI를 유도하는 것에 관한 것입니다. 분류 로직, 데이터 변환, UI 컴포넌트, 테스트 생성 등은 가치는 높지만 보안 중요도는 상대적으로 낮습니다. 반면 인증 흐름, 결제 처리, 액세스 제어(Access control)는 실패 모드가 치명적이며, 현재 연구에서 가장 높은 취약점 발생률을 보이는 영역입니다.

4. 액세스 제어를 필수 체크리스트 항목으로 취급할 것

누락되었거나 지나치게 광범위한 액세스 제어 (Access Controls)가 실제 사고를 일으키는 구체적인 실패 패턴이라는 점을 고려할 때, 모든 AI 생성 엔드포인트(Endpoint)에 적용되는 간단한 체크리스트만으로도 가장 치명적인 부류의 문제를 잡아낼 수 있습니다.

AI 생성 엔드포인트가 머지(Merge)되기 전:
□ 이 엔드포인트는 호출자가 인증(Authenticated)되었는지 확인하는가?
□ 호출자가 이 특정 리소스에 대해 권한(Authorised)을 가지고 있는지 확인하는가?
□ 해당 리소스가 인증된 사용자에게 속해 있는지 검증하는가?
□ 필요한 최소한의 데이터만 반환하는가?
□ 모든 데이터베이스 작업에 매개변수화된 쿼리 (Parameterized Queries)를 사용하는가?
□ 민감한 매개변수를 제외하고 요청을 로그(Log)에 기록하는가?

여섯 가지 질문입니다. 이를 일관되게 적용한다면 Moltbook 유출, Tea App 노출, 그리고 Lovable의 RLS 문제를 방지할 수 있었을 것입니다.

불편한 전망

AI로 인해 도입되는 CVE(Common Vulnerabilities and Exposures)의 증가 추세가 계속된다면, 2026년 말까지 AI 생성 CVE는 취약점 데이터베이스에서 지배적인 카테고리가 될 것입니다.

우리는 작성되는 새로운 코드의 대다수가 구조적인 보안 격차를 포함하게 되는 시대의 초입에 서 있습니다. 이는 개발자가 부주의해서가 아니라, 그들이 사용하는 도구가 적대적 조건 (Adversarial Conditions)을 최우선 고려 사항으로 설계되지 않았기 때문입니다.

AI 코딩 도구로 인한 생산성 향상은 실재합니다. 연구에 따르면 태스크 수준의 벤치마크에서 작업 완료 시간이 최대 55%까지 빨라집니다. 하지만 팀들은 또한 41% 더 높은 코드 혼란 (Code Churn)과 7.2% 감소된 인도 안정성 (Delivery Stability)을 보고하고 있습니다.

출력 속도는 더 빨라졌습니다. 그것이 더 나은 결과물인지 여부는 전적으로 모델의 출력과 운영 환경(Production) 사이에 어떤 검토 인프라가 놓여 있느냐에 달려 있습니다.

이 시기를 잘 헤쳐 나가는 개발자들은 AI 도구를 거부하는 사람들도, AI의 출력을 비판 없이 수용하는 사람들도 아닙니다. 그들은 실패 모드 (Failure Modes)가 구체적으로 어디에 집중되어 있는지 — 설계 수준의 보안 결정, 액세스 제어, 권한 범위 설정 (Permission Scoping) — 를 이해하고, 일반적인 코드 리뷰가 이를 해결해 줄 것이라고 가정하는 대신 이러한 특정 격차를 중심으로 검토 프로세스를 구축하는 사람들입니다.

45%라는 수치는 AI 지원 개발 (AI-assisted development)에 반대하는 근거가 아닙니다. 이는 여러분의 리뷰 프로세스가 실제로 무엇을 잡아내고 있고, 무엇을 잡아내지 못하고 있는지를 이해해야 한다는 근거입니다.

만약 이 내용이 유용했다면, 위의 6가지 질문 체크리스트를 자유롭게 복사하고 수정하여 팀의 PR (Pull Request) 템플릿에 추가해 보세요. 연구 링크는 본문 곳곳의 인용구에 포함되어 있으니, 직접 원문을 읽어볼 가치가 있습니다.

여러분의 팀이 AI 코드 보안에 접근하는 방식을 댓글로 남겨주세요. 무엇이 효과적이고 무엇이 그렇지 않은지 진심으로 궁금합니다.

매일 AI 도구를 사용하여 구축하고, 무엇이 작동하는지, 무엇이 작동하지 않는지, 그리고 연구 결과가 실제로 말하는 바와 데모가 보여주는 바가 어떻게 다른지에 대해 솔직하게 작성합니다. AI 보안, 실제 운영 환경의 점검 (production reality checks), 그리고 때때로 마주하게 될 불편한 통계들을 확인하려면 팔로우해 주세요.
exactsolution.com