AI가 코드베이스 절반을 썼다 — 유지보수 청구서는 3개월 차에 도착했다
AI 코딩 도구가 초안 생성 비용을 거의 0으로 만들었지만, 리뷰와 유지보수 비용은 그대로라서 '생산성'의 회계가 왜곡된다는 글입니다. 저자는 자신의 오픈소스 프로젝트들에서 관찰한 패턴과 METR 연구(숙련 개발자가 AI 사용 시 19% 더 느려짐)를 근거로, 생성 속도가 아닌 소유 비용(ownership cost)을 측정해야 한다고 주장합니다. 디버깅, 태스크 단위 비용, 무한 루프, 이해의 외주화라는 네 가지 숨은 비용 항목을 구체적 수치와 함께 제시합니다.
본문
AI 코딩 도구를 매일 쓰고 오픈소스 프로젝트를 활발히 배포해 온 저자가, 이 글은 '반AI' 글이 아니라 '회계' 글이라고 선을 긋습니다. 우리는 첫 초안(first draft)이 얼마나 빨리 나오는지는 잘 측정하지만, 그 이후에 발생하는 비용은 거의 측정하지 않으며, 실제 비용은 바로 그 '이후'에 살고 있다는 것입니다.
깨진 비용 비율 — 생성은 0으로, 유지보수는 그대로
전통적인 개발 주기에서는 작성·리뷰·유지보수 비용이 대략 비례했고, 그래서 경제성을 추론할 수 있었습니다. AI는 이 비율을 깨뜨렸습니다. 생성 비용은 거의 0으로 떨어졌지만 리뷰 비용은 그대로이고, 코드베이스 수명에서 가장 긴 단계인 유지보수 비용도 전혀 움직이지 않았습니다. 결과는 새로운 형태입니다. 첫 주에는 극도로 생산적으로 보이다가 3개월 차에 점점 비싸지는 프로젝트입니다. 저자는 '3개월 차'가 한 프로젝트의 스톱워치가 아니라 올해 출시한 도구들에서 반복해서 본 패턴이라고 말합니다. 대규모 장애가 아니라, 실제보다 믿음직해 보였던 코드가 쌓이면서 이후 변경이 그것을 피해 가며 작동해야 하는 느린 비용입니다.
저자가 인용하는 사례는 사고가 아니라 작은 버그였습니다. 코드는 잘 읽혔고 테스트는 통과했고 주석도 사려 깊어 보였지만, optional 필드가 없을 때 API 응답을 잘못 해석했습니다. happy path만 처리하고 '부재'를 놓친 것입니다. 팀 아무도 그 코드를 제대로 심문하지 않았고, 믿음직해 보였기 때문에 검증이 덜 들어갔다는 점이 문제의 본질입니다. 2025년 METR 연구가 정량적 버전입니다. 숙련된 오픈소스 개발자들이 AI 도구를 쓰면 더 빠르다고 느꼈지만 실제로는 19% 더 오래 걸렸습니다.
청구서가 도착하는 네 곳
저자는 소유 비용이 떨어지는 지점 네 곳을 계측했습니다.
첫째, 생성된 코드의 디버깅입니다. 저자의 도구 CauterRule은 반복되는 에이전트 실패를 조사하기 위해 4,768개의 trajectory 필드 테스트를 돌려야 했고, trajectory별 타임아웃·격리·토큰 상한 같은 러너 강화 작업까지 필요했습니다. 코드는 며칠 만에 쓰였지만 이해하려면 인프라가 필요했다는 것이 청구서의 형태입니다.
둘째, 호출당이 아니라 태스크당 나타나는 비용입니다. 싼 모델 호출, 실패, 재시도, 실패, 에스컬레이션 — 대시보드에는 $0.001로 보이지만 태스크 완료 비용은 $0.053이었습니다. 저자가 ai-tierforge를 만든 이유이며, 모든 것을 하나의 모델로 보내는 것 대비 실제 절감률은 44.8%였습니다.
셋째, 끝나지 않는 루프입니다. circuit breaker 없는 생성된 에이전트 루프는 크게 실패하지 않고 조용히 비싸게 실패합니다. 저자의 LoopGuard가 391개 테스트를 필요로 한 이유는 실패 모드가 '시스템이 영원히 일을 계속하는 것'이기 때문입니다.
넷째, 배우기 전에 외주화하는 이해입니다. 저자가 수치화할 수 없지만 가장 크다고 보는 항목입니다. 아키텍처와 트레이드오프를 의심하는 습관을 들이기 전에 모델이 전문가처럼 보이는 결과물을 만들어 주면, 빠진 판단력은 어딘가에서 나타나야 하고 보통 리뷰에서 다른 사람의 시간으로 나타납니다.
'AI를 덜 쓰라'가 아니라 '사람의 주의를 옮기라'
저자의 결론은 사용 축소가 아니라 인간의 주의가 가는 곳을 바꾸는 것입니다. 볼륨이 늘면 인간의 주의는 선형으로 확장되지 않으므로 결정론적 게이트인 자동화에 더 많이 맡기고, 리뷰는 '깔끔해 보이는가'가 아니라 '왜 작동하는지, 무엇을 가정하는지, 어떻게 실패하는지를 이해하는가'를 보는 방향으로 바꿉니다. 특히 주니어 엔지니어에게 설명을 더 일찍 요구해 판단력 훈련이 계속되게 하고, 산출량이 아니라 '다음 변경이 얼마나 비쌀 것인가'라는 소유 지표를 추적해야 합니다. 모델이 초안을 쓰면 글쓰기 중에 일어나던 추론은 다른 곳에서 일어나야 하며, 이는 도구 선택이 아니라 프로세스 설계 선택입니다.
저자는 이것이 통제된 실험이 아니라 자기 프로젝트의 패턴이며, METR 결과도 판결이 아니라 힌트라고 스스로 한계를 밝힙니다. 다만 '빠르다'의 정의가 merge에서 멈춘다면 라이프사이클의 싼 절반만 측정하는 것이라는 점은 실험 없이도 말할 수 있다고 강조합니다. 모든 팀이 생성 속도를 재는 지금, 소유 비용을 재면 무엇이 달라질지를 독자에게 묻습니다.
원문: dev.to / 번역·요약: Trawling