바이브코딩 보안 — AI가 짠 코드 45%가 보안 테스트를 통과 못 한 이유

솔직히 고백하자면, 나도 얼마 전 주말에 AI한테 앱 하나를 통째로 맡겼다. 공과금이랑 구독료를 정리하는 간단한 웹앱이었고, 코드는 한 줄도 직접 쓰지 않았다. 40분 만에 돌아갔다. 꽤 뿌듯했다.

며칠 뒤에 알았다. 그 앱은 브라우저 개발자 도구만 열면 데이터베이스 접근 키가 그대로 보이는 구조였다.

지금 같은 일이 전 세계에서 동시에, 수백만 번 벌어지고 있다.

이미 주류가 된 개발 방식

용어를 만든 건 AI 연구자 안드레 카파시(Andrej Karpathy)다. 코드를 직접 쓰는 대신 원하는 결과 — "바이브" — 를 일상어로 설명하면 AI가 나머지를 채워준다. 안 되면 될 때까지 다시 물어보면 된다. 코드가 어떻게 도는지 몰라도 된다는 게 이 방식의 매력이자 함정이다.

규모를 보면 일시적 유행으로 보기 어렵다. Stack Overflow 개발자 설문에서 전 세계 응답자의 84%가 2025년에 AI 코딩 도구를 쓰고 있거나 쓸 계획이라고 답했다. 바이브코딩 플랫폼 이용자의 약 63%는 프로그래밍 배경이 없는 사람들이다. 가트너는 2028년까지 새로 만들어지는 기업용 프로덕션 소프트웨어의 40%가 이 방식으로 생산될 것으로 본다. 2025년 겨울 Y Combinator 배치에 들어간 스타트업의 25%는 코드베이스의 95%가 AI 생성이었다.

돌아가는 소프트웨어와 믿고 맡길 수 있는 소프트웨어는 서로 다른 물건이다.

"작동한다"는 완성이 아니다

개발자가 하루 종일 코드만 친다고 생각하기 쉽지만, 코딩은 전체 과정의 한 조각이다. 배포 전에 따로 던지는 질문들이 있다. 모든 상황에서 제대로 도는가. 안전한가. 다른 사람이 이어받아 고칠 수 있는가. 잘못됐을 때 무슨 일이 벌어지는가.

이 절차들은 개발 속도를 늦추려고 있는 게 아니다. 목적대로 잘 돌아가는 것처럼 보이는 소프트웨어도 민감한 정보를 흘리거나 중요한 시스템을 멈춰 세울 수 있기 때문에 있는 것이다.

가계부 앱을 떠올려보자. 열리고, 지출이 기록되고, 합계가 계산된다. 겉으로는 아무 문제 없다. 그런데 모든 경우에 계산이 맞나. 금융 정보는 어떤 방식으로 저장되고 있나. 입력하다 앱이 죽으면 데이터는 어떻게 되나.

초보자가 떠올리기 어려운 질문이고, 직업 개발자는 습관처럼 던지는 질문이다. 이 간극이 바이브코딩의 진짜 리스크다.

고치는 과정도 만만치 않다. 문제 하나를 고쳐달라고 하면 엉뚱한 곳에 새 문제가 생긴다. AI가 뭘 바꿨는지 모르는 상태에서, AI가 만들었을지도 모르는 문제를 다시 AI에게 물어보게 된다.

숫자로 보면 더 선명하다

한 보안 연구에서 AI가 생성한 코드 샘플의 약 45%가 표준 보안 테스트를 통과하지 못했다.

더 구체적인 실측도 나와 있다. SecurityWeek가 2026년 7월 보도한 Theori의 자동 침투테스트 플랫폼 Xint.io 분석에서, 바이브코딩으로 만든 앱들에서 실제 공격이 가능한 취약점 434건이 확인됐다. 크리티컬 등급 23건 가운데 11건이 하드코딩되거나 기본값 그대로 남은 시크릿 노출이었고, 6건은 디버그 모드가 켜진 채 배포돼 원격 코드 실행이 가능한 상태였다.

