「데이터는 있다. 나머지는 AI 에이전트에게 전달하기만 하면 된다」——이 생각이 실무 운영에서 가장 빈번하게 실패하는 원인입니다.

본 기사에서는 AI 에이전트가 안전하고 정확하게 동작하기 위해 필요한 데이터 프로덕트 (Data Product) 설계 원칙을 해설합니다. 구체적으로는 다음 4가지 포인트에 초점을 맞춥니다.

• 데이터의 「의미」를 명시하기
  세만틱 컨트랙트 (Semantic Contract) - 실행 시점에 평가
  권한 인식 검색 (Permission-aware Search) - 품질 및 신선도에 기반
  정지 판단 기구 - 이들을 뒷받침
  아키텍처상의 책임 분담

대상 독자는 AI 에이전트를 PoC에서 실무(Production)로 이행하려는 엔지니어, 아키텍트, SRE입니다.

많은 팀은 「데이터 레이크 (Data Lake)가 있다」, 「데이터 웨어하우스 (Data Warehouse)에 데이터가 갖춰져 있다」, 「BI 대시보드가 작동하고 있다」라는 이유로 AI 에이전트의 준비가 끝났다고 생각합니다.

하지만 기존의 분석과 AI 에이전트 사이에는 결정적인 차이가 있습니다.

인간 분석가는 모호함을 허용할 수 있다. 3개의 대시보드를 열고, 정의를 교차 참조(Cross-reference)하며, 암묵지(Tacit knowledge)로 보완한다.

AI 에이전트는 그것을 할 수 없다. 주어진 필드명(Field name)에만 의존하여 추론하며, 종종 「그럴듯하게 틀린다」.

구체적인 예를 들겠습니다.

• 재무 팀이 월간 결산 에이전트를 도입하려 했으나, 시산표에 「잠정치」와 「확정치」가 혼재되어 있었다.
• 구매 에이전트가 「승인된 벤더」를 참조하려 했으나, 조달 시스템과 ERP의 정의가 달랐다.
• 고객 지원 에이전트가 「활성 고객 (Active Customer)」을 판정하려 했으나, 부문마다 정의가 제각각이었다.

데이터는 존재한다. 하지만 에이전트가 올바르게 사용할 수 있는 형태로 패키징되어 있지 않다.

이 격차야말로 데모와 실무 운영을 가르는 가장 큰 벽입니다.

데이터를 **프로덕트 (Product)**로 취급한다는 발상은 마이크로서비스 (Microservices)나 데이터 메쉬 (Data Mesh)의 문맥에서 널리 알려져 있습니다. AI 에이전트용으로는 더욱 엄격한 계약이 필요합니다.

최소한, 에이전트 대응 데이터 프로덕트에 필요한 요소는 다음과 같습니다.

요소	설명
안정적인 스키마 (Schema)	하위 호환성이 있는 변경 관리
...

이러한 것들이 갖춰지지 않은 데이터는 에이전트에게 「문맥 없는 필드의 더미」입니다.

스키마 레지스트리 (Schema Registry)나 API 문서가 이미 있을지도 모릅니다. 하지만 에이전트가 필요로 하는 것은 필드명만이 아닙니다.

예를 들어 revenue라는 필드가 있을 경우, 에이전트는 이것이 다음 중 무엇을 가리키는지 알 필요가 있습니다.

• 수주 매출 (Booked revenue)
• 청구 매출 (Billed revenue)
• 인식 매출 (Recognized revenue)
• 순매출 (Net revenue)

마찬가지로 margin이 매출 총이익인지, 공헌 이익인지, 특정 배부 후의 이익인지.

active customer가 「과거 90일간 거래 있음」인지 「유효한 계약 있음」인지 「정식 해지 절차 없음」인지.

이 **세만틱 컨트랙트 (Semantic Contract)**는 다음 정보를 명시적으로 정의하는 레이어입니다.

• 각 필드의 비즈니스적 의미
• 해당 필드를 사용해야 하는/해서는 안 되는 조건
• 암묵적으로 포함된 전제 조건
• 정의의 변경 이력과 변경 책임자

