'AI 코딩 도구를 도입하면 생산성이 40% 향상된다.' 벤더 슬라이드에서 이 숫자를 본 적이 있다면, 한 번쯤 의심해봤을 것이다. 최근 세 편의 분석이 거의 동시에 같은 결론을 가리키고 있다. 속도 지표 뒤에는 측정되지 않은 세 가지 청구서가 숨어 있고, 그 합계가 생산성 이득을 조용히 잠식한다.
첫 번째 청구서: 생산성 수치의 착시
dev.to의 한 글은 시니어 엔지니어들이 실제로 시간 로그를 남긴 결과를 공유했다. AI가 함수를 10초 만에 생성하는 것은 사실이다. 문제는 그 다음이다. 코드를 꼼꼼히 읽고, 팀 스타일 가이드에 맞게 수정하고, AI가 뭉개버린 엣지 케이스를 디버깅하고, 빠진 테스트를 직접 작성하고 나면 '10초짜리 작업'이 45분으로 불어난다. 40%라는 숫자는 생성 단계만 측정한 결과다. 리뷰·통합·디버깅을 포함한 풀 사이클로 측정하면 대부분 한 자릿수로 수렴하고, 때로는 0이 된다.
핵심은 이것이다. 숙련된 엔지니어에게 병목은 '타이핑 속도'가 아니다. 생각하고, 읽고, 통합하는 과정이 병목이다. AI는 타이핑 시간을 줄이고 그 대신 읽기·검증 시간을 늘린다. '40% 빨라진다'는 표현보다 'AI는 시간을 쓰는 위치를 바꾼다'는 표현이 훨씬 정확하다. 이 차이를 모르고 도입하면, 팀은 빨라졌다는 체감 없이 지쳐간다.
두 번째 청구서: AI가 반복하는 보안 취약점
생산성 착시보다 더 위험한 문제가 있다. LLM은 '동작하는 코드'를 최적화 목표로 학습했지, '안전한 코드'를 목표로 학습하지 않았다. VibeGuard 개발자가 AI 생성 코드를 전용 스캐너로 분석한 결과, 동일한 클래스의 취약점이 반복적으로 등장했다. f-string으로 SQL 쿼리를 조합하는 SQL 인젝션, 파일명을 그대로 경로에 이어붙이는 패스 트래버설, 그리고 아무 동작도 하지 않으면서 성공 응답을 반환하는 스텁 스켈레톤이 대표적이다.
특히 주목할 부분은 '바이브 코딩 패턴'이라고 불리는 15가지 항목이다. async 없이 await를 쓰거나, DB에 실제로 쓰지 않으면서 {"status": "saved"}를 반환하거나, 파라미터가 리턴값에 전혀 영향을 미치지 않는 코드들이다. 기존 Bandit이나 Semgrep 같은 정적 분석 도구는 이 패턴을 탐지하도록 설계되지 않았다. 25,000개 이상의 스타를 받은 오픈소스 AI 코딩 어시스턴트에서도 subprocess.Popen(cmd, shell=True) 형태의 커맨드 인젝션이 발견됐다. AI가 짠 코드라는 이유만으로 신뢰하면, 그 신뢰 자체가 취약점이 된다.
현실적인 대응은 두 가지다. AI 생성 코드를 PR 단계에서 자동으로 스캔하는 파이프라인을 붙이거나, AI 생성 코드임을 명시적으로 표시해 리뷰어의 경계 수준을 높이는 것이다. 어느 쪽이든 '검증 없이 머지'하는 관행은 지금 당장 멈춰야 한다.
세 번째 청구서: 일회용 코드라는 환상의 유지보수 비용
'AI가 10배 빠르게 재작성할 수 있다면, 굳이 오래가는 코드를 짤 필요가 있나?' 이 논리는 코드를 유지보수한 경험이 없는 사람들에게서 주로 나온다. dev.to의 또 다른 글은 이를 직설적으로 비판한다. 성숙한 코드베이스는 단순한 논리 집합이 아니다. DST 전환 시점에 특정 결제 제공사가 null 필드를 반환한다는 사실, 그 이유는 여전히 불명이지만 line 412의 조건문에 박혀 있다는 것—이런 암묵적 지식은 티켓이나 문서가 아니라 코드 자체에 살아 있다.
재작성은 기억 상실 이벤트다. AI가 같은 기능을 빠르게 재구현할 수 있어도, 3개월간의 인시던트 회고를 거쳐 쌓인 재시도 로직의 맥락까지 복원하지는 못한다. 속도는 생산의 속도일 뿐, 이해의 속도가 아니다. 타이핑이 병목이 아니었던 것처럼, 재생성 속도도 운영 안정성의 척도가 아니다. 재작성이 기술 부채를 없애는 것이 아니라, 그것을 발견하는 시계를 리셋하는 것에 불과하다는 지적은 현장 경험이 있는 사람이라면 즉시 공감할 수 있다.
세 청구서의 합산
세 가지 리스크를 나란히 놓으면 공통 구조가 보인다. 모두 '측정하지 않아서' 발생하는 문제다. 생산성은 생성 단계만 측정했고, 보안은 기존 도구로 탐지되지 않아 측정되지 않았고, 유지보수 비용은 미래의 누군가에게 전가되어 지금 청구서에 잡히지 않는다.
AI-First 워크플로우를 설계하는 팀이라면 지금 당장 세 가지 기준을 점검할 필요가 있다. 첫째, 생산성 측정 범위를 코드 생성 완료가 아니라 '리뷰 통과 후 인시던트 없이 운영 중'으로 확장하라. 둘째, AI 생성 코드를 위한 보안 스캔을 CI에 붙여라—기존 정적 분석 도구만으로는 충분하지 않다. 셋째, '재작성 가능'과 '재작성해야 함'을 구분하라. 일회용 코드 철학은 on-call이 없는 사람들의 사치다.
AI 코딩 도구의 가능성에 비관적일 이유는 없다. 다만 도구의 잠재력과 도구를 둘러싼 시스템의 완성도는 다른 문제다. 속도 지표가 인상적일수록, 그 뒤에 숨은 청구서를 더 꼼꼼히 읽어야 한다. 그것이 ROI 계산의 시작점이다.