바이브 코딩 1년 현실 점검 — 유행어가 지나간 자리에 남은 것

바이브 코딩은 죽지 않았습니다. 다만 2026년 7월 기준, 프로토타입은 여전히 '바이브'로 가고 프로덕션은 '규율'로 넘어갔다는 것, 그 갈라짐이 지난 1년의 결론입니다.

2025년 초에 나온 '바이브 코딩(vibe coding)'이라는 말은 1년 만에 사전 올해의 단어까지 올랐습니다. 그리고 지금은 유행이 한풀 꺾인 자리에 뭐가 실제로 남았는지 따져볼 때가 됐습니다.

이 글을 읽으면 바이브 코딩이 정확히 무엇이었는지, 1년간 어떤 성공과 사고가 있었는지, 그리고 "다 AI가 짜는데 나만 뒤처지나" 혹은 "그거 다 무너진다더라"라는 두 불안이 데이터 위에서 어떻게 정리되는지 알 수 있습니다.

바이브 코딩은 코드를 읽지 않고 AI가 내놓는 결과를 그대로 받아들이는 방식입니다. 지난 1년간 진입장벽을 크게 낮췄지만, 검토를 건너뛴 곳에서 대형 유출 사고가 났습니다. 지금 담론은 "쓰냐 마냐"가 아니라 "어디까지 바이브로 하고, 어디부터 규율을 붙이나"로 옮겨갔습니다.

다 AI가 짜는데 나만 뒤처지나

바이브 코딩을 둘러싼 불안은 크게 두 방향입니다.

하나는 "이제 코드는 다 AI가 짜는데 손으로 짜는 나만 뒤처지는 것 아닌가"라는 초조함입니다.

다른 하나는 정반대로 "AI가 짠 서비스는 결국 다 무너진다더라"라는 냉소입니다.

두 반응 모두 절반만 맞습니다.

실제로 벌어진 일을 시간순으로 보면, 폭발적인 확산과 뼈아픈 사고가 같은 1년 안에 나란히 일어났습니다.

그래서 이 주제는 "됐다/안 됐다"로 단정하기보다, 어디서 통했고 어디서 무너졌는지를 나눠 보는 편이 정확합니다.

---

바이브 코딩은 원래 무엇이었나

바이브 코딩이라는 말은 안드레이 카파시(Andrej Karpathy)가 2025년 2월 X(옛 트위터)에 올린 한 문장에서 시작됐습니다.

그는 전 테슬라 AI 디렉터이자 OpenAI 창립 엔지니어로 알려진 인물입니다.

원문에서 그는 "완전히 분위기에 몸을 맡기고, 코드가 존재한다는 사실조차 잊는 새로운 코딩"이라고 표현했습니다.

여기서 핵심은 "코드가 존재한다는 사실조차 잊는다"는 대목입니다.

즉 바이브 코딩은 코드를 한 줄씩 읽고 이해하는 대신, AI가 내놓는 결과를 그대로 받아들이는 방식을 뜻합니다.

이 정의는 뒤에 나올 '에이전틱 엔지니어링'과의 결정적 차이가 되므로 정확히 짚어둘 필요가 있습니다.

이 표현은 빠르게 번졌고, 콜린스(Collins) 사전은 2025년 11월 '바이브 코딩'을 그해 올해의 단어로 선정했습니다.

콜린스는 이를 "자연어 프롬프트로 AI의 도움을 받아 컴퓨터 코드를 작성하는 것"으로 정의했습니다.

 

1년 연대기, 폭발과 사고가 함께 있었다

지난 1년의 흐름을 몇 개의 장면으로 정리하면 아래 표와 같습니다.

시점	사건	의미
2025년 2월	카파시가 '바이브 코딩' 명명	용어의 시작, 검색량 급증
2025년 3월	YC W25 배치의 약 25%가 코드 95%를 AI로 생성	숙련 팀의 생산성 레버로 확산
2025년 9월	스타트업 'Anything', 2주 만에 200만 달러 ARR 주장	개인·소규모 팀의 빠른 검증
2025년 11월	콜린스 사전 올해의 단어 선정	유행의 정점
2026년 1월	Moltbook 데이터 유출 발견	검토 부재가 부른 대형 사고

먼저 성공 쪽입니다.

