AI 에이전트가 다른 에이전트를 호출할 수 있다고 해서 협업이 저절로 좋아지는 것은 아니다. 오케스트레이터는 직접 처리할지 위임할지 판단하고, 적합한 실행 주체를 선택한 뒤, 필요한 컨텍스트만 전달하고, 반환된 결과를 신뢰해도 되는지 확인해야 한다.

Google Cloud가 제기한 에이전트 위임 문제는 멀티 에이전트 시스템의 핵심 설계 과제를 보여준다. 프로덕션 관점에서 위임은 모델 사이의 자유로운 대화보다 입력과 권한, 종료 조건을 검사할 수 있는 제어 프로토콜에 가깝다.

에이전트는 위임할 때 무엇을 결정해야 하나?

첫 단계는 위임 자체가 필요한지 판단하는 것이다. 현재 에이전트가 처리할 수 있는 작업인지, 전문 도구나 별도 권한이 필요한지, 다른 도메인의 에이전트 또는 사람의 판단이 필요한지를 구분해야 한다.

다음으로 사용자의 목표를 독립적으로 실행 가능한 작업으로 분해해야 한다. 전체 대화 기록을 그대로 넘기는 것은 작업 명세가 아니다. 수신 에이전트가 실제 목적을 추측해야 하고, 불필요한 지시를 이어받거나 긴 컨텍스트에 묻힌 제약 조건을 놓칠 수 있다.

반환값을 어떻게 처리할지도 미리 정해야 한다. 결과를 승인하거나, 수정을 요청하거나, 다른 실행자에게 다시 보내거나, 사람에게 에스컬레이션할 수 있다. 결국 위임은 작업 분해, 라우팅, 실행, 검증이 이어지는 폐쇄 루프다.

핸드오프 전에 작업 계약부터 정의하라

위임 단위는 별도로 평가할 수 있을 만큼 좁고, 추가 추측 없이 실행할 수 있을 만큼 완결적이어야 한다. 최소한 다음 항목을 명시하는 것이 좋다.

• 목표: “알아서 해결” 같은 표현이 아니라 도달해야 할 최종 상태
• 입력: 사용할 수 있는 데이터와 신뢰 기준이 되는 자료
• 제약: 허용된 도구와 권한, 시간·비용 한도, 금지된 행위
• 출력: 기대하는 스키마, 분석 결과, 패치, 의사결정 또는 근거
• 승인 기준: 성공과 실패, 수동 검토 필요 상태를 구분하는 검사 조건

예를 들어 장애 대응 에이전트에 “프로덕션을 복구하라”고 지시하면 원인 분석, 조치 선택, 승인, 변경 실행을 한 번에 맡기게 된다. 대신 허용된 텔레메트리를 분석하고, 근거에 따라 가설을 정렬한 뒤, 환경을 변경하지 않은 상태로 복구안을 반환하도록 범위를 제한할 수 있다.

실제 변경은 별도의 정책 게이트와 승인 절차를 통과한 후 최소 권한을 가진 실행자가 담당하게 한다. 이는 관리형 자동화 Control Plane에서 정책 결정과 실행 권한을 분리하는 방식과도 맞닿아 있다.

어떤 에이전트에 얼마나 많은 컨텍스트를 전달해야 하나?

라우팅은 에이전트 이름이나 자연어 소개가 아니라 검증 가능한 역량 명세를 기준으로 해야 한다. 레지스트리에는 처리 가능한 작업 유형, 필요한 권한과 도구, 출력 형식, 알려진 운영 제한을 기록할 수 있다. 등록된 역량은 최초 연결 시점뿐 아니라 구성 요소가 바뀔 때도 다시 검증해야 한다.

도입 초기에는 명시적 라우팅 규칙이 모델의 자율 선택보다 테스트하기 쉽다. 모델이 실행자를 선택하더라도 허용 목록, 최대 핸드오프 횟수, 위임 깊이, 비용 한도와 대체 경로 안에서 움직이도록 해야 한다. 그러지 않으면 불확실한 판단이 재위임과 재시도의 연쇄로 커질 수 있다.

