바이브 코딩은 마치 고백처럼 취급됩니다. 누군가 모델이 작성한 코드를 한 줄도 읽지 않고 작동하는 앱을 만들었다고 인정하면, 그 자리에 있는 사람들은 마치 그가 안전 점검을 건너뛰었다고 고백한 것처럼 반응합니다. 여기서 옹호하고 싶은 주장은 이렇습니다: 그 반응은 대체로 틀렸습니다. 문법을 직접 타이핑하지 않는 것이 자신이 무엇을 하는지 모른다는 뜻은 아닙니다 — 이는 판단력을 어디에 쏟을지가 다르게 배분된 것일 뿐이며, 사람들이 만드는 것의 상당수에서는 그것이 오히려 올바른 선택입니다.
이 단어 자체는 생긴 지 겨우 몇 년밖에 안 됐는데 벌써 너무 많은 일을 떠맡고 있습니다. 겉으로는 비슷해 보이지만 실제로는 매우 다른 두 가지 행동을 가리키는 데 쓰입니다:
- 원하는 것을 신중하게 설명하고, 결과를 실제 기준과 대조해 확인한 뒤 출시하는 사람.
- 막연한 아이디어를 붙여넣고, 스크린샷을 슬쩍 보고, 잘 되길 바라며 프로덕션에 올리는 사람.
바이브 코딩을 비판하는 사람들은 대개, 그리고 합당하게, 후자를 묘사하고 있습니다. 하지만 마치 전자는 존재하지 않는다는 듯, 혹은 둘이 게으름의 정도만 다를 뿐 같은 스펙트럼 위에 있다는 듯 이야기합니다. 둘은 애초에 같은 스펙트럼 위에 있지 않습니다. 하나는 워크플로이고, 다른 하나는 워크플로의 부재입니다.
예전 기술이 실제로 하던 일은 무엇이었나
코드를 한 줄씩 읽고, 스택 트레이스를 세 파일 떨어진 널 포인터까지 추적하는 것 — 그것 자체가 목표였던 적은 한 번도 없습니다. 그것은 지금도 변하지 않은 목표, 즉 "이것이 내가 필요로 하는 대로 안전하게 작동하는가, 내일도 신뢰할 수 있는가"라는 질문에 답할 수 있는 유일한 수단이었을 뿐입니다. 30년 동안 그 질문에 답하는 유일한 방법은 기계를 직접 살펴볼 수 있을 만큼 그 언어에 능숙해지는 것이었습니다. 그래서 유창함이 역량의 대리 지표가 되었고, 결국 그 대리 지표가 목표 그 자체로 오인되었습니다. 사람들은 "diff를 읽을 수 있는가"를 목적을 위한 수단이 아니라 도덕적 미덕처럼 취급하기 시작했습니다.
검증이 더 이상 그런 유창함을 요구하지 않게 되면 — 빌드가 무엇을 테스트했는지, 무엇이 통과했는지, 리뷰어 에이전트가 무엇을 지적했는지에 대한 자체 기록을 남기게 되면 — 그 대리 지표는 더 이상 필요하지 않습니다. 우리는 실제 질문으로 돌아갑니다. 작동하는가. 신뢰할 수 있는가. 우리가 모든 빌드에 검증 기록을 구축한 이유는 바로 이 질문이 "사람이 소스를 읽었는가"를 거치지 않고도 답이 나와야 하기 때문입니다. 대부분의 빌더에게는 프롬프트가 있든 없든 애초에 그런 일이 일어날 리 없었으니까요. 워드프레스 플러그인의 PHP 코드를 읽는 사람도 아무도 없었습니다.
그 기술은 실제로 어디로 갔는가
그것은 명세로 옮겨갔고, 명세는 보기보다 어렵습니다. 누군가 진짜로 훌륭한 빌드 프롬프트를 작성하는 것을 지켜보면, 시니어 엔지니어가 설계 문서에 적용하는 것과 같은 규율을 발견하게 됩니다:
- 허용 기준은 무엇인가?
- 명시적으로 범위에서 제외되는 것은 무엇인가?
- 결제 시 장바구니가 비어 있는 예외 상황에서는 어떻게 되는가?
- 누가 이 데이터를 볼 수 있고, 누가 볼 수 없는가?
막연한 프롬프트는 막연한 앱을 만듭니다. 막연한 티켓이 막연한 풀 리퀘스트를 만드는 것과 같은 이유입니다 — 형편없는 제약 조건은 형편없는 결과물을 낳으며, 여기에 모델이 관여하는지 여부는 상관없습니다. AI 도구로 성공적으로 만드는 사람들은 생각하는 과정을 건너뛰는 게 아닙니다. 그들은 그 생각을 첫 오류가 발생한 뒤의 두 시간이 아니라, 첫 메시지 전 15분으로 앞당겼을 뿐입니다.
옮겨간 기술의 나머지는 리뷰 단계의 판단력이며, 이는 코드를 읽는 것보다는 빌드의 요약과 검증 기록을 읽고 적절히 회의적인 질문을 던지는 것에 가깝습니다. "환불 처리"라는 말이 정말로 환불이 중간에 실패하는 경우까지 처리한다는 뜻인가? 빈 상태도 테스트했는가, 아니면 정상 경로만 테스트했는가? 이것은 진짜 기술이며, "파이썬 읽는 법을 배워라"가 시간과 적성이 있는 일부 사람들에게만 가르칠 수 있었던 것과 달리, 훨씬 더 폭넓게 가르칠 수 있는 기술입니다. 저는 프로그래밍 경험이 전혀 없는 어느 가게 주인이 자신의 재고 관리 앱에 대해, 직접 작성하지 않은 코드에 대해 질문하는 수많은 엔지니어보다 더 날카로운 검증 질문을 던지는 것을 본 적이 있습니다. 그가 자신의 사업을 알고, 무엇이 망가진 상태인지 정확히 알기 때문입니다. 이는 진짜 기술을 대신하는 열등한 기술이 아닙니다. 그의 빌드에 있어서는, 문법 지식보다 훨씬 더 적합한 기술입니다.
조롱을 정당화하는 진짜 이야기
이제 양보할 부분입니다. 비판하는 사람들이 이걸 근거 없이 지어내는 건 아니니까요. 진짜로 나쁜 형태의 바이브 코딩이 존재하며, 그것은 조롱이 실제 대상을 갖게 될 만큼 흔합니다:
- 로그인 시스템을 만들고, 초록색 체크마크를 보고, 그 로그인 시스템이 어떤 데이터에 접근할 수 있는지, 토큰이 전혀 없는 요청이 들어오면 어떻게 되는지 한 번도 묻지 않은 채 출시하는 사람.
- 자연어 프롬프트로 만든 데이터베이스 쿼리를 사용자 입력이 이스케이프되지 않은 채 도달하는지 확인도 하지 않고 배포하는 것.
검증 기록은 빌드가 실행되었고 테스트가 통과했다는 것을 알려줄 수 있습니다. 하지만 그 테스트가 올바른 것을 다루었는지는 알려줄 수 없으며, 그것을 확인하지 않은 채 배포하는 것을 막아주지도 않습니다.
그것이 도구가 아무리 발전해도 변하지 않는 바닥선입니다. 당신이 만드는 특정 빌드에 있어 "완료"가 무엇을 의미해야 하는지 파악하고, 체크 표시를 맹목적으로 믿기보다 실제로 기록을 읽어보는 것은 여전히 당신의 책임입니다.
그것을 건너뛰는 것은 새로운 형태의 역량이 아닙니다. 새 옷을 입은 옛날식 부주의함일 뿐이며, 지금 받고 있는 평판을 정확히 받을 자격이 있습니다. 비판하는 사람들이 착각하는 지점은, 그런 실패 사례가 존재한다고 해서 규율 자체가 존재할 수 없다고 가정하는 것입니다. 규율은 존재할 수 있습니다. 다만 예전의 규율과는 다른 모습일 뿐이고, 문법적 유창함으로만 역량을 측정해온 사람들은 아직 그것을 알아볼 방법이 없는 것입니다.
몇 년만 더 지나면 이 단어도 "해커"가 "영리한 땜장이"에서 더 무서운 의미로 좁아졌다가 다시 느슨해진 것처럼 변할 것입니다. 결국 남는 것은 처음부터 중요했던 실제 구분, 즉 신중하게 명세를 작성하고 자신의 작업을 검증하는 빌더와 그렇지 않은 빌더의 차이입니다. 거기에 도달하기 위해 사용한 도구는 애초에 그다지 중요한 것이 아니었습니다.
