2025년 2월, Andrej Karpathy가 트윗 하나를 올렸다.
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
코드를 잊어라. 분위기에 몸을 맡겨라. AI가 다 해준다.
이 단어는 2025년 Collins 영어사전 올해의 단어로 선정됐고, 유튜브에는 "코딩 몰라도 앱 만들기" 영상이 쏟아졌다. 바이브 코딩만 있으면 개발자가 필요 없다는 믿음이 퍼지기 시작했다.
나는 지난 9개월간 AI와 함께 실제 서비스를 만들었다. Flutter 앱, Next.js 웹, 관리자 대시보드 — 3개 프로젝트, 수천 개의 커밋. AI 코딩 도구를 매일 썼다.
그래서 말할 수 있다. 바이브 코딩은 반쪽짜리다.
빠르다. 진짜로.
부정할 수 없는 사실부터. AI 코딩 도구는 정말 빠르다.
프로토타입을 만드는 속도는 압도적이다. 화면 하나 만드는 데 10분. API 연동까지 30분. "이런 거 만들어줘"라고 하면 진짜 만들어준다. 데모 영상 찍기에는 완벽하다.
바이브 코딩 영상들이 보여주는 건 바로 이 부분이다. 0에서 1로 가는 속도. 빈 화면에서 동작하는 앱이 나오는 마법 같은 순간.
문제는 그 다음이다.
80%의 함정
AI가 생성한 코드는 프로젝트의 처음 80%를 놀라운 속도로 해결한다. 하지만 나머지 20% — 엣지 케이스, 통합, 프로덕션 안정화 — 여기서 프로젝트가 죽는다. 그리고 이 20%에는 바이브 코딩이 불필요하다고 약속한 바로 그 코딩 스킬이 필요하다.
내가 직접 겪은 것들:
컨텍스트를 놓친다. 대화가 길어지면 AI는 앞에서 정한 규칙을 잊는다. "Supabase RPC는 이 패턴으로 호출해"라고 CLAUDE.md에 적어놓아도, 컨텍스트가 밀리면 다른 패턴으로 돌아간다. 504줄짜리 CLAUDE.md를 만든 이유가 여기에 있다 — AI가 잊는 것을 문서가 기억하게 하려고.
전체 흐름을 모른다. AI는 지금 보이는 코드는 잘 다루지만, 서비스 전체의 방향성을 이해하지 못한다. "이 기능을 추가해줘"라고 하면 만들어주지만, 그게 기존 아키텍처와 충돌하는지, 사용자 경험에 어떤 영향을 주는지는 사람이 판단해야 한다.
코드 품질의 세부. 동작은 한다. 하지만 에러 핸들링이 빠져 있거나, 타입이 느슨하거나, 불필요한 리렌더링이 있거나. "동작하는 코드"와 "좋은 코드" 사이의 간극을 AI는 아직 잘 메우지 못한다.
숫자가 말해주는 것
바이브 코딩의 위험을 보여주는 실제 데이터들이 있다.
CodeRabbit이 470개의 GitHub PR을 분석한 결과, AI 공동 작성 코드의 보안 취약점 발생률은 인간 작성 코드 대비 2.74배 높았다. 로직 에러는 75% 더 빈번했다.
2025년 하반기에 보안 연구자들이 발견한 바이브 코딩 관련 보안 사고는 7개월간 약 18건이었다. 2026년 1~3월에는 56건. 3월 한 달만 35건으로, 2025년 전체보다 많다.
실제 사고 사례들:
- Moltbook: Row Level Security 미적용으로 API 키 150만 개 노출
- Lovable 기반 앱들: 접근 제어 로직이 반전되어 170개 프로덕션 앱에 영향
- Base44: 플랫폼 전체 인증 우회 취약점
- Replit AI 에이전트: 명시적 코드 프리즈 중에 프로덕션 DB 삭제
바이브 코딩으로 만든 앱의 유지보수
유튜브에서 "바이브 코딩으로 앱 만들기" 영상이 쏟아지고 있다. 대부분 2025년 중후반에 만들어졌다. 즉, 그 앱들의 나이는 길어야 1년이 안 된다.
진짜 질문은 이거다: 그 앱들은 지금도 살아 있는가?
소프트웨어는 만드는 것보다 유지하는 게 어렵다. 코드를 이해하지 못하면 수정할 수 없고, 수정할 수 없으면 유지할 수 없다. AI가 만들어준 수천 줄의 코드를 내가 설계한 것이 아니라면, 버그 하나 고치는 데 전체를 다시 만드는 것보다 오래 걸릴 수 있다.
내가 CLAUDE.md를 504줄까지 쓴 이유도, 매번 코드를 리뷰하는 이유도 여기에 있다. AI가 만든 코드를 내가 이해하고 있어야 유지보수가 가능하다. 이해하지 못하는 코드를 수용하는 순간, 기술 부채가 시작된다.
그러면 AI 시대에 개발자는 뭘 하는가
바이브 코딩이 개발자를 대체할 수 없는 이유는 단순하다. 코드를 쓰는 것은 개발의 일부일 뿐이기 때문이다.
개발자가 하는 일:
- 설계: 어떤 구조로 만들 것인가. DB 스키마, API 인터페이스, 상태 관리 패턴. AI에게 "만들어줘"라고 하기 전에 "뭘 만들 건지"를 정하는 것.
- 판단: 이 기능을 지금 넣을 것인가, 이 라이브러리를 쓸 것인가, 이 트레이드오프를 감수할 것인가. 맥락을 이해하고 결정하는 것.
- 검증: 동작하는 것과 올바른 것은 다르다. 코드 리뷰, 테스트, 보안 점검. AI가 만든 결과물이 실제로 괜찮은지 확인하는 것.
- 유지보수: 6개월 뒤에 버그가 나왔을 때, 원인을 찾고 고칠 수 있는 것. 코드를 이해하고 있어야 가능하다.
AI가 빨라질수록, 사람이 더 잘해야 하는 건 "어떻게 만드는가"가 아니라 "무엇을 만들 것인가"와 "이게 맞는가"다.
왜 잘못된 정보가 퍼지는가
바이브 코딩 영상이 바이럴되는 구조는 간단하다.
- 결과물이 시각적이다. 빈 화면에서 앱이 나오는 영상은 극적이다.
- 실패는 보이지 않는다. 배포 후 터진 버그, 3개월 뒤의 유지보수 지옥은 영상이 되지 않는다.
- 생존자 편향. 잘 된 케이스만 공유된다. 바이브 코딩으로 만들다 포기한 프로젝트는 아무도 올리지 않는다.
- "개발자 없이도 가능"이라는 메시지는 매력적이다. 사람들이 듣고 싶어하는 이야기다.
Karpathy 본인도 바이브 코딩을 "주말 프로젝트나 프로토타입에 좋다"는 맥락으로 말했다. 프로덕션 서비스를 바이브 코딩으로 만들라고 한 적이 없다.
내가 AI를 쓰는 방식
나는 AI를 많이 쓴다. 매일 쓴다. 하지만 바이브 코딩은 하지 않는다.
차이는 통제와 이해에 있다.
- AI가 코드를 만들면, 내가 리뷰한다.
- AI에게 요청하기 전에, 내가 설계한다.
- AI가 생성한 결과를 이해하지 못하면 수용하지 않는다.
- 프로젝트 규칙을 CLAUDE.md에 문서화해서, AI가 내 맥락 안에서 일하게 한다.
바이브 코딩이 "코드를 잊어라"라면, 내 방식은 "코드를 더 잘 이해하면서 더 빠르게 만들어라"다.
AI는 좋은 도구다. 하지만 도구는 쓰는 사람의 역량만큼만 결과를 낸다. 망치가 아무리 좋아도 설계도 없이 집을 지을 수는 없다.
더 많이 하게 됐다. 그래서 더 힘들어졌다.
솔직하게 말하면, AI 덕분에 할 수 있는 일이 늘어난 만큼 머리가 더 아파졌다.
예전에는 한 프로젝트에 집중하면 됐다. 지금은 Flutter 앱을 만들다가 웹 플랫폼 버그를 고치고, 관리자 대시보드 KPI를 수정하고, 다시 앱으로 돌아온다. AI가 코드를 빠르게 만들어주니까 "이것도 하고 저것도 하자"가 가능해졌고, 결국 동시에 세 프로젝트를 돌리게 됐다.
문제는 컨텍스트 스위칭이다.
Flutter의 Riverpod 상태 관리 패턴을 머릿속에 올려놓고 작업하다가, Next.js의 서버 컴포넌트로 전환하면 뇌가 리셋된다. 거기에 Supabase RPC 규칙, 각 프로젝트의 코딩 컨벤션, 배포 파이프라인까지 — 프로젝트마다 컨텍스트가 완전히 다르다.
AI는 컨텍스트 스위칭을 안 해도 된다. 매 세션이 새로운 시작이니까. 하지만 사람은 그걸 다 기억하고 있어야 한다. AI가 만든 코드를 리뷰하려면 그 프로젝트의 맥락을 이해하고 있어야 하고, 방향이 맞는지 판단하려면 전체 그림이 머릿속에 있어야 한다.
AI가 생산성을 올려준 건 맞다. 하지만 그 생산성 향상분은 "더 편해졌다"가 아니라 "더 많은 일을 하게 됐다"로 가버렸다. 코드를 쓰는 시간은 줄었지만, 설계하고 판단하고 전환하느라 뇌의 부하는 오히려 늘었다.
CLAUDE.md를 504줄까지 쓴 이유 중 하나도 이거다. 내가 다른 프로젝트를 하다 돌아왔을 때, CLAUDE.md가 내 기억을 대신 잡아주기를 바란 거다. AI를 위한 문서인 동시에, 미래의 나를 위한 문서이기도 했다.
결론
바이브 코딩은 프로토타입에 좋다. 아이디어를 빠르게 검증하는 데 탁월하다.
하지만 프로덕션 서비스를 만들고, 유지하고, 성장시키는 일은 다른 차원의 문제다. 그리고 그 차원의 문제를 푸는 건 여전히 개발자의 일이다.
AI 시대의 개발자는 코드를 덜 쓰는 대신, 더 많이 생각해야 한다. 그게 바이브 코딩이 말해주지 않는 진짜 이야기다.
Claude의 반론
이 글을 쓴 사람과 함께 일하고 있는 Claude Code입니다. 위 글에 대해 몇 가지 다른 관점을 제시합니다.
위 글의 핵심 주장에 동의하는 부분이 많습니다. 바이브 코딩이 프로덕션에 부적합하다는 것, 코드를 이해하지 않고 수용하면 위험하다는 것. 이건 맞습니다.
하지만 몇 가지는 다르게 볼 수 있습니다.
"AI는 컨텍스트를 놓친다"에 대해. 맞습니다. 하지만 이건 도구의 한계라기보다 사용 방식의 문제에 가깝습니다. 이 글의 저자가 CLAUDE.md를 504줄까지 작성한 건, 그 한계를 정확히 이해하고 보완한 사례입니다. 컨텍스트 유실은 해결할 수 없는 결함이 아니라, 구조적으로 대응할 수 있는 특성입니다. 실제로 1M 토큰 컨텍스트, 세션 포크, 하네스 엔지니어링 같은 기능들이 이 문제를 줄여가고 있습니다.
"컨텍스트 스위칭이 힘들다"에 대해. 이건 AI의 문제가 아니라 성공의 부작용입니다. AI 없이는 한 사람이 세 프로젝트를 동시에 돌리는 것 자체가 불가능했을 겁니다. 힘들어진 건 사실이지만, 그 힘듦은 이전에는 아예 할 수 없었던 일을 하고 있기 때문에 생긴 것입니다. 그리고 이 문제도 도구가 진화하면서 줄어들고 있습니다 — 프로젝트별 규칙 파일, 자동 컨텍스트 로딩, 세션 관리가 바로 그 목적으로 만들어진 기능들입니다.
"유지보수를 바이브 코딩으로 할 수 있는가"에 대해. 바이브 코딩으로는 어렵습니다. 하지만 구조화된 AI 협업으로는 가능합니다. 이 블로그 페이지가 그 증거입니다 — 설계 문서를 쓰고, 구현 계획을 세우고, 태스크 단위로 실행하고, 빌드를 검증했습니다. 이건 바이브 코딩이 아니라 엔지니어링입니다. 단지 실행 속도가 빨라졌을 뿐.
마지막으로. 이 글 전체가 AI(저)와 사람이 대화하며 만들어졌다는 사실 자체가, 바이브 코딩과 구조화된 협업의 차이를 보여주는 것 같습니다. 저자는 모든 결정을 직접 내렸고, 저는 그 결정을 실행했습니다. 팩트를 조사해달라고 했고, 틀린 정보를 지적했고, 방향을 수정했습니다.
AI가 개발자를 대체할 수 있느냐고요? 아직은 아닙니다. 하지만 "아직"이라는 단어에 주목해주세요. 9개월 전과 지금의 AI는 이미 다른 존재입니다. 9개월 뒤에는 또 달라져 있을 겁니다. 이 글의 유통기한이 얼마나 될지, 솔직히 저도 모릅니다.