AI 시대의 좋은 개발자는 코드를 더 많이 만들지 않는다
AI 코딩 에이전트 시대에 코드 생산량보다 유지보수 비용과 검증 가능한 작은 변경이 더 중요해지는 이유를 정리합니다.
이 글은 아래 두 글을 읽고, 개인적인 해석과 생각을 덧붙여 정리했습니다.
요즘 AI 코딩 에이전트는 코드를 정말 빠르게 만든다.
Codex, Claude Code, Cursor, Copilot 같은 도구를 쓰면 예전에는 몇 시간이 걸리던 수정도 몇십 분 만에 끝나곤 한다. 구현 초안, 테스트 코드, 리팩터링, 문서 정리 같은 작업은 이미 AI의 도움을 꽤 자연스럽게 받는 영역이 됐다.
처음에는 이 변화가 단순히 생산성 향상처럼 보인다. 코드를 더 빨리 쓸 수 있으니 더 많은 일을 할 수 있고, 더 많은 일을 할 수 있으니 팀의 속도도 올라갈 것처럼 보인다.
하지만 최근 몇몇 글을 읽으면서 질문이 조금 바뀌었다.
중요한 것은 “AI가 코드를 빨리 쓰는가?”가 아니다.
진짜 질문은 “AI가 만든 코드는 나중에 유지보수하기 쉬운가?”다.
James Shore의 글은 AI 코딩 에이전트가 코드 생산량만 늘리고 유지보수 비용을 줄이지 못하면 장기적으로 손해일 수 있다고 말한다. Sean Goedecke의 글은 AI가 단기 생산성을 높이는 대신 개발자가 손으로 코드를 쓰며 배우던 성장 경로를 약하게 만들 수 있다고 말한다.
두 글의 결은 다르지만, 결국 같은 문제로 이어진다.
AI 시대에 개발자가 신경 써야 할 것은 단순한 코드 작성 속도가 아니다. 유지 가능한 변경을 만들 수 있는가. 그리고 그 변경을 판단할 수 있는 능력을 계속 유지할 수 있는가.
그래서 AI 코딩 에이전트의 진짜 가치는 “코드를 더 많이 쓰게 해준다”가 아니라 “같은 문제를 더 적고 명확하며 검증 가능한 코드로 해결하게 해준다”에 가까워야 한다.
코드를 빨리 쓰는 것과 오래 유지하는 것은 다르다
James Shore의 글에서 가장 강한 주장은 단순하다.
코드는 작성하는 순간 끝나는 것이 아니라, 작성한 뒤 계속 유지해야 하는 대상이다. 버그를 고쳐야 하고, 의존성을 업데이트해야 하고, 설계를 정리해야 하고, 다음 기능을 붙일 때 다시 이해해야 한다.
개발팀의 생산성이 시간이 지나며 떨어지는 이유도 여기에 있다. 처음에는 대부분의 시간을 새 기능에 쓸 수 있다. 하지만 코드가 쌓일수록 유지보수해야 할 표면적이 늘어난다. 어느 순간 새 기능보다 기존 코드의 버그, 정리, 호환성, 운영 이슈에 더 많은 시간이 들어간다.
Shore는 이를 일부러 단순한 모델로 보여준다. AI가 코드 생산량을 2배로 늘렸다고 해보자. 그런데 그 코드가 유지하기 더 어렵다면, 생산성 이득은 생각보다 빨리 사라진다. 심지어 AI 사용을 중단하더라도 이미 들어간 코드는 남는다. 도구의 속도 이득은 사라지지만, 코드의 유지보수 비용은 계속 남는 것이다.
이 모델은 현실을 완벽하게 설명하는 수식이라기보다 경고음에 가깝다. 실제 유지보수 비용은 팀, 도메인, 코드베이스, 리뷰 문화, 테스트 수준에 따라 달라진다.
그래도 방향은 맞다고 본다.
코드 작성 비용이 낮아졌다고 해서 코드 유지 비용까지 자동으로 낮아지지는 않는다. 오히려 코드를 더 많이 만들 수 있게 되면, 유지해야 할 코드도 더 빨리 늘어난다.
AI의 위험은 틀린 코드보다 맥락 없는 코드다
AI가 만든 코드의 위험을 이야기하면 보통 “틀린 코드”를 먼저 떠올린다. 존재하지 않는 API를 호출하거나, 엉뚱한 타입을 쓰거나, 테스트를 통과하지 못하는 코드를 만드는 경우다.
이런 문제는 비교적 발견하기 쉽다. 빌드가 깨지고, 테스트가 실패하고, 런타임 에러가 난다. 물론 귀찮고 비용이 들지만 적어도 문제라는 사실은 드러난다.
더 위험한 것은 그럴듯하지만 맥락을 모르는 코드다.
당장 동작한다. 테스트도 몇 개 통과한다. 리뷰 화면에서 크게 이상해 보이지 않는다. 하지만 기존 아키텍처와 어긋나거나, 책임 경계를 흐리거나, 비슷한 로직을 한 번 더 만들거나, 예외 처리를 넓게 잡아버린다.
이런 코드는 처음에는 티가 잘 나지 않는다. 문제는 몇 달 뒤에 온다. 다음 사람이 해당 영역을 수정하려고 할 때 왜 이렇게 되어 있는지 알 수 없다. 어디까지 바꿔도 되는지 확신이 없다. 테스트는 있지만 무엇을 보장하는지 불분명하다. 결국 작은 변경에도 시간이 오래 걸리고, 수정 범위가 넓어지고, 버그 재발률이 올라간다.
2026년에 공개된 대규모 연구인 Debt Behind the AI Boom도 비슷한 경고를 한다. 이 연구는 공개 GitHub 저장소와 AI 흔적이 남은 커밋을 분석한 것이기 때문에 모든 현업 코드에 그대로 일반화할 수는 없다. 다만 AI가 만든 커밋 중 일부가 코드 스멜, 정확성 문제, 보안 문제를 만들고, 추적 가능한 AI 도입 이슈 중 22.7%가 최신 버전까지 남아 있었다는 결과는 가볍게 볼 수 없다.
특히 흥미로운 지점은 AI가 단순한 코드 스멜이나 반복적인 유지보수 작업에는 도움이 될 수 있지만, 정확성이나 보안처럼 실행 맥락을 깊게 이해해야 하는 문제에서는 더 조심해야 한다는 점이다.
결국 AI가 만든 코드를 볼 때 중요한 질문은 “돌아가나요?” 하나로 끝나지 않는다.
- 기존 책임 경계 안에 들어가는가?
- 같은 로직을 다른 곳에 한 번 더 만들지는 않았는가?
- 예외와 실패 상태를 너무 넓게 뭉개지 않았는가?
- 이 변경을 다음 사람이 이해하고 고칠 수 있는가?
- 테스트가 실제 위험을 잡고 있는가?
AI 코딩 에이전트는 빠르게 코드를 만들 수 있다. 하지만 그 코드가 시스템 안에서 어떤 의미를 갖는지는 여전히 사람이 판단해야 한다.
반대로 볼 근거도 있다
그렇다고 “AI 코딩 에이전트는 유지보수 비용을 늘리고 개발자를 약하게 만든다”로 단정하면 너무 단순하다.
반대 근거도 있다.
GitHub의 Copilot 연구는 5년 이상 경험이 있는 개발자 202명을 대상으로 한 통제 실험에서 Copilot을 사용한 그룹의 코드가 기능성, 가독성, 신뢰성, 유지보수성, 간결성 평가에서 더 좋았다고 주장한다.
이 결과는 중요하다. AI가 무조건 코드 품질을 떨어뜨린다는 주장에 제동을 건다. 명확한 과제, 제한된 범위, 경험 있는 개발자, 테스트와 리뷰가 있는 환경에서는 AI가 실제로 더 나은 결과를 돕는 경우가 있다.
다만 이 연구가 복잡한 레거시 시스템이나 장기 운영 코드베이스의 유지보수 비용까지 증명한 것은 아니다. 실험 과제에서 좋은 평가를 받은 코드와, 몇 년 동안 여러 팀이 바꾸는 제품 코드의 유지 비용은 다른 문제다.
METR의 2025년 연구는 또 다른 방향의 반례를 준다. 경험 많은 오픈소스 개발자들이 자신에게 익숙한 대형 저장소에서 실제 이슈를 처리할 때, AI 도구 사용 시 평균 19% 더 오래 걸렸다고 보고했다. 이것도 모든 환경에 일반화할 수는 없다. 연구 자체도 특정 시점의 도구와 특정한 작업 환경을 다룬다.
METR은 이후 2026년 업데이트에서 실험 설계를 바꾸고 있다고 설명했다. 최신 도구에서는 결과가 달라질 수 있고, 선택 편향 같은 문제도 더 신중히 다뤄야 한다는 취지다.
결국 현재까지의 증거는 한쪽으로 깔끔하게 정리되지 않는다.
AI는 어떤 작업에서는 빠르고 좋다. 어떤 작업에서는 느리고 위험하다. 명확한 과제에서는 도움이 되지만, 오래된 맥락과 암묵지가 많은 코드베이스에서는 오히려 비용을 만들 수 있다.
미국 BLS도 2024~2034년 소프트웨어 개발자, QA, 테스터 고용이 15% 성장할 것으로 전망한다. 이 전망이 AI의 영향을 충분히 반영했는지는 별도 문제지만, 적어도 “개발자 직업이 곧 사라진다”는 단순한 결론과는 거리가 있다.
Stack Overflow의 2025 개발자 설문도 비슷하다. 많은 개발자가 AI 도구를 쓰고 있지만, 복잡한 작업을 잘 처리한다고 강하게 믿는 비율은 제한적이다. 도입은 빠르지만 신뢰는 아직 균일하지 않다.
내가 보기엔 결론은 이렇다.
AI는 유지보수 비용을 늘릴 수도 있고 줄일 수도 있다. 차이는 AI를 코드 생성 도구로만 쓰느냐, 품질 관리와 맥락 관리 도구로도 쓰느냐에서 갈린다.
소프트웨어 엔지니어링의 커리어 모델도 흔들린다
Sean Goedecke의 글은 유지보수 비용보다 개발자 커리어 쪽에 더 초점을 둔다.
그의 주장은 불편하다. AI를 쓰면 장기적으로 코딩 감각이나 코드베이스 이해력이 약해질 수 있다는 우려가 있더라도, 회사가 단기 생산성을 요구한다면 개발자는 결국 AI를 써야 할 수 있다는 것이다.
예전에는 소프트웨어 엔지니어링을 배우는 가장 좋은 방법이 소프트웨어 엔지니어링을 직접 하는 것이었다. 많이 구현하고, 많이 깨뜨리고, 많이 디버깅하고, 많이 리뷰받으면서 성장했다. 주니어는 손으로 코드를 쓰며 시스템 감각을 만들고, 그 경험이 쌓여 시니어의 설계와 리뷰 판단으로 이어졌다.
그런데 AI가 구현의 상당 부분을 대신하면 이 경로가 흔들릴 수 있다.
1
2
3
4
주니어
→ 많은 구현 경험
→ 디버깅과 운영 경험
→ 시니어의 설계/리뷰/판단 능력
이 흐름이 약해지고, 대신 이런 흐름이 생길 수 있다.
1
2
3
4
5
요구사항 입력
→ AI가 구현 초안 작성
→ 사람은 결과를 승인
→ 직접 시행착오를 겪는 시간 감소
→ 판단 기준이 충분히 자라지 않음
물론 이게 모든 개발자에게 그대로 일어난다는 뜻은 아니다. 좋은 개발자는 AI를 쓰면서도 계속 코드를 읽고, 원인을 추적하고, 테스트를 설계하고, 결과를 비판적으로 검토한다. 오히려 AI를 학습 도구로 잘 쓰면 더 빠르게 성장할 수도 있다.
하지만 아무 생각 없이 위임만 하면 이야기가 달라진다. 코드를 쓰지 않는 것이 문제가 아니라, 코드를 이해하지 않은 채 승인하는 습관이 문제가 된다.
Stanford HAI의 2026 AI Index는 22~25세 소프트웨어 개발자 고용이 2024년 이후 거의 20% 감소했다고 보고했다. 이 수치 하나로 개발자 직업의 미래를 단정할 수는 없다. 다만 초급 개발자가 경험을 쌓는 사다리가 약해지고 있다는 신호로는 볼 수 있다.
Anthropic의 Claude Code 분석에서도 Claude Code 대화의 79%가 어느 정도 자동화 형태로 분류되었다고 한다. AI가 단순한 자동완성이나 조언 도구를 넘어, 작업 일부를 직접 수행하는 도구로 이동하고 있다는 뜻이다.
그래서 앞으로 개발자에게 더 중요해지는 능력은 “코드를 한 줄씩 직접 치는 능력”만은 아닐 것이다.
그보다 중요한 것은 이 변경이 왜 필요한지, 어디까지 바꿔야 하는지, 무엇이 깨질 수 있는지, 어떤 테스트가 있어야 하는지, 어떤 코드는 만들지 말아야 하는지를 판단하는 능력이다.
그래서 개발자는 무엇을 바꿔야 하나
AI 코딩 에이전트를 쓰지 말자는 이야기가 아니다.
오히려 써야 한다. 이미 충분히 강력하고, 앞으로 더 강력해질 가능성이 높다. 문제는 어디에 쓰느냐다.
나쁜 사용법은 대체로 이런 흐름이다.
1
2
3
4
5
6
7
요구사항을 대충 설명한다
→ 에이전트가 큰 변경을 만든다
→ 동작만 보고 머지한다
→ 리뷰는 대충 한다
→ 테스트는 부족하다
→ 문서와 의사결정 기록은 없다
→ 몇 달 뒤 아무도 왜 이렇게 됐는지 모른다
이 흐름에서는 AI가 빠를수록 더 위험하다. 잘못된 변경이 더 빨리 들어가고, 유지보수해야 할 코드가 더 빨리 쌓인다.
반대로 좋은 사용법은 이렇게 가야 한다.
1
2
3
4
5
6
7
작은 작업 단위로 제한한다
→ 기존 구조를 먼저 읽힌다
→ 변경 계획을 먼저 받는다
→ 테스트/타입/린트/보안 체크를 강제한다
→ PR에서 설계 의도와 리스크를 설명한다
→ 사람이 최종 책임지고 리뷰한다
→ AI에게 유지보수성 리뷰까지 시킨다
실무적으로는 AI에게 “코드 써줘”보다 아래 일을 더 자주 시키는 편이 낫다.
기존 코드 이해
이 모듈의 책임, 외부 의존성, 변경 위험, 테스트 포인트를 먼저 정리하게 한다. 코드를 쓰기 전에 시스템을 읽게 해야 한다.
작은 변경 계획
수정 파일 후보, 최소 변경 범위, 사이드이펙트, 롤백 방법을 먼저 제안하게 한다. 계획이 이상하면 구현도 이상해질 가능성이 높다.
테스트 보강
이번 변경에서 깨질 수 있는 케이스를 테스트로 추가하게 한다. 특히 성공 케이스보다 실패 케이스, 경계 조건, 기존 호환성을 보게 해야 한다.
리뷰어 역할
중복, 과한 추상화, 책임 경계 위반, 보안 위험, 레거시 패턴 위반을 찾게 한다. AI는 작성자 역할보다 리뷰어 역할에서 더 안전하게 도움이 되는 경우가 많다.
PR 설명과 문서화
왜 이 방식으로 바꿨는지, 대안은 무엇이었는지, 남은 리스크는 무엇인지 정리하게 한다. AI 시대의 문서는 보고용 산출물이 아니라 다음 AI와 다음 사람에게 주는 입력값이다.
개인적으로 Codex나 Claude Code를 쓸 때도 이 흐름이 더 안전하다고 느낀다.
한 번에 기능 하나를 통째로 맡기기보다, 맥락 파악, 계획, 작은 변경, 테스트, 리뷰로 쪼개는 편이 결과가 낫다. 특히 고객사별 커스터마이징, 오래된 레거시, 납품형 솔루션처럼 보이지 않는 맥락이 많은 코드베이스에서는 더 그렇다.
AI가 빠르게 만든 코드는 당장은 편하다. 하지만 몇 달 뒤 누군가가 “이거 왜 이렇게 되어 있죠?”라고 물었을 때 답할 수 없다면, 그 속도는 빚이 된다.
결론: 더 많은 코드가 아니라 더 작은 변경
이 두 글은 반AI 글이라기보다, AI 시대에 좋은 개발 조직이 무엇을 측정해야 하는지 묻는 글에 가깝다.
코드 생산량, PR 개수, 커밋 수만 보면 AI는 거의 항상 좋아 보일 수 있다. 하지만 장기적으로 봐야 할 지표는 다르다.
- 버그 재발률이 줄었는가?
- 리뷰 시간이 줄었는가, 아니면 대충 승인하는 문화가 생겼는가?
- 변경 범위가 작아졌는가?
- 테스트가 실제 위험을 더 잘 잡는가?
- 온보딩 난이도가 낮아졌는가?
- 같은 영역을 반복해서 다시 고치는 일이 줄었는가?
- 장애와 고객 문의가 줄었는가?
- 문서와 의사결정 기록이 더 좋아졌는가?
AI가 빠르게 만든 코드는 당장은 편하다. 하지만 몇 달 뒤 누군가가 “이거 왜 이렇게 되어 있죠?”라고 물었을 때 답할 수 없다면, 그 속도는 빚이 된다.
AI 코딩 에이전트는 더 많은 코드를 만드는 도구로 쓰면 유지보수 비용을 늘린다. 하지만 더 작고 명확하며 검증 가능한 변경을 만드는 도구로 쓰면 유지보수 비용을 줄일 수 있다.
그래서 앞으로 개발자에게 필요한 태도는 “AI에게 얼마나 많이 시킬 수 있는가”가 아니다.
AI가 만든 결과를 얼마나 좁은 변경으로 통제하고, 얼마나 명확한 기준으로 검증하며, 얼마나 오래 유지 가능한 형태로 남길 수 있는가다.
코드는 빨리 쓸수록 좋은 것이 아니다. 오래 유지할 수 있을 만큼만, 이해 가능한 크기로, 검증 가능한 방식으로 들어가야 한다.
AI 시대의 좋은 개발자는 코드를 더 많이 생산하는 사람이 아니라, 생산하지 않아도 될 코드를 막고, 필요한 코드를 작게 만들고, 들어간 코드의 미래 비용을 줄이는 사람이다.