AI 에이전트가 ERP/CRM/HRIS에서 제대로 작동하지 않는 진짜 이유와 3단계 성숙 모델

• AI 에이전트가 ERP/CRM/HRIS 등의 기간 시스템(Core Systems)과 연동할 때의 아키텍처(Architecture) 상의 과제
• 시스템의 API 설계, 액세스 권한, 데이터 정합성, 감사(Audit)의 현실적인 문제
• 단계적으로 자율성을 높이는 「Read → Recommend → Act」 성숙 모델
• 이벤트 기반 설계(Event-driven design)와 API 파사드(API Facade)를 통한 구현 접근 방식
• CIO/COO/CHRO/변혁 리더가 질문해야 할 체크 관점

경리 팀이 월간 결산을 자동화하는 AI 에이전트를 도입했다고 가정해 보자. 에이전트는 송장을 읽고, 발주서와 대조하며, 불일치를 검출한다. 여기까지는 순조롭다. 하지만 다음에 입고가 완료되었는지, 공급업체가 활성 상태인지, 송장이 지급 보류 워크플로우(Workflow)에 들어가 있는지 확인하려고 하는 순간, 에이전트는 멈춰버린다.

이것은 AI 모델의 성능 문제가 아니다. 아키텍처(Architecture)의 문제다.

ERP, CRM, HRIS와 같은 기간 시스템은 단순한 '쿼리 가능한 거대 데이터베이스'가 아니다. 이것들은 업무 상태의 공식 기록이며, 모든 트랜잭션(Transaction)은 검증되고 제어된다. 에이전트가 그 상태를 이해할 수 없다면 제대로 된 판단을 내릴 수 없다. 하지만 대부분의 기간 시스템은 표준화와 트랜잭션 제어를 위해 설계되어 있으며, 동적이고 반자율적인 상호작용을 상정하고 있지 않다.

결과적으로 유망한 에이전트 PoC(Proof of Concept)는 벽에 부딪힌다. CIO는 아키텍처 문제로 본다. COO는 프로세스 설계 문제로 본다. CFO와 CHRO는 통제와 설명 책임(Accountability)의 문제로 본다. 모두가 옳다.

Read(읽기)부터 Act(실행)까지의 단계적 접근 방식이 엔터프라이즈 기간 시스템에서의 실천적인 경로를 제시한다

에이전트가 실제 업무를 처리하려고 할 때 어떤 일이 일어나는지 살펴보자.

많은 기간 시스템은 여전히 배치 처리(Batch processing)나 느린 포인트 투 포인트(Point-to-point) 통합에 의존하고 있다. API가 존재하더라도 인간이 조작하는 구조화된 애플리케이션을 위해 설계되어 있으며, 에이전트가 여러 엔드포인트(Endpoint)를 순차적으로 호출하고, 정책 검증에서 일시 중지하며, 승인 후에 재개하는 동작을 상정하고 있지 않다.

기간 시스템의 권한은 인간의 역할(Role)을 위해 정의되어 있다. '디지털 워커(Digital Worker)'에게 좁은 범위의 권한을 부여하도록 설계되어 있지 않다. 결과적으로 기업은 에이전트에게 과도한 권한을 부여하거나, 아예 부여하지 않거나의 양자택일을 강요받는다.

실제 업무 규칙은 ERP나 CRM 안에만 존재하는 것이 아니다. 스프레드시트, 로컬 SOP, 이메일, 지식 베이스, 문서화되지 않은 운영 습관 등에 산재해 있다. 기간 시스템에만 접속한 에이전트는 항상 컨텍스트(Context)를 오해한다.

결론: 시스템이 준비되어 있다는 전제는 거의 항상 틀렸다.

가장 흔한 실수는 에이전트에게 갑자기 트랜잭션 실행을 허용하는 것이다. 훨씬 건전한 접근 방식은 단계적이다. 이 모델은 단순한 기술 로드맵이 아니라 리스크 관리, 신뢰 구축, 운영 모델 성숙의 수단이기도 하다.

개요: 읽기 전용(Read-only) 액세스부터 시작한다. 에이전트의 역할은 트랜잭션 컨텍스트의 이해, 예외 검출, 상태 요약, 인사이트 및 우선순위 제시로 한정한다.

