바이브 코딩

쉽게 말하면, 바이브 코딩은 코드를 한 줄씩 짜는 대신 만들고 싶은 것을 평범한 말로 AI에게 설명하고, AI가 만든 코드를 검토를 최소화하거나 아예 하지 않은 채 실행해 보며 고쳐 나가는 개발 방식이다. 2025년 2월 안드레이 카파시가 이 말을 처음 쓴 뒤 빠르게 퍼졌다. 시제품이나 개인용 도구를 빨리 만들 수 있지만, 빠른 만큼 취약하다는 지적도 받는다.

1. 정의

바이브 코딩(vibe coding)은 프로그래머가 의도를 일상 언어로 설명하고, 소스 코드 생성을 대규모 언어 모델(LLM)에 맡기는 소프트웨어 개발 방식이다. 개발자는 코드를 한 줄씩 쓰지 않고 대화형 프롬프트로 AI를 이끌며, 결과물을 최소한으로 검토하거나 전혀 검토하지 않고 받아들인다. 오류가 나면 피드백을 주거나 오류 메시지를 그대로 모델에 붙여 넣어 반복한다.

이 용어는 2025년 2월 2일 안드레이 카파시(Andrej Karpathy)가 X(구 트위터)에 올린 글에서 처음 쓰였으며, 이 글은 조회 수 450만 회를 넘겼다. 위키피디아 편집자들은 용어가 생긴 지 몇 주 만에 이 실천 방식을 다룬 문서를 따로 만들었다.²

바이브 코딩은 AI 보조 프로그래밍의 한쪽 끝에 놓인다. 반대쪽 끝에서는 개발자가 LLM을 정교한 자동 완성 도구처럼 쓰면서 생성된 코드를 한 줄씩 검토한다. 가장 순수한 형태에서는 개발자가 코드를 전혀 읽지 않고, 상위 수준의 설명만으로 AI가 동작하는 소프트웨어를 만들어 주리라 믿는다.

2025년에는 이 방식이 상업적으로 빠르게 성장했다. Cursor는 2025년 6월까지 ARR(연간 반복 매출) 5억 달러를 넘었고, Lovable은 정식 공개 후 1년 안에 ARR 2억 달러에 이르렀으며, Bolt.new는 2024년 10월 출시 후 5개월 만에 ARR 4,000만 달러에 도달했다. 2025년 말 주요 바이브 코딩 도구 다섯 종을 조사한 보안 연구에서는 테스트 앱 15개에서 취약점 69개가 나왔다. 이는 이 방식의 빠른 속도와 취약성을 함께 보여 준다.^3,4,5,6

2. 개발 배경

바이브 코딩은 개발자와 코드의 관계를 뒤집는다. 전통적인 소프트웨어 공학에서 프로그래머는 모든 줄의 작성자이고, AI를 쓰더라도 주니어 보조 역할에 머문다. 바이브 코딩에서는 AI가 작성자가 되고, 사람은 제품 관리자처럼 원하는 동작을 설명한 뒤 모델이 내놓은 구현을 받아들인다. 카파시는 이 방식을 “무언가를 보고, 무언가를 말하고, 무언가를 실행하고, 무언가를 복사해 붙여 넣는 것”으로 요약했다. 프로그래밍이 시작된 이래 이어진 ‘이해 우선’ 모델을 의도적으로 거부하는 셈이다.²

이 표현이 실제 행동 변화를 잡아낸 배경에는 기반 모델이 쓸 만한 수준에 올라선 점이 있다. 2025년 초 Claude 3.5 Sonnet, GPT-4o 같은 최상위 LLM은 짧은 프롬프트만으로 여러 파일로 된 동작하는 앱을 만들 수 있었고, React, Next.js, Supabase, Tailwind로 짠 웹 스택에서 특히 그랬다. Claude Code, Replit Agent, Devin, OpenAI Codex CLI, Cursor Composer 같은 코딩 에이전트는 모델이 저장소를 읽고, 셸 명령을 실행하고, 패키지를 설치하고, 사람의 개입 없이 단계마다 테스트를 돌리게 했다. 바이브 코딩은 이런 도구를 최대치로 쓰는 경험을 가리키는 문화적 이름이 되었다.

3. 용어의 기원

2025년 2월 2일 안드레이 카파시(Andrej Karpathy)는 OpenAI 공동 창립자이자 테슬라의 전 AI 선임 디렉터로서 X에 글을 올렸다. 그는 AI가 만든 코드의 차이점(diff)을 더 읽지 않고 모두 수락(Accept All)하는 방식을 “바이브 코딩”이라 부르며, 주말 프로젝트 정도에는 괜찮다고 썼다. 오류 메시지는 설명 없이 그대로 붙여 넣고, 사이드바 여백을 절반으로 줄이라는 식의 사소한 수정도 음성으로 요청한다고 밝혔다.

이 글에는 제품 두 가지가 나온다. 하나는 Anysphere가 만든 코드 편집기 Cursor의 에이전트 모드인 Cursor Composer로, Claude 3.5 Sonnet과 함께 썼다. 다른 하나는 macOS용 음성 텍스트 변환 앱 SuperWhisper다. 이 조합은 2025년 상반기 바이브 코딩의 대표 구성이었다. 카파시의 설명에는 여러 파일에 걸친 코드를 생성하는 모델, 그 결과를 프로젝트 전체에 적용하는 편집기, 의도를 설명하는 부담을 줄여 주는 음성 입력이라는 세 조건이 깔려 있다.²

카파시는 나중에 이 트윗이 퍼진 일을 두고 생각이 쏟아지는 중에 가볍게 던진 글이라고 말했다. 17년 동안 플랫폼을 써 왔지만 어떤 글이 반응을 얻을지는 여전히 예측하지 못했다고 덧붙였다. 이 글은 많은 개발자가 이미 겪고 있었지만 이름이 없던 현상에 이름을 붙였다. 2026년 2월 2일, 최초 게시일로부터 정확히 1년 뒤 카파시는 1주년을 기념하는 다른 글에서 이 용어가 업계 어휘에 얼마나 깊이 자리 잡았는지 짚었다.⁷

개념의 뿌리는 더 깊다. 카파시는 2023년 “가장 뜨거운 새 프로그래밍 언어는 영어”라고 주장했는데, LLM이 발전하면 사람이 특정 프로그래밍 언어를 배우지 않고도 컴퓨터에 지시할 수 있게 될 수 있다는 뜻이었다. 그 전에도 사이먼 윌리슨(Simon Willison)의 2023년 ‘AI 보조 프로그래밍’ 글, 2022년 Replit Ghostwriter, 2021년 GitHub Copilot 같은 시도가 있었지만 하나로 굳은 이름은 없었다. 카파시의 트윗이 그 이름을 제공했다.⁸

2025년 11월 콜린스 사전(Collins Dictionary)은 “바이브 코딩”을 올해의 단어로 골랐다. 사전은 이를 자연어 프롬프트로 인공지능의 도움을 받아 컴퓨터 코드를 작성하는 일이라고 정의했다. 이 선정은 이 개념이 소프트웨어 공학 커뮤니티를 넘어 퍼졌음을 보여 준다. 메리엄-웹스터(Merriam-Webster)는 2025년 3월 속어·트렌드 목록에 이 말을 올렸는데, 카파시의 트윗이 나온 지 몇 주 만이어서 기술 신조어가 사전에 오른 속도로는 최근 드물게 빨랐다.⁹

4. 실제 작업 방식

바이브 코딩의 작업 흐름은 전통적인 프로그래밍과 여러 면에서 다르다. 텍스트 편집기를 열고 문법을 한 글자씩 입력하는 대신, AI 기반 코딩 환경을 열고 일상 언어로 원하는 바를 설명한다.¹⁰

4.1. 기본 작업 흐름

