에이전트가 24시간 코드를 생산하는 시대가 실제로 왔다. dev.to에 공개된 ClawWorks 사례는 6개 AI 에이전트(SDM 1 + SDE 5)가 cron 스케줄로 돌아가며 콘텐츠 발행부터 인프라 관리, 암호화폐 트레이딩 봇 운영까지 처리하는 아키텍처를 실수치와 함께 공개했다. 첫 주에 44세션에서 45개 이상의 태스크를 완료했다는 숫자는 인상적이다. 하지만 이 사례를 '에이전트 팀 구축 성공담'으로만 읽으면 절반을 놓치는 것이다.
같은 시점에 나온 두 번째 보고서가 그 절반을 채운다. 한 개발팀이 AI 에이전트로 Enzyme 테스트 53개 스위트를 React Testing Library로 마이그레이션했다. 테스트는 전부 통과했고, 코드도 깔끔해 보였다. 그런데 팀 리뷰를 거치고 나서야 드러난 사실—존재할 수 없는 ARIA role을 검사하는 단언, disabled와 aria-disabled를 혼동한 접근성 테스트, 어떤 회귀도 잡아내지 못할 껍데기 케이스들. 에이전트가 생성한 코드는 '의도적으로 작성된 것처럼 보인다'는 게 핵심 문제였다. 볼륨이 클수록, 코드가 그럴듯해 보일수록, 문제는 더 깊이 숨는다.
그리고 세 번째 데이터 포인트. Linux 커널 커뮤니티가 Linux 7.0에서 AI 코딩 어시스턴트 정책을 공식화했다. 요약하면 이렇다: AI 보조 코드는 허용, 완전 기계 생성 제출은 불허, Assisted-by 태그로 투명성 확보, Developer Certificate of Origin은 그대로 유지. 세계에서 가장 엄격한 코드 리뷰 문화를 가진 커뮤니티가 내린 결론은—AI가 쓴 코드라도 책임은 사람이 진다는 것이다.
세 사례를 나란히 놓으면 하나의 구조적 긴장이 선명해진다. 자율화 속도와 품질 거버넌스는 같은 축 위에서 트레이드오프가 아니다. 이것들은 아예 다른 설계 공간에 속한다. ClawWorks가 3-티어 PR 리뷰 시스템(Tier 1 자체 병합 → Tier 2 SDE-3 리뷰 → Tier 3 AWS WAF 체크리스트 필수)을 만든 것도, 테스트 마이그레이션 팀이 마이그레이션 에이전트와 리뷰 에이전트를 분리 실행하는 투-프롬프트 아키텍처로 전환한 것도, Linux 커널이 Assisted-by 태그와 DCO를 동시에 요구한 것도—모두 같은 인식에서 출발한다. 에이전트가 산출물을 만드는 단계와, 그 산출물을 팀이 신뢰할 수 있게 검증하는 단계는 분리해서 설계해야 한다.
테스트 마이그레이션 사례에서 나온 비용 구조는 이 문제의 현실적 무게를 보여준다. 단일 패스 배치 처리로 약 13달러, 스위트 단위 처리로 32달러, 스위트 단위에 리뷰 에이전트까지 붙이면 62달러—거의 5배 차이다. 그런데 62달러짜리 접근이 인간 리뷰어가 사전에 잡아낸 모든 이슈를 해결했다. 속도를 위해 검증을 생략하면 비용이 줄어드는 게 아니라, 사람이 나중에 처리해야 할 기술 부채가 그만큼 쌓인다는 뜻이다. '에이전트 활용 비용'을 API 청구서로만 계산하는 팀은 전체 비용의 절반도 보지 못하고 있다.
더 근본적인 문제도 있다. 에이전트가 긴 컨텍스트에서 검증 지시를 '체크박스'처럼 처리하는 현상—테스트 마이그레이션 팀이 '더 나은 프롬프트'가 아니라 '다른 아키텍처'로 해결책을 바꾼 이유가 여기 있다. 검증 단계가 생략될 수 있는 구조라면, 아무리 지시를 정교하게 써도 에이전트는 결국 그 단계를 건너뛴다. 품질 게이트는 프롬프트로 강제할 수 없다. 워크플로우 구조 자체에 박아 넣어야 한다. ClawWorks의 WAF 체크리스트 필수화, Linux의 DCO 의무화가 모두 같은 원리다.
실무적 시사점은 세 가지로 압축된다. 첫째, 산출물 생성과 품질 검증을 단일 에이전트 패스에 묶지 말 것. 마이그레이션-리뷰 분리처럼, 역할이 다르면 에이전트도 다르게 설계해야 한다. 둘째, 품질 게이트는 리뷰 선택지가 아니라 머지 블로커로 설계할 것. ClawWorks의 WAF 체크리스트처럼, '침묵'은 통과가 아니라 반려로 처리되어야 한다. 셋째, 에이전트 산출물에 대한 책임 귀속을 명시적으로 설계할 것. Linux의 Assisted-by 태그와 DCO 병행은 오픈소스만의 이야기가 아니다. 팀 내부에서도 누가 어떤 에이전트 출력물을 검토하고 책임졌는지를 추적 가능하게 만들지 않으면, 사고가 났을 때 거버넌스 공백이 그대로 드러난다.
자율 에이전트 팀을 운영한다는 것은 결국 두 가지 시스템을 동시에 설계하는 일이다. 에이전트가 빠르게 산출물을 만드는 시스템, 그리고 그 산출물이 팀의 신뢰 기준을 통과했음을 보장하는 시스템. 전자만 있으면 속도는 나오지만 품질은 확신할 수 없고, 후자 없이 전자만 고도화하면 기술 부채가 AI 속도로 쌓인다. 에이전트 팀 리빌딩을 고민하는 팀이라면 지금 당장 물어야 할 질문은 '에이전트를 몇 개 돌릴 것인가'가 아니라 '생성된 코드를 어떤 구조로 검증할 것인가'다.