"바이브 코딩 숭배는 미쳤다" — Bram Cohen 기고 및 커뮤니티 반응 심층 분석
원문 출처
- Bram Cohen 블로그: The Cult Of Vibe Coding Is Insane (2026년 4월 6일)
- GeekNews 커뮤니티 반응: Hacker News 의견 번역
- 작성 기준일: 2026년 4월 7일
배경: Claude Code 소스 코드 유출 사건
이 글을 이해하려면 먼저 사건의 발단이 된 Claude Code 소스 코드 유출 사태를 알아야 한다. 2026년 3월 31일, Anthropic은 자사의 AI 코딩 어시스턴트인 Claude Code의 npm 패키지(버전 2.1.88)를 배포하는 과정에서 .npmignore 파일에 *.map 항목을 추가하는 것을 실수로 누락했다. 그 결과, Bun 런타임이 자동 생성한 59.8MB 크기의 JavaScript 소스 맵 파일이 공개 npm 레지스트리에 그대로 올라갔다.
이 소스 맵 파일을 역산하면 원본 TypeScript 소스를 그대로 복원할 수 있었다. Solayer Labs의 인턴 개발자 Chaofan Shou(@Fried_rice)가 이를 X(트위터)에 최초 공개했고, 해당 게시물은 수 시간 만에 2,880만 회 이상의 조회수를 기록했다. 유출된 코드베이스는 GitHub에 미러링되며 순식간에 84,000개 이상의 스타와 82,000개 이상의 포크를 달성했다.
Anthropic의 Claude Code 총괄인 Boris Cherny는 이것이 “단순한 개발자 실수(plain developer error)”였음을 인정하면서, “Claude Code에 대한 나의 기여 100%는 Claude Code가 직접 작성한 것”이라는 발언을 남겼다. 이 한 문장이 이후 논쟁의 핵심이 된다. Anthropic 측은 “민감한 고객 데이터나 자격증명은 포함되지 않았으며, 이는 보안 침해가 아닌 배포 패키징 과정의 인적 오류”라고 공식 발표했다. 이 사건은 같은 주에 CMS 설정 오류로 내부 문서 약 3,000건이 노출된 ‘Mythos 모델 스펙 유출’ 사고에 이어 발생한 것으로, 불과 일주일 만에 두 번의 유출 사고가 겹쳤다는 점에서 업계의 주목을 받았다.
유출된 코드베이스의 규모는 방대했다. TypeScript 파일 약 1,906개, 총 51만 2,000여 줄의 코드, 44개의 숨겨진 기능 플래그가 포함되어 있었으며, 항상 실행되는 백그라운드 에이전트인 ‘KAIROS’, ‘Undercover Mode’, ‘autoDream’ 등 공개되지 않은 기능들이 다수 발견되었다. 특히 내부 코드명 ‘Capybara’가 차세대 Claude 모델 패밀리를 가리키는 것으로 확인되었고, Anthropic 직원들이 Claude Code를 사용해 오픈소스 저장소에 ‘stealth’ 방식으로 기여하고 있다는 사실도 드러났다.
Bram Cohen의 주장: “바이브 코딩 숭배는 미쳤다”
저자 소개
이 글의 필자 Bram Cohen은 단순한 블로거가 아니다. 그는 P2P 파일 공유 프로토콜인 BitTorrent의 창시자로, 분산 시스템과 네트워크 프로토콜 설계에서 수십 년의 경험을 가진 저명한 엔지니어다. 이 점에서 그의 발언은 단순한 비평가의 관점이 아닌, 깊은 기술적 배경 위에서 나온 것임을 전제해야 한다.
도그푸딩(Dogfooding)이란 무엇이며, 어떻게 광신이 되는가
Cohen은 이번 Claude Code 유출 사건의 근본 원인을 “도그푸딩의 극단화” 에서 찾는다. 도그푸딩(Dogfooding)이란 기업이 자신의 제품을 직접 사용하는 관행을 말한다. 이것은 원래 좋은 원칙이다. 자신이 만든 도구를 실제로 써봄으로써 버그를 발견하고, 사용자 경험을 이해하고, 개선점을 찾을 수 있다. 그런데 Anthropic의 경우 이 원칙이 종교적 광신의 수준으로 변질되었다는 것이 Cohen의 핵심 주장이다.
구체적으로 Anthropic 팀은 Claude Code를 사용해 Claude Code를 개발하는 과정에서, 실제로 코드를 들여다보는 행위 자체를 금기시했다는 것이다. 이것이 바로 ‘바이브 코딩(Vibe Coding)’의 극단적 형태다. 인간 개발자는 어떤 코드가 생성되는지 보지 않고, AI와 고수준의 대화만 나누며, 구현의 세부 사항에는 전혀 개입하지 않는 방식이다.
“순수한 바이브 코딩은 신화다”
Cohen은 바이브 코딩 그 자체를 완전히 부정하지는 않는다. 그러나 “순수한 바이브 코딩”이란 애초에 존재하지 않는 신화라고 단언한다. 그 이유는 다음과 같다.
첫째, AI가 생각하고 출력하는 언어는 결국 인간의 언어다. LLM의 내부 추론 과정 자체가 수십억 명의 인간이 수천 년에 걸쳐 쌓아올린 언어라는 인류 공동의 자산 위에 서 있다. 둘째, 개발팀은 여전히 ‘플랜 파일(계획 문서)’, 스킬, 규칙 등 AI가 작동하는 데 필요한 프레임워크를 구축한다. 이 프레임워크 없이 AI는 제대로 작동하지 않는다. 즉, 인간의 구조화된 개입은 어떤 형태로든 반드시 존재한다.
그렇다면 Anthropic 팀이 거부한 것은 정확히 무엇인가? 그것은 코드를 직접 읽고, 문제를 육안으로 확인하고, 그 내용을 바탕으로 AI에게 높은 수준의 지침을 제공하는 행위다. Cohen은 이것을 “바이브 코딩 위반”으로 간주하는 태도 자체가 이미 교조주의적 광신의 영역에 들어간 것이라고 본다. 실제로 외부인이 코드를 들여다보고서야 “에이전트(agent)이기도 하고 도구(tool)이기도 한” 중복 항목이 다수 존재한다는 사실을 발견했는데, 내부 팀은 코드를 ‘보지 않는다’는 원칙 때문에 이를 전혀 인지하지 못했다.
기술 부채(Tech Debt)와 AI의 역할
Cohen은 소프트웨어 역사 전반에 걸쳐 공통적으로 나타나는 현상 하나를 지적한다. “프로젝트는 죄악 속에서 태어난다(Projects are born in sin).” 어떤 소프트웨어든 초기에는 빠른 출시를 위해 즉흥적으로 설계된 코드, 임시방편, 중복 구조들이 쌓이게 된다. 그리고 이 기술 부채가 너무 커지면, 순수하게 좋은 코드를 지향한다면 1년 내내 아무것도 새로 만들지 않고 정리만 해야 하는 상황이 된다.
그런데 AI의 등장이 이 방정식을 바꿨다. AI를 활용하면 몇 주 만에 상당한 규모의 기술 부채를 해소할 수 있다. 새로운 기능을 개발하면서 동시에 레거시 코드를 정리하는 것도 가능해졌다. Cohen의 주장은 이 새로운 가능성을 외면하는 것이 곧 나쁜 코드를 의식적으로 선택하는 행위라는 것이다.
올바른 방법: 인간-AI 협업의 실제 모습
Cohen은 자신이 일상적으로 실천하는 방법을 구체적으로 제시한다. 그는 코드를 직접 보면서 문제를 포착하고, 그것을 AI와의 대화 주제로 삼는다. 예를 들어 “이 코드베이스에서 도달 불가능한 코드를 감사해보자(Let’s audit this codebase for unreachable code)”라든가, “이 함수는 눈이 아프다(This function makes my eyes bleed)”와 같이 시작한다.
이후 AI와 충분한 대화를 나누면서, AI가 지나치게 동의만 하려 할 때 이를 교정하고, 실제 문제와 해결 방향에 대한 공통된 이해를 쌓는다. 그 다음 AI에게 계획을 세우도록 지시하고, 실제 구현을 맡긴다. 이 과정에서 AI가 마치 ‘원샷(one-shot)’으로 복잡한 작업을 해결하는 것처럼 보이지만, 실제로는 그 전에 인간과의 충분한 사전 대화가 있었기 때문에 가능한 것이다. 즉, AI의 탁월한 성능은 인간의 사전 개입이 있을 때 비로소 최대화된다.
이 접근법을 Claude Code의 중복 코드 문제에 적용한다면 어떻게 될까? Cohen은 구체적인 방법을 제시한다. 인간이 “에이전트이기도 하고 도구이기도 한 항목들이 많다. 예시들을 함께 살펴보고, 각각이 에이전트가 되어야 하는지 도구가 되어야 하는지 얘기해보자”라고 시작하면 된다. 일반적인 기준을 토론으로 합의한 뒤, 전체 코드베이스를 감사하고, 잘못된 유형에 있는 것들을 변환하고, 양쪽에 걸쳐 있는 것들은 두 버전을 읽어보고 최선의 내용을 통합한 하나의 문서로 정리하면 된다. 이 과정을 AI는 매우 잘 수행할 수 있다.
결론: “나쁜 소프트웨어는 당신이 선택하는 것이다”
Cohen의 결론은 냉혹하고 단호하다. AI를 코딩에 사용한다고 해서 코드 품질이 낮아야 하는 필연적인 이유는 없다. 사람들이 나쁜 품질의 소프트웨어를 가지게 되는 것은 그들이 그런 선택을 했기 때문이다. “AI 없이 과로한 인간들이 만든 라이브러리”와 씨름하느라 지난 일주일을 힘들게 보냈다며, 나쁜 소프트웨어는 도구의 문제가 아니라 결정의 문제임을 강조한다.
Hacker News / GeekNews 커뮤니티의 반응 분석
이 글에 대한 개발자 커뮤니티의 반응은 단순한 찬반 양론을 넘어서 여러 층위의 복잡한 시각을 보여준다.
“코드 품질이 나쁜데 왜 성공했나?” — 제품-시장 적합성(PMF) 논거
커뮤니티에서 가장 많은 공감을 얻은 시각 중 하나는 역설적인 관찰이다. Claude Code는 많은 이들이 “충격적”이라고 표현한 코드 품질로 만들어졌음에도 불구하고, 출시 1년도 안 돼 연간 반복 매출(ARR) 25억 달러를 달성한 제품이다. 이것이 우리에게 시사하는 바는 무엇인가?
커뮤니티의 상당수는 이것이 오히려 “전통적인 코드 품질 규칙을 어겨도 성공할 수 있다”는 증거라고 해석한다. 그리고 이런 일은 이전에도 항상 있어왔다는 것이다. 마감일에 쫓겨 임시방편으로 만든 코드가 프로덕션에 그대로 남는 것은 대기업에서도, 스타트업에서도, 심지어 개인 프로젝트의 첫 커밋에서도 흔하게 벌어진다.
또한 Claude Code는 근본적으로 “단순한 구조의 제품”이며, 진짜 가치는 내부 코드가 아닌 모델 자체에 있다는 관점도 설득력을 얻었다. 코드 품질이 낮아도 큰 문제가 되지 않는 저위험 영역에서, AI가 쓴 코드가 운영을 맡는 것은 충분히 합리적인 선택일 수 있다는 것이다. 실제로 Claude Code의 경쟁사들은 소스코드가 공개되더라도 모델 가중치와 Anthropic의 완성된 서비스 생태계 없이는 동일한 경험을 재현할 수 없다.
“바이브 코딩은 스펙트럼이다” — AI 개입 수준의 다층적 이해
커뮤니티에서 가장 풍부한 토론을 이끌어낸 주제는 바이브 코딩의 스펙트럼 개념이다. 여러 개발자들이 자신이 어느 수준에서 AI와 협업하는지를 ‘레벨’로 표현하며 공유했다.
컴퓨터 비전 분야의 한 개발자는 자신의 앱을 이렇게 구분했다. 알고리즘과 렌더링 파이프라인은 AI 개입이 오히려 방해가 되는 Level 0, UI는 완전히 AI에 맡기는 Level 7, 미들웨어는 그 중간 어딘가. 이처럼 코드의 영역에 따라 적절한 AI 개입 수준을 달리 적용하는 것이 핵심 기술이라는 인식이 공유되었다.
또 다른 개발자는 TDD, 타입 안정성, 스펙 작성 등 안전장치를 충분히 갖춘 상태에서 Level 5 정도의 협업을 유지한다고 했다. 동적 언어에서는 이 이상 나아가는 것이 불안하고, 만약 더 높은 수준으로 가려면 차라리 정적 타입 언어로 완전히 전환하는 것이 낫다는 의견도 있었다.
재미있는 것은 회사 업무와 개인 프로젝트 사이의 괴리를 고백하는 목소리도 있었다는 점이다. 회사에서는 Level 4를 유지하지만, 개인 프로젝트에서는 어느새 Level 6까지 올라간다는 것이다. 여기서 작동하는 것이 어떻게 작동하는지 완전히 이해하지 못한 채 그냥 받아들이는 유혹이 있다는 솔직한 고백도 있었다.
“핵심은 인간의 판단력 유지다” — Dogfooding 논거의 재해석
이 토론에서 특히 날카로운 지적이 하나 있었다. 논점은 코드 품질 그 자체가 아니라, 사용자가 AI의 결과물을 비판적으로 평가할 수 있는가 하는 것이다.
경험 많은 엔지니어가 판단력을 유지하며 AI를 사용하는 것과, 판단 자체를 AI에 맡기는 것은 완전히 다른 행위다. 문제는 현재 AI 코딩 도구들이 이 두 가지를 구분하지 못하고, 마케팅은 후자(비판적 판단 없이 AI에 의존하는 것)에 맞춰져 있다는 점이다. 이것은 Claude Code 유출 사태가 드러낸 가장 깊은 층위의 문제다.
“반복(iteration)의 경제학” — 바이브 코딩 지지자들의 논거
바이브 코딩을 옹호하는 측의 논거도 체계적으로 소개되었다. LLM은 인간보다 훨씬 빠르고 저렴하게 반복할 수 있다. 인간은 코드를 작성하고, 검증하고, 수정하는 각 단계마다 상당한 시간과 인지적 비용을 지불해야 한다. 그러나 LLM은 토큰 비용만으로 이 사이클을 몇 초 만에 수십 번 반복할 수 있다.
따라서 코드 품질이 처음부터 완벽하지 않아도, AI가 빠르게 반복하면서 개선할 수 있다면 문제없다는 것이다. 다만 이에 회의적인 목소리도 있었다. 실제로 이 접근법이 깨지는 사례를 너무 많이 봤다는 것이다. AI가 더 발전한다면 이 논리가 맞을 수 있지만, 현재 수준에서는 과신하기 이르다는 신중론이다.
“코드 정리야말로 Claude Code의 최고 용도” — 실용적 접근
놀랍게도 Claude Code를 적극적으로 사용하는 개발자들 중 일부는 Cohen의 주장에 실질적으로 동의하는 경험을 공유했다. 이들이 Claude Code를 가장 가치 있게 쓰는 용도가 바로 코드 품질 개선이라는 것이다. 반복적인 테스트 패턴 정리, JSON 직렬화 일관성 유지, 중복 코드 제거 등의 작업을 AI가 거의 무료에 가까운 비용으로 처리해준다.
한 개발자는 Opus, GPT, Gemini 등 여러 모델을 병렬로 돌려 버그 탐지와 코드 개선을 시키고, 각 모델의 결과를 교차 검증한 뒤 최종 목록을 만들어 수정하는 방법을 공유했다. 불필요한 변경도 많지만, 실제로 잡아내는 문제들의 가치가 충분하다고 평가했다.
“클레이튼 크리스텐슨의 혁신 이론” — 산업 구조적 해석
이 현상을 Clayton Christensen의 파괴적 혁신(Disruptive Innovation) 이론으로 해석하는 시각도 흥미롭다. 기존 기업들은 수익성이 높은 현재 제품과 방법론에 안주하면서, 새로운 저품질 기술을 무시하는 경향이 있다. 그러나 그 기술이 충분히 발전하면 결국 시장 전체를 뒤집는다는 것이다.
Claude Code도 이미 “충분히 괜찮은(good enough)” 수준에 도달했고, AI가 계속 발전한다면 결국 수작업 코드를 능가할 것이라는 전망이 나왔다. 설령 AI 발전이 멈추더라도, 현재 모델을 중심으로 한 새로운 툴링과 패턴이 만들어질 것이라는 낙관론도 있었다. 다만 이런 낙관론이 지나쳐, 경영진이 테스트와 코드 리뷰 자체를 없애려 한다는 이야기까지 나온다는 우려의 목소리도 있었다.
바이브 코딩 커뮤니티의 분류학
이 토론에서 한 참가자는 바이브 코딩을 둘러싼 사람들을 흥미롭게 유형화했다. 첫 번째는 금전적 이해관계자들로, AI 도구 기업이나 관련 투자자들이다. 두 번째는 코딩에 지쳐 새로운 것을 배우기 싫어하는 개발자들이다. 세 번째는 처음으로 무언가를 만들어보는 입문자들로, 이들은 창작의 순수한 즐거움을 느끼며 AI를 활용한다. 그리고 네 번째는 조용하지만 생산성 높은 중간층으로, 낙관적이면서도 경험이 풍부한 실용주의자들이다.
또 다른 참가자는 여기에 중요한 다섯 번째 유형을 추가했다. 코딩 자체를 사랑하지만, 상상한 것을 실제로 구현하기까지 너무 오랜 시간이 걸리는 것에 좌절했던 고성과 개발자들이다. 이들에게 AI는 창작과 구현 사이의 격차를 줄여주는 해방구다. 품질을 유지하면서 속도를 높이는 방법을 배우고 싶다는 것이 이들의 지향점이다.
마지막으로, 지난 10년간의 소프트웨어 산업을 “불필요한 복잡성의 시대”로 규정하는 시각도 있었다. 대기업의 문제와 구조를 소규모 프로젝트가 불필요하게 따라 하느라 생산성이 낮아지고 피로감만 쌓였는데, AI 덕분에 이런 복잡성을 건너뛰고 바로 결과를 얻을 수 있게 되었다는 것이다.
종합 분석: 이 논쟁이 시사하는 것
1. “좋은 코드”의 의미가 재정의되고 있다
Claude Code 유출 사태와 이를 둘러싼 논쟁은 소프트웨어 개발에서 “좋은 코드”가 무엇을 의미하는가에 대한 근본적인 질문을 제기한다. 아키텍처의 우아함, 중복의 최소화, 가독성 — 이런 전통적 기준으로는 형편없는 코드가, 25억 달러의 ARR을 달성한 제품을 만들어냈다. 이것이 “코드 품질은 중요하지 않다”는 뜻인가? 아니면 “코드 품질의 정의를 바꿔야 한다”는 신호인가?
Bram Cohen은 후자의 입장이다. 그는 AI 시대의 코드 품질 기준이 “읽기 좋은가”가 아니라 “AI와 인간이 함께 효과적으로 유지보수하고 발전시킬 수 있는가”로 이동해야 한다고 암시한다.
2. 인간의 역할은 사라지지 않는다 — 다만 변한다
Cohen의 가장 중요한 통찰 중 하나는 “AI가 코드를 쓴다고 해서 인간의 역할이 사라지는 것이 아니다”라는 점이다. 인간의 역할은 코드를 작성하는 것에서 문제를 포착하고, 방향을 설정하고, AI의 출력을 비판적으로 평가하는 것으로 이동한다. 이 역할을 포기하고 AI에 모든 것을 맡기는 것이 바로 그가 비판하는 “바이브 코딩 광신”이다.
커뮤니티의 토론도 이 점을 지지한다. 경험 있는 엔지니어가 판단력을 유지하며 AI를 사용하는 것과, 판단 자체를 AI에 위임하는 것은 결과적으로 완전히 다른 소프트웨어를 만들어낸다.
3. 보안 위험은 별개의 심각한 문제다
이번 유출 사태에서 언론의 초점은 주로 코드 품질 논쟁에 맞춰졌지만, 실제로 더 심각한 문제는 보안이었다. 유출과 동시에 악성 npm 패키지들이 등장했고, 원격 접근 트로이목마(RAT)를 포함한 악성 axios 버전이 배포되었다. GitHub에는 Vidar 인포스틸러와 GhostSocks를 배포하는 위장 저장소가 만들어졌다. 소스 코드 유출이 단순한 지적 재산권 문제를 넘어 실제 사용자 보안에 직접적인 위협이 될 수 있음을 보여준 사례다.
4. “AI가 쓴 코드”의 저작권과 윤리적 역설
Anthropic이 유출된 코드를 기반으로 한 GitHub 저장소들에 DMCA 통지를 보내는 과정에서, 자사의 공식 예제 코드 저장소의 포크에도 실수로 통지를 보내는 사태가 벌어졌다. 더 나아가, 타인의 코드를 AI로 재작성하는 것이 저작권 침해에 해당하지 않는다고 주장해온 AI 업계의 논리가, 이번에는 Claude Code의 소스를 Python과 Rust로 재작성한 클린룸 구현체들에 그대로 적용되었다. 이것은 AI 산업 전체가 직면한 저작권 논쟁의 아이러니한 자화상이다.
결론
“바이브 코딩 숭배는 미쳤다”는 Bram Cohen의 글은 2026년 3월 Claude Code 소스 코드 유출 사태를 계기로, AI 보조 소프트웨어 개발의 본질적인 문제를 정면으로 제기한다. 그의 핵심 주장은 명료하다. AI를 쓴다고 해서 코드 품질이 희생되어야 하는 것은 아니며, 인간이 코드를 보고, 문제를 포착하고, AI에게 방향을 제시하는 역할을 포기하는 순간 바이브 코딩은 광신이 된다.
개발자 커뮤니티의 반응은 이보다 훨씬 복잡하다. 나쁜 코드가 엄청난 성공을 거둔 현실을 앞에 두고, 사람들은 “코드 품질이 정말 중요한가”, “AI 개입의 적절한 수준은 어디인가”, “인간 판단력의 역할은 무엇인가”라는 질문을 각자의 경험과 맥락 속에서 다르게 답하고 있다.
분명한 것은 이 논쟁이 아직 끝나지 않았다는 것이다. AI가 더 발전할수록, 그리고 더 많은 소프트웨어가 AI의 손으로 만들어질수록, 인간 개발자의 역할과 코드 품질의 정의는 계속해서 재조정될 것이다. 그 재조정의 방향을 결정하는 것은 결국 개별 팀과 개발자들의 선택이다. Bram Cohen의 말처럼, 나쁜 소프트웨어는 운명이 아니라 선택이다.
이 문서는 2026년 4월 7일 기준의 공개 정보를 바탕으로 작성되었습니다.