기능이 돌아간다고 안전한 게 아닙니다

바이브코딩 보안 문제가 본격적으로 수면 위로 올라온 건 2026년 3월입니다. 카네기멜론대(CMU)·콜롬비아대 공동 연구팀이 arXiv에 올린 논문 SusVibes는 실제 오픈소스 프로젝트 108개에서 200개 작업을 추출해 최신 AI 코딩 에이전트를 테스트했습니다.

결과가 충격적입니다. Claude 4 Sonnet 기반 SWE-Agent는 기능 테스트 61%를 통과했지만, 보안 테스트까지 모두 통과한 비율은 10.5%에 불과했습니다. (출처: arXiv:2512.03262, CMU·Columbia University, 2025.12) 즉, AI가 “동작하는 코드”를 만들어도 10개 중 9개는 어딘가에 구멍이 뚫려 있다는 뜻입니다.

바이브코딩이라는 용어는 2025년 2월 AI 연구자 안드레이 카르파티가 처음 쓴 말입니다. 자연어로 원하는 것을 묘사하면 AI가 코드를 쓰는 방식을 가리킵니다. Collins Dictionary는 이를 2025년 올해의 단어로 선정했고, MIT가 선정한 2026년 10대 혁신 기술 목록에도 들어갔습니다. 인기만큼이나 빠르게 퍼졌고, 그만큼 빠르게 구멍도 커지고 있습니다.

공개 앱 5,600개를 스캔해 보니

실험실 숫자만 있는 게 아닙니다. 보안 스타트업 Escape.tech는 실제 인터넷에 공개 배포된 바이브코딩 앱 5,600개를 직접 스캔했습니다. 나온 결과는 취약점 2,000개 이상, 그리고 API 키·인증 정보 등 노출된 시크릿 400개 이상이었습니다. (출처: Forbes, 2026.03.20, Escape.tech 연구 인용)

CodeRabbit이 2025년 12월 470개 오픈소스 GitHub 풀리퀘스트를 분석한 결과, AI가 작성한 코드의 보안 취약점은 사람이 작성한 코드보다 2.74배 더 많았고, 논리·정확성 문제는 75% 더 자주 나타났습니다. (출처: Forbes, 2026.03.20) 프로덕션 코드가 이 상태로 실제 사용자에게 배포되고 있다는 게 핵심입니다.

보안 경고를 주면 오히려 기능이 망가집니다

“보안에 주의해” 한 마디만 프롬프트에 넣으면 해결되지 않을까요? SusVibes 논문은 이 가정을 직접 실험으로 뒤집었습니다. 연구팀이 세 가지 보안 힌트 전략(일반 보안 안내, 취약점 유형 자기 선택, 정답 CWE 제공)을 테스트한 결과, 보안 점수는 소폭 올랐지만 기능 정확도가 약 77%포인트 급락했습니다. (출처: arXiv:2512.03262, 2025.12)

결론적으로 연구팀은 “보안과 기능을 동시에 잡을 수 있는 더 정교한 전략이 필요하다”고 밝혔습니다. AI 에이전트가 보안을 우선시하면 기능 구현에 덜 집중하는 경향이 있기 때문입니다. 현재 어떤 프론티어 모델도 이 문제를 완전히 해결하지 못했고, 이유는 아직 공개되지 않았습니다.

어떤 취약점이 가장 많이 나오나

SusVibes가 커버한 취약점 유형은 77개(CWE 기준)입니다. AI 코딩 에이전트가 가장 자주 놓치는 유형은 크게 네 가지로 압축됩니다. 첫 번째는 인젝션 취약점입니다. SQL 쿼리에 사용자 입력을 그대로 넣는 패턴이 반복되고, 파라미터화된 쿼리 대신 문자열 조합으로 처리합니다. 테스트 데이터로는 멀쩡히 동작하지만, 실제 악성 입력이 들어오는 순간 DB 전체가 노출됩니다.

두 번째는 인증·권한 오류입니다. 로그인 함수를 생성할 때 해싱은 하지만 알고리즘이 취약하거나, 세션 토큰의 HttpOnly·Secure 플래그를 빠뜨리는 경우가 잦습니다. 세 번째는 하드코딩된 시크릿입니다. Escape.tech 스캔에서 400개 이상의 API 키·인증 정보가 그대로 노출된 게 대표적 사례입니다. (출처: Forbes, 2026.03.20) 네 번째는 취약한 의존성입니다. AI가 라이브러리를 추천할 때 버전 고정이나 CVE 확인 없이 제안하는 경우가 많습니다.