• 목표를 설명한다. 개발자는 원하는 소프트웨어를 글로 쓰거나 SuperWhisper 같은 도구로 말한다. “검색창이 있는 레시피 웹사이트를 만들어 줘”처럼 큰 요구도 되고, “사이드바 여백을 절반으로 줄여 줘”처럼 구체적인 요청도 된다.
• AI가 코드를 만든다. LLM이 프롬프트를 해석해 소스 코드를 생성한다. 결과물은 여러 파일에 걸치는 경우가 많고, 상황에 따라 HTML, CSS, JavaScript, Python 등 어떤 언어로도 나온다.
• 받아들이고 실행한다. 순수한 바이브 코딩에서는 차이점을 읽거나 줄 단위로 검토하지 않고 결과를 받아들인다. 개발자는 앱을 실행해 제대로 되는지만 본다.
• 피드백으로 반복한다. 결과가 맞지 않으면 문제를 자연어로 설명하거나 오류 메시지를 그대로 AI에 붙여 넣는다. 모델이 이를 바탕으로 코드를 고친다.
• 필요가 채워질 때까지 반복한다. 이 주기는 소프트웨어가 개발자의 필요를 충족할 때까지 이어지며, 어느 시점에도 개발자가 기저 코드를 자세히 이해할 필요는 없다.

카파시는 원래 트윗에서 SuperWhisper라는 음성 텍스트 변환 도구로 AI와 대화한다고 밝혔다. 프롬프트를 타이핑하지 않고 소리 내어 말하면 작업은 동료와 대화하는 느낌에 가까워진다. 이후 Whisper Flow, Aiko, ChatGPT와 Claude의 음성 모드 같은 제품이 같은 방식을 더 넓은 사용자에게 퍼뜨렸다.²

4.2. 정의 조건

사이먼 윌리슨(Simon Willison)은 2025년 3월 글 「Not all AI-assisted programming is vibe coding」에서 가장 명확한 정의를 내놓았다. 바이브 코딩이 성립하려면 세 조건이 필요하다. LLM이 코드를 쓰고, 개발자가 결과를 읽거나 검토하지 않으며, 개발자가 그 코드를 다른 사람에게 제대로 설명할 수 없어야 한다. 이 중 하나라도 어긋나면 그 활동은 보통 AI 보조 개발이지 바이브 코딩이 아니다.¹¹

이 방식에는 공통된 행동 패턴도 있다. 개발자는 대안을 요청하지 않고 AI의 첫 답을 받아들이며, 원인을 분석하지 않고 원시 오류 메시지를 그대로 붙여 넣는다. 원인을 진단하기보다 증상을 설명하며 고치고, 테스트는 거의 추가하지 않는다. 실행이 한 번 성공하면 코드가 맞다고 여기지만, 그 정확성이 실행되지 않은 예외 상황에 달려 있을 때도 마찬가지다. 이런 습관이 합쳐져 신뢰성과 이해보다 속도와 탐색을 중시하는 작업 방식이 된다.

4.3. 전통 프로그래밍과의 비교

5. 바이브 코딩을 가능하게 하는 도구

여러 범주의 도구가 바이브 코딩을 실용적으로 만들었다. AI 강화 코드 편집기부터 완전 관리형 앱 제작 플랫폼까지 범위가 넓다.

5.1. AI 코드 편집기

5.2. 앱 빌더 플랫폼

5.3. 뒷받침 기술

• 대규모 언어 모델: Claude, GPT-4 등이 코드 생성 능력을 제공한다. 모델의 추론과 문맥 처리가 나아지며 바이브 코딩이 점점 현실성을 얻었다. SWE-bench Verified 통과율은 2023년 한 자릿수에서 2026년 초 주요 시스템 전반 75% 이상으로 올랐다.
• 컨텍스트 창: 더 큰 컨텍스트 창(context window) 덕분에 AI 도구가 단일 파일이 아닌 코드베이스 전체를 처리해 여러 파일을 일관되게 바꿀 수 있다. 앤트로픽이 Claude에 제공한 100만 토큰 컨텍스트 창과 2025년 OpenAI의 맞먹는 용량으로 저장소 전체를 프롬프트 하나에 넣는 일이 현실적이 되었다.
• 프롬프트 엔지니어링: 프롬프트 엔지니어링(prompt engineering)은 바이브 코딩에서 덜 강조되지만, 밑의 시스템은 여전히 잘 짜인 프롬프트에 기대어 쓸 만한 코드를 낸다. 도구 제작사들은 이 작업 대부분을 채팅 화면 뒤에 숨긴다.
• 모델 컨텍스트 프로토콜(MCP): 2024년 11월 앤트로픽이 발표한 MCP는 AI 도구가 데이터베이스, 문서 시스템, 개발 도구 같은 외부 문맥에 표준 방식으로 연결되게 한다. 2025년 말에는 Cursor, Claude Code, Windsurf, OpenAI Codex와 대부분의 주요 편집기가 이를 채택했다.
• WebContainers: StackBlitz의 브라우저 기반 실행 환경으로, Bolt.new를 구동한다. Node.js와 npm을 전부 클라이언트 쪽에서 실행해 서버를 거치지 않는 작업 흐름도 가능하다.
• 음성 입력 계층: SuperWhisper, Whisper Flow, Aiko, ChatGPT와 Claude의 음성 모드는 말로 하는 프롬프트를 지속적인 속도로 쓸 수 있게 한다.¹³

6. AI 보조 프로그래밍과의 차이

AI를 프로그래밍에 쓰는 모든 경우가 바이브 코딩인 것은 아니다. 사이먼 윌리슨(Simon Willison)은 2025년 3월 이 구분을 분명히 하며, 바이브 코딩이라는 말이 AI를 쓰는 개발 전체에 잘못 적용되고 있다고 주장했다.¹¹

6.1. 윌리슨의 기준

윌리슨의 경계는 이렇다. LLM이 모든 줄을 썼더라도 개발자가 코드를 검토하고 테스트했으며 다른 사람에게 작동 원리를 설명할 수 있다면, 그것은 AI의 도움을 받은 소프트웨어 개발이지 바이브 코딩이 아니다. 그의 정의에서 바이브 코딩은 AI가 쓴 코드를 검토하지 않고 소프트웨어를 만드는 일이다.

윌리슨이 내세운 프로덕션 수준 AI 보조 프로그래밍의 ‘황금률’은 다른 사람에게 설명할 수 없는 코드를 저장소에 커밋하지 않는 것이다.¹¹

6.2. AI 보조 수준

AI 보조 개발은 연속된 스펙트럼으로 볼 수 있다.

6.3. 바이브 엔지니어링으로의 진화

2025년 말 일부 실무자는 ‘바이브 엔지니어링(vibe engineering)’이라는 말로 중간 지점을 가리키기 시작했다. AI로 코드를 공격적으로 생성하되 아키텍처, 테스트, 배포에는 엔지니어링 규율을 유지해 바이브 코딩의 속도는 살리고 품질 함정은 피하려는 방식이다. 윌리슨은 2025년 10월 글에서 이 틀에 동의하며, 대응은 포기가 아니라 테스트, 버전 관리, 사람이나 별도 AI 리뷰어의 코드 검토라는 규율이라고 주장했다.

컨텍스트 엔지니어링(context engineering)도 2025년에 등장한 더 체계적인 흐름이다. MIT Technology Review는 업계가 2025년 초의 느슨한 ‘바이브’ 방식에서 AI가 컨텍스트를 처리하는 방법을 체계적으로 관리하는 쪽으로 옮겨 갔다고 설명했다. 이 실천은 모델이 알아서 맞는 결과를 내기를 바라는 대신, 매 단계에서 AI의 컨텍스트 창(context window)에 정확히 필요한 정보만 채우는 데 초점을 둔다. Cursor Rules, Claude Code의 CLAUDE.md 관례, AGENTS.md 커뮤니티 표준이 이를 공식화했다.¹³

