바이브 코딩이 위험한 이유는 코드를 안 봐서가 아니다

바이브 코딩의 핵심 리스크는 AI가 코드를 많이 쓴다는 사실이 아니다. 사람이 구현 내부를 덜 읽게 될 때도 판단 가능한 검증 장치를 갖췄는지가 문제다.

Share

바이브 코딩이라는 말에는 이상한 조롱이 섞여 있다.

AI에게 대충 말하고, 나온 코드를 제대로 보지 않고, 느낌으로 ship하는 무책임한 개발처럼 들린다. 실제로 그렇게 쓰면 위험하다. 하지만 그 비판만으로는 중요한 변화를 놓친다.

문제는 코드를 전부 읽느냐가 아니다.

읽지 않은 구현도 판단할 수 있는 검증 체계가 있느냐다.

Anthropic의 Vibe coding in prod는 이 지점을 잘 잡는다. 발표자는 바이브 코딩을 단순히 "AI가 코드를 많이 써주는 것"으로 보지 않는다. 더 정확히는 사람이 구현 세부를 전부 이해하지 못한 상태에서도 제품을 만들고 검증하는 방식으로 본다.

이건 사실 새로운 문제가 아니다.

대표가 회계사의 모든 분개를 직접 검산하지 않아도 회사를 운영한다. PM이 엔지니어가 쓴 모든 코드를 읽지 않아도 기능을 검수한다. CTO가 모든 도메인의 최고 전문가가 아니어도 팀의 결과물을 판단한다. 우리는 이미 오래전부터 "내가 내부를 전부 모르는 결과물"을 다루며 일해왔다.

차이는 속도다.

AI가 코드를 훨씬 많이, 훨씬 빠르게 만들기 시작하면서 기존의 느슨한 검증 습관이 버티지 못하게 됐다. 예전에는 사람이 코드를 쓰는 속도가 자연스러운 제동 장치였다. 이제 그 제동 장치가 사라진다. 그러면 남는 질문은 하나다.

무엇으로 멈출 것인가.

이때 필요한 것은 더 많은 불안이 아니라 더 좋은 acceptance test다. 사용자가 기대하는 행동이 무엇인지, 어떤 상태가 성공인지, 무엇이 깨지면 안 되는지 명확히 해야 한다. 구현을 모두 읽지 않아도 결과를 판단할 수 있는 기준이 있어야 한다.

바이브 코딩을 책임 있게 하려면 사람의 역할도 바뀐다.

사람은 Claude의 타자수가 아니라 매니저가 된다. 새로 합류한 팀원에게 일을 맡기듯이 배경을 설명하고, 요구사항을 정리하고, 참고할 파일을 알려주고, 제약 조건을 말해준다. 발표자가 말하는 15분, 20분짜리 준비는 낭비가 아니다. 그 시간이 결과물의 품질을 결정한다.

좋은 지시는 짧은 명령이 아니다.

좋은 지시는 온보딩이다. 이 기능은 왜 필요한지, 비슷한 구현은 어디 있는지, 어떤 테스트를 추가해야 하는지, 어떤 UX는 피해야 하는지, 어떤 로그나 CI를 확인해야 하는지 알려주는 것이다. 사람이 제대로 준비하지 않고 "알아서 해줘"라고 던졌다면, 실패의 상당 부분은 모델이 아니라 관리 방식에 있다.

또 하나 중요한 점은 검증을 모델에게도 맡길 수 있어야 한다는 것이다.

단순히 코드를 쓰게 하는 것으로 끝나면 사람의 부담은 줄지 않는다. 오히려 낯선 diff만 늘어난다. Claude가 테스트를 만들고, 실행하고, 실패를 읽고, 다시 고치고, 마지막에 무엇을 확인했는지 보고하게 해야 한다. 그래야 사람은 "이 diff를 처음부터 끝까지 해독하는 사람"이 아니라 "검증 근거를 보고 ship 여부를 판단하는 사람"이 된다.

그렇다고 사람의 책임이 사라지는 것은 아니다.

오히려 책임은 더 선명해진다. 어떤 테스트가 충분한지, 어떤 리스크는 사람이 직접 봐야 하는지, 어떤 변경은 배포 전에 막아야 하는지 정하는 일은 여전히 사람의 몫이다. AI가 코드를 빨리 쓰게 될수록 사람은 더 높은 층위의 판단을 게을리할 수 없다.

여기서 바이브 코딩의 위험이 드러난다.

코드를 안 보는 것 자체가 위험한 게 아니다. 안 봐도 되는 것과 반드시 봐야 하는 것을 구분하지 못하는 것이 위험하다. 버튼 색상 변경과 결제 로직 변경은 같은 방식으로 맡기면 안 된다. 테스트가 촘촘한 리팩터링과 프로덕션 데이터 마이그레이션은 같은 자율도를 줄 수 없다.

책임 있는 바이브 코딩은 속도를 포기하지 않는다.

대신 속도가 지나갈 레일을 깐다. 요구사항, 테스트, 리뷰, 로그, 배포 게이트, rollback 경로를 준비한다. 이 레일이 없으면 빠른 생성은 빠른 혼란이 된다. 레일이 있으면 빠른 생성은 실제 생산성이 된다.

그러니 질문은 "AI가 쓴 코드를 다 읽어야 하나"가 아니다.

더 좋은 질문은 이것이다.

이 변경을 내가 내부까지 읽지 않아도 판단할 수 있는가.

판단할 수 없다면 아직 ship할 준비가 안 된 것이다. Claude가 부족해서가 아니라, 작업의 성공 조건이 부족한 것이다.

바이브 코딩의 미래는 무책임한 느낌 개발이 아니다.

검증 가능한 위임이다.