브램 코헨이 본 바이브 코딩의 함정, 코드를 안 보는 문화가 더 위험하다

한눈에 보기

• 글 공개: 2026년 4월 5일 브램 코헨이 The Cult Of Vibe Coding Is Insane 공개
• 핵심 비판: AI에게 맡긴 뒤 사람이 코드를 아예 보지 않으려는 태도
• 쉬운 요약: 계획표와 규칙을 짜는 순간 사람은 이미 개발 과정에 들어와 있음
• 실무 결론: AI는 중복 찾기와 정리에 강하지만 구조 판단과 마지막 점검은 사람이 맡아야 함
• 함께 볼 자료: 구글, DORA, 깃클리어도 빠른 작성과 늘어나는 검증 부담을 함께 짚음
• 한국 시사점: 출시 속도보다 검토 가능한 양, 작은 변경 단위, 책임자 지정이 더 중요

서론

브램 코헨은 2026년 4월 5일 개인 블로그에 The Cult Of Vibe Coding Is Insane라는 글을 올렸다. 제목은 세지만, 하고 싶은 말은 분명하다. AI가 코드를 빨리 쓰는 것보다, 사람이 코드를 읽지 않으려는 문화가 더 큰 문제라는 것이다.

그는 글의 출발점으로 클로드 소스 코드 유출 뒤 퍼진 조롱 섞인 반응을 든다. 다만 이 글은 사건을 쫓는 취재 기사라기보다, 최근 AI 코딩 문화에 대한 비판 칼럼에 가깝다. 핵심은 한 문장으로 정리된다. AI가 대신 써 줬다고 해서 사람의 점검 책임까지 사라지는 것은 아니다.

https://gitstar.space

GitStar - GitHub Rankings, Package Signals, and Weekly Digests

 

1. 브램 코헨이 정면으로 비판한 것

• 출발점: 자기 도구를 직접 써 보는 문화는 필요
• 문제 지점: 그 문화가 지나쳐서 사람이 내부를 보지 않는 규칙처럼 굳어짐
• 핵심 반론: 작업 계획과 규칙을 세우는 순간 이미 사람은 개발에 참여하고 있음
• 품질 경고: 읽을 수 있는 코드를 읽지 않으면 중복과 엉킨 구조가 남기 쉬움

브램 코헨은 "AI가 썼으니 사람은 손대지 말자"는 태도를 현실과 맞지 않는다고 본다. 사람이 자연어로 지시를 내리고, 작업 순서를 정하고, 어떤 기준으로 고칠지 말해 주는 순간 이미 개발은 사람과 AI가 함께 하는 일이라는 뜻이다.

이 때문에 그는 순수한 바이브 코딩이라는 말 자체를 거의 신화에 가깝게 본다. 사람이 기준을 세우고도 정작 결과물은 보지 않겠다고 하면, 책임만 빠진 채 속도만 남기 쉽기 때문이다.

문제는 여기서 한 걸음 더 나간 태도다. 이미 사람 손으로 계획과 규칙을 만들고 있으면서도, 막상 코드 안쪽에서 중복과 혼선을 발견했을 때는 "직접 보면 안 된다"며 손을 떼는 분위기다. 브램 코헨은 이것을 기술 한계보다 문화적 선택에 가깝다고 본다.

2. 원문을 쉬운 말로 옮기면 이런 뜻이다

• 좋은 방식: AI를 써도 결과를 읽고 문제를 짚을 수 있어야 함
• 나쁜 방식: 코드가 엉켜 보여도 "내가 보면 안 된다"며 지나침
• AI의 장점: 전체 훑기, 중복 찾기, 정리 초안 만들기
• 사람의 장점: 예시 고르기, 기준 세우기, 틀린 판단 바로잡기
• 권하는 흐름: 먼저 묻고 -> 계획하고 -> 실행하기

브램 코헨이 말하는 핵심은 복잡하지 않다. AI에게 막연하게 "알아서 정리해 줘"라고 맡기지 말고, 먼저 무엇이 문제인지 사람 말로 분명히 적어 주라는 것이다.

예를 들어 코드 안에 같은 기능이 여러 군데 겹쳐 있다면, 사람이 먼저 "중복이 어디 있는지 찾아 보자", "이 기능은 어떤 역할인지 나눠 보자", "겹치는 문서는 하나로 합치자" 같은 기준을 세워야 한다. 그다음 AI가 속도를 내면 결과가 훨씬 낫다는 설명이다.

브램 코헨은 이런 대화를 거친 뒤 실행하는 방식을 더 현실적인 AI 코딩으로 본다. 시작은 조금 느려 보여도, 나중에 다시 뜯어고치는 비용을 줄일 수 있기 때문이다.

3. 사람이 손을 떼면 왜 더 위험해질까

• 첫 문제: 중복 코드가 늘어도 초기에 놓치기 쉬움
• 둘째 문제: 구조가 어색해도 누구도 이름 붙여 지적하지 않음
• 셋째 문제: 많이 만든 사람이 아니라 많이 검토한 사람이 병목이 됨
• 넷째 문제: 작은 오류가 쌓여 큰 유지보수 비용으로 돌아옴

