달러당 18센트: 버그가 현실화될 때 AI 코딩 도구가 실제로 발생시키는 비용

칼럼 개요

엔지니어링 리더들로 가득 찬 방에서 AI 코딩 도구가 팀의 속도를 높였는지 물어보면, 거의 모두가 그렇다고 대답할 것입니다. 하지만 영수증을 보여달라고 하면 대화는 훨씬 더 불편해집니다. 올해 몇 주 간격으로 발표된 두 개의 데이터는 업계 대부분이 이미 해결되었다고 생각했던 논쟁을 조용히 다시 열었습니다. AI가 생성한 코드가 실제로 출시 비용이 더 저렴한 것일까요, 아니면 우리가 보지 않는 곳으로 비용을 옮겼을 뿐일까요?

누구도 항목별로 나누지 않은 청구서

개발자 트위터를 뜨겁게 달군 수치는 Entelligence AI에서 나왔습니다. 이 회사는 2,444개 기업의 사용량 데이터를 추출하고 거의 아무도 귀찮아 하지 않는 작업을 수행했습니다. 바로 AI 코딩 토큰에 지출된 모든 달러를 프로덕션 단계까지 추적한 것입니다. 그 내역은 결코 미묘하지 않았습니다. 지출된 달러당 44센트는 AI 자체가 도입한 버그를 수정하는 데 들어갔고, 27센트는 제대로 작동하지 않는 AI 생성 코드를 다시 작성하는 데 사용되었으며, 또 다른 11센트는 인간이 모델이 실제로 무엇을 했는지 파악하려 하면서 코드 리뷰 및 병합 지연의 마찰로 증발했습니다. 이를 모두 합산하면 지출된 달러당 실제 출시 가능한 가치는 약 18센트만 남습니다. 10만 달러짜리 토큰 예산은 실제 프로덕션에 도달하는 약 1만 8천 달러어치의 코드를 낳을 뿐입니다.

이러한 프레이밍은 누구나 회의에서 반복할 수 있는 단일 비율로 매우 직관적이기 때문에 빠르게 퍼졌습니다. 하지만 이 역시 거의 같은 속도로 반론을 불러일으켰고, 그럴 만한 이유가 있습니다. 공급업체의 종합 설문조사 데이터를 요약한 바이럴 트윗은 통제된 연구가 아니며, "18센트"라는 수치는 매우 다른 종류의 엔지니어링 작업을 하나의 숫자 아래 혼동하고 있고, 팀마다 리뷰 프로세스의 엄격함 정도가 크게 다릅니다. 바로 이 점을 지적하는 반론인 "달러당 18센트"는 원래의 주장 대신 읽을 가치가 있습니다. 이는 기저의 패턴을 반박하기보다는 특정 숫자가 감당할 수 있는 것보다 더 많은 정밀도를 요구받고 있다고 주장할 뿐입니다. 기억할 만한 요점은 소수점 둘째 자리가 아닙니다. 바로 발견의 형태입니다. 즉, AI 코딩 지출의 상당 부분은 새로운 가치를 창출하는 것이 아니라 혼란을 만들어낸 바로 그 도구의 뒤처리를 하는 데 쓰이고 있다는 것입니다.

"두 배 빠름"이 어떻게 돈을 잃게 만들 수 있는가

Entelligence의 수치가 스냅샷이라면, Hacker News 정상에 올랐고, 의견이 뚜렷이 갈린 댓글 섹션 속에서도 그 자리를 지킨 James Shore의 에세이 "유지보수 비용을 줄여주는 AI가 필요하다"는 그 스냅샷이 왜 그런 모습인지 설명하는 메커니즘입니다. Shore의 주장은 AI가 나쁜 코드를 작성한다고 믿을 것을 요구하지 않습니다. 대부분의 ROI 피치가 편리하게 건너뛰는 회계적 항등식을 받아들이기만 하면 됩니다. 즉, 총 유지보수 부담은 코드를 얼마나 빨리 생산했는지가 아니라 유지보수하는 코드의 규모에 비례한다는 것입니다.

모델을 앞으로 실행해 보십시오. AI 에이전트를 통해 팀의 산출량이 두 배가 됩니다. 즉, 기능은 두 배, 파일은 두 배, 코드베이스에 내장된 엣지 케이스는 두 배가 됩니다. 낙관적인 시나리오인 코드 단위당 유지보수 비용이 그대로 유지된다고 가정해도, 유지보수 청구서를 줄인 것이 아니라 두 배로 늘린 것입니다. 왜냐하면 이제 두 배의 코드가 두 배의 지원 티켓, 보안 패치, 통합 문제를 발생시키기 때문입니다. Shore의 모델은 요점을 구체적으로 만들기 위해 타임라인을 길게 가져갑니다. 그럴듯한 가정들을 바탕으로 할 때, 대규모 AI 가속 개발을 도입한 지 약 2년 반 이내에 유지보수 작업은 개발자 시간의 절반 이상을 소비하는 것으로 증가합니다. 속도는 올라갔습니다. 하지만 새로운 작업을 수행할 순수 용량은 늘어나지 않았습니다. 왜냐하면 기존 작업에 대한 세금이 그와 함께 똑같이 증가했기 때문입니다.

