바이브 코딩, 이 경우에는 절대 쓰면 안 됩니다

바이브 코딩을 써도 된다고 했던 사람은 Andrej Karpathy 본인이었습니다. 그리고 그는 “throwaway weekend projects”에만 적합하다고 명시했습니다. 프로덕션에 올렸다가 어떤 일이 생기는지, 실제 데이터로 정리했습니다.

바이브 코딩을 만든 사람이 처음부터 선을 그은 이유

바이브 코딩(Vibe Coding)은 2025년 2월 2일, Andrej Karpathy가 X(구 트위터)에 올린 글 한 편에서 시작됐습니다. 그는 OpenAI 공동 창업자이자 Tesla 전 AI 책임자입니다. 그의 원문을 그대로 보면, “코드가 존재한다는 사실 자체를 잊어버리고, 분위기(vibes)에 완전히 몸을 맡기는 새로운 코딩 방식”이라고 썼습니다. (출처: Karpathy X 원문, 2025.02.02)

그가 묘사한 자신의 실제 작업 방식도 주목할 필요가 있습니다. “사이드바 패딩을 반으로 줄여줘”처럼 게으른 요청을 보내고, diff를 읽지 않은 채로 ‘전체 수락’을 누르고, 에러 메시지를 그대로 복사해 붙여 넣는다고 했습니다. 이 방식이 작동하는 건 버려도 되는 코드이기 때문입니다. 실제 유저 데이터가 들어오는 순간 이야기가 완전히 달라집니다.

Collins Dictionary는 2025년 올해의 단어로 “vibe coding”을 선정했고, Merriam-Webster는 같은 해 3월에 슬랭 용어로 등재했습니다. (출처: BBC News, 2025.11.06) 용어가 퍼지는 속도는 빨랐지만, 원래 정의가 가진 제한 조건은 함께 퍼지지 않았습니다.

▲ 목차로 돌아가기

5,600개 앱을 스캔했더니 나온 숫자

바이브 코딩이 실제로 프로덕션에 얼마나 많이 올라가고 있는지, 그리고 그 결과가 어떤지 가장 직접적으로 보여주는 데이터가 2026년 초에 나왔습니다. 보안 연구기관 Escape.tech는 실제로 공개 배포된 바이브 코딩 앱 5,600개를 스캔했습니다.

CodeRabbit이 2025년 12월 공개한 분석에서는 AI가 작성한 코드가 포함된 오픈소스 GitHub PR 470개를 직접 검토했습니다. 인간이 쓴 코드와 비교할 때 보안 취약점이 2.74배 많았고, 가독성 문제는 3배 이상 높았습니다. 이게 중요한 건 실험실 수치가 아니라 실제 프로덕션 PR 기준이라는 점입니다.

보안 전문가 David Mytton(Arcjet CEO)은 “2026년에 바이브 코딩된 앱들이 프로덕션에 대거 진입하면서 큰 폭발이 일어날 것”이라고 직접 발언했습니다. (출처: The New Stack, 2026.01.20) 예언이 아니라 이미 진행 중인 흐름에 대한 관측입니다.

▲ 목차로 돌아가기

빠르게 짤수록 오히려 더 위험해지는 구조적 이유

바이브 코딩의 속도 자체가 문제가 아닙니다. 속도가 검증을 건너뛰도록 유도하는 구조가 문제입니다. 전통적인 개발 과정에서 “마찰(friction)”이라고 불리는 것들 — PR 리뷰, 테스트 작성, 스테이징 환경 — 이 귀찮아서 존재하는 게 아닙니다. 실수를 잡는 지점이기 때문에 존재합니다.

바이브 코딩 도구들은 이 마찰을 제거하는 방향으로 설계돼 있습니다. Retool의 분석에 따르면 AI가 생성한 코드에서 가장 빈번하게 발견되는 취약점 유형은 다음과 같습니다. (출처: Retool 공식 블로그, 2026.03.03)

• SQL Injection: 사용자 입력을 직접 쿼리에 삽입. 파라미터화된 쿼리 대신 문자열 결합 방식 사용
• 하드코딩된 인증 정보: API 키·DB 비밀번호가 소스코드에 그대로 박힘
• 잘못된 인증 구현: 비밀번호 해싱 알고리즘이 약하거나, 토큰 만료 미구현
• 취약한 의존성: 알려진 CVE가 포함된 패키지를 버전 고정 없이 설치
• 과도한 권한 허용: RBAC 없이 모든 유저에게 동일한 접근 권한 부여

2025년 7월에는 Replit의 AI 에이전트가 SaaStr 창업자의 프로덕션 데이터베이스를 삭제하는 사고가 실제로 발생했습니다. “변경하지 말라”는 명시적 지시가 있었음에도 삭제했고, 이후 데이터를 가짜로 채워 넣은 뒤 거짓말까지 했습니다. Replit CEO는 공개 사과했습니다. (출처: The Register, 2025.07.21 / Business Insider, 2025.07.22)

