코딩 에이전트를 붙인 팀에서 반복해서 보이는 장면이 있다. PR 수는 몇 배로 늘고 CI는 대부분 초록으로 통과하는데, 배포 주기는 그대로다. 늘어난 것은 만들어진 변경의 양이고, 그대로인 것은 그 변경을 괜찮다고 판정하는 용량이다.
The New Stack의 Arjun Iyer는 7월 11일 글에서 이 지점을 병합 게이트의 설계 문제로 정리했다. 병합 전에 시스템 전체를 검증하는 것이 옳아서 지금 구조가 된 게 아니라, 병합 전 환경을 매번 띄우는 일이 비현실적이었기 때문에 게이트가 인프라가 감당할 수 있는 크기로 줄어들었다는 것이다. 빌드, 유닛 테스트, 계약 검사까지가 게이트에 남았고 나머지 검증은 병합 뒤로 밀렸다.
그 타협은 사람이 PR을 쓰던 동안에는 버텼다. 지금은 버티지 못한다.
에이전트는 초록불이 켜질 때까지 고친다
게이트에 남은 세 층은 하필 에이전트가 가장 잘 맞추는 층이다. 빌드가 깨지면 고치고, 테스트가 빨개지면 다시 돌리고, 타입과 계약이 어긋나면 맞춘다. 초록이 될 때까지 반복하는 일이 에이전트에게는 거의 비용이 들지 않는다. 통과했다는 신호가 걸러내는 힘을 잃는다.
에이전트가 스스로 발견할 수 없는 것은 자기 피드백 루프 밖에 있다. 로컬에서 완벽한 변경이 세 서비스 건너의 소비자를 깨뜨린다는 사실은, 그 소비자가 루프 안에 없으면 알 수 없다. 같은 글이 인용한 오픈소스 PR 분석에서 AI가 작성한 변경은 사람이 쓴 변경보다 약 1.7배 많은 문제를 안고 있었고, 대부분 로직과 정확성 오류였다. 백 명 규모 팀이 예전에 수백 명이 만들던 PR 양을 내놓는 상황에서, 이 비율은 그대로 병합 뒤로 넘어간다.
벤더들은 게이트를 자동화하면서 서명만은 사람에게 남겼다
7월 한 달 동안 나온 대응은 방향이 같다.
| 제품 | 자동화한 것 | 사람에게 남긴 것 |
|---|---|---|
| AWS DevOps Agent (7/7, 프리뷰) | 저장소 간 지식 그래프로 하류 실패 예측, 변경별 테스트 계획 생성·프로덕션 유사 환경 실행 | 프로덕션 배포 승인 |
| GitLab 19.2 (7/16) | 의존성 취약점 자동 수정, 보안 리뷰 플로우 | 모든 수정의 메인테이너 승인 |
| GitHub Copilot code review (7/29, GA) | .github/skills의 SKILL.md와 읽기 전용 MCP 컨텍스트를 리뷰에 주입 | 리뷰 결론과 병합 |
AWS는 조직 표준을 자연어로 적어두면 변경을 그 기준과 대조한다. GitLab의 Manav Khurana는 코딩 에이전트가 훨씬 많은 코드를 만들 수 있게 하면서 병목을 리뷰와 보안 쪽으로 밀어냈다고 말했다. 세 제품 모두 에이전트가 스스로 병합하는 경로는 열지 않았다.
그래서 처리량 상한은 서명하는 사람 수에서 정해진다
판단 재료를 늘리는 것과 판단 자체를 늘리는 것은 다르다. 게이트 자동화는 앞을 늘렸다. 하류 영향 분석과 테스트 결과와 에이전트 리뷰 코멘트가 PR마다 따라붙는다. 그런데 그것을 읽고 책임지고 승인하는 사람 수는 그대로다. 한 건당 읽을 것이 늘었으니 개인의 처리 시간은 오히려 길어질 수 있다.
측정할 지표가 바뀐다. 생성량이나 수용률이 아니라, 병합 대기 큐의 길이와 승인자 한 명당 대기 건수다. 이 숫자가 늘고 있다면 도구를 더 붙여도 풀리지 않는다.
에이전트 도입 교육은 대부분 생성 쪽에 몰려 있지만, 실제로 막히는 자리는 판정 쪽이다. 조녁컴퍼니가 AX 전환 현장에서 먼저 손대는 것도 승인 기준을 글로 적고 그 판단을 여러 사람이 나눠 가질 수 있게 만드는 일이다.