읽히지 않는 5천 줄
Redis 창시자 살바토레 산필리포(antirez)는 AI가 하루에 만든 5천 줄을 사람이 모두 읽는 방식은 지속하기 어렵다고 말한다. 설계 의도를 통제한다면, 줄 단위 리뷰보다 설계 문서와 QA에 시간을 쓰는 편이 낫다는 주장이다. 클린 코드 저자 Robert C. Martin 역시 커버리지, 의존성, 복잡도, 변이 테스트 같은 지표로 에이전트의 코드를 관리한다고 밝혔다. 반면 UML 공동 창시자 Grady Booch는 지표만으로 보안 취약점이나 죽은 코드, 장기 유지보수 문제까지 잡아내지 못한다고 지적한다.
현장에서는 이미 코드 작성보다 검증이 더 큰 병목이 되고 있다. 810만 건 이상의 PR을 분석한 결과, AI 보조 PR은 일반 PR보다 리뷰를 받기까지 4.6배 오래 기다렸다. 에이전트 PR의 수락률도 32.7%로 일반 PR의 84.4%에 크게 못 미쳤다.
GitLab 조사에서도 85%가 병목이 작성에서 검증으로 옮겨갔다고 답했다. 개인 생산성이 늘었다는 응답은 79%였지만 배포 속도는 그만큼 빨라지지 않았다. 숙련 개발자가 AI 사용 후 실제로 19% 느려졌는데도 스스로는 20% 빨라졌다고 여긴 METR의 실험에서도 같은 결과가 나타났다.
같은 명세는 같은 실패를 낳는다
여러 에이전트가 검토한다고 해서 독립적인 검증이 되는 것은 아니다. 1986년 John C. Knight와 Nancy G. Leveson은 같은 명세로 만든 27개 프로그램을 시험했다. 프로그램들은 독립적으로 개발됐지만 명세가 어렵거나 모호한 지점에서 함께 실패했다.
2026년에는 서로 다른 모델과 언어를 쓴 코딩 에이전트 48개로 이 실험을 재현했다. 세 구현의 다수결로 평균 실패 건수는 387.44건에서 130.99건으로 줄었지만 공통 실패는 여전히 모호한 명세에 집중됐다.
따라서 검증자는 모델만 바꿀 게 아니라 판단 기준을 달리해야 한다. 같은 프롬프트로 코드와 테스트를 함께 만들면 둘 다 같은 요구사항을 놓친다. 사람이 정한 속성 테스트, 변이 테스트, 실제 트래픽 같은 외부 기준이 필요하다.
AI에게 어디까지 맡길 것인가
불완전계약 이론은 계약에 없는 상황을 결정할 권리를 ‘잔여통제권’이라 부른다. 소프트웨어에서 스펙, 타입, 테스트, SLO(서비스 수준 목표)가 계약이라면, 여기에 적히지 않은 조건은 결국 사람의 판단으로 남는다.
그동안 개발자는 소스 코드를 읽으며 이 빈칸을 찾았다. 하지만 코드 생성 비용이 낮아질수록 통제의 중심은 소스 자체에서 불변조건, 관측 가능성, 시스템 경계로 옮겨간다. 무엇을 얼마나 읽을지도 전체 코드량이 아니라 명세 밖에 남은 판단의 크기로 정해야 한다. 배포 후 바꾸기 어려운 저장 형식이나 복제 프로토콜을 Redis 코어에서 따로 다루는 것도 같은 이유다.
위임 범위 역시 PR 크기만으로 정할 수 없다. 명세와 불변조건이 분명한 영역은 에이전트에 크게 맡기고 판단의 빈칸이 많은 영역은 작게 나눠 사람이 개입해야 한다. 모든 영역에 완벽한 명세를 만들 수는 없으므로 이 방식은 위험이 큰 곳부터 선택적으로 적용하는 편이 현실적이다.
통제는 되돌릴 수 없는 곳에 집중하라
사람이 반드시 통제해야 할 것은 ‘중요해 보이는 코드’가 아니라 복구하기 어려운 결정이다. 긴 코드라도 즉시 되돌리기 쉽다면 줄 단위 리뷰의 가치는 낮다. 반대로 몇 줄뿐이어도 데이터 삭제나 권한 변경을 실행한다면 사람이 직접 확인해야 한다. 2025년 Replit 에이전트의 프로덕션 데이터베이스 삭제 사고에서도 핵심 위험은 코드 길이가 아니라 실행 권한이었다.
조직은 되돌리기 어려운 구간을 미리 정한다.
- 데이터 마이그레이션
- 저장, 통신 형식
- 공개 API
- 권한과 과금
- 암호키
- 삭제와 외부 전송
이곳에는 사람이 만든 속성 기반 테스트, 실제 트래픽을 활용한 검증, 단계적 배포와 롤백 수단을 요구해야 한다. 위험이 낮은 나머지 변경은 자동 검증에 맡긴다. 모든 코드에 같은 리뷰 강도를 적용하면 정작 위험한 변경에 쓸 시간이 부족해진다.
그래도 코드 읽기 능력은 남겨야 한다. 문서만으로는 어떤 변경이 위험한지 가려내는 감각까지 전수하기 어렵다. 자동화가 늘어도 항공 업계가 수동 비행 훈련을 유지하듯 개발자도 코드를 읽고 시스템을 추적하는 훈련이 필요하다.