AI 코딩 에이전트에 코드 다 맡겼더니 장애가 늘었다 (github.com)

한줄 요약

AI 코딩 에이전트 자동화를 과신하면 코드 품질과 운영 안정성이 동시에 무너진다.

AI가 다 짜주는 '소프트웨어 팩토리', 실제로는 어떻게 됐나?

AI 코딩 에이전트 도입 이후 개발 속도는 빨라졌지만, 코드 품질과 운영 안정성은 반대 방향으로 움직이고 있다. Faros AI가 내놓은 리포트에 따르면 AI 코딩 툴이 업계에 본격 확산된 이후, PR 리뷰 코멘트 수는 25% 증가했고 코멘트 길이는 22.7% 길어졌으며, 리뷰 없이 머지되는 PR 비율은 31.3%나 늘었다. 더 심각한 건 운영 지표다. PR당 인시던트는 242.7% 급증했고, 월별 인시던트는 57.9%, 개발자 1인당 버그 수는 54% 증가했다.

이건 단순한 상관관계 신호에 가깝고, 인과관계로 단정하기는 어렵다. 하지만 현장에서 체감되는 방향성과 맞아떨어진다는 점에서 그냥 흘려들을 수 없다.

StrongDM은 사람이 코드를 읽지도 쓰지도 않는 '다크 팩토리' 실험을 공개적으로 선언했고, OpenAI의 Ryan Lopopolo는 Symphony라는 내부 소프트웨어 팩토리 사례를 발표했다. 이 흐름이 만들어낸 서사는 단순하다. '당신이 병목이다. 모델은 이미 충분히 좋다. 코드는 공짜다. 그냥 더 많이 배포하면 된다.'

왜 '하네스 엔지니어링'만으로는 부족한가?

문제가 터지면 돌아오는 반응은 늘 비슷하다. "그건 사용법 문제다(skill issue)." 더 많은 토큰을 쓰고, 더 좋은 프롬프트를 작성하고, 린터를 더 촘촘하게 걸면 해결된다는 논리다. PR 리뷰 봇에 '적대적 리뷰(adversarial review)' 같은 마법 단어를 뿌려두면 코드가 알아서 품질을 잡아준다는 믿음이다.

그런데 이건 도구의 문제가 아니다. AI 에이전트는 컨텍스트를 소비하고 지시를 실행하는 데 탁월하지만, 그 지시가 올바른 방향을 향하고 있는지 판단하는 건 여전히 사람의 영역이다. 루프를 더 많이 돌리고, 자동화 레이어를 더 쌓는 것, 즉 하네스 엔지니어링은 실행 속도를 높이는 방법이지 판단 품질을 보장하는 방법이 아니다.

실제로 AI 코딩 에이전트 도입 이후 코딩 실수로 인한 서비스 장애를 겪어선 안 될 기업들이 장애를 겪고 있다는 사례도 이미 보고되고 있다. Matt Pocock은 "코드베이스가 예전보다 훨씬 빠르게 무너지고 있다"고 직접적으로 표현했다.

외주 개발이나 내부 개발 모두, 지금 이 국면에서 점검할 것

AI 도구가 개발 현장에 깊숙이 들어온 지금, 외주 개발이든 내부 개발이든 품질 관리 기준을 다시 세워야 하는 시점이다. 빠른 코드 생성이 가능해졌다는 건, 반대로 품질 검증 없이 엉성한 코드가 빠르게 쌓일 수 있다는 뜻이기도 하다.

도입 전 체크포인트

AI 코딩 에이전트나 자동화 파이프라인을 확대하기 전에 다음을 먼저 따져봐야 한다.

리뷰 프로세스가 살아있는가? 자동화 속도가 빨라질수록 사람의 리뷰 비중은 줄어들기 쉽다. PR 머지 전 리뷰 필수 여부를 제도적으로 고정해두지 않으면 자연스럽게 건너뛰게 된다.

인시던트 기준선이 있는가? AI 도구 도입 전과 후의 인시던트, 버그, 배포 실패율을 비교할 수 있는 수치가 있어야 한다. 감각이 아니라 데이터로 판단해야 한다.

자동화가 '판단'을 대체하고 있지는 않은가? 에이전트가 코드를 생성하고, 봇이 리뷰하고, CI가 통과시키는 루프만 남으면 책임 있는 판단자가 사라진다. 어느 단계에서 사람이 개입하는지 명확히 설계되어 있어야 한다.

속도 지표와 품질 지표를 함께 보고 있는가? 배포 횟수나 PR 처리 속도만 KPI로 삼으면, 빠르게 망가지는 시스템을 빠르게 만들고 있을 수 있다.