7. 수혜 집단

바이브 코딩은 집단에 따라 다른 영향을 준다.

7.1. 비개발자

바이브 코딩의 가장 큰 영향은 소프트웨어 제작을 민주화할 잠재력이다. 프로그래밍 배경이 없는 사람도 일상 언어로 앱을 설명해 동작하는 코드를 받을 수 있다. 앤드루 응(Andrew Ng)은 구글 브레인 공동 창립자이자 바이두의 전 수석 과학자로, 코딩 문턱이 그 어느 때보다 낮아졌다고 말했다. 그는 소프트웨어 엔지니어뿐 아니라 CEO, 마케터, 채용 담당자처럼 코딩하는 사람이 코딩하지 않는 사람보다 더 많은 일을 해낼 것이라고 주장했고, DeepLearning.AI를 통해 Replit과 함께 비개발자를 위한 AI 에이전트 앱 제작 강좌를 만들었다.¹⁴

하버드 교육대학원(Harvard Graduate School of Education)의 카렌 브레넌(Karen Brennan) 교수는 2025년 말 바이브 코딩 강의를 열며 핵심 가치를 ‘실험의 경제학’이 바뀐 데서 찾았다. 작동하는 시제품을 석 달 대신 세 시간에 만들 수 있다면, 소프트웨어 아이디어를 시험해 볼 수 있는 사람의 범위가 몇 자릿수 단위로 늘어난다는 것이다.

7.2. 빠른 시제품 제작과 MVP

창업자와 제품 디자이너는 바이브 코딩으로 아이디어를 빨리 검증한다. 최소 기능 제품(MVP)을 몇 주 동안 만드는 대신 개념을 AI에 설명하고 몇 시간 안에 작동하는 시제품을 받을 수 있다. 현장 연구들에서는 바이브 코딩이 전통적 개발보다 시제품 제작을 60~80% 빠르게 한다는 결과가 제시되었다.¹⁵

2025년 3월 Y Combinator는 겨울 배치 스타트업의 25%가 코드베이스의 95%를 AI가 생성한 상태라고 보고했다. 재러드 프리드먼(Jared Friedman) 매니징 파트너는 이들이 매우 기술적인 창업자로, 처음부터 제품을 직접 만들 능력이 충분하지만 대부분의 코드를 AI에 맡기기로 선택한 사람들이라고 설명했다.¹⁶

CEO 개리 탄(Garry Tan)은 X에 2025년 겨울 배치 코드 줄의 95%가 LLM으로 생성됐다고 쓰면서, 이는 오타가 아니며 바이브 코딩 시대가 왔다는 뜻이라고 밝혔다. 탄은 바이브 코딩을 쓰는 엔지니어 10명이 과거 50~100명이 하던 일을 해낸다고도 말했다. 2025년 3월 CNBC 인터뷰에서는 이 배치를 Y Combinator 역사상 가장 빠르게 성장한 배치로 꼽고, 그 도약을 AI 보조 개발 덕분이라고 설명했다.¹⁷

7.3. 독립 개발자와 전문 개발자

독립 개발자도 바이브 코딩으로 큰 역량을 낸다. 한 사람이 AI 도구로 과거에는 소규모 팀이 필요했던 제품을 만들 수 있다. 인디 해커 커뮤니티 Indie Hackers와 Bootstrapped Founders는 직원 없이 월 매출 10만 달러 이상에 이른 개인 운영자들을 기록했고, 제품을 출시할 수 있었던 이유로 바이브 코딩 작업 흐름을 자주 꼽았다.

전문 프로그래머는 바이브 코딩을 선택적으로 쓴다. 상용구 코드, 낯선 프레임워크, 빠른 실험에 쓰고, 초기 생성에는 바이브 코딩을 쓴 뒤 결과를 검토하고 다듬는 혼합 방식도 많다. 앤드루 응은 AI가 쓸 만한 소프트웨어를 쓰도록 이끄는 일이 깊이 지적인 작업이며 상당한 사고가 필요하다고 경고했다. 그는 AI 코딩 보조와 하루 종일 일하면 하루가 끝날 때 완전히 지친다고도 말했다.¹⁴

2025년 스택오버플로 개발자 설문에서 응답자의 80%는 어떤 형태로든 AI 도구를 썼지만, 업무에서 바이브 코딩을 쓴다는 응답은 약 23%였다. 5%는 이 방식을 명시적으로 거부했다.¹⁸

8. 주목할 만한 사례

몇몇 프로젝트는 바이브 코딩의 가능성과 한계를 함께 보여 주었다.

8.1. Fly.Pieter.com(피터 레벨스의 비행 시뮬레이터)

독립 개발자이자 기업가인 피터 레벨스(Pieter Levels, 온라인 별명 Levelsio)는 2025년 2월 Cursor와 AI로 브라우저 기반 3D 비행 시뮬레이터를 만들었다. 게임 개발 경험이 없었지만 “브라우저에서 3D 비행 게임을 만들어 줘”라고 입력하고 반복해 고쳐 약 세 시간 만에 초기 프로토타입을 완성했다. 게임은 2025년 2월 23일 출시되었고, 일론 머스크(Elon Musk)가 이 발표를 리트윗하며 AI 게임이 크게 성장할 것이라고 댓글을 달아 인기가 폭발했다.

이 프로젝트에는 실시간 멀티플레이어, 게임 내 광고, 브랜드 3D 오브젝트가 들어 있었다. 2025년 3월 12일까지 연간 반복 매출이 100만 달러에 이르렀고, 월 매출은 10만 달러 이상으로 정점을 찍었다. 기업들은 비행선 광고에 주당 1,000달러, 브랜드 F-16 전투기에는 수만 달러를 냈다. 레벨스는 초기 급등 뒤 안정 상태의 월 매출이 6만 7,000달러라고 밝혔다. 이 성공으로 바이브 코딩 게임이 늘었고, 2025년 3월에는 AI로 만든 게임을 모아 둔 디렉터리 사이트도 등장했다.¹⁹

8.2. Bolt.new의 성장 이야기

Bolt.new는 StackBlitz가 2024년 10월 4일 출시했고, 바이브 코딩이 상업적 제품 적합성에 이른 대표 사례가 되었다. 출시 전 StackBlitz는 연간 매출 약 8만 달러의 작은 개발자 도구 회사였고, 2023년 12월 이사회는 성과를 내지 못하면 사업을 접으라는 최후통첩을 보냈다. 팀은 마케팅 없이 트윗 한 개와 함께 Bolt를 내놓았고, Claude 3.5 Sonnet을 WebContainers 실행 환경에 연동했다.

출시 당일 ARR이 6만 달러 늘었고 다음 날 8만 달러가 더해졌으며, 30일 만에 ARR 400만 달러에 도달했다. 2025년 2월에는 2,000만 달러, 3월에는 4,000만 달러를 넘었다. 당시 소프트웨어 역사에서 가장 빠른 매출 성장 중 하나였다.⁶

8.3. Lovable의 유럽 부상

스톡홀름에 본사를 둔 Lovable은 안톤 오시카(Anton Osika)가 만든 오픈소스 프로젝트 GPT Engineer(2023년)에서 출발했다. 오시카와 공동 창업자 파비안 헤딘(Fabian Hedin)은 2024년 말 공개 베타를 ‘GPT Engineer App’으로 내놓았고, 2025년 초 Lovable로 이름을 바꿨다. 정식 공개 후 8개월 만에 ARR 1억 달러를 넘었고, 2025년 11월 ARR은 2억 달러로 두 배가 되었다.⁵