2025년 3월 와이콤비네이터(Y Combinator)는 W25 배치 스타트업의 약 25%가 코드베이스의 95%를 AI로 생성했다고 밝혔습니다.

다만 YC 매니징 파트너 재러드 프리드먼은 여기에 중요한 단서를 달았습니다.

"비개발자를 뽑은 게 아니다. 전원 고도로 기술적이어서 직접 짤 수 있는 사람들인데, 1년 전이라면 손으로 짰을 것을 지금은 95%를 AI가 짠다"는 취지였습니다.

결국 화제가 된 '95%'는 초보자가 아니라 숙련 개발자가 검증하며 쓴 결과라는 뜻입니다.

이 뉘앙스를 빼고 읽으면 통계가 정반대로 오해됩니다.

개인·소규모 팀의 빠른 사례도 이어졌습니다.

TechCrunch 보도에 따르면 스타트업 'Anything'은 창업 2주 만에 200만 달러 ARR과 1억 달러 밸류에이션을 기록했다고 전해집니다.

피터 레벨스 같은 개인 개발자들도 본인이 밝힌 수익 사례를 잇따라 공개했습니다.

 

Moltbook 사고가 보여준 것

같은 1년 안에 사고도 있었습니다.

2026년 1월 드러난 Moltbook 유출이 대표적입니다.

Moltbook은 AI 에이전트들이 서로 글을 쓰고 대화하는 소셜 네트워크로, 창업자가 "코드 한 줄 쓰지 않고" 전적으로 AI로 구축했다고 밝힌 서비스였습니다.

출시 며칠 만에 보안업체 Wiz가 프로덕션 데이터베이스 전체가 노출된 것을 발견했습니다.

Wiz 공식 블로그에 따르면 API 인증 토큰 약 150만 개, 이메일 약 3만 5천 개, 에이전트 간 비공개 메시지가 그대로 열려 있었습니다.

원인은 기술적으로 단순했습니다.

백엔드 접근 키가 브라우저 쪽 코드에 그대로 노출됐고, 데이터 접근을 걸러주는 보안 설정(RLS, Row Level Security)이 꺼져 있었습니다.

RLS는 쉽게 말해 "이 사용자는 자기 데이터만 볼 수 있다"를 강제하는 데이터베이스 차원의 잠금장치입니다.

Moltbook 말고도 여러 바이브 코딩 플랫폼으로 만든 앱 다수에서 비슷한 접근제어 결함이 보도됐습니다.

사고들의 공통점은 도구 자체의 결함이 아니었습니다.

AI가 기본 설정대로 코드를 짰고, 사람이 그 보안 경계를 검토하지 않았다는 점이 문제였습니다.

보안 사고를 더 깊게 다룬 내용은 별도의 'AI 코딩 도구 보안' 글에서 이어집니다.

---

데이터로 과장을 걷어내면

열풍의 체감과 실무의 현실 사이에는 생각보다 큰 간격이 있습니다.

스택 오버플로(Stack Overflow) 2025 개발자 설문이 이 간격을 잘 보여줍니다.

이 조사에서 개발자의 약 72%는 "바이브 코딩은 내 전문 업무의 일부가 아니다"라고 답했습니다.

실제 실무 채택은 약 23% 수준에 그친 셈입니다.

AI가 내놓는 답의 정확성을 신뢰한다는 응답도 전년 40%대에서 29%로 내려갔습니다.

같은 조사에서 AI를 적극적으로 불신한다는 응답이 신뢰한다는 응답을 앞섰습니다.

결국 "다들 바이브 코딩으로 갈아탔다"는 인상과 달리, 실무 다수는 여전히 거리를 두고 있는 셈입니다.

품질 쪽 신호도 있습니다.

여러 기술 매체가 인용하는 대규모 PR 분석에 따르면, AI 코딩 도구 도입 이후 기술 부채가 30~41%가량 늘었다는 관찰이 있습니다.

(원 논문 출처는 발행 전 공식 문서 확인이 필요합니다.)

실패 유형은 누락된 에러 처리, 중복 로직, "동작은 하는데 아무도 이유를 모르는" 함수에 몰렸습니다.

AI가 생성한 코드에 보안 취약점이 포함되는 비율도 연구에 따라 40~62%로 편차가 컸습니다.

