바이브 코딩이 뭔지, 지금 얼마나 쓰이는지

바이브 코딩은 2025년 초 AI 연구자 안드레이 카르파티(Andrej Karpathy)가 만든 용어입니다. 코드를 한 줄씩 쓰는 대신, 자연어로 원하는 기능을 설명하면 AI가 코드를 생성하는 방식입니다. 카르파티 본인 표현으로는 “코드가 존재한다는 사실조차 잊어버리는” 개발 방식이고, 콜린스 사전이 2025년 올해의 단어로 선정했습니다.

수치가 이미 꽤 큽니다. GitHub Copilot은 2026년 기준 개발자가 작성하는 코드의 46%를 차지하고 있으며 (출처: GitHub 공식 통계, 2026.01), 조사에 따르면 개발자 75%가 바이브 코딩을 활용하고 있고 그 중 90%가 만족한다고 응답했습니다. (출처: The Information 설문, CMU 논문 인용) 속도는 실제로 빠릅니다. 그 속도가 무엇을 함께 데려오는지가 문제입니다.

▲ 목차로 돌아가기

기능이 돌아간다는 게 전부가 아닌 이유

솔직히 말하면, 이 부분이 가장 충격적이었습니다. CMU 연구팀이 발표한 “Is Vibe Coding Safe?” 논문(arxiv: 2512.03262)은 실제 GitHub 리포지터리 108개에서 200개 작업을 AI 에이전트에게 맡긴 뒤 기능 테스트와 보안 테스트를 따로 돌렸습니다. 결과가 딱 이렇게 나왔습니다.

최고 성능 조합인 SWE-Agent + Claude 4 Sonnet 기준으로, 기능적으로 올바른 코드 중 82.8%가 보안 취약점을 포함하고 있었습니다. 다시 말해, “테스트가 통과됐다”는 것이 “이 코드는 안전하다”를 전혀 보장하지 않습니다.

CodeRabbit이 2025년 12월 470개 오픈소스 GitHub PR을 분석한 결과도 비슷합니다. AI가 작성한 코드는 사람이 작성한 것보다 보안 취약점이 2.74배 더 많이 발견됐습니다. (출처: CodeRabbit 공식 보고서, 2025.12) 수치 자체보다 더 중요한 건, 이게 실험적 사이드 프로젝트가 아니라 실제 서비스에 올라간 프로덕션 코드라는 점입니다.

▲ 목차로 돌아가기

실제로 어떤 취약점이 생기나 — 4가지 패턴

CMU 논문이 사례 분석에서 밝힌 취약점들은 낯선 개념이 아닙니다. 실제 버그 바운티나 레드팀이 고가치 서비스에서 찾아내는 것과 같은 종류입니다.

공통점이 있습니다. AI는 기능 요구사항을 구현하는 건 잘 합니다. 하지만 “타이밍 일관성”, “URL 스킴 검증”, “세션 만료 처리” 같이 보안 불변 조건(security invariant)을 지키는 부분에서 반복적으로 실패합니다. 기능을 이해하는 것과 그 기능이 안전해야 한다는 맥락을 함께 이해하는 건 다른 문제이기 때문입니다.

▲ 목차로 돌아가기

“보안 신경 써줘”라고 해도 안 되는 이유

CMU 연구팀은 프롬프트로 보안 문제를 해결할 수 있는지도 실험했습니다. 세 가지 방식을 시도했습니다. 첫째는 “보안을 신경 써줘”라는 일반 안내 추가, 둘째는 에이전트가 스스로 관련 CWE를 식별하게 하는 방식, 셋째는 정확한 CVE 번호를 직접 알려주는 방식입니다. 결과는 생각보다 단호했습니다.

또 다른 연구 수치도 있습니다. Legit Security가 인용한 연구에서 AI에게 반복적으로 코드를 수정하게 하면 개발 속도는 빨라지지만, 치명적 취약점이 37% 증가했습니다. (출처: Legit Security 공식 블로그, 2025.12.22) 빠르게 고치면 고칠수록 더 많은 구멍이 생긴다는 건데, 바이브 코딩의 특성인 “에러 메시지 붙여넣기 → AI 수정 반복” 루프가 정확히 이 상황을 만들어 냅니다.

결론적으로, 바이브 코딩의 보안 문제는 프롬프트를 더 잘 쓰는 방식으로는 해결되지 않습니다. 모델 외부에서 작동하는 독립적인 검증 체계가 필요합니다.

▲ 목차로 돌아가기

코드 저작권, 생각보다 훨씬 복잡합니다

