AI 시대의 좋은 개발자는 코드를 더 많이 만들지 않는다

작성 2026년 5월 12일

이 글은 아래 두 글을 읽고 개인적인 해석과 생각을 덧붙여 정리했습니다.

You Need AI That Reduces Maintenance Costs

Software engineering may no longer be a lifetime career

요즘 AI 코딩 에이전트는 코드를 정말 빠르게 만든다.

Codex, Claude Code, Cursor, Copilot 같은 도구를 쓰면 예전에는 몇 시간이 걸리던 수정도 몇십 분 만에 끝나곤 한다. 구현 초안, 테스트 코드, 리팩터링, 문서 정리 같은 작업은 이미 AI의 도움을 꽤 자연스럽게 받는 영역이 됐다.

처음에는 이 변화가 단순히 생산성 향상처럼 보인다. 코드를 더 빨리 쓰면 더 많은 일을 할 수 있고 팀의 속도도 올라갈 것 같다.

하지만 최근 몇몇 글을 읽으면서 질문이 조금 바뀌었다. AI가 코드를 빨리 쓰는지는 이제 별로 궁금하지 않다.

진짜 질문은 “AI가 만든 코드는 나중에 유지보수하기 쉬운가?”다.

James Shore의 글은 AI 코딩 에이전트가 코드 생산량만 늘리고 유지보수 비용을 줄이지 못하면 장기적으로 손해일 수 있다고 말한다. Sean Goedecke의 글은 다른 걱정을 한다. 개발자는 손으로 코드를 쓰며 배워왔다. AI가 단기 생산성을 높이는 대신 그 성장 경로를 약하게 만들 수 있다고 본다.

두 글의 결은 다르지만 닿는 문제는 같다.

AI 시대에 개발자가 신경 써야 할 것은 단순한 코드 작성 속도가 아니다. 유지 가능한 변경을 만들 수 있는가. 그리고 그 변경을 판단할 수 있는 능력을 계속 유지할 수 있는가.

그래서 AI 코딩 에이전트의 진짜 가치는 “코드를 더 많이 쓰게 해준다”가 아니라 “같은 문제를 더 적고 명확하며 검증 가능한 코드로 해결하게 해준다”에 가까워야 한다.

코드를 빨리 쓰는 것과 오래 유지하는 것은 다르다

James Shore의 주장은 단순하다. 코드는 작성한 뒤에도 계속 유지해야 하는 대상이다. 버그를 고치고 의존성을 업데이트해야 한다. 설계도 정리해야 하고 다음 기능을 붙일 때는 다시 이해해야 한다.

유지보수할 표면적이 늘어나는 것은 팀의 속도가 떨어지는 한 가지 원인이다. 다만 코드의 양만으로 비용을 예측할 수는 없다. 변경 빈도, 책임 경계, 호환성 요구, 운영 방식에 따라 오래된 코드도 안정적으로 유지할 수 있다.

Shore는 이를 일부러 단순한 모델로 보여준다. AI가 코드 생산량을 2배로 늘렸다고 해보자. 그런데 그 코드가 유지하기 더 어렵다면 생산성 이득은 생각보다 빨리 사라진다. 심지어 AI 사용을 중단하더라도 이미 들어간 코드는 남는다. 도구의 속도 이득은 사라져도 코드의 유지보수 비용은 계속 남는다.

이 모델은 유지보수 비용을 무시했을 때의 위험을 보여주는 사고 실험이다. 현실을 완벽하게 설명하는 수식은 아니다. 실제 유지보수 비용은 팀, 도메인, 코드베이스, 리뷰 문화, 테스트 수준에 따라 달라진다.

그래도 방향은 맞다고 본다. 코드 작성 비용이 낮아졌다고 해서 코드 유지 비용까지 자동으로 낮아지지는 않는다. 오히려 코드를 더 많이 만들 수 있게 되면 유지해야 할 코드도 더 빨리 늘어난다.

틀린 코드뿐 아니라 맥락 없는 코드도 위험하다

AI가 만든 코드의 위험을 이야기하면 보통 틀린 코드를 먼저 떠올린다. 존재하지 않는 API를 호출하거나 엉뚱한 타입을 쓰거나 테스트를 통과하지 못하는 코드를 만드는 경우다.

이 중 일부는 빌드 오류나 테스트 실패로 드러난다. 하지만 테스트하지 않은 조건에서만 발생하는 로직 오류나 보안 문제는 쉽게 발견되지 않을 수 있다.

여기에 더해 그럴듯하지만 시스템의 맥락과 맞지 않는 코드도 경계해야 한다.