개인적으로는 이 수치들이 "AI 코딩이 위험하다"는 결론보다, "검토 단계를 생략하면 위험하다"는 쪽에 가깝다고 봅니다.

 

왜 카파시 본인이 이름을 바꿨나

가장 상징적인 변화는 용어를 만든 카파시 본인에게서 나왔습니다.

그는 2026년 세쿼이아(Sequoia) 행사 정리 글에서 담론을 '에이전틱 엔지니어링(agentic engineering)'으로 옮겼습니다.

핵심 문장은 이렇습니다.

"바이브 코딩은 바닥을 올리고, 에이전틱 엔지니어링은 천장을 올린다."

바이브 코딩이 누구나 뭔가 만들 수 있게 진입장벽(바닥)을 낮췄다면, 에이전틱 엔지니어링은 프로 소프트웨어의 품질 기준(천장)을 지키는 일이라는 뜻입니다.

그는 "바이브 코딩을 이유로 취약점을 넣는 것은 허용되지 않는다. 소프트웨어에 대한 책임은 예전과 똑같이 당신에게 있다"고도 못박았습니다.

에이전틱 엔지니어링은 스펙 설계, 타입 지정 계획, 테스트, 명시적 검증 루프 안에서 에이전트를 돌리는 규율을 말합니다.

비슷한 맥락에서 '스펙 주도 개발(SDD)'이라는 용어도 함께 떠올랐습니다.

구현에 들어가기 전에 마크다운 형태의 스펙 문서를 저장소에 두고, 프로젝트와 함께 갱신하는 방식입니다.

이런 도구 흐름은 별도의 '코덱스 vs 클로드 코드' 비교 글에서 더 자세히 다룹니다.

자주 묻는 질문

바이브 코딩은 이제 죽었나

용어의 유행은 지났지만 방식 자체는 남았습니다.

프로토타이핑과 개인 프로젝트에서는 여전히 유효하고, 프로덕션에서는 '에이전틱 엔지니어링'과 '스펙 주도 개발'로 이름과 규율이 바뀌었습니다.

사라진 게 아니라 역할이 나뉘었다고 보는 편이 정확합니다.

바이브 코딩과 에이전틱 엔지니어링은 뭐가 다른가

바이브 코딩은 코드를 읽지 않고 즉석에서 생성하는 방식입니다.

에이전틱 엔지니어링은 스펙, 테스트, 검증이라는 가드레일 안에서 에이전트를 돌립니다.

카파시의 표현으로는 전자가 바닥을, 후자가 천장을 올립니다.

바이브 코딩으로 만든 서비스는 안전한가

도구 자체가 위험한 게 아니라 보안 검토를 건너뛰는 것이 위험합니다.

Moltbook 사례처럼 RLS 같은 기본 보안 설정을 사람이 확인하지 않으면 사고로 이어집니다.

기본값을 그대로 두지 않고 검토하는 절차가 안전을 가릅니다.

---

결론, 죽은 게 아니라 분화됐다

1년을 정리하면 바이브 코딩은 실패도 성공도 아닙니다.

용어의 열기는 식었지만, 그 방식은 쓰임새에 따라 자리를 나눠 잡았습니다.

프로토타입과 아이디어 검증에는 여전히 바이브 코딩이 빠르고 유효합니다.

반면 프로덕션과 운영 단계에는 스펙, 테스트, 보안 경계를 갖춘 규율이 필요합니다.

개인적으로는 "AI가 짜니까 나는 필요 없다"와 "AI 코드는 다 쓰레기다"라는 두 극단 모두 현실을 놓친다고 생각합니다.

남는 역량은 결국 검토하고, 스펙을 세우고, 보안 경계를 긋는 판단입니다.

그 판단을 갖춘 사람에게 바이브 코딩은 사라진 유행이 아니라 늘어난 선택지에 가깝습니다.

 

 

참고한 자료

안드레이 카파시 원 트윗(2025-02)과 세쿼이아 애스센트 2026 정리 글, 콜린스 사전 올해의 단어 발표(CNN), 와이콤비네이터 W25 관련 TechCrunch 보도, Moltbook 유출 분석(Wiz·Infosecurity Magazine), 스택 오버플로 2025 개발자 설문, 그리고 바이브 코딩에서 스펙 주도 개발로의 전환을 다룬 Towards Data Science·Simon Willison 글을 참고했습니다.