생성 속도는 전달 속도가 아니다 — AI 코드가 쌓는 새로운 기술부채

AI로 두 배 빨리 짰는데, 몇 달 뒤 더 느려진다면

AI 코딩 도구를 쓰기 시작하면 가장 먼저 느끼는 건 속도다. 한 줄 지시로 함수가 통째로 나오고, 막히던 작업이 몇 분 만에 풀린다. 그런데 같은 코드베이스를 몇 달째 끌고 가다 보면 묘한 일이 벌어진다. 분명히 코드는 빨리 쌓이는데, 새 기능 하나 붙이는 일이 점점 더 오래 걸린다.

나는 이 글을 거창한 팀 방법론이 아니라, AI를 일상 작업에 직접 녹여 쓰는 한 개발자의 관점 — 요즘 흔히 AX(AI Experience, 개인이 자기 업무에 AI를 들여 쓰는 경험)라고 부르는 자리 — 에서 쓴다. 도구를 적극적으로 쓸수록 더 또렷하게 보이는 한 가지가 있다. AI는 새로운 종류의 기술부채(technical debt, 지금 편하려고 미뤄 둔 설계·정리 비용이 이자처럼 쌓이는 것)를 쌓는데, 이 부채가 예전 것과 성질이 다르다.

AI 코드의 진짜 특징 — 국소 최적화, 전역 무지

세심하게 가이드되지 않은 AI 코드의 핵심 특징은 하나로 요약된다. 지금 이 프롬프트의 지시에는 충실하지만, 시스템 전체의 틀은 존중하지 않는다는 것이다. 당장의 목적만 푼다. 눈앞의 함수는 동작하게 만들지만, 그 옆에 이미 같은 일을 하는 함수가 있는지, 우리 코드가 어떤 규칙으로 정리돼 왔는지는 모른다. 운영 연구(operations research)에서 부분만 최적화하다 전체를 망치는 현상을 국소 최적화(local optimization)라고 부르는데, AI 코드가 딱 그렇다. 부분은 똑똑하고 전역은 무지하다.

그 결과가 중복과 우회다. 이미 있는 유틸리티를 모른 채 비슷한 함수를 새로 만들고, 기존 구조에 맞추기 어려우면 옆길로 새 경로를 판다. 한두 번이면 티가 안 나지만, 빠르게 생성되는 만큼 빠르게 쌓인다.

# 기존 코드베이스에 이미 있는 공용 함수
def format_price(amount):
    return f"{amount:,}원"

# 프롬프트: "결제 화면에 가격 표시 기능 추가해줘"
# AI가 생성한 코드 — 기존 함수의 존재를 모른 채 새로 만든다
def show_price(value):            # 1) 같은 일을 하는 함수가 또 생긴다 (중복)
    won = format(value, ',')      # 2) 천 단위 콤마 로직을 따로 다시 구현한다
    return won + "원"             # 3) 단위 표기 규칙도 별도 — 한쪽만 바뀌면 어긋난다

코드 설명. 위 예시는 AI가 왜 중복을 만드는지 한눈에 보여준다. 프롬프트에는 "가격 표시를 추가해 달라"는 지시밖에 없고, AI는 그 지시에 충실히 동작하는 함수를 만든다. 문제는 코드베이스에 이미 같은 일을 하는 함수가 있다는 사실을 모른다는 점이다. 그래서 천 단위 콤마와 단위 표기라는 똑같은 규칙이 두 곳에 따로 생긴다. 나중에 표기 규칙을 "원" 대신 "₩"로 바꾸기로 하면, 한쪽만 고치고 다른 한쪽을 놓쳐 화면마다 표기가 어긋난다. 지시는 완벽히 따랐지만 전체의 일관성은 깨진 것이다.

이 부채는 '그럴싸하다'

예전의 기술부채는 대개 티가 났다. 뻔한 버그이거나, 누가 봐도 지저분한 코드였다. AI가 쌓는 부채는 다르다. 그럴싸하다. 변수명도 깔끔하고, 주석도 붙어 있고, 작게 떼어 만든 단위 테스트(unit test, 함수 하나하나가 제대로 도는지 검사하는 자동 시험)는 통과한다. 리뷰에서 바로 걸러내기가 어렵다.

균열은 더 나중에, 더 큰 단위에서 드러난다. 통합 테스트(integration test, 여러 모듈을 붙여 함께 도는지 검사하는 시험)나 실제 운영에서 비로소 깨진다. 단위 테스트는 부분의 정합만 보지, 전체의 정합은 보지 못하기 때문이다.

다이어그램 설명. 위 흐름은 AI 코드가 어느 지점에서 부채로 바뀌는지 보여준다. 프롬프트 한 줄에서 출발해 AI가 당장의 목적만 푸는 코드를 만들고, 작은 단위 테스트는 무사히 통과한다 — 여기까지가 "그럴싸하다"고 느끼는 구간이다. 진짜 문제는 통합·운영에서 균열이 드러나는 지점이다. 시스템 전체의 틀을 모른 채 만든 코드라 중복과 우회가 누적되고, 그 비용이 쌓여 몇 달 뒤에는 오히려 개발 속도가 역전된다. 가장 빠지기 쉬운 함정은 통과한 단위 테스트가 안전을 보장한다고 믿는 데 있다. 단위 테스트는 부분이 도는지만 확인할 뿐, 그 부분이 시스템과 어긋나는지는 알려주지 않는다.

