바이브 코딩의 광신도는 미쳤다
source https://bramcohen.com/p/the-cult-of-vibe-coding-is-insane
Claude 소스 코드가 유출됐고, 사람들은 그 코드가 얼마나 엉망인지 신나게 비웃고 있다. 이런 일이 어떻게 벌어질 수 있냐고 생각할 수도 있다. 답은, dogfooding이 선을 한참 넘었기 때문이다.
Dogfooding은 자기 제품을 직접 써보는 걸 말한다. 원래는 좋은 생각이다. 그런데 이게 어느 순간 합리적인 한계를 넘어 거의 컬트처럼 굴러갈 수 있다. 여기서는 그게 바로 vibe coding이라는 형태로 나타난다. 내부가 어떻게 돌아가는지에는 아예 손도 대지 않고, 심지어 들여다보지도 않는 걸 원칙처럼 여기는 식이다.
물론 이건 터무니없는 얘기다. 여기서 인간의 기여가 없는 것도 아니다. 우선 인간의 언어를 쓰고 있고, 기계도 내부 사고 과정에서 그 똑같은 인간 언어를 쓴다. 개발팀 바깥의 다른 인간들이 그 기반 작업을 다 해놨고, 그래서 당신 팀은 순수한 vibe coding만 하고 있다고 주장할 수도 있겠다. 하지만 실제로는 그것도 아니다. 여전히 plan file(그럴듯하게 말한 거고, 그냥 todo list다), skills, rules 같은 인프라를 직접 만들고 있다. 기계는 프레임워크를 잡아주지 않으면 정말 형편없이 돌아간다.
그러니까 순수한 vibe coding이라는 건 신화에 가깝다. 그런데도 다들 그걸 하려 들고, 그 결과 꽤 우스꽝스러운 상황이 나온다. 예를 들면, 어떤 인간이 실제로 들여다보고 나서 중복이 엄청 많다는 걸 발견했다. 여기서 이런 의문이 들 수 있다. 개발자들이 왜 그냥 직접 가서 안 봤지? 다시 말하지만, vibe coding이니까. 내부를 들여다보는 건 cheating이다. 기계가 뭘 하고 있는지에 대해 두루뭉술하게 대화만 나누는 게 허용된 전부다.
이게 특히 더 우스운 건, 내부에 일반인은 이해 못 할 정도로 엄청 기술적인 무언가가 숨어 있는 것도 아니라는 점이다. 이 코드는 영어로 쓰여 있다. 누구든 읽을 수 있다. 조금만 훑어봐도 “와, agents이면서 tools인 것들이 엄청 많네. 이건 좀 중복 아닌가, 정리해야겠는데” 같은 생각은 충분히 할 수 있다.
이런 일은 소프트웨어 업계에서 늘 벌어진다. 프로젝트는 대개 태생부터 죄를 짓고 시작한다. 예전에는 소프트웨어 프로젝트에 기술 부채가 너무 많아서, 순수하게 개발 관점에서만 맞는 선택을 하려면 다음 1년 내내 새 기능은 하나도 못 만들고 청소만 해야 하는 경우가 흔했다. 그런데 이제는 AI로 코딩할 수 있으니, 이런 정리를 몇 주 만에 끝내기도 하고, 새 기능을 만들면서 조금 더 천천히 부채를 갚아나갈 수도 있다. 그리고 그렇게 해야 한다. 훨씬 더 높은 품질을 목표로 해야 한다. 엉망진창을 정리하는 일은 AI가 실제로 꽤 잘하는 분야다.
이 경우에도 인간은 기계에게 이렇게 말할 수 있었을 거다. “agents이면서 tools인 것들이 너무 많아. 전부 리스트업하고, 몇 가지 예시를 같이 보자. 내가 어떤 건 agent여야 하고 어떤 건 tool이어야 하는지 말해줄게. 그걸 바탕으로 같이 일반적인 가이드라인을 정하자. 그런 다음 전체를 audit해서 각각 어느 범주에 속하는지 정하고, 잘못된 타입에 들어간 건 옮기자. 둘 다 있는 것들은 두 버전을 다 읽어보고, 좋은 부분만 남겨서 하나의 문서로 합치자.”
AI는 사실 이런 일을 꽤 잘한다. 특히 그 전에 대화를 충분히 해두면 더 그렇다. Ask mode가 바로 그래서 있는 거다. 몇 가지 예시를 같이 보면서, 왜 그렇게 판단하는지 설명해주고, AI가 비위 맞추려고 맞장구치다가 틀린 말을 하면 바로잡는다. 이런 식으로 충분히 주고받고 나면, 겉보기엔 거의 one-shot으로 일을 끝내는 것처럼 보일 때가 많다. 하지만 실제로는 전혀 one-shot이 아니다. 그 전에 인간과 AI 사이에 많은 왕복이 있었다. 다만 막상 일을 시작할 때는, 이상한 edge case나 자주 터질 문제들을 이미 정리해뒀기 때문에 훨씬 빠르게 치고 나가는 것이다.
그런데 Claude 팀은 그렇게 하지 않는다. dogfooding을 완전히 과하게 밀어붙인 나머지, 내부를 몇 분만 들여다보면서 뭐가 망가졌는지 확인하고 그 엉망인 상태를 기계에 설명해주는 일조차 완강히 거부하고 있다. 사실 그것조차 vibe coding 개념을 크게 어기는 일도 아니다. 내부를 조금 읽긴 하지만, 어디까지나 문제를 어떻게 풀어야 하는지에 대한 높은 수준의 개념적이고 추상적인 아이디어만 주는 거니까. 실제 글쓰기 작업은 거의 전부, 아니 말 그대로 전부를 기계가 하고 있다 해도 될 정도다.
나는 몇 달째 이런 식으로 작업하고 있다. 대화를 시작할 때 “이 코드베이스에 unreachable code가 있는지 audit해보자”거나 “이 함수는 보기만 해도 눈에서 피가 난다” 같은 말을 던지고, 거기서 실행 가능한 뭔가가 나올 때까지 계속 이야기를 한다. 그러다 방향이 잡히면 내가 어떻게 해야 한다고 생각하는지 설명하고, 내가 더 이상 보탤 생각이 없고 기계도 교정이 필요한 멍청한 말을 그만할 때까지 대화를 이어간다. 그다음에 plan을 만들라고 하고 build를 누른다. 이게 내 일상이다. AI는 스스로 “여기 spaghetti code가 너무 많네, 정리해야겠다”라고 눈치채는 데는 정말 약하다. 하지만 여기가 spaghetti code라고 말해주고 어느 정도 가이드를 주면, 아니 가끔은 가이드가 없어도, 꽤 괜찮게 엉킨 코드를 정리해낸다.
AI로 코딩한다고 해서 반드시 저품질 소프트웨어를 만들게 되는 건 아니다. 오늘 내 hot take는 그거다. 소프트웨어 품질이 엉망인 건 AI를 써서가 아니라, 그냥 그렇게 만들기로 선택했기 때문이다. 나는 지난 일주일 동안 AI 도움도 없이, 돈은 더럽게 많이 받는 고깃덩어리들이 만든 라이브러리를 붙잡고 컴퓨터 앞에서 계속 소리 질렀다. 형편없는 소프트웨어는 선택이다. 그건 당신이 책임져야 한다. 더 잘해야 한다.
