바이브 코딩이란

출발점: 185단어짜리 트윗

2025년 2월 2일, Andrej Karpathy가 X에 이렇게 썼습니다 [1]:

"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. … I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

"보고, 말하고, 돌리고, 붙여 넣는다. 대체로 된다." — 이 한 줄이 이후 모든 정의의 원형이 됐어요. Sarkar와 Drosos는 이 트윗을 "Karpathy 정전(canon)"이라 부르고, 굳이 규범을 세우지 않고 본인이 바이브 코딩이라 부르면 바이브 코딩이라는 기준만 씁니다 [2]. 실제 사용자들의 말은 더 솔직합니다: "AI가 무거운 일을 하게 한다", "앱이랑 그냥 수다 떤다", "코드를 파고들지 않고 AI를 받아들인다" [2].

정의는 스펙트럼

2026년의 다성문헌 리뷰(논문 28편 + 실무 자료 19편)는 열두 개의 정의를 모아 하나로 합칩니다 [4]:

바이브 코딩은 의도 주도 개발 실천이다. 개발자는 원하는 기능·제약·맥락을 주로 자연어 프롬프트로 말하고, 언어 모델이 코드를 생성·수정·반복한다. 개발자의 역할은 코드를 직접 쓰는 것에서 의도를 표현하고, 결과를 평가하고, 고쳐 달라고 하고, 다음 반복을 조종하는 것으로 옮겨 간다. 가장 강한 형태(Karpathy)에서는 코드를 아예 읽지 않지만, 실제로는 최소 검토("순수" 바이브 코딩)부터 테스트·린트·사람 검토를 갖춘 구조적 검증까지 스펙트럼 위에 있다.

Meske 등은 이것을 "의도 매개(intent mediation)의 재구성"이라 부릅니다 — 패치 케이블에서 어셈블리, FORTRAN, 객체지향, 로우코드를 거쳐 온 역사에서 처음으로 결정론적 지시가 확률적 추론으로 바뀐 순간이라는 거예요 [3]. 실무 자료 101편을 읽은 리뷰는 더 짧게 말합니다: "속도와 실험을 이해보다 앞세우는" 실천 [5].

루프

정의가 뭐든 실제로 하는 일은 같습니다. 바이브 코딩 세션 8시간 27분을 분석한 연구가 관찰한 순환 [2]:

1. 목표(또는 하위 목표)를 정한다
2. 프롬프트를 쓴다
3. 생성된 코드를 (대충) 본다
4. 받아들이거나 거절한다
5. 앱을 돌려 본다
6. 버그를 찾는다
7. 프롬프트를 고치거나, 직접 손으로 고친다 → 2로

3번이 "대충"인 게 특징이에요. 이 연구의 프로그래머들은 코드를 줄 단위로 읽지 않고 빨강·초록 diff의 크기와 모양을 훑는 "인상주의적 스캔" 을 했고, 수십 줄의 변경을 2초 만에 수락하기도 했습니다 [2]. 5번이 진짜 검토입니다. 그래서 여러 논문이 "정말 중요한 것은 생성 속도가 아니라 그 주위를 감싼 평가 루프의 엄격함"이라고 결론 냅니다 [4].

전문성은 사라지지 않고 옮겨 간다

"코드를 안 쓰니 전문성이 필요 없다"는 결론은 아무 논문도 내지 않았어요. 오히려 반대입니다.

• 전문성은 "코드를 쓰는 것에서 AI 결과를 평가하고, 이끌고, 다듬는 것으로 방향이 바뀐다" [2]. 세 종류의 전문성이 섞입니다: 전통적 프로그래밍, AI 다루기(모델·프롬프트·컨텍스트 창), 그리고 제품 관리(무엇을 만들지 정하는 힘).
• 사람은 "무엇(What)"과 "왜(Why)"를, 에이전트는 "어떻게(How)"를 맡는다 [7].

• 162명 설문에서 비개발자·초보·전문가는 경험 자체는 비슷하게 보고했지만("맞아 보이는데 돌려 보면 틀린다", "데모용으로는 좋고 프로덕션엔 안 된다"), 검증 행동이 갈렸습니다. 비개발자만 "생성된 코드를 한 번도 확인하지 않는다"고 답한 집단이었고, 이해가 안 돼 디버깅을 포기하는 비율도 높았어요. 회귀분석에서 이 차이를 설명한 건 직함이 아니라 혼자 코딩해 본 누적 시간이었습니다 [6].

Sarkar와 Drosos는 한 걸음 더 나가요: 자기들이 본 바이브 코더는 전부 숙련 프로그래머였고, 비전문가의 바이브 코딩은 "겉보기만 비슷한 전혀 다른 활동"일 수 있다고 — 그 연구는 아직 없다고 씁니다 [2]. 이 위키의 잘 하는 법는 그 공백을 메우려는 시도입니다.

어디까지 믿을 것인가: 다섯 모델

1000편 이상을 훑은 서베이는 "얼마나 검토하느냐"로 다섯 가지 작업 모델을 나눕니다 [7]. 작품을 만들 때 유용한 기준이에요.

모델	무엇	언제
UAM 무제약 자동화	AI 결과를 전부 믿고 거의 안 본다	버릴 프로토타입, 개념 증명, 개인용 도구 — 여기까지만
ICCM 대화형 협업	AI 생성 → 사람이 읽고 이해 → 테스트 → 수락. AI가 운전, 사람이 내비	대부분의 작업
PDM 계획 주도	먼저 사양·규칙 파일·구현 계획 세 문서를 쓰고 시작	오래 갈 프로젝트
TDM 테스트 주도	테스트가 곧 사양	정확성이 중요한 부분
CEM 맥락 강화	코드베이스 색인, 문서, 규칙 파일을 항상 제공	위 어느 것과도 결합

첫날 만드는 시제작은 UAM이어도 됩니다. 12월 전시에 세울 작품은 아니에요. 어느 쪽인지 미리 정하고 시작하는 게 핵심입니다.

바이브 코딩과 에이전틱 코딩

Cursor의 "채팅"과 "에이전트" 모드 차이가 여기 있습니다. Sapkota 등은 바이브 코딩(사람이 감독·공동조종자, 컴포넌트 단위, 피드백 루프가 시스템 밖 = 사람)과 에이전틱 코딩(에이전트가 계획·실행·테스트, 사람은 감독)을 나누고, "바이브 코딩이 창의적 앞단, 에이전틱이 그것을 운영·확장하는 뒷단"이 될 거라고 봅니다 [8].

같은 논문이 든 사용 사례 9번이 바로 우리 일이에요: "음악과 클릭에 반응하는 JavaScript 애니메이션을 만들어 줘" → p5.js·Tone.js 파이프라인 → "비트 세기에 따라 색이 바뀌게" → "클릭에 파티클 꼬리를" — "생성 예술, 사운드 시각화, 인터랙티브 설치의 문턱을 크게 낮춘다" [8].

수업에서

한 가지 숫자

경험 많은 개발자가 Cursor + Claude로 일했더니 오히려 19% 느려졌다는 실험이 있습니다 [7에서 재인용]. 도구가 좋다고 빨라지는 게 아니라, 맥락을 잘 주고, 환경이 갖춰지고, 협업 방식이 정해졌을 때 빨라진다는 뜻이에요. 이 방식이 어디로 가는지는 어디로 가는가가, 왜 낯설지 않은지는 이미 있던 이름들가, "정해진 방식"은 잘 하는 법가 다룹니다.