기업이 에이전트에 맡길 수 있는 일의 범위는 모델이 몇 단계를 수행하느냐만으로 정해지지 않는다. 오류를 얼마나 빨리 발견하고, 발견 전의 손실을 얼마나 작게 제한할 수 있느냐가 실제 범위를 가른다. 여기서 검증 비용은 검사에 드는 시간과 인력뿐 아니라 잘못을 늦게 발견해 생기는 피해까지 포함한다.
현업 에이전트는 10단계 안에서 멈춘다
실제 배포에서는 얼마나 멀리 갈까? UC Berkeley, Stanford, IBM Research 연구진은 26개 분야의 배포 시스템 실무자 86명을 설문하고 20건을 심층 사례 연구로 분석했다. 배포된 시스템의 68%는 사람이 개입하기 전까지 10단계 이하로 움직였고, 47%는 5단계도 넘지 않았다. 실험실은 모델의 최대 과제 길이를 시험하지만, 현업은 실패를 추적하고 피해를 제한할 수 있는 길이로 운영 범위를 정한다.
그 짧은 범위는 구현에서도 드러난다. 70%는 별도 파인튜닝 없이 상용 모델을 썼고, 79%는 사람이 작성한 프롬프트에 의존했다. 심층 사례의 80%는 미리 정한 제어 흐름을 사용했다. 보험 심사 에이전트도 보장 조회, 의학적 필요성 검토, 위험 식별이라는 순서를 벗어나지 않았다. 정해 둔 길만 걷는다는 말이다.
그런데 응답 속도는 결정적인 제약이 아니었다. 66%가 분 단위 이상의 응답 시간을 허용했고 17%는 명시적 제한을 두지 않았다. 사람이 하던 일을 충분히 단축한다면 몇 분의 대기 시간도 감수한다. 현업에서는 순간적인 속도보다 업무가 예상한 범위 안에서 끝나는지가 더 중요하다.
99% 정확도도 장기 실행을 버티지 못한다
단계만 늘리면 충분할까? 각 단계의 성공이 서로 독립이고 성공률이 95%로 일정하다고 가정하면, 10단계를 모두 성공할 확률은 약 60%, 20단계는 36%다. 단계별 성공률이 99%여도 100단계를 모두 통과할 확률은 약 37%에 그친다. 긴 실행에서는 작은 오류율도 누적된다.
토비 오드가 제시한 에이전트 반감기 모형에서도 같은 패턴이 나타난다. 전체 성공률 80%를 요구하면 가능한 업무 길이는 50% 기준의 약 3분의 1, 99%를 요구하면 약 70분의 1로 줄어든다. 실제 과제에서는 시간이 흐르며 실패 위험이 일정하게 유지되지 않을 수 있어 정확한 예측식이라기보다 높은 신뢰성을 요구할수록 자율 실행의 길이가 짧아진다는 설명에 가깝다.
한 번의 성공과 반복 신뢰성도 다르다. 고객 응대 평가인 τ-bench에서 같은 과제를 여덟 번 연속 성공한 비율은 소매 분야에서 25%를 밑돌았다. 다른 장기 과제 연구에서는 소프트웨어 작업의 반복 안정성이 크게 떨어진 반면 문서 처리는 거의 유지됐다. 복잡한 전략을 택한 프론티어 모델의 실패율은 최대 19%에 이르기도 했다. 모델이 어려운 문제를 한 번 푼 능력과 반복 업무로의 안정적 투입은 별개다.
그렇다고 능력 자체가 정체된 것은 아니다. METR(AI 모델의 장기 과제 수행 능력을 측정하는 연구기관)이 측정한 50% 성공 기준의 과제 길이는 2019년 이후 약 7개월마다 두 배로 늘었다. 그러나 기업은 절반의 성공률로 업무를 운영할 수 없다. 벤치마크에서 가능해진 시점과 높은 성공률로 반복 운영할 수 있는 시점 사이에는 시차가 있다.
관찰 가능성이 자율성의 한계를 정한다
심층 사례의 85%는 모델 API를 직접 호출하는 자체 구현을 사용했다. 외부 프레임워크를 쓴다는 전체 설문 응답도 61%였지만, 실제 배포의 핵심 경로는 단순한 코드로 관리한 경우가 많았다. 직접 만든 루프에서는 도구의 입력과 출력, 재시도 횟수, 중단 조건을 빠짐없이 기록하고 어느 호출에서 실패했는지 재현하기 쉽다.
관찰만으로 끝나지 않았다. 행동 권한도 제한했다. 일부 팀은 에이전트를 읽기 전용으로 운영했다. SRE(사이트 신뢰성 엔지니어링) 에이전트는 장애 보고서만 작성하고 실제 조치는 사람에게 넘겼다. 세 팀은 샌드박스를 사용했고, 한 팀은 허용된 기능만 담은 래퍼 API를 제공했다. 오류가 나더라도 실제 시스템에 미치는 피해를 정해진 범위 안에 가둬 둔 셈이다.
그런데 평가에는 여전히 사람이 필요했다.
- 팀의 74%가 사람 평가에 의존했고, LLM 심판을 쓴 팀도 모두 사람 검증을 병행했다.
- 공식 벤치마크 대신 A/B 테스트와 사용자 의견을 활용한 팀도 75%였다.
규제 분야에는 공개 데이터가 부족하고 고객마다 정책과 도구가 달라 하나의 공통 평가셋을 적용하기 어렵기 때문이다.
권한과 평가를 갖춰도 남는 변수가 있다. 업무별로 정답이 드러나는 속도는 다르다. 코드는 테스트와 컴파일러로 수초 안에 결과가 나온다. 반면 보험 심사의 잘못은 금전 손실이나 승인 지연으로 몇 달 뒤에야 드러날 수 있다. 실행 단계 수가 같아도 후자는 오류를 발견하기 어렵고 발견 전 피해도 크다. 그래서 후자는 더 짧은 실행 단위와 더 잦은 사람 검토로 대응한다.
자율성은 검증에서 시작된다
첫 배포는 목표 성공률과 단계별 실측 성공률에 따라 자율 실행 길이의 상한을 정하는 데서 시작한다. 사람 검토는 되돌리기 어려운 환불, 삭제, 발송 직전, 정답이 늦게 드러나는 판단 직전, 담당자의 서명이 필요한 산출물 직전에 둔다.
행동 권한은 읽기 전용에서 시작한다. 모든 입력과 출력, 재시도와 중단 사유를 기록하면서 실제 실패 사례를 모은다. 이 사례로 회귀 테스트를 만들고, 검증 수단이 확보된 기능부터 실제 시스템을 변경하는 권한을 단계적으로 연다.
검증 체계도 고정된 완성품이 아니다. 모든 기준은 사람의 의도를 일부만 담고 있으며, 모델이나 입력 분포가 바뀌면 기존 기준의 빈틈도 달라진다. 고정된 보상함수(모델의 행동에 점수를 매겨 학습 방향을 정하는 기준)는 모델의 능력이 높아질수록 효력을 잃을 수 있다. 모델을 바꿀 때마다 평가셋과 통과 기준을 다시 점검하고, 자동 통과 결과 중 일부는 사람이 표본 검사한다.
운영 가능한 자율성에는 두 가지 상한이 있다. 검증 없이 이어 갈 수 있는 단계의 수와, 사람 승인 없이 행사할 수 있는 권한의 범위다. 모델의 최대 능력이 늘어도 그 상한은 자동으로 열리지 않는다. 오류를 발견하고 기록하며 피해를 제한할 수 있는 범위가 사라지고 나면, 자율성의 근거도 사라진다.