엔터프라이즈에서는 이 세만틱 레이어를 BI, 업무 애플리케이션, AI 에이전트, 비즈니스 사용자 전체에서 통일해야 합니다. 왜냐하면 많은 데이터 충돌은 「기술적인 품질 문제」가 아니라 「정의의 문제」이기 때문입니다.

특히 다음 영역에서는 세만틱 컨트랙트를 엄격하게 적용해야 합니다.

• 여러 기능에 걸쳐 사용되는 데이터
• 트랜잭션이나 승인에 관여하는 데이터
• 액션을 실행하는 에이전트가 참조하는 데이터
• HR, 재무, 법무, 고객 데이터 등 규제 대상 영역

「인덱스에 있으니까」, 「벡터 스토어 (Vector Store)에 있으니까」라는 이유로 에이전트가 데이터를 가져와서는 안 됩니다.

액세스는 다음과 같은 컨텍스트 (Context)에 의존하여 평가되어야 합니다.

누가 (사용자 ID, 역할) -
어떤 채널에서 (Slack, Web, API) -
어떤 워크플로우의 어느 단계에서 (신청 중, 승인됨, 감사 중) -
무엇을 위해 (성과 검토, 보상 조사, 예외 처리) -
데이터의 기밀성은 (공개, 사내 한정, 허가 필요) -

많은 RAG (Retrieval-Augmented Generation) 구현은 "모든 것을 인덱싱하고, 의미적으로 가장 관련 있는 것을 가져온다"라는 단순한 패턴에서 시작됩니다. 하지만 엔터프라이즈 환경에서는 이것이 위험합니다.

• 가장 관련성이 높은 문서가 가장 허용된 문서와는 다를 수 있음
• HR 온보딩 에이전트가 "복리후생"과 관련된 보상 문서를 찾아버림
• 법무 계약 어시스턴트가 다른 사업부의 계약을 참조함

흔히 하는 실수는 액세스 제어 (Access Control)를 인덱싱 시점에만 적용하는 것입니다.

하지만 권한은 호출자의 컨텍스트 (Context)에 따라 변하기 때문에, **실행 시점 (Runtime)**에 평가해야 합니다.

에이전트 시스템에서는 역할 기반 액세스 제어 (RBAC, Role-Based Access Control)만으로는 너무 거칠 때가 많습니다.

• 같은 역할을 가진 두 명의 매니저가 동일한 데이터를 서로 다른 목적으로 사용해서는 안 됨
• 매니저는 팀 데이터를 성과 검토 (Performance Review)에는 사용할 수 있지만, 보상 조사에는 사용할 수 없음
• 재무 에이전트는 송장 (Invoice)의 예외 처리를 위해 상세 내용을 읽을 수 있지만, 교차 엔티티 (Cross-entity) 벤더 요약을 마음대로 집계해서는 안 됨

이러한 복잡성에 대응하려면 메타데이터의 풍부화 (Enrichment), IAM/정책 엔진과의 긴밀한 통합, 레이턴시 (Latency) 허용, 인덱스 설계의 정교함이 필요합니다.

하지만 HR, 재무, 법무, 고객 데이터, 규제 대상 업무에서는 이것이 최소 요구 사항입니다. 이를 소홀히 하면 에이전트가 새로운 데이터 유출 경로가 됩니다.

AI 에이전트의 실무적인 최대 리스크는 할루시네이션 (Hallucination)이 아닙니다.

오래된 데이터, 불완전한 데이터, 과도기적 데이터를 자신만만하게 사용하여 액션을 취하는 것입니다.

실제 장애 사례를 들어보겠습니다.

• 구매 에이전트가 듀 딜리전스 (Due Diligence) 승인 상태가 동기화되지 않은 벤더를 추천함
• 재무 결산 에이전트가 잠정치로부터 코멘트를 생성함 (확정치는 따로 있었음)
• 고객 서비스 에이전트가 업데이트되지 않은 주문 상태를 바탕으로 환불을 약속함
• IT 인시던트 에이전트가 CMDB가 오래된 상태인 시스템에 복구 라우팅을 지시함

