당신의 에이전트형 AI 파일럿은 아마도 잘못된 지표를 측정하고 있을 것입니다

당신은 에이전트형 AI (Agentic AI) 시스템을 구축했습니다. 잘 작동하고 있습니다. API 호출을 체이닝하고, 의사결정을 내리며, 예외 상황을 처리하는 등 실제로 자율적인 업무를 수행하고 있습니다. 이제 이 시스템이 인프라 비용을 지출할 가치가 있다는 것을 증명해야 합니다.

그래서 당신은 메트릭 (Metrics) 대시보드를 불러옵니다: 소비된 토큰 (Tokens), 평균 응답 시간 (Average response time), 상호작용당 비용 (Cost per interaction). 깔끔한 숫자들입니다. 재무 부서가 좋아할 만한 수치죠.

하지만 이 메트릭들은 에이전트가 아닌 챗봇 (Chatbot)을 위해 설계된 것입니다. 그리고 그 불일치가 당신의 비즈니스 케이스 (Business case)를 조용히 망가뜨리고 있습니다.

챗봇 메트릭의 함정

대부분의 팀은 RAG (Retrieval-Augmented Generation) 시스템과 지원용 봇에서 사용하던 AI 메트릭을 그대로 물려받습니다. 해당 시스템들은 다음과 같은 기준으로 평가되었습니다:

• 쿼리당 비용 (Cost per query) – 한 번의 질의응답 상호작용에 비용이 얼마나 드는가?
• 응답 정확도 (Response accuracy) – 올바른 답변을 검색했는가?
• 사용자 만족도 점수 (User satisfaction scores) – 사람이 응답을 마음에 들어 했는가?

이 지표들은 단순한 검색창을 대체하던 시절에는 타당했습니다. 하지만 에이전트형 시스템은 그렇게 작동하지 않습니다.

에이전트는 질문에 답하는 것이 아닙니다. 에이전트는 워크플로우 (Workflow)를 실행합니다. 에이전트는 다음과 같은 일을 할 수 있습니다:

• 컨텍스트 (Context)를 수집하기 위해 세 개의 서로 다른 API 호출
• 비즈니스 규칙에 기반한 의사결정 수행
• CRM에 데이터를 다시 기록
• Slack에서 후속 작업 트리거
• 실패를 처리하고 백오프 (Backoff)와 함께 재시도

만약 이를 "쿼리당 비용"으로 측정한다면, 당신은 사과 한 알과 과일 샐러드 전체를 비교하고 있는 셈입니다. 작업의 단위가 비교 불가능합니다. 당신의 ROI (Return on Investment) 근거는 정밀한 검토 과정에서 무너지고 맙니다.

실제로 측정해야 하는 것

AI가 아니라 _워크플로우_부터 시작하세요. 에이전트가 무엇을 대체하고 있는지 매핑해 보세요:

이전 (수동 프로세스):

1. 지원 담당자가 에스컬레이션 (Escalation) 이메일을 받음
2. CRM에서 고객 조회 (평균 2분)
3. 레거시 시스템에서 주문 내역 확인 (평균 3분)
...

이후 (에이전트형 시스템):

# 에이전트형 환불 워크플로우를 위한 의사코드 (Pseudocode)
async def handle_refund_escalation(email):
    customer = await crm.lookup(email.from_address)
...

이것을 측정하세요:

• End-to-end completion time (종단 간 완료 시간) (13분 → 45초)
• Throughput increase (처리량 증가) (시간당 1인당 8건 → 시간당 80건)
• Error rate (오류율) (수동 데이터 입력 오류 vs 에이전트 실패)
• Escalation rate (에스컬레이션율) (여전히 인간의 검토가 필요한 비율 %)
• Cost per completed workflow (완료된 워크플로우당 비용) (API 호출당 비용이 아님)

