바이브 코딩의 현실, AI가 짠 코드가 쉽게 깨지는 4가지 이유

바이브 코딩이란 무엇인가, 뜻부터 짧게

바이브 코딩(vibe coding)은 사람이 코드를 한 줄씩 쓰지 않고 AI에게 말로 지시해 프로그램을 만드는 방식이다. 붙여 써서 바이브코딩이라고도 한다. OpenAI 공동 창업자 안드레이 카파시가 2025년 2월 2일 X(옛 트위터)에 처음 쓴 말로, 콜린스 사전은 이 말을 2025년 "올해의 단어"로 뽑았다.

처음 뜻은 AI가 내놓은 코드를 읽지 않고 결과만 보며 고쳐 나가는 놀이에 가까웠다. AI 코딩 에이전트와 AI 코딩 툴이 회사 개발 도구로 자리 잡은 2026년에는 코드 대부분을 AI에게 맡기는 개발 방식 전반을 넓게 가리키는 말이 됐다. 이 글이 다루는 것도 이 넓은 뜻, 곧 현업에서 AI에게 코드를 맡기는 일이다.

바이브 코딩의 현실, 현업 코드의 90% 이상을 AI가 쓴다

개발자 에번 X. 머즈는 2026년 11월 7일 블로그 글 "AI 사용은 쉽게 깨지는 코드베이스를 만든다"에서, Meta에 있던 마지막 몇 달 동안 코드의 90% 이상을 AI로 만들었다고 썼다. 그는 90%가 "괜찮은 평가를 받기 위한 최소치"였다고 적었다. 같은 글에서 자신이 5월에 Meta에서 해고됐다고 밝혔고, 그 이유는 동료들보다 AI 도구를 받아들이는 데 조금 더 머뭇거렸기 때문일 수 있다고 추측했다.

지금 일하는 곳은 "다른 대형 테크 기업"이라고만 했다. 회사 이름은 글에 나오지 않는다. 그곳에서는 코드의 100%를 AI로 만들고 있으며, 이유는 "그것이 오늘날의 기대치"라서라고 했다. 눈여겨볼 대목은 생산량이다. 머즈는 AI가 자신이 쓰는 코드의 양을 10배로 늘리지 못했고, 2배로도 늘리지 못했다고 적었다.

회사 쪽 발표도 같은 방향이다. Anthropic은 2026년 11월 9일 Claude Fable 5.2 발표문에서 "Anthropic 핵심 코드베이스에 병합되는 변경의 90% 이상을 이제 Claude가 작성한다(사람의 지도 아래)"고 밝혔다. 다만 두 숫자는 세는 단위가 다르다. 머즈는 본인이 만든 코드의 비중이고, Anthropic은 병합된 변경의 비중이며 측정 방식은 공개하지 않았다.

AI가 짠 코드가 약해지는 4가지 이유

머즈가 꼽은 AI 코딩의 단점은 얕은 테스트, 필요 이상의 복잡도, 사람의 이해 저하, 품질 기준을 지키기 어려운 속도 네 가지다. 그는 AI가 "자기 컨텍스트 창 안에 들어오는 문제는 아주 잘 풀지만" 그 좁은 틀 밖의 긴 시간에 걸친 문제는 보지 못한다고 진단했다.

첫째, 테스트가 얕다. AI는 값을 넣고 꺼내는 수준의 사소한 테스트를 많이 쓰고, 화면 끝에서 끝까지 도는 테스트는 이미 있는 것만 따라 쓴다. 머즈는 이 때문에 줄 단위 커버리지 숫자에는 드러나지 않는 큰 빈틈이 생긴다고 했다.

둘째, 코드가 필요 이상으로 복잡해진다. 도우미 함수 하나면 될 자리에 두세 개를 만들고, 중복을 없애라(DRY) 같은 지침을 지나치게 따른다는 것이다. 그는 마우스를 올렸을 때의 효과를 CSS 한 줄 대신 자바스크립트 이벤트로 짜려던 동료의 사례도 들었다.

셋째, 사람이 코드를 이해하는 정도가 떨어진다. AI에 기댈수록 코드베이스 전체를 아는 개발자가 줄고, 새로 들어온 추상화가 기존 구조와 어긋나도 알아채기 어렵다.

넷째, 속도가 너무 빠르다. 풀 리퀘스트(PR, 코드 병합 요청)는 점점 빨리 올라오고 리뷰 시간은 짧아져, 개발자가 대충 훑어보게 된다. 테스트 빈틈이나 이름이 엉성한 변수 같은 작은 문제가 쌓여 결국 뒤엉킨 코드가 된다는 것이 머즈의 설명이다.

