AI 에이전트의 정밀도는 데이터 기반에 의해 결정된다 — 실운영에서 '그럴듯한 오류'를 방지하는 3계층 아키텍처

• AI 에이전트가 실운영에서 실패하는 진짜 원인 (모델이 아닌 데이터)
• 「그럴듯한 오류 (operational hallucination)」의 정체와 그 영향
• 구조화 데이터 및 비구조화 데이터 각각에 요구되는 6가지 특성
• 런타임 (Runtime)에서 실행되는 거버넌스 및 권한 제어 설계
• 프로토타입에서 본산 스케일로 이전하기 전에 확인해야 할 체크리스트

어느 기업의 재무 팀이 결산 업무를 지원하는 AI 에이전트를 개발했다. ERP에 접속하여 분개를 읽고, 대조 작업의 초안을 생성한다. 데모에서는 모든 것이 아름답게 작동했다.

하지만 실제 월간 결산이 시작되자 상황은 급변했다. 에이전트는 송장(Invoice)의 상태를 오독하고, 잘못된 계정 과목을 추천하며, 이미 해결된 예외 사항을 에스컬레이션(Escalation)했다. 팀은 주말을 소비하며 모든 것을 처음부터 다시 확인해야 했다.

무엇이 잘못되었을까? 모델이 아니다. 에이전트 프레임워크도 아니다. 문제는 데이터였다.

많은 기업이 "어떤 모델을 선택할지", "어떤 에이전트 플랫폼을 채택할지", "워크플로우를 어떻게 오케스트레이션 (Orchestration)할지"에 집중한다. 하지만 엔터프라이즈 (Enterprise) 맥락에서 모델은 점점 커모디티화 (Commodity)되고 있다. 구매하거나 복제할 수 없는 것은 바로 **자사의 컨텍스트 (Context)**다. "고객"의 정의, 승인 체인의 구조, 정책 예외 처리, 비즈니스 엔티티 (Entity) 간의 관계성 — 이 모든 것은 데이터 기반에 의존한다.

강고한 데이터 기반이 없다면, 에이전트는 자신만만하게, 그리고 틀린 답을 내놓는다. 그럴듯해 보이지만 실제 비즈니스 규칙을 무시한 권장 사항을 수행한다. 이것은 모델의 환각 (Hallucination)이 아니다. 운영 측면에서 훨씬 더 위험한, **오퍼레이셔널 할루시네이션 (operational hallucination, 운영적 환각)**이다.

데모용 에이전트와 본산용 에이전트를 나누는 3가지 계층: 데이터 기반, 실행 계층, 거버넌스 런타임

AI의 환각 (Hallucination)에 대해서는 자주 논의된다. 모델이 사실에 기반하지 않은 정보를 생성하는 문제다. 하지만 엔터프라이즈 환경에서는 더 까다로운 문제가 발생한다. 그것이 바로 **오퍼레이셔널 할루시네이션 (operational hallucination)**이다. 에이전트의 출력은 그럴듯하지만, 실제 비즈니스 상태에 대해서는 틀려 있다.

• 재무 에이전트가 "송장은 미결제 상태"라고 보고한다 — 하지만 ERP의 상태는 이미 변경되었다.
• HR 에이전트가 6개월 전에 폐지된 휴가 정책을 인용한다.
• 공급망 (Supply Chain) 에이전트가 실제 재고 제약을 이해하지 못한 채 운송 경로를 변경한다.

문제는 단순한 정확성만이 아니다. 에이전트가 행동, 우선순위, 의사결정에 영향을 미치기 시작한다는 점이다. 잘못된 답변이 나올 때마다 재작업, 지연, 컴플라이언스 (Compliance) 리스크가 발생한다.

이것이 성공적인 파일럿과 실패한 본산 롤아웃 (Rollout)의 차이가 대부분 대화 품질이 아닌 **데이터 준비성 (Data Readiness)**에 있는 이유이다.

에이전트가 엔터프라이즈 시스템에서 행동하기 위해서는 — 상태를 확인하고, 조건을 검증하며, 워크플로우를 트리거 (Trigger)하기 위해서는 — 구조화 데이터에 의존한다. 고객 레코드, 주문, 송장, 공급업체 마스터, 직원 프로필, 계약, 티켓 등이다.

하지만 ERP나 CRM을 도입하고 있다고 해서 데이터가 에이전트 대응이 완료되었다는 뜻은 아니다. 구조화 데이터에는 다음과 같은 6가지 특성이 필요하다.

"활성 고객"이란 무엇인가? 주문이 "완료"되는 시점은 언제인가? 기능이나 국가에 따라 정의가 다르면 에이전트는 일관성 없는 판단을 내린다.

모든 데이터 도메인에는 단순한 기술 관리자가 아닌 **비즈니스 오너 (Business Owner)**가 필요하다. 오너십 (Ownership)이 없다면 데이터 품질 문제는 "시스템 문제"로 라벨링되고, 에이전트는 계속해서 실패할 것이다.

에이전트는 데이터의 출처를 알 필요가 있다. 대시보드의 필드가 다층적인 변환을 거치고 있다면, 에이전트가 현재의 비즈니스 상태를 올바르게 읽고 있다고 보장할 수 있는가?

완전성, 유일성, 일관성, 적시성 — 이것들은 가정해서는 안 된다. 중복된 벤더 마스터나 시대에 뒤떨어진 조직도는 에이전트의 워크플로우를 파괴한다.

데이터에는 시스템 간에 전달되는 의미가 필요하다. 여기서 엔터프라이즈 데이터 모델과 마스터 데이터 관리 (MDM)가 중요해진다.

