AI가 빨리 짜준 코드의 청구서는 6개월 뒤에 온다 — 30만 커밋이 말하는 기술부채

AI 코딩 어시스턴트를 써 본 사람이라면 누구나 안다. 프롬프트 한 줄이면 함수 하나, 때로는 파일 하나가 통째로 나온다. 체감 속도는 분명히 빨라졌다. 그런데 그 빠름이 공짜였을까. 최근 1~2년 사이 쌓인 대규모 실측 데이터는 조용히 같은 방향을 가리킨다. 우리가 아낀 시간의 청구서가 유지보수성 항목으로 날아오고 있다는 것이다. 이건 "요즘 코드가 좀 지저분해진 것 같다"는 인상이 아니라, 수십만 커밋 단위로 측정된 추세다.

이 글의 주장은 하나다. AI로 코드를 빨리 생산하면 단기 처리량(throughput)은 오르지만, 그 대가로 코드베이스의 유지보수성이 계량 가능한 방식으로 나빠진다. 구체적으로는 중복 블록이 늘고, 새 코드가 기존 코드와 엮이지 않는 고립된 파일로 쌓이며, 정리되지 않은 기술부채가 누적된다. 핵심은 이 세 가지가 각각 독립된 관찰이 아니라, "생성은 쉽지만 통합·정리는 어렵다"는 하나의 구조적 원인에서 나온다는 점이다.

데이터가 그리는 곡선

가장 무거운 증거는 2026년 공개된 대규모 실증 연구 "Debt Behind the AI Boom"이다. 이 연구는 5개 AI 코딩 어시스턴트로 작성된 것으로 검증된 30만 2,600개의 AI 저작 커밋을 6,299개 GitHub 저장소에서 수집했다. 여기서 드러난 곡선이 인상적이다. 미해결 상태로 살아남은 기술부채 이슈의 총량이 2025년 초 수백 건 규모에서, 2026년 2월에는 10만 건 이상의 생존 이슈로 급증했다.

다이어그램 설명. 미해결 부채 이슈가 수백 건에서 10만 건 이상으로 불어난 경로를 단계별로 보여준다. 눈여겨볼 것은 절대 수치보다 기울기다. 부채가 "쌓이는 속도"가 어시스턴트 채택 곡선과 나란히 가파르게 꺾인다. 코드를 만드는 행위는 자동화됐지만, 만들어진 코드를 코드베이스 전체 맥락에 맞춰 정리하고 죽은 부채를 갚는 행위는 여전히 사람의 몫으로 남아 병목이 됐다는 뜻이다.

부채는 어디서 새어 들어오나

부채가 "어디서" 새어 들어오는지도 여러 독립 연구가 같은 지점을 짚는다. 첫째, 코드 스멜(code smell, 당장 버그는 아니지만 유지보수를 어렵게 만드는 코드 패턴). Paul 등의 2025년 분석은 AI가 생성한 코드가 사람이 쓴 코드보다 code smell을 평균 63% 더 많이 담고 있다고 보고했다. 둘째는 중복이다. 코드 변경 데이터를 장기 추적하는 GitClear는 5줄 이상 중복 블록이 2024년 기준 전년 대비 8배로 늘었고, 재사용을 뜻하는 "이동(moved)" 변경이 24%에서 9.5%로 줄어드는 동안 복사·붙여넣기는 8.3%에서 12.3%로 올라갔다고 집계했다. 셋째는 고립이다. 같은 데이터에서 함수 간 연결성(호출 관계로 엮이는 정도)이 2023년 이후 35% 감소했다. 새로 생성된 코드가 기존 코드베이스와 손잡지 않고 자립형 파일로 떨어져 나간다는 신호다.

다이어그램 설명. "AI 코드 생성 급증"이라는 하나의 원인에서 네 갈래의 부채 경로가 갈라져 나와 전부 "유지보수 비용 상승"으로 모이는 구조다. 중복 급증과 함수 연결성 하락이 코드 자체에 남는 부채라면, 피상적 리팩터링과 리뷰 중 삭제는 "그럼 정리하면 되지 않나"라는 반문을 미리 막는 갈래다. Ottenhof의 2026년 관찰에 따르면 사람은 함수 추출, 책임 분리 등 다양한 구조 개선으로 리팩터링하지만, AI 에이전트의 리팩터링은 애노테이션을 더하거나 고치는 식의 표면적 변경에 쏠려 있다. 즉 부채를 만드는 것도, 갚는다고 내놓는 것도 얕다. Watanabe의 2026년 분석은 여기에 인간 비용을 붙인다. 에이전트가 만든 PR에서 생성된 메서드의 9.9%가 리뷰 과정에서 삭제됐다. 애초에 필요 없던 코드를 사람이 읽고, 판단하고, 걷어내는 데 인지 자원을 쓴 셈이다.

