바이브 코딩과 자동 프로그래밍

TL;DR

바이브 코딩은 순간의 아이디어를 AI에게 전적으로 맡기는 방식. 자동 프로그래밍은 PRD/스펙을 철저히 수립한 뒤 실제 코딩을 맡기는 방식. 둘 중 뭐가 좋냐는 논쟁이 많은데, 결론부터 말하면 호불호가 아니라 상황에 따라 달라지는 것입니다.

두 진영의 논쟁

요즘 AI 코딩 관련 커뮤니티를 보면 크게 두 부류가 있습니다. "바이브 코딩 최고!" 하는 쪽과 "AI가 만든 코드라도 사람이 반드시 리뷰하고 이해해야 한다" 하는 쪽이죠. 트위터(X)든 레딧이든 이 주제만 나오면 꽤 뜨거운 논쟁이 벌어지더군요.

근데 양쪽 이야기를 깊게 들어보면, 사실 결론은 같습니다. 각자 전제하고 있는 상황이 다를 뿐이죠. 오늘은 이 두 개념을 정리하고 실제로 언제 뭘 쓰면 좋은지 이야기해보겠습니다.

바이브 코딩(Vibe Coding)

용어의 탄생

바이브 코딩은 2025년 2월 6일 Andrej Karpathy가 X(구 트위터)에서 처음 사용한 용어입니다. Karpathy는 OpenAI 창립 멤버이자 전 Tesla AI 디렉터로, AI 분야에서는 설명이 필요 없는 인물이죠.

그의 원문을 요약하면 이렇습니다:

바이브에 완전히 몸을 맡기고, 코드가 존재한다는 사실조차 잊어버리는 새로운 코딩 방식.

실제로 Karpathy는 Cursor Composer + Claude를 사용하면서 SuperWhisper로 음성 입력만 하고, diff도 안 보고 "Accept All"을 누르고, 에러가 나면 그냥 복붙해서 넣는 방식으로 개발했다고 합니다. 코드가 자기 이해 범위를 넘어가도 신경 쓰지 않았다고 하죠.

중요한 건 Karpathy 본인도 이 방식의 한계를 명확히 인지하고 있었다는 점입니다. 원문에서도 "throwaway weekend projects에는 나쁘지 않다"고 했습니다. 실제로 Karpathy는 나중에 Nanochat이라는 프로젝트를 직접 손으로 코딩하면서 "AI 에이전트를 몇 번 써봤지만 충분히 도움이 안 돼서 결국 직접 짰다"고 밝히기도 했습니다.

핵심 특징

• 자연어로 원하는 걸 말하고, AI가 생성한 코드를 리뷰 없이 수용
• 코드의 동작 원리를 완전히 이해하지 않아도 됨
• 에러 발생 시 에러 메시지를 그대로 AI에게 전달
• 빠른 프로토타이핑과 아이디어 검증에 최적화

Simon Willison의 정의가 가장 명확하더군요: "LLM이 모든 코드를 썼더라도 리뷰하고, 테스트하고, 이해했다면 그건 바이브 코딩이 아니다. 그건 LLM을 타이핑 도우미로 쓴 것이다."

자동 프로그래밍(Auto Programming)

용어의 배경

자동 프로그래밍이라는 개념 자체는 사실 컴퓨터 과학 초기부터 있던 아이디어입니다. 하지만 최근 AI 코딩 맥락에서 말하는 "자동 프로그래밍"은 조금 다릅니다. PRD(Product Requirements Document)나 상세 스펙을 먼저 완벽하게 작성하고, 그 문서를 기반으로 AI가 체계적으로 구현하게 하는 방식이죠.

이 접근법은 여러 사람들이 비슷한 결론에 도달하면서 자연스럽게 형성됐습니다. Addy Osmani(전 Google Chrome DevEx 리더, 현 Google Cloud AI Director)는 이를 "spec-driven AI development"라고 부르며 바이브 코딩과 명확히 구분했고, Andrew Ng도 "바이브 코딩이라는 이름에 속지 마라, 실제로는 고도의 엔지니어링 작업"이라고 강조하면서 "rapid engineering"이라는 표현을 선호했습니다.