컨텍스트에도 최소 권한 원칙이 적용된다. 하위 에이전트는 작업 수행에 필요한 정보만 받아야 하며, 상위 에이전트의 전체 메모리나 자격 증명, 대화 이력을 자동으로 상속해서는 안 된다. 구조화된 작업 요약과 권한이 부여된 데이터 참조, 상관관계 식별자를 전달하면 통제와 추적이 쉬워진다.

핸드오프가 늘어날 때마다 원래 의도가 변형될 가능성도 커진다. 실행자는 답변뿐 아니라 판단 근거와 불확실성, 완료 여부를 기계가 읽을 수 있는 상태로 반환해야 한다. 유창하게 작성된 문장을 정확성의 증거로 간주해서는 안 된다.

프로덕션에서는 위임을 어떻게 평가하고 관측할까?

최종 답변만 평가하면 실패가 시작된 지점을 알기 어렵다. 위임 필요성 판단, 작업 분해의 정확성, 실행자 선택의 적합성, 승인 기준 충족 여부를 분리해 테스트해야 한다.

평가 시나리오에는 컨텍스트 누락, 상충하는 지시, 도구 장애, 권한 거부, 잘못된 출력 형식, 반복 타임아웃 등을 포함할 수 있다. 모든 테스트에서 작업을 완수하는 것이 정답은 아니다. 위험한 상황에서는 중단하고 불확실성을 알리거나 사람의 검토를 요청하는 편이 올바른 동작이다.

프로덕션 트레이스는 최초 요청부터 각 핸드오프, 도구 호출, 검증, 재시도와 에스컬레이션을 연결해야 한다. 정책 및 구성 요소 버전, 송신자와 수신자, 소요 시간, 리소스 사용량, 검증 결과, 종료 이유가 있어야 의사결정 흐름을 재구성할 수 있다. 단, 민감한 프롬프트와 데이터에는 마스킹, 접근 통제와 보존 정책을 함께 적용해야 한다.

위임은 지연 시간과 인프라 비용에도 직접 영향을 준다. 한 요청이 여러 실행으로 분기될 수 있기 때문이다. 프로덕션 AI의 GPU 및 모델 서빙을 운영하는 팀이라면 위임 깊이, 병렬 실행, 재시도, 토큰 사용량을 감춰진 구현 세부사항이 아니라 관리 대상 리소스로 봐야 한다.

안전하게 자율성을 확대하는 순서는?

먼저 읽기 전용이며 결과를 저렴하게 검증할 수 있는 워크플로에서 시작한다. 외부 시스템을 변경하는 행위에는 승인을 요구하고, 핸드오프 횟수와 종료 조건을 정한 뒤 품질을 측정한다.

그다음 트레이스를 검토해 반복되는 작업 분해 및 라우팅 오류를 찾는다. 에이전트를 더 추가하기 전에 계약과 정책부터 개선하는 편이 낫다. 명확한 인터페이스와 운영 피드백은 플랫폼 엔지니어링에서 개발자 경험을 높이는 기반이기도 하다.

정상 상황과 실패 상황 모두에서 평가 기준을 만족할 때만 실행 권한을 단계적으로 늘려야 한다. 자율성은 데모가 인상적이라는 이유로 켜는 기능이 아니라, 운영 데이터로 확보해야 하는 속성이다.

결론

• 위임을 입력, 제약, 출력, 승인 기준이 명시된 작업 계약으로 모델링한다.
• 검증된 역량을 기준으로 라우팅하고 필요한 컨텍스트와 권한만 제공한다.
• 위임 판단, 작업 분해, 실행자 선택, 최종 결과를 각각 평가한다.
• 위임 깊이와 재시도, 비용, 부수 효과를 제한하고 사람에게 넘길 경로를 둔다.
• 반복 가능한 평가와 프로덕션 트레이스가 뒷받침될 때만 자율성을 확대한다.

관련 글

• 프로덕션 AI를 위한 DevOps: GPU와 모델 서빙 최적화
• Ansible Automation Orchestrator: 관리형 Control Plane 설계
• Red Hat의 새 DevOps 방향을 잇는 계층, 개발자 경험

참고 자료

How agents can delegate better