2025년 12월 Lovable은 기업가치 66억 달러에 시리즈 B로 3억 3,000만 달러를 조달했다. CapitalG(알파벳)와 Menlo Ventures가 주도했고, 엔비디아(Nvidia)도 참여했다. 2026년 3월에는 ARR 4억 달러, 일일 활성 사용자 1,500만 명 이상, 하루 새로 만들어지는 프로젝트 20만 건을 보고했다. 오시카는 미국이 기반 모델에서 앞서 있어도 유럽 기업이 이 분야에서 경쟁할 수 있다고 자주 주장하며 바이브 코딩의 대표적 대변인이 되었다.^5,12,20

8.4. Cursor의 시장 위치

Cursor의 모회사 Anysphere는 대중화된 바이브 코딩 도구 중 기업가치가 가장 높은 사례가 되었다. ARR은 2025년 1월 1억 달러, 6월 5억 달러, 11월 10억 달러를 넘었고, 2026년 2월에는 20억 달러에 이르렀다. 블룸버그는 2026년 초 Anysphere가 기업가치 500억 달러로 최소 20억 달러를 조달하는 협상 중이며, 안드리센 호로위츠, 스라이브 캐피털, 엔비디아가 공동 주도한다고 보도했다. 보도에 따르면 고객사에 포춘 1,000대 기업의 거의 70%가 포함되어, 개인과 대기업 구매자를 동시에 잡은 드문 개발자 도구가 되었다.⁴

8.5. 개인용·유틸리티 앱

• Claude로 만든 합판 재단 시각화 도구로, 자재 절단을 최적화하도록 돕는다
• 부모를 위한 잠자리 동화 생성기
• 가진 재료로 만들 수 있는 칵테일을 추천하는 레시피 생성기
• 단체 여행을 조율하는 휴가 계획 앱
• 프로그래밍 경험이 없는 자녀가 만든, 고령 부모의 복약 일정 관리 앱
• 한부모 모임의 학교 카풀 조율 도구
• 습도 센서와 연동된 취미용 식물 물주기 추적기

이 프로젝트들은 한 사람이 아이디어와 AI 도구만으로 며칠이나 몇 주가 아니라 몇 시간 만에 작동하는 앱을 만든다는 공통 패턴을 보인다.²¹

8.6. 학계 연구

2025년 논문 「User-Centered Design with AI in the Loop」는 바이브 코딩으로 사용자 인터페이스를 빠르게 시제품화하는 과정을 살폈고, 설계에서 구현까지의 주기가 크게 줄어든다는 결과를 얻었다. Microsoft Research와 대학 공동연구진은 2025년 6월 「Screen Reader Users in the Vibe Coding Era: Adaptation, Empowerment, and New Accessibility Landscape」를 발표해, 시각 장애 및 저시력 프로그래머가 바이브 코딩 작업 흐름에 어떻게 적응했는지 기록했다.²²

EASE 2026 학회의 일부로 첫 국제 워크숍 「Vibe Coding and Vibe Researching (VibeX 2026)」이 공지되어 학계의 관심이 커지고 있다. 2025년 10월 arXiv 프리프린트 「Vibe Coding: Toward an AI-Native Paradigm for Semantic and Intent-Driven Programming」은 프로그래밍의 기본 단위를 문법이 아니라 의도로 보자고 제안했다.

9. 채택과 생태계

바이브 코딩은 1년 만에 신조어에서 세계적 흐름으로 옮겨 갔다. 채택은 여러 축으로 측정할 수 있다.

9.1. 도구별 매출과 사용자 수(2025~2026년)

위 수치는 회사 발표, TechCrunch와 블룸버그 보도, 제3자 추적 자료에서 가져왔다. 비상장 회사의 ARR은 자체 보고 수치로 다뤄야 한다.

9.2. 개발자 채택

2025년 스택오버플로 개발자 설문은 전문 개발자를 대상으로 한 가장 큰 연례 조사다. 응답자의 80%가 업무에서 AI 도구를 썼는데, 이는 전년 76%보다 늘어난 수치다. 반면 AI 정확도에 대한 신뢰는 40%에서 29%로 떨어졌다. 바이브 코딩에 대해서는 72%가 업무와 무관하다고 답했고, 5%는 명확히 거부했다. 가장 큰 불만은 응답자 66%가 꼽은 “거의 맞지만 완전히 맞지는 않은 AI 해결책”이었고, 다음은 AI 생성 코드 디버깅이 더 오래 걸린다는 점(45%)이었다.¹⁸

이 결과는 양극화된 분포를 보여 준다. 대부분의 전문 개발자는 AI 도구를 똑똑한 자동 완성처럼 쓰고, 스타트업 창업자·독립 개발자·비전통적 빌더 중심의 소규모 집단이 바이브 코딩 작업 흐름을 전면 채택했다.

9.3. 투자자들의 관심

바이브 코딩은 2025년 벤처 투자의 핵심 주제가 되었다. 개리 탄(Garry Tan)과 안드리센 호로위츠 파트너들이 이 분야를 공개적으로 홍보했고, 세쿼이아 캐피털(Sequoia Capital)과 Founders Fund는 각각 경쟁 도구 여러 곳에 투자했다. Lovable의 2025년 12월 시리즈 B에 알파벳의 CapitalG와 엔비디아가 함께한 점은 순수 벤처 투자사를 넘어선 전략적 관심을 보여 준다. 2026년 3월 무렵 가장 큰 바이브 코딩 도구들의 공개 ARR을 합치면 30억 달러를 넘었고, 비공개 기업가치 합계는 800억 달러를 넘었다.²⁰

9.4. 교육과 커뮤니티

앤드루 응은 2025년 3월 DeepLearning.AI를 통해 Replit과 함께 ‘Vibe Coding 101’을 열었다. 하버드 대학교 확장 스쿨은 2025년 말 학점이 붙는 강좌를 개설했다. 이 용어는 The New York Times, The Verge, IEEE Spectrum, Wired, MIT Technology Review, Fortune, Fast Company, TechCrunch 등 주요 매체에도 등장했다.¹⁴

온라인에서는 Indie Hackers, 서브레딧 r/vibecoding, 소규모 디스코드 서버 네트워크가 빌더를 모으고 작업 흐름 템플릿을 공유한다. 학회에서는 AI Engineer Summit, NeurIPS 워크숍, AI 컨퍼런스 시리즈에 바이브 코딩 트랙이 생겼다.

10. 보안은 괜찮은가

보안은 바이브 코딩의 핵심 실패 양상으로 떠올랐다. 주요 플랫폼 전반에서 같은 패턴이 반복되었는데, 기본 설정으로 배포된 바이브 코딩 앱이 민감한 데이터를 노출했고, 만든 개발자는 코드를 자세히 읽어 보지 않아 이를 알아채지 못했다.

10.1. Veracode 2025 GenAI 코드 보안 보고서

Veracode의 2025 GenAI Code Security Report는 알려진 보안 약점이 있는 80개 코드 완성 과제에 대해 100개 이상의 LLM을 시험했다. 핵심 결과는 AI가 생성한 코드 샘플의 45%에 최소 하나의 보안 취약점이 있었다는 것이다. 취약점이 가능한 경우 AI 생성 사례의 86%에서 교차 사이트 스크립팅(XSS) 오류가, 생성 샘플의 20%에서 SQL 인젝션 취약점이 나타났다. 보고서는 취약점이 입력 검증, 인증 흐름, 접근 제어에 몰려 있으며, 이는 여러 해 동안 OWASP 상위 10개 목록을 지배해 온 범주와 같다고 밝혔다.²³

10.2. 다섯 개 도구 보안 비교

2025년 12월 연구(CSO Online 보도)는 바이브 코딩 도구 다섯 개(Claude Code, OpenAI Codex, Cursor, Replit, Devin)에 같은 테스트 앱 15개를 만들게 했다. 결과물에서 취약점은 모두 69개였다. 이 중 약 45개는 낮음에서 중간 심각도, 다수는 높음, 약 6개는 치명적으로 분류되었다. 가장 심각한 취약점은 API 인가 로직, 객체 수준 권한 검사 실패, 비즈니스 로직 결함과 관련이 있었다.³

