---
title: "AI 코딩 에이전트가 진짜 쓸모 있으려면 유지보수 비용을 줄여야 한다"
published: 2026-05-10T23:39:55.000Z
canonical: https://jeff.news/article/2552
---
# AI 코딩 에이전트가 진짜 쓸모 있으려면 유지보수 비용을 줄여야 한다

제임스 쇼어는 AI 코딩 에이전트의 생산성 논쟁을 ‘코드를 얼마나 빨리 쓰느냐’가 아니라 ‘그 코드의 유지보수 비용이 얼마나 줄었느냐’로 봐야 한다고 주장한다. 코드 생산량이 2배가 됐는데 유지보수 비용이 그대로면 장기적으로 유지보수 총량도 2배가 되고, 코드가 더 읽기 어려워졌다면 손해는 더 빨리 온다. AI 도입의 성공 조건은 속도 향상률의 역수만큼 유지보수 비용을 낮추는 것이다.

- 글의 주장은 아주 직설적임. AI 코딩 에이전트는 코드 작성 속도가 아니라 유지보수 비용을 줄여야 함
  - 코드를 2배 빨리 쓰게 됐다면, 그 코드의 유지보수 비용은 절반이 돼야 함
  - 3배 빨라졌다면 유지보수 비용은 3분의 1이 돼야 함
  - 그렇지 않으면 당장의 속도 향상을 장기 비용으로 바꾸는 거래가 된다는 얘기임

- 이유는 모든 코드가 유지보수 비용을 만들기 때문임
  - 한 달 동안 쓴 코드는 다음 해에 버그 수정, 정리, 의존성 업그레이드 같은 비용을 계속 발생시킴
  - 이 비용은 코드가 살아 있는 동안 해마다 반복됨
  - 새 기능 개발 시간이 줄어드는 건 보통 기능을 못 만들어서가 아니라 이미 만든 코드를 먹여 살리느라 시간이 빠지기 때문임

- 저자는 예시 모델로 유지보수 비용을 숫자로 설명함
  - 한 달치 코드를 쓰면 첫해에 10일, 이후 매년 5일의 유지보수가 든다고 가정함
  - 이 경우 새 프로젝트 첫 달은 전부 새 기능 개발에 쓰지만, 시간이 지날수록 유지보수 비중이 커짐
  - 약 2년 반이 지나면 팀 시간의 절반 이상이 유지보수로 빠지고, 10년 뒤에는 새 기능을 거의 못 만드는 상태에 가까워짐

> [!IMPORTANT]
> 이 글의 핵심 공식은 단순함. AI가 코드 생산량을 2배로 늘리면, 유지보수 비용은 절반으로 줄어야 장기적으로 이득이다.

- AI가 생산성과 유지보수 비용을 동시에 늘리면 상황은 빠르게 망가짐
  - 예를 들어 어떤 에이전트가 코드 산출량을 2배로 늘렸는데, 코드가 더 이해하기 어렵고 리뷰가 부실해 유지보수 비용도 2배가 됐다고 하자
  - 그러면 다음 달 유지보수 부담은 사실상 4배로 뛴다는 게 저자의 모델임
  - 이 경우 AI 도입 후 약 5개월 만에 생산성 이득이 사라지고, 이후에는 도입하지 않았을 때보다 나빠진다고 설명함

- 심지어 AI가 사람과 같은 수준의 유지보수 비용을 만든다고 해도 충분하지 않음
  - 코드 생산량이 2배인데 코드당 유지보수 비용이 그대로면, 전체 유지보수 비용도 2배가 됨
  - 저자의 모델에서는 이런 경우에도 19개월 뒤 도입 전 생산성 수준으로 돌아가고, 40개월 뒤에는 순손실이 됨
  - “AI가 나쁜 코드를 만들지 않는다”만으로는 장기 이득이 보장되지 않는다는 포인트임

- 더 무서운 건 AI를 나중에 끊어도 비용은 남는다는 점임
  - 에이전트 비용이 비싸져서 사용을 중단하면, 코드 작성 속도 이득은 사라짐
  - 하지만 AI가 남긴 코드의 유지보수 비용은 코드가 살아 있는 한 계속 남음
  - 그래서 잘못 도입한 AI는 구독을 해지한다고 원상복구되지 않는다고 설명함

- 저자가 말하는 성공 조건은 “속도 향상의 역수만큼 유지보수 비용을 줄이는 것”임
  - 2배 빠르면 유지보수 비용은 절반
  - 3배 빠르면 유지보수 비용은 3분의 1
  - 그래야 AI를 나중에 제거하더라도 장기 생산성 손해가 남지 않는다고 봄

- 이 글은 반AI 글이라기보다 평가 기준을 바꾸자는 글에 가까움
  - 저자는 AI가 유지보수 작업 자체를 더 빠르게 해주는 식의 다른 레버도 있을 수 있다고 인정함
  - 다만 “코드를 더 많이 만든다”는 지표만 보고 도입하면, 팀은 풀리퀘스트 더미와 읽기 어려운 코드에 묻힐 수 있음
  - 결국 코딩 에이전트 도입의 질문은 “얼마나 빨리 만들었나”가 아니라 “나중에 고칠 때 얼마나 덜 아픈가”여야 함

---
## 기술 맥락

- 이 글의 기술적 선택지는 AI 도입 여부가 아니라, AI를 어떤 지표로 평가할지예요. 코드 생성 속도만 보면 도입 효과가 바로 보이지만, 유지보수 비용은 몇 달이나 몇 년 뒤에 누적돼서 나타나거든요.

- 저자가 유지보수 비용을 강조하는 이유는 소프트웨어 팀의 병목이 시간이 갈수록 새 코드 작성에서 기존 코드 관리로 이동하기 때문이에요. 버그, 리팩터링, 의존성 업그레이드가 쌓이면 새 기능을 만들 여력이 줄어들어요.

- AI 코딩 에이전트가 위험해지는 지점은 리뷰 품질이 같이 떨어질 때예요. 산출량이 늘어난 만큼 팀이 코드를 제대로 읽지 못하면, 이해하기 어려운 변경이 그대로 병합되고 나중에 더 비싼 문제로 돌아와요.

- 그래서 실무에서는 생성 속도뿐 아니라 변경 후 결함률, 리뷰 시간, 되돌림 비율, 리팩터링 빈도, 의존성 업그레이드 난이도 같은 지표를 같이 봐야 해요. AI가 정말 생산성을 올렸는지는 코드가 운영에 들어간 뒤에 더 분명해져요.

## 핵심 포인트

- 코드는 작성 후 버그 수정, 정리, 의존성 업그레이드 같은 유지보수 비용을 계속 만든다는 전제에서 출발함
- 예시 모델에서는 일반 프로젝트도 2년 반 뒤 생산성의 절반 이상을 유지보수에 쓰게 됨
- AI가 코드 생산량을 2배로 늘리고 유지보수 비용도 2배로 늘리면 몇 달 안에 생산성 이득이 사라짐
- AI로 2배 빨라졌다면 코드 유지보수 비용은 절반이 돼야 장기적으로 이득이라는 결론

## 인사이트

AI 코딩 도구 평가에서 ‘얼마나 빨리 만들었나’만 보면 거의 무조건 착시가 생긴다. 팀이 봐야 할 지표는 생성된 코드가 리뷰, 디버깅, 리팩터링, 업그레이드 비용을 얼마나 남기는지다.