AI는 짧은 시간에 초안을 많이 만들 수 있다. 문제는 그 다음이다. 코드가 빨리 늘어날수록, 그 코드를 읽고 맞는지 살피는 일도 함께 늘어난다.

브램 코헨이 말하는 위험은 바로 여기 있다. 사람 손이 완전히 빠지면 생성 속도는 빨라져도 검토 속도는 따라가지 못한다. 결국 눈에 잘 띄지 않는 중복, 어색한 구조, 비슷한 기능의 반복 구현이 쌓이기 쉽다.

쉽게 비유하면 이렇다. 숙제를 빨리 쓰는 학생이 꼭 공부를 잘한 학생은 아니다. 빨리 쓴 답안도 틀린 곳을 확인하고 고쳐야 점수가 올라간다. AI 코딩도 비슷하다. 초안 작성 속도와 최종 품질은 같은 말이 아니다.

4. 다른 자료와 같이 보면 더 분명해진다

• 구글 설명: 바이브 코딩은 아이디어를 빨리 눈앞에 옮기는 출발점
• 구글 보정: 많은 사람이 쓰는 제품으로 키우려면 여전히 정밀한 개발이 필요
• DORA 2025: AI는 조직의 강점과 약점을 함께 키우는 도구
• DORA 2026년 3월 10일: 작성 시간은 줄어도 검증 시간은 다시 늘 수 있음
• 깃클리어 2025: 중복 코드는 늘고, 정리해 옮긴 코드는 줄었다는 분석

브램 코헨의 주장이 특별히 눈길을 끄는 이유는 비슷한 문제의식이 다른 자료에서도 이어지기 때문이다.

구글은 2025년 10월 바이브 코딩을 아이디어를 빠르게 시험해 보는 방식으로 설명했다. 하지만 같은 글에서, 많은 사용자가 쓰는 서비스로 가려면 결국 정확한 개발 실력과 세밀한 손질이 더 필요하다고도 적었다. 빠른 시작은 가능하지만, 끝까지 자동으로 해결되지는 않는다는 뜻이다.

DORA는 2025년 보고서에서 AI를 증폭기라고 불렀다. 내부 도구와 테스트, 협업 방식이 잘 갖춰진 팀은 AI 덕분에 더 빨라질 수 있다. 반대로 기준이 느슨한 팀은 빚처럼 쌓이는 코드도 더 빨리 늘어날 수 있다.

2026년 3월 10일 DORA 글은 한 걸음 더 나간다. 코드를 쓰는 데 아낀 시간이 나중에 검증과 확인에 다시 들어갈 수 있다고 짚는다. 빨라진 만큼 공짜로 이익이 남는 게 아니라는 이야기다.

깃클리어의 2025년 연구도 비슷한 신호를 보여 준다. 2020년부터 2024년까지 2억1100만 줄의 변경 내용을 봤더니, 복제된 코드 비중은 8.3%에서 12.3%로 올랐다. 반대로 코드를 더 깔끔하게 옮겨 정리한 흔적은 줄었다. 이 수치만으로 모든 책임을 AI에 돌릴 수는 없지만, 많이 만드는 속도와 잘 정리하는 능력은 다를 수 있다는 점은 분명하게 보여 준다.

 

한국에서는 빠른 출시 압박이 더 크게 느껴지는 경우가 많다. 그래서 AI 코딩 도구의 체감 효율이 특히 좋다. 하지만 서비스 운영까지 생각하면, 빨리 만드는 능력만으로는 부족하다.

결제와 권한, 정산 같은 영역은 작은 실수도 곧 장애와 민원으로 이어진다. 이런 부분은 사람이 설계와 검토를 강하게 쥐고 있어야 한다. 반대로 사내 문서 정리, 시험용 화면 정리, 테스트 초안 작성, 중복 코드 정리 같은 일은 AI가 큰 도움을 줄 수 있다.

결국 핵심은 "어디까지 맡길까"다. 전부 맡기거나 전부 거부하는 식보다, 위험이 큰 구간은 사람이 직접 보고, 반복이 많은 구간은 AI를 적극 활용하는 방식이 훨씬 현실적이다.

결론

브램 코헨이 글에서 말한 핵심은 선명하다. 바이브 코딩 자체가 문제라기보다, 코드를 안 보는 태도를 미덕처럼 여기는 문화가 더 위험하다는 것이다.

AI는 빠르게 만들고, 사람은 제대로 볼 줄 알아야 한다. 이 역할이 나뉘지 않으면 속도는 남아도 품질은 남지 않는다. 지금 AI 코딩을 쓰는 팀일수록, 생성 속도보다 검토 체계와 책임 구조를 먼저 점검해야 하는 이유가 여기에 있다.

참고 자료

• The Cult Of Vibe Coding Is Insane - Bram Cohen, 2026년 4월 5일
• Ask a Techspert: What is vibe coding? - Google, 2025년 10월 6일
• DORA Research: 2025 - DORA, 2025년
• Balancing AI tensions: Moving from AI adoption to effective SDLC use - DORA, 2026년 3월 10일
• AI Copilot Code Quality: 2025 Look Back at 12 Months of Data - GitClear, 2025년