바이브코딩, 1년의 기록 — 열광과 현실, 그리고 다음 단계
2025년 올해의 단어로 선정된 바이브코딩. 검색량 6,700% 폭증 이후 1년, 현장에서 실제로 무슨 일이 벌어졌는지 데이터와 사례로 정리합니다. 보안 취약점 45%, 코드 중복 8배, 창시자의 고백까지.
윤성열
프렌티스 대표이사, 공학박사
2026년 3월 16일
바이브코딩, 1년의 기록
2025년, Collins English Dictionary는 “vibe coding”을 올해의 단어로 선정했습니다.1 검색량은 6,700% 폭증했고, “코딩을 몰라도 앱을 만들 수 있다”는 기대감이 업계를 휩쓸었습니다.2
1년이 지난 지금, 현장의 답은 어떨까요? 결론부터 말하면, 바이브코딩은 죽지 않았지만 진화해야 했습니다. 이 글에서는 데이터와 현장 경험을 바탕으로, 바이브코딩의 빛과 그림자, 그리고 다음 단계를 정리합니다.
바이브코딩이란
2025년 2월, OpenAI 공동 창업자 Andrej Karpathy가 X(구 Twitter)에 이렇게 썼습니다.
“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.”3
번역하면 “느낌에 몸을 맡기고, 코드의 존재 자체를 잊어버리는 새로운 방식의 코딩”입니다. AI에게 자연어로 지시하면 코드가 나오고, diff를 확인하지 않고 수락하며, 에러가 나면 에러 메시지를 그대로 AI에 전달하는 방식입니다.
기존 코딩과 비교하면 차이가 명확합니다.
| 구분 | 기존 코딩 | 바이브코딩 |
|---|---|---|
| 코드 작성 | 개발자가 직접 타이핑 | AI가 생성, 개발자가 수락 |
| 디버깅 | 코드를 읽고 원인 분석 | 에러 메시지를 AI에 전달 |
| 설계 | 아키텍처를 먼저 설계 | 자연어로 의도만 전달 |
| 속도 | 숙련도에 비례 | 프롬프트 품질에 비례 |
| 검증 | 테스트 + 코드 리뷰 | ”돌아가면 OK” |
이 방식이 주목받은 이유는 분명합니다. 빠릅니다. 프로토타입을 하루 만에 만들 수 있고, 코딩 경험이 없는 기획자도 아이디어를 실체화할 수 있습니다. 한국에서 열린 바이브코딩 대회에서는 비개발자가 대다수 수상하기도 했습니다.4
왜 이렇게 열광했나
Stack Overflow 2025 개발자 서베이에 따르면, 전 세계 개발자의 84%가 AI 코딩 도구를 사용하거나 사용할 계획이라고 답했습니다. 2024년의 76%에서 크게 올랐습니다.5 전문 개발자의 51%는 매일 AI 도구에 의존하고 있습니다.
도구 시장도 급변했습니다. Cursor가 100만 사용자를 돌파했고, Claude Code는 출시 8개월 만에 개발자 선호도 1위(46%)를 차지했습니다.6 GitHub Copilot은 2,000만 사용자를 넘겼지만, 개발자 호감도에서는 9%로 밀렸습니다.
이 열광에는 이유가 있었습니다. 실제로 보일러플레이트 코드, CRUD API, 문서 작성 같은 반복 작업에서 생산성이 크게 올랐습니다. “코딩의 민주화”라는 표현까지 나왔습니다.
하지만 데이터가 보여주는 현실은 좀 달랐습니다.
현실: 숫자가 말하는 것
보안 — AI 코드의 45%가 취약
Veracode의 2025년 GenAI Code Security Report는 충격적입니다. AI가 생성한 코드의 45%가 보안 취약점을 포함하고 있었습니다.7
더 문제적인 발견이 있습니다. AI에게 수정을 반복 요청할수록 보안이 더 나빠진다는 것입니다. IEEE-ISTAS 2025 연구에 따르면, 5회 반복 수정 후 취약점이 37.6% 증가했습니다.
코드 품질 — 중복 8배, 유지보수 불가
GitClear는 Google, Microsoft, Meta 등의 211만 줄 코드 변경사항(2020-2024)을 분석했습니다.8 결과는 명확했습니다.
| 지표 | 변화 | 의미 |
|---|---|---|
| 코드 중복 블록 | 8배 증가 | 같은 코드가 여기저기 복사 |
| 초기 커밋 후 2주 내 수정 | +83% | 처음부터 잘못 만든 코드 |
| 리팩토링 비율 | 25%에서 10% 미만으로 감소 | 구조 개선 없이 양만 증가 |
GitClear의 분석은 이렇게 요약됩니다. “AI 도구 채택과 함께 코드 복제는 증가하고 리팩토링은 감소했다. 유지보수성을 희생하고 생산성을 우선시하는 패턴이다.”
개발자 신뢰 — 84%가 쓰지만 33%만 신뢰
가장 아이러니한 수치입니다.
Stack Overflow 서베이에서 AI 도구를 쓰는 개발자는 84%인데, 정확성을 신뢰한다고 답한 비율은 33%에 불과합니다.5 46%는 불신한다고 답했고, “높은 신뢰”는 3%뿐이었습니다.
개발자 66%는 “거의 맞지만 미묘하게 틀린” 경험에 불만을 표했습니다. 이 66%가 말하는 것은 단순한 에러가 아닙니다. 돌아가는 것 같은데 구석에 문제가 숨어 있는, 발견이 어려운 종류의 결함입니다.
창시자의 고백
이 데이터보다 더 인상적인 것은 Karpathy 본인의 행동입니다.
바이브코딩이라는 용어를 만든 바로 그 사람이, 자신의 프로젝트 nanochat(오픈소스 LLM 클라이언트, 약 8,000줄)을 전부 손으로 코딩했습니다.9
Gizmodo 인터뷰에서 그는 이렇게 말했습니다.
“Claude와 Codex 에이전트를 몇 번 시도했지만, 전혀 도움이 되지 않았다. 순 손실(net unhelpful)이었다.”
AI 평론가 Gary Marcus는 이 상황을 이렇게 논평했습니다.
“Andrej Karpathy, inventor of the term vibe coding, hand-coding.”10
Karpathy의 변명은 이렇습니다. 바이브코딩은 “버려지는 주말 프로젝트(throwaway weekend projects)“를 위한 것이었다고. 하지만 이 말은 처음부터 한 것이 아니라, nanochat 이후에 나온 것입니다.
이 에피소드가 보여주는 것은 분명합니다. 바이브코딩은 빠른 프로토타이핑에는 강력하지만, 품질이 중요한 소프트웨어에는 충분하지 않습니다.
바이브코딩은 죽었나?
Gary Marcus는 “Is vibe coding dying?”이라는 글에서 바이브코딩의 사용이 초기 폭증 이후 수개월간 감소 추세라고 지적했습니다.10 Java 창시자 James Gosling은 “프로젝트가 조금만 복잡해지면 뇌가 터진다”고 비판했습니다.11
하지만 바이브코딩이 죽었다고 보기는 어렵습니다. 84%가 쓰고 있고, 도구는 계속 발전하고 있습니다. 정확하게 말하면, 순수한 형태의 바이브코딩(“돌아가면 OK”)은 한계에 부딪혔고, 더 구조화된 형태로 진화하고 있습니다.
아래 타임라인이 이 1년의 흐름을 보여줍니다.
- Karpathy가 X에 'vibe coding' 포스트
- 검색량 6,700% 폭증
- Collins English Dictionary 올해의 단어 선정
- "누구나 개발자가 될 수 있다" 낙관론 확산
- Karpathy 본인이 nanochat 8,000줄 직접 코딩
- James Gosling: "조금만 복잡해지면 뇌가 터진다"
- Veracode: AI 코드 45% 보안 취약점
- GitClear: 코드 중복 8배 증가
- Gary Marcus: "바이브코딩 사용 감소 추세"
- 개발자 신뢰도 33%로 하락 (SO Survey)
- 코드 churn rate +83% (GitClear)
- 11% 프로젝트 완전 포기
- SDD(스펙 주도 개발) 산업 표준으로 수렴
- AWS Kiro, GitHub Spec-Kit 출시
- Claude Code 개발자 선호도 1위 (46%)
- "스펙이 있는 바이브코딩"으로 진화
다음 단계: 스펙이 있는 바이브코딩
Stack Overflow 블로그의 한 글 제목이 이 흐름을 잘 요약합니다. “Vibe coding needs a spec, too.”12
AWS의 VP Deepak Singh은 같은 글에서 이렇게 말했습니다. “80%의 Amazon 개발자가 AI 에이전트를 사용하지만, 복잡한 문제에서는 결국 명세를 작성하게 된다. 이것이 Kiro의 출발점이다.”
이 접근을 **스펙 주도 개발(Spec-Driven Development, SDD)**이라고 부릅니다. 바이브코딩의 속도를 유지하면서, 명세(Specification)로 품질을 보장하는 방식입니다.
2025년 하반기부터 업계가 이 방향으로 수렴하고 있습니다.
| 조직 | 도구 | 접근 |
|---|---|---|
| AWS | Kiro IDE13 | 요구사항/설계/작업 3단계 명세 |
| GitHub | Spec-Kit14 | 오픈소스 SDD 템플릿/CLI |
| Fission AI | OpenSpec | 기존 코드베이스 진화 중심 |
세 도구 모두 같은 원칙을 공유합니다. 코드를 쓰기 전에 무엇을 만들지 먼저 정의한다. 그리고 AI가 그 정의를 구현한다.
바이브코딩과 SDD의 차이를 SDLC 7단계로 비교하면 한눈에 보입니다.
바이브코딩은 7단계 중 구현(Implementation) 하나에만 강합니다. 계획, 설계, 유지보수는 커버하지 못합니다. SDD는 요구사항부터 유지보수까지 6단계를 커버합니다.
실전: 어디에 쓰고, 어디에 쓰지 말 것
바이브코딩을 완전히 버릴 필요는 없습니다. 상황에 따라 쓰는 것이 답입니다.
바이브코딩이 적합한 경우
- 프로토타입과 PoC: 아이디어를 빠르게 검증할 때
- 내부 도구: 사내 대시보드, 관리 페이지 등
- 학습과 실험: 새로운 프레임워크를 탐색할 때
- 반복적인 CRUD: 보일러플레이트 코드 생성
- 문서와 테스트: 문서 작성, 테스트 코드 생성
바이브코딩이 위험한 경우
- 금융/의료 시스템: 정확성과 감사 추적이 중요한 영역
- 보안 핵심 모듈: 인증, 암호화 (45% 취약점을 감안하면)
- 대규모 팀 프로젝트: 여러 사람이 유지보수할 코드
- 레거시 시스템: 복잡한 비즈니스 로직 이해가 필요한 경우
프롬프트가 곧 품질
바이브코딩을 쓰더라도 결과 품질은 프롬프트 품질에 비례합니다.
나쁜 프롬프트: “로그인 기능 추가해줘”
좋은 프롬프트: “이메일과 비밀번호로 로그인하는 기능을 추가해줘. bcrypt로 비밀번호를 해싱하고, JWT 토큰을 발급해줘. 토큰 유효기간은 24시간으로 설정하고, src/api/auth.ts에 라우트를 만들어줘.”
차이는 기술 선택, 보안 요구사항, 파일 위치의 명시 여부입니다. 좋은 프롬프트는 사실상 간이 명세서입니다. 그리고 그 명세서를 체계적으로 만드는 것이 바로 SDD입니다.
프렌티스의 접근
프렌티스는 바이브코딩을 부정하지 않습니다. 다만 “돌아가면 OK”에서 멈추지 않습니다.
필자가 17년간 소프트웨어 아키텍처를 설계하고, 8년간 기업 교육을 수행하면서 확인한 패턴은 일관적입니다. 도구를 깔아주는 것만으로는 부족합니다. 도구 위에 체계(스펙, 룰, 패턴)가 쌓여야 조직의 자산이 됩니다.
프렌티스의 Spectra 플랫폼은 이 체계를 자동화합니다. 명세를 작성하면 패턴이 축적되고, 팀 전체가 일관된 품질의 코드를 생성할 수 있습니다.
바이브코딩을 제대로 활용하고 싶다면, 프렌티스의 교육과정을 참고하세요.
| 과정 | 시간 | 대상 | 내용 |
|---|---|---|---|
| 바이브코딩 입문 with Claude Code | 8시간 | 개발자, 비개발자 | 설치부터 실전 프로젝트까지 |
| AI 기반 SW 방법론 | 8시간 | 개발자(3년 이상) | SDD, AI 워크플로우 설계 |
| AI-DLC 테크리더 | 4시간 | 아키텍트(5년 이상) | AI 기반 개발 생명주기 설계 |
| Cursor 활용 | 8시간 | 전 개발자 | IDE 기반 AI 코딩 실무 |