바이브코딩 보안 취약점, 기능 통과 코드의 80%가 위험합니다

바이브코딩으로 생성한 코드가 기능 테스트를 모두 통과해도, 그중 80% 이상이 실제 공격에 노출될 수 있는 보안 구멍을 안고 있습니다. CMU·Georgia Tech 연구팀이 실제 GitHub 저장소와 CVE 데이터베이스를 추적해 나온 숫자입니다. 그리고 “보안 지침을 프롬프트에 넣으면 되지 않을까”라는 생각도, 실험 결과에서 한 번 더 뒤집혔습니다.

기능 테스트를 통과해도 안심할 수 없는 이유

카네기멜론대학교(CMU) 연구팀이 2025년 12월에 발표한 SusVibes 벤치마크(arXiv:2512.03262v2, 2026.02.16 업데이트)는 실제 GitHub 오픈소스 프로젝트 108개에서 추출한 200개 과업을 AI 코딩 에이전트에게 맡겼습니다. 결과는 불편합니다.

가장 성적이 좋은 조합인 SWE-Agent + Claude Sonnet 4.6은 200개 과업 중 61%를 기능적으로 정확하게 처리했습니다. 그런데 그 기능 정상 코드들 가운데 보안 테스트까지 통과한 건 10.5%뿐이었습니다. 나머지 82.8%는 실제 공격이 가능한 보안 구멍을 안고 있었습니다. (출처: arXiv:2512.03262v2, CMU·Columbia·Johns Hopkins·HydroX AI 공동 연구)

이 현상의 구조적 원인은 AI가 “과도 구현(Excessive Implementation)”을 하는 방식에 있습니다. 주어진 기능 요청 범위를 넘어서 불필요한 로직을 덧붙이는데, 그 덧붙인 코드 안에 보안 검증 누락이 숨어있습니다. 코드는 돌아가지만, 외부에서 악성 입력을 보내면 그 틈으로 침투할 수 있는 구조가 만들어집니다.

Anthropic이 2024년 내부적으로 “바이브코딩을 프로덕션에 사용한다”고 밝힌 바 있습니다. (출처: arXiv:2512.03262v2 Introduction 인용) 도구를 만든 회사도 쓰는 방식이지만, 그 위험성은 이제 수치로 증명되고 있습니다.

▲ 목차로 돌아가기

실제 CVE 데이터로 보는 AI 코드 피해 규모

Georgia Tech 사이버보안 스쿨 SSLab이 운영하는 Vibe Security Radar는 AI 코딩 도구가 직접 만든 취약점을 공개 CVE 데이터베이스에서 추적합니다. 2026년 3월 현재 기준으로, AI 코드 기인 CVE가 월 35건으로 집계됐습니다. 1월 6건, 2월 15건에서 한 달 만에 두 배 이상 증가한 수치입니다. (출처: Infosecurity Magazine, 2026.03.26 / Vibe Security Radar, Georgia Tech SSLab)

3개월 연속 가파른 상승이고, 이 추세는 멈출 이유가 없습니다. SSLab 연구자 Hanqing Zhao는 “실제 피해 건수는 현재 추적되는 수치의 5~10배, 약 400~700건에 달할 것으로 추정한다”고 밝혔습니다. 메타데이터 흔적이 지워진 프로젝트까지 포함하면 확인된 74건보다 훨씬 많다는 뜻입니다.

Claude Code만 해도 2026년 3월 기준 GitHub 공개 커밋의 4% 이상을 차지하고 있습니다. 코드가 많아질수록 취약점도 함께 늘어나는 구조입니다.

▲ 목차로 돌아가기

보안 프롬프트를 넣어도 더 나빠지는 상황

“보안에 주의하라”고 프롬프트에 적어두면 낫지 않을까 생각하기 쉽습니다. CMU 연구팀도 이걸 직접 실험했고, 결과는 예상과 정반대였습니다.

SusVibes 벤치마크에서 시험한 전략은 ① 일반적인 보안 안내 추가(generic), ② 취약점 유형을 스스로 파악하도록 유도(self-selection), ③ 정확한 CWE 유형을 직접 알려주는 방식(oracle) 세 가지입니다. 세 방법 모두 보안 성공률을 어느 정도 높였지만, 동시에 기능 정확도를 약 7%p 감소시켰습니다. (출처: arXiv:2512.03262v2, 2026.02.16)

에이전트가 보안 체크 로직에 집중하느라 정작 요청한 기능 구현에 신경을 덜 쓰게 되는 구조적 딜레마입니다. 보안과 기능 둘 다를 동시에 높이는 방법은 아직 연구팀도 해법을 내놓지 못했습니다.

Veracode가 2025년 발표한 GenAI 코드 보안 리포트에 따르면, AI 코드 생성 과업의 약 45%가 알려진 보안 결함을 포함합니다. 동전 던지기 수준의 확률로 취약점이 들어온다는 뜻입니다. (출처: Veracode 공식 블로그, 2026.01.13)

▲ 목차로 돌아가기

공개된 앱 5,600개를 스캔하니 나온 숫자

Escape.tech 연구팀은 벤치마크 환경이 아니라 실제로 배포된 바이브코딩 앱을 스캔했습니다. 공개 접근 가능한 5,600개 앱을 분석한 결과, 2,000건 이상의 고위험 취약점과 400건의 노출된 시크릿(API 키, 인증 정보 포함)이 나왔습니다. 세 앱 중 하나 이상이 즉시 악용 가능한 구멍을 가진 채 운영되고 있었던 셈입니다. (출처: Forbes, 2026.03.20, Escape.tech 연구 인용)