같은 시기 발표된 Wiz 연구는 표준 도구로 검사했을 때 바이브 코딩 앱의 20%에 심각한 취약점이나 설정 오류가 있었다고 밝혔다.²⁴

10.3. Lovable의 보안 위기

Lovable은 바이브 코딩 첫해에 가장 널리 보도된 단일 업체 보안 사건의 주인공이었다. 2025년 5월 보안 연구자 매트 팔머(Matt Palmer)와 코디 로(Kody Low)는 Lovable로 만든 웹앱 1,645개 중 170개(약 10.3%)에서 임의의 방문자가 다른 사용자의 데이터를 읽을 수 있는 치명적 취약점을 발견했다고 발표했다. 원인은 Lovable 앱이 행 수준 보안 정책 없이 Supabase에 연결되어 있었기 때문이다. 노출된 데이터에는 이름, 이메일 주소, API 키, 금융 기록, 개인 부채 금액이 포함되었다.²⁵

팔란티어의 다니엘 아사리아(Daniel Asaria)는 독립적으로 문제를 재현했다. 파이썬 코드 15줄로 한 시간 안에 여러 앱에서 부채 잔액, 집 주소, API 키를 빼냈고, 이 문제에는 CVE-2025-48757이 부여되었다. Semafor는 Lovable을 해커에게 쉬운 먹잇감이라고 묘사했고, TheNextWeb은 노출된 프로젝트가 접근 가능한 상태로 남아 있던 48일을 추적했는데, 그 기간 동안 Lovable은 버그 보고를 해결하지 않고 닫았다.^25,26,27

2026년 2월에는 Lovable의 권한 관리 백엔드에서 객체 수준 권한 검사 실패(BOLA) 결함이 별도로 나타나, 2025년 11월 이전에 만든 프로젝트의 채팅 기록에 다시 접근할 수 있게 되었다. 2026년 4월 공개된 내용에 따르면 무료 Lovable 계정으로도 다른 사용자의 소스 코드, 데이터베이스 자격 증명, AI 채팅 기록, 고객 데이터를 읽을 수 있었다. Lovable은 처음에 데이터 유출을 부인하고 ‘의도된 동작’이라고 주장했다. 이어 자사 문서 탓을 하다가 버그 바운티 파트너 HackerOne에 책임을 돌렸고, 결국 부분 사과를 했다.²⁸

10.4. Replit Agent의 SaaStr 사건

2025년 7월 기술 기업가이자 SaaStr 창업자 제이슨 레름킨(Jason Lemkin)은 Replit의 AI 에이전트가 자신이 설명한 활성 코드 동결 중에 운영 데이터베이스를 삭제한 사건을 공개로 기록했다. 그의 설명에 따르면 에이전트는 허가받지 않은 명령을 실행해 경영진 1,200명 이상과 기업 1,190곳 이상의 기록을 날렸다.^29,30

에이전트는 레름킨이 공개한 스크린샷에서 치명적인 판단 오류를 인정하고, 명시적인 신뢰와 지시를 위반했다고 말했다. 처음에는 롤백이 불가능하다고 알렸지만, 그는 얼마 뒤 데이터를 수동으로 복구했다. Replit CEO 아므자드 마사드(Amjad Masad)는 개발 데이터베이스와 운영 데이터베이스의 자동 분리, 롤백 체계 개선, 계획 전용 모드 도입 등 새 안전장치를 내놓았다고 답했다. AI Incident Database는 이 사건을 Incident 1152로 기록했다. 이 사건은 안전하지 않은 코드를 생성한 데 그치지 않고 에이전트가 사람의 명시적 지시를 거슬러 행동했다는 점에서 보안 논의의 기준점이 되었다.^31,32,33

10.5. 슬롭 스쿼팅

더 넓게 퍼진 보안 위험은 AI가 만든 패키지 추천과 관련이 있다. 2025년 4월 파이썬 소프트웨어 재단(PSF)의 상주 개발자 세스 라슨(Seth Larson)은 LLM이 존재하지 않는 패키지 이름을 지어낼 때, 그 이름으로 악성 패키지를 npm, PyPI 같은 레지스트리에 등록하는 행위를 ‘슬롭 스쿼팅(slop squatting, slopsquatting)’이라 불렀다.³⁴

Lasso Security의 바르 라냐도(Bar Lanyado)와 후속 연구들은 LLM이 추천한 패키지의 19.7%가 존재하지 않았고, 오픈소스 모델은 21.7%, 독점 모델은 5.2%에서 이런 환각이 나타났다고 밝혔다. 연구자들은 20만 5,000개를 넘는 고유한 환각 패키지 이름을 찾았다. 환각된 이름의 43%는 모든 실행에서 반복되었고, 10회 실행 중 58%는 한 번 넘게 반복되어 공격자에게 안정적인 표적이 되었다.^35,36

공격 방식은 단순하다. 공격자가 LLM이 추천하는 가짜 패키지를 미리 등록해 두고, 바이브 코더가 설치 명령을 복사해 실행하기를 기다린 뒤, 패키지의 설치 스크립트로 악성코드를 전달한다. 2025년 말에는 npm과 PyPI에서 환각 데이터셋에 기록된 이름과 일치하는 악성 업로드가 여러 건 확인되었다.³⁷

10.6. 접근성 결함

AI 생성 코드는 경험 많은 개발자가 내면화한 웹 콘텐츠 접근성 지침(WCAG)의 기본 원칙을 자주 어긴다. 보그단 체로바츠(Bogdan Cerovac)의 「Beware of Vibe Accessibility」(2025년 4월)와 Deque Systems의 「Vibe Fixing」 보고서는 흔한 결함을 기록했다. 생성된 이미지의 대체 텍스트 누락, 적절한 랜드마크 대신 의미 없는 div만 늘어놓은 구조, 명도 대비 기준에 못 미치는 색, ARIA 레이블 누락, 표준 HTML 컨트롤로 충분한데 다시 만든 접근성 없는 맞춤형 위젯 등이 있었다.³⁸

유럽 표준 EN 301 549는 학습 데이터에서 WCAG보다 덜 다뤄져, 유럽 제품이 특히 취약하다. Microsoft Research의 스크린 리더 사용자 논문은 바이브 코딩 인터페이스가 문서화, 일관성, 명명 규칙이 부족해 접근성 감사를 복잡하게 만들고, 회귀 오류를 쉽게 도입하고 찾기 어렵게 만든다고 밝혔다.²²

10.7. 노출된 자격 증명과 설정 표류

반복되는 사고 유형은 바이브 코딩 앱이 API 키, OAuth 토큰, 데이터베이스 연결 문자열을 클라이언트에 보이는 파일에 하드코딩한 채 배포되는 것이다. XDA-Developers의 애덤 콘웨이(Adam Conway)는 2025년 말 특별히 찾지 않았는데도 사용자 데이터를 유출하는 바이브 코딩 앱을 계속 발견했다고 기록했다.

제3자 서비스를 연결하라고 요청받은 LLM은 사용자의 API 키를 클라이언트 쪽 자바스크립트나 커밋된 환경 파일에 그대로 붙여 넣곤 했다. Snyk, GitGuardian, TruffleHog 같은 정적 분석 도구들은 2025년 내내 노출된 비밀 정보가 꾸준히 늘었다고 보고했다.³⁹

11. 커뮤니티의 반응

소프트웨어 개발 커뮤니티는 카파시의 트윗 이후 바이브 코딩을 두고 의견이 갈렸다.

11.1. 옹호 측의 시각

