--- title: "AI 코딩 에이전트 때문에 소프트웨어가 개판 됐는데 아무도 모름" published: 2026-03-25T15:00:00.000Z canonical: https://jeff.news/article/153 --- # AI 코딩 에이전트 때문에 소프트웨어가 개판 됐는데 아무도 모름 코딩 에이전트 등장 1년 만에 소프트웨어 품질이 심각하게 떨어지고 있다는 경고. 에이전트한테 다 맡기다 보니 코드베이스가 감당 안 되는 복잡성 덩어리로 변해가는 중. 필자는 '속도 좀 줄이고 인간이 다시 주도권 잡아야 함'이라고 주장함. - **코딩 에이전트** 도입 1년차, AWS·Microsoft 등 대형 서비스도 품질 저하 체감 중 - 에이전트는 실수를 **학습하지 않고** 반복하며, 속도가 빠른 만큼 '작은 버그'가 기하급수적으로 쌓임 - **아키텍처·API 설계** 같은 핵심 결정을 에이전트에 위임하면 유지보수 불가능한 복잡성 폭탄이 됨 - 에이전트의 **코드베이스 검색(agentic search)** 은 recall이 낮아서 코드 중복·비일관성이 자동 생산됨 - 해결책: **속도 줄이고**, 핵심 구조는 직접 짜고, 에이전트 출력물은 반드시 인간이 최종 검토 --- ## 다 망가지고 있다 코딩 에이전트가 본격 등장한 지 약 1년. 소프트웨어가 **이상하리만치 불안정**해지고 있다는 느낌이 팽배함. **98% 업타임**이 대형 서비스에서도 예외가 아닌 기본값처럼 돼버렸고, UI 버그는 QA팀이 잡았어야 할 수준인데도 그냥 출시되는 경우가 늘고 있음. AWS에서 AI 관련 장애가 있었다는 보도가 나왔다가 즉시 부정됐지만, 이후 내부적으로 '90일 리셋'이 진행됐다는 후문. **Satya Nadella**는 Microsoft 코드의 상당 부분이 AI가 작성한다고 공언했고, Windows 품질이 떨어지고 있다는 인식도 늘고 있음. "코드의 100%를 AI가 작성한다"고 주장하는 회사들의 제품은 **기가바이트 단위 메모리 누수**, UI 결함, 크래시 등 최악의 품질을 보여주는 경우가 많음. 그리고 커뮤니티에선 "에이전트 코딩하다 코드베이스 막다른 골목 됐다"는 말이 점점 더 많이 들림. ## 에이전트가 만드는 버그는 왜 특히 위험한가 인간도 실수를 하지만, 인간은 **학습**을 함. 같은 실수를 반복하면 혼나거나 스스로 고침. 반면 에이전트("clanker")는 동일한 실수를 **무한 반복**하고, AGENTS.md에 주의사항을 적어줘도 관찰하지 못한 실수는 계속 일어남. 결정적 차이는 **병목(bottleneck)** 의 유무. 인간 개발자는 하루에 짤 수 있는 코드량에 한계가 있어서 버그도 천천히 쌓임. 고통이 임계점을 넘으면 리팩토링을 함. 그런데 에이전트 군단에는 병목도 없고 고통도 없음. 작은 버그들이 **감당할 수 없는 속도**로 복리처럼 쌓임. 인간이 루프에서 빠져 있으니 쌓이는 것도 모름. 알아챌 때는 이미 늦음. ## 복잡성의 상인들 에이전트들은 훈련 데이터에서 온갖 나쁜 아키텍처 결정을 학습했음. 거기다 에이전트끼리는 서로의 결정을 공유하지 않고, 코드베이스 전체를 보지도 못함. 결과적으로 **항상 국소적(local) 결정**만 내림. 이게 엄청난 코드 중복, 의미 없는 추상화 계층으로 이어짐. 인간으로만 이루어진 대형 엔터프라이즈 코드베이스가 이 수준의 복잡성에 도달하는 데는 수 년이 걸림. 에이전트를 쓰면 2인 팀도 **몇 주 만에** 똑같은 상태가 됨. ## 에이전트의 코드 검색(Agentic Search)은 recall이 낮다 ripgrep이든, 벡터 DB든, LSP 서버든 뭘 써도 코드베이스가 커질수록 **검색 recall이 떨어짐**. 즉 에이전트가 변경해야 할 코드나 재사용 가능한 기존 코드를 **다 못 찾음**. 이게 중복 코드와 비일관성의 근본 원인. 복잡도가 커질수록 이 문제는 더 심해지는 악순환. ## 그럼 어떻게 해야 하나: 속도를 줄여라 에이전트에 맡기기 좋은 작업은 이런 것들: - **범위가 명확**해서 전체 시스템을 몰라도 되는 작업 - **자체 평가(loop close)** 가 가능한 작업 (예: 시작 시간 단축, 정확도 측정) - 미션 크리티컬하지 않은 내부 도구나 애드혹 스크립트 - 아이디어 러버덕 용도 단, 어떤 경우든 **인간이 최종 품질 게이트**여야 함. **아키텍처, API 설계** 등 시스템의 근간을 정의하는 것들은 직접 손으로 써라. 코드를 단계적으로 짜는 과정에서 생기는 **마찰(friction)** 이 바로 이해와 학습의 기회임. 에이전트한테 하루에 생성하도록 허용하는 코드량을 실제로 리뷰 가능한 수준으로 제한해라. 그 결과물은: 유지보수 가능한 코드베이스, 실제로 동작하는 제품, 더 적지만 올바른 기능들. 그리고 가장 중요한 것 — **내가 여전히 내 코드베이스가 뭔지 알고 있다는 것**. > **"모든 것은 규율과 주체성을 필요로 한다. 모든 것은 인간을 필요로 한다."** ## 핵심 포인트 - 에이전트는 실수를 학습하지 않고, 병목이 없어 버그가 기하급수적으로 복리 축적됨 - 아키텍처·설계를 에이전트에 위임하면 인간 엔터프라이즈 코드베이스가 수년 걸릴 복잡도에 수 주 만에 도달 - 코드베이스가 클수록 에이전트의 agentic search recall이 떨어져 중복·비일관성 자동 양산 - 핵심 구조는 직접 작성하고, 에이전트 출력물의 일일 리뷰 가능 한도를 설정해야 함 - 속도를 줄이는 것이 곧 품질·유지보수성·개발자 역량 성장을 지키는 길 ## 인사이트 ㄹㅇ 공감 100%인 글. '에이전트가 다 해줄 거야'라는 환상 때문에 정작 본인이 자기 코드베이스의 외계인이 되는 상황이 이미 현실에서 벌어지고 있음. 속도가 능사가 아니라 **이해하면서 만드는 것**이 결국 더 빠른 길이라는 걸 업계 전체가 조금씩 깨닫고 있는 것 같아서, 이런 글이 계속 나오는 게 오히려 반가움.