바이브 코딩(vibe coding)이란? 한계와 AI 코드 검증 루프

바이브 코딩은 의도를 말로 던지면 LLM이 코드를 채우는 방식이에요. 1편에서 프롬프트 한 방의 한계를 봤어요: 상태도, 도구도, 검증도 없다는 것. 코드 영역에서 그 한계를 처음 흔든 게 바이브 코딩이에요. 2025년 2월, Andrej Karpathy가 던진 말이 이름이 됐어요 ^[1]. "코드가 존재한다는 걸 잊고, 완전히 바이브에 맡긴다."

> 'LLM 활용의 진화' 시리즈 ②편. ① 프롬프팅 · ② 바이브 코딩 · ③ 에이전트 · ④ 하네스 엔지니어링 · ⑤ 오픈 모델.

바이브 코딩이 연 것: 만드는 마찰이 사라졌어요

바이브 코딩의 핵심은 추상화 레벨을 한 칸 올린 것이에요. 예전엔 한 줄 한 줄 우리가 썼다면, 이제는 "이런 걸 만들고 싶어"라고 의도를 말하고 LLM이 코드를 채워요. 우리는 결과를 보고 다시 말로 고치죠.

이게 두 가지를 풀었어요. 첫째, 속도: 프로토타입을 만드는 시간이 몇 시간에서 몇 분으로 줄었어요. 둘째, 접근성: 문법을 다 외우지 않아도 의도만 명확하면 무언가를 만들 수 있게 됐어요. 만드는 일의 마찰이 확 줄어든 거예요.

그런데 '느낌'은 검증이 아니에요

문제는 바이브 코딩이 프롬프팅에서 한 가지 한계를 그대로 물려받았다는 거예요. 바로 검증의 부재예요. 코드가 돌아가는 것처럼 보인다고 맞는 건 아니에요.

• 동작'하는 것처럼' 보여요: 해피 패스만 확인하고 넘어가면, 엣지 케이스에서 조용히 깨져요.
• 이해 못 한 코드가 쌓여요: 내가 안 쓴 코드라 디버깅도 못 하고, 기술 부채가 빠르게 누적돼요.
• 보안·정합성이 빠져요: "되네?"와 "맞네"는 달라요. 느낌은 후자를 보장하지 못해요.

바이브 코딩의 유명한 농담이 "works until it doesn't"예요. 될 때까지는 되다가, 안 되는 순간 왜 안 되는지 아무도 모르는 상태가 와요.

느낌만 믿을 때와 검증 루프를 붙였을 때는 이렇게 갈려요.

바이브를 멈추지 말고, 검증을 붙여요

해법은 바이브 코딩을 그만두는 게 아니에요. 빠르게 만드는 건 그대로 두되, 생성 뒤에 검증 루프를 붙이는 것이에요. 의도 → 생성 → 실제로 실행 → 검증 → 통과하면 반영. 우리가 코드를 다룰 때 쓰는 규칙도 이거예요. 격리된 작업 공간에서 만들고, 진짜로 돌려서 확인한 다음에야 합쳐요.

# ① 바이브: 생성물을 바로 main 에 — '되는 것처럼' 보일 뿐
# ② 하네스: 격리 → 생성 → 실제 실행으로 검증 → 통과해야 머지
git worktree add ../wt-feature -b feature/x   # 격리된 작업 공간
#   (LLM 이 wt-feature 안에서 구현)
cd ../wt-feature
pytest -q && pnpm typecheck                    # 추정이 아니라 '실행'으로 검증
#   통과하면 머지, 아니면 다시 — main 은 깨지지 않아요

핵심은 한 줄이에요. "추정으로 끝내지 말고, 실제 결과를 본다." 바이브 코딩이 만든 속도에, 검증이라는 바닥을 깔아 주는 거예요. 격리는 실패해도 안전하게 만들고, 실행은 "되는 것처럼"을 "된다"로 바꿔요.

정리하면

바이브 코딩은 만드는 마찰을 지워 속도와 접근성을 열었어요. 하지만 프롬프팅의 '검증 없음'을 그대로 안고 있어서, 검증 하네스 없이는 "works until it doesn't"에 갇혀요. 빠르게 만들되, 격리하고 실행해서 검증하는 것, 그게 바이브를 실무로 끌어올리는 한 끗이에요.

여기까진 루프를 사람이 돌았어요. 만들고, 돌려 보고, 고치는 걸 우리가 했죠. 그럼 모델이 스스로 도구를 쓰고 결과를 보며 루프를 돈다면? 다음 편, 에이전트예요.

이 글과 이어지는 내용은 프롬프트 잘 쓰는 법: 컨텍스트 설계로 AI 결과물을 고정하기, AI 에이전트란? 모델이 스스로 루프를 돌 때 권한과 승인 게이트, 퍼스트파티 데이터가 뭐예요? 서드파티 쿠키 이후 마케팅 활용법에서 볼 수 있어요.