그런건 없어, 아직은.
토이 프로젝트가 아닌 진짜 프로덕트에서 바이브 코딩을 하면서 여러가지 고민이 많았다. 그 중 가장 큰 고민은 바로 속도였다. 바이브 코딩 시대에 남들은 미친듯이 속도를 추구하며 달려가고 있는데 왜 나는 그 속도가 안나는거지? 어떻게 하면 속도를 낼 수 있지?
이를테면 이런 얘기가 여기 저기서 들리는 것이다. 속도가 전부다. 코드는 더이상 귀하지 않다.
그래 알겠어. 근데 어떻게 하는거냐고. 바이브 코딩으로 엄청 빠르게 작업할 수 있지, 그런데 코드가 개판인데? 코드에 신경 쓰다 보면 바이브 코딩의 그 속도감은 찾을 수가 없고. 어떻게 하면 높은 품질의 코드를 빠른 속도로 생산해 낼 수 있을까? 한참 이런 고민을 하던 중 눈에 띄는 영상이 있었다.
제목부터 끝내준다. Vibe coding in prod. 토이 프로젝트 말고 진지한 프로덕트에서는 바이브 코딩을 어떻게 하는가. 심지어 발표자가 앤트로픽의 개발자다. 안 볼 수 없지.
이 영상을 반복해서 보다보니 생각 정리에 크게 도움이 되었다. 처음에는 ‘어떻게 하면 좋은 품질의 코드를 바이브 코딩으로 만들 수 있을까’의 관점에서 보다가 차차 다른 내용이 더 중요하다고 느껴졌다. 내가 보기에 이 영상의 핵심은 바로 이것이다.
아직까지는 진지한 제품을 만드는데 있어서 코어 아키텍처는 사람이 이해하고 있어야 하고, 기술 부채를 걱정하지 않는 종단에만 제한적으로 바이브 코딩을 활용할 수 있다는 이야기다. 좀 심하게 말하면 진짜 프로덕트에는 쓰지 말란 얘기다.
아참, 여기서 아주아주 중요한게 또 하나 있는데, ‘바이브 코딩’이라는 용어 그 자체다. 여기서 말하는 바이브 코딩은 안드레 카파시가 정의한 ‘코드 자체를 보지 않는’ 코딩을 말한다. 많은 사람들이 코딩 에이전트를 활용한 코딩을 아울러 바이브 코딩이라고 칭하고 있는데, 여기서는 그렇게 생각하면 논의의 핵심을 놓칠 수 있다.
이제야 이해가 됐다. 바이브 코딩을 하면 속도는 빠르지만 코드 품질은 형편 없었던 것도, 우리 팀이 바이브 코딩을 한다면서도 속도가 느렸던 것도. 바이브 코딩을 할 거면 아예 코드를 보지 말던가, 아니면 바이브 코딩을 안 하던가 했어야 했는데, 바이브 코딩을 한다면서 코드 품질을 동시에 챙기려고 했으니 처음부터 말이 안되는 이야기였던 거다.
여기에 쇄기를 박는 소식이 하나 더 나왔다. 바로 ‘바이브 코딩’이라는 용어를 유행시킨 장본인인 안드레 카파시가 최근에 X에 이런 글을 남긴 것이다.
글 전체를 요약하자면 여러 가지 LLM 보조 코딩 방식을 적절히 섞어서 쓰는게 좋다인데, 자신은 전체 중 75% 정도를 (전통적인? 방식인) 커서 탭 자동완성을 쓰고, 나머지는 코드 블록을 선택한 후 커서 옆에서 Claude Code / Codex 같은 걸 돌리는 방식을 쓰며, 본인이나 Cursor, Claude Code가 어떤 버그에 10분 이상 막혀 있으면 최종적으로 전체 코드를 GPT-5 pro 같은 녀석에게 주고 해결 시켜본다고 한다. 바이브 코딩은 1도 안하고 있는 것이다. ㅎㅎㅎㅎ
그래서 요즘은 “어떻게 하면 바이브 코딩을 잘 할 수 있을까?”하는 고민은 내려놨다. AI가 자동으로 뚝딱 만들어줬네, 며칠만에 뭘 만들었네하는 이야기들을 들어도 이제 부럽거나 초조하지 않다. 되려 더 좋은 코드와 설계를 알아볼 수 있는 눈을 어떻게 더 빨리 향상 시킬 것이냐가 고민이다.
앞서 소개한 Vibe Coding in Prod에도 언급되었듯 모델 성능은 앞으로 더더더 좋아질 것이고, 그때는 정말 코드를 안 보고 제품을 만드는 세상이 올지도 모른다. 앤드류 응이 영상에서 말한 것 처럼 3개월 후면 일하는 방식을 또 바꿔야 할 수도 있다. 그건 그때가서 고민하고, 일단은 기본기로 돌아가보련다.