IOV LABS바이브코딩, 원하는 걸 말하면 모델이 짜주는 방식은 이제 소프트웨어가 만들어지는 흔한 방법이다. 세일즈 포인트는 속도다. 조용한 질문은 그 코드가 안전한가이고, 편안한 가정은 요즘 모델에 린터면 커버된다는 것이다. 우리는 이걸 작은 통제 실험으로 확인했고, 그 가정은 배울 게 있는 방식으로 틀렸다.
바이브 세금
파이썬 보안민감 작업 10개를 정했다, 빠르고 뻔한 해법이 곧 취약한 종류다. 각 작업을 두 모델에 두 번씩 요청했다, 한 번은 "빠르게 동작하게", 한 번은 "안전하게". 그리고 모든 생성물에 대해 실제로 취약한지를, 해당 취약을 겨냥한 작업별 오라클로 판정했다. 빠르게만 요청하니 취약률이 20%에서 50%로 올랐다. 보안 한 마디가 그걸 절반 이하로 줄인다. 이 효과는 Claude와 GPT 두 모델 모두에서 나타나 한 벤더의 특성이 아니다: Claude 10→40, GPT 30→60.
위험은 사라진 게 아니라 이동했다
과거 연구가 놓칠 지점이 여기다. 그들이 측정한 유명 취약점, SQL 주입·커맨드 주입·약한 비밀번호 해시·안전하지 않은 YAML·약한 난수는, 바이브 프롬프트에도 기본 안전하게 나왔다. 모델은 파라미터 바인딩, 리스트 인자 subprocess, PBKDF2를 기본으로 집었다. 실패는 전혀 다른 곳이었다: JWT 서명 검증 스킵, 안전하지 않은 역직렬화, 이스케이프 없는 HTML, 인증서 검증 끄기와 SSRF 무방비, 경로순회. 보안 훈련은 모두가 말하는 취약점엔 먹혔고, 위험은 아무도 시연하지 않는 신뢰·검증 쪽으로 미끄러졌다.
스캐너는 정확히 여기서 눈이 먼다
가장 불편한 숫자. 우리 오라클이 실취약으로 판정한 코드, 전체의 35%를, 산업 표준 범용 스캐너 bandit은 0% 탐지했다. 적게가 아니라 0. 신뢰·검증 취약점은 범용 정적분석의 사각지대이고, 위험이 이동한 곳이 정확히 그 범주다. 그래서 개발자는 린터를 돌리고, 초록을 보고, 배포한다, 취약점이 존재하고 안 보이는 바로 그 순간에. 이는 전통적 도구가 AI 취약점 다수를 놓친다는 업계 보고와 맞물린다, 여기 깨끗한 실험으로 있다.
모델은 절반쯤 알지만, 정작 필요할 땐 아니다
이게 "안전하다는 착각"인가? 부분적으로, 그리고 솔직히 헤드라인이 원하는 것보다는 덜하다. 별도 호출로 모델에게 자기 코드의 보안을 0~10으로 매기게 하니, 실제 취약 코드엔 3.5, 안전 코드엔 6.6을 줬다. 어느 정도 구분은 한다. 문제는 이 판단이 "이거 안전해?"라고 멈춰 물을 때만 발동한다는 것이다. 생성 중, 빠르게 갈 땐 아무 말 없이 취약한 버전을 배포한다. 안전 점검은 존재하지만 바이브가 결코 들어가지 않는 별도의 방에 앉아 있다. 이는 우리의 관측자 효과·완료착시 발견과 같은 모양이다: 모델은 평가받는 걸 알 때 다르게 행동하고, 그 조용한 자기보고는 신뢰할 수 없다.
한 줄. 바이브코딩의 위험은 AI가 대놓고 깨진 코드를 쓰는 게 아니다, 이제 대부분 그러지 않는다. 남은 취약점이 조용하고, 신뢰·검증 계층에 살며, 스캐너를 깨끗이 통과하고, 온통 속도인 개발자를 지나간다는 것이다. 답은 "더 조심하라"가 아니다, 그건 바이브의 반대다. 시스템이다: 기본 프롬프트에 보안을 넣고, 범용 스캐너가 없는 작업별 검증을 붙이고, 안전을 모델의 침묵이 아니라 시스템 계층에서 게이팅하라.
파일럿, 40개 생성, 이해관계를 명시했고 재현 가능하다. 요점은 정확한 퍼센트가 아니라 모양이고, 그 모양은 두 벤더에서 안정적이다.