AI 시대에 더 이상 데이터를 이동시키고 싶지 않은 이유

기업 데이터 팀은 단 하나의 이야기, 즉 '먼저 중앙 집중화하고, 그다음에 분석하라'는 교육을 받아왔습니다. 우리는 CRM 행(row)을 데이터 웨어하우스(warehouse)로 가져옵니다. 재무 데이터를 데이터 레이크(lake)로 스냅샷(snapshot)합니다. 문서를 검색 인덱스(search index)로 내보냅니다. 임베딩(embeddings)을 위해 모든 것을 청크(chunk)로 나눕니다. 그리고 상위 50개의 청크를 모든 에이전트 프롬프트(agent prompt)에 붙여넣습니다.

데이터를 한곳에 모아 사람이 보고서를 실행할 수 있게 하는 것이 어려운 문제였던 시절에는 그 이야기가 말이 되었습니다. 하지만 에이전트가 몇 초마다 CRM, 급여, 티켓, 계약, 그리고 결코 복제되어서는 안 될 API를 가로질러 질문을 던지기 시작한 순간부터 그 이야기는 설득력을 잃었습니다.

데이터를 이동시키는 것은 결코 공짜가 아니었습니다. AI 시대에 데이터 이동은 로드맵 상에서 가장 비용이 많이 드는 실수가 되었습니다.

그래서 우리는 새로운 것을 만들었습니다:

AI 시대가 변화시킨 것들

1. 신선도(Freshness)가 제품 요구 사항이 되었습니다
   월요일 대시보드를 위한 야간 ETL 작업은 괜찮았습니다. 하지만 사용자가 오후 4시 47분에 에이전트에게 5분 전 고객의 권한(entitlement)이 변경되었는지 물어볼 때는 괜찮지 않습니다. 모든 복사본은 지연(lag)을 발생시키며, 에이전트는 확신에 찬 언어로 오래된 답변을 증폭시킵니다.

2. 토큰 경제학(Token economics)은 "모두 쏟아붓기"를 처벌합니다
   수백만 개의 행을 다시 임베딩(re-embedding)하고, 웨어하우스 샘플을 다시 보내고, 문서 코퍼스(corpora)를 컨텍스트(context)에 채워 넣는 방식은 확장(scale)할 수 없습니다. 팀들은 라이브 시스템을 통한 범위 지정 쿼리(scoped queries)와 비교했을 때, 동일한 질문임에도 불구하고 비용은 훨씬 적게 들면서 토큰 소모량은 수십 배에 달한다고 보고합니다.

3. 컴플라이언스(Compliance)는 복사본을 따라갑니다
   GDPR, HIPAA, SOC 2, 그리고 고객 DPA는 데이터가 어디에 '있어야 하는지'가 아니라 실제로 어디에 '살고 있는지'에 관심을 가집니다. 모든 레이크(lake), 인덱스(index), 벡터 스토어(vector store)는 감사(audit), 침해(breach), 그리고 설명해야 할 새로운 접점(surface)이 됩니다. 컴플라이언스 범위를 만든 것은 에이전트가 아니라 여러분의 파이프라인(pipeline)입니다.

4. 복사본은 진실(truth)로부터 멀어집니다
   소스 시스템은 컬럼(column) 이름을 변경하고, 테이블을 폐기하며, 잘못된 행을 지속적으로 수정합니다.

S3나 Pinecone에 있는 그림자 사본(shadow copy)은 표류합니다. 에이전트는 그림자 사본으로부터 답변하고, 재무팀은 원본 시스템에서 장부를 마감합니다. 이것은 환각(hallucination)이 아니라 아키텍처 불일치(architecture mismatch)입니다.

데이터를 이동시킬 것인가 vs. 제자리에서 질의할 것인가

모든 것을 이동시키기 (Move everything)
ETL → 레이크(lake) → 웨어하우스(warehouse) → 임베딩(embeddings) → RAG → 프롬프트(prompt). 구축에 높은 지연 시간(latency)이 필요하고, 실행 비용이 높으며, 어떤 행(row)이 답변을 승인했는지 증명하기 어렵고, 접근 규칙이 역할별로 다를 경우 고통스럽습니다.

제자리에서 질의하기 (Query in place)
에이전트가 비즈니스 용어로 질문하면 → 추론 계층(reasoning layer)이 실시간 소스(live sources)에 매핑되고 → 통제된 가져오기(governed fetch)를 통해 증명 번들(proof bundle)을 얻습니다. 기록은 이미 속해 있는 Postgres, Salesforce, MongoDB, CSV, REST API에 그대로 남아 있습니다.

RAG는 데이터 전략이 아닙니다
검색 증강 생성(Retrieval-augmented generation)은 좁은 문제, 즉 모델에게 관련 텍스트를 제공하는 문제를 해결했습니다. 그것은 관계(

Anything Graph CLI는 오늘날 개발자들을 위해 이 패턴을 구현합니다: SQL, CSV, Salesforce, MySQL, SQL Server, MongoDB 및 REST를 위한 오픈 소스 어댑터(open-source adapters)를 제공합니다. Cursor나 Claude에서 MCP를 연결하고, 플레이북(playbook) 용어로 질문하면, 프롬프트 덤프(prompt dump)에 아무것도 복사하지 않고도 라이브 데이터(live data)로부터 답변을 얻을 수 있습니다.

복사가 여전히 유효한 경우
우리는 분석 웨어하우스(analytics warehouses)나 아카이브 저장소(archival storage)에 반대하는 것이 아닙니다. 집계(Aggregates), 역사적 트렌드(historical trends), 그리고 규제된 보존(regulated retention)은 여전히 목적에 맞게 구축된 시스템에 속해야 합니다.

변화의 핵심은 더 좁고 더 시급합니다: 기본적으로 운영 데이터(operational data)를 에이전트 컨텍스트 경로(agent context path)로 복사하지 마십시오. 복사가 도움이 되는 곳에서는 학습(Train), 배치 보고(batch-report), 아카이브(archive)를 수행하십시오. 에이전트에게는 진실이 이미 존재하는 곳에서 답변을 제공하십시오.

결론
AI 시대가 데이터 중력(data gravity)을 제거한 것은 아닙니다. 오히려 토큰 비용(token bills), 컴플라이언스 검토(compliance reviews), 그리고 그럴듯하게 들리는 오답(wrong answers)을 통해 데이터 중복을 가시화했을 뿐입니다.

프로덕션 에이전트(production agents)를 출시하는 팀들은 동일한 아키텍처로 수렴하고 있습니다: 연합 쿼리(federated query), 관리되는 어휘(governed vocabulary), 모든 답변에 대한 증명(proof on every reply). 더 적은 파이프라인(pipeline). 더 적은 지연(lag). 더 적은 리스크(risk).

AI를 위해 데이터를 이동시키는 것을 멈추십시오. 데이터가 이미 존재하는 곳에서 데이터에 대해 추론(reasoning)하기 시작하십시오.