게시물 아래의 Hacker News 스레드는 단순한 참여 지표가 아닌 하나의 출처로 취급할 만합니다. 의견 불일치는 대략 예상되는 곳에서 나뉩니다. 강력한 테스트 커버리지, 엄격한 리뷰 규율, 그리고 시니어 엔지니어들이 AI를 통제하는 팀들은 복리 효과가 실제이지만 관리 가능하며, 통제 불능의 악순환이라기보다는 20~30%의 유지보수 세금에 가깝다고 보고합니다. AI 생성 코드를 느슨한 감독 하에 출시하는 팀들은 Shore의 최악의 시나리오에 더 가까운 무언가를 묘사합니다. 이러한 분열은 어느 극단보다도 더 중요합니다. 왜냐하면 결과가 도구에 의해 결정되는 것이 아니라, 조직이 부채가 복리로 쌓이기 전에 이를 잡을 만큼 이미 규율이 잡혀 있었는지에 의해 결정된다는 것을 시사하기 때문입니다.

누구도 인정하고 싶어 하지 않는 의존성

세 번째 데이터 포인트를 겹쳐 놓으면 그림은 불편할 정도로 선명해집니다. 이제 AI 지원 없이는 코드 작성을 거부하는 개발자들에 대한 TechCrunch의 보도는, 이렇게 해야 하는지에 대한 내부 논쟁 없이 조용히 한계를 넘어선 인력을 묘사합니다. 더 빨라지기 때문에 도구를 채택하는 것은 한 가지입니다. 그것 없이 작업하는 것이 더 이상 선택지처럼 느껴지지 않는 지점, 즉 지원 없이 코드를 작성하는 기술이 충분히 위축되어 되돌아가는 것이 실제로 선택지에 없는 지점에 도달하는 것은 또 다른 문제입니다.

이를 유지보수 수학과 나란히 놓으면 진정으로 어색한 조합이 도출됩니다. 즉, 도구의 산출물이 같은 개발자 다수가 수작업으로 갚을 역량이나 자원을 갖추지 못한 유지보수 청구서를 만들어 내는데도 그 도구에 점점 더 의존하게 되는 인력입니다. AI가 코드를 작성했고, AI가 작성 비용만큼 저렴하게 이를 유지보수할 수 있다고 신뢰할 수 없으며, 보통 이 유지보수를 맡을 사람들은 AI 없이 하는 데 가장 익숙하지 않다면 부채는 상환되지 않고 미뤄질 뿐입니다. 이는 가상의 실패 모드가 아닙니다. 이는 코드베이스 규모 측면이 아닌 인적 자본 측면에서 바라본 Shore의 에세이가 묘사하는 바로 그 메커니즘입니다.

업계가 구축하는 것을 잊은 지표

이 모든 것이 "AI 코딩 도구는 작동하지 않는다"는 결론으로 귀결되는 것은 아닙니다. 회의적인 시각을 포함한 여기의 모든 출처는 이러한 도구가 실제로 코드 작성을 가속화한다는 것을 당연하게 여깁니다. 이는 논쟁의 대상이 아닙니다. 논쟁이 되는 것은 업계가 올바른 것을 측정해 왔는지 여부입니다. 시간당 코드 라인 수, 스프린트당 병합된 PR, 출시된 기능당 소비된 토큰 등은 모두 생산 측면의 지표입니다. 이들은 파이프라인의 전방이 얼마나 빨리 움직이고 있는지 알려줄 뿐입니다. 6개월 후 그 코드를 작성하지 않았고 처음에 면밀히 리뷰하지도 않았을 누군가에 의해 그 코드를 수정, 디버깅 또는 확장해야 할 때 무슨 일이 일어나는지는 알려주지 않습니다.

이 전체 논쟁을 판가름하는 실제 변수는 바로 이것입니다. AI가 소프트웨어 팀에 미치는 순효과은 산출 속도를 측정하여 답할 수 있는 문제가 아닙니다. 왜냐하면 속도는 바로 청구서가 청구되기 직전에 올라가는 숫자이기 때문입니다. 더 정직한 ROI 모델은 대출 기관이 대출을 다루는 것과 같은 방식으로 AI 지원 코드를 다룰 것입니다. 즉, 오늘 전달되는 가치를 몇 분기 뒤 유지보수 장부에 나타나기 시작하는 상환 일정과 비교하여 저울질하는 것입니다. 일부 팀은 이미 이러한 트레이드오프를 내면화하여, AI가 생성한 모든 것에 대해 더 엄격한 리뷰 게이트와 필수 테스트 커버리지를 적용하는 방식으로 AI 도입을 구조화하고 있습니다. 위의 수치를 볼 때 대부분의 팀은 여전히 대출을 보조금인 양 계산하고 있습니다. 달러당 44센트라는 수치와 2년 반의 유지보수 곡선은 동일한 미지급 청구서를 묘사하는 두 가지 방법입니다. 그 청구서가 관리 가능한 상태로 남을지, 아니면 이번 10년 동안 소프트웨어 개발의 지배적인 비용이 될지는 어떤 모델이나 에이전트를 사용하느냐보다는, 조직이 그 청구서가 도착하기 전에 이를 살펴보기로 결정했는지 여부에 더 크게 달려 있습니다.