바이브 코딩 숭배는 미쳐있다

2 weeks ago 16

Claude의 소스코드 유출 사건을 계기로, "바이브 코딩(vibe coding)"의 맹신이 실제 프로젝트 품질에 어떤 해를 끼치는지가 드러남
바이브 코딩은 코드 내부를 전혀 들여다보지 않는 것을 원칙으로 삼지만, 이는 순수한 미신에 불과하며 실제로는 계획 파일, 스킬, 규칙 등 인간의 구조 설계가 반드시 수반됨
AI는 코드 중복·기술 부채 정리 같은 작업에 실제로 매우 뛰어나지만, 이를 활용하려면 인간이 직접 코드를 살피고 문제를 파악해 AI에게 설명해야 함
AI가 자발적으로 "스파게티 코드가 있으니 정리해야겠다"고 인식하는 경우는 드물며, 인간이 방향과 맥락을 먼저 제공할 때 높은 품질의 결과물이 나옴
“나쁜 소프트웨어는 개발자의 선택” 이라는 문구처럼, 품질 저하는 AI가 아닌 의사결정의 결과임
즉, 소프트웨어 품질 저하는 AI 탓이 아니라 개발자가 스스로 내리는 선택

Claude 소스코드 유출과 바이브 코딩의 문제

바이브 코딩은 코드 내부에 어떤 기여도 하지 않고, 심지어 들여다보지도 않는 것을 원칙으로 삼는 방식
그러나 순수한 바이브 코딩은 미신(Myth) 임 — 실제로는 계획 파일(할 일 목록), 스킬, 규칙 등 인간이 만든 프레임워크가 반드시 존재하며, 이 구조 없이 AI는 매우 낮은 성능을 발휘함
코드는 영어로 작성되어 있어 누구나 읽을 수 있음에도, "내부를 보는 것은 반칙"이라는 논리로 개발자들이 직접 확인을 거부함
실제로 인간 한 명이 코드를 살펴본 결과 에이전트와 툴 사이에 대규모 중복이 존재한다는 사실이 발견되었으며, 이는 누군가가 잠깐만 살펴봤다면 쉽게 인지할 수 있는 문제였음

소프트웨어 프로젝트는 흔히 기술 부채를 안고 출발하며, 과거에는 이를 정리하는 데만 1년이 걸리는 경우도 있었음
AI를 활용하면 이 정리 작업을 수 주 만에 완료하거나, 새 기능 개발과 병행하면서 점진적으로 해소할 수 있음
AI는 코드 정리에 매우 뛰어나지만, 스스로 문제를 감지하는 능력은 부족함 — 인간이 "여기 스파게티 코드가 있다"고 알려주고 가이드를 제공할 때 좋은 결과가 나옴

중복 문제를 해결하는 올바른 방법으로, 다음과 같은 단계를 제시:
- 에이전트와 툴 양쪽에 해당하는 항목 목록 작성
- 예시 검토 후 각 항목이 에이전트인지 툴인지 판단
- 전체 기준 논의 및 일반 가이드라인 수립
- 전체 항목 감사 후 잘못 분류된 항목 수정
- 양쪽에 모두 존재하는 항목은 두 버전을 검토해 하나로 통합
Ask 모드가 이 과정을 위한 것으로, 예시를 함께 검토하고 AI가 지나치게 동의하려 할 때 잘못된 부분을 바로잡는 과정이 핵심
충분한 대화 후에는 AI가 원샷(one-shot)처럼 보이는 결과를 냈다고 느낄 수 있지만, 실제로는 사전에 인간과의 많은 상호작용이 전제된 결과임
Claude 팀은 이 과정 없이 독식을 극단적으로 적용해, 코드 내부를 잠깐 살피고 문제를 설명하는 최소한의 노력도 거부하고 있음

본인의 워크플로우 예시: 대화 시작 시 "이 코드베이스에서 도달 불가능한 코드를 감사하자" 또는 "이 함수는 눈이 아프다"고 말하며 대화를 시작함
실행 가능한 방향이 나올 때까지 대화를 계속하고, 해야 할 일을 설명한 뒤 AI가 어리석은 말을 멈출 때까지 계속 논의함
이후 계획을 세우고 빌드를 실행하는 것이 일상적인 방식