바이브 코딩이란 무엇인가

2025년 초, Andrej Karpathy가 트윗 하나를 올렸다.

"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."

"바이브 코딩"이라는 표현이 처음 등장한 순간이다. 코드가 존재한다는 사실조차 잊어버리고, 그냥 느낌(vibe)에 몸을 맡기는 개발 방식. Karpathy는 AI에게 코드를 시키면서 결과만 보고 "대충 이런 느낌이야"라고 피드백하는 자신의 개발 스타일을 이렇게 불렀다.

이 글에서는 바이브 코딩이 정확히 무엇인지, 왜 이런 용어가 등장했는지, 그리고 실제로 어떻게 작동하는지 정리한다.

---

코드 작성 비용이 0에 가까워졌다

바이브 코딩이 가능해진 건 단순하다. 코드를 직접 쓰는 비용이 거의 사라졌기 때문이다.

2021년 GitHub Copilot이 등장했을 때만 해도 "자동완성이 좀 똑똑해졌네" 정도였다. 한 줄, 한 함수 단위로 제안해주는 수준. 여전히 개발자가 흐름을 잡고, 구조를 짜고, 대부분의 코드를 직접 쳤다.

그런데 2024년을 지나면서 상황이 달라졌다. Cursor, Claude Code, Windsurf 같은 도구들이 나오면서 "파일 하나를 통째로 만들어줘", "이 기능 전체를 구현해줘"가 가능해졌다. 심지어 "에러 나는데 고쳐줘"라고 하면 알아서 디버깅까지 한다.

처음 이런 도구를 쓸 때 솔직히 반신반의했다. "이게 되겠어?"라는 생각으로 시작해서, 한 시간 만에 동작하는 프로토타입을 보고 멍해졌다. 예전 같으면 하루는 걸렸을 작업이었다.

---

"타이핑"이 아니라 "판단"이 병목이 됐다

이 경험을 몇 번 반복하면서 깨달은 게 있다. 개발의 병목이 바뀌었다.

예전에는 이랬다:

• 뭘 만들지 결정한다 (10분)
• 어떻게 만들지 설계한다 (30분)
• 코드를 친다 (2시간)
• 디버깅한다 (1시간)
• 테스트한다 (30분)

지금은 이렇다:

• 뭘 만들지 결정한다 (10분)
• AI에게 시킨다 (5분)
• 결과를 본다 (5분)
• "아 이거 말고 저렇게 해줘" (반복)

코드 치는 시간이 거의 사라졌다. 대신 "이게 내가 원하는 건가?"를 판단하는 시간이 대부분을 차지한다. 결과물을 보고, 아니다 싶으면 다시 시키고, 맞는 것 같으면 넘어가고.

이게 바이브 코딩의 핵심이다. 코드를 쓰는 게 아니라, AI가 만든 코드를 평가하고 방향을 잡아주는 것. 마치 영화 감독이 배우에게 "다시, 이번엔 좀 더 슬프게"라고 하는 것처럼.

---

바이브 코딩의 실제 루프

실제로 바이브 코딩은 이런 흐름으로 진행된다.

[1] 의도 전달
    "로그인 폼 만들어줘. 이메일이랑 비밀번호 입력받고,
     유효성 검사도 해줘."

[2] AI가 코드 생성
    → 컴포넌트 파일 생성
    → 스타일 적용
    → 기본 유효성 검사 로직 추가

[3] 결과 확인
    → 브라우저에서 실행해봄
    → "동작은 하는데... 디자인이 별로네"

[4] 피드백
    "버튼 색상 파란색으로 바꾸고,
     에러 메시지는 입력창 아래에 빨간색으로 보여줘"

[5] 반복
    → 원하는 결과가 나올 때까지 [2]~[4] 반복

여기서 중요한 건, 내가 코드를 안 본다는 게 아니다. 코드는 본다. 근데 한 줄 한 줄 작성하는 게 아니라, 전체를 훑어보고 "이 방향이 맞나?" 정도만 확인한다. 마음에 안 들면 직접 고치기보다 AI한테 다시 시키는 게 빠를 때가 많다.

Karpathy가 말한 "코드가 존재한다는 사실을 잊는다"는 건 이런 맥락이다. 코드의 세부 구현보다 결과와 동작에 집중하게 된다.

---

기존 개발과 뭐가 다른가

바이브 코딩과 기존 개발 방식을 비교하면 이렇다.

구분	기존 개발	바이브 코딩
코드 작성자	개발자	AI
개발자 역할	구현자	감독/검증자
핵심 스킬	문법, 알고리즘, 타이핑	의도 전달, 결과 판단
속도 결정 요인	타이핑 속도, 숙련도	판단 속도, 명확한 요구사항
디버깅	코드를 읽고 추적	AI에게 증상 설명

이게 좋은 건지 나쁜 건지는 아직 모르겠다. 확실한 건, 다르다는 것. 그리고 이 방식이 점점 더 많은 개발자들 사이에서 퍼지고 있다는 것.

---

"바이브"라는 표현이 중요한 이유

왜 하필 "바이브"인가. Karpathy가 그냥 멋있어서 붙인 이름이 아니다.

기존 개발은 정확한 명세가 필요했다. 함수 시그니처, 타입 정의, 로직 흐름. 이걸 코드로 정확히 표현해야 했다.

바이브 코딩은 다르다. "대충 이런 느낌이야"로 시작한다. 정확한 명세가 없어도 일단 뭔가 나온다. 그걸 보고 "아, 이건 아니고"라며 조정해 나간다. 느낌으로 개발한다는 표현이 과장이 아닌 거다.

물론 이게 위험할 수 있다. 느낌으로 만든 코드가 정말 제대로 동작하는지 어떻게 보장할 것인가? 이건 다음 편에서 다룬다.

---

바이브 코딩이 모든 걸 바꾸진 않는다

한 가지 확실히 해두고 싶은 게 있다. 바이브 코딩이 만능은 아니다.

• 새로운 알고리즘을 발명하는 건 여전히 사람 몫이다
• 아키텍처 결정도 AI가 대신해주지 않는다
• 요구사항이 모호하면 AI도 모호한 결과를 낸다
• 테스트와 검증은 더 중요해졌다 (AI 코드를 믿을 수 없으니)

바이브 코딩은 구현의 수고를 덜어주는 것이지, 개발 전체를 대체하는 게 아니다. 오히려 "구현 말고 다른 것들"의 중요성이 더 부각됐다.

---

마무리: 이 시리즈에서 다룰 것

이 시리즈 "바이브 코딩 생존 가이드"에서는 바이브 코딩을 현실적으로 다룬다.

1. 바이브 코딩이란 무엇인가 - 지금 이 글
2. 바이브 코딩이 실패하는 3가지 패턴 - 왜 빠르게 만든 코드가 망가지는가
3. 개발자에서 "개발 감독"으로 - 역할 전환과 새로운 스킬셋
4. Spec-First 워크플로우 - 이상적인 바이브 코딩 루프
5. AI 코드를 신뢰하는 방법 - 테스트 전략
6. 1인 개발자의 바이브 코딩 시스템 - 혼자서 팀처럼
7. 바이브 코딩 프로젝트의 6개월 후 - 지속 가능성

바이브 코딩은 자유를 주지만, 책임은 사라지지 않는다. 다음 편에서는 그 책임을 무시했을 때 어떤 일이 벌어지는지 이야기한다.