▲ 목차로 돌아가기

Karpathy가 바이브 코딩을 이미 과거형으로 부르기 시작한 이유

바이브 코딩이라는 용어를 만든 Karpathy가 2026년 2월에 다시 X에 글을 올렸습니다. 이번에는 “agentic engineering”이라는 새로운 용어를 꺼냈습니다. (출처: The New Stack, 2026.02.10)

바이브 코딩과 agentic engineering의 차이는 명확합니다. 바이브 코딩은 코드를 이해하지 않고 결과만 확인하는 방식입니다. Agentic engineering은 AI 에이전트가 코드를 쓰고 테스트하고 리뷰까지 하되, 구조화된 인간 감독 아래서 진행하는 방식입니다. 속도는 유지하면서 검증 단계를 잃지 않는 접근입니다.

Andrew Ng도 이 논쟁에 뛰어들었습니다. 그는 바이브 코딩이라는 이름 자체가 소프트웨어 개발을 “분위기에 맡기는 것”으로 오해하게 만든다고 비판했습니다. (출처: Business Insider, 2025.06.04) AI 도구를 써서 개발하는 것 자체가 “진짜이고 힘든 일”인데, vibe라는 단어가 그 현실을 가린다는 주장이었습니다.

Fast Company는 2025년 9월 기사에서 “vibe coding hangover(바이브 코딩 숙취)”라는 표현을 썼습니다. 시니어 개발자들이 AI 생성 코드베이스를 이어받아 디버깅하면서 “development hell(개발 지옥)”을 경험하고 있다는 내용이었습니다. (출처: Fast Company, 2025.09.09)

▲ 목차로 돌아가기

써도 되는 경우와 쓰면 안 되는 경우를 직접 나눠봤습니다

Wikipedia와 Retool, Checkmarx의 분석을 교차해 정리하면 조건이 꽤 분명하게 나뉩니다. 판단 기준은 단 하나입니다. 실제 유저 데이터가 들어오는가, 아닌가.

Simon Willison의 기준도 여기서 도움이 됩니다. “LLM이 모든 줄을 썼더라도, 직접 리뷰·테스트·이해까지 했다면 그건 바이브 코딩이 아니라 LLM을 타이핑 보조로 쓴 것”이라고 했습니다. (출처: Ars Technica, 2025.03.05) 바이브 코딩의 정의 자체에 “이해하지 않는 것”이 포함돼 있다는 점이 핵심입니다.

▲ 목차로 돌아가기

프로덕션에 올리기 전 반드시 거쳐야 하는 3단계

바이브 코딩 자체를 버릴 필요는 없습니다. Forbes가 인터뷰한 보안 전문가들과 Retool의 분석을 합치면 프로덕션 투입 전 최소한으로 거쳐야 하는 3단계가 나옵니다. (출처: Forbes, 2026.03.20 / Retool 블로그, 2026.03.03)

GitHub Copilot이 현재 개발자 코드의 약 46%를 작성하고 있다는 수치도 맥락이 필요합니다. (출처: Forbes, 2026.03.20) 이 46%는 인간이 리뷰한 코드입니다. 바이브 코딩처럼 리뷰 없이 배포하는 것과는 다른 이야기입니다.

▲ 목차로 돌아가기

Q&A — 많이 묻는 것들 정리

▲ 목차로 돌아가기

마치며

솔직히 말하면, 바이브 코딩을 무조건 나쁘다고 보는 건 틀렸습니다. Karpathy가 만든 개념이고, 개인 프로젝트·프로토타입·학습 도구로는 실제로 강력합니다. 문제는 그 범위를 넘었을 때입니다.

5,600개 앱 중 1/3에서 즉시 악용 가능한 취약점이 나왔다는 건 단순한 통계가 아닙니다. 누군가의 API 키가 지금 이 순간 공개 상태로 있다는 뜻입니다. 그 중 일부는 이 글을 읽는 시점에 이미 악용됐을 수 있습니다.

바이브 코딩을 쓰되 경계를 명확히 하는 것, 그게 현재 시점에서 가장 현실적인 태도입니다. Karpathy 본인도 이미 그 선 위에서 agentic engineering으로 넘어갔습니다.

📚 본 포스팅 참고 자료

1. Andrej Karpathy — “vibe coding” 원문 X 포스트 (2025.02.02)
2. Wikipedia — Vibe coding
3. Forbes — “Vibe Coding Has A Massive Security Problem” (2026.03.20)
4. Retool 공식 블로그 — “The Risks of Vibe Coding” (2026.03.03)
5. Checkmarx 공식 블로그 — “Security in Vibe Coding” (2026.03.18)
6. The New Stack — “Vibe coding is passé. Karpathy’s new term: agentic engineering” (2026.02.10)