구현 예시:

• 경리: 원장 데이터, 대조 상태, 예외 이력을 읽어 결산 지연 리스크가 있는 계정을 플래그(Flag) 지정
• 구매: 조달 의뢰, 공급업체 상태, 계약, 구매 이력을 읽어 적절한 구매 경로 안내
• 고객 운영(Customer Operations): 유인 대응 전에 케이스 요약(Case summary)을 준비
• HR: 온보딩(Onboarding) 정체를 선제적으로 통지

비즈니스 가치: 데이터 검색 시간 단축, 예외 우선순위 지정, 수동 핸드오프(Hand-off) 감소. 단, 읽기만으로는 비용 구조가 바뀌지 않는다. 의사 결정이나 트랜잭션 생성은 여전히 인간이 필요하다.

개요: 에이전트는 읽기뿐만 아니라 트랜잭션 초안 작성, 워크플로우 요청 생성, 액션 권장 사항 작성, 다음 단계 트리거를 수행한다. 단, 모든 사항은 인간의 승인이 필요하다.

구현 예시:

• 매입채무: 송장 불일치를 검출하고 근본 원인 분석을 준비하며, 해결 케이스를 초안으로 작성하여 검토로 넘김
• 영업: 어카운트 매니저(Account Manager)에게 차선책을 준비하고, 상담 업데이트 초안을 작성
• HRIS: 직원 데이터 변경 초안을 작성하지만, 승인은 HR 또는 라인 관리자가 수행
• IT 운영: 텔레메트리(Telemetry)를 수집하고 근본 원인을 제안하며, 런북(Runbook) 액션을 준비하지만 엔지니어가 승인

주의사항: 승인 워크플로우(Approval Workflow)가 빈약하면, 병목 현상이 '데이터 검색'에서 '에이전트 초안 승인 대기'로 옮겨갈 뿐이다. 승인은 정말로 필요한 액션에만 한정해야 하며, 충분한 컨텍스트(Context)와 명확한 SLA(Service Level Agreement)를 설정해야 한다.

개요: 가장 성숙한 단계. 에이전트가 핵심 시스템(Core System) 내에서 직접 액션을 실행할 수 있다. 키워드는 **경계 설정(Bounded)**이다. 무제한적인 트랜잭션(Transaction) 생성이 아니라, 특정 시나리오, 명확한 정책 및 임계값, 완전한 로그, 롤백(Rollback) 또는 보상 액션(Compensating Action), 동작 이탈 시의 킬 스위치(Kill Switch)를 갖춘 제한된 자율성을 의미한다.

실행 가능한 예시:

• 고객 서비스: 티켓 상태 업데이트, 표준 커뮤니케이션 전송, 정책 범위 내의 소액 주문 변경
• 채권 관리: 자동 후속 조치(Follow-up) 전송, 지불 확약 리마인더 생성
• IT 운영: 특정 서비스 재시작 등 저위험 복구 작업
• 구매: 고도로 표준화된 카테고리의 발주서 초안 작성

절대로 Stage 3로 만들어서는 안 되는 영역:

• 중요한 재무 관리 (예: 재료 분개 전기)
• 고액의 공급업체 마스터 변경
• 직원 보상 결정
• 신용 승인
• 고액의 고객 정책 변경

이러한 영역은 훨씬 더 오랫동안 인간을 루프(Human-in-the-loop)에 남겨두어야 한다.

많은 초기 에이전트 구현은 수동적이다. 사용자가 질문하거나 버튼을 눌렀을 때만 동작한다. 이는 코파일럿(Copilot)으로서는 문제가 없지만, 에이전트 운영 모델로서는 업무 변화에 따라 능동적으로 동작하는 패턴이 훨씬 더 강력하다.

에이전트는 다음과 같은 시그널을 받았을 때 가장 효과적으로 동작한다:

• 주문 변경
• 티켓 에스컬레이션(Escalation)
• 송장 기한 초과
• 결제 실패
• 재고 예외
• 직원 온보딩 지연
• 출하 리스크

이벤트 버스(Event Bus): 엔터프라이즈 시스템이 운영 이벤트를 공유 플랫폼에 공개하고, 에이전트가 관련 있는 것만 구독(Subscribe)한다.