반론 — 이 곡선은 필연이 아니다

정직하게 균형을 잡자. 위 데이터를 "AI 코드는 나쁘다"로 읽으면 과장이다. 세 가지 유보가 있다.

첫째, 측정된 것은 대부분 정적 분석 지표다. 개발 속도가 일시적으로 오른다는 것과 정적 지표상 부채가 쌓인다는 것을 함께 보고하는 다중 문헌 리뷰(MLR, 학술 논문과 실무 문헌을 함께 훑는 리뷰 방법론)는, 이 둘이 반드시 최종 결함률로 직결된다고 단정하지 않는다. 중복이 늘었다고 곧바로 장애가 늘었다는 뜻은 아니다.

둘째, 반대 방향 데이터도 존재한다. 같은 문헌군 안에는 에이전트가 작성한 코드가 오히려 사람 코드보다 사후 수정률이 낮더라는 연구도 있다. 결과는 코드의 성격과 맥락에 크게 의존한다 — 잘 정의된 작은 작업에서는 AI 코드가 더 안정적일 수 있다.

셋째, GitClear 류의 지표는 "복사·붙여넣기 = 나쁨"이라는 가치판단을 내장한다. 어떤 맥락에선 명시적 중복이 잘못된 추상화보다 낫다. 지표를 목적함수로 착각하면 안 된다.

그래서 이 글의 주장은 "AI 코드는 열등하다"가 아니라 "AI는 생성을 싸게 만들지만 통합·정리는 싸게 만들지 못한다"로 좁혀진다. 청구서는 코드의 품질 그 자체가 아니라 그 비대칭에서 발생한다.

정리 — 비대칭을 시스템으로 상쇄한다

측정된 추세가 필연이 아니라면, 아키텍트가 할 일은 그 비대칭을 시스템으로 상쇄하는 것이다. 처리량 지표만 보지 말 것 — "머지된 PR 수"는 부채가 늘어도 좋아 보이니, 중복률·함수 연결성·미해결 부채 이슈의 생존 시간을 같은 대시보드에 나란히 둔다. 생성이 아니라 통합에 리뷰 예산을 쓸 것 — 리뷰 중 삭제되는 코드가 10%에 육박한다면, "이 코드가 맞나"보다 "이 코드가 기존 것과 엮이나, 중복은 아닌가"를 리뷰 체크리스트 상단에 올린다. 리팩터링은 사람의 일로 남겨둘 것 — 에이전트의 리팩터링이 표면적이라는 관찰은, 구조 개선을 AI에 통째로 위임하지 말라는 경고다. 그리고 작고 명확한 작업에 AI를 배치할 것 — AI 코드의 안정성은 맥락 의존적이고, 경계가 뚜렷한 작업일수록 청구서가 작다.

빨리 짜는 것 자체는 죄가 아니다. 다만 속도의 이면에 유지보수성이라는 이연 비용이 붙는다는 사실이 이제는 인상이 아니라 데이터라는 점 — 그것을 알고 설계하는 것과 모르고 방치하는 것의 차이가, 6개월 뒤 코드베이스를 가른다.

---

참고한 공개 자료:

• Debt Behind the AI Boom — 30.26만 AI 저작 커밋 실증 연구, arXiv (https://arxiv.org/abs/2603.28592)
• AI 코딩과 기술부채 다중 문헌 리뷰(MLR), code smell +63% 포함 — arXiv (https://arxiv.org/pdf/2606.14796)
• AI 에이전트 코드의 리팩터링·리뷰 삭제율 실증 (Ottenhof 2026, Watanabe 2026) — arXiv (https://arxiv.org/html/2605.06464v1)
• AI Copilot Code Quality: 2025 Research — GitClear (https://www.gitclear.com/ai_assistant_code_quality_2025_research)
• The AI Code Quality Maintainability Gap — GitClear (https://www.gitclear.com/the_ai_code_quality_maintainability_gap)
• AI-generated code maintainability — Ivan Turković (https://www.ivanturkovic.com/2025/07/28/ai-generated-code-maintainability/)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.