데이터도 같은 이야기를 한다

이건 체감만의 이야기가 아니다. 코드 분석 업체 GitClear가 2억 1,100만 줄(2020~2024)을 분석한 결과, 작성한 지 2주 안에 다시 고쳐지는 코드(churn, 갓 커밋한 코드가 곧바로 수정되는 비율로 미성숙·저품질 신호로 본다)가 3.1%에서 5.7%로 늘었다. 복사-붙여넣기로 들어온 줄은 8.3%에서 12.3%로 올라, 처음으로 리팩터링·이동된 줄 수를 넘어섰다. 중복 코드 블록이 든 커밋은 한 해 사이 약 8배로 뛰었다. 코드가 빨라지는 동안 중복과 churn도 같이 빨라졌다.

전달 속도 쪽 지표도 어긋난다. 구글이 주관하는 개발 성과 연구 DORA의 2024년 보고서는, AI 도입이 25% 늘 때 전달 처리량(throughput, 변경을 운영에 내보내는 속도)이 1.5% 줄고 전달 안정성(stability, 배포가 사고 없이 도는 정도)이 7.2% 떨어진다고 추정한다. 흥미로운 건 그 원인이 "AI 코드가 형편없어서"가 아니라는 분석이다. AI를 쓰면 한 번에 묶어 내보내는 변경의 덩어리(배치 크기)가 커지고, 작은 단위로 자주 검증하는 기본기가 무너지면서 안정성이 흔들린다.

핵심은 비율이다 — 두 배 빨리 짰으면 절반만 유지보수해야 한다

여기서 가장 또렷한 정리는 애자일 분야의 오래된 저자 James Shore에게서 나온다. 그의 주장은 단순하다. AI가 코드를 두 배 빨리 만든다면, 그 코드는 유지보수 비용이 절반이어야 본전이라는 것이다. 세 배 많이 만들면 유지보수는 3분의 1이어야 한다. 생성 속도가 유지보수 비용을 같은 비율로 깎아 주지 못하면, 속도 이득은 몇 달 만에 증발한다.

왜 그런가. 코드는 한 번 짜고 끝나는 게 아니라 평생 돌봐야 하는 자산이기 때문이다. Shore가 인용하는 경험칙으로는, 한 달치 코드를 짜면 첫해에 그 코드를 돌보는 데만 열흘, 이후로는 매년 닷새가 든다. 이렇게 쌓이면 보통의 프로젝트에서 2년 반쯤 지나면 일하는 시간의 절반 이상이 새 기능이 아니라 유지보수로 간다. 코드를 빨리 만드는 능력은 이 누적되는 유지보수 더미 위에 더 많은 코드를 더 빨리 얹는 능력이기도 하다.

축	생성 속도	전달 속도
측정 대상	코드가 화면에 찍히는 속도	가치가 운영까지 안전하게 닿는 속도
AI 효과	크게 빨라진다	관리하지 않으면 오히려 느려진다
드러나는 시점	지금 당장	몇 달 뒤 유지보수 더미에서

표 설명. 위 표는 우리가 "AI로 빨라졌다"고 말할 때 실제로 무엇이 빨라졌는지를 갈라 본다. 빨라진 쪽은 코드가 찍히는 생성 속도다. 정작 사업에 중요한 건 가치가 운영까지 닿는 전달 속도인데, 이쪽은 중복·churn·커진 배치를 관리하지 않으면 도리어 느려진다. 두 속도를 한 단어 "빠르다"로 뭉뚱그리는 순간, 우리는 당장 보이는 이득만 세고 몇 달 뒤 청구되는 비용은 빠뜨린다.

그래서 — AI를 유지보수 비용 줄이도록 길들인다

결론은 AI를 쓰지 말자가 아니다. AI가 빠른 만큼 부채도 빠르게 쌓이니, 그 부채를 줄이는 방향으로 도구를 길들이자는 것이다. 개인 작업에서 내가 실제로 효과를 본 방법은 단순하다.

첫째, 지시를 "이걸 만들어"가 아니라 "우리 코드의 이 규칙·이 기존 함수를 따라서 만들어"로 바꾼다. AI에게 전체의 틀을 알려 주면 국소 최적화가 줄어든다. 둘째, 받은 코드를 단위 테스트 통과로 끝내지 않고, 통합 지점과 중복 여부를 사람이 한 번 더 본다. 그럴싸함에 속지 않는 마지막 관문이다. 셋째, 한 번에 내보내는 변경을 작게 쪼갠다 — DORA가 가리킨 그 기본기다.

생성 속도는 공짜로 주어지지만, 전달 속도는 길들여야 얻는다. AI가 코드를 빨리 만들어 주는 건 시작일 뿐이고, 그 코드의 유지보수 비용까지 줄여 줄 때 비로소 진짜 이득이 된다. 빨라진 손을 자랑하기 전에, 몇 달 뒤의 나에게 청구서가 가지 않는지를 먼저 묻는 습관이 필요하다.

---

참고한 공개 자료:

• James Shore, "You Need AI That Reduces Maintenance Costs" — https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs
• GitClear, "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones" — https://www.gitclear.com/ai_assistant_code_quality_2025_research
• DORA, "Accelerate State of DevOps Report 2024" — https://dora.dev/research/2024/dora-report/
• Google Cloud Blog, "Announcing the 2024 DORA report" — https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report

---

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