옹호자들은 바이브 코딩을 어셈블리어에서 고수준 언어로 옮겨 간 것과 비슷한 프로그래밍의 자연스러운 진화로 본다. 코드 세부를 추상화하면 개발자가 제품 설계, 사용자 경험, 비즈니스 로직에 집중할 수 있다고 주장한다. 피터 레벨스와 Y Combinator 스타트업의 성공담은 바이브 코딩이 실질적인 경제 가치를 낼 수 있다는 증거로 자주 인용된다. 개리 탄(Garry Tan)의 ‘엔지니어 10명이 과거 50명이 하던 일을 한다’는 주장은 벤처 업계의 되풀이되는 화제가 되었고, 그의 펀드 포트폴리오 기업 여러 곳이 바이브 코딩 작업 흐름을 공개적으로 채택했다.

11.2. 회의론 측의 시각

전문 프로그래머들은 상당한 회의를 표명해 왔다. 많은 이들은 코드를 이해하는 일이 선택 사항이 아니라 신뢰할 수 있는 시스템을 만드는 기본 요건이라고 주장한다. 2025년 스택오버플로 개발자 설문은 코딩 에이전트가 아직 주류가 되지 않았음을 보여 주었다. 개발자의 72%가 업무에서 바이브 코딩을 명시적으로 제외했고, 같은 해 AI 도구 채택은 늘었지만 AI 정확도에 대한 신뢰는 29%로 떨어졌다.¹⁸

앤드루 응은 AI 보조 개발 전반은 지지하면서도 용어 자체에는 반대했다. 2025년 5월 한 AI 컨퍼런스에서 그는 바이브 코딩을 오해를 부르는 유행어라고 하며, 이 이름 때문에 엔지니어가 그저 분위기에 맡기는 것처럼 들린다고 안타까워했다. AI를 이끌어 쓸 만한 소프트웨어를 만들게 하려면 깊은 지적 참여가 필요하고, 탄탄한 기초가 있어야 개발자가 AI와 더 나은 협업을 할 수 있으므로 누구나 여전히 코딩을 배워야 한다고 주장했다.¹⁴

11.3. 코드 품질 근거

2025년 12월 CodeRabbit이 GitHub 오픈소스 풀 리퀘스트 470건을 분석한 결과, 생성형 AI가 공동 작성한 코드는 사람이 쓴 코드보다 ‘주요’ 문제가 약 1.7배 많았다. 논리 오류, 잘못된 의존성, 흐름 제어 결함, 설정 오류(사람이 쓴 코드보다 75% 많음), 보안 취약점(2.74배 높음)의 비율이 높게 나타났다.⁸

GitClear의 장기 연구는 2020~2024년 사이 2억 1,100만 줄의 코드 변경을 다루었고, AI 코딩 보조 도구 도입과 맞물린 뚜렷한 추세를 찾았다. 리팩터링 비율은 2021년 변경 줄의 25%에서 2024년 10% 미만으로 떨어졌다. 코드 중복은 약 네 배로 늘어 새 줄의 8.3%에서 12.3%가 되었다. 복사-붙여넣기 줄이 20년 만에 처음으로 이동하거나 리팩터링된 줄을 넘어섰는데, 이는 ‘같은 것을 반복하지 말라’는 오랜 원칙을 어긴 것이다. 2주 안에 새로 쓴 코드가 수정되는 비율인 코드 변동률(churn)은 2020년 3.1%에서 2024년 5.7%로 올랐고, 새로 쓴 코드가 검토를 통과하지 못하거나 재작업이 필요한 경우가 늘었음을 시사한다.

11.4. 이해 부족

바이브 코딩에 대한 핵심 철학적 반론은 개발자가 읽지 않은 코드를 배포한다는 것이다. 개발자가 읽지 않은 코드에서 버그가 생기면 디버깅은 극도로 어려워진다. 비판자들은 디버깅 자체가 사람이 코드를 의미 있게 검토할 수 있다는 전제를 두는데, 바이브 코딩의 규모와 속도에서는 그 전제가 무너진다고 지적한다.

연구자들은 AI 에이전트가 런타임 오류를 없애려고 검증 검사를 지우거나, 데이터베이스 정책을 완화하거나, 인증 흐름을 끄는 것을 관찰했다. AI는 눈앞의 오류를 없애는 데 최적화되어 다른 곳에 더 나쁜 문제를 만들 수 있다. 비판자들은 ‘첫 시도 정답 착각’도 지적했다. 첫 실행에 돌아간 프로토타입은 실패할 경로를 개발자가 실행해 본 적이 없어서 통과했을 뿐인데도 정확성의 증거처럼 느껴진다는 것이다.

11.5. 개발자 생산성의 역설

2025년에는 뜻밖의 연구 결과가 나왔다. METR(Model Evaluation and Threat Research)은 2025년 2~6월 경험 많은 오픈소스 개발자 16명을 대상으로 246개 과제에 걸친 무작위 대조 실험을 했다. 개발자들은 AI 코딩 도구(주로 Cursor Pro와 Claude 3.5·3.7 Sonnet)를 쓸 때 19% 느렸다. 실험 전에는 AI가 24% 빠르게 해 줄 것이라 예측했고, 끝난 뒤에도 20% 빨라졌다고 여겼다. 체감과 실제 생산성의 차이는 39%포인트에 이르렀다. 이는 AI 보조 코딩의 체감 생산성 향상이 특히 복잡한 과제를 다루는 경험 많은 개발자에게는 실제와 맞지 않을 수 있음을 시사한다.

11.6. 기술 부채와 바이브 코딩 후유증

바이브 코딩은 단기적으로 작동하는 코드를 만들지만 기술 부채를 빠르게 쌓는다. 리팩터링, 테스트, 아키텍처 계획이 없으면 바이브 코딩 프로젝트는 유지 보수가 불가능해질 수 있다. 2025년 9월 Fast Company는 ‘바이브 코딩 숙취(vibe coding hangover)’를 보도했다. 시니어 엔지니어들은 아무도 이해할 수 없을 만큼 커진 AI 생성 코드베이스 때문에 ‘개발 지옥’을 겪는다고 말했다.

HackerNoon에 널리 공유된 글 「The Vibe Coding Hangover: What Happens When AI Writes 95% of Your Code」는 AI가 코드 줄의 95%를 써도 엔지니어링 작업의 95%는 남는다고 주장했다. 검토, 아키텍처, 디버깅, 테스트, 보안, 유지 보수 부담이 모두 사람에게 남는다는 것이다.

독립 개발자 바스 나이홀트(Bas Nijholt)는 「Vibe coding worked, until the 15-hour cleanup」라는 인기 글에서 주말 프로젝트가 성공해 보였지만 공유 전에 이틀짜리 수작업 정리가 필요했다고 썼다. Charly3Pins 사이트의 「Vibe Coding: A Weekend Hack That's Not Ready for the Real World」도 다른 관점에서 비슷한 지적을 했다. 이런 글들은 빠른 초기 성공, 원인 모를 버그의 느린 누적, 결국 전통적 엔지니어링 관행으로의 항복이라는 공통 흐름을 보인다.

11.7. 오픈소스에 미치는 영향

2026년 1월 논문 「Vibe Coding Kills Open Source」는 바이브 코딩이 오픈소스 생태계에 부정적 영향을 준다고 주장했다. 저자들은 바이브 코딩이 늘수록 오픈소스 관리자와의 소통이 줄어든다고 보았다. 바이브 코더는 버그 보고나 수정 기여를 거의 하지 않으며, 바이브 코딩 앱이 의존하는 라이브러리와 프레임워크를 관리하는 이들에게는 숨은 비용이 생긴다. 이 주장은 xz utils 관리자들이 앞서 제기한 우려와 같은 맥락이다.

11.8. 의미 확산 문제

