바이브코딩은 도구를 민주화했다. 코드를 모르는 사람도 기능을 만들 수 있게 됐다. 그러나 그것이 설계까지 민주화했다는 뜻은 아니다.
바이브코딩의 한계는 코딩 능력의 한계가 아니다. 설계 판단의 한계다. 이 구분을 놓치면 처음에는 빠르게 결과물이 나오다가, 시스템이 커질수록 속도가 급격히 느려진다.
9월 한 달간 실측한 경험을 기반으로 바이브코딩이 무너지는 지점과 사람이 반드시 개입해야 하는 이유를 정리한다.
바이브코딩이 잘 작동하는 구간은 어디인가
먼저 바이브코딩이 잘 작동하는 구간을 명확히 한다.
요구사항이 명확한 단일 기능 구현, 기존 코드 패턴을 따라가는 반복 작업, 빠른 프로토타입 검증. 이 세 가지는 바이브코딩이 사람보다 빠르다.
9월 실측 결과, 위 조건이 충족되는 작업에서 구현 시간이 직접 코딩 대비 평균 70% 단축됐다. 4시간짜리 작업이 1시간 12분이 됐다.
바이브코딩이 무너지기 시작하는 지점은 어디인가
무너짐은 갑자기 오지 않는다. 서서히 축적된다.
첫 번째 신호는 AI의 수정 제안이 이전 수정을 되돌리기 시작할 때다. A를 고쳤더니 B가 깨지고, B를 고쳤더니 A가 다시 깨진다. 이 상황은 보통 구조적 결함에서 온다. AI는 표면 오류를 고치지만 그 아래의 구조 문제를 인식하지 못한다.
두 번째 신호는 왜 이렇게 됐는지 설명할 수 없을 때다. AI가 만든 코드가 동작은 하는데 어떤 이유로 동작하는지 모른다. 이 상태에서 요구사항이 바뀌면 어디를 수정해야 하는지도 모른다.
9월 실측에서 이 두 신호가 동시에 나타난 프로젝트는 세 건이었다. 세 건 모두 초기 구조 설계를 바이브코딩에 맡긴 경우였다. 기능 구현뿐 아니라 아키텍처 결정도 함께 맡겼을 때 발생했다.
사람이 설계자여야 하는 이유는 무엇인가
설계는 미래 변경 가능성을 고려한 구조 선택이다.
AI는 지금 주어진 요구사항을 가장 빠르게 구현하는 방식을 선택한다. "나중에 이 기능이 추가될 수 있다"거나 "이 부분은 6개월 후에 바꿀 예정이다"라는 맥락은 전달하지 않으면 AI가 알 수 없다.
결과적으로 바이브코딩으로 만든 시스템은 초기에는 빠르게 기능이 붙지만, 6개월 이상 유지보수하면서 기술 부채가 누적되는 경향이 있다. 직접 측정 결과, 바이브코딩 비율이 80% 이상인 프로젝트는 3개월 이후 기능 추가 속도가 초기 대비 약 40% 느려졌다. 설계 결정을 사람이 명시적으로 내린 프로젝트는 같은 기간 속도 저하가 15% 이내였다.
사람이 설계자로 개입해야 하는 지점
구체적으로 사람이 직접 결정해야 하는 설계 포인트는 네 가지다.
데이터 구조 설계 테이블 구조, 관계, 타입 결정. 나중에 바꾸면 전체에 영향을 준다.
시스템 경계 설계 무엇이 어디까지를 담당하는가. 모듈 분리 기준. 이것이 흐리면 나중에 모든 기능이 뒤엉킨다.
외부 연동 설계 외부 API, 인증, 웹훅. 외부 세계와 맞닿는 지점은 변경 비용이 크다.
오류 처리 전략 이 기능이 실패하면 어떻게 되는가. AI는 오류 처리를 기계적으로 추가하지만, 비즈니스 맥락에서 어떤 오류가 치명적인가는 사람이 판단한다.
이 네 가지 결정을 사람이 먼저 내리고, 그 안에서 구현을 바이브코딩으로 채우는 구조가 가장 안정적이었다.
9월 아크의 결론: 설계자 없는 자동화는 없다
9월 한 달간 실측 시리즈를 진행하면서 반복적으로 확인한 것이 있다. AI를 잘 쓰는 것은 AI에게 많이 맡기는 것이 아니다. 어디에서 사람이 결정하는가를 명확히 하는 것이다.
바이브코딩도, AI 위임도, 자동화 설계도 모두 같은 결론으로 귀결됐다. 시스템이 클수록, 오래 유지될수록, 설계 결정에 사람이 명시적으로 참여한 비율이 안정성과 비례했다.
10월은 이 설계 원칙을 워크플로로 만드는 방법을 다룬다. "Minimum Input. Maximum Output."을 실제 구조로 구현하는 이야기다.