Executive Summary

그 간극은 이미 수치로 드러나 있다. AI에 완전히 준비된 데이터를 가진 기업은 극소수에 그치고, 준비되지 않은 데이터는 매년 기업당 수천만 달러의 비용으로 되돌아오며, 확장 실패의 책임은 대개 주인을 찾지 못한다. 뒤집으면, 그 주인을 지정한 기업은 파일럿을 운영으로 넘길 확률이 뚜렷이 높았다.

엔터프라이즈 AI 담론에는 이미 정설이 하나 있다. 파일럿은 잘 되는데 운영으로 넘어가지 못하고, 그 원인이 모델의 지능이 아니라 뒤엉킨 데이터라는 것이다. 이 진단 자체는 옳다. 그래서 이 리포트는 거기서 출발하되 거기 머물지 않는다. "데이터가 문제"라는 문장은 전제로 접어둔다. 실무자가 정작 묻고 싶은 질문은 그다음이다. 정확히 어떤 결함이, 어떤 경로로 에이전트를 멈추는가.

"운영에 못 간다"는 통념부터 한 겹 뜯어보면 그림은 생각보다 복잡하다. RAND는 기업 AI 프로젝트의 80.3%가 약속한 비즈니스 가치를 내지 못했다고 분석하면서, 그 실패를 뭉뚱그리지 않고 네 갈래로 나눴다. 운영 도달 전에 완전히 폐기된 33.8%, 운영에는 도달했으나 기대 가치에 미달한 28.4%, 돌아가고는 있지만 투자를 회수하지 못하는 18.1%, 그리고 비즈니스 케이스를 충족한 19.7%다. 여기서 눈여겨볼 대목은 두 번째 갈래다. 운영에 도달하고도 실패하는 경우가 폐기되는 경우와 맞먹는다. 파일럿의 죽음은 배포 순간에 끝나지 않는다.

탈락이 집중되는 지점도 특정된다. AgentMarketCap의 2026 성숙도 모델은 기업의 에이전트 여정을 네 단계로 그린다. 에이전트 5개 미만의 프로토타입 단계(Stage 1)에는 78%가 도달하지만, 5~20개로 확장을 시도하는 순간 60%가 이른바 'Stall Zone'에 갇힌다. 안정적 운영(Stage 3)에 이르는 기업은 전체의 31%, 그중에서도 금융은 21%, 의료는 8%에 그친다. 탈락은 모델 성능이 부족해서가 아니라, 결함이 곱해지는 확장의 문턱에서 일어난다.

출처: AgentMarketCap, The Enterprise Agent Deployment Maturity Model 2026 (2026-04-11)

이 글 전체를 관통하는 문장은 하나다. valid와 usable은 다른 축이다. 스키마 검증을 통과했다고 해서 에이전트가 오독 없이 소비할 수 있는 데이터가 되는 것은 아니다. 앞으로 해부할 여섯 종의 결함은 예외 없이 이 성질을 공유한다. 파서는 통과시키고, 파이프라인은 오류를 내지 않으며, 대시보드는 초록불이다. 그런데 에이전트는 자신 있게 틀린 답을 낸다.

아래 표는 여섯 결함을 한자리에 모은 것이다. 각 결함의 발생 규모, "왜 검증을 통과하는가", 그리고 에이전트가 실제로 저지르는 잘못의 형태를 나란히 담았다. 이어지는 섹션에서 각 행을 하나씩 다룬다.

첫 두 결함은 데이터의 '내용'이 아니라 데이터의 '뜻'에 관한 문제다. 값은 멀쩡하다. 그런데 그 값이 무엇을 가리키는지가 흐려져 있다. 이런 결함은 예외를 던지지 않기 때문에, 파이프라인 어디에도 빨간불이 켜지지 않는다.

2.1의미 드리프트: 같은 이름, 다른 뜻