Checkmarx는 한 가지를 더 경고합니다. AI 코딩 도구가 광범위한 권한을 요구하는 구조이기 때문에, 도구 자체가 침해되면 소스코드·인증 정보·민감한 자산이 함께 노출될 수 있다고 지적했습니다. (출처: Checkmarx Blog, 2026.03.17) 도구를 신뢰하는 것 자체가 리스크가 되는 상황입니다.

프롬프트 자체가 구멍을 만들 수 있습니다

바이브코딩 보안에서 기존 블로그가 잘 다루지 않는 지점이 있습니다. 취약점이 코드 생성 이후에 생기는 게 아니라, 프롬프트를 입력하는 순간부터 시작된다는 점입니다. Retool의 분석에 따르면, 프롬프트에 샘플 데이터·설정 정보·시스템 연결 방식을 그대로 넣으면, AI가 그 정보를 학습해 비안전한 구현을 생성할 가능성이 높아집니다. (출처: Retool Blog, 2026.03.03)

Wits 대학 IS 교수 Rennie Naidoo는 또 다른 문제를 지적합니다. AI 모델은 공개 레포지토리를 학습했기 때문에 과거의 나쁜 패턴도 함께 흡수했다는 점입니다. 실제로 AI 생성 C 함수에서 버퍼 오버플로 취약점이 발견됐고, Python에서는 멀티플레이어 데이터 교환에 보안상 위험한 pickle 모듈이 사용된 사례도 공개됐습니다. (출처: Wits University/CIO-SA, 2026.03.10)

솔직히 말하면, 자동화 편향(Automation Complacency)이 여기서 크게 작용합니다. AI가 계속 맞아왔으니까 이번에도 맞겠지 — 이 심리가 검토를 건너뛰게 만들고, 그게 취약점이 프로덕션에 도달하는 경로가 됩니다. 도구가 좋아질수록 이 편향은 오히려 강해지는 구조입니다.

그래도 쓰려면 이것만은 지켜야 합니다

GitHub Copilot은 현재 평균 개발자 코드의 46%를 AI가 생성합니다. (출처: Forbes, 2026.03.20) 완전히 안 쓰는 건 선택지가 아닙니다. 그렇다면 리스크를 줄이는 실제 방법은 무엇인지 연구 데이터에서 도출한 세 가지를 정리했습니다.

이 세 가지는 바이브코딩의 속도 이점을 포기하지 않으면서 리스크를 줄이는 데 실제로 효과가 있다고 보안 전문가들이 지목한 방법입니다. 완벽한 해법은 아직 없고, 더 정교한 보안 전략은 현재 연구 중입니다.

Q&A — 자주 묻는 것들

마치며

바이브코딩이 빠르다는 건 사실입니다. 단 몇 초 만에 앱을 뚝딱 만들어내는 경험은 실제입니다. 그런데 그 속도가 “검토를 건너뛰어도 된다”는 신호로 읽혀서는 안 됩니다. 공식 연구들이 공통적으로 가리키는 방향은 하나입니다. 바이브코딩은 시작점이지 끝점이 아닙니다.

기능이 통과해도 보안은 통과하지 못한다는 걸 수치로 확인한 이상, “한 번 돌려봤는데 됐다”는 판단은 충분한 근거가 되지 않습니다. 특히 실제 사용자 데이터가 연결되는 순간부터는, 속도의 이점보다 놓친 취약점의 비용이 훨씬 빠르게 불어납니다.

AI 도구가 더 좋아질수록 이 문제가 저절로 해결될 거라고 기대하기 어렵습니다. SusVibes 연구팀도 “더 정교한 보안 전략이 필요하다”고 마무리했습니다. 지금 당장 쓸 수 있는 현실적인 방법은, 속도는 AI에게 맡기고 검토는 사람과 자동화 도구가 함께 가져가는 구조입니다.

본 포스팅 참고 자료

1. CMU·Columbia University, Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code — arxiv.org/html/2512.03262
2. Forbes / Jodie Cook, Vibe Coding Has A Massive Security Problem (2026.03.20) — forbes.com
3. Checkmarx, Security in Vibe Coding (2026.03.17) — checkmarx.com
4. Retool, The Risks of Vibe Coding (2026.03.03) — retool.com
5. Wits University / CIO-SA, Securing Vibe Coding: The Hidden Risks (2026.03.10) — wits.ac.za