이 모두 모델의 문제가 아니라, 데이터 프로덕트 (Data Product)가 품질 및 신선도 시그널을 적절히 전달하지 못했기 때문에 발생한 원인입니다.

에이전트 대응 데이터 프로덕트에는 최소한 4가지 메커니즘이 필요합니다.

품질 체크 (Quality Check): 필드 결손 체크, 스키마 일치 확인, 참조 무결성 검증 -
신선도 인디케이터 (Freshness Indicator): 최종 업데이트 시각, 기대되는 리프레시 주기, 유효 기간 내 여부 -
이상 탐지 (Anomaly Detection): 스파이크나 이상 패턴이 발생할 경우, 에이전트는 데이터를 무조건 신뢰하지 않음 -
폴백 동작 (Fallback Behavior): 품질이나 신선도가 임계값을 밑돌 경우의 행동 —— 중단, 대체 데이터 소스 이용, 인간에게 에스컬레이션 (Escalation)

가장 간과하기 쉬운 것은 에이전트가 "데이터가 부족하다"라고 말할 수 있는 능력입니다.

• AP 예외 에이전트는 입고가 등록되지 않았다면 불일치로 분류해서는 안 됨
• HR 에이전트는 급여 자격 데이터가 확정되지 않았다면 질문에 답해서는 안 됨
• 공급망 에이전트는 출하 피드 (Feed)가 업데이트되지 않았다면 경로 변경을 권장해서는 안 됨

거버넌스 관점에서는 "언제 멈춰야 하는지 아는 에이전트"가 "항상 자신만만한 에이전트"보다 훨씬 가치가 있습니다.

데이터와 지식을 에이전트용 프로덕트로 취급하는 것은 아키텍처 전체에 영향을 미칩니다.

모든 데이터 프로덕트에 다음을 할당합니다.

비즈니스 오너 (Business Owner): 정의와 이용 규칙의 결정 책임자 -
테크니컬 오너 (Technical Owner): 전달과 품질 구현 책임자 -
리스크/컴플라이언스 오너 (Risk/Compliance Owner) (기밀 영역의 경우): 규제 대응 책임자

오너가 없는 상태에서는 에이전트가 이용 가능한 데이터를 무엇이든 사용하게 되지만, 정의가 바뀌거나 품질이 저하되었을 때 책임을 질 사람이 없습니다.

데이터 프로덕트의 위치뿐만 아니라 다음을 추적하는 카탈로그가 필요합니다.

• 시맨틱 컨트랙트 (Semantic Contract)
• 신선도 기대치 및 품질 상태
• 액세스 정책 (Access Policy)
• 리스크 계층 (Risk Hierarchy)

이를 통해 에이전트 플랫폼은 데이터 프로덕트를 관리 가능한 의존 관계로 다룰 수 있습니다. 애드혹 (Ad-hoc)한 연결이 아니게 됩니다.

에이전트가 실패했을 때, 먼저 모델을 의심하는 것이 아니라 다음을 확인합니다.

• 데이터 프로덕트는 적절했는가?
• 시맨틱 컨트랙트는 충분히 명확했는가?
• 품질 저하 시 폴백이 올바르게 동작했는가?
• 검색이 정책을 존중했는가?

평가 파이프라인 (Evaluation Pipeline)에 이러한 관점들을 통합함으로써, 모델 기인 문제와 데이터 기인 문제를 분리할 수 있습니다.

AI 에이전트의 엔터프라이즈 도입을 성공시키는 열쇠는 모델도, 오케스트레이션 (Orchestration)도, 도구 호출 (Tool Calling)도 아닙니다.

엔터프라이즈 데이터를 에이전트가 사용할 수 있는 프로덕트로서 패키징하는 규율입니다.

이러한 이해를 갖춘 조직은 인상적인 데모 단계에서 실제로 신뢰할 수 있는 운영 단계로 빠르게 전환할 수 있습니다.

여러분의 팀에 전달하고 싶은 질문은 이것입니다.

"여러분의 에이전트는 데이터가 신뢰할 수 없을 때 정지해야 한다는 것을 알고 있습니까?"

만약 대답이 "아니오"라면, 아직 실무 운영 (Production)을 위한 준비가 되지 않은 것입니다.