에이전트는 코어 테이블에 직접 액세스해서는 안 된다. 권한을 강제하고, 감사 추적 (Audit Trail)을 유지하며, 안정적인 스키마 (Schema)를 제공하는 **인터페이스 (Interface)**가 필요하다.

# 나쁜 예: 에이전트가 테이블을 직접 쿼리
agent.query("SELECT * FROM invoices WHERE status = 'unpaid'")
# 좋은 예: API 게이트웨이를 통해 권한과 감사를 강제
...

많은 조직은 에이전트를 구축하기 시작한 후에야 비구조화 데이터 (Unstructured Data)의 가치를 깨닫는다. 정책, 계약, 이메일, 통화 기록, SOP, 지식 문서(Knowledge Article) — 이들은 수동적인 아카이브였다. 에이전틱 AI (Agentic AI)에서 이것들은 **액티브 컨텍스트 계층 (Active Context Layer)**이 된다.

고객의 티켓 상태는 CRM에 있지만, 실제 컨텍스트 — 고객에게 약속한 내용, 감정적인 톤, 근본 원인 — 는 통화 기록이나 채팅 이력에 있다. 공급업체 마스터 데이터는 깨끗할지라도, 상거래 조건이나 계약 예외 사항은 PDF에 있다. 직원 데이터는 HRIS에 있지만, 로컬 정책이나 FAQ의 예외 사항은 포털이나 이메일에 있다.

비구조화 데이터에는 단순한 "벡터 스토어 (Vector Store)에 문서 업로드"가 아닌, **규율 있는 파이프라인 (Disciplined Pipeline)**이 필요하다.

신뢰할 수 있는 소스로부터의 제어된 수집 / 정책과 초안을 분리하는 분류 / 메타데이터를 포함한 지능형 청킹 (Intelligent Chunking) / 권한과 컨텍스트를 존중하는 검색 / 만료된 문서를 활성화하지 않는 라이프사이클 관리 (Lifecycle Management)

유혹은 "어쨌든 전부 다 집어넣는 것"이다. 이에 저항하라. 공식 SOP, 활성 계약, 검증된 지식 문서, 큐레이션된 정책 문서 — **고가치이며 권위 있는 코퍼스 (Corpus)**부터 시작하라. 회사가 지금까지 작성한 모든 파일을 대상으로 해서는 안 된다.

전통적인 데이터 거버넌스 (Data Governance)는 문서, 위원회, 수동 제어 수준에서 멈춰 있었다. 에이전틱 AI에서 거버넌스는 런타임 (Runtime)에서 실행되어야 한다.

질문은 "누가 이 데이터에 접근할 수 있는가?"에서 "누가 에이전트를 통해, 어떤 목적으로, 어떤 워크플로우에서, 어느 정도의 자율성으로 이 데이터에 접근할 수 있으며, 그 접근이 인사이트인가 액션인가?"로 바뀐다.

권한은 검색 시점에 체크한다. 답변 생성 후가 아니다. HR 에이전트는 허가되지 않은 사용자에게 보상 데이터를 추출해서는 안 된다. -
감사 추적 (Audit Trail)은 "무엇이 접근되었는가"뿐만 아니라, "어떤 데이터가, 어떤 소스로부터, 어떤 권한으로, 어떤 워크플로우에서, 어떻게 에이전트의 판단에 영향을 미쳤는가"를 설명해야 한다. -
에이전트가 잘못된 권장 사항을 제시했을 때, 문제가 데이터 품질, 잘못된 검색, 누락된 메타데이터, 혹은 미이행된 정책 중 어디에 있는지 추적할 수 있어야 한다.

# 거버넌스 런타임 설정 예시 (개념)
governance_rules:
- data_domain: "employee_compensation"
...

파일럿과 실운영의 차이는 데이터 준비성에 있다. 에이전틱 AI의 발자국을 넓히기 전에 다음을 확인하라.

• 우선순위 데이터 도메인에 일관된 비즈니스 정의가 있는가

• 고객, 공급업체, 직원, 송장 데이터에 명확한 소유자 (Owner)가 있는가

• 데이터 품질 (완전성, 일관성, 적시성)이 모니터링되고 있는가

• 에이전트가 권한을 강제하는 인터페이스를 통해 데이터에 접근하고 있는가

• 코퍼스가 큐레이션되어 있으며 초안과 구별되어 있는가

• 버전, 유효일, 지역, 분류 등의 메타데이터가 존재하는가

• 검색이 소스 시스템과 일관된 권한을 존중하는가

• 문서, 트랜스크립트, 상호작용 이력에 대한 보존 정책이 있는가

• 에이전트가 권장 사항을 수행하기 위해 사용한 데이터를 추적할 수 있는가

• 런타임에서 권한이 체크되는가

• 감사 추적이 "무엇을", "왜" 했는지 설명할 수 있는가

• "데이터는 나중에 정리하겠다"라고 말하고 있다

• 코어 마스터 데이터가 아직 부서 간에 논의 중이다

• 에이전트가 권한이 불분명한 문서에서 답변을 추출하고 있다

• 서비스 계정 (Service Account)이 과도하게 넓은 접근 권한을 가지고 있다

• 정책에 버전 메타데이터가 없다

• 검색이 사용자 권한을 무시하고 있다

이것들은 기술적 부채가 아니다. **스케일링의 블로커 (Scaling Blocker)**이다.

"어떤 모델을 사용할 것인가?"가 아니다.

"어떤 데이터가 우리의 진실된 소스(Source of Truth)인가? 그것을 누가 소유하고 있는가? 에이전트가 오직 현실에 기반하여 행동하도록 어떻게 보장할 것인가?"

이것이 프로토타입을 실운영으로 전환하는 유일한 질문이다.