70%는 진짜다. 그리고 그게 함정이다
에이전트 코딩이 가져다주는 속도감은 실제다. 오후 한 나절에 일주일치 작업물이 나온다는 말도 과장이 아니다. 하지만 dev.to에 올라온 분석 글 「Vibe Coding Gets You 70% There」은 그 흥분 뒤에 붙는 영수증을 냉정하게 펼쳐 보인다. Columbia DAPLab이 Cline, Claude, Cursor, Replit, V0를 분석했더니 9가지 공통 실패 패턴이 있었고, 가장 위험한 건 컴파일 에러가 아니라 조용히 틀리는 코드였다. 에러 핸들링 누락, 비즈니스 로직 오작동, 테스트를 통과하면서도 잘못 동작하는 코드. 사용자가 먼저 발견하는 종류의 버그들이다.
숫자는 더 불편하다. METR의 RCT 실험에서 숙련 개발자들은 AI 도구를 쓰면 20% 빨라질 거라 예측했고, 작업 후에도 그렇게 믿었다. 실측치는 19% 느려짐이었다. GitClear가 구글, MS, 메타 등 211억 줄 코드를 분석하니 AI 도입 후 코드 볼륨은 10% 늘었지만 리팩토링 비율은 25%→10%로 60% 줄었고, 코드 중복은 48% 증가했다. Forrester는 2026년까지 기술 의사결정자의 75%가 AI 생성 코드발 기술 부채에 직면할 거라 추산한다.
왜 30%가 막히는가
문제는 AI가 못 쓰는 도구여서가 아니다. 바이브가 시스템이 아니기 때문이다. 첫 번째 프롬프트로 1층을 올리고, 두 번째 프롬프트로 2층을 올리면, 계단이 없는 건물이 생긴다. 각 층은 멀쩡한데 구조가 없다.
의존성 문제가 이걸 잘 드러낸다. AI가 '패키지 3개 필요하다'고 할 때, 실제 전이 의존성은 평균 13.5배 팽창한다. 패키지 3개를 수락하는 순간 37개짜리 미검증 아이스버그가 따라온다. Firebase가 오픈 상태로 배포되고, API 키가 클라이언트 사이드 JS에 하드코딩된다. AI는 악의가 없다. 다만 '작동한다'를 최적화했을 뿐이고, '보안이 유지된다'는 프롬프트에 없었다.
이게 바로 나머지 30%가 요구하는 것이다. 에러 핸들링, 서버 사이드 검증, 기본 잠금 보안 설정, 엣지케이스 로직. 이것들은 만든 다음에 프롬프트로 때울 수 없다. 시작 전에 설계해야 한다.
현장에서 검증된 방식: 컨텍스트를 먼저, 결과물은 나중에
Lablup의 신정규 대표가 Backend.AI:GO를 40일간 개발하며 약 100만 줄을 생성한 경험(GeekNews 공유)은 이 문제를 다른 각도에서 짚어준다. 그가 강조한 핵심은 하나다. 결과물로 바로 들어가지 말고, 컨텍스트를 먼저 쌓아라.
에이전트에게 '기능을 만들어라'라고 시키는 것과, '이 코드베이스의 구조를 파악하고 이 맥락 위에서 기능을 만들어라'는 완전히 다른 결과를 낸다. 그가 설계한 워크플로우에서 자동화의 핵심은 결과물을 직접 생성하는 게 아니라 결과물을 생성하는 장치를 구축하는 것이었다. 생성 장치를 반복 개선하고, 결과물에는 직접 손을 대지 않는다. 이슈 해결 시에는 사람이 읽을 수 있는 tech report를 자동 생성해 기술적 선택의 근거를 남긴다. AI가 만든 결과물이지만 사람이 감사(audit)할 수 있는 구조다.
이건 단순한 팁이 아니다. 에이전트 코딩의 철학적 분기점이다. Claude Code가 '최대한 사용자에게 물어보며 얼라인을 맞추는' 방향으로 진화하고, Codex가 '내가 다 알아서 한다'는 방향으로 간다는 차이도 같은 맥락이다. 최고 성능치는 Codex가 높을 수 있지만, 팀 워크플로우에서 통제 가능성은 다른 축이다.
테크 리드가 실제로 설계해야 할 것
70% 이후를 안전하게 넘기려면 에이전트를 시작하기 전에 세 가지를 고정해야 한다.
첫째, 아키텍처 문서를 먼저 작성하라. 어떤 테이블이 존재하는지, 인증 플로우가 어떻게 흐르는지, API 경계가 어디인지를 에이전트가 참조할 수 있는 형태로 기록한다. 에이전트는 이 문서를 프롬프트로 전달받는 게 아니라, 컨텍스트로 '이미 알고 있는 상태'로 만들어야 한다. 실행 전 컨텍스트 주입이 결과 품질의 천장을 결정한다.
둘째, '작동하는가'가 아니라 '의도대로 작동하는가'를 검증하라. AI가 생성한 코드는 테스트를 통과해도 틀릴 수 있다. 쓴 테스트만큼만 맞는다. 보안 민감 구간, 엣지케이스, 비즈니스 로직의 예외 흐름은 사람이 직접 리뷰해야 한다. AI 생성물은 초안이고, 검증 책임은 여전히 팀에 있다.
셋째, 생성 장치를 관리하라, 결과물이 아니라. 신정규 대표의 방식처럼, 좋은 결과를 반복 생산하는 파이프라인과 프롬프트 구조 자체를 팀 자산으로 쌓아야 한다. 특정 에이전트 세션에서 우연히 잘 나온 코드가 아니라, 어떤 세션에서도 일정 수준 이상이 나오는 시스템을 만드는 게 목표다.
70% 이후는 속도 문제가 아니라 설계 문제다
에이전트 코딩이 팀에 가져다주는 속도는 실재한다. 그 속도를 유지하면서 30%를 무너뜨리지 않는 방법도 존재한다. 다만 그건 더 좋은 프롬프트를 찾는 문제가 아니다.
소프트웨어 정의가 코드 중심에서 AI 모델 중심으로 이동하는 시대에, 복제가 쉬워진 기능 구현 위에서 차별점은 결국 얼마나 잘 설계된 시스템 위에서 에이전트를 굴리느냐가 된다. 에이전트를 더 많이 쓰는 팀이 아니라, 에이전트가 실수해도 무너지지 않는 구조를 먼저 만든 팀이 이긴다.
테크 리드의 역할은 에이전트를 잘 쓰는 사람이 아니라, 에이전트가 잘 작동하는 판을 설계하는 사람으로 이동하고 있다.