정의. 의미 드리프트(semantic field drift)는 같은 이름의 필드가 시스템마다 다른 것을 뜻하는 현상이다. 전형적인 사례가 "활성 고객(active customer)"이다. 한 시스템에서는 90일 내 구매한 고객을, 다른 시스템에서는 30일 내 로그인한 고객을 뜻한다. Finance, Marketing, Sales가 "3분기 고객 총가치"라는 같은 프롬프트를 던지면 세 가지 다른 답을 받는다. 어느 부서도 틀리지 않았는데 답이 다르다.

왜 검증을 통과하는가. 필드는 채워져 있고, 타입도 맞고, null도 아니다. 스키마가 검증하는 것은 "값이 있는가"이지 "그 값이 무엇을 뜻하는가"가 아니다. 의미는 스키마 바깥에 산다. 그래서 어떤 정형 검증으로도 잡히지 않는다.

에이전트 실패 경로. 룰 기반 BI 시대에는 이 모호성이 문제가 되지 않았다. Earley Institute의 진단이 정확하다. "BI 도구와 운영 시스템은 수십 년간 시맨틱 모호성을 허용해 왔다. 분석가가 암묵적 조정 레이어 역할을 했기 때문이다. 에이전트형 AI는 그 버퍼를 제거한다." 사람이라면 "어느 쪽 정의를 말하는 거죠?"라고 되물었을 자리에서, LLM은 충돌하는 정의 중 하나를 아무 플래그 없이 골라 자신 있는 오답을 낸다. 기업의 73%가 이미 AI 출력의 불일치를 경험했다고 답한다.

탐지·수리. 정의를 코드 바깥의 계약으로 고정하는 것이 출발점이다. 2026년 1월 출범한 Open Semantic Interchange v1.0에 Snowflake·dbt Labs·Salesforce를 포함한 30여 파트너가 모인 것은, 시맨틱 레이어를 공용 표준으로 끌어올리려는 업계의 첫 대응이다. 데이터 계약(data contract)에 "활성 고객"의 정의를 못 박으면, 정의가 달라지는 순간 계약 위반으로 표면화된다.

2.2중복·유령 레코드: 한 사람이 넷이 될 때

정의. 중복 레코드는 하나의 실체(entity)가 데이터 안에서 여러 개로 존재하는 상태다. M&A 이후 같은 고객이 네 개 시스템에서 네 개의 ID를 갖는 것이 교과서적 사례다. Landbase의 2026 통계에 따르면 평균 엔터프라이즈 데이터베이스의 중복률은 15~25%에 달한다. 1,000만 건의 고객 레코드라면 150만~250만 건이 유령이다.

왜 검증을 통과하는가. 각 레코드는 개별적으로 완벽하게 유효하다. 이름도 있고 ID도 있고 형식도 맞다. 중복은 레코드 하나를 보는 검증으로는 절대 잡히지 않는다. 레코드 사이의 관계를 봐야만 드러나는데, 대부분의 스키마 검증은 행 단위에서 멈춘다.

에이전트 실패 경로. 에이전트가 "고객 수"를 세거나 "총 구매액"을 집계할 때, 유령 레코드는 조용히 숫자를 부풀린다. 결정론적 룰로 처리 가능한 매칭은 약 80%에 그치고, 나머지 20%가 다운스트림의 모든 모델·캠페인·컴플라이언스 리포트를 오염시킨다. 에이전트는 이 오염된 집계 위에서 "자동 재주문", "우량 고객 세그먼트 추출" 같은 행동을 실행한다.

탐지·수리. 엔티티 해소(entity resolution)와 중복 제거 파이프라인이 정답이다. Landbase는 알고리즘 기반 매칭 도입 시 첫 수개월 내 중복이 30~40% 감소한다고 보고한다. 핵심은 조인과 핸드오프 지점마다 중복률을 정량으로 프로파일링하는 것이다. 측정하지 않으면 유령은 계속 늘어난다.

세 번째와 네 번째 결함은 'valid하지만 usable하지 않은' 상태의 가장 순수한 표본이다. 데이터는 스키마를 통과하고 JSON은 완벽하게 파싱되는데, 그 안에서 뜻이 조용히 뒤틀린다.