GitHub가 2025년 9월 공식 블로그에서 Spec Kit을 발표하면서 "스펙이 진실의 원천(source of truth)이 되어 무엇을 빌드할지 결정한다"고 선언한 것도 같은 맥락이죠. MetaGPT 같은 멀티 에이전트 프레임워크는 이를 기술적으로 구현해서, PRD 하나를 입력하면 PM, 아키텍트, 엔지니어 역할의 에이전트들이 협업하여 코드를 생성하는 구조를 만들었습니다.

핵심 특징

• 구현 전에 PRD/스펙/설계 문서를 철저하게 작성
• AI가 스펙을 기반으로 단계적으로 구현
• 각 단계마다 검증과 테스트를 수행
• 개발자가 아키텍처와 설계를 완전히 통제

Ryan Carson(Treehouse 창립자, 5회 연쇄 창업가)의 워크플로우가 좋은 예시입니다. 현재 Untangle이라는 이혼 지원 앱을 AI만으로 혼자 만들고 있는데, 상세한 PRD를 작성하고, 거기서 계층적 태스크 리스트를 만들고, 각 서브태스크를 AI로 처리하되 "코드, 테스트, 커밋" 사이클로 사람이 감독하는 방식이죠.

비교: 뭐가 다른가

실제 사용: 상황에 따라 다르다

바이브 코딩이 빛나는 순간

개인 프로젝트 개선이나 빠른 아이디어 검증에는 바이브 코딩이 압도적입니다. "이거 되나?" 싶은 걸 10분 만에 확인할 수 있죠.

• 주말 사이드 프로젝트
• MVP 또는 프로토타입
• 내부 도구나 일회성 스크립트
• 새로운 라이브러리/프레임워크 탐색

Y Combinator의 2025년 Winter 배치에서 25%의 스타트업이 코드베이스의 95%가 AI 생성이었다는 통계도 있습니다. 초기 스타트업이 아이디어 검증 단계에서 바이브 코딩을 적극 활용하고 있다는 뜻이죠.

자동 프로그래밍이 필요한 순간

실제 복잡한 기능 구현, 특히 회사 업무에서는 자동 프로그래밍 방식이 필수입니다.

• 프로덕션 코드베이스 작업
• 팀 단위 개발
• 보안이 중요한 시스템
• 장기 유지보수가 필요한 프로젝트

Addy Osmani가 정리한 것처럼, FAANG급 팀들은 기술 설계 문서 작성 → 엄격한 코드 리뷰 → TDD 방식으로 AI를 활용합니다. 바이브 코딩의 탈을 쓴 AI-assisted engineering이죠.

하이브리드가 답이다

솔직히 현실에서는 깔끔하게 나뉘지 않습니다. 바이브 코딩으로 빠르게 프로토타입 → 자동 프로그래밍 방식으로 프로덕션 전환하는 하이브리드가 가장 실용적이더군요.

아침에 바이브 코딩으로 새 기능 실험 → 밤에 에이전트가 문서/테스트 추가 → 다음 날 리뷰 후 머지. 이런 리듬이 자연스럽게 자리 잡는 것 같습니다.

호불호가 아니라 전제가 다른 것

바이브 코딩을 좋아하는 사람, 싫어하는 사람. 온라인에서 보면 꽤 극단적으로 갈리는 것처럼 보이더군요. 하지만 깊게 들어가 보면 이런 구조입니다:

• 바이브 코딩 찬성론자: 주로 개인 프로젝트, 프로토타입, 사이드 프로젝트를 전제로 이야기함
• 바이브 코딩 반대론자: 주로 프로덕션, 팀 개발, 유지보수를 전제로 이야기함

