한 고객이 네 가지 다른 철자로 저장되어 있을 때 CRM에 해당 고객의 오픈 파이프라인(open pipeline)을 요청하면, 검색 기반 에이전트(retrieval-based agent)는 모든 설정에서 확신에 찬 틀린 숫자로 대답합니다. 몇 개의 레코드를 읽으면 $120,000, 백 개를 읽으면 $1,345,000라고 답하며, 실제 금액인 $275,000는 절대 맞히지 못합니다. 모델은 잘못한 것이 없습니다. 데이터 내에서 고객의 정체성(identity)이 결코 해결되지 않았으며, 그 어떤 오케스트레이션 (orchestration)으로도 이를 복구할 수 없습니다. 이 예시는 실행 가능한 데모로 구현되어 있으며, 검색 차단 지점(retrieval cutoff)마다 잘못된 총액이 재현됩니다.

이것이 AI 에이전트 프로젝트에서 발생하는 가장 값비싼 의외의 상황이며, 에이전트의 탈을 쓰고 있는 데이터 문제입니다. 팀은 에이전트의 범위를 정하고 모델 예산을 책정합니다: 토큰(tokens), 벡터 스토어(vector store), 약간의 오케스트레이션 (orchestration). 에이전트는 깨끗한 문서 세 개를 가지고는 데모를 잘 수행하지만, 실제 데이터를 마주하게 되면 6주 뒤 프로젝트는 지연됩니다. 모델 때문이 아니라, 아무도 계획에 넣지 않았던 데이터 때문입니다. 이것이 바로 데이터 준비 세금 (data-prep tax)입니다. 이것이 무엇인지, 왜 끝나지 않고 반복되는지, 그리고 에이전트 구축을 약속하기 전에 어떻게 범위를 정해야 하는지 설명하겠습니다.

요약 (TL;DR)

• 모델은 범용 제품(commodity)이고, 데이터가 시스템입니다. 에이전트가 프로덕션(production) 환경에서 작동할지를 결정하는 것은 모델의 선택이 아니라 데이터의 상태입니다.
• 데이터 문제는 하나가 아니라 두 가지입니다. 지식 데이터(knowledge data; 정책, 문서, FAQ)는 형식과 용어 문제로 실패합니다. 운영 데이터(operational data; 레코드, 액세스, 신뢰할 수 있는 원천/source-of-truth)는 정체성 해결(identity resolution)과 권한 문제로 실패합니다. 이들은 별도로 추정되거나 아예 추정되지 않습니다.
• 세금은 반복됩니다. 비즈니스가 변화함에 따라 준비된 데이터는 드리프트(drift)합니다. 누군가 유지보수를 담당하지 않으면, 에이전트는 조용히 오래되고 해결되지 않은 데이터를 바탕으로 답변하기 시작합니다.
• 구축 전 정직한 테스트: 유능한 사람이 오늘 당신의 데이터를 보고 에이전트의 질문에 올바르게 답할 수 있습니까? 만약 그렇지 않다면, 에이전트도 할 수 없습니다. 때로는 올바른 프로젝트가 데이터 프로젝트이며, 에이전트는 선택 사항일 뿐입니다.

두 종류의 데이터, 두 종류의 고통

"데이터를 준비하라(Prepare the data)"는 말은 마치 하나의 작업처럼 들립니다. 하지만 이는 두 가지 작업이며, 각각 실패하는 방식이 다릅니다. 이 둘을 혼동하는 것이 바로 추정치가 틀어지는 원인입니다. 이러한 구분은 대부분의 에이전트 계획이 잘못되는 지점이며, 따라서 다른 무엇보다도 이를 정확히 정의하는 것이 중요합니다.

**지식 데이터 (Knowledge data)**는 에이전트가 질문에 답하기 위해 읽는 비정형 자료입니다. 정책, 절차, 제품 문서, FAQ, 누군가가 2023년에 만든 발표 자료 등이 이에 해당합니다. 여기서 발생하는 고통은 형식(format)과 일관성(consistency)입니다. 동일한 정책이 PDF, 위키(wiki) 페이지, 녹화된 전사 회의(all-hands)에 흩어져 있습니다. 세 개의 부서가 동일한 개념에 대해 서로 다른 세 가지 단어를 사용합니다. 문서의 절반은 오래된 정보이며, 어느 쪽이 오래된 것인지 아무도 모릅니다. 이 데이터가 검색(retrieval)에 유용하게 쓰이기 위해서는 일관된 형식으로 변환되고, 중복이 제거되며, 용어가 조정되고, 날짜가 기입되어야 합니다. 이 중 그 어떤 것도 AI 작업이 아닙니다. 이는 편집(editorial) 및 정보 구조(information-architecture) 작업이며, 전체 노력의 대부분을 차지합니다.

