기록 시스템(System of Record)에서 실행 시스템(System of Action)으로: ITSM을 위한 에이전틱 AI (Agentic AI) 설계

현대적인 서비스 데스크(Service Desk)의 목표는 티켓 회피(Ticket Deflection)가 아니라 해결(Resolution)입니다. 수년 동안 우리는 ITSM 플랫폼을 인간이 문제의 이동을 수동으로 추적하는 미화된 원장, 즉 기록 시스템(System of Record)으로 취급해 왔습니다. 우리는 지능형 FAQ 역할을 하는 LLM(Large Language Model) 챗봇으로 이를 "해결"하려고 시도했습니다. 하지만 사용자에게 비밀번호를 재설정하는 방법을 알려주는 챗봇은 문제를 해결하는 것이 아니라, 단지 노력을 사용자에게 다시 떠넘기는 것뿐입니다.

진정한 에이전틱 AI (Agentic AI)는 서비스 데스크를 실행 시스템(System of Action)으로 변화시킵니다. 이는 정보를 제공하는 단계에서 워크플로(Workflow)를 실행하는 단계로 이동하는 것을 의미합니다. 이를 위해서는 AI를 설계하는 방식에 근본적인 변화가 필요하며, 선형적인 프롬프트-응답(Prompt-Response) 패턴에서 벗어나 계획(Plan), 실행(Act), 관찰(Observe)을 수행할 수 있는 자율 루프(Autonomous Loops)로 나아가야 합니다.

ITSM에서 '챗봇' 시대의 한계

왜 서비스 데스크의 대부분의 생성형 AI (GenAI) 구현이 MTTR(Mean Time To Resolution, 평균 복구 시간)을 개선하는 데 실패할까요? 그것들이 선형적(Linear)이기 때문입니다. 전통적인 챗봇은 다음과 같은 경로를 따릅니다: 사용자가 질문을 하면, LLM이 문서를 검색하고, LLM이 답변을 요약합니다. 만약 답변이 문제를 해결하지 못하면 루프가 종료되고, 사람이 처리해야 할 티켓이 생성됩니다.

에이전틱 AI (Agentic AI)는 이러한 선형적 흐름을 폐쇄 루프(Closed-loop) 시스템으로 대체합니다: 계획(Plan) $\rightarrow$ 실행(Act) $\rightarrow$ 관찰(Observe) $\rightarrow$ 개선(Refine).

에이전틱 루프(Agentic Loop)에서 AI는 단순히 답변만 하는 것이 아니라 추론(Reasoning)합니다. 만약 사용자가 "애플리케이션이 느리다"라고 보고하면, 에이전트는 사용자에게 "성능 문제 해결 가이드"를 안내하는 대신, 일련의 진단 단계를 계획합니다. 에이전트는 앱 서버의 현재 CPU 부하를 확인하거나, CI/CD 파이프라인에서 마지막 5개의 배포 내역을 조회하고, 특정 트레이스 ID(Trace ID)에 대한 에러 로그를 분석할 수 있습니다. 에이전트는 API를 호출하여 실행하고, 결과를 관찰하며, 발견한 내용에 따라 계획을 개선합니다.

선형적 챗봇 vs. 에이전틱 해결 루프 (Agentic Resolution Loops)

A comparison diagram showing a linear flow from user to chatbot to answer, versus a circular loop involving planning, tool execution, and observation.

Triage Agent (분류 에이전트)는 입구 역할을 합니다. 이 에이전트의 임무는 문제를 해결하는 것이 아니라, 의도(intent)와 텔레메트리(telemetry)를 합성하는 것입니다. 에이전트는 요청을 분류하고 "환경적 맥락(environmental context)"을 수집합니다. 만약 사용자가 "결제 게이트웨이가 다운되었습니다"라고 말한다면, Triage Agent는 단순히 티켓을 생성하는 데 그치지 않습니다. 자동으로 모니터링 시스템에 쿼리를 날려 5xx 에러를 확인하고, 그 타이밍을 최근의 변경 사항과 상관 분석(correlate)합니다.

Resolution Agent (해결 에이전트)

Triage Agent가 문제를 정의하고 나면, Resolution Agent가 업무를 인계받습니다. 이 에이전트는 "실행자(doer)"입니다. 이 에이전트는 특정 도구 세트(Action Space, 실행 공간)에 접근할 수 있습니다. 결제 게이트웨이 문제의 경우, 포드(pod)를 재시작하는 스크립트를 호출하거나 특정 카나리 배포(canary deployment)의 롤백(rollback)을 트리거할 수 있습니다. 이 에이전트는 Plan-Act-Observe (계획-실행-관찰) 루프 내에서 작동하며, 루프를 종료하기 전에 해당 조치가 실제로 텔레메트리 급증(telemetry spike)을 해결했는지 검증합니다.

Governance Agent (거버넌스 에이전트)

이것은 CTO에게 가장 중요한 구성 요소입니다. Governance Agent는 가드레일(guardrail) 역할을 하며, Resolution Agent가 제안한 조치들을 가로챕니다. 이 에이전트는 해결 방법에는 관심이 없으며, 오직 정책(policy)에만 집중합니다.

Resolution Agent가 데드락(deadlock)을 해결하기 위해 데이터베이스 재시작을 제안하는 시나리오를 가정해 봅시다. Governance Agent는 현재 캘린더를 확인하고, 주요 공휴일 주말을 위한 "운영 동결(Production Freeze)" 상태임을 확인합니다. 에이전트는 해당 조치를 차단하고, 긴급 변경 자문 위원회(CAB, Change Advisory Board)의 승인을 받도록 요청을 재라우팅합니다.

Multi-Agent ITSM Orchestration Topology (멀티 에이전트 ITSM 오케스트레이션 토폴로지)