코드베이스가 약해졌다는 신호 4가지, 우리 팀은 해당될까?

머즈는 코딩 에이전트가 코드베이스를 해치고 있는지 확신이 없다면 장애 증가, 복구 지연, 사용자에게만 보이는 오류, 나빠진 사용자 경험 네 가지 증상을 살펴보라고 했다. 그는 에이전트 도입 뒤 고객에게 영향을 준 장애가 늘었다며 "주말마다 장애가 나는 것 같다"고 썼다.

복구가 늦어지는 이유로는 개발자들의 얕은 이해를 들었다. 코드를 직접 짜지 않았으니 장애가 났을 때 어디를 봐야 할지 모른다는 것이다. 자동 테스트에서도 사람이 직접 눌러 보는 테스트에서도 안 잡히고 실제 사용자에게만 드러나는 오류가 생기며, 결국 사용자와 개발자 양쪽의 경험이 함께 나빠진다고 봤다. 아래 점검표는 그의 네 가지 신호를 팀에서 확인할 수 있는 질문으로 풀어 쓴 것이다.

점검표는 진단 도구가 아니다. 해당하는 항목이 많을수록 사람이 코드를 읽고 고치는 시간을 늘려 볼 신호로 읽는다.

Hacker News 댓글 403개, AI 코딩 에이전트를 두고 반응은 엇갈렸다

머즈의 글은 개발자 커뮤니티 Hacker News에 2026년 11월 10일 저녁(한국 시각) 올라와, 11일 오전 10시 30분 무렵 372점을 받고 댓글 403개가 달렸다. 댓글은 크게 네 갈래로 나뉜다. 감독 없이 쓰는 것이 문제라는 쪽, 좋은 틀을 주면 튼튼한 코드가 나온다는 쪽, 책임은 결국 사람에게 있다는 쪽, 그리고 코드는 이제 쓰고 버리는 것이라는 쪽이다.

리뷰 없이 운영하는 사례도 나왔다. 한 이용자는 코드베이스를 전혀 보지 않고 리뷰도 하지 않는다며 "지금까지 사용자는 30명"이라고 썼고, 다른 이용자는 "실제 사용자와 최소 6개월은 운영해 보고 다시 오라"고 답했다. 찬반 어느 쪽도 AI 도구 자체를 버리자고 하지는 않았다. 머즈 역시 지금도 코드의 100%를 AI로 쓰며, 결론 소제목을 "사람을 위한 제품에는 사람의 손길이 필요하다"로 달았다.

댓글은 일부를 골라 요지를 옮긴 것이다. 403개 댓글의 찬반 비율을 센 것은 아니다.

AI 코딩 단점을 줄이는 방법으로 거론되는 다섯 가지

Hacker News 토론에서는 테스트를 사람이 설계하고, AI가 쓴 코드를 사람이 읽고 병합하며, 한 번에 바꾸는 범위를 작게 두라는 방법이 거론됐다. 머즈의 글에는 처방 목록이 없다. 아래는 댓글에서 나온 의견을 정리한 것이고, 효과가 검증된 지침은 아니다.

예시와 규칙을 주는 방법은 실제 도구로도 나왔다. Google Chrome 팀은 AI 코딩 에이전트용 웹 개발 지침 "Modern Web Guidance"의 1.0을 2026년 11월 10일 Hacker News에 소개했다. 에이전트가 2019년 무렵의 낡은 자바스크립트 대신 지금의 웹 표준 기능을 쓰도록 200개가 넘는 안내문을 넣은 것으로, 이 글은 11일 오전 259점, 댓글 75개를 받았다.

Chrome 팀의 수치는 스스로 잰 값이어서 다른 환경에서도 같은 효과가 난다고 볼 수는 없다. 다만 "AI가 평균 수준 코드를 쓰는 것은 기본값이고, 좋은 틀을 주면 달라진다"는 커뮤니티의 반론과 같은 방향이다.

비개발자와 입문자에게 AI 코딩 툴이 주는 의미는?

AI 코딩 툴 덕분에 만들기는 쉬워졌지만, 고치고 운영하는 일에는 여전히 코드에 대한 이해가 필요하다. 머즈의 글이 경고하는 대상도 사용자가 있고 늘 켜져 있어야 하는 서비스다. 혼자 쓰는 작은 프로젝트와 남이 쓰는 서비스는 요구되는 품질이 다르다.

입문자라면 작은 개인 프로젝트에서 AI 코딩 툴을 써 보되, AI가 만든 코드를 한 번은 읽고 "왜 이렇게 짰는지" 다시 물어보는 습관을 들이는 편이 좋다. 그 과정이 곧 개발 공부가 된다.

바이브 코딩 문제점, 자주 묻는 네 가지