당장 동작하고 테스트도 몇 개 통과한다. 리뷰 화면에서 크게 이상해 보이지 않는다. 하지만 기존 아키텍처와 어긋난다. 책임 경계를 흐리거나 비슷한 로직을 한 번 더 만들거나 예외 처리를 넓게 잡아버린다.

이런 코드는 처음에는 티가 잘 나지 않는다. 문제는 몇 달 뒤에 온다. 다음 사람이 해당 영역을 수정하려고 할 때 왜 이렇게 되어 있는지 알 수 없고 어디까지 바꿔도 되는지 확신이 없다. 테스트는 있지만 무엇을 보장하는지 불분명하다. 결국 작은 변경 하나에도 시간이 오래 걸리고 수정 범위가 넓어진다. 버그 재발률도 올라간다.

2026년에 사전 공개 논문으로 나온 대규모 연구인 Debt Behind the AI Boom도 비슷한 경고를 한다. 공개 GitHub 저장소에서 AI 사용 흔적이 명시된 커밋을 분석했고, 정적 분석 도구가 탐지한 코드 스멜과 정확성·보안 관련 이슈의 변화를 추적했다. 추적 대상 이슈의 22.7%가 연구에서 확인한 각 저장소의 마지막 버전까지 남아 있었다. 다만 정적 분석 경고가 모두 실제 장애나 악용 가능한 취약점이라는 뜻은 아니다. 사람만 작성한 커밋과의 대조 실험도 아니므로, 이 결과만으로 AI가 사람보다 더 많은 문제를 만든다고 결론 내릴 수는 없다.

특히 흥미로운 지점은 이 표본에서 AI 관련 커밋이 코드 스멜은 새로 만든 것보다 더 많이 제거했지만, 정확성·보안 관련 이슈는 제거한 것보다 더 많이 만들었다는 점이다. 실행 맥락을 깊게 이해해야 하는 변경에는 더 세심한 검증이 필요하다는 시사점으로 읽었다.

AI가 만든 코드 앞에서 “돌아가나요?” 하나만 물어서는 부족하다.

기존 책임 경계 안에 들어가는가?
같은 로직을 다른 곳에 한 번 더 만들지는 않았는가?
예외와 실패 상태를 너무 넓게 뭉개지 않았는가?
이 변경을 다음 사람이 이해하고 고칠 수 있는가?
테스트가 실제 위험을 잡고 있는가?

AI 코딩 에이전트는 빠르게 코드를 만들 수 있다. 하지만 그 코드가 시스템 안에서 어떤 의미를 갖는지는 여전히 사람이 판단해야 한다.

반대로 볼 근거도 있다

그렇다고 “AI 코딩 에이전트는 유지보수 비용을 늘리고 개발자를 약하게 만든다”로 단정하면 너무 단순하다.

반대 근거도 있다. GitHub의 Copilot 연구는 Python 경력 5년 이상의 개발자를 모집해 도구 사용 여부를 무작위로 배정하고, 202명의 유효 제출물을 분석했다. Copilot을 사용한 그룹의 코드가 기능성, 가독성, 신뢰성, 유지보수성, 간결성 평가에서 더 좋았다고 보고했다.

이 결과는 중요하다. AI가 무조건 코드 품질을 떨어뜨린다는 주장에 제동을 건다. 명확한 과제, 제한된 범위, 경험 있는 개발자, 테스트와 리뷰가 있는 환경에서는 AI가 실제로 더 나은 결과를 돕는 경우가 있다.

다만 이 연구가 복잡한 레거시 시스템이나 장기 운영 코드베이스의 유지보수 비용까지 증명한 것은 아니다. 실험 과제에서 좋은 평가를 받은 코드는 몇 년 동안 여러 팀이 바꾸는 제품 코드와 유지 비용이 다르다.

METR의 2025년 연구는 또 다른 방향의 반례를 준다. 경험 많은 오픈소스 개발자들이 자신에게 익숙한 대형 저장소에서 실제 이슈를 처리할 때 AI 도구 사용 시 평균 19% 더 오래 걸렸다고 보고했다. 이것도 모든 환경에 일반화할 수는 없다. 연구 자체도 특정 시점의 도구와 특정한 작업 환경을 다룬다.

METR은 이후 2026년 업데이트에서 실험 설계를 바꾸고 있다고 설명했다. 최신 도구에서는 결과가 달라질 수 있고 선택 편향 같은 문제도 더 신중히 다뤄야 한다는 취지다.

현재까지의 증거는 한쪽으로 깔끔하게 정리되지 않는다. AI는 어떤 작업에서는 빠르고 좋고 어떤 작업에서는 느리고 위험하다. 이 연구들만으로 어떤 과제에서 항상 이득인지 경계를 정할 수는 없지만, 짧은 실험의 품질 점수와 실제 저장소의 작업 시간, 장기 유지 비용을 구분해야 한다는 점은 분명하다.