**운영 데이터 (Operational data)**는 에이전트가 실행에 옮기는 정형 자료입니다. 고객 기록, 직원 기록, 승인, 권한(entitlements), 누가 무엇을 볼 수 있는지 등이 이에 해당합니다. 여기서 발생하는 고통은 형식이 아닙니다. 그것은 식별(identity)과 권한(authority)입니다. 두 시스템의 정보가 다를 때 어떤 시스템이 진실의 원천(source of truth)인가요? "Acme"라는 네 가지 철자 중 무엇이 실제 고객이고, 무엇이 완전히 다른 회사인가요? 이 기록을 볼 수 있는 사람은 누구이며, 에이전트가 그 권한을 준수하나요? 이것들은 데이터 모델링(data-modeling) 및 거버넌스(governance) 문제이며, 이를 추측하는 에이전트는 이 글의 서두에서 언급한 것처럼 그럴듯하게 틀린 수치를 반환하게 됩니다.

지식 데이터 (Knowledge data)	운영 데이터 (Operational data)
정책, 문서, FAQ, 트랜스크립트 (transcripts)	기록, 승인, 권한, 신뢰할 수 있는 원천 (source-of-truth)
...

운영 측면은 실패가 눈에 보이지 않기 때문에 가장 비용이 많이 드는 의외의 상황을 만들어냅니다. 파이프라인은 답변을 내놓고, 수치는 합리적으로 보이지만, 예측치가 움직이기 전까지는 아무도 알아차릴 수 없는 방식으로 틀리게 됩니다. 해결책은 더 나은 모델을 만드는 것이 아닙니다. 그것은 검색(retrieval)이 실행되기 전에 데이터가 보유하고 있는 해결된 정체성(resolved identity)입니다. 이는 relational-RAG demo가 분리해낸 것과 정확히 일치합니다. 모델을 바꾸면 잘못된 합계는 계속 유지되지만, 정체성을 해결하면 그 문제는 사라집니다.

세금은 반복됩니다, 일회성 설정이 아닙니다

가장 흔한 추정 오류는 데이터 준비를 끝나는 하나의 단계로 취급하는 것입니다. 데이터 준비는 끝나지 않습니다. 비즈니스는 멈춰 있지 않기 때문입니다. 신제품이 출시되고, 정책이 변경되며, 조직이 개편되고, 마이그레이션으로 인해 계정의 절반이 이름이 바뀝니다. 이러한 모든 이벤트는 무언가가 데이터를 최신 상태로 유지하지 않는 한, 준비된 데이터를 저하시킵니다.

따라서 비용은 두 부분으로 나뉩니다. 데모가 깨끗한 하위 집합(subset)에서 실행되었기 때문에 과소평가된, 데이터를 준비하는 데 드는 초기 비용이 있습니다. 그리고 이를 계속 준비된 상태로 유지하는 데 드는 지속적인 비용이 있는데, 이는 대개 예산에 전혀 반영되지 않습니다. 유지보수는 기초 데이터가 얼마나 빨리 변동(churn)하느냐에 따라 규모가 결정되는 상시적인 인력 책임 사항이며, 실패 모드는 단순히 그 추정치를 틀리는 것이 아닙니다. 그것은 소유자(owner)를 지정하지 않는 것이며, 이로 인해 데이터는 표류(drift)하고 에이전트는 성능이 저하되지만 아무도 이를 인지할 책임이 없게 됩니다. 데모는 구축된 당일에는 정확합니다. 시스템이 계속 정확하게 유지되는 것은 운영 비용(operating cost)이지, 자본 비용(capital cost)이 아닙니다.

당신의 AI 에이전트가 정말로 데이터 프로젝트인지 어떻게 알 수 있을까요?

유능한 사람이 현재 보유한 데이터만을 사용하여 수작업으로 에이전트가 의도한 질문에 올바르게 답할 수 있는지 자문해 보십시오. 만약 대답이 '아니오'라면, 에이전트도 더 나은 결과를 낼 수 없습니다. 에이전트는 누락된 단일 진실 공급원(source-of-truth), 해결되지 않은 중복 데이터, 또는 문서화되지 않은 액세스 규칙(access rules)을 수정해주지 않습니다. 대신 그것들을 그대로 물려받아, 스프레드시트보다 더 큰 자신감을 가지고 제시할 뿐입니다.

만약

