복잡한 엔지니어링 작업을 AI 에이전트에게 맡기려는 팀이 가장 먼저 부딪히는 문제는 속도가 아니다. 코드가 나오는 속도는 이미 빠르다. 문제는 그 코드를 프로덕션에 올릴 수 있는지 판단하는 데 드는 시간과 노력이 전혀 줄어들지 않는다는 점이다.
에이전트가 하루 만에 수천 줄의 코드를 생성하더라도, 그것을 검토하고 테스트하고 머지 여부를 결정하는 일은 여전히 사람에게 쌓인다. 결과적으로 많은 팀이 속도를 얻는 대신 검토 부담을 키우는 방식으로 AI를 도입하고 있다.
이 글은 그 구조를 바꾸는 방법을 다룬다. 구체적으로, AI 에이전트를 단일 도구나 병렬 작업자로 보는 대신 역할이 나뉜 팀으로 운영할 때 어떤 요구사항을 설계해야 하는지, 그리고 어떤 조건에서 이 모델이 의미 있는지를 설명한다.
속도 최적화 모델이 실패하는 지점
AI 에이전트 자동화의 초기 실험 대부분은 처리량을 극대화하는 방향으로 설계됐다. 여러 에이전트를 동시에 실행하고, 충돌을 처리하는 병합 레이어를 두는 구조다. 코드가 얼마나 빨리 만들어지느냐가 핵심 지표였다.
이 모델은 프로토타입이나 탐색적 작업에는 어울릴 수 있다. 하지만 데이터 마이그레이션 도구, 결제 처리, 멀티테넌트 SaaS의 핵심 로직처럼 버그 하나가 고객 데이터에 직접 영향을 주는 영역에서는 처리량보다 결함률이 중요하다.
속도 최적화 모델의 근본적인 약점은 검토가 사후에 몰린다는 것이다. 에이전트가 만들어낸 코드를 다시 사람이 한꺼번에 검토해야 하고, 범위를 벗어난 구현이나 테스트 누락이 머지 직전에 발견된다. 이때 드는 수정 비용은 처음부터 구조를 잘 잡았을 때보다 훨씬 크다.
팀 단위 운영 모델의 설계 원리
Cockroach Labs가 MOLT 마이그레이션 툴셋 개발에 적용한 접근은 다른 출발점에서 시작한다. 이들이 선택한 기준은 "PR을 얼마나 빨리 생성하느냐"가 아니라 "머지된 PR 중 부끄럽지 않은 비율이 얼마나 되느냐"였다.
이 기준을 적용하면 에이전트 설계의 우선순위가 바뀐다. 빠른 생성보다 의무적 검토 단계가 먼저 와야 하고, 단일 에이전트가 처음부터 끝까지 처리하는 구조보다 역할이 분리된 팀 구조가 더 적합하다.
이들이 설계한 구조를 참고하면, 팀 단위 운영 모델의 핵심 설계 원리는 세 가지다.
첫째, 역할 분리. 계획을 세우는 에이전트, 구현하는 에이전트, 검토하는 에이전트, 머지 전 프로세스를 확인하는 에이전트가 각각 다르다. 동일한 에이전트 인스턴스가 자신의 코드를 스스로 검토하지 않는다.
둘째, 의무적 되돌아가기 경로. 검토 단계에서 문제가 발견되면 작업이 이전 단계로 돌아간다. 이 경로가 설계에 명시되지 않으면, 문제가 있어도 다음 단계로 넘어가는 압력이 생긴다.
셋째, 사람이 개입하는 기준의 명확화. 에이전트 팀이 스스로 해결하지 못하는 케이스가 무엇인지 사전에 정의하고, 그 기준에 도달했을 때만 사람이 들어온다. 이렇게 하면 사람의 판단이 필요한 케이스와 그렇지 않은 케이스가 구분된다.
요구사항 단계에서 결정해야 할 것들
이 모델을 도입하려는 팀이 요구사항 단계에서 놓치기 쉬운 결정이 몇 가지 있다.
작업 분해 기준을 누가 정하는가. Cockroach Labs의 경우, 단일 이슈가 너무 크다고 판단되면 계획 에이전트가 하위 이슈로 분해하고 의존성 그래프를 만든다. Db2 지원 작업 하나가 32개의 하위 이슈로 나뉘었다. 분해 기준과 재분해 조건을 사전에 정하지 않으면 에이전트마다 기준이 달라지고, 작업 간 의존성 관리가 무너진다.
상태를 어디에 저장하는가. 에이전트 팀은 각 작업이 지금 어느 단계에 있는지, 무엇이 승인되고 무엇이 반려됐는지를 추적해야 한다. 이 상태가 에이전트 컨텍스트 안에만 있으면 중간에 실패했을 때 복구가 어렵다. 외부 시스템에 명시적으로 기록하는 구조가 필요하다. Cockroach Labs는 GitHub 이슈 레이블과 스크래치 파일을 상태 저장소로 사용했다.
검토 에이전트의 프롬프트를 구현 에이전트와 다르게 설계했는가. 같은 베이스 모델을 쓰더라도 검토 역할의 에이전트는 "무엇이 잘못될 수 있는가"를 찾도록 설계해야 한다. 구현 에이전트의 관점과 검토 에이전트의 관점이 같으면 같은 오류를 반복해서 놓친다.
정기 점검 루틴이 있는가. 작업이 어느 단계에서 막혔을 때 이를 감지하고 다음 행동을 결정하는 루틴이 없으면, 에이전트가 조용히 멈춰 있어도 알 수 없다. Cockroach Labs 구조에는 30분마다 진행 상황을 확인하는 역할이 별도로 있다.
이 모델이 적합한 작업 유형과 그렇지 않은 경우
팀 단위 운영 모델은 어디에나 적합하지는 않다. 어떤 작업에 이 구조가 필요한지 판단하는 기준은 비교적 명확하다.
이 모델이 맞는 경우는 다음과 같다. 작업 범위가 크고 여러 하위 작업으로 분해 가능할 때, 버그 하나가 고객 데이터나 프로덕션 환경에 직접 영향을 줄 수 있을 때, 동일한 유형의 작업이 반복적으로 발생하는 패턴이 있을 때다. 데이터베이스 마이그레이션 도구 확장, 멀티테넌트 SaaS의 핵심 데이터 처리 로직 수정, 반복적인 레거시 시스템 통합 작업 같은 케이스가 여기 해당한다.
반면, 단순한 기능 추가나 짧은 탐색적 작업에는 이 구조가 과하다. 검토 단계와 상태 관리 인프라를 만드는 비용이 작업 자체보다 클 수 있다. 또한 작업 유형이 너무 다양하고 불규칙해서 역할별 프롬프트를 안정적으로 설계하기 어려운 경우에도 이 모델의 효과는 떨어진다.
품질 보증을 위한 검증 단계 설계
팀 단위 운영 모델에서 품질 보증은 사후 테스트가 아니라 프로세스 안에 내장된다. 이 점이 기존의 단일 에이전트 방식과 가장 크게 다른 부분이다.
검증 단계를 설계할 때 실무적으로 확인해야 할 항목은 다음과 같다.
계획 단계에서 나온 산출물, 즉 작업 분해 결과와 의존성 그래프가 구현 시작 전에 별도 검토를 받는가. 구현된 코드가 계획 단계에서 정의된 범위 안에 있는가를 검토 단계에서 명시적으로 확인하는가. 테스트 커버리지 기준이 사전에 정의되어 있고, 에이전트가 그 기준을 충족했는지 머지 전에 자동으로 확인하는가. 사람이 개입한 케이스를 기록하고, 그 패턴이 반복되면 프로세스 자체를 수정하는 루틴이 있는가.
마지막 항목이 중요하다. 에이전트 팀 운영에서 사람의 역할은 개별 작업을 직접 처리하는 것보다, 에이전트가 반복적으로 실패하는 지점을 찾아 구조를 개선하는 데 있다. 이것이 팀 단위 운영 모델이 단순 자동화와 다른 이유다. 자동화는 속도를 높이고, 팀 모델은 반복 가능성을 만든다.
도입 전에 먼저 답해야 할 질문
이 모델을 검토하는 제품 매니저라면, 벤더 선정이나 구현 설계보다 먼저 팀 내부에서 몇 가지를 정리해야 한다.
지금 자동화하려는 작업에서 품질 문제가 발생했을 때 피해 범위가 어디까지인가. 에이전트가 생성한 코드를 검토하는 현재의 방식이 에이전트 속도와 맞는가, 아니면 병목이 되고 있는가. 동일한 유형의 작업이 앞으로 6개월 안에 몇 번 반복될 것으로 예상하는가.
첫 번째 질문에서 피해 범위가 제한적이면 팀 모델보다 단순한 구조가 낫다. 두 번째에서 검토가 이미 병목이라면 에이전트를 추가하기 전에 검토 구조를 먼저 바꿔야 한다. 세 번째에서 반복 횟수가 충분하지 않으면 팀 모델 구축에 드는 초기 비용이 회수되지 않을 수 있다.
이 세 질문에 대한 답이 명확해진 다음에야, 어떤 에이전트 구조를 요구사항에 넣을지 구체적으로 논의할 수 있다.