이제 비즈니스 성과와 직결되는 수치들을 갖게 되었습니다. 여러분의 에이전트가 인간보다 시간당 72건 더 많은 에스컬레이션을 처리하며, 99.2%의 정확도를 유지하고, 수동 처리 비용인 £4.80 대비 워크플로우당 £2.30의 비용으로 운영된다는 점을 보여줄 수 있습니다.

이것이 바로 비즈니스 케이스(Business case)입니다. "40,000개의 토큰을 절약했습니다"는 비즈니스 케이스가 아닙니다.

파일럿 프로젝트가 실제 성과를 숨기는 이유

대부분의 에이전트형 파일럿은 기존 프로세스와 병행하여(in parallel) 실행됩니다. 여러분은 결과물을 비교하고 있지만, 기존 프로세스가 여전히 가동 중이기 때문에 실제 비용 절감액은 포착하지 못하고 있습니다.

이는 세 가지 문제를 야기합니다:

1. 비용 절감이 나타나지 않음 – 두 시스템 모두에 비용을 지불하고 있습니다.
2. 처리량 이득이 보이지 않음 – 에이전트는 10배 더 많은 물량을 처리할 수 있지만, 여러분은 10배 더 많은 업무를 에이전트에게 보내지 않고 있습니다.
3. 비교가 인위적임 – 실제 생산 부하를 측정하는 대신 특정 작업만을 선별(cherry-picking)하여 측정하고 있습니다.

신뢰할 수 있는 수치를 얻으려면 다음과 같이 해야 합니다:

• 실제 운영 트래픽의 _일정 비율(percentage)_을 에이전트에게 라우팅하십시오.
• 해당 워크플로우에서 실제로 절감된 시간과 비용을 측정하십시오.
• 해당 비율을 확대할 때 어떤 일이 발생하는지 추적하십시오.

과학 실험을 하지 마십시오. 롤백(Rollback) 기능이 있는 프로덕션 배포(Production rollout)를 실행하십시오.

재무 부서를 실제로 설득하는 방법

CFO는 여러분의 모델 아키텍처(Model architecture)에는 관심이 없습니다. 그들은 다음 사항에 관심이 있습니다:

• Unit economics (단위 경제성) – 완료된 워크플로우당 비용
• Payback period (회수 기간) – 누적 절감액이 구축 비용을 초과하는 시점은 언제인가?
• Risk (리스크) – 시스템이 고장 나면 어떻게 되는가?

이러한 질문들을 중심으로 지표를 구축하십시오. 이를 제대로 해내고 싶다면, 여러분의 ROI 프레임워크가 잘못되었다고 간주하는 것이 시작점입니다.

그리고 더 큰 디지털 전환 (Digital Transformation) 맥락에서 에이전트형 시스템 (Agentic Systems)을 구축하고 있다면, AI 자동화 및 소프트웨어 개발에 경험이 있는 팀과 협력하는 것이 프로덕션 (Production) 단계에 도달하기도 전에 파일럿 프로젝트를 침몰시키는 흔한 구조적 실수를 피하는 데 도움이 됩니다.

실질적인 시사점 (The Practical Takeaway)

에이전트형 코드를 한 줄이라도 더 작성하기 전에, 해당 코드가 대체하려는 워크플로 (Workflow)를 매핑하십시오. 다음을 정의하십시오:

• 워크플로당 절약된 시간
• 오류율 (Error rate) 비교
• 처리량 상한선 (Throughput ceiling) (기존 방식 vs. 새로운 방식)
• 완료된 작업 단위당 총 비용

그런 다음, 첫날부터 이러한 지표를 캡처할 수 있도록 에이전트를 계측 (Instrument)하십시오. 토큰 수 (Token counts)가 아닙니다. 추론 지연 시간 (Inference latency)도 아닙니다. 바로 _비즈니스 결과 (Business outcomes)_입니다.

왜냐하면, 실행할 가치가 있다는 것을 증명할 수 없다면 세상에서 가장 뛰어난 에이전트형 시스템이라 할지라도 가치가 없기 때문입니다.