본문으로 건너뛰기
J
0
r/jeffnews HN 약 6분

AI 코딩 에이전트 때문에 소프트웨어가 개판 됐는데 아무도 모름

general 0

요약

코딩 에이전트 등장 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%인 글. '에이전트가 다 해줄 거야'라는 환상 때문에 정작 본인이 자기 코드베이스의 외계인이 되는 상황이 이미 현실에서 벌어지고 있음. 속도가 능사가 아니라 **이해하면서 만드는 것**이 결국 더 빠른 길이라는 걸 업계 전체가 조금씩 깨닫고 있는 것 같아서, 이런 글이 계속 나오는 게 오히려 반가움.

댓글

댓글

댓글을 불러오는 중...