내 결론은 이렇다.

AI는 유지보수 비용을 늘릴 수도 있고 줄일 수도 있다. 도구를 어떻게 쓰는지는 중요한 조건이지만, 작업 난이도·모델 성능·기존 구조·검증 비용까지 함께 결과를 만든다.

소프트웨어 엔지니어링의 커리어 모델도 흔들린다

Sean Goedecke의 글은 유지보수 비용보다 개발자 커리어 쪽에 더 초점을 둔다.

그가 제시하는 가정은 불편하다. AI에 구현을 맡기는 일이 장기적으로 코딩 감각이나 코드베이스 이해력을 약하게 만든다고 해도, 단기 생산성 이득이 충분하다면 회사는 AI 사용을 요구할 수 있다는 것이다. 그는 능력 저하가 입증된 사실이라고 단정하지는 않는다.

예전에는 소프트웨어 엔지니어링을 배우는 가장 좋은 방법이 소프트웨어 엔지니어링을 직접 하는 것이었다. 많이 구현하고 많이 깨뜨렸다. 디버깅과 리뷰를 많이 받으면서 성장했다. 주니어는 손으로 코드를 쓰며 시스템 감각을 만들었고 그 경험이 쌓여 시니어의 설계와 리뷰 판단이 됐다.

그런데 AI가 구현의 상당 부분을 대신하면 이 경로가 흔들릴 수 있다.

내가 우려하는 경로는 직접 원인을 추적할 기회가 줄고, 이해하지 않은 변경을 승인하는 일이 반복되면서 판단 기준을 훈련할 기회가 줄어드는 것이다. 아직 확정된 인과관계라기보다 점검할 가설이다. AI 사용량이 같아도 결과를 설명하고 디버깅하는 방식에 따라 학습은 달라질 수 있다.

물론 이게 모든 개발자에게 그대로 일어난다는 뜻은 아니다. 좋은 개발자는 AI를 쓰면서도 계속 코드를 읽고 원인을 추적한다. 테스트를 설계하고 결과를 비판적으로 검토한다. 오히려 AI를 학습 도구로 잘 쓰면 더 빠르게 성장할 수도 있다.

하지만 아무 생각 없이 위임만 하면 이야기가 달라진다. 코드를 이해하지 않은 채 승인하는 습관이 문제가 된다. 코드를 직접 쓰지 않는 것 자체는 문제가 아니다.

코드를 한 줄씩 직접 치는 능력만으로는 부족해질 것이다. 이 변경이 왜 필요한지, 어디까지 바꿔야 하는지, 무엇이 깨질 수 있는지, 어떤 테스트가 있어야 하는지, 어떤 코드는 만들지 말아야 하는지를 판단하는 능력이 개발자에게 더 중요해진다.

그래서 개발자는 무엇을 바꿔야 하나

도구 사용 자체를 의무로 만들기보다, 팀이 자주 겪는 변경에서 이익이 남는지 확인하고 싶다. 특히 고객사별 커스터마이징과 레거시 호환성이 많은 납품형 솔루션에서는 “일단 동작함”과 “다음에도 안전하게 바꿀 수 있음”의 차이가 크다.

나쁜 사용법은 대체로 이런 흐름이다.

요구사항을 대충 설명한다
→ 에이전트가 큰 변경을 만든다
→ 리뷰와 테스트를 충분히 하지 않는다
→ 동작만 보고 머지한다
→ 문서와 의사결정 기록을 남기지 않는다
→ 몇 달 뒤 아무도 왜 이렇게 됐는지 모른다

이 흐름에서는 AI가 빠를수록 더 위험하다. 잘못된 변경이 더 빨리 들어가고 유지보수해야 할 코드가 더 빨리 쌓인다.

반대로 좋은 사용법은 이렇게 가야 한다.

작은 작업 단위로 제한한다
→ 기존 구조를 먼저 읽힌다
→ 변경 계획을 먼저 받는다
→ 변경의 위험과 저장소 규칙에 맞는 검증을 수행한다
→ PR에서 설계 의도와 리스크를 설명한다
→ AI에게 유지보수성 리뷰까지 시킨다
→ 사람이 최종 검토한 뒤 병합한다

실무적으로는 AI에게 “코드 써줘”보다 아래 일을 더 자주 시키는 편이 낫다.

기존 코드 이해

이 모듈의 책임, 외부 의존성, 변경 위험, 테스트 포인트를 먼저 정리하게 한다. 코드를 쓰기 전에 시스템을 읽게 해야 한다.