Architecture map showing the flow of a request through a Triage Agent, a Governance Agent for policy checks, and an Execution Agent for tool invocation. 교차 분석을 통해 자율적인 근본 원인 분석(Root Cause Analysis, RCA)을 수행합니다. 로그에서 발생한 500 에러를 CI/CD 파이프라인의 특정 커밋 해시와 연관 지음으로써, 트리아지 및 해결 에이전트가 회귀(regression)를 유발한 정확한 변경 사항을 식별할 수 있습니다. 이들은 추측하지 않고 텔레메트리 데이터를 종합합니다. 이는 엔터프라이즈용 멀티 에이전트 오케스트레이션 패턴의 실질적인 응용 사례입니다.## 액션 공간(Action Space) 정의 및 통합 패턴(Integration Patterns)어떻게 에이전트가 레거시 환경에서 실제로 무언가를

우리는 에이전틱 AI (Agentic AI)를 오케스트레이션 미들웨어 (Orchestration Middleware)로 취급합니다. 에이전트는 ServiceNow나 Jira Service Management (JSM)를 대체하는 것이 아니라, 이들을 구동합니다.

1. 사용자 인터페이스 (The User Interface): 사용자는 Slack, Teams 또는 포털을 통해 상호작용합니다.
2. 오케스트레이션 계층 (The Orchestration Layer): 멀티 에이전트 시스템 (Multi-agent system)이 요청을 처리합니다.
3. 기록 시스템 (The System of Record): 에이전트가 JSM 또는 ServiceNow의 티켓을 실시간으로 업데이트합니다.

"직원 온보딩 (Employee Onboarding)" 요청을 예로 들어보겠습니다. 전통적인 설정에서는 이 요청이 5개의 서로 다른 팀으로 라우팅되는 5개의 티켓 체인으로 이어집니다. 에이전틱 설정에서는 단일 요청이 에이전트 체인을 트리거합니다:

• ID 에이전트 (Identity Agent): 클라우드 액세스를 프로비저닝 (Provisioning)하고 이메일 계정을 생성합니다.
• 하드웨어 에이전트 (Hardware Agent): ERP 시스템에서 조달 요청을 트리거합니다.
• 액세스 에이전트 (Access Agent): 사용자의 역할에 따라 올바른 AD 그룹에 사용자를 할당합니다.

에이전트는 단순히 "이메일을 보내는" 것이 아닙니다. API를 호출하고, 성공 코드 (Success code)를 확인하며, 확인 ID (Confirmation IDs)와 함께 마스터 온보딩 티켓을 업데이트합니다.

신뢰 프레임워크 (The Trust Framework): HITL 및 검증 가능한 감사 추적 (Verifiable Audit Trails)

사람의 확인 없이 새벽 3시에 AI 에이전트가 운영 데이터베이스 (Production database)를 재시작하도록 허용하시겠습니까? 아마 아닐 것입니다. 하지만 신뢰 점수 (Confidence score)가 99%이고 영향 범위가 비임계 마이크로서비스 (Non-critical microservice)로 제한된다면 허용할 수도 있습니다.

여기에서 "신뢰 사다리 (Trust Ladder)"가 등장합니다. 수동 방식에서 자율 방식으로 한 번에 도약하는 것이 아닙니다. 점진적으로 증가하는 자율성의 사다리를 올라가는 것입니다.

ITSM 신뢰 사다리: 자율성으로의 진행 (The ITSM Trust Ladder: Progression to Autonomy). 위험 허용도 (Risk tolerance) 및 검증을 기반으로 AI를 수동적인 조언자에서 자율적인 운영자 (Autonomous operator)로 전환하기 위한 CTO를 위한 프레임워크입니다.

1. 제안된 수정 (Suggested Fix): AI가 문제를 식별하고 명령어를 제안합니다. 사람은 이를 실행합니다.
2. 사람 승인 액션 (Human-Approved Action): AI가 액션을 준비합니다. 사람이 "승인 (Approve)"를 클릭합니다.
3. 알림을 동반한 자율 액션 (Autonomous Action with Notification): AI가 액션을 실행하고 즉시 사람에게 알립니다.
4. 완전 자율 (Full Autonomy): AI가 액션을 실행하고 기록하며, 액션이 실패하는 경우에만 사람에게 경고를 보냅니다.

경계 보호 (Guarding the Perimeter)

이를 구현하기 위해서는 두 가지가 필요합니다: 인간 참여형 (Human-in-the-Loop, HITL) 트리거와 불변 로그 (Immutable logs)입니다.

HITL 트리거는 위험 임계값 (Risk thresholds)을 기반으로 합니다. "Tier 0" 서비스를 수정하거나 동결 기간 (Freeze window) 중에 발생하는 모든 액션은 반드시 수동 승인을 트리거해야 합니다. 이는 AI가 "디스크 공간 확보"를 시도하는 동안 실수로 운영 볼륨 (Production volume)을 삭제하는 일을 방지하기 위함입니다.

또한, 검증 가능한 감사 추적 (Audit trail)을 유지해야 합니다. 에이전트가 수행하는 모든 사고 과정 (Thought), 액션 (Action), 관찰 (Observation)은 변경할 수 없는 방식으로 기록되어야 합니다. 만약 에이전트가 장애를 유발하는 구성 변경 (Configuration change)을 수행했다면, AI가 무슨 일이 일어났는지 "요약"하게 해서는 안 됩니다. LLM의 추론 (Reasoning)에 대한 원시 트레이스 (Raw trace)와 에이전트가 호출한 정확한 API 호출 (API call) 정보가 필요합니다. 이것이 기업 거버넌스를 위한 불변 로그 구축 (building immutable logs for enterprise governance)의 토대입니다.