이름은 에이전트, 일은 질의응답
기업이 AI 에이전트에 기대하는 것은 분명하다. 여러 단계를 거쳐 실제 업무를 끝내는 능력이다. 하지만 현실은 기대와 다르다. 2026년 6월 100인 이상 기업 101곳을 조사한 VentureBeat Pulse에 따르면, 응답 기업의 71%는 배포한 에이전트 가운데 다단계 워크플로를 수행하는 비율이 25% 이하라고 답했다. 평가 기준은 ‘업무 완료’인데, 정작 배포된 제품의 상당수는 질의응답이나 검색, 문서 작성을 돕는 챗봇에 가깝다.
이런 혼선은 공급자와 구매자가 함께 만든다. Gartner는 기존 챗봇이나 RPA를 큰 기능 변화 없이 에이전트라고 부르는 행태를 ‘에이전트 워싱’이라고 지적했다. 기업도 ‘에이전트’라는 이름이 붙으면 더 큰 예산과 전담 인력, 폭넓은 시스템 권한을 배정하기 쉽다. 기능이 이름을 정하기도 하지만 이름이 먼저 예산과 권한을 키운다.
구매 시장 역시 기술 담론과는 다르게 움직인다. 주요 모델 사업자 다섯 곳의 스택이 전체 배포의 약 80%를 차지했고 오픈 프레임워크나 자체 구축의 비중은 한 자릿수에 그쳤다. 부족한 것은 플랫폼이 아니라 플랫폼을 실제 업무에 연결하고 안정적으로 운영하는 역량이다.
따라서 기업이 세어야 할 것은 배포한 에이전트의 수가 아니라 정해진 조건에 따라 끝까지 완료된 다단계 업무의 수다.
돌려라. 단, 검증 가능한 것을
다단계 시스템의 신뢰도는 단계별 평균만으로 설명할 수 없다. 각 단계의 성공률이 이고 모든 개 단계가 성공해야 한다면, 전체 성공률은 이다. 단계마다 성공률이 95%여도 5단계 업무의 성공률은 77.4%, 20단계는 35.8%로 떨어진다. 단계별 성공률이 85%라면 10단계 업무를 완주할 확률은 약 19.7%에 불과하다.
실제 환경은 계산보다 더 까다롭다. 잘못된 출력 형식, API 오류, 권한 거부, 불완전한 데이터가 다음 단계까지 영향을 미치기 때문이다. 검증 지점과 비용 한도가 없는 장거리 자율 실행은 모델의 추론 성능을 따지기 전에 확률과 비용의 벽에 부딪힌다.
Anthropic도 복잡한 프레임워크보다 단순하고 조합 가능한 구조가 프로덕션에서 더 잘 작동한다고 설명한다. 경로가 정해진 업무는 워크플로로 처리하고 모델이 경로와 도구를 직접 선택해야 할 때만 에이전트를 쓴다. 프롬프트 체이닝, 라우팅, 평가 같은 패턴도 필요한 만큼 단계적으로 조합한다.
운영 환경에서는 긴 자율 실행보다 짧고 검증 가능한 경로가 낫다. 계획을 공개하고 반복 횟수를 제한하며 중요한 순간에는 사람이 개입한다. 다단계 업무가 제대로 나뉘지 않았거나 데이터 접근권, 쓰기 권한, 실패 후 철회 절차가 없다면 모델을 바꿔도 문제는 해결되지 않는다.
실험이 늘었다고 수익이 곧바로 늘어나는 것도 아니다. 맥킨지 조사에서 조직 내 한 곳 이상에 에이전틱 AI를 확장한 기업은 23%였지만 개별 기능의 확장 비율은 모두 10% 미만이었다. 가트너는 비용 증가, 불명확한 사업 가치, 부족한 위험 통제를 이유로 2027년 말까지 관련 프로젝트의 40% 이상이 취소될 것으로 전망했다.
좌석 수나 토큰 사용량, 파일럿 만족도만으로는 업무 성과를 알 수 없다. 단계 수를 줄이고 각 단계에 검증 가능한 종료 조건을 두면 성공률과 투자 효과를 제대로 측정한다.
누가 에이전트의 스위치를 쥐는가
기업이 오케스트레이션 플랫폼을 고를 때는 기능 목록만 보지 않는다. 먼저 모델을 선택하고 그 모델의 런타임과 도구 체계를 따라가는 경우가 많다. 테크 매체 VentureBeat 조사에서도 최신 프런티어 모델과의 긴밀한 통합이 주요 선택 요인으로 꼽혔다. 이른바 ‘모델 중력’이다.
모델 사업자의 통합 환경을 쓰면 구축은 빨라진다. 그러나 추론 절차와 도구 스키마, 메모리, 평가 기준까지 한곳에 모이면 다른 모델로 옮기기 어렵다. 외부 오케스트레이터를 붙였더라도 상태와 평가 결과를 밖에서 재현하지 못한다면 실질적인 운영권은 여전히 모델 사업자에게 있다.
기업도 이 위험을 알고 있다. 조사 대상의 51%는 2026년 말까지 하이브리드 컨트롤 플레인을 사용할 것으로 예상했고 사업자에게 운영을 완전히 맡기겠다는 응답은 6%에 그쳤다. 모델은 편리한 네이티브 환경에서 쓰되 상태와 권한은 외부에서 관리하려 한다.
다만 하이브리드라는 이름만으로 통제권이 생기지는 않는다. 권한 경계, 상태 머신, 감사 로그, 업무 평가 기준을 모델과 분리해 보관한다. 토큰이나 반복 실행이 한도를 넘으면 즉시 정지하는 킬 스위치(강제 중단 장치)도 필요하다. 실제로 조사 기업의 27%는 비용이 커지기 전에 에이전트를 중단할 실시간 재정 통제가 없었다.
특히 금융과 헬스케어처럼 감사와 철회가 필수인 업무에서는 이 구분이 중요하다. 모델을 교체해도 같은 권한과 중단 조건, 평가 방식을 재현할 수 있어야 한다.
플랫폼의 통제권은 구성도에 무엇이 그려져 있느냐가 아니라 운영 규칙을 누가 보관하고 실행하느냐로 결정된다.
에이전트와 계약하라
운영 관점에서 에이전트는 단일 프롬프트에 답하는 챗봇과 구분된다. 명확한 업무 결과를 향해 제한된 단계와 비용 안에서 도구를 사용하고 실패를 분류하며 사람이나 정책이 언제든 실행을 정지한다. 이 조건을 충족하지 못한다면 챗봇이나 검색, 매크로, 고정 워크플로로 분류하는 편이 정확하다.
이 기준을 문서로 만든 것이 ‘실행 계약’이다. 실행 계약에는 매출, 처리 건수, 해결된 요청처럼 측정 가능한 목표, 최대 단계 수와 비용 한도, 도구와 데이터의 접근, 수정 권한, 인간 검토와 에스컬레이션 시점, 예상 실패 유형과 재시도, 롤백 절차, 토큰, 행동, 권한을 즉시 차단하는 킬 스위치가 들어가야 한다.
측정 방식도 계약에 맞춰 바꿔야 한다. 배포 수나 토큰 수 대신 완료된 업무 건수를 기록하고 단계별 성공률과 전체 성공률을 나눠 봐야 한다. 권한 오류, 도구 오류, 환각, 무한 반복 같은 실패 원인도 따로 집계한다. 무인 완료율과 인간 개입 후 성공률을 구분하면 모델 성능, 워크플로 설계, 통제 장치의 효과를 각각 확인한다.
프로덕션의 기본값은 짧은 실행 경로와 강한 검증 절차여야 한다. 단순 프롬프트나 고정 워크플로로 해결할 수 없는 업무에만 동적 경로를 허용한다. 경로를 미리 정할 수 없고 자율 판단의 이점이 검증된 경우에만 멀티에이전트를 별도로 운영한다. 자율성은 처음부터 주어지지 않는다. 반복된 평가 뒤에 부여하는 권한이다.
플랫폼을 교체하거나 새로 도입하기 전에는 현재 시스템부터 다시 분류한다. 챗봇, 검색, 고정 워크플로, 에이전트를 나누고 실제 에이전트에는 같은 실행 계약을 적용한다. 그래야 새 플랫폼이 꼭 필요한 업무와 기존 구조로 충분한 업무가 드러난다.
기업이 사야 할 것은 ‘에이전트’라는 명패가 아니라 끝까지 업무를 완료하고 필요할 때 즉시 정지하며 나중에 모든 과정을 감사 가능한 실행 계약이다.