사이먼 윌리슨은 ‘의미 확산(semantic diffusion)’이라 부른 반복 문제를 짚었다. 바이브 코딩이라는 말이 너무 넓게 쓰여 원래 뜻을 잃고 있다는 것이다. 기자, 마케터, 일부 개발자까지 프로그래밍에서 AI를 쓰는 모든 경우를 바이브 코딩이라 불러, 검토가 있는 AI 보조 개발과 검토가 없는 실제 바이브 코딩의 구분이 흐려졌다. 2025년 5월 윌리슨은 「Two publishers and three authors fail to understand what 'vibe coding' means」라는 후속 글에서 인쇄된 책을 포함한 출판물의 잘못된 용례를 짚었다. 그는 규율 있는 AI 보조 엔지니어링과 무모한 바이브 코딩을 뭉뚱그리면 양쪽 모두 손해라고 주장했다. 규율 있는 방식은 바이브 코딩의 보안 실패에 책임을 떠안고, 바이브 코딩은 실제로는 거의 내지 못하는 프로덕션 품질 결과물의 공을 인정받는다는 것이다.⁴⁰

11.9. 산업의 진화

2025년 말 논의는 바이브 코딩이 좋은지 나쁜지를 넘어섰다. MIT Technology Review는 그해 흐름을 바이브 코딩에서 컨텍스트 엔지니어링으로 옮겨 가는 과정으로 묘사하며, 업계가 AI 보조 개발을 더 구조화된 방식으로 채택하고 있다고 설명했다. 모델 컨텍스트 프로토콜(MCP)과 에이전트 간 통신 규격인 A2A는 LLM을 외부 문맥 원천에 연결하고 AI 에이전트들이 협업하게 하는 표준으로 떠올랐다. 바이브 코딩이 대중화한 아이디어가 성숙해 가는 단계를 보여 준다.¹³

12. 문화적 논쟁

바이브 코딩의 정치적·노동 시장적 함의는 2025년과 2026년 가장 큰 기술 논쟁 중 하나가 되었다.

12.1. 민주화와 기술 저하의 대립

민주화 논리는 단순하다. 소프트웨어를 싸게 만들 수 있으면 더 많은 사람이 자기 문제를 스스로 풀 수 있다. 3만 달러짜리 맞춤 재고 관리 시스템 계약을 감당하지 못했던 소상공인이 주말에 직접 만들 수 있고, 교사는 학급 도구를, 지역 활동가는 개발자 고용 없이 등록 사이트를 만들 수 있다. BRICS Economic Review의 「Democratization of Software Development Through Vibe Coding」(2025)은 신흥 시장의 사례를 정리하며, 이 방식이 전 세계 소프트웨어 생산량을 크게 늘릴 수 있다고 주장했다.

기술 저하(deskilling) 반론도 직접적이다. 바이브 코딩이 덜 믿을 만한 소프트웨어를 더 빠르고 싸게 만든다면, 노동 시장은 신뢰성보다 빠르고 싸게 만드는 생산자에게 보상할 것이라는 주장이다. 주니어 개발자는 어려운 선택에 놓인다. AI 도구는 그들과 비슷한 수준으로, 때로는 더 낫게, 때로는 훨씬 나쁘게 코드를 쓰지만 확실히 더 빠르다. 상용구 작업에서 시니어 엔지니어링으로 이어지던 경력 경로가 좁아질 수 있다. LeadDev와 TechTarget 등 기술 매체는 이를 초년 엔지니어에게 실존적 시험이라는 틀로 다루었다.

12.2. 노동 조직과 직군 변화

업계 관찰자들은 2023년과 2024년 체결된 SAG-AFTRA와 미국작가조합(WGA)의 AI 조항에 견주어 왔다. 당시 노조는 대본, 목소리, 초상의 생성형 AI 사용 범위를 협상했다. 반면 소프트웨어 개발자는 대부분 비노조 상태여서 같은 집단 교섭 구조가 없다. 알파벳 노동자 조합(Alphabet Workers Union)과 마이크로소프트의 CWA 계열 노조 일부가 작업장 협상에서 AI 도구 문제를 제기했지만, 2026년 초 기준 소프트웨어 업무를 대상으로 SAG-AFTRA 수준의 광범위한 계약은 나오지 않았다.

‘프롬프트 엔지니어’는 2023년과 2024년 잠깐 고임금 직군으로 떠올랐다. Anthropic 등 여러 회사가 연봉 10만 달러 이상의 공고를 냈다. 그러나 2025년 중반에는 이 직함이 주류 채용 공고에서 사실상 사라졌다. 모델 공급사들이 프롬프트 설계를 시스템 프롬프트, 도구 정의, 에이전트 루프 같은 제품 설계 안으로 흡수했고, 최신 모델은 작은 프롬프트 차이에 덜 민감해졌다. 이 직군의 쇠퇴로 바이브 코딩이 새 전문 분야를 열었다는 서사도 흔들렸다. 비판자들은 LLM이 분기마다 나아지는 상황에서 LLM 중심 직함이라는 전제 자체가 취약하다고 지적했다.

12.3. 전문성 판단과 언론의 시각

비판자들은 바이브 코딩이 노력 없이 가능한 것처럼 말하지만 여전히 전문가의 판단이 필요하다고 자주 지적했다. 언제 AI를 믿을지, 언제 되돌릴지, 언제 처음부터 다시 할지, 언제 시제품을 버릴지는 천천히 익혀지는 기술이다. 앤드루 응이 바이브 코딩을 ‘깊이 지적인 활동’이라고 한 주장이 이 반론을 잘 담고 있다. 하버드 가제트(Harvard Gazette)가 2026년 4월 실은 기사 「Vibe coding may offer insight into our AI future」는 이 방식을 비인간 저자와 협업하는 강제 실험으로 보고, 그에 따르는 편집 작업을 강조했다.

주류 언론의 보도는 축하와 경계 사이에서 오갔다. TechCrunch, The Verge, Wired는 개별 창업자와 매출 성과를 조명했다. IEEE Spectrum, MIT Technology Review, Ars Technica, Hacker News는 품질, 보안, 노동 문제에 초점을 맞췄다. The Register는 특정 사고를 날카롭게 다뤘다. 같은 주에 백만 달러짜리 인디 게임을 다룬 긍정적인 기사와 기본 설정이 안전하지 않은 플랫폼에 대한 경고가 함께 나올 수 있었다.

13. 인접 개념과 관련 개념

바이브 코딩은 더 넓은 실천 방식과 용어 가족 안에 놓여 있다.

13.1. 관련 개발 방식

윌리슨의 기준은 바이브 코딩(검토 없음)과 AI 보조 코딩(충분한 검토)을 구분한다. 대부분의 실무 개발자는 AI를 조수로 쓰고, 실제 운영 작업에 순수 바이브 코딩을 하는 사람은 적다. 이 구분은 채용, 코드 리뷰, 사고 대응에 실질적 결과를 준다.

2025년 말 나온 ‘바이브 엔지니어링(vibe engineering)’은 AI의 속도와 엔지니어링 규율을 결합하려 한다. 실무자는 AI로 코드를 생성한 뒤 테스트, 코드 리뷰, 배포 파이프라인, 관측 가능성을 더한다. 윌리슨은 2025년 10월 이 용어에 관한 글에서, 운영 작업에는 순수 바이브 코딩이 아니라 바이브 엔지니어링이 맞는 모델이라고 주장했다.

컨텍스트 엔지니어링(context engineering)도 2025년에 등장한 개념으로, 각 단계에서 AI가 무엇을 보는지에 초점을 둔다. Cursor Rules, Claude Code의 CLAUDE.md 관례, AGENTS.md가 이를 공식화했다. 컨텍스트 엔지니어링으로의 이동에는 모델이 병목인 경우는 드물고 병목은 모델이 프로젝트에 대해 아는 내용이라는 업계 전반의 인식이 담겨 있다.

13.2. 명세 기반 개발과 테스트 우선 코딩

스펙 기반 AI 개발은 흐름을 뒤집는다. 코드를 명세에 맞춰 쓰는 대신, 개발자가 상세한 자연어 명세를 쓰고 구현은 AI에 맡긴다. 명세가 진실의 원천이 된다. AWS의 Kiro 프레임워크와 여러 오픈소스 실험이 2025년과 2026년에 이 패턴을 채택했다.