1. 두 가지 데이터 유형을 각각 별도로 인벤토리화(Inventory)하세요. 지식 소스(knowledge sources)와 운영 소스(operational sources)를 목록화하고 각각 별도로 추산하십시오. 왜냐하면 두 유형은 실패하는 방식이 다르며, 운영 측면이 과소평가되는 경향이 있기 때문입니다.
2. 식별(Identity) 문제를 구체화된 키(materialized key)로 해결하세요. 검색(retrieval) 단계 내부가 아니라, 검색 전 단계에서 중복되거나 변형된 엔티티가 어떻게 하나의 쿼리 가능한 식별자가 될지 결정하십시오. Dataverse 용어로 설명하자면, 이는 모델이 런타임에 추측하는 name LIKE 매칭이 아니라, 데이터플로(dataflow)에 의해 유지되는 대체 키(alternate key) 또는 해결된 계정 테이블(resolved-account table)이어야 합니다. 이것이 가장 영향력이 큰 단일 데이터 결정 사항입니다.
3. 진실의 원천(source-of-truth)과 최신성 정책(freshness policy)을 명명하세요. 에이전트가 진술할 모든 사실에 대해, 어떤 시스템이 해당 사실을 소유하는지, 그리고 얼마나 최신 상태여야 하는지를 결정하십시오. 데이터 내에서 해결되지 않은 충돌은 에이전트가 임의로 답변을 만들어내는 충돌로 이어집니다.
4. 답변을 모델링하기 전에 액세스(access)를 모델링하세요. 에이전트는 소스 시스템이 따르는 것과 동일한 행 수준(row-level) 및 역할 수준(role-level) 권한을 준수해야 합니다. 이를 준수한다는 것은 데이터 거주성(data residency)을 보존하고, 어떤 레코드가 각 쿼리에 답변했는지에 대한 감사 추적(audit trail)을 생성하는 것도 의미합니다. 이를 사후에 적용하는 것은 고통스러우며, 실패할 경우 컴플라이언스(compliance) 사고로 이어집니다.
5. 그다음에, 오직 그 단계에서만 에이전트(agent)를 쓸지, 플로(flow)를 쓸지, 쿼리(query)를 쓸지 결정하세요. 데이터의 범위(scope)가 정해지면 적절한 도구가 무엇인지 명확해지는 경우가 많으며, 때로는 에이전트가 정답이 아닐 수도 있습니다.

깨끗한 데이터가 실제로 만들어내는 복리 효과

이 세금(tax)을 지불할 가치가 있게 만드는 재정의는 다음과 같습니다. 해결된 고객 식별 정보, 정의된 진실의 원천, 그리고 최신 지식 베이스는 단 하나의 에이전트를 위해 흡수해야 하는 비용이 아닙니다. 에이전트에게 올바른 파이프라인 번호를 제공하는 동일한 'Acme' 식별 정보는, 여러분의 분석(analytics)에는 올바른 매출 합계(revenue rollup)를 제공하고, 여러분의 통합(integrations) 시스템에는 다시 기록할 올바른 계정 정보를 제공합니다. 데이터 작업은 모든 다운스트림(downstream) 소비자에게 동시에 기여합니다.

그렇기 때문에 이 비용은 기능을 제공하기 위한 투입(feeding a feature)이라기보다 기반을 구축하는 것(building a foundation)으로 이해하는 것이 더 적절합니다. 데이터 준비(data preparation)를 최소화해야 할 오버헤드(overhead)로 취급하는 팀은 취약한 에이전트 하나를 출시할 뿐입니다. 반면, 이를 제품(product)으로 취급하는 팀은 다음 에이전트, 다음 대시보드, 그리고 다음 통합(integration)을 저렴하게 만들어 주는 해결된(resolved) 거버넌스 계층(governed layer)을 구축합니다. 모델 선택은 더 가역적인(reversible) 결정입니다. 모델을 교체하면 프롬프트 재조정(prompt re-tuning), 평가 재기준 설정(evaluation re-baselining), 출력 드리프트(output drift)가 발생하지만, 이는 범위가 제한된 작업입니다. 해결되고 거버넌스가 적용된 데이터는 복리로 쌓이는 부분이며, 경쟁사가 벤더를 바꾼다고 해서 복제할 수 없는 부분입니다.

계획의 최우선 순위에 두십시오

데이터 준비 세금(data-prep tax)은 모든 사람이 보는 프로젝트의 부분에서는 보이지 않기 때문에 사람들을 계속 놀라게 합니다. 데모는 정제된 하위 집합(clean subset)에서 실행되고, 슬라이드에는 "AI 에이전트"라고 적혀 있지만, 결과(outcome)를 결정짓는 작업은 화면 밖에서 일어나며 예산 편성에서도 마지막 순위로 밀려납니다. 먼저 범위를 정하십시오: 해결된 식별 키(resolved identity key), 신뢰할 수 있는 원천(source-of-truth)에 대한 결정, 액세스 모델(access model), 그리고 이를 최신 상태로 유지할 소유자(owner)를 정의해야 합니다. 그 기반이 에이전트의 정확성을 결정하며, 모델과 달리 나중에 되돌릴 수 없는 부분입니다.

다음 글 읽기

• Relational records need a key, not an embedding - 데이터에서 식별(identity)이 해결되지 않았을 때 검색(retrieval)이 확신에 찬 오답을 반환하는 것을 보여주는 실행 가능한 데모
• Dataverse MCP, Business Skills, and Coding Agents: The 2026 Decode - 플랫폼 측면의 대응물: Dataverse 데이터 플랫폼의 관심사로서의 신뢰할 수 있는 원천(source-of-truth)과 식별 해결(identity resolution)
• Microsoft's Agents Hub Decoded - 공식 에이전트 가이드라인이 공식화하는 내용과, 그 가이드라인이 여러분에게 남겨둔 비용 및 절제에 대한 요구사항

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 특정 벤더에 치우치지 않은 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 많은 내용은 az365.ai에서 확인하실 수 있습니다.