Rebuilding CI for AI-Scale Commit Volume — Gautam Korlam, SonarSource

한 줄 핵심

에이전트가 커밋을 대량 생성하는 시대에는 CI, 리뷰, 승인, 감사 기록을 사람 속도에 맞춘 방식에서 벗어나 더 빠른 검증과 정책 집행, 증거 보존을 함께 설계해야 한다.

시간별 요약

1. 0:00
   코딩 에이전트가 병목을 CI로 옮긴다 코딩 에이전트가 코드를 대량으로 생성하면서 병목은 작성 단계가 아니라 CI와 머지 인프라로 이동한다. 특히 규제가 강한 산업에서는 빠른 속도와 함께 준수 가능성과 감사 가능성을 동시에 확보해야 한다.
2. 1:13
   머지 전에 조합을 시험하는 SubmitQueue 대규모 모노레포에서는 변경을 하나씩 직렬로 머지하면 너무 느리고, 동시에 다 열어두면 trunk가 쉽게 깨진다. 이를 해결하기 위해 들어오는 커밋 조합을 병렬로 시험하고, 깨질 가능성이 있는 PR은 큐에서 돌려보내면서 trunk를 깨끗하게 유지한다.
3. 2:53
   사람 속도로 만든 큐의 한계 리뷰와 CI 큐는 원래 사람이 하루 몇 번 변경하던 속도에 맞춰져 있어, 에이전트가 수십 개의 PR을 한꺼번에 만드는 환경에서는 금세 포화된다. 그 결과 CI와 리뷰가 중앙 병목이 되어 전체 소프트웨어 팩토리의 처리량이 급격히 떨어진다.
4. 5:24
   소프트웨어 팩토리와 반복적 수리 루프 사양만 인간이 관리하고 나머지를 에이전트가 작성하는 소프트웨어 팩토리도 인간 속도로 설계된 공정 위에서는 병목이 생긴다. 빌드 재실행, 불안정한 테스트, 리뷰 적체, 승인 형식화, 로그 만료 문제까지 겹치기 때문에 공정 자체를 다시 설계해야 한다.
5. 7:08
   CI 실패와 피드백 비용 PR의 13%에서 CI 실패가 기록될 정도로, 실패는 개발자와 에이전트의 왕복 수정 비용을 크게 만든다. CI가 녹색이어야 리뷰가 시작되는 구조에서는 검증과 리뷰가 직렬화되어 전체 리드타임이 더 길어진다.
6. 8:11
   증분 빌드, 캐싱, 병렬 처리 가장 효과적인 대응은 CI를 최대한 빠르게 만들고, 비싼 검사는 가능한 한 뒤로 미루며, 캐싱과 샤딩으로 증분 빌드 비용을 낮추는 것이다. 또한 위험도에 따라 빠른 AI 리뷰와 더 깊은 사람 리뷰를 나누고, 정책 위반은 CI 이후가 아니라 더 앞단에서 잡아야 한다.
7. 10:16
   CI를 넘어 정책을 강제하기 컴파일이 통과했다고 해서 HIPPA나 내부 규정 같은 정책을 만족하는 것은 아니므로, 규칙 집행은 CI 밖에서도 이뤄져야 한다. 정책이 실제로 적용되었음을 기록해 두어야 감사와 준수 확인에 사용할 수 있다.
8. 13:28
   위험도 기반 머지와 승인 정책 문서 수정, dependency bump, 일부 내부 도구 변경처럼 낮은 위험의 변경은 자동 승인과 자동 머지가 가능하다. 반대로 결제나 민감 영역은 인간 승인자를 요구하고, 변경한 에이전트가 자기 변경을 승인하지 못하도록 제로 트러스트 기준을 적용해야 한다.
9. 15:21
   테스트된 커밋, 예외 처리, 감사 증거 CI 결과만 저장해서는 시간이 지나 로그가 만료되면 무엇이 검증되었는지 증명할 수 없으므로, PR에 원인, 해결 방식, 승인자, 오버라이드 사유 같은 증거를 남겨야 한다. 이렇게 해야 에이전트가 만든 변경도 누가 어떤 근거로 승인했고 어떤 테스트를 통과했는지 추적할 수 있다.

실무 인사이트

• 에이전트 도입의 핵심 병목은 코드 생성이 아니라 CI·리뷰·승인·감사 기록의 처리량이므로, 자동화는 작성 도구보다 검증 파이프라인부터 손봐야 효과가 크다.
• 낮은 위험 변경은 자동 승인으로 흘리고, 민감 변경만 사람에게 올리는 위험도 기반 정책이 대량 변경 시대의 가장 현실적인 운영 방식이다.
• CI 결과 그 자체보다 PR에 남는 결정 기록과 해결 이력이 장기적으로 더 중요하므로, 감사 가능성은 별도 기능이 아니라 개발 파이프라인의 기본 요구사항으로 다뤄야 한다.