# 바이브 코딩이란

> [!NOTE]
> **한 장 요약.** 바이브 코딩 = 말로 시키고 → 코드가 생기고 → **돌려 보고** → 다시 말하기. 코드를 안 읽는 "순수" 형태부터 테스트·검토를 갖춘 형태까지 하나의 스펙트럼이고, 어느 칸에서 일할지는 **미리 정한다**. 전문성은 사라지지 않고 "쓰기"에서 "평가하고 이끌기"로 옮겨 간다.

## 출발점: 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)에서는 코드를 아예 읽지 않지만, 실제로는 **최소 검토("순수" 바이브 코딩)부터 테스트·린트·사람 검토를 갖춘 구조적 검증까지** 스펙트럼 위에 있다.

![바이브 코딩 경험의 네 요소 — 대화형 상호작용(패러다임), 공동 창작(활동), 몰입과 즐거움(경험), 그리고 이 셋을 잇는 신뢰. 출처: Pimenova 외 (2025) Fig. 1 [12], CC BY 4.0](/wiki/vibe/fig-2509.12491-1.png)

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

## 루프

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

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

![바이브 코딩의 한 바퀴 — Sarkar & Drosos(2025)의 관찰을 이 위키가 다시 그린 것 [2]](/wiki/vibe/loop.svg)

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

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

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

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

![개발자 · 코딩 에이전트 · 프로젝트의 삼각 관계. 개발자는 "코드 세부가 아니라 결과에 집중"하고, 에이전트는 "프로젝트 맥락 안에서" 코딩한다. 출처: Ge 외 (2025) Fig. 2 [7], CC BY 4.0](/wiki/vibe/fig-2510.12399-1.png)


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

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

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

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

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

![얼마나 볼 것인가 — 정의의 스펙트럼 [4] 위에 다섯 작업 모델 [7]을 놓은 것. 이 위키가 그림](/wiki/vibe/spectrum.svg)

![제약(세로) 대 개발 속도(가로) 평면 위의 다섯 모델. UAM은 "빠르고 위험", TDM은 "빠르고 경직", 맥락 강화(CEM)는 어느 것이든 오른쪽 위로 밀어 올린다. 출처: Ge 외 (2025) Fig. 8 [7], CC BY 4.0](/wiki/vibe/fig-2510.12399-2.png)

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

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

Cursor의 "채팅"과 "에이전트" 모드 차이가 여기 있습니다. Sapkota 등은 바이브 코딩(사람이 감독·공동조종자, 컴포넌트 단위, 피드백 루프가 시스템 밖 = 사람)과 에이전틱 코딩(에이전트가 계획·실행·테스트, 사람은 감독)을 나누고, "바이브 코딩이 창의적 앞단, 에이전틱이 그것을 운영·확장하는 뒷단"이 될 거라고 봅니다 [8]. ![바이브 코딩의 다섯 기본 기술 — 생각하기(문제 정식화) · 프레임워크(구조 감각) · 체크포인트(버전 관리) · 디버깅(협업적 오류 해결) · 맥락(정보 제공). 출처: Sapkota 외 (2025) Fig. 2 [8], CC BY 4.0](/wiki/vibe/fig-2505.19443-1.png)

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

## 수업에서

> [!TIP]
> - 첫날 시제작을 시작하기 전에 각자 **"오늘은 스펙트럼의 어디서 일할지"** 한 마디로 말한다. 답은 "왼쪽 끝"이어도 됩니다 — 버릴 것이니까.
> - 루프의 5번(돌려 보기)을 건너뛴 사람이 옆에 있으면 알려 주세요. 3번에서 멈추고 다음 프롬프트로 가는 것이 가장 흔한 실수입니다.
> - "AI가 무거운 일을 한다"는 말이 맞는지, 오늘 끝나고 자기 프롬프트 기록을 보며 **내가 한 판단이 몇 번이었는지** 세어 봅니다.

## 한 가지 숫자

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