서로 다른 전제를 깔아놓고 같은 용어를 두고 이야기하니 의견이 달라 보이는 거죠. 실제로 양쪽 의견을 충분히 들어보면 결론은 비슷합니다. "프로토타입에는 빠르게, 프로덕션에는 체계적으로."

Karpathy 본인이 바이브 코딩을 제안해놓고 본인의 진지한 프로젝트는 직접 손코딩한 것 자체가 이걸 증명합니다. Simon Willison도 80개 이상의 바이브 코딩 실험을 하면서도 프로덕션 코드에는 반드시 리뷰와 이해를 거친다고 했죠.

Andrew Ng의 입장도 같습니다. "바이브 코딩"이라는 용어가 마치 편하게 놀면서 코딩하는 것처럼 들리지만, 실제로 AI 프로그래밍은 고도의 정신적 에너지가 필요한 작업이라고 했습니다. 하루 종일 AI와 프로그래밍하고 나면 매우 지친다고요.

AI는 똑똑한 주니어다

회사 업무에서는 확실히 자동 프로그래밍 방식이 적합합니다. 바이브 코딩은 안 됩니다.

이유는 단순합니다. 모든 코드가 내 머릿속에 있어야 합니다. 회사 코드는 내가 설명할 수 있어야 하고, 리뷰할 수 있어야 하고, 문제가 생겼을 때 디버깅할 수 있어야 합니다. AI가 생성한 코드라도 내가 이해하지 못하면 그건 시한폭탄이죠.

실제로 2025년 9월 Fast Company에서 보도한 "바이브 코딩 숙취(hangover)" 현상이 정확히 이 문제입니다. 시니어 엔지니어들이 AI가 만든 코드를 유지보수하면서 겪는 고통을 "development hell"이라고 표현했더군요.

그래서 회사에서 AI를 활용할 때는:

• 반드시 계획/스펙을 먼저 작성할 것
• AI가 만든 코드를 꼭 리뷰하고 이해할 것
• 내 머릿속에 구현 방향이 있는 상태에서 AI에게 맡길 것
• 아니면 최소한 PRD라도 꼭 만들어서 방향을 잡을 것

AI는 개발 능력만큼은 시니어를 넘었지만, 결국 주니어 개발자와 같습니다. 왜냐하면 프로젝트 컨텍스트를 모르거든요. 주니어한테 "알아서 해"라고 안 하잖아요. 설계를 먼저 같이 합의하고, 구현을 맡기고, 결과를 리뷰하는 거죠.

결론: 상황에 맞게 쓰자

바이브 코딩이냐 자동 프로그래밍이냐, 이건 호불호의 문제가 아닙니다. 상황에 따라 최적의 방법이 달라지는 것이죠.

• 주말 프로젝트? → 바이브 코딩으로 빠르게
• 프로덕션 기능? → PRD 작성하고 체계적으로
• 새로운 기술 탐색? → 바이브 코딩으로 감 잡고
• 팀에 공유할 코드? → 스펙 기반으로 이해 가능하게

이 두 가지를 상황에 맞게 오가는 것, 그게 AI 시대 개발자의 핵심 역량이 아닐까 싶습니다.

Refs

• Andrej Karpathy의 바이브 코딩 원문 트윗 (2025.02.06): https://x.com/karpathy/status/1886192184808149383
• Karpathy의 MenuGen 바이브 코딩 후기: https://karpathy.bearblog.dev/vibe-coding-menugen/
• Simon Willison, "Not all AI-assisted programming is vibe coding": https://simonwillison.net/2025/Mar/19/vibe-coding/
• Addy Osmani, "Vibe coding is not the same as AI-Assisted engineering": https://addyo.substack.com/p/vibe-coding-is-not-the-same-as-ai
• Andrew Ng 인터뷰 "Ambient Programming": https://eu.36kr.com/en/p/3438070821653888
• Vibe Coding - Wikipedia: https://en.wikipedia.org/wiki/Vibe_coding
• GitHub Blog, "Spec-driven development with AI" (2025.09): https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/