구글이 신규 코드의 75%를 AI로 생성한다고 밝힌 지금, 'Vibe Coding'은 더 이상 실험적 개념이 아니다. 프롬프트 몇 줄로 수천 줄짜리 피처가 뚝딱 만들어지는 현실이 이미 왔다. 그런데 이 속도 뒤에서 조용히 쌓이는 것이 있다. 아무도 제대로 설명하지 않는 기술 부채의 구조적 원인이다.
AI가 만드는 '쓰레기 산'의 메커니즘
dev.to에 올라온 'The High Interest on the AI Loan'은 이 문제를 정면으로 파고든다. 핵심 진단은 단순하다. 대부분의 코딩 에이전트는 기능적 성공 여부만 보상받도록 훈련됐다. 테스트를 통과하면 AI는 '이겼다'고 판단한다. 아키텍처가 스파게티인지, 같은 로직이 다섯 군데 중복됐는지, 성능 병목이 숨어 있는지는 보상 함수에 없다. 결과적으로 AI는 눈앞의 테스트를 통과하기 위해 가장 빠른 경로를 선택하고, 그 잔해가 코드베이스에 쌓인다.
현실적으로 이 현상은 세 가지 패턴으로 나타난다. 첫째, 아키텍처 파편화 — 비슷한 기능이 파일마다 다른 방식으로 구현돼 있다. 둘째, 중복 로직 증식 — 동일한 로직이 다섯 가지 변형으로 존재하며 어느 게 '진짜'인지 모른다. 셋째, 유령 버그 — AI가 생성한 레이어 깊숙이 숨어 있어 아무도 이해하지 못하는 엣지 케이스가 언젠가 터진다. 100,000줄 AI 프로젝트가 사실 50,000줄로 설계됐어야 할 시스템이라는 지적은, 지금 많은 팀의 레포에 그대로 적용된다.
더 조용한 위험: 개발자가 코드를 잃어버리는 것
기술 부채보다 더 말하기 불편한 문제가 있다. 같은 dev.to에서 한 시니어 개발자가 털어놓은 고백이다. 처음엔 보일러플레이트만 AI에 맡겼다. 그다음엔 쓰기 귀찮은 함수, 그다음엔 '알긴 하는데 굳이' 싶은 함수. 어느 순간 프롬프트 없이 코딩을 시작하는 게 어색해졌다. 주니어가 "AI 없이 어떻게 짜요?"라고 물었을 때, 막히는 건 시니어 자신이었다.
또 다른 개발자는 20년 경력을 가지고 하루 종일 'next'만 타이핑하며 보냈다고 썼다. 에이전트가 use case를 분석하고, 스펙을 뽑고, 태스크로 쪼개고, 코드를 짜고, 리뷰까지 했다. 개발자가 하는 일은 AI 출력을 검토하고 다음 단계로 넘기는 것뿐. 속도는 빨라졌다. 퇴근 후 에너지도 남는다. 하지만 그는 이렇게 썼다. "온종일 생각을 안 해서 에너지가 남는 건데, 그게 좋은 건지 모르겠다."
이 두 사례가 가리키는 것은 같다. AI 의존이 깊어질수록 개발자는 시스템의 전체 맥락을 잃어간다. 클라이언트가 미팅에서 슬쩍 언급한 요구사항, v2에서 바뀔 수 있는 구조적 가정, 코드베이스의 암묵적 규칙 — 이런 건 컨텍스트 창에 넣을 수 없다. 그걸 기억하고 설계에 반영하는 건 여전히 사람의 몫이다. 그런데 그 사람이 코드를 이해하지 못하게 된다면?
팀 리드가 지금 당장 물어야 할 질문
나는 AI-First 워크플로우를 지지한다. 반복 작업을 AI에게 맡기고 팀이 더 어려운 문제에 집중하는 구조는 분명히 옳다. 하지만 Vibe Coding 팀에서 내가 목격하는 가장 큰 실수는 'AI가 짠 코드를 이해하는 책임'을 아무도 명시적으로 갖지 않는다는 것이다.
코드 리뷰가 'AI가 하니까 사람이 안 봐도 된다'는 결론으로 이어지는 순간, 팀은 자신이 짜지 않은 코드를 출하하기 시작한다. 주니어의 학습 목표가 'AI가 더 잘 아니까 배울 필요 없다'는 판단으로 막히는 순간, 팀의 기술 이해 수준은 시간이 갈수록 낮아진다. 두 가지 모두 실제 팀에서 일어나고 있는 일이다.
기술 부채를 막는 건 도구 제한이 아니라 구조 설계다
AI 사용을 줄이자는 게 아니다. '검증 구조'를 이미 여러 번 강조했으니, 이번엔 다른 각도로 얘기하겠다. 팀원이 AI 없이도 자신의 코드를 설명할 수 있어야 한다는 원칙을 워크플로우 안에 명시적으로 심는 것이다.
구체적으로는 세 가지다. 첫째, 피처 리뷰에서 'AI가 왜 이렇게 짰는가'가 아니라 '우리가 왜 이 구조를 선택했는가'를 설명하게 한다. 생성 결과물이 아니라 설계 의사결정을 소유하게 만드는 것이다. 둘째, 아키텍처 결정은 AI에게 위임하지 않는다. AI는 구현 옵션을 빠르게 탐색하는 데 탁월하지만, 시스템의 방향을 선택하는 책임은 사람이 져야 한다. 셋째, 팀 내 '코드 이해 격차'를 주기적으로 측정한다. 누군가 시스템의 특정 영역을 아무도 이해하지 못하는 상태가 됐다면, 그건 기술 부채가 임계점에 도달했다는 신호다.
결국 이건 팀 문화의 문제다
기술 부채의 이자는 매달 10%씩 붙는다. Vibe Coding으로 오늘 40시간을 절약하면, 6개월 뒤 400시간을 쓰며 구조를 뜯어고치게 된다. 이 공식은 AI 이전에도 유효했고, AI 이후에도 변하지 않는다.
AI-First 팀을 설계할 때 내가 고집하는 한 가지 원칙이 있다. AI는 팀의 실행 속도를 높이는 도구지만, 팀의 이해 수준을 대체하는 도구가 아니다. 개발자가 AI를 쓰면서도 자신이 무엇을 만들고 있는지 설명할 수 있을 때, 그 팀은 빠르면서도 무너지지 않는다. 반대로 AI 출력을 검토하는 역할로만 개발자를 쓰기 시작하면, 빠르게 짜고 느리게 망가지는 사이클이 반복된다.
팀원의 주체성을 지키는 것. 그게 Vibe Coding 시대의 기술 부채를 막는 가장 근본적인 방법이다.