에이전트 구동형 공유 서비스 재설계: 운영 모델, API 및 거버넌스 구현 지침

공유 서비스(회계・인사・IT 지원)에 AI 에이전트를 도입할 때, 단순히 챗봇을 추가하는 것이 아니라, 운영 모델 자체를 '인간 + 에이전트'의 협조형으로 재설계하는 방법을 설명합니다. 특히 아키텍처 설계, API 연동, 권한 관리, 감사 로그, 운영 평가 등 엔지니어 관점에서 구현에 적용할 포인트를 정리했습니다.

공유 서비스는 다음 3가지 측면에서 에이전트화에 적합합니다.

• 고볼륨 및 패턴화된 업무: 회계의 청구서 처리, 인사 문의, IT의 비밀번호 재설정 등 대량의 반복 업무가 존재합니다. - 분해 가능한 프로세스 구조: 요청 접수 → 의도 분류 → 시스템 검색 → 정책 체크 → 대응 결정 → 실행/에스컬레이션과 같은 단계로 분해할 수 있습니다. - 기존 운영 데이터 기반: ERP, HRIS, ITSM, 지식 베이스(Knowledge Base), SOP가 이미 존재합니다.

다만 중요한 것은 '자동화가 쉽기 때문'이 아니라, '운영 모델을 재설계하기에 충분한 풍부함(richness)이 있기 때문'입니다. 단순히 공수 절감(工数削減)이 목적이라면, 가장 안전한 좁은 유스케이스(use case)만 자동화하고 끝날 것입니다. 그러면 서비스 품질은 변하지 않습니다.

기존의 공유 서비스는 사람이 티켓을 큐에서 꺼내 여러 시스템을 가로질러 컨텍스트를 수집하고 판단하는 인간 중심의 플로우였습니다. 에이전트 구동형에서는 이 플로우를 다음과 같이 재설계합니다.

이 3개 계층을 **서비스 카탈로그(Service Catalog)**로 정의하고, 각 서비스에 다음 설계 정보를 연결합니다.

• 트리거 조건: 어떤 요청이 어느 계층으로 라우팅될지 - API 연동처: 참조/업데이트할 시스템 (ERP, HRIS, ITSM 등) - 권한 스코프(Scope): 에이전트가 실행 가능한 작업의 범위 - 폴백 조건(Fallback Condition): 인간에게 인계해야 할 임계치 (신뢰도, 리스크 레벨)

에이전트가 여러 시스템을 가로지르려면 다음 API 설계가 전제됩니다.

• 에이전트가 사용자 정보, 정책, 트랜잭션 이력을 가져올 수 있는 읽기 전용 엔드포인트
  예: GET /api/v1/employees/{id}/leave-balance,
  GET /api/v1/invoices/{id}/status

• 주의점: 에이전트가 얻은 데이터의 신선도를 보장하기 위해 캐시 전략과 레이트 제한(Rate Limit)을 설계해야 합니다.

• 에이전트가 실제로 작업을 실행할 수 있는 엔드포인트
  예: POST /api/v1/password-reset,
  PATCH /api/v1/invoices/{id}/approve

• 필수 설계: Idempotency(멱등성, 동일 요청의 중복 실행 방지), 트랜잭션 관리(부분 업데이트의 롤백)

• 모든 에이전트 작업을 추적 가능하게 합니다
  예: POST /api/v1/audit-log (에이전트가 호출), GET /api/v1/audit-log?agent_id=xxx

• 기록해야 할 항목: - 요청 출처 (사용자 ID, 에이전트 ID) - 호출한 API와 파라미터 - 실행 결과 (성공/실패/에러 코드) - 인간 개입 시의 타임스탬프와 판단 내용

에이전트에게 부여하는 권한은 **최소 권한의 원칙(Principle of Least Privilege)**을 따르며, 다음 세분화된 수준으로 설계합니다.

흔히 하는 오해는 '폴백(fallback)을 피해야 한다'는 생각입니다. 실제로는, 폴백은 중요한 제어 메커니즘입니다. 다음 조건에서 사람에게 인계하도록 설계합니다.

• 데이터가 부족한 경우
• 정책이 충돌하는 경우
• 에이전트의 신뢰도가 낮은 경우
• 리스크 평가가 임계치를 초과한 경우
• 사용자가 에이전트의 결과를 거부한 경우

폴백을 적절하게 설계하지 않으면, 에이전트가 무리하게 해결하려다 높은 비용의 실수를 저지르거나, 반대로 너무 보수적이 되어 모든 것을 사람에게 맡기게 되어 투자 대비 효과(ROI)가 사라집니다.

에이전트를 도입한 효과를 측정하기 위해서는 기존의 '티켓 처리 수'가 아니라, 다음 지표들을 채택해야 합니다.

• 오류율 (Error Rate): 에이전트가 잘못 처리한 비율 (감사 로그에서 추출)
• 규정 준수 위반 건수 (Compliance Violation Count): 정책 위반이 발생한 케이스
• 사용자 만족도 (User Satisfaction Score): 에이전트 대응 후 설문조사 점수
• 신뢰도 지표 (Trust Metric): 에이전트의 권장 사항에 대한 인간의 수용률, 오버라이드율

공유 서비스가 에이전트화할 준비가 되었는지 여부는 다음 관점에서 평가합니다.

• 프로세스가 문서화되어 있는지(SOP, 플로우차트)
• 지식 기반(Knowledge Base)이 최신이고 모순이 없는지
• 각 시스템의 API가 안정적으로 제공되는지
• 서비스 오너(Service Owner)가 명확하게 정의되었는지
• 현재 KPI가 '티켓 처리 수'가 아니라 '해결 품질'을 측정하고 있는지

이러한 조건들이 충족되지 않은 환경에 에이전트를 도입하면, 오래된 혼란 위에 새로운 레이어를 추가하는 것에 불과합니다.

경영진이 결정해야 할 것은 '어떤 챗봇을 구매할지'가 아닙니다. 다음 세 가지입니다.

어떤 서비스를 에이전트 실행형으로 만들 것인가
어떤 서비스를 에이전트 지원형으로 만들 것인가
어떤 서비스를 인간 실행형으로 남겨둘 것인가

이 결정이 서비스 카탈로그, 에스컬레이션 모델, KPI, 책임 구조(Accountability Structure)를 변화시킵니다. 공유 서비스를 사람만의 티켓 처리 기계로 계속 설계한다면, 에이전트는 구 모델의 장식품에 지나지 않습니다. 결과 지향적으로 서비스를 재설계하면, 인간과 에이전트는 하나의 운영 시스템으로 기능합니다.