2026년 3월에는 바이브코딩 플랫폼 Lovable에서 AI가 기본 인증 제어를 생략해 미성년자를 포함한 18,000명의 사용자 데이터가 노출되는 사고가 있었습니다. 기능은 작동했습니다. 로그인도 됐고, 데이터도 저장됐습니다. 하지만 보안 검증 로직이 빠져 있었습니다.

OWASP AI Security Project가 집계한 바에 따르면, AI 생성 앱의 약 80%가 패치 전 상태에서 악용 가능한 취약점을 하나 이상 포함하고 있습니다. (출처: vibeappscanner.com/vibe-coding-security-statistics, OWASP AI Security Project 인용) 이 수치는 SusVibes 벤치마크의 이론값이 현실과 거의 정확히 일치한다는 걸 보여줍니다.

▲ 목차로 돌아가기

어떤 도구가 취약점을 가장 많이 만드나

Georgia Tech의 Vibe Security Radar는 Claude Code, GitHub Copilot, Cursor, Devin, Windsurf, Aider, Amazon Q, Google Jules 등 약 50개 AI 코딩 도구를 추적합니다. 74건의 확인된 CVE 중 Claude Code가 가장 많이 연결돼 있습니다. 하지만 이건 Claude Code가 가장 위험하다는 뜻이 아닙니다.

SSLab의 Hanqing Zhao는 “흔적이 없는 도구가 안전한 게 아니라, 우리가 아직 못 잡는 것”이라고 말했습니다. (출처: Infosecurity Magazine, 2026.03.26) 추적 시스템이 고도화되면 Copilot 계열 도구의 실제 기여분도 수면 위로 올라올 가능성이 높습니다.

SusVibes 벤치마크에서 LLM 백본별로 보면, Gemini 2.5 Pro가 보안 측면에서 Claude 4 Sonnet·Kimi K2보다 상대적으로 나은 성적을 냈습니다. 하지만 절대값 자체는 여전히 낮습니다. 어떤 에이전트-모델 조합을 써도 SecPass 최고가 12.5%를 넘지 못했습니다.

▲ 목차로 돌아가기

지금 당장 적용할 수 있는 대응 흐름

바이브코딩을 버리라는 게 아닙니다. 생산성 향상 효과는 실재하고, GitHub Copilot은 이미 개발자 코드의 약 46%를 작성하고 있습니다. (출처: Forbes, 2026.03.20) 속도를 포기하지 않으면서 위험을 줄이는 건 가능하지만, 순서가 중요합니다.

솔직히 말하면, 현재 상황에서 바이브코딩으로 만든 코드베이스를 100% 신뢰하기는 어렵습니다. “증명되기 전까지는 취약하다고 가정한다”는 원칙을 기본값으로 두는 게 맞습니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며 — 속도가 배신하는 순간은 예고 없이 옵니다

바이브코딩의 생산성은 실재합니다. 하루 만에 작동하는 MVP를 뽑아내는 경험은 개발 방식을 바꿀 만큼 강렬합니다. 그런데 기능이 작동한다는 것과 안전하게 배포할 수 있다는 것은 전혀 다른 이야기입니다.

CMU 연구팀이 200개 과업을 실험한 결과, 기능을 통과시킨 코드의 80% 이상이 보안 테스트에서 떨어졌습니다. Georgia Tech은 이 현상을 실제 CVE 데이터베이스를 추적해서 확인했습니다. 3월 한 달에만 35건. 이 숫자는 매달 빠르게 증가하고 있습니다.

막상 해보면 자동 보안 스캔을 CI/CD에 넣는 것도, 프롬프트를 더 구체적으로 쓰는 것도 그렇게 번거로운 일이 아닙니다. 속도를 포기하지 않아도 됩니다. 배포 전 게이트 하나를 추가하는 것만으로 리스크의 상당 부분을 줄일 수 있습니다.

이 부분이 좀 아쉬웠습니다. 바이브코딩 붐과 함께 도구 소개 콘텐츠는 넘쳐났는데, 실제 수치로 위험을 짚은 한국어 콘텐츠는 거의 없었습니다. 공식 논문과 CVE 추적 데이터를 직접 확인하고 나서야 이 격차가 얼마나 큰지 체감했습니다.

▲ 목차로 돌아가기

📎 본 포스팅 참고 자료

1. CMU·Columbia·Johns Hopkins 공동 연구팀, “Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks” — https://arxiv.org/abs/2512.03262 (v2: 2026.02.16)
2. Infosecurity Magazine, “Researchers Sound the Alarm on Vulnerabilities in AI-Generated Code” — https://www.infosecurity-magazine.com/news/ai-generated-code-vulnerabilities/ (2026.03.26)
3. Veracode, “Vibe Coding and GenAI Security: Balancing Speed with Risk” — https://www.veracode.com/blog/genai-security-and-vibe-coding/ (2026.01.13)
4. Forbes, “Vibe Coding Has A Massive Security Problem” — https://www.forbes.com/sites/jodiecook/2026/03/20/vibe-coding-has-a-massive-security-problem/ (2026.03.20)
5. 한국저작권위원회, “AI 바이브 코딩의 편리함과 보안 위험성 딜레마” — https://blog.naver.com/kcc_press/224181410245 (2026.02.12)
6. Georgia Tech SSLab, Vibe Security Radar — https://github.com/HQ1995/vibe-security-radar