AI 코딩 에이전트의 한계: 소프트웨어 공장이 실패하는 이유

핵심 메시지

• 코드 리뷰를 없애고 에이전트에게 전부 맡기는 "조명 끈 소프트웨어 공장"은 유지보수가 필요한 복잡한 코드베이스에서 결국 무너진다.
• 이는 하네스(harness)를 더 정교하게 만들거나 토큰을 더 쓴다고 풀리는 규모의 문제가 아니라, 코딩 모델이 학습되는 방식에서 비롯된 근본적 한계다.
• 코딩 모델은 "테스트를 통과했는가"로 보상받도록 강화학습되기 때문에, 나쁜 설계나 유지보수성 악화에는 벌점을 줄 방법이 없어 코드 품질을 스스로 지켜내지 못한다.
• 유지보수성과 코드 품질을 검증하는 일은 "코드가 돌아가고 테스트가 통과한다"를 확인하는 것보다 훨씬 어렵다. 나쁜 설계의 대가는 몇 달, 몇 년 뒤에야 드러나기 때문이다.
• 해법은 앞단의 제품 리뷰·아키텍처·프로그램 설계에 시간을 들여 정렬을 마친 뒤 코드를 계속 읽는 것이며, 사전 정렬 30분이 리뷰의 몇 시간을 아껴 오히려 더 빠르게 만든다.

쉽게 이해하기

많은 기업이 "코드의 75%를 에이전트가 짠다"고 자랑하며 AI 코딩을 생산에 밀어 넣고 있다. 발표자는 그 극단인 "조명 끈 소프트웨어 공장"—아무도 코드를 읽지 않고 에이전트가 다 만드는 방식—이 왜 실패하는지 자신의 경험을 들어 짚었다.

그는 AI 코딩 도구가 널리 퍼진 2025년 초 이후 나타난 균열을 언급했다. 한 조사에 따르면 풀 리퀘스트의 리뷰 품질이 크게 떨어졌고, 리뷰 없이 병합되는 PR이 늘었으며, 장애와 버그도 증가했다. 흔히 "네가 잘못 쓰는 것"이라고들 하지만, 발표자는 이것이 사용법의 문제가 아니라고 본다.

핵심 주장은 이것이 규모나 하네스 엔지니어링으로 풀 문제가 아니라 모델 학습의 문제라는 것이다. 코딩 모델은 문제를 여러 번 풀게 한 뒤 "테스트를 통과했고 다른 것을 깨뜨리지 않았는가"라는 이진 보상으로 강화학습된다. 이 구조에서는 불필요한 예외 처리나 억지 형변환처럼 테스트만 통과시키는 편법에 벌점을 줄 수 없다.

더 근본적으로, 코드의 유지보수성과 품질을 검증하는 일은 실행과 테스트 통과를 확인하는 것보다 몇 자릿수는 더 어렵다. 나쁜 아키텍처의 비용은 몇 달, 몇 년 뒤에 나타나므로 그 보상 신호를 학습 시점으로 되돌려 전달하기가 어렵다. 그래서 모델은 인간의 상당한 조종 없이는 시간이 지날수록 코드베이스 품질을 유지·개선하지 못한다. 클로드 코드가 성공한 비결도 모델 연구소가 배포할 하네스에 맞춰 모델을 직접 학습시킨 데 있다고 그는 짚었다.

대안으로 그는 "조명을 다시 켜자"고 제안한다. 작은 작업은 그대로 에이전트에 맡기되, 큰 작업은 제품 리뷰·시스템 아키텍처·프로그램 설계(타입·메서드 시그니처·호출 구조)를 앞단에서 정리하고, 구현 순서를 나눈 "수직 슬라이스"로 진행한다. 앞단 정렬에 30분을 쓰면 리뷰의 몇 시간을 아낄 수 있어 모든 줄을 읽고도 더 빨리 움직일 수 있다는 것이다.

주요 인사이트

• "테스트 통과"라는 보상만으로 학습된 모델은 코드가 작동하게는 만들어도 좋은 설계를 지향하지 않는다. 벤치마크가 측정하지 못하는 유지보수성이 바로 AI 코딩의 사각지대다.
• 하네스와 리뷰 에이전트, 더 많은 토큰은 코드 품질의 바닥을 끌어올릴 수는 있어도, 모델이 애초에 좋은 코드를 알아보지 못하는 한 한계가 있다. 당분간은 사람이 코드를 읽어야 한다는 결론이다.
• AI로 더 빨리 가는 길은 리뷰를 없애는 것이 아니라, 앞단 설계·정렬에 AI를 활용해 리뷰를 짧고 즐겁게 만드는 데 있다. PR이 넘쳐 힘들다면 PR이 많은 게 아니라 나쁜 PR이 많은 것이다.

자주 묻는 질문

관련 AI 소식