ERP를 넘어 AI 에이전트 운영 체제로
출처: https://www.youtube.com/watch?v=uVD-6Q83uBI · 더존ICT그룹 · 30:51 · 2025-12-18
요지
- 기업의 AX는 개인이 AI 도구를 잘 쓰는 수준을 넘어, 조직이 AI를 공식적인 업무 수행자로 배치하는 단계로 나아가야 한다.
- 성공적인 AI 에이전트 도입에는 모델 성능보다 통합된 데이터, 문서화된 업무 지식, 기존 시스템과의 연결, 사람의 검토 체계가 더 중요하다.
- ERP·MES·SCADA·QMS·그룹웨어 등에 흩어진 데이터를 연결하는 데이터 패브릭이 전사 AI 운영의 기반이다.
- 업무 프로세스는 자료 수집·가공 중심에서 판단·승인·감독 중심으로 재설계해야 한다.
- 전문 에이전트들이 가치사슬을 따라 협업하고 사람이 주요 통제 지점을 검토하면, 분석에서 실행까지 이어지는 지능형 운영 체제를 만들 수 있다.
- AX의 효과를 기업 성과로 연결하려면 시스템 도입과 함께 직무와 조직 구조도 재설계해야 한다.
개요
전통적인 ERP는 재무·구매·생산 등 기업 활동을 표준화하고 기록하는 핵심 시스템이다. 그러나 실제 기업 데이터와 업무는 ERP 하나에만 존재하지 않는다. MES, SCADA, QMS, 그룹웨어, 공유 폴더, 클라우드, 개인 PC와 각종 레거시 시스템에 분산되어 있다. 이 상태에서는 좋은 AI 모델을 도입해도 조직 전체의 맥락을 이해하거나 실제 업무를 끝까지 수행하기 어렵다.
발표는 ERP를 단순한 기록·처리 시스템에서 AI 에이전트가 판단하고 실행하는 지능형 운영 체제로 확장해야 한다고 주장한다. 이를 위해서는 개인용 코파일럿 도입을 넘어 데이터 통합, 프로세스 재정의, 에이전트 간 협업, 휴먼 인 더 루프, 직무 재설계를 하나의 AX 프로그램으로 추진해야 한다.
배경 / 사전 지식
ERP(Enterprise Resource Planning)는 재무, 구매, 판매, 재고, 생산, 인사 등 기업의 주요 자원을 통합 관리하는 시스템이다. MES는 제조 실행, SCADA는 설비 감시·제어, QMS는 품질 관리를 담당한다. 기업마다 이 시스템들의 구성과 연결 상태가 다르며, 연결이 부족하면 동일한 자료를 사람이 다시 입력하거나 여러 시스템에서 수작업으로 취합하게 된다.
과거의 RPA는 “A이면 B를 수행한다”와 같은 고정 규칙으로 반복 작업을 자동화했다. 입력 문서나 업무 절차가 조금만 바뀌어도 깨지기 쉬웠다. AI 기반 에이전트는 비정형 문서를 읽고 상황을 판단하며 여러 도구를 호출할 수 있어, 과거 RPA 후보였지만 구현하기 어려웠던 업무를 다시 자동화할 가능성을 연다.
AX(AI Transformation)는 AI 도구를 추가하는 데 그치지 않고 데이터, 프로세스, 시스템, 조직과 직무를 AI와 함께 일하도록 바꾸는 전환을 뜻한다. 여기서 에이전트는 목표를 받아 필요한 정보를 조회하고, 판단하고, 시스템을 조작하며, 결과를 보고하는 소프트웨어 업무 수행자다.
핵심 개념
개인의 AI 활용과 조직의 AI 도입
개인이 생성형 AI로 문서를 요약하거나 보고서를 작성하면 개인 생산성은 높아진다. 그러나 업무 자체의 책임과 흐름은 여전히 사람에게 남아 있다. 조직 차원의 도입에서는 구매 검토, 결산 분석, 품질 대응과 같은 업무를 조직이 에이전트에게 직접 할당한다. 이를 위해 AI를 공식적인 업무 수행자로 인정하고 권한, 입력, 산출물, 검토자와 책임 범위를 명시해야 한다.
데이터 패브릭
데이터 패브릭은 여러 시스템에 흩어진 데이터를 물리적으로 한곳에 모두 복사한다는 뜻만은 아니다. 공통 식별자, 메타데이터, 접근 규칙과 연결 계층을 마련해 필요한 데이터를 일관된 의미로 탐색하고 제공하는 구조다. ERP, MES, SCADA, QMS, 그룹웨어와 문서 저장소가 연결되어야 에이전트가 기업 전체의 맥락을 이용할 수 있다.
암묵지의 조직 지식화
많은 업무 절차는 매뉴얼보다 사수와 부사수 사이의 구전으로 전달된다. AI에게 일을 맡기려면 판단 기준, 예외 처리, 보고 방식과 승인 조건을 명시적인 지식으로 바꿔야 한다. 문서화된 규정은 RAG 같은 검색 기반 지식 제공 방식으로 연결할 수 있고, 업무 대상과 관계가 복잡하면 지식 그래프도 검토할 수 있다.
전문 에이전트와 멀티에이전트 협업
하나의 범용 에이전트가 모든 일을 처리하게 하기보다 품질, 생산, SCM, 재무처럼 역할과 권한이 제한된 전문 에이전트를 둔다. 이들이 표준 메시지와 상태를 주고받으며 가치사슬 전체의 워크플로를 완성한다. 예를 들어 품질 에이전트가 이상을 감지하면 생산 에이전트에 감속을 요청하고, SCM 에이전트가 관련 조달을 점검하며, 경영관리 에이전트가 보고서를 작성할 수 있다.
휴먼 인 더 루프
AI와 사람 모두 오류를 낼 수 있으므로 무조건적인 신뢰나 거부가 아니라 검토 가능한 통제 구조가 필요하다. 고위험 의사결정, 금액이 큰 거래, 외부 보고와 되돌리기 어려운 실행 앞에는 사람의 승인 지점을 둔다. 에이전트는 판단 근거, 사용한 데이터, 수행한 작업과 예외를 기록해 독립적인 검토가 가능해야 한다.
프로세스 중심과 협업 중심 설계
발표는 SAP 계열 접근을 통합 데이터 모델과 프로세스 중심, Microsoft Dynamics 365 계열 접근을 사용자 협업과 확장성 중심으로 대비한다. 중요한 점은 특정 제품의 우열이 아니라 기업의 산업, 규제, 작업 특성에 맞는 설계 철학을 먼저 정하는 것이다. 반복성과 통제가 중요한 조직은 프로세스 중심, 창의성과 유연한 협업이 중요한 조직은 협업 중심의 비중을 높일 수 있다.
직무 재설계
AI가 자료 수집과 분석만 줄여 주고 기존의 역할·책임·성과지표를 그대로 두면 기업 차원의 효과가 제한될 수 있다. 사람의 직무는 반복 처리자에서 예외 검토자, 의사결정자, 에이전트 감독자로 이동해야 한다. 장기적으로 IT 조직은 사람에게 시스템을 제공하는 역할에 더해 에이전트의 배치, 권한, 성능과 수명주기를 관리하게 된다.
작동 원리
- 먼저 현재 업무를 관찰해 수작업, 중복 입력, 대기 시간과 반복 판단 지점을 찾는다. 과거 RPA 검토 목록도 유용한 출발점이다.
- 자료 가공 중심의 절차를 의사결정 중심으로 다시 정의한다. 각 단계의 입력, 판단 기준, 예외, 산출물, 책임자와 승인 조건을 명시한다.
- ERP와 주변 시스템의 데이터 위치, 소유자, 품질과 식별자를 조사한다. 공통 의미 모델과 접근 계층을 만들어 데이터 패브릭을 구축한다.
- 업무를 작은 책임 단위로 나누어 전문 에이전트를 설계한다. 각 에이전트에는 최소 권한만 부여하고 호출 가능한 시스템과 행동 범위를 제한한다.
- 규정과 사례는 RAG로 제공하고, 운영 데이터는 API나 MCP 같은 표준 연결 방식으로 조회하게 한다. 중요한 값은 출처와 조회 시점을 함께 남긴다.
- 에이전트들이 표준화된 이벤트와 작업 상태를 주고받도록 오케스트레이션한다. 실패, 중복 실행, 시간 초과와 보상 작업도 설계한다.
- 금액, 위험도와 되돌릴 수 있는지에 따라 사람의 검토 지점을 둔다. 낮은 위험의 조회·초안 작성부터 시작해 검증된 범위만 자동 실행으로 확대한다.
- 정확도뿐 아니라 처리 시간, 재작업률, 예외율, 승인 반려율과 사업 성과를 측정한다. 결과에 맞춰 데이터, 프롬프트, 규칙, 권한과 직무를 함께 개선한다.
예를 들어 구매 요청이 이메일로 들어오면 접수 에이전트가 요청을 구조화하고, 공급업체·예산 정보를 ERP와 문서 시스템에서 조회한다. 검증 에이전트가 규정 위반과 위험을 판단한 뒤, 일정 금액 이상이면 담당자에게 승인을 요청한다. 승인된 건만 실행 에이전트가 발주하고 모든 근거와 결과를 감사 로그에 남긴다.
코드 예시
아래 코드는 외부 패키지 없이 실행할 수 있는 간단한 구매 승인 워크플로다. 실제 환경에서는 각 함수를 ERP API, 문서 저장소와 승인 시스템 호출로 교체해야 한다.
from dataclasses import dataclass
from enum import Enum
class Decision(Enum):
AUTO_APPROVE = "auto_approve"
HUMAN_REVIEW = "human_review"
REJECT = "reject"
@dataclass(frozen=True)
class PurchaseRequest:
request_id: str
vendor: str
amount: int
budget_remaining: int
vendor_risk: str
def validate(req: PurchaseRequest) -> Decision:
if req.amount <= 0 or req.amount > req.budget_remaining:
return Decision.REJECT
if req.vendor_risk != "low" or req.amount >= 10_000_000:
return Decision.HUMAN_REVIEW
return Decision.AUTO_APPROVE
def execute(req: PurchaseRequest, decision: Decision) -> dict:
# 실제 구현에서는 멱등성 키로 request_id를 전달해 중복 발주를 막는다.
if decision is Decision.AUTO_APPROVE:
return {"request_id": req.request_id, "status": "ordered"}
if decision is Decision.HUMAN_REVIEW:
return {"request_id": req.request_id, "status": "awaiting_approval"}
return {"request_id": req.request_id, "status": "rejected"}
def run_workflow(req: PurchaseRequest) -> dict:
decision = validate(req)
result = execute(req, decision)
return {
**result,
"decision": decision.value,
"evidence": {
"amount": req.amount,
"budget_remaining": req.budget_remaining,
"vendor_risk": req.vendor_risk,
},
}
if __name__ == "__main__":
request = PurchaseRequest(
request_id="PR-2025-001",
vendor="Example Parts",
amount=12_000_000,
budget_remaining=30_000_000,
vendor_risk="low",
)
print(run_workflow(request))
이 예시의 핵심은 AI가 모든 요청을 곧바로 실행하지 않는다는 점이다. 예산을 초과하면 거절하고, 고위험 공급업체나 큰 금액은 사람에게 넘기며, 자동 승인 범위에서만 실행한다. 또한 판단에 사용한 근거를 결과에 포함해 검토 가능성을 확보한다.
함정·실수
- 모델부터 선정한다: 데이터 위치와 업무 기준이 정리되지 않은 상태에서는 높은 성능의 모델도 신뢰할 만한 결과를 내기 어렵다. 프로세스와 데이터 진단을 먼저 수행한다.
- 개인용 챗봇을 전사 AX로 간주한다: 문서 작성 속도는 높아져도 조직의 업무 흐름은 바뀌지 않을 수 있다. 업무의 시작부터 실행·보고까지 책임 구조를 설계한다.
- 암묵지를 그대로 둔다: 담당자의 머릿속에만 있는 예외 규칙은 에이전트가 알 수 없다. 실제 사례와 반려 사유를 포함한 운영 지식으로 문서화한다.
- 모든 데이터를 무작정 한곳에 복사한다: 의미와 품질이 다른 데이터가 섞이면 혼란만 커진다. 공통 식별자, 데이터 계보, 소유권과 최신성 기준을 함께 관리한다.
- 완전 자율화를 한 번에 시도한다: 발주, 회계 처리와 설비 제어는 잘못 실행했을 때 손실이 크다. 조회, 추천, 초안 작성, 승인 후 실행 순서로 자동화 수준을 높인다.
- 에이전트의 판단 과정만 장황하게 저장한다: 자유 형식 추론문은 감사 근거가 되기 어렵다. 입력 출처, 적용 규칙, 도구 호출, 결정과 승인자를 구조화해 기록한다.
- 중복 실행과 장애 복구를 무시한다: 네트워크 재시도로 발주나 전표가 중복 생성될 수 있다. 멱등성 키, 상태 머신, 재시도 한도와 보상 작업을 둔다.
- 직무와 평가 체계를 그대로 둔다: AI가 업무 일부를 맡아도 사람에게 예전 산출물을 그대로 요구하면 이중 작업이 생긴다. 책임, 권한과 성과지표를 함께 개편한다.
베스트 프랙티스
- 가치, 구현 가능성, 데이터 준비도와 위험도를 기준으로 유즈 케이스를 평가하고 작은 범위의 파일럿부터 시작한다.
- 과거 RPA 후보 목록에서 비정형 판단 때문에 보류된 업무를 다시 검토하되, 자동화 자체보다 사업 성과를 기준으로 우선순위를 정한다.
- 에이전트 하나에 한정된 역할과 최소 권한을 부여하고, 업무 간 계약은 구조화된 입력·출력 스키마로 정의한다.
- 데이터 카탈로그, 계보, 품질 지표와 접근 통제를 데이터 패브릭의 필수 구성요소로 운영한다.
- 모든 실행에 요청 ID와 감사 로그를 남기고, 외부 보고나 금전·안전 관련 작업에는 명시적인 승인 단계를 둔다.
- 섀도 모드에서 사람의 판단과 에이전트 결과를 비교한 뒤 추천 모드, 승인 후 실행, 제한적 자동 실행 순으로 확대한다.
- 제조 현장에서는 예지보전이나 비전 검사처럼 측정 가능한 설비·품질 문제를 제한된 장비에 먼저 적용해 효과와 오탐을 검증한다.
- 정확도 외에도 처리 시간, 비용, 재작업, 장애, 사용자 채택률과 실제 손익 효과를 함께 추적한다.
- 시스템 설계와 동시에 사람이 맡을 예외 처리, 검토, 의사결정과 에이전트 운영 역할을 정의한다.
- 현재 AI 성능만으로 장기 유즈 케이스를 폐기하지 말고, 미래 적용을 가능하게 할 데이터와 업무 지식을 지금부터 축적한다.
참고
- 발표에서 비교 대상으로 언급한 AI 결합 ERP 생태계: SAP S/4HANA·Joule·BTP, Microsoft Dynamics 365·Copilot·Power Platform
- 에이전트와 기존 시스템을 연결하는 방식으로 MCP 언급
- 기업 지식을 제공하는 방식으로 RAG, 임베딩, 그래프 데이터베이스 언급
- 제조 분야 적용 사례: 생산 스케줄링, 산출량 예측, 예지보전, 현장 지원 봇, AI 비전 검사, 수요 예측과 조달 최적화
- 경영관리 적용 사례: 월말 결산, 계정 분류, 전표·증빙 분석, 보고서 생성, P&L 변동 분석과 롤링 포캐스트