Agent-Native Data Exchange
모두가 데이터 웨어하우스를 에이전트에 맞게 준비하고 있다 — 그건 아키텍처의 틀린 끝에서 시작하는 것일지 모른다
핵심 개념
대부분의 조직은 더 큰 클러스터, 더 많은 복제본, 더 빠른 시맨틱 레이어, 더 강한 워크로드 통제를 같은 중앙 분석 시스템 주위에 추가하는 방식으로 에이전트를 준비한다. 현대 웨어하우스가 admission control·워크로드 격리·리소스 그룹·쿼터를 이미 제공하므로 통할 수도 있다.
하지만 그 접근은 에이전트가 공유 플랫폼에 접속하는 아주 빠른 분석가처럼 행동할 것이라고 가정한다.
Agent-native data exchange는 반대 모델을 시험한다: 모든 에이전트를 같은 분석 plane으로 라우팅하는 대신, 각 에이전트에게 자기 임베디드 분석 엔진을 주고 에이전트끼리 데이터 제품을 직접 교환하게 한다.
왜 웨어하우스 가정이 흔들리는가
전통적 웨어하우스·레이크하우스 운영 모델은 사람 속도의 분석 소비를 중심으로 조직되었다 — 예약 리포트, 대시보드, 탐색 쿼리.
사람은 매출이 하룻밤에 40% 떨어지면 멈춰서 비즈니스가 바뀐 건지 데이터가 깨진 건지 묻는다. 회의·문서·Slack·스프레드시트·과거 분석에서 온 암묵적 컨텍스트도 지니고 있다.
에이전트는 다르다.
| 차원 | 사람 | 에이전트 |
|---|---|---|
| 수 | 제한적 | 수가 많고 고도로 동시적 |
| fan-out | 없음 | 요청 하나가 여러 에이전트를 촉발하고 각자 추가 작업 생성 |
| 검사 시간 | 결과를 보고 판단 | 출력이 밀리초 안에 다운스트림으로 넘어가 중간 결과를 검사할 시간이 없음 |
| 암묵적 컨텍스트 | 제도적 지식 보유 | 명시되지 않으면 신선도·시맨틱 의도·비정상성을 추론할 수 없음 |
사람 분석가는 회계팀이 회의에서 명확히 해줘서 “revenue”가 환불 차감 후라는 걸 안다. 에이전트가 같은 제도적 지식을 일관되게 복원·적용하리라 신뢰할 수 없다.
결과적 압력: 높은 쿼리 동시성, 투기적·중복 작업, 중간 결과의 빠른 연쇄, 에러의 빠른 전파, 그리고 기계 검증 가능한 시맨틱·provenance·신선도·신뢰에 대한 강한 요구.
중앙 시스템을 스케일하면 상당 부분 수용할 수 있지만, 엄격한 워크로드 격리 없이는 투기적 에이전트 트래픽이 다른 사용자를 방해하고, 시맨틱 정의가 구현에서 drift할 수 있고, 사람 리뷰를 전제로 설계된 거버넌스 프로세스가 자율적 데이터 교환과 같은 속도로 작동하지 않을 수 있다.
Peer 모델
각 에이전트(peer)가 자기 임베디드 분석 엔진, 로컬 캐시, mesh 접근, 선택적으로 system of record 직접 연결을 갖는다. 대부분의 peer는 웨어하우스와 직접 통신하지 않고 다른 peer에서 immutable 분석 slice를 가져온다.
에이전트의 역할이 바뀐다 — 더 이상 데이터 플랫폼의 클라이언트일 뿐이 아니라 분석 데이터를 보유하고, peer에게 서빙하고, 보유한 것에서 새 제품을 파생할 수 있다.
Data Mesh 용어로 소유권이 더 구체적이 된다. 도메인이 공유 웨어하우스 안의 스키마를 “소유”하는 데 그치지 않고 자기 제품을 물리적으로 보유·서빙하는 엔진을 운영한다.
에이전트 자체는 disposable로 남는다 — 생성되고, 작업하고, durable 결과를 넘기고, 회수된다. 프로세스와 포트는 사라지지만 만든 제품은 durable holder에 남는다.
데이터 경로를 탈중앙화해도 control plane은 여전히 필요하다 — 발견, 라우팅, 인가, 신선도 조율.
Immutable slice — 교환의 단위
에이전트는 “최신”이라는 미검증 개념을 교환하지 않는다. “최신”은 mutable해서 지금은 이 스냅샷, 잠시 후엔 저 스냅샷으로 해소될 수 있다.
라이브 대시보드와 스크린샷의 차이. 라이브 대시보드는 읽는 동안 바뀔 수 있고, 스크린샷은 하나의 고정된 상태를 나타낸다.
slice 참조가 식별하는 것:
| 필드 | 식별 대상 |
|---|---|
| catalog / dataset / snapshot | 어느 데이터베이스 상태에서 나왔나 |
| slice digest | materialize된 콘텐츠 자체 (DB 상태만이 아니라 정확한 내용) |
| contract digest | 데이터가 해석되어야 할 시맨틱 아티팩트 |
데이터가 바뀌면 기존 slice를 변형하지 않고 새 참조를 만든다.
이것이 모든 캐시 일관성 문제를 없애지는 않는다. “newest” 같은 mutable alias, 라우팅 레코드, 인가 상태, revocation, holder 가용성은 여전히 control-plane 관심사다. 좁은 이득은 pinned된 분석 콘텐츠가 더 이상 무효화·조정을 요구하지 않는다는 것이다.
계약 3계층
기존 data contract 작업은 생산자에 집중했다 — 스키마를 게시하고 컬럼을 기술하고 조용히 바꾸지 않겠다고 약속. 필요하지만, 소비자의 가정은 대체로 암묵적으로 남는다(쿼리·대시보드·문서·원래 만든 분석가의 기억 안에).
에이전트에게는 그 가정이 기계 검증 가능한 아티팩트로 표현되어야 한다.
1. Semantic contract
생산자의 계약을 실행 가능한 시맨틱 모델(예: Malloy)로 표현하고 해시해 slice 참조에 포함한다. 그러면 다른 계약 파일을 쓰는 두 에이전트는 다르게 이름 붙은 slice를 가리키게 된다.
sum(qty * unit_price)를 sum(qty * unit_price) * 0.9로 바꾸면 digest가 바뀌고 참조가 바뀌어 — 시맨틱 불일치가 다운스트림 계산 안에 숨지 않고 교환·해소 시점에 드러난다.
다만 해시가 의미를 증명하지는 않는다. 같은 모델도 다른 엔진 버전·런타임 설정·외부 아티팩트에서 다르게 해석될 수 있으므로, 프로덕션 시맨틱 identity는 실행 관련 컨텍스트(엔진 버전, dialect, 런타임 설정, 의존성 digest)를 포함해야 한다. 주장은 해시가 의미를 증명한다는 게 아니라 명시적 시맨틱 아티팩트가 제품 identity의 일부가 된다는 것.
2. Compatibility relation
콘텐츠 해시는 바이트 단위 동일성만 말한다. 호환성은 판단할 수 없다.
- 포맷 변경(
sum(qty * unit_price)vssum(qty*unit_price))이 의미를 안 바꾸면서 해시를 바꾼다 - 더 중요하게, additive 변경과 breaking 재정의가 둘 다 그냥 “다른 해시”로만 보인다
그래서 모델을 정규화된 스펙으로 파싱해 measure·query·source·의존성·실행 컨텍스트를 기록하고 비교한다: IDENTICAL / ADDITIVE / BREAKING / UNRELATED.
BREAKING이 가장 중요하다. 두 에이전트가 gross_revenue를 쓰는데 하나는 환불 전, 하나는 환불 후로 정의한다면 둘 다 내부적으로 유효하지만 출력을 동등하게 취급해서는 안 된다.
단, 계약 호환이 두 결과를 합쳐도 안전하다는 뜻은 아니다. 기저 slice가 겹치거나 다른 grain·기간·통화·모집단일 수 있다. 계약 호환성은 “한 계약이 다른 계약이 요구하는 정의를 보존하는가”만 답하고, 결합 가능성은 grain·파티션·시간 커버리지·단위·차원 도메인·중복·집계 동작을 고려하는 별도의 composition 규칙이 정해야 한다.
3. Intent contract
소비자의 요구사항. 에이전트는 어떤 스냅샷이 있는지 모를 수 있으므로 스냅샷 ID를 직접 요청해서는 안 되고, 원하는 데이터셋 + 요구하는 시맨틱 정의 + 신선도 선호를 진술한다.
Intent → resolve against catalog → pinned SliceRef
가용한 모든 계약이 소비자가 의존하는 measure를 바꾸면 해소가 실패한다. 소비자가 무엇을 받아들일 준비가 되었는지 선언하고 교환이 가용 제품을 그 선언에 대조하는 구조다.
Provenance — 파생 데이터는 스스로를 승격할 수 없다
탈중앙 시스템은 authoritative source 데이터와 에이전트가 파생한 데이터를 구별해야 한다.
모든 slice에 provenance tier를 부여하고, 파생 slice는 authoritative source를 명시적으로 요구하는 요청을 만족시킬 수 없게 한다 (refusing to launder provenance). tier는 서명된 아티팩트와 함께 이동한다 — mutable side table에만 두면 잃거나 재작성하기 쉬워진다.
단일 tier 플래그로는 여러 파생 단계 후의 출처를 설명하기 부족하므로 각 slice가 lineage DAG를 지닌다. 노드마다 입력·선언된 연산·생산 principal·tier·digest·서명을 담고, 각 노드의 digest가 입력들의 digest를 커버하므로 이전 노드를 바꾸면 위쪽이 전부 바뀐다.
검증의 한계를 정직하게 볼 것: 체인 무결성과 root가 신뢰 정책을 만족하는지는 확인하지만, 기저 데이터가 올바른지, 선언된 연산이 충실히 실행됐는지, 관련 입력이 빠지지 않았는지는 증명하지 않는다. 서명은 principal이 attestation을 했다는 것을 증명할 뿐 그 진술의 참을 증명하지 않는다. → AI Agent Identity and Security
Data Mesh 반론: 웨어하우스 하나가 신뢰 데이터의 유일한 origin이면 P2P 전송 아래 중앙 권위를 보존한 것 아닌가? 답은 권위가 제품 단위로 스코프된다는 것이다. 한 시스템이 orders에 authoritative이고 다른 도메인 시스템이 고객 지원에 authoritative일 수 있다. peer는 데이터를 보유·서빙하는 능력에서는 대칭이지만 provenance 권위에서는 동등하지 않다.
컴퓨트를 데이터 쪽으로
에이전트 무리는 필요한 결과가 집계값 하나일 때 큰 slice를 전송할 여유가 없다. 같은 slice가 전체 데이터셋 · 필터 결과 · 집계 · 계약 · provenance proof로 소비될 수 있어야 한다.
원격 쿼리 pushdown은 심각한 보안 경계다. 신뢰되지 않는 peer에게 다른 peer의 DB 연결에 무제한 SQL 접근을 주면 무관한 테이블 접근, 로컬 파일 검사, 확장 호출, 상태 변형, 무제한 리소스 소비가 가능하다. 필요한 것: read-only 격리 프로세스, 참조된 slice만 노출하는 capability-scoped 뷰, 제한된 쿼리 문법 또는 검증된 논리 플랜, CPU·메모리 한도, timeout, row 한도, 확장 제한, 파일·네트워크 통제.
검증 gap도 남는다: 서명된 입력이 원격 peer가 올바른 집계를 반환했음을 증명하지 않는다. 악의적이거나 침해된 holder는 입력 provenance가 유효해도 틀린 결과를 반환할 수 있고, 이를 다루려면 재현 가능한 로컬 실행, 복제 계산, TEE, 서명된 런타임 attestation 같은 별도 메커니즘이 필요하다.
LLM이 있어야 할 자리
아키텍처는 에이전트를 위한 것이지만 핵심 신뢰 결정은 결정론적이어야 한다.
계약 해싱, 구조적 비교, intent 해소, 스냅샷 pinning, digest 검증, 서명 확인, 신뢰 정책 강제는 같은 입력에 대해 모든 peer에서 같은 결과를 내야 한다.
계약 변경이 IDENTICAL인지 BREAKING인지를 LLM에게 결정하게 하면 호환성 경계가 확률적이 되고, 두 모델이 두 지표를 함께 써도 되는지에 대해 다른 결론에 도달할 수 있다.
LLM은 모호한 요청을 구조화된 intent로 번역하는 데 적합하다.
모델이 intent를 제안하고, 결정론적 코어가 검증·해소한다. 모델이 존재하지 않는 measure를 지어내거나 없는 계약을 요구하면 해소가 실패해야 하고, 모델은 그럴듯한 설명을 생산하는 것만으로 slice를 신뢰할 만하다고 선언할 수 없다.
남는 어려움
- 레지스트리로 병목이 옮겨간다 — 디렉토리는 분석 바이트를 서빙하지 않으므로 웨어하우스보다 네임서버에 가깝지만, DNS도 계층·위임·복제·캐싱·TTL과 많은 운영 기계로 확장한다. 침해된 레지스트리는 옛 참조를 replay하거나, revocation을 억제하거나, 클라이언트마다 다른 말을 하거나, 악의적 holder로 라우팅할 수 있다. 서명이 무단 치환은 막지만 신선도나 가용성을 자동으로 주지는 않는다
- 다중 홉 실패 디버깅 — 각 slice가 lineage를 지니므로 “이 아티팩트가 어디서 왔나”는 답하기 쉬워지고, 그 lineage는 생산한 peer가 사라진 뒤에도 남는다. 하지만 분산 트레이싱, 메트릭, 리소스 회계, admission control, revocation, 감사 로그, 이상 탐지, 쿼리 격리, fleet 관리는 여전히 필요하다
연관 개념
- Data Mesh and Federation
- Data Contracts
- Semantic Layer
- DuckDB
- Catalog-Managed Tables
- AI Agent Identity and Security
- Knowledge Spine
- AI Agent
- Idempotency
Source: To Every Agent Its Own Database