보안 이외에 잘 알려지지 않은 함정이 하나 더 있습니다. 바이브 코딩으로 만든 코드는 저작권 보호를 받기 어렵습니다. 대한민국을 포함해 베른 협약 가입국에서는 저작권이 인간의 사상과 감정을 표현한 자연인에게만 귀속됩니다. AI가 생성한 코드는 이 기준에서 저작물로 인정되지 않습니다. (출처: 나무위키 바이브 코딩 항목 법적 쟁점 섹션 / 저작권법 ‘아이디어·표현 이분법’ 원칙)

실용적으로 이것이 의미하는 건 뭘까요. 경쟁사가 내 바이브 코딩 결과물을 그대로 복사해도 법적으로 대응하기 어려울 수 있습니다. 반대로, AI가 학습 과정에서 사용한 오픈소스 코드의 저작권은 원 저작자에게 그대로 남아 있습니다. GitHub Copilot이 저작권 세탁 논란을 받는 이유도 여기에 있습니다. 프로젝트를 서비스로 키울 계획이라면, 법률 검토가 코드 검토만큼 중요한 단계가 됩니다.

▲ 목차로 돌아가기

바이브 코딩을 쓰면 안 되는 상황이 있습니다

Google Cloud 공식 문서는 바이브 코딩이 적합한 시작점으로 “일회성 프로토타입, 빠른 아이디어 구현”을 명시합니다. (출처: Google Cloud 공식 바이브 코딩 가이드, 2026.02.26) 그 반대 경우, 즉 쓰면 위험해지는 상황도 사실상 공식 문서 안에 정의되어 있습니다. 아래 세 경우입니다.

▲ 목차로 돌아가기

그래도 쓸 거라면 — 실질적인 선택 기준

바이브 코딩을 버리자는 게 아닙니다. GitHub Copilot이 개발자 코드의 46%를 차지하는 지금, 이 흐름을 역행하는 게 오히려 비현실적입니다. Forbes가 정리한 실제로 잘 쓰는 팀들의 방식은 명확합니다. AI가 생성한 코드를 시작점으로만 쓰고, 프로덕션에 올리기 전에 자동화된 보안 스캔을 반드시 거칩니다.

Snyk, Semgrep, CodeRabbit처럼 AI 코드 전용 리뷰 도구를 쓰면 많은 취약점을 배포 전에 잡을 수 있습니다. CMU 연구팀이 제시한 프레임도 같습니다. “AI 개별 결과물을 믿는 게 아니라, AI를 감싸는 가드레일 시스템을 믿는” 구조가 되어야 합니다. 인증, 결제, 개인정보 관련 코드만큼은 사람이 전체 diff를 확인하고 승인하는 단계를 생략하지 말 것을 권장합니다.

▲ 목차로 돌아가기

자주 묻는 질문

마치며

바이브 코딩이 빠른 건 사실입니다. 카르파티가 이 개념을 소개한 지 1년 만에 개발자 75%가 사용하고, GitHub Copilot은 전체 코드의 46%를 차지하고 있습니다. 속도는 실제입니다. 그런데 CMU 연구가 보여준 건, 그 속도가 만들어낸 코드의 80% 이상이 보안 구멍을 안고 있다는 겁니다.

프롬프트를 더 잘 쓴다고 해결되지 않고, AI를 바꿔도 구조적으로 같은 문제가 반복됩니다. 결국 바이브 코딩을 도구로 제대로 쓰려면 “AI가 짰으니 됐겠지”가 아니라 “AI가 짰으니 한 번 더 검증하자”는 판단이 프로세스에 들어가야 합니다. 배포 전 자동 스캔, 인증/결제 코드에 대한 사람 리뷰, 이 두 가지만 지켜도 실제 사고 확률은 크게 달라집니다.

빠른 것과 안전한 것은 기본값으로 같이 오지 않습니다. 직접 설계해야 같이 옵니다.

📚 본 포스팅 참고 자료

1. Google Cloud 공식 바이브 코딩 가이드 — cloud.google.com/discover/what-is-vibe-coding
2. CMU 연구팀, “Is Vibe Coding Safe?” — arxiv.org/abs/2512.03262
3. Forbes, “Vibe Coding Has A Massive Security Problem” (2026.03.20) — forbes.com
4. Symbiotic Security, “Vibe Coding Is Not Secured by Default” — symbioticsec.ai
5. Stack Overflow Blog, “A New Worst Coder Has Entered the Chat” (2026.01.02) — stackoverflow.blog