AI 코딩 에이전트, 결국 '유지보수 비용'을 줄여야 진짜다

'AI가 코드를 짜준다'는 말의 함정

요즘 AI 코딩 에이전트 이야기가 정말 많이 나와요. Cursor, Claude Code, GitHub Copilot 같은 도구들이 생산성을 몇 배로 올려준다는 광고를 매일 같이 보게 되죠. 그런데 James Shore라는 베테랑 개발자(애자일/익스트림 프로그래밍 분야에서 오래 일한 분이에요)가 흥미로운 글을 하나 올렸어요. 한 줄로 요약하면 "코드를 빨리 써주는 AI는 의미 없다, 유지보수 비용을 줄여주는 AI여야 한다"는 주장이거든요.

왜 이런 말을 하느냐면, 소프트웨어 개발에서 정말 비싼 건 코드를 처음 짜는 비용이 아니라 이미 짜놓은 코드를 계속 고치고 늘려가는 비용이기 때문이에요. 보통 프로젝트 전체 비용의 60~80%가 유지보수에 들어간다는 연구 결과도 있어요. 그러니까 신규 코드 작성 속도를 두 배로 올려봤자, 전체 비용은 잘해야 10~20% 줄어드는 거예요. 반면에 유지보수가 쉬운 코드를 만들어주면 훨씬 큰 절감 효과가 생기죠.

지금 AI 코딩 도구의 진짜 문제

글에서 지적하는 핵심 문제는 이래요. 현재 AI 에이전트들은 "동작하는 코드"를 빠르게 뱉어내는 데는 능숙한데, 그 코드가 나중에 읽고 고치기 좋은 구조인지는 신경 쓰지 않는다는 거예요. 변수명이 어색하거나, 비슷한 로직이 여기저기 중복되거나, 한 함수가 너무 많은 일을 하거나, 추상화가 어설프거나 하는 문제들이요.

이게 왜 무서우냐면, AI가 만든 코드가 쌓이면 쌓일수록 "기술 부채(technical debt)"가 빠르게 늘어나거든요. 기술 부채라는 건 쉽게 말해 "지금은 빨리 가려고 대충 짠 코드, 나중에 이자처럼 더 비싸게 갚아야 하는 빚" 이에요. AI가 신나게 코드를 뽑아내는 동안 부채도 같이 폭증한다면, 6개월 뒤에는 아무도 손대기 싫은 거대한 진흙덩어리가 되어버려요. 실제로 GitClear 같은 곳에서 발표한 연구를 보면, AI 도구를 많이 쓰는 코드베이스일수록 코드 중복률(duplication)과 churn(짧은 시간 안에 다시 고쳐지는 코드 비율)이 늘어난다는 결과도 나오고 있어요.

그럼 어떤 AI를 써야 할까

저자가 제시하는 기준은 꽤 명확해요. 단순히 "이 기능 만들어줘"에 코드를 뱉어내는 AI가 아니라, 테스트를 먼저 짜고, 기존 코드를 리팩터링하면서 새 기능을 추가하고, 중복을 발견하면 추출해주는 AI여야 한다는 거예요. 익스트림 프로그래밍에서 말하는 "한 발짝씩 안전하게 전진하기(small, safe steps)" 원칙을 AI도 따라야 한다는 거죠.

예를 들어 결제 로직에 새 옵션을 하나 추가한다고 쳐봐요. 별로인 AI는 if문 하나 더 끼워 넣고 끝낼 거예요. 좋은 AI라면 "이 결제 로직이 이미 너무 복잡해졌으니 전략 패턴(Strategy Pattern)으로 분리하면 어떨까요? 먼저 기존 동작에 대한 테스트를 추가하고, 안전하게 구조를 바꾼 다음 새 옵션을 깔끔하게 끼워 넣을게요" 이렇게 제안할 수 있어야 한다는 거예요.

업계는 이미 움직이고 있다

사실 이런 문제의식은 곳곳에서 나오고 있어요. Anthropic이 Claude Code에 "plan mode"를 도입한 것도, GitHub이 Copilot에 "refactor suggestion" 기능을 강화하는 것도, Cursor가 큰 코드베이스 컨텍스트를 더 잘 이해하게 만드는 것도 다 같은 맥락이에요. 그냥 자동완성이 아니라 "엔지니어처럼 사고하는 동료" 를 만들려는 거죠. Sourcegraph의 Cody나 Tabnine 같은 도구들도 "우리 회사 코드 스타일에 맞춰서 리팩터링한다"는 점을 강조하기 시작했고요.

반대로 "vibe coding"이라고 부르는 흐름도 있어요. 코드 품질 따위 신경 안 쓰고 일단 LLM에 던져서 결과물만 받는 스타일인데, 이게 단기 프로토타입에는 괜찮지만 프로덕션에 가져가면 위험하다는 경고가 많이 나오고 있죠. 결국 업계는 "빠르게 뽑아내는 AI" vs "오래 가는 코드를 만드는 AI"로 갈라지는 중이에요.

한국 개발자에게 주는 시사점

국내 회사들도 AI 코딩 도구 도입을 빠르게 늘리고 있는데요, 도입 효과를 측정할 때 "PR 수"나 "라인 수" 같은 지표만 보면 함정에 빠지기 쉬워요. 진짜 봐야 할 건 "6개월 뒤에 이 코드가 얼마나 쉽게 고쳐지는가" 예요. 사이드 프로젝트라면 vibe coding으로 빠르게 만들어도 되지만, 회사 코드라면 AI에게 "이 함수 너무 길지 않아? 분리하는 게 좋을까?"라고 한 번 더 물어보는 습관을 들이는 게 좋아요.

그리고 시니어 개발자들의 역할이 바뀌고 있어요. 직접 코드를 치는 시간보다 "AI가 만든 코드의 구조를 평가하고 방향을 잡아주는" 시간이 더 중요해지고 있거든요. 코드 리뷰 스킬, 아키텍처 감각, 리팩터링 능력이 그 어느 때보다 중요해진 시대예요.

마무리

결국 핵심은 이거예요. "AI가 만들어준 코드가 빠른가"보다 "6개월 뒤에도 그 코드를 고치고 싶은 마음이 드는가"가 더 중요하다는 거. 여러분은 어떻게 생각하세요? AI 도구를 쓰면서 "오, 이건 진짜 유지보수까지 생각해주네" 싶었던 경험이 있나요? 아니면 반대로 "이거 6개월 뒤에 누가 고치지..." 싶은 코드를 양산한 적이 있나요?