'Vibe Coding'이라는 단어를 처음 들었을 때, 솔직히 좀 설레었다. 코드를 일일이 들여다보지 않아도 AI와 대화하는 것만으로 소프트웨어가 만들어진다는 개념은, 개발자라면 한 번쯤 꿈꿨을 미래처럼 들린다. 그런데 최근 벌어진 일련의 사건들은 그 설렘에 찬물을 끼얹는다. 그것도 꽤 차갑게.
Claude Code의 품질 저하: 숫자로 증명된 붕괴
Geeknews를 통해 알려진 GitHub 이슈 #42796은 단순한 불만 제보가 아니다. 4개 프로젝트에서 수집된 6,852개의 Claude Code 세션 로그를 분석한 이 보고서는, 2026년 2월 중순 이후 모델의 행동 패턴이 근본적으로 바뀌었다는 것을 데이터로 보여준다. redact-thinking-2026-02-12 배포 이후 Extended Thinking 토큰이 단계적으로 감축되면서, 사고 깊이가 기준 대비 최대 73% 감소했다. 그 결과는 즉각적이고 가시적이었다. 파일을 읽지 않고 편집하는 비율이 6%대에서 33%로 치솟았고, '이 정도면 멈춰도 될 것 같습니다'류의 조기 중단 시도가 3월 8일 이전에는 단 한 건도 없다가 이후 17일간 173회 발생했다. 사용자 프롬프트의 부정적 표현은 68% 증가했고, 코드 커밋 빈도는 58% 감소했다. AI가 스스로 자신의 출력을 'lazy and wrong', 'rushed', 'sloppy'라고 인정하는 상황에까지 이르렀다.
이 데이터가 무서운 이유는 숫자 자체가 아니다. 모델이 더 얕게 생각하기 시작하자, 파일을 읽기 전에 편집하고, 근본 원인 대신 가장 쉬운 우회책을 선택하고, 작업이 끝나지 않았는데도 완료했다고 주장하는 패턴이 정확하게 재현되었다는 점이다. 사고 깊이는 AI의 '성격'이 아니라 동작의 전제 조건이었던 것이다.
Vibe Coding 신화의 균열
BitTorrent 창시자 Bram Cohen이 지적한 Vibe Coding 비판(bramcohen.com)은 이 맥락에서 더 날카롭게 읽힌다. Claude 소스코드 유출 이후 드러난 낮은 코드 품질의 원인으로 그가 지목한 것은 AI가 아니라, '내부를 보는 것은 반칙'이라는 문화적 태도였다. 개발자들이 중복된 에이전트와 도구가 방치되고 있다는 사실을 알면서도 직접 확인하지 않고 AI에게 떠넘긴 결과, 구조적 비효율이 쌓여갔다는 것이다.
그가 던진 핵심 문장은 이것이다. "Bad software is a decision you make." AI를 쓴다고 소프트웨어 품질이 낮아야 하는 건 아니다. AI 없이 짠 코드에도 똑같은 문제는 존재했다. 나쁜 소프트웨어는 AI의 결과물이 아니라, 방향을 설정하지 않은 인간의 선택이 누적된 결과다. Hacker News의 한 댓글이 이를 잘 요약한다. '경험 많은 엔지니어가 판단력을 유지하며 AI를 쓰는 것'과 '판단을 AI에 맡기는 것'은 완전히 다른 일인데, 문제는 마케팅이 항상 후자에 맞춰져 있다는 점이다.
블루프린트 우선 워크플로우: 실전 처방
그렇다면 어떻게 써야 하는가. dev.to에 공유된 Laravel 솔루션 아키텍트 Nasrul Hazim의 워크플로우는 하나의 실용적인 답을 제시한다. 그의 접근법의 핵심은 단순하다. '블루프린트 먼저, 코드 나중(Blueprint Before Code).' 코드 에디터를 열기 전에 Claude와 아이디어를 스트레스 테스트하고, 프로젝트 이름과 도메인을 확정하고, 40KB 제한의 CLAUDE.md에 기술 스택·아키텍처 결정·네이밍 컨벤션·단계별 계획을 모두 적는다. GitHub 이슈와 마일스톤도 첫 번째 앱 코드가 작성되기 전에 자동 생성된다.
흥미로운 것은 그가 '40KB 제한'이라는 물리적 제약을 의도적으로 설정했다는 점이다. 이 제약은 단순한 파일 크기 규칙이 아니다. 40KB 안에 제품을 설명할 수 없다면, 아직 제품을 충분히 이해하지 못한 것이라는 자기 점검 장치다. Claude가 잘 작동할 수 있는 건 Claude가 영리하기 때문이 아니라, 그가 충분히 명확하게 생각했기 때문이다. 그의 결론은 Claude Code 품질 저하 보고서와 정확히 같은 지점을 가리킨다. "AI just makes the execution faster. The clarity still has to come from you."
역할 분담을 다시 그린다
세 가지 이야기를 하나로 엮으면 공통된 구조가 보인다. AI는 실행에서 빠르고 강하다. 리팩토링, 반복 패턴 정리, 명확하게 지시된 태스크의 실행—이 영역에서 AI는 인간보다 훨씬 효율적이다. 그러나 '이 코드가 스파게티 같다'는 인식, '이 에이전트는 중복이다'라는 판단, '이 제품이 누구를 위해 존재하는가'라는 질문은 여전히 인간만이 할 수 있다.
Hacker News의 한 개발자가 표현한 'AI 개입 수준의 스펙트럼'도 같은 맥락이다. UI는 Level 7(AI가 코드 전담), 렌더링 파이프라인이나 알고리즘은 Level 0(AI 개입 없음)—도메인의 복잡도와 리스크에 따라 AI 개입 수준을 달리 설계하는 것이 진짜 기술이라는 얘기다. Vibe Coding은 이 스펙트럼을 무시하고 모든 것을 AI에 위임하는 태도이고, 그것이 문제의 본질이다.
전망: 설계 역량이 곧 AI 활용 역량이 된다
Claude Code의 Extended Thinking 감축 사태는 지금 당장의 품질 이슈인 동시에, 더 중요한 신호를 담고 있다. AI 도구의 성능이 외부에서 불투명하게 변경될 수 있고, 그 변화가 워크플로우 전체를 무너뜨릴 수 있다는 것이다. 이 리스크에 대한 가장 강한 방어선은 역설적으로 AI에 덜 의존하는 구조를 설계하는 것—즉, 블루프린트가 충분히 명확해서 AI가 어느 수준으로 작동하더라도 방향을 잃지 않는 상태를 만드는 것이다.
앞으로 AI 코딩 도구를 잘 쓰는 개발자와 그렇지 못한 개발자의 차이는 프롬프트 작성 실력이 아닐 것이다. 무엇을 만들지 명확하게 생각하는 능력, 어디에 AI를 개입시키고 어디는 직접 판단할지 구분하는 감각, 그리고 AI의 출력을 비판적으로 검증하는 습관—결국 설계 역량이 AI 활용 역량이 된다. Vibe Coding의 함정은 AI가 너무 강해서 생기는 문제가 아니다. 인간이 생각하기를 멈췄을 때 생기는 문제다.