AI 에이전트(LLM 기반의 자율 에이전트)를 실제 운영하고 있는 조직에서 자주 발생하는 문제—'에이전트는 바쁘게 움직이지만, 정말 비즈니스 가치를 창출하고 있는가?'—에 대해, 기존 KPI(공수 절감, 처리량, SLA 달성률)가 왜 오해를 불러일으키는지를 설명하고, 대신 구현/운영/감사 현장에서 사용할 수 있는 5차원 스코어카드를 제안합니다.

대상 독자는 AI 에이전트의 시스템 설계, API 연동, 권한 통제, 감사 로그, 운영 평가에 참여하는 엔지니어・아키텍트・SRE・IT 기획 담당자입니다. 경영론이 아닌, 구체적인 측정 항목과 설계 판단 기준에 초점을 맞춥니다.

기존 KPI(FTE 가동률, 처리 건수, SLA 달성률)는 인간이 단독으로 작업하는 세계를 전제로 설계되었습니다. 하지만 인간+AI 에이전트 팀에서는 하나의 비즈니스 성과가 '디지털 노동력 × 인간의 판단 × 워크플로우 제어 × 데이터 품질 × 가드레일'의 합성으로 탄생합니다.

구체적 예시: 경리 월말 마감 지원 에이전트

• 에이전트가 ERP에서 증빙을 수집하고, 코멘트 초안을 작성
• 인간의 확인 공수가 줄어들어 FTE 가동률이 저하됨
• 기존 KPI에서는 '유휴 리소스'로 간주됨
• 하지만 실제로는, 인간이 **고부가가치 업무(원인 분석, 사업 부문과의 조정)**에 집중하게 됨

구체적 예시: 고객 지원 에이전트

• 일일 처리 티켓 수가 증가함
• 그러나 상장의 수정(Override)이 빈번하고, 고객의 재문의율이 상승함
• SLA 대시보드는 녹색이지만,
  해결 품질은 저하됨

이 패턴은 공통적입니다: 활동 측정 지표는 양호해 보이나, 성과 품질은 조용히 열화된다. 그렇기에 새로운 측정 프레임워크가 필요합니다.

5次元スコアカードの概念図

기존의 선형 메트릭스에서 가치・품질・신뢰・위험・비용을 균형 잡는 5층 스코어카드로 전환

에이전트는 수단이지 목적이 아닙니다. 가장 먼저 이것을 측정해야 합니다.

'에이전트 도입 전 사이클 타임', '오류율', '운영 비용'을 문서화하지 않으면, 개선의 원인이 에이전트 때문인지, 정책 변경 때문인지, 데이터 클렌징 때문인지를 구분할 수 없습니다.

비즈니스 성과가 양호하더라도, 에이전트 내부가 건강하지 않은(고비용, 잦은 수정, 은밀한 인간 부하) 경우가 많습니다.

구현상의 포인트:

• 수정률을 측정하려면, 에이전트의 출력과 인간의 최종 출력을 diff로 저장하는 메커니즘이 필요합니다.
• 환각율은 LLM의 자기 평가(Self-Consistency)나 외부 지식 기반과의 일치율로 근사할 수 있습니다.

에이전트가 사용되지 않으면 의미가 없습니다. 하지만, 억지로 사용하게 해도 의미가 없습니다.

• 에이전트의 출력에는 근거 링크(참조된 사내 문서 ID, API 응답의 JSON 경로)를 반드시 첨부해야 합니다. - 오버라이드가 발생했을 경우, 그 차이분을 학습 데이터에 피드백하는 파이프라인을 설계합니다.

이 층은 컴플라이언스・감사・위험 관리 팀과 공동으로 설계해야 합니다.

에이전트의 툴 호출을 감사하는 미들웨어

class AuditMiddleware:
def init(self, allowed_tools: list[str], audit_logger):
...

가장 내부적인 레이어: 성공 1건당 총 비용. 이것이 추가적인 자율성에 투자할 가치가 있는지, 기술적으로는 성공적이지만 경제적으로는 파산 상태인지를 판단하게 합니다.

• 계산식:
  (LLM API 비용 + 컴퓨트 비용 + 인간 확인 비용 + 수정 비용) / 성공 완료 건수

• 비교 대상: 기존의 완전 수동 프로세스의 1건당 비용

• 판단 기준: 에이전트의 비용이 수동 방식의 70% 이하일 경우 스케일 투자 기준으로 삼을 수 있습니다.

"이번 달에는 1,000개의 태스크를 자동화했습니다"라는 보고는 아무것도 말하지 않은 것과 같습니다. 그 1,000개 태스크 중 몇 건이 수정 없이 완료되었나요? 몇 건이 고객 만족도를 향상시켰나요? 이를 동시에 제시할 수 없다면, 그것은 '바쁘기만 한 에이전트'일 뿐입니다.

이것이 가장 위험한 **환영의 생산성(Phantom Productivity)**입니다. 에이전트는 바쁘게 움직이고 있습니다. 인간은 뒤에서 수정 작업을 하고 있습니다. 아무도 그 연관성을 시각화하지 않고 있습니다. 오버라이드율(Override Rate)을 에이전트 개선의 최우선 백로그 항목으로 다루어야 합니다.

• 비즈니스: "처리 시간이 단축되었다"
• IT: "API 응답이 빠르다"
• 리스크: "감사 추적(Audit Trail)이 완벽하다"

이것들이 분리되어 있으면 에이전트의 평가를 할 수 없습니다. 5차원 스코어카드를 한 장으로 통합하고 모든 이해관계자가 합의하는 것이 스케일링의 전제 조건입니다.

• 기준선(Baseline) 확보: 에이전트 도입 전의 사이클 타임, 오류율, 비용을 문서화합니다.
• 5차원 스코어카드 설계: 위의 지표들을 자사의 도메인에 맞춰 커스터마이징합니다.
• 감사 로그 설계: 모든 API 호출, LLM 입출력, 인간 수정 차이를 불변(Immutable)하게 저장합니다.
• 오버라이드율을 개선 백로그의 최우선 항목으로 지정: 수정 패턴을 분석하여 프롬프트나 RAG에 피드백합니다.
• 스코어카드를 주간 검토의 표준 아젠다로 설정: 경영진이 아닌 개발팀 스스로가 매주 확인하도록 합니다.

'에이전트가 작동하고 있다'와 '에이전트가 가치를 창출하고 있다'는 별개의 문제입니다. 5차원 스코어카드로 그 차이를 시각화해야 합니다.