3.1null 오독: 없음과 0을 구별하지 못할 때

정의. null은 "값이 없음" 또는 "아직 모름"을 뜻하지, "0"을 뜻하지 않는다. 그러나 에이전트가 데이터를 프롬프트로 직렬화하거나 계산에 넣는 과정에서 null은 손쉽게 0이나 기본값으로 뭉개진다. 재고 필드의 null(=확인 안 됨)을 0(=품절)으로 읽으면 에이전트는 자동 재주문을 취소한다. 잔액 null을 0으로 읽으면 신용 판단이 통째로 뒤집힌다.

왜 검증을 통과하는가. null은 대부분의 스키마에서 합법적인 값이다. 검증기는 "null이 허용되는가"만 확인하고 통과시킨다. 문제는 다운스트림에서 null을 어떻게 해석하느냐인데, 그 해석은 검증 대상이 아니다.

에이전트 실패 경로. Microsoft ISE 팀이 기록한 "손실 직렬화(lossy serializer)" 현상이 이 결함의 본질을 보여준다. LLM이 만든 JSON은 형식적으로 100% 유효하지만 계약 신뢰성은 사실상 0에 가깝다. 필수 서브필드가 빠지거나 배열이 비어 있어도 파서는 통과시킨다. 담당자가 요약을 열었을 때 이벤트 기록도, 미완료 태스크도 없다. 사고가 없어서가 아니라 모델이 조용히 누락시켰기 때문이다. 멀티에이전트 시스템의 생산 실패율이 41~86.7%(MAST, NeurIPS 2025, 1,600여 실행 추적)에 이르는 배경에 이런 침묵의 누락이 있다.

3.2타입 강제변환: 형식은 맞는데 값이 틀린다

정의. 타입 강제변환은 LLM이 툴을 호출하거나 구조화된 출력을 낼 때 값의 타입을 임의로 바꾸는 현상이다. customer_id를 문자열 대신 정수로 반환하거나, boolean 필드를 통째로 누락하거나, JSON 전체를 이스케이프된 문자열로 감싸버린다. OpenAI 내부 연구에 따르면 스키마 강제가 없을 때 GPT-4의 출력 스키마 준수율은 40% 미만이다. 뒤집으면, 툴 호출의 60% 이상이 타입 불일치나 필드 누락의 위험을 안고 있다는 뜻이다.

왜 검증을 통과하는가. 직렬화 형식 자체는 완벽하게 유효한 경우가 많다. 중괄호도 맞고 문법도 옳다. 형식 검증은 통과하지만, 그 안의 customer_id가 정수로 바뀐 탓에 후속 조회가 조용히 빈 결과를 낸다. deepset-ai/haystack 이슈 #6098처럼 실제 오픈소스 프로젝트에서 반복 보고되는 패턴이다.

탐지·수리. 스키마 강제(structured output / constrained decoding)를 적용하면 준수율은 near-zero 실패로 떨어진다. 그러나 강제 스키마만으로는 null 오독까지 막지 못한다. 타입과 의미를 함께 계약으로 못 박고, 에이전트 입력 지점에서 프로파일링해야 한다.

이 두 결함이 합쳐질 때 나타나는 결과가 그 유명한 "파일럿에선 됐는데 운영에선 왜"의 정량적 정체다. 선별된 테스트 데이터로 단일 실행하는 파일럿에서 에이전트는 60%의 정확도를 낸다. 그러나 null·중복·타입 불일치가 뒤섞인 실데이터를 다중 실행하는 운영에서는 25%의 일관성으로 떨어진다. 3배의 저하다. 격차의 주범은 모델이 갑자기 멍청해진 것이 아니라, 파일럿 데이터에서 일관되게 처리되던 null의 의미가 운영 데이터에서는 시스템마다 달라졌다는 데 있다.

출처: 복수 LLM 신뢰성 연구 종합. 데이터 에이전트 벤치마크의 최고 모델 pass@1도 38%에 그친다(arXiv 2025).

