AI가 코드를 빨리 써도 소프트웨어 팩토리가 무너지는 이유

AI가 코드를 빨리 써도 소프트웨어 팩토리가 무너지는 이유

IT & AI 뉴스 썸네일

AI 코딩 도구는 구현 시간을 크게 줄였어요. 하지만 사람이 코드를 읽지 않는 자동 개발 방식은 복잡한 프로덕션 코드에서 유지보수 비용을 뒤로 미룰 수 있어요. HumanLayer의 창업자 덱스는 자동 검사와 반복 실행을 늘리는 것만으로 장기 품질까지 지키기 어렵다고 주장해요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
보상의 한계	코딩 모델은 테스트 통과처럼 바로 확인할 수 있는 결과에 맞춰 학습해요	수개월 뒤 드러나는 결합도와 변경 비용은 짧은 평가에서 잡기 어려워요
벤치마크의 빈틈	SWE-bench 계열은 문제 해결과 기존 테스트 보존을 확인해요	무리한 예외 처리나 넓은 타입 변환도 테스트만 통과하면 높은 점수를 받을 수 있어요
리뷰 병목	AI가 구현을 빨리 끝내도 사람의 검토 시간은 같은 비율로 줄지 않아요	생성량이 리뷰 역량을 넘으면 낮은 품질의 변경이 코드베이스에 쌓일 수 있어요
현실적인 속도	저자는 사람의 설계 판단을 남긴 채 2~3배 빠른 개발을 목표로 제안해요	10~100배 자동화보다 품질과 속도의 균형을 구체적으로 논의할 수 있어요

1. 테스트 통과만으로는 오래 고치기 쉬운 코드를 만들 수 없어요

AI 코딩 자동화는 요구사항을 작업으로 나누고, 모델이 코드를 만든 뒤 테스트와 정적 검사를 반복하는 방식으로 발전했어요. 구현 단계가 수 시간에서 수분으로 줄어들면서 사람이 직접 코드를 읽는 과정까지 없애려는 시도도 나왔어요. 저자는 이런 무인 방식이 작은 프로젝트에서는 빠르게 결과를 낼 수 있지만, 여러 해 운영할 시스템에는 다른 기준이 필요하다고 봐요. 2

코딩 모델의 강화 학습은 짧은 실행 안에서 채점할 수 있는 보상을 주로 사용해요. 요청한 버그를 고쳤는지, 새 테스트가 통과하는지, 기존 동작을 깨뜨리지 않았는지가 대표적이에요. 반면 한 기능을 바꿀 때 여러 파일을 함께 고쳐야 하는 구조, 지나치게 넓은 예외 처리, 무리한 타입 변환처럼 유지보수를 어렵게 만드는 선택은 당장 실패로 나타나지 않을 수 있어요. 테스트가 녹색이어도 다음 변경이 더 비싸지는 이유예요. 2

SWE-bench 계열에도 같은 한계가 있어요. 실제 오픈소스 저장소의 이슈를 해결하고 회귀 테스트를 지키는 능력은 잘 측정하지만, 수정 뒤 코드 구조가 더 단순해졌는지까지 장기간 관찰하지는 않아요. 한 번의 과제를 통과하는 능력과 6개월 동안 계속 고치기 쉬운 시스템을 만드는 능력은 평가 주기가 달라요. 저자는 현재 벤치마크가 후자를 충분히 다루지 못한다고 지적해요. 2

생성 속도가 빨라지면 코드 리뷰가 새 병목이 돼요. 에이전트가 여러 변경을 동시에 만들 수 있어도 숙련 개발자가 읽고 설계 의도를 확인하는 시간은 그대로 남아요. 이 단계를 건너뛰면 자동 검사가 놓친 결합도와 중복이 빠르게 누적될 수 있어요. 저자는 직접 무인 개발 방식을 몇 달간 운영한 뒤, 장애 원인을 찾으려면 사람이 오랫동안 읽지 않았던 코드를 다시 파악해야 했다고 설명해요. 결국 일부 기능은 처음부터 다시 구현하는 편이 쉬웠다고 해요. 2

이 주장은 AI 코딩 도구가 쓸모없다는 뜻과는 거리가 있어요. 구현 전에 제품 요구사항, 시스템 구조, 프로그램 설계와 작은 수직 기능 단위를 사람이 검토하면 재작업 범위를 줄일 수 있다는 제안이에요. 모델에는 경계가 분명한 구현을 맡기고, 개발자는 코드가 어떤 구조를 남기는지 계속 읽어야 해요. 저자는 이런 조건에서 인간 수준에 가까운 품질을 유지하며 2~3배 빠르게 개발하는 목표가 더 현실적이라고 봐요. 2

왜 중요한가요

개발팀은 AI가 작성한 코드 비율보다 변경 비용이 시간이 지나며 어떻게 달라지는지 확인할 필요가 있어요. 테스트 통과율과 작업 완료 건수만 보면 자동화가 잘 작동하는 것처럼 보일 수 있어요. 같은 기능을 고칠 때 수정 파일 수가 늘고, 리뷰 시간이 길어지고, 되돌림과 장애가 잦아진다면 생성 속도의 이익이 줄어들어요. 2

도입 지표도 장기 품질을 함께 봐야 해요. 변경 리드타임 외에 리뷰 없이 병합된 변경 비율, 변경 실패율, 장애 복구 시간, 반복 수정이 필요한 파일 수를 추적하면 코드베이스가 감당할 수 있는 생성량을 찾기 쉬워요. 자동 검사는 명백한 오류를 줄이는 데 유용하지만, 제품 요구와 구조적 선택을 대신 판단하지는 못해요.

728x90

모든 변경을 같은 강도로 검토할 필요는 없어요. 문서나 단순한 반복 수정은 자동화 범위를 넓히고, 데이터 모델·권한·결제·공용 인터페이스처럼 파급 범위가 큰 변경은 구현 전에 설계를 먼저 맞추는 방식이 실용적이에요. AI 코딩의 성과는 생성한 코드 양보다 다음 변경을 얼마나 안전하게 이어갈 수 있는지로 확인하는 편이 좋아요.

참고 자료

1. 소프트웨어 팩토리가 실패하는 이유: 하네스 엔지니어링만으로는 부족함 — GeekNews
2. Why Software Factories Fail — HumanLayer / GitHub