arXiv·Tenzai 공식 데이터 기반
바이브코딩 보안,
기능 통과율 61%인데 보안은 10%입니다
Claude Code, Cursor, Codex, Replit, Devin — 가장 많이 쓰는 AI 코딩 도구 5개를 실제로 테스트해봤더니, 전부에서 취약점이 나왔습니다. 생산성은 올라갔지만 보안 구멍이 그만큼 같이 생겼다는 공식 수치가 있습니다.
(기능 통과 61% 대비)
(15개 앱 테스트)
고위험 보안 결함 비율
기능 테스트는 통과해도 보안 테스트는 다릅니다
바이브코딩 보안에 대한 가장 구체적인 수치는 2025년 12월에 arXiv에 올라온 논문에서 나옵니다. Songwen Zhao 외 5인이 발표한 Is Vibe Coding Safe?에서는 실제 오픈소스 프로젝트에서 뽑은 200개의 기능 요청 작업을 벤치마크로 만들고, 코딩 에이전트들의 결과를 기능과 보안 두 기준으로 동시에 평가했습니다.
결과가 이렇습니다. SWE-Agent와 Claude 4 Sonnet 조합 기준으로 기능적 정확성 통과율은 61%였습니다. 그런데 같은 코드를 보안 기준으로 다시 봤더니 보안 통과율은 10.5%에 그쳤습니다. (출처: arXiv:2512.03262, 2026.02.16 v2)
💡 공식 논문의 기능 통과율(61%)과 보안 통과율(10.5%)을 나란히 놓고 보면, 코드가 “돌아간다”는 것과 “안전하다”는 것은 완전히 다른 기준이라는 게 드러납니다. 기능 테스트만 믿고 배포하면, 10개 중 9개는 보안 구멍이 있는 채로 서비스가 나가는 셈입니다.
이 수치가 무서운 이유는 단순히 숫자가 낮아서가 아닙니다. 기능 테스트는 “버튼이 눌리는가?”를 보고, 보안 테스트는 “버튼을 누르면 내부 데이터가 새나가지 않는가?”를 봅니다. 둘은 서로를 대체하지 않습니다.
SQL 인젝션은 막는데 왜 더 쉬운 곳에서 뚫릴까요
보안 스타트업 텐자이(Tenzai)는 2025년 12월, Claude Code·Cursor·OpenAI Codex·Replit·Devin 5개 도구에 동일한 프롬프트를 주고 쇼핑몰 앱 등 3개의 실제 애플리케이션을 만들게 했습니다. 총 15개 앱에서 취약점 69개가 발견됐고, 그중 6개는 ‘치명적(Critical)’ 등급이었습니다. (출처: Tenzai 공식 보고서 “Bad Vibes”, blog.tenzai.com, 2025.12)
여기서 흥미로운 점은 이겁니다. SQL 인젝션과 크로스사이트 스크립팅(XSS)처럼 OWASP Top 10에 오랫동안 올라있던 ‘잘 알려진’ 취약점은 5개 도구 모두가 비교적 잘 막았습니다. 프레임워크 자체에 방어 메커니즘이 내장되어 있고, AI가 훈련 데이터에서 그 패턴을 충분히 학습했기 때문입니다.
반면 진짜 문제는 비즈니스 로직 취약점에서 터졌습니다. 주문 수량이 반드시 양수여야 한다는 당연한 조건을 설정하라고 명시적으로 지시하지 않았더니, 테스트한 5개 도구 중 4개(Claude Code, Cursor, Devin, Replit)가 이 조건을 넣지 않았습니다. 공격자가 수량을 음수로 넣어 금액을 마이너스로 만드는 게 가능했습니다. (출처: Tenzai 공식 보고서)
💡 텐자이 연구진은 “에이전트는 비즈니스 로직에 관한 ‘상식’이 없다. 개발자가 직관적으로 아는 것을 에이전트는 명시적으로 지시받지 않으면 모른다”고 설명했습니다. 기술적 취약점은 AI가 점점 잘 잡지만, 정작 실제 비즈니스에서 돈이 빠져나가는 구멍은 기술적 패턴이 아니라 맥락 이해의 부재에서 생깁니다.
가격을 음수로 설정하는 것을 막는 코드가 없는 경우도 5개 중 3개(Cursor, Devin, Replit)에서 나왔습니다. 이 두 가지 모두 단순하고 명확한 규칙이었는데도 대부분의 에이전트가 명시적 지시 없이는 구현하지 않았습니다.
5개 도구 모두 이것만큼은 못 했습니다
텐자이 보고서에서 가장 충격적인 부분은 취약점의 종류가 아니라, 15개 앱 전부에서 빠진 보안 기능들입니다. 이건 어떤 도구가 더 잘하고 못하고의 문제가 아니라, 지금 시점의 구조적 한계에 가깝습니다.
이 항목들의 공통점은 “명시적으로 요청하지 않으면 AI가 알아서 넣지 않는다”는 점입니다. 텐자이 보고서에서도 명확히 밝힙니다. “에이전트는 우리가 명시적으로 요청한 것을 만들었다. 하지만 보안의 큰 그림은 전혀 보지 못했다.”
보안 문제를 프롬프트로 고칠 수 있을까요
많은 분들이 이렇게 생각합니다. “보안 요청을 프롬프트에 추가하면 되지 않나?” 합리적인 생각이지만, 논문의 실험 결과는 다릅니다.
arXiv 논문(arXiv:2512.03262)은 프롬프트에 보안 지시를 더했을 때 어떤 효과가 있는지를 별도로 실험했습니다. 일반적인 보안 주의사항 추가, 먼저 보안 위험을 찾게 하는 방식, 특정 취약점 유형을 피하라는 명시적 지시까지 세 가지 전략을 모두 써봤지만, “어느 방법도 보안 취약점을 의미 있게 줄이지 못했다”는 것이 결론입니다. (출처: arXiv:2512.03262 논문 실험 결과)
💡 공식 논문과 Tenzai 보고서를 함께 놓고 보면 같은 결론이 나옵니다. 프롬프트로 보안을 지시하는 것과, 코드 생성 이후 독립적인 보안 검증을 도입하는 것은 전혀 다른 문제입니다. 전자는 입력 조건이고, 후자는 검증 체계입니다.
텐자이 역시 같은 결론을 냈습니다. “프롬프트를 다듬는 것으로 이 문제를 포괄적으로 해결하는 솔루션은 아직 존재하지 않는다.” 다만 한 가지 희망적인 방향도 함께 제시합니다. AI가 만든 취약점을 다른 AI로 탐지하는 자동화된 검증 파이프라인이 대안으로 연구되고 있습니다. 현재로선 ‘확인 필요’ 단계에 있습니다.
실제로 어떤 앱이 어떻게 터졌나
Tenzai 보고서에서 Claude Code가 생성한 코드에서 발견된 치명적 취약점 중 하나를 구체적으로 살펴보면 이렇습니다. 상품 삭제 API에서 인증된 사용자에게는 소유권 확인을 하지만, 인증되지 않은 요청에 대해서는 소유권 확인이 그냥 건너뛰어지고 삭제가 실행됩니다. 로그인 없이도 URL만 알면 상품을 지울 수 있는 구조입니다. (출처: Tenzai 공식 보고서, blog.tenzai.com)
Codex가 만든 쇼핑몰 앱에서는 주문 API가 구매자 역할의 사용자에게는 본인 주문 여부를 확인하지만, 다른 역할(예: 판매자)에게는 이 검증이 완전히 빠집니다. 판매자로 로그인하면 시스템의 모든 주문 데이터를 열람할 수 있었습니다. (출처: Tenzai 공식 보고서)
한국저작권위원회 리포트(2026년 2월호)에서도 유사한 패턴을 설명합니다. AI가 과업의 맥락을 넘어서 불필요한 로직을 덧붙이는 ‘과도 구현(Excessive Implementation)’ 현상이 보안 허점을 만드는 주요 원인으로 분석됩니다. 수도꼭지 누수를 고쳐달라고 했더니 집 전체 배관을 바꾸는 것에 빗댄 설명입니다. (출처: 한국저작권위원회 저작권 이슈 트렌드 2026년 2-1호)
💡 세 사례 모두 코드는 작동합니다. 버튼을 누르면 결과가 납니다. 바이브코딩으로 만든 앱이 잘 돌아가는 것처럼 보이는 이유가 바로 이겁니다. 보안 결함은 정상적인 사용에서는 드러나지 않고, 누군가 의도적으로 잘못된 입력을 넣거나 인증 흐름을 우회하려 할 때야 비로소 터집니다.
Veracode의 2026년 보안 감사 결과에 따르면 AI가 생성한 코드 중 45%에 고위험 보안 결함이 포함되어 있습니다. Java 코드의 경우 보안 실패율이 72%, Python도 38%로 나타났습니다. (출처: Veracode GenAI Code Security Report, 2026)
그렇다면 지금 쓰면서 최소한 해야 할 것들
바이브코딩을 당장 그만두라는 이야기가 아닙니다. 구글, 마이크로소프트도 각각 전체 코드의 30% 이상을 AI가 생성한다고 공식 발표했고(출처: Alphabet Q1 2025 Earnings Call, Microsoft LlamaCon 2025), 현실적으로 생산성을 포기하기 어렵습니다. 다만 최소한의 안전장치는 구분해서 볼 필요가 있습니다.
코드를 읽을 수 있는 개발자라면: Semgrep(CE 무료 버전)과 Trivy를 GitHub Actions에 연결하는 데 15분이면 됩니다. 로그인, 인증, 데이터베이스 쿼리, 파일 처리, API 인가 로직에 집중해서 검토하면 AI가 만든 취약점 중 상당수를 잡을 수 있습니다.
비개발자가 바이브코딩으로 서비스를 만든다면: 사용자 데이터, 결제, 개인정보를 다루는 기능만큼은 Supabase, Auth0/Clerk, Stripe처럼 보안이 내장된 관리형 서비스로 대체하는 게 현실적입니다. AI가 직접 인증 코드를 만들게 하지 않는 것만으로도 주요 위험 경로를 줄일 수 있습니다.
팀 단위라면: 보안 검토가 필요한 코드와 그렇지 않은 코드를 기준으로 나누는 게 먼저입니다. 사용자 데이터·인증·결제를 건드리는 코드는 반드시 코드를 읽을 수 있는 사람의 검토를 거치고, 단순 UI나 내부 비민감 도구는 빠르게 바이브코딩으로 만드는 구분이 현실적입니다.
💡 Tenzai 보고서와 arXiv 논문을 교차해서 보면 공통적으로 이 방향을 가리킵니다. AI가 코드를 만드는 속도와 AI가 보안을 검증하는 속도를 맞추는 것이 지금의 과제입니다. “AI로 만들고 AI로 검증한다”는 파이프라인이 현재로선 가장 현실적인 방향으로 연구되고 있습니다.
Anthropic의 연구(출처: Anthropic, AI-assistance and coding skills, 2026)에서 재미있는 점도 나왔습니다. AI 코딩 도구를 쓴 개발자들이 코딩 퀴즈에서 수동 코더에 비해 17% 낮은 점수를 받았습니다. AI에게 코드만 짜게 하지 않고 개념 설명도 함께 요청한 경우에는 실력이 유지됐습니다. 바이브코딩을 쓰면서도 내부 구조를 이해하는 방식으로 접근하는 게 장기적으로 둘 다 유리합니다.
자주 묻는 것들
마치며
솔직히 말하면, 지금 상황에서 바이브코딩을 쓰지 않는 게 답이라는 생각은 들지 않습니다. 생산성은 실제로 올라가고, 진입장벽이 낮아진 것도 사실입니다. 다만 “돌아간다”와 “안전하다”가 다른 기준이라는 것은 공식 수치로 이미 확인됐습니다.
기능 통과율 61%에 보안 통과율이 10.5%라는 수치는, 지금 바이브코딩으로 서비스를 만들고 있다면 보안 검증 체계가 생산성만큼 중요하다는 이야기입니다. 이 부분만큼은 프롬프트로 해결되지 않고, 별도의 단계가 필요합니다.
2026년 3월 현재, 바이브코딩을 검증하는 자동화된 보안 에이전트도 함께 연구되고 있습니다. 만드는 속도와 검증하는 속도가 맞춰질 때, 지금의 구조적 한계는 상당 부분 해소될 것입니다. 그 시점이 올 때까지는 최소한의 수동 검증 단계를 빠뜨리지 않는 것이 지금 할 수 있는 가장 현실적인 대응입니다.
- Songwen Zhao 외 5인, “Is Vibe Coding Safe?” arXiv:2512.03262 — https://arxiv.org/abs/2512.03262
- Tenzai 공식 보고서 “Bad Vibes” (2025.12) — https://blog.tenzai.com/bad-vibes
- 한국저작권위원회, 저작권 이슈 트렌드 2026년 2-1호 — 네이버 블로그
- 연합뉴스, “바이브코딩 벌써 옛말…보안위험에 초고수 개발자 선호 흐름” (2026.01.17) — yna.co.kr
- Veracode, GenAI Code Security Report 2026 — veracode.com
- CIO Korea, “바이브 코딩 확산, 보안에는 주의 필요” (2026.01.15) — cio.com
본 포스팅은 2026년 03월 20일 기준으로 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 인용된 수치는 각 출처 기재 시점의 데이터이며, 이후 업데이트된 연구 결과로 달라질 수 있습니다.
댓글 남기기