AI 속도는 선물이 아니라 대출이다
팀이 AI 코딩 도구를 도입하고 나서 가장 먼저 보고하는 건 속도다. PR이 빨라지고, 티켓이 닫히고, 매니저는 만족한다. 문제는 그 다음에 온다. dev.to에 공유된 분석에 따르면, AI 코딩 토큰에 쓴 1달러 중 약 44센트가 AI가 만들어낸 버그를 수정하는 데 다시 소비된다. 추가로 27센트는 AI 출력물 재작성, 11센트는 리뷰와 머지 지연에 사라진다. 계산하면 토큰 예산의 약 18%만이 안정적인 프로덕션에 도달한다.
물론 이 수치는 신뢰성 툴링을 판매하는 Entelligence AI가 출처라 자기 이익이 개입된 마케팅 수치로 봐야 한다. 하지만 같은 방향을 가리키는 독립적인 데이터들이 있다. CodeRabbit이 약 470개 오픈소스 PR을 분석한 결과 AI 생성 코드는 인간 코드 대비 약 1.7배 많은 이슈를 만들었고, 크리티컬 이슈 비율도 더 높았다. 싱가포르경영대학 연구자들은 AI 생성 코드가 실제 프로젝트에 장기 유지보수 비용을 누적시킨다는 결론을 냈다. 서로 다른 출처, 서로 다른 이해관계, 그런데 같은 패턴이다.
속도 착각이 더 위험하다
부채 자체보다 더 까다로운 문제가 있다. 개발자들이 AI 속도를 실제보다 크게 과대평가한다는 것이다. METR이 2025년에 숙련된 오픈소스 개발자들을 대상으로 진행한 실험에서, 개발자들은 AI가 자신을 약 20% 빠르게 한다고 느꼈다. 하지만 측정 결과는 반대 방향이었다—타이핑으로 아낀 시간이 오류 수정, 모델 조향, 대기 시간으로 다시 소비됐기 때문이다. METR의 2026년 2월 업데이트는 선택 편향 문제를 인정하며 결과를 일부 수정했지만, 핵심 메시지는 그대로다. 체감 생산성은 항상 실측 생산성보다 높다.
이 간극이 팀에 실질적인 해를 끼친다. 팀이 '20% 더 빠르다'는 느낌으로 일정, 인력, 아키텍처 결정을 내리는데, 실제 수치는 제자리이거나 약간 느린 상황이라면—거기다 토큰 예산의 44센트가 리워크로 새고 있다면—그 결정들은 전부 잘못된 전제 위에 서 있는 셈이다.
스펙 감사가 부채를 조기에 차단한다
그렇다면 무엇이 이 구조를 바꿀 수 있나. dev.to에 공유된 SysEdge 실험이 하나의 방향을 제시한다. 이 도구는 요구사항, 테스트, 아키텍처 표준을 Neo4j 그래프로 모델링하고, AI 기반 감사 커맨드 두 가지를 제공한다. coverage-review는 유스케이스 스펙을 액터 완전성, 인가 경계, 예외 커버리지, 테스트 가능성 등 7개 차원으로 평가하고, audit-test는 테스트 파일을 스펙 파생 여부까지 포함해 7개 차원으로 분석한다.
실험 대상은 Formbricks와 Documenso, 두 개의 프로덕션 오픈소스 프로젝트였다. 콜드 클론 상태에서 감사를 돌렸다.
Formbricks에서는 익명화 기능이 활성화된 상태에서 설문 응답 내보내기에 PII가 포함되는 결함이 발견됐다. 원인은 단순했다. 해당 유스케이스 스펙에 익명화 예외 처리가 한 줄도 쓰여 있지 않았다. 코드 리뷰로는 이 결함을 잡을 수 없다. 변경된 diff가 없기 때문이다. 요구사항 자체가 처음부터 없었던 것이다. 관련 기능의 테스트 커버리지는 V-모델 전 계층에서 0이었다.
Documenso에서는 더 구체적인 리스크들이 나왔다. 봉투 만료를 처리하는 Inngest 잡 핸들러에 테스트가 전혀 없었다. Playwright e2e 테스트는 만료된 상태에 대한 UI 응답을 검증하지만, 그 상태를 만드는 잡이 정상 작동하는지, 부분 실패 시 어떤 상태가 되는지는 검증하지 않는다. 법적 구속력이 있는 전자서명 플랫폼에서 '만료 처리 잡이 500개 중 500개를 처리하다 실패하면 나머지 500개는 어떤 상태인가'라는 질문이 스펙에 존재하지 않는다는 건 명백한 리스크다. 서명 인증서 테스트도 마찬가지였다—PDF에 인증서 페이지가 나타나는지는 확인하지만, 서명 해시의 암호학적 유효성이나 TSA 타임스탬프 정확성은 전혀 검증하지 않는다. 암호화 파이프라인 관련 코드에는 단위 테스트가 없다.
클론부터 모든 결함 발견까지 걸린 시간은 약 15분. AI 비용은 약 0.30달러(haiku 모델 기준)였다.
AI-First 팀이 당장 적용할 수 있는 구조
두 소스가 함께 가리키는 건 하나다. AI는 스펙이 없는 곳을 공략한다. 스펙이 없으면 AI 생성 코드든 인간이 작성한 코드든 결함이 숨어든다. 그런데 AI 코딩 속도가 빨라질수록 스펙 없이 코드가 쌓이는 속도도 같이 빨라진다. 결과적으로 부채는 보이지 않는 곳에서 가속된다.
이 구조를 바꾸려면 검증 단계를 코드 리뷰 이후로 미루면 안 된다. 팀이 내일 당장 적용해볼 수 있는 접근은 세 단계다.
첫째, 대출 유형을 분류하라. AI 코드가 전부 같은 리스크를 갖는 건 아니다. 스캐폴딩, 설정 파일, 1회성 스크립트는 유지보수 꼬리가 없으니 부채 부담이 낮다. 반면 수년간 유지할 핵심 도메인 로직, 인증/인가 코드, 보안 민감 영역은 AI 생성 코드의 크리티컬 버그 비율이 가장 높은 곳이다. '이 코드가 틀렸을 때 비용이 얼마나 되는가, 그리고 얼마나 싸게 검증할 수 있는가'—이 두 질문이 AI 코딩 사용 판단의 기준이 돼야 한다.
둘째, 스펙 감사를 PR 이전으로 당겨라. SysEdge 실험이 보여준 건 코드 리뷰가 스펙 공백을 잡지 못한다는 사실이다. 변경된 diff가 없으면 리뷰어가 볼 것도 없다. 유스케이스 스펙이 예외 처리와 인가 경계를 명시하고 있는지, 테스트가 스펙에서 파생됐는지를 코드가 쓰이기 전에 검증하는 단계가 필요하다. 도구 수준의 자동화가 아니더라도, 스펙 체크리스트를 PR 템플릿에 포함하는 것만으로도 상당한 부채를 조기에 차단할 수 있다.
셋째, 부채의 두 열을 같은 대장에 올려라. 대부분의 팀은 AI 업사이드(생성된 라인, 닫힌 티켓)만 추적한다. 다운사이드—AI 생성 코드에서 비롯된 인시던트 비율, 해당 코드의 리뷰 소요 시간, 첫 머지 후 N주 내 재작성 횟수—는 같은 대장에 올라오지 않는다. 두 열이 분리된 상태에서 AI 속도는 영원히 순이익처럼 보인다. 신용카드가 명세서 도착 전까지 공짜처럼 느껴지는 것과 같은 구조다.
전망: AI 감사가 개발 파이프라인의 표준이 될 것이다
AI 코딩 도구가 팀의 표준 스택으로 자리잡는 속도는 이미 되돌릴 수 없는 수준이다. METR 연구에서 유료 실험 참가자의 30~50%가 AI 없이 작업하기를 거부했다는 사실이 이를 방증한다. 도구를 빼는 건 선택지가 아니다.
그렇다면 남은 질문은 하나다. AI가 만드는 부채를 누가, 언제, 어떤 구조로 감사하는가. 현재 주류인 코드 리뷰 중심 접근은 스펙 공백과 테스트 파생 누락을 구조적으로 놓친다. AI 기반 스펙 감사—요구사항 완전성, 예외 커버리지, 테스트-스펙 연결 추적—가 CI/CD 파이프라인의 필수 게이트로 들어오는 건 이제 방향의 문제가 아니라 속도의 문제다.
AI가 코드를 만드는 속도만큼, 그 코드가 무엇을 빠뜨렸는지를 검증하는 속도도 따라가야 한다. 그 균형을 팀 레벨에서 설계하지 않으면, 빨라진 속도는 결국 나중에 갚아야 할 대출로 남는다.