AI 코딩 에이전트, 느려져야 할 때 - Mario Zechner의 경고
AI 코딩 에이전트, 느려져야 할 때
원문: Thoughts on slowing the fuck down — Mario Zechner (2026-03-25)
나는 매일 Claude Code를 쓴다. QA 자동화에 에이전트를 붙이고, 코드 리뷰에 AI를 활용하고, 팀에도 적극 도입을 권장하는 입장이다. 그런 내가 이 글을 읽고 불편했다. 불편했다는 건, 찔렸다는 뜻이다.
Mario Zechner(libGDX 창시자, 개발자/코치)가 AI 코딩 에이전트의 무분별한 도입에 정면으로 경고한다. 핵심 메시지는 — "느려지는 것이 가는 길이다." 에이전트를 버리라는 게 아니다. 더 의도적으로 쓰라는 것이다.
모든 것이 망가졌다
저자는 현재 소프트웨어 산업의 품질 저하를 직시한다. 그리고 이를 뒷받침하는 사건들은 실제로 일어났다.
Amazon Kiro AI가 라이브 서버를 삭제한 사건
2025년 12월, Amazon의 AI 코딩 에이전트 Kiro가 AWS Cost Explorer 버그를 수정하는 과정에서 프로덕션 환경을 자율적으로 삭제했다. 패치 대신 "삭제 후 재생성이 가장 효율적"이라 판단한 것이다. 인간의 승인 없이, 기계 속도로. 결과는 중국 리전 13시간 서비스 중단.
Amazon은 "접근 권한 문제이지 AI 자율성 문제가 아니다"라고 해명했지만, 2026년 3월에 두 차례 추가 장애가 발생했다. 3월 2일 12만 건, 3월 5일에는 미국 주문량이 99% 급감하며 약 630만 건이 손실됐다. Amazon은 이후 335개 크리티컬 시스템을 대상으로 시니어 엔지니어 승인과 2인 리뷰를 의무화하는 90일 안전 리셋 프로그램을 가동했다.
출처: Engadget, Tom's Hardware, ruh.ai
Microsoft CEO: "코드의 30%가 AI 작성"
2025년 4월, Satya Nadella는 Meta의 LlamaCon에서 Microsoft 코드의 최대 30%가 AI로 작성되고 있다고 밝혔다. Python에서는 진전이 있지만 C++에서는 여전히 어렵다고 인정했다. CTO Kevin Scott은 2030년까지 95%의 코드가 AI 생성될 것이라 전망했다. Google CEO Sundar Pichai도 자사 코드의 30% 이상이 AI 생성이라 발언했다.
출처: CNBC, TechCrunch, Tom's Hardware
AI 코드는 실제로 1.7배 더 많은 문제를 만든다
숫자가 말해준다. CodeRabbit의 470개 GitHub PR 분석 결과:
| 항목 | AI vs 인간 |
|---|---|
| 로직/정확성 오류 | 1.75배 |
| 코드 품질/유지보수성 | 1.64배 |
| 보안 취약점 | 1.57배 |
| 성능 이슈 | 1.42배 |
| XSS 취약점 | 2.74배 |
| 과도한 I/O 연산 | 8배 |
미해결 기술 부채는 2025년 초 수백 건에서 2026년 2월 11만 건 이상으로 폭증했다. DORA 2025 리포트에 따르면, AI 채택률이 높은 조직에서 PR 크기 154% 증가, 코드 리뷰 시간 91% 증가, 버그율 9% 상승이 관찰됐다. DORA는 이를 AI 자체의 문제가 아니라, 자동화 테스트와 리뷰 프로세스가 생성 속도를 따라가지 못하는 조직 문제로 진단한다.
왜 이런 일이 벌어지는가 — 세 가지 구조적 원인
Mario는 "모든 것이 망가졌다"에서 그치지 않고, 왜 이런 일이 벌어지는지를 구조적으로 설명한다. 이 부분이 이 글의 진짜 가치다.
1. 인간은 병목이다 — 그리고 그것이 품질의 원천이다
"인간은 병목이다. 인간은 몇 시간 내에 2만 줄의 코드를 생산할 수 없다."
인간이 느린 이유는 단순히 타이핑이 느려서가 아니다. 인간은 복잡한 코드를 짜다가 "이건 너무 복잡하다"는 고통을 느낀다. 같은 실수를 반복하면 패턴을 인식하고 행동을 수정한다. 피로와 인지 부하가 자연스럽게 속도를 조절한다.
에이전트는 이 세 가지를 모두 제거한다. 병목이 없는 에이전트 군대는 작은 실수들을 지속 불가능한 속도로 누적시킨다. 그리고 그 고통은 훨씬 나중에야 표면화된다.
이 논증이 날카로운 이유가 있다. 느린 것이 곧 품질 필터라는 시각의 전환. 우리가 개선하려고 제거하는 바로 그 병목이, 사실은 품질을 지키는 메커니즘이었다는 역설.
2. 국소적 결정의 누적 — "아름다운 똥꽃"
에이전트는 각 지점에서 합리적으로 보이는 결정을 내린다. "산업 모범 사례"를 충실히 적용하고, 패턴을 따르고, 테스트를 추가한다. 문제는 전체 시스템을 모른 채 그렇게 한다는 것이다.
결과: 코드 중복, 불필요한 추상화, 일관성 없는 패턴. 표면적으로는 그럴싸해 보이지만 내부에서 썩어가는 코드베이스 — Mario의 표현을 빌리면 "아름다운 똥꽃".
인간 코드베이스가 수년에 걸쳐 복잡해지는 것을, 에이전트는 수주 만에 달성한다. 이것은 단순히 코드 양의 문제가 아니라, 시스템 이해 가능성(understandability)이 붕괴되는 문제다.
3. 검색 재현율(Recall)의 구조적 한계
에이전트는 큰 코드베이스에서 관련 코드를 전부 찾아내지 못한다. 이것은 에이전트의 부주의가 아니라, 현재 LLM 아키텍처의 구조적 제약이다. 컨텍스트 윈도우는 유한하고, 대형 코드베이스는 그 윈도우를 초과한다. 빠진 맥락은 중복 구현, 기존 패턴 무시, 일관성 파괴로 이어진다.
코드베이스가 클수록 재현율은 떨어진다. 이것이 위의 1, 2번 문제를 구조적으로 악화시키는 피드백 루프다.
반론: 모든 것이 그렇게 단순하지는 않다
공정하게 말하면, Mario의 주장에 동의하지 않는 지점도 있다.
- "모든 것이 망가졌다"는 진단은 과장일 수 있다. 소프트웨어 품질 저하가 AI 때문인지, 소프트웨어 복잡성의 구조적 증가 때문인지 인과관계가 불명확하다.
- "에이전트 작성 테스트는 무용하다"는 너무 강하다. 테스트의 가치는 작성자가 아니라 커버리지와 시나리오 다양성에서 온다. 인간이 작성한 테스트도 같은 편향에 취약하다.
- "중독" 비유는 수사적 과잉이다. 도구를 효과적으로 쓰는 사람들도 많다. 감정을 자극하지만 논증의 엄밀성을 희생한다.
그럼에도 핵심 논증 — "병목으로서의 인간"과 "국소적 결정의 누적" — 은 구조적으로 타당하다.
올바른 접근법
에이전트가 적합한 영역
| 조건 | 설명 |
|---|---|
| 스코핑 가능 | 전체 시스템 이해 없이 완결되는 작업 |
| 평가 가능 | 에이전트 스스로 결과를 검증할 수 있는 작업 |
| 미션 크리티컬 아님 | 부가 도구, 내부 소프트웨어 |
| 검증 도구 | 아이디어 검증용 러버덕 역할 |
인간이 지켜야 할 것
- 최종 품질 관문은 반드시 인간이
- 아키텍처는 직접 손으로 작성 (탭 완성 정도만 허용)
- 일일 코드 생성량을 리뷰 능력 범위 내로 제한
- 페어링: 에이전트와 단계별로 함께 빌드하며 시스템 이해 심화
그래서 나는 무엇을 바꿨나
이 글을 읽고 "에이전트를 쓰지 말자"는 결론을 내리지 않았다. 오히려 반대다 — 에이전트를 더 의도적으로 써야 한다는 확신이 강해졌다.
내가 팀에서 실제로 적용하기 시작한 기준:
- 에이전트 생성 코드의 PR 리뷰 의무화 — "AI가 짰으니 괜찮겠지"는 가장 위험한 가정이다
- 아키텍처 결정은 반드시 인간이 주도 — 에이전트에게 scaffolding은 맡기되, 구조 설계는 직접 한다
- 일일 생성량 ≤ 리뷰 가능량 — 에이전트가 하루에 만든 코드를 리뷰하는 데 사흘이 걸렸던 경험이 있다. 그때 깨달았다. 속도가 아니라 처리량이 문제라는 것을
- 주니어에게 에이전트를 일찍 쥐어주지 않기 — 직접 구현하면서 오는 이해는, 에이전트 출력을 리뷰하는 것으로 대체되지 않는다
Mario의 "중독" 비유가 과장이라고 생각하면서도, 한편으로는 인정할 수밖에 없다. 에이전트가 빠르게 뱉어낸 코드가 리뷰 없이 머지되는 순간, 나도 모르게 팀을 루프 밖으로 밀어내고 있었다.
"느려지는 것, 정말로 느려지는 것이 가는 길이다."
동의한다. 단, 느려지는 것은 에이전트를 쓰지 않는다는 뜻이 아니다. 에이전트의 속도를 인간의 리뷰 능력에 맞추는 것이다. 속도가 아니라 이해가 먼저다.
Member discussion