새로운 모델 벤치마크를 돌리는 일을 멈추고, 에이전트가 구독 취소를 시도하는 모습을 지켜보기 시작하십시오. 그 두 활동 사이의 간극이 바로 프로덕션 시스템이 무너지는 지점입니다. 단발성(single-turn) 테스트는 응답이 듣기 좋은지를 알려줄 수는 있습니다. 하지만 에이전트가 엉뚱한 고객에게 환불을 해줬는지, 캘린더 API를 상대로 14번이나 무한 루프를 돌았는지, 혹은 사기 탐지(fraud check) 단계를 통째로 건너뛰기로 결정했는지는 알려주지 못합니다. 텍스트는 에이전트가 생성하는 것 중 가장 덜 위험한 요소입니다. 진짜 위험은 에이전트가 건드리는 도구, 에이전트가 변경하는 데이터, 그리고 도움을 요청해야 할 순간에 계속 진행해 버리는 상황 속에 숨어 있습니다.
프로덕션 환경에서 텍스트 벤치마크가 실패하는 이유
표준 벤치마크의 높은 점수는 오해를 불러일으키는 안도감이 되었습니다. 우아한 문장을 쓰는 에이전트라도 운영상의 위험 요소가 될 수 있습니다. 시스템이 예약을 잡거나, 데이터베이스 레코드를 수정하거나, 지원 티켓을 생성할 때, 생성된 텍스트는 워크플로우의 가시적인 표면에 불과합니다. 그 이면에서 에이전트는 어떤 엔드포인트를 호출할지, 어떤 페이로드를 보낼지, 그리고 언제 멈출지에 대해 구체적인 결정을 내리고 있습니다. 에이전트는 독해 능력 리더보드 상위권을 차지하면서도, 자원을 중복 예약하거나, 잘못된 행(row)을 수정하거나, 민감한 상태 정보를 로그 파일에 유출함으로써 비용을 발생시킬 수 있습니다. 출력물의 세련됨이 아니라, 작업의 메커니즘을 검증해야 합니다. 만약 에이전트가 오프라인 QA 테스트에서는 높은 점수를 받으면서도, 루핑을 일으키거나 도구를 오용하여 워크플로우를 망친다면, 여러분의 평가는 잘못된 신호를 보고 있는 것입니다.
5가지 의존성 매핑하기
Van Data Team의 팀원들은 모든 평가를 시작할 때 다섯 가지 특정 제어 지점을 매핑하는 것부터 시작합니다. 이렇게 하면 질문 자체가 완전히 달라집니다. 어떤 모델이 다른 모델보다 더 똑똑한지를 묻는 대신, 에이전트가 실제 제약 조건 하에서 프로덕션 작업을 실제로 완수할 수 있는지를 묻기 시작하는 것입니다.
비즈니스 결과(Business outcomes). 달러 가치와 고객 영향력을 기준으로 "완료"가 무엇을 의미하는지 정의하십시오. 에이전트가 요약본을 내놓았다고 해서 작업이 완료된 것이 아닙니다. 재고 기록이 정확하고, 예약이 확정되었으며, 고객이 유효한 운송장 번호를 받았을 때 비로소 작업이 완료된 것입니다.
변경 가능한 상태(Mutable state). 에이전트가 무엇을 변경할 수 있는지 정확히 파악하십시오. 어떤 테이블, 어떤 상태, 어떤 계정 플래그를 건드릴 수 있습니까? 에이전트가 환불을 발행하거나, 작업을 재스케줄링하거나, 결제 주소를 업데이트할 수 있다면, 에이전트가 건드리는 모든 필드를 목록화해야 합니다.
도구 권한(Tool permissions). 어떤 API 엔드포인트와 함수가 범위 내에 있는지 명확히 하십시오. 검색 도구, 쓰기 도구, 알림 도구에 대한 접근 권한을 가진 에이전트는 경계가 모호하면 이들을 혼동할 것입니다. 각 권한을 특정 운영 요구 사항에 매핑하십시오.
실패 복구(Failure recovery). 캘린더 API가 타임아웃되거나, 500 에러를 반환하거나, 잘못된 형식의 JSON을 전달할 때 어떤 일이 발생할지 결정하십시오. 에이전트는 당황하거나, 성공 메시지를 환각(hallucinate)하거나, 영원히 재시도해서는 안 됩니다. 명확한 폴백(fallback) 경로가 필요합니다.
사람의 검토 단계(Human review gates). 에이전트가 진행하기 전에 사람이 승인해야 하는 순간을 식별하십시오. 이는 자동화의 약점이 아닙니다. 영향력이 큰 변경을 위한 안전장치이자, 평가 루브릭을 위한 정답(ground-truth) 라벨의 원천입니다.
실제 평가 계획의 모습
의존성 매핑이 끝나면, 프로덕션의 복잡성에 걸맞은 평가 계획이 필요합니다. 슬라이드 덱에 담긴 지표는 여기서 도움이 되지 않습니다.
합성 질문 은행이 아닌, 실제 프로덕션 실패 사례로부터 테스트 세트를 구축하십시오. 만약 에이전트가 지난 화요일에 유사한 두 개의 SKU를 혼동하여 실패했다면, 바로 그 혼동 사례가 영구적인 테스트 케이스가 되어야 합니다. 여러분의 평가 스위트는 사고를 통해 새로운 것을 배울 때마다 성장해야 합니다.
운영 관점에서 성공적인 완료를 정의하는 루브릭을 작성하십시오. "도움이 되는" 또는 "정확한"과 같은 모호한 기준은 쓸모가 없습니다. 유용한 루브릭은 환불 작업이 성공하려면 원래의 결제 ID가 참조되었고, 금액이 요청과 일치하며, 확인 이메일이 대기열에 추가되었고, 트랜잭션 ID가 기록되어야 한다고 명시해야 합니다.
도구 호출 및 재시도에 대한 트레이스 사양(trace specs)을 정의하십시오. 에이전트가 무엇을 계획했는지, 실제로 무엇을 호출했는지, 몇 번이나 재시도했는지, 그리고 재시도 전략이 적절했는지에 대한 관측 가능성(observability)이 필요합니다. 도구 수준의 세부 정보가 없는 트레이스는 그저 그럴싸한 이야기일 뿐입니다.
사람에게 알림을 보내야 하는 시점에 대한 정책을 설정하십시오. 에이전트는 자신의 한계를 알고 있어야 합니다. 요청 금액이 임계값을 초과하거나, VIP 계정을 참조하거나, 이전에 본 적 없는 상태에 직면하면, 추측하는 대신 에스컬레이션(escalate)해야 합니다.
잘못된 모델 업그레이드를 차단하기 위한 릴리스 게이트를 설치하세요. 새로운 모델이 업그레이드가 되려면 사용자의 특정 성과를 개선해야만 합니다. 만약 도구 인자(tool arguments)를 더 자주 환각하거나, 지연 시간(latency)을 증가시키거나, 새로운 안전 위험을 초래한다면, 그 모델은 배포되어서는 안 됩니다. 릴리스 게이트는 베이스 모델 벤더가 새로운 버전을 출시하더라도 프로덕션을 안정적으로 유지해 줍니다.
런타임 그레이딩: 에이전트의 작업 과정을 모니터링하기
Anthropic은 업계가 오프라인 테스트를 넘어 런타임 그레이딩으로 나아가도록 독려해 왔습니다. 사후에 기록(transcript)을 판단하는 대신, 런타임 그레이딩을 사용하면 작업이 진행 중인 동안 시스템이 에이전트의 작업을 판단할 수 있습니다. 이를 통해 오류가 실제 문제로 굳어지기 전에 포착할 기회를 얻을 수 있습니다.
그레이더를 추가하면 토큰과 지연 시간이 발생합니다. 모든 사소한 단계마다 그레이딩을 할 수는 없습니다. 각 그레이더의 위치를 결정하는 것은 설계상의 결정입니다. 실수가 발생했을 때 비용이 많이 드는 지점에 그레이더를 배치하세요. 가장 가치 있는 체크포인트는 데이터베이스에 상태 변경을 커밋하기 직전, 결제를 처리하기 직전, 그리고 고객에게 메시지를 보내기 직전입니다. 이 순간들은 잘못된 결정이 되돌릴 수 없는 작업으로 이어지는 시점입니다.
특정 사각지대를 주의해야 합니다. 동일한 모델이 작업을 수행하고 동시에 그 작업을 그레이딩한다면, 동일한 실수를 놓칠 수 있습니다. 오류를 생성한 추론 과정이 검토 단계에서 그 오류를 쉽게 합리화할 수 있기 때문입니다. 영향력이 큰 작업의 경우, 반드시 사람의 검토(human review)를 포함하세요. 특히 돈이나 고객의 신뢰가 걸려 있는 경우에는 사람이 그레이더의 판단 자체를 검증하도록 해야 합니다.
여기서의 목표는 운영 제어입니다. 장애 데이터, 작업 루브릭, 런타임 트레이스를 하나의 피드백 사이클로 연결하세요. 계획, 도구 사용, 복구 동작, 그리고 최종 결과에 이르는 전체 경로를 평가하십시오. 오프라인 테스트를 사용하여 배포 전에 이미 알려진 재현 가능한 오류를 잡아내고, 런타임 트레이스를 사용하여 예상치 못한 새로운 실패를 찾아내십시오. 휴먼 리뷰를 통해 현재의 루브릭이 너무 단순하여 보완이 필요한 부분을 발견하십시오.
그러므로 스스로에게 물어보십시오. 워크플로우의 어느 지점에 런타임 그레이더를 배치할 것인가? 도구 호출 전인가, 도구 호출 후인가, 아니면 위험한 변경 직전인가? 대부분의 팀은 너무 광범위하게 시작하여 모든 것을 그레이딩하려다 비용 부담으로 인해 진행이 멈추게 됩니다. 좁게 시작하십시오. 잘못되었을 때 가장 큰 타격을 줄 단 하나의 행동을 선택하십시오. 그리고 거기에 먼저 그레이더를 배치하십시오.
단 하나의 비용이 큰 실수부터 시작하세요
운영 평가(Operational evaluation)는 연구를 위한 과제가 아닙니다. 에이전트가 라이브로 작동할 때 더 편안하게 잠들기 위한 방법입니다. 첫날부터 완벽한 프레임워크가 필요하지는 않습니다. 잘 정의된 단 하나의 워크플로우, 명확한 비즈니스 용어로 작성된 루브릭, 그리고 오류가 발생했을 때 비용이 가장 많이 드는 정확한 시점에 배치된 그레이더가 필요할 뿐입니다. 이것만 제대로 갖춘다면, 실제로 신뢰할 수 있는 토대를 마련한 것입니다.
에이전트 평가 및 런타임 그레이딩에 대해 실무자 커뮤니티와 함께 더 깊이 파고들고 싶다면, https://t.me/GyaanSetuAi에서 GyaanSetu 학습 커뮤니티를 찾아보실 수 있습니다.