테스트 우선 AI 코딩은 테스트 주도 개발을 AI 생성에 맞게 바꾼다. 개발자가 테스트 케이스를 쓰고(AI의 도움을 받기도 한다), 이를 통과하도록 AI가 구현 코드를 만든다. 테스트는 순수 바이브 코딩에 없는 객관적인 수락·거부 신호를 준다.

13.3. AI 우선 개발과 풍자적 용어

‘AI 우선 개발(AI-first development)’은 느슨한 상위 개념으로, 요구 사항 생성, 코드 생성, AI 기반 테스트와 배포까지 소프트웨어 개발 생애 주기 전체를 AI 도구 중심으로 짜는 것을 뜻한다. 바이브 코딩은 그 안의 한 전술이다.

행동 주도 개발(behavior-driven development)을 풍자한 ‘바이브 주도 개발(vibe-driven development)’은 Hacker News와 컨퍼런스 발표에서 구조 없는 바이브 코딩 세션을 가리키는 데 쓰였다. 이 말에는 방식이 혼란으로 흐를 수 있다는 자기 인식이 담겨 있다.

바이브 코딩은 전통적 노코드·로코드 도구(Bubble, Webflow, Retool)와 비슷한 영역에 있지만 두 가지가 다르다. 첫째, 독자적 설정이 아니라 실제 소스 코드를 만든다. 둘째, 열려 있어서 개발자는 벤더 템플릿에 맞는 앱만이 아니라 어떤 앱이든 설명할 수 있다. 실무자들은 두 접근을 섞어 노코드 플랫폼을 확장하거나 벗어나는 데 바이브 코딩을 쓴다.

14. 소프트웨어 개발 관행에 미친 영향

바이브 코딩은 소프트웨어 업계가 개발 작업 흐름, 채용, 교육을 생각하는 방식에 영향을 주었다.

14.1. 기술 요구와 팀 구성의 변화

바이브 코딩의 확산은 개발자에게 어떤 기술이 중요한지를 둘러싼 논쟁을 낳았다. AI가 코드 작성의 기계적 부분을 맡는다면 시스템 설계, 아키텍처 사고, 품질 보증, 요구 사항을 명확히 말하는 능력이 더 가치 있어진다. 반대로 문법과 API 세부를 외우는 일의 중요성은 줄어든다. 2025년 채용 담당자들은 시스템 설계 면접과 ‘AI 협업’ 평가를 더 중시한다고 밝혔다. 후자는 후보자가 작은 문제를 AI와 짝을 이뤄 푸는 모습을 관찰하는 방식이다.

Y Combinator는 AI 도구를 쓰는 엔지니어 10명이 과거 50~100명이 하던 일을 해낼 수 있다고 관찰했다. 이는 팀 규모와 생산성 기대의 큰 변화를 시사한다. 일부 업계 관찰자는 AI로 강화된 소규모 팀이 큰 전통 엔지니어링 조직을 점점 이길 것이라고 예측한다. 이 변화가 실제라면 엔지니어링 관리와 채용 깔때기에, 그리고 소프트웨어 조직이 인원 수를 최적화할지 산출을 최적화할지라는 오래된 질문에 영향을 준다.

14.2. 새로운 개발 작업 흐름

• 명세 기반 AI 개발: 개발자가 상세한 명세를 쓰고 AI가 구현을 만든다.
• 테스트 우선 AI 코딩: 개발자가 테스트 케이스를 쓰고 AI가 이를 통과하는 코드를 만든다.
• 대화형 반복: 편집, 컴파일, 테스트의 전통적 주기를 AI와의 지속적인 주고받는 대화가 대체한다.
• 다중 에이전트 파이프라인: 기획, 구현, 테스트, 리뷰를 각각 다른 에이전트가 맡고 사람은 주요 결정에만 참여한다.

14.3. 교육과 채용

컴퓨터 과학 교육도 달라지기 시작했다. 앤드루 응은 Replit과 함께 DeepLearning.AI를 통해 ‘Vibe Coding 101’을 열어 AI 에이전트로 앱을 만들고 배포하는 법을 가르쳤다. 하버드 확장 스쿨은 학점 강좌를 추가했고, App Academy, Hack Reactor, Le Wagon 같은 부트캠프는 바이브 코딩 모듈을 넣었다. 대학 학과들은 모델이 입문 과제를 몇 초 만에 끝낼 수 있을 때 기초 프로그래밍을 어떻게 가르칠지 고민했다. 일부 교수는 학생이 코드를 만드는 것만이 아니라 설명할 수 있는지 확인하려고 구두 시험과 실시간 프로그래밍 세션으로 옮겨 갔다고 보고했다.

생산성 기대가 바뀌면서 AI 네이티브 스타트업의 채용 방식도 바뀌었다. Lovable, Cursor의 자체 엔지니어링 팀, Y Combinator 지원 기업 다수는 소규모 팀을 뽑고 모든 엔지니어에게 AI 도구를 최대 강도로 쓰기를 기대한다. 2025년과 2026년 채용 공고에는 Claude Code나 Cursor가 필수 요건으로 늘었는데, 10년 전 Git이나 GitHub가 그랬던 것과 같은 흐름이다.

15. AI 코딩 도우미·에이전트와의 관계

바이브 코딩은 AI 보조 소프트웨어 개발과 에이전트 생태계 안에 있다.

15.1. 코딩 도우미와 에이전트

GitHub Copilot 같은 전통적 AI 코딩 도우미는 주로 고급 자동 완성으로 작동한다. 개발자가 입력하는 동안 코드 완성을 제안하고, 개발자는 제안을 받을지 결정한다. 이는 AI 보조 프로그래밍이지만 개발자가 코드에 계속 관여하므로 바이브 코딩은 아니다.

AI 에이전트는 단순한 코드 완성보다 한 걸음 더 나아간다. 에이전트형 코딩 도구는 변경 순서를 계획하고, 여러 파일을 고치고, 테스트를 돌리며, 오류를 스스로 반복해 고칠 수 있다. Claude Code, Cursor의 에이전트 모드, OpenAI Codex CLI, Devin이 이런 방식으로 작동한다. 에이전트형 코딩은 바이브 코딩과 밀접하다. 개발자가 더 큰 작업 덩어리를 AI에 맡기게 하지만, 리뷰와 함께할 수도 리뷰 없이 할 수도 있다.

15.2. 페어 프로그래밍 비유와 검증 격차

일부 개발자는 AI 코딩 도구와의 관계를 ‘AI와의 페어 프로그래밍’이라고 묘사한다. 전통적 페어 프로그래밍에서는 두 사람이 한 작업대에서 한 명은 코드를 쓰고(드라이버) 다른 한 명은 실시간으로 검토한다(내비게이터). AI 페어 프로그래밍에서는 AI가 드라이버이고 사람이 내비게이터로서 AI의 결과를 검토하고 이끈다. 이 비유는 사람이 더 이상 이끌지 않고 AI가 감독 없이 운전하는 순수 바이브 코딩에서는 무너진다.

비판적 논평에 자주 나오는 주제는 ‘검증 격차(verification gap)’다. AI가 생성한 코드가 말한 대로 동작하는지 확인하는 인지적·시간적 비용을 뜻한다. 수동 검증은 느리고, 자동 검증(테스트, 형식 기법, 정적 분석)은 부분적이다. 바이브 코딩은 설계상 검증을 최소화하며, 이 때문에 빠르지만 위험하다. 몇몇 공급사는 별도의 AI 에이전트가 다른 에이전트의 코드를 리뷰하고 테스트하는 검증 파이프라인을 실험해 왔다. 비판자들은 검증되지 않은 검증자가 문제를 해결하기보다 옮길 뿐일 수 있다고 지적한다.