마지막 두 결함은 시간축 위에서 벌어진다. 어제까지 멀쩡하던 데이터가 오늘 조용히 어긋난다. 파이프라인이 아니라 에이전트가 뒤늦게 그 어긋남을 발견한다.

4.1무성 스키마 변경: 아무도 알려주지 않은 컬럼

정의. 무성 스키마 변경(silent schema change)은 데이터 공급자가 스키마를 바꿨는데 소비자에게 고지하지 않는 상황이다. 전형적 시나리오는 이렇다. 벤더가 JSON 페이로드 중간에 컬럼 하나를 추가한다. 인제스트 프로세스에는 스키마 검증이 없다. 그래서 오류도, 알림도 없이 처리가 어긋나고, 남는 것은 빈 대시보드뿐이다.

왜 검증을 통과하는가. 애초에 검증할 스키마 계약이 없기 때문이다. 데이터는 여전히 흘러 들어오고 형식도 그럴듯하다. 변경을 감지하려면 "이전 스키마와 지금 스키마가 같은가"를 비교해야 하는데, 대부분의 파이프라인은 그런 비교를 하지 않는다.

규모. 2026 State of Database Change Governance 리포트에서 39%의 팀이 스키마 드리프트를 최상위 AI 리스크로 꼽았다. Liquibase는 AI 리스크의 64%가 모델이 아니라 스키마 레이어에 실재한다고 주장한다(단일 벤더 추정치이므로 방향성 근거로만 읽는 것이 안전하다). 데이터 엔지니어링 커뮤니티에서 "silent killer"라는 별명이 붙은 이유다.

탐지·수리. 스키마 계약과 자동 스키마 검증을 인제스트 앞단에 두면 변경이 즉시 계약 위반으로 표면화된다. RIVA 같은 2026년 프레임워크는 LLM 에이전트 기반으로 구성 드리프트를 신뢰성 있게 탐지하는 접근을 실증했다.

4.2신선도 붕괴: 낡은 컨텍스트 위의 결정

정의. 신선도 붕괴(staleness)는 데이터가 존재하고 형식도 정상이지만 이미 시효가 지난 상태다. 에이전트가 초당 한 번 결정을 내리는데 데이터는 시간당 한 번 갱신된다면, 한 시간 동안 3,600개의 결정이 동일한 낡은 컨텍스트 위에서 실행된다.

에이전트 실패 경로와 처방. NANDini 멀티에이전트 연구는 신선도 탐지 메커니즘이 없을 때 결정 오류율이 37.6%에 이른다는 것을 실측했다. 같은 연구에서 Data Facts 메타데이터 스키마를 적용하자 오류율은 8.6%로 떨어졌다. 탐지 장치 하나가 오류를 4분의 1 이하로 줄인 것이다. 이것이 이 리포트가 비관에 머물지 않는 이유다. 결함에 이름을 붙이고 탐지 장치를 붙이면, 개선은 정량으로 나타난다.

출처: arXiv 2606.26211, Data Facts: A Metadata Schema ... in the NANDini Multi-Agent Ecosystem (2026)

여섯 결함을 하나씩 해부하고 나면 자연스럽게 두 번째 축에 이른다. 이 결함들이 예외를 던지지 않는다는 사실은, 뒤집으면, 예외가 발생해도 아무도 그것을 받아들지 않는다는 뜻이다. 룰 기반 ETL과 BI 시대에는 분석가와 엔지니어가 암묵적 조정 레이어였다. 이상한 값이 보이면 사람이 손으로 잡았다. 자율 에이전트는 그 버퍼를 제거한다. 예외는 여전히 발생하지만, 이제 명시적 소유자가 없어 조용히 삼켜진다.

이 공백은 추상적 우려가 아니라 정량으로 측정된다. AgentMarketCap에 따르면 에이전트 확장 실패의 89%가 추적 가능한 원인 중 "불명확한 소유권 문제"로 귀인된다. 자율 AI 에이전트에 대한 성숙한 거버넌스 모델을 가진 기업은 21%뿐이다. EY/AIUC-1 컨소시엄 조사에서는 AI 트래픽을 엔드투엔드로 모니터링하는 기업이 38%, 에이전트 간 상호작용을 지속 모니터링하는 기업은 17%에 그쳤다. 매출 10억 달러 이상 기업의 64%가 2025년 AI 장애로 100만 달러 이상의 손실을 보고했다.