취약점의 '종류'가 흥미롭다. SQL 인젝션이나 XSS처럼 교과서에 나오는 주입 결함은 오히려 드물어졌다. 모델이 그 부분은 확실히 학습했다는 뜻이다. 대신 권한 우회(IDOR)가 남았고, 앱이 커질수록 악화됐다. 작은 앱에서 11%, 큰 앱에서 28%.

시크릿 유출은 더 노골적이다. GitGuardian이 낸 2026년 리포트를 보면 2025년 한 해 공개 GitHub 커밋에서 새로 노출된 하드코딩 시크릿이 2,865만 건으로, 전년 대비 34% 늘어 역대 최대를 찍었다. 같은 리포트에서 AI 보조로 작성된 커밋의 시크릿 유출률은 3.2%, 전체 평균 1.5%의 두 배가 넘었다.

프로덕션에 올라간 바이브코딩 앱 1,072개를 훑은 결과도 있다. 300개 넘는 앱이 브라우저에서 그대로 열리는 자바스크립트에 데이터베이스 키를 박아뒀고, 172개는 인증 없이 누구나 데이터를 지울 수 있었다.

코드를 만드는 일이 쉬워졌다고 해서, 그 코드가 안전한지 판단하는 일까지 쉬워진 건 아니다.

진짜 문제는 코드가 아니라 습관

보안 연구자들이 오래전부터 경고해 온 개념이 있다. 자동화 편향(automation bias) — 자동화된 시스템이 내놓은 결과를 충분히 검증하지 않고 받아들이는 경향이다. AI가 복잡한 문제를 잘 풀수록, 답을 의심하지 않고 넘어가기가 쉬워진다.

소프트웨어에서 이게 유독 위험한 이유는 실수가 눈에 안 보이기 때문이다. 잘못 계산된 숫자는 티가 나지만, 잘못 열린 권한은 누군가 들어오기 전까지 아무 신호도 주지 않는다.

국내 사정도 크게 다르지 않다. 개발 커뮤니티나 사이드프로젝트 모임을 보면 "AI로 만들긴 했는데 이대로 배포해도 되는지 모르겠다"는 질문이 부쩍 늘었다. 만든 사람이 코드를 못 읽으니 스스로 판단할 기준이 없는 것이다.

개인이나 소규모 팀이 보안 감사를 통째로 돌릴 여력은 없겠지만, 배포 전에 이 정도는 직접 확인해볼 만하다.

• API 키나 DB 접속 정보가 프런트엔드 코드에 들어가 있지 않은지 — 브라우저에서 소스 보기만 해도 절반은 걸러진다.
• 로그인한 사용자가 남의 데이터에 접근할 수 있는지 — URL의 계정 번호를 남의 것으로 바꿔보면 몇 초 만에 확인된다.
• 디버그 모드가 켜진 채 배포되지 않았는지 — 에러 화면에 내부 경로가 다 보이면 이미 늦었다.
• 삭제나 수정 요청에 권한 검사가 붙어 있는지 — 앞선 조사에서 172개 앱이 여기서 뚫렸다.

앞서 나온 취약점 통계의 상당수가 이 네 가지 안에 들어간다.

오해는 없었으면 한다. 바이브코딩 자체가 잘못됐다는 이야기가 아니다. 아이디어를 빠르게 실험하고, 프로그래밍 개념을 배우고, 나만 쓸 도구를 만드는 데 이만한 방법이 없다. 프로토타입 단계에서부터 보안 감사를 붙이자는 건 과잉이다. 선이 그어지는 지점은 꽤 분명하다. 개인정보, 돈, 남의 데이터가 얽히는 순간부터는 누가 코드를 썼든 사람의 검토가 필요하다.

바이브코딩은 소프트웨어를 만들 수 있는 사람의 범위를 극적으로 넓혔다. 다만 만들어진 결과물을 판단하는 책임까지 대신 져주지는 않는다. AI는 코드를 쓸 수 있어도, 그 코드가 하는 일에 책임을 지지는 못한다.

여러분은 어떤가. AI로 만든 걸 실제로 배포해본 적 있다면 배포 전에 무엇을 확인했는지 궁금하다. 혹시 나처럼 뒤늦게 식은땀 흘린 경험이 있다면, 그 이야기도 듣고 싶다.

---

📎 출처: 원문 보기