작은 변경 계획

수정 파일 후보, 최소 변경 범위, 사이드이펙트, 롤백 방법을 먼저 제안하게 한다. 계획이 이상하면 구현도 이상해질 가능성이 높다.

테스트 보강

이번 변경에서 깨질 수 있는 케이스를 테스트로 추가하게 한다. 특히 성공 케이스보다 실패 케이스, 경계 조건, 기존 호환성을 보게 해야 한다.

리뷰어 역할

중복, 과한 추상화, 책임 경계 위반, 보안 위험, 레거시 패턴 위반을 찾게 한다. 다만 AI 리뷰도 같은 가정을 놓칠 수 있다. 구현과 같은 모델이 동의했다는 사실은 독립된 검증을 대신하지 못한다.

PR 설명과 문서화

왜 이 방식으로 바꿨는지, 대안은 무엇이었는지, 남은 리스크는 무엇인지 정리하게 한다. AI 시대의 문서는 다음 AI와 다음 사람에게 주는 입력값이다.

개인적으로 Codex나 Claude Code를 쓸 때도 이 흐름이 더 안전하다고 느낀다.

한 번에 기능 하나를 통째로 맡기기보다 맥락 파악, 계획, 작은 변경, 테스트, 리뷰로 쪼개는 편이 결과가 낫다. 특히 고객사별 커스터마이징, 오래된 레거시, 납품형 솔루션처럼 보이지 않는 맥락이 많은 코드베이스에서는 더 그렇다.

AI가 빠르게 만든 코드는 당장은 편하다. 하지만 몇 달 뒤 누군가가 “이거 왜 이렇게 되어 있죠?”라고 물었을 때 답할 수 없다면 그 속도는 빚이 된다.

유지 비용을 확인하는 작은 실험

다음은 아직 수행한 측정이 아니라, 내가 팀에서 적용해보고 싶은 방법이다. 처음부터 모든 코드에 복잡한 평가 체계를 붙이기보다는 자주 바뀌는 한 영역부터 본다.

비교 대상을 고른다. 같은 영역의 유사한 결함 수정이나 기능 변경을 고르고 난이도·담당자·AI 사용 여부를 남긴다. 쉬운 작업만 AI에 배정했다면 비교에 편향이 생긴다.
완료까지의 전체 비용을 기록한다. 구현 시간만이 아니라 사람의 리뷰·재수정 시간, 도구 비용, 배포 후 후속 수정을 함께 본다. 벽시계 시간과 사람이 실제로 쓴 시간은 구분한다.
다음 변경에서 다시 확인한다. 새 담당자가 수정 위치와 이유를 찾을 수 있는지, 같은 로직을 여러 파일에서 함께 바꿔야 하는지 본다. 단기 코드 평가만으로 장기 유지보수성을 확정하지 않는다.

리뷰 기준도 “좋아 보인다”에서 한 단계 구체화할 수 있다.

리뷰 질문	확인할 증거	충분하지 않은 증거
기존 계약을 지켰는가	변경 전후 입력·출력과 호환성 사례	새 코드만 실행한 성공 화면
회귀를 막는가	과거 결함 조건에서 실패하고 수정 후 통과하는 테스트	구현의 반환값을 그대로 복제한 테스트
변경 범위가 적절한가	관련 파일과 호출 경로, 제외한 대안의 이유	수정 줄 수가 적다는 설명
다음 수정이 쉬운가	같은 규칙이 모인 위치와 의사결정 기록	추상화나 문서의 개수

권한 변경과 단순 문구 수정에 같은 검증을 요구할 필요는 없다. 검증 비용도 유지 비용의 일부이므로, 실패 영향과 복구 가능성에 맞춰 가장 작은 충분한 검증을 선택해야 한다.

코드를 덜 만드는 것 자체가 목표는 아니다

제목의 “더 많이 만들지 않는다”는 코드 줄 수를 성과 목표로 삼지 않겠다는 뜻이다. 필요한 테스트, 실패 처리, 명확한 모듈을 추가해서 코드가 늘어나는 것이 더 좋은 선택일 수 있다. 작은 변경도 책임을 여러 곳에 흩뜨리면 다음 변경을 어렵게 만든다.

내가 지키고 싶은 기준은 필요한 변경의 의도를 설명할 수 있고, 실제 위험을 검증할 수 있으며, 다음 사람이 바꿀 위치를 찾을 수 있는가다.

에이전트가 빨리 만든 코드는 당장은 편하다. 그 속도가 이익으로 남는지는 다음 변경과 운영에서 드러난다. 그래서 구현량보다 미래의 수정 비용을 함께 줄이는 방향으로 AI를 쓰고 싶다.