소유권이 왜 이렇게 흩어졌는가. 조사에 따르면 에이전트 보안 책임이 보안팀 39%, IT 부서 32%, AI 보안 전담 13%로 나뉘어 있다. 모두가 조금씩 책임지는 구조는 결국 아무도 책임지지 않는 구조다. Blackstraw의 Atul Arya가 짚은 대목이 이 역학을 잘 요약한다. "ROI는 6~12개월 사이에 나타나는데, 임원의 지지는 같은 시점에 사라진다. 성공 지표를 처음에 정의하지 않았기 때문이다."

처방은 낙관적이다. 예산 권한과 측정 목표를 함께 쥔 '명명된 에이전트 오너(named agent owner)'를 둔 기업은 파일럿에서 운영으로의 전환율이 2.7배 높다. 전환에 성공한 기업의 94%가 명명된 오너를 보유했고, 87%는 프롬프트·모델·툴을 바꾸기 전에 자동 평가를 실행한다. 소유권을 되찾는 실무 도구가 바로 데이터 계약과 관측성(observability)이다. 데이터 계약은 생산자와 소비자 사이에 스키마·의미·신선도 SLA를 명시적으로 약속하고, 그 약속을 어기는 순간을 예외의 주인에게 알린다.

여섯 결함과 주인 없는 예외는 결국 하나의 구분으로 수렴한다. 정합성(validity)과 사용가능성(usability)은 다른 축이다. 깨끗한 데이터는 스키마 검증을 통과한 데이터다. 쓸 수 있는 데이터는 에이전트가 오독 없이 소비할 수 있는 데이터다. 형식이 완벽해도 null이 0으로 읽히거나 "활성 고객"의 정의가 시스템마다 다르면, 그 데이터는 valid하지만 usable하지 않다.

이 간극은 놀라울 만큼 크다. Cloudera와 하버드 비즈니스 리뷰 애널리틱 서비스의 2026년 조사에서, 자사 데이터가 AI에 "완전히 준비됐다"고 답한 기업은 7%에 불과했다. Deloitte는 에이전트형 AI 배포에 적합한 데이터 아키텍처를 가진 기업을 14%로 집계한다. 두 수치는 정의가 다르지만 같은 방향을 가리킨다. 대다수 기업의 데이터는 '깨끗한' 상태에도 이르지 못했고, '쓸 수 있는' 상태와는 더 멀다.

가장 위험한 것은 이 간극을 메우는 방법에 대한 오해다. 같은 조사에서 기업의 47%가 "에이전트형 AI가 데이터 품질 문제를 알아서 해결해 줄 것"이라고 믿는다고 답했다. 앞의 다섯 섹션이 보여준 그림은 정반대다. 에이전트는 데이터 품질을 고쳐주기는커녕, 사람이라는 조정 버퍼를 제거해 결함을 증폭한다. 데이터 품질은 에이전트 도입의 결과물이 아니라 전제 조건이다.

그렇다면 '쓸 수 있는 데이터'의 조건은 명확하다. 여섯 종의 결함이 없고, 남은 예외에는 주인이 있는 상태다. Gartner가 2026년 "agent-ready data"를 "clean data"보다 구체화된 기준으로 용어집에 편입한 것도 같은 인식의 전환을 보여준다. 문제는 이 상태를 어떻게 측정하느냐다. 그런데 데이터 품질을 애초에 측정조차 하지 않는 기업이 59%에 이른다. 측정이 첫걸음이다.