변경 데이터 캡처 (CDC, Change Data Capture): 네이티브 이벤트(Native Event)를 사용할 수 없는 경우, 트랜잭션 데이터의 변경 사항을 캡처한다.

이벤트 주도 설계(Event-driven Design)는 **가시성(Observability)**도 향상시킨다. 모든 트리거, 판단, 액션이 추적 가능한 이벤트 체인(Event Chain)이 된다: 이벤트 발생 → 에이전트 기동 → 추가 데이터 취득 → 정책 체크 → 액션 실행 또는 에스컬레이션. 운영, 리스크, 감사 팀에게 있어 이는 에이전트가 백그라운드에서 조용히 동작하는 것보다 훨씬 더 건전한 방식이다.

기업이 움직이지 못하는 이유 중 하나는 "모든 핵심 시스템을 현대화(Modernize)한 후에야 에이전트를 사용할 수 있다"는 전제 때문이다. 그것은 비현실적이다. 더 나은 접근 방식은 우선순위가 높은 유스케이스(Use Case)에 기반한 **선택적 현대화(Selective Modernization)**이다.

레거시 시스템(Legacy System)이 변경하기 어려운 경우, 그 앞에 API 파사드(API Facade) 또는 서비스 레이어를 구축한다. 이를 통해:

• 복잡성 단순화
• 스키마(Schema) 정규화
• 에이전트가 할 수 있는 일 제한
• 스크린 스크레이핑(Screen Scraping) 또는 데이터베이스 직접 액세스 방지

에이전트는 절대 다음과 같은 행동을 해서는 안 된다:

• UI를 클릭하여 조작하기
• 핵심 테이블에 직접 쿼리(Query) 실행하기
• 일부 인간만이 이해하는 숨겨진 로직에 의존하기

API 파사드는 거버넌스(Governance)도 지원한다. 에이전트는 검증되고, 정책이 적용되며, 완전히 로그가 기록되고, 필요에 따라 중단할 수 있는 서비스를 통해서만 상호작용하도록 결정할 수 있다.

에이전트를 핵심 시스템에 연결하는 것은 단순한 미들웨어 프로젝트가 아니다. 에이전트가 ERP, CRM, HRIS에 닿는 순간, 거버넌스의 영향이 즉시 표면화된다.

Read(읽기), Recommend(권고), Act(실행)의 경계는 형식적으로 정의되어야 한다. 각 팀이 자율성 수준을 개별적으로 결정하게 해서는 안 된다.

에이전트의 액션은 핵심 시스템의 트랜잭션 로그와 에이전트의 판단 로그가 서로 연결되어야 한다.

에이전트가 핵심 시스템에서 읽기와 실행을 수행하게 되면, 인간의 업무는 데이터 입력이나 상태 확인에서 예외 처리, 승인, 정책 개선으로 전환된다.

CIO에게: 디지털 코어(Digital Core)는 에이전트 실행 플랫폼으로서 기능할 준비가 되어 있는가? 아니면 접근하기 어려운 기록 관리 시스템으로 남아 있는가?

COO에게: 어떤 프로세스에서 진짜 병목 현상은 사람이 아니라, 핵심 시스템으로부터의 업무 상태에 대한 액세스 지연인가?

CHRO에게: 에이전트가 HRIS (인적자원정보시스템)에서 데이터를 읽고 워크플로우 (Workflow)를 실행하기 시작할 때, 어떤 역할이 관리 (Management)에서 모니터링 및 예외 관리 (Exception Management)로 전환되는가?

변혁 리더에게: 로드맵이 고가치 유스케이스 (High-value Use Case)와 현실적인 통합 능력에서 시작되고 있는가? 아니면 인상적인 AI 데모와 준비되지 않은 핵심 시스템 (Legacy Systems) 사이에서 끼어 있는 상태인가?

이러한 질문에 대한 답이 아직 명확하지 않다면, 다음 우선순위는 에이전트의 수를 늘리는 것이 아니다. 에이전트와 핵심 시스템 사이의 안전한 경로를 명확히 하는 것이다. 거기서부터 진정한 에이전트형 엔터프라이즈 (Agentic Enterprise)가 시작된다.