페블러스 DataClinic은 데이터셋을 정량으로 진단해 '쓸 수 있는 상태'인지 판별하는 제품이다. 이 리포트가 해부한 여섯 결함 — 의미 드리프트, 중복, null, 타입, 스키마, 신선도 — 은 사실 DataClinic이 실제로 잡아내는 결함 축(무결성·분포·중복·결측)을 에이전트 운영의 언어로 다시 쓴 것이다. 그러니까 이 글은 추상적 담론이 아니라, 데이터 진단이라는 실무가 왜 필요한지를 결함 단위로 번역한 문서에 가깝다.

특히 3배 정확도 저하(60%→25%)와 신선도 탐지 전후(37.6%→8.6%)는 페블러스가 오래 지켜온 명제의 가장 깨끗한 증거다. 학습·입력 데이터의 결함은 모델과 에이전트의 행동으로 전파된다. 이 명제를 추상적 "품질 85%" 같은 숫자가 아니라, null→0 오독, 시스템마다 다른 필드, 낡은 컨텍스트 같은 결함 단위로 계량할 수 있다는 것 — 그것이 이 리포트가 도착한 자리다.

파일럿을 운영으로 넘기지 못하는 조직에 줄 수 있는 처방은 "모델을 더 튜닝하세요"가 아니다. "이 여섯 결함을 먼저 진단하고, 남은 예외에 주인을 지정하세요"다. 아래 표는 여섯 결함을 그대로 진단·소유권 체크리스트로 옮긴 것이다. 자기 조직의 파이프라인에서 조인과 핸드오프 지점마다 이 항목을 프로파일링하는 것이 첫걸음이 된다.

업계 리포트·설문

• 1.AgentMarketCap. (2026-04-11). The Enterprise Agent Deployment Maturity Model 2026: Why 86% of Companies Are Stuck in Pilot Purgatory.
• 2.Cloudera / HBR Analytic Services. (2026-03-05). Only 7% of Enterprises Say Their Data Is Completely Ready for AI. (n=230+)
• 3.Writer.com & Workplace Intelligence. (2026-04-07). Enterprise AI Adoption in 2026. (n=2,400)
• 4.Informatica. (2025). CDO Insights 2025. (n=600 data leaders)
• 5.Deloitte. (2026). State of AI in the Enterprise 2026. (N=3,235)
• 6.Landbase. (2026). Duplicate Record Rate Statistics: 32 Key Facts for 2026.
• 7.Liquibase. (2026). The Real AI Failure Mode: Data Quality at the Schema Layer, Not the Model.
• 8.Earley Information Science. (2026). Why Enterprise AI Stalls: Semantic Infrastructure.
• 9.EY / AIUC-1 Consortium. (2026-03). AI Ownership and Accountability Report. Forrester root-cause analysis 포함 (named agent owner, 2.7×).
• 10.Business Standard. (2026-06-30). Experts explain why enterprise AI projects struggle to move beyond pilots.
• 11.Gartner. (2025-06-25). Poor Data Quality Costs Organizations $12.9M Annually; Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.

학술 논문·기술 보고

• 12.MAST Research Team. (2025). MAST: A Multi-Agent System Failure Taxonomy. NeurIPS 2025. (1,600+ traces, 14 failure modes)
• 13.NANDini Research Team. (2026). Data Facts: A Metadata Schema for Structured Data Exchange in the NANDini Multi-Agent Ecosystem. arXiv: 2606.26211.
• 14.Agentic AI Fault Research Team. (2026). Characterizing Faults in Agentic AI: A Taxonomy of Types, Symptoms, and Root Causes. arXiv: 2603.06847.
• 15.Microsoft ISE Developer Blog. (2026). Separating Deterministic Extraction from AI Inference. (손실 직렬화)
• 16.RAND Corporation. (2024). Enterprise AI Project Failure Analysis. (80.3% 실패율, MECE 분류)
• 17.Lanham, M. (2026). LLM Output Compliance Without Schema Enforcement. Medium/@Micheal-Lanham. (스키마 강제 없는 준수율 <40%)

일부 수치(스키마 레이어 리스크 64%, 컨텍스트 드리프트 65% 등)는 단일 벤더 또는 비공식 합성 추정치로, 본문에서 "추정"으로 표기했다.