Data Eng Wiki

Making Your Data Ready for Agentic AI

52 min read

Making Your Data Ready for Agentic AI

Author: Pramod Sadalage, Prem Chandrasekaran (Thoughtworks) | Source: martinfowler.com | Published: 2026-08-27

한 줄 요약

인간은 이상해 보이는 데이터에서 멈추지만 에이전트는 그냥 행동한다 — 30년간 인간을 위해 만든 데이터 아키텍처를 전혀 다른 소비자에게 넘기는 지금, 사람이 공짜로 해주던 다섯 가지 일(신뢰·맥락·추적·거버넌스·실행)을 데이터 자체에 밀어 넣어야 하고, 그것을 contract → context layer → access, 관통하는 observability 라는 의존 순서로 쌓아야 한다.

핵심 주장/내용

  • 데이터의 소비자가 바뀌고 있다: 30년 넘게 인간을 위한 데이터 시스템을 만들었다. 대시보드, 리포트, 분석가 쿼리 — 전부 화면 앞에 앉은 사람을 중심으로 설계되었고, 그게 작동한 이유는 인간이 엄청난 양의 암묵적 컨텍스트를, 그리고 부족한 것을 주변 사람에게 추적해 알아내는 호기심을 가져오기 때문이다
    • 인간 분석가는 당신 조직에서 “revenue”가 무엇을 뜻하는지 안다. 어떤 테이블을 쿼리하고 어떤 것을 피할지 안다. 숫자가 이상해 보일 때, 합계가 수상하게 딱 떨어질 때, 날짜가 공휴일에 걸릴 때, 가격이 너무 낮아 보일 때를 알아챈다. 그 본능이 막대한 양의 보이지 않는 컨텍스트·지식 노동을 하고 있다
    • 에이전트에게는 그런 것이 전혀 없다. 수년간 축적한 tribal knowledge와 패턴 인식에 기댈 수 없으므로 컨텍스트를 명시적으로, 접근을 실시간으로, 신뢰할 수 있는 품질을 필요로 한다. 가장 중요한 차이: 데이터가 이상하게 느껴질 때 인간은 다시 확인하지만 에이전트는 자신 있게 그것에 따라 행동한다
  • “AI-ready”가 이제 뜻해야 하는 것 — 다섯 속성: 인간 소비자에게는 데이터가 충분히 좋기만 하면 됐고 나머지는 분석가가 했다. 의미, 온전성 확인, 숫자를 믿을 수 있는지에 대한 판단이 전부 사람 머릿속에 살았다. 에이전트에게 넘기면 그 암묵적 노동의 모든 조각이 데이터 자체로 옮겨가야 한다
속성인간이 공짜로 해주던 일이제 데이터가 해야 하는 일
Trusted이상한 숫자에서 멈춤에이전트가 보기 전에 정확·신선·검증
Contextual”revenue는 이미 반품 제외”, “회계연도는 2월 시작”을 앎의미를 데이터에 명시
Traceable나중에 왜 그랬는지 설명 가능30초 만에 결정하므로 일어나는 순간 포착하지 않으면 추론이 사라짐
Governed역할과 판단으로 접근이 한정됨설계로 한정되어야 함
Operational대시보드를 읽고 가서 뭔가를 함읽을 수 있는 게 아니라 행동 가능해야 함
  • 다섯 가지 모두 같은 생각에 귀결된다. 각각은 인간이 생각 없이 하던 일이고 이제 데이터 자체로 밀려났다. 하나를 놓치면 에이전트는 사람처럼 우아하게 저하되지 않는다. 자신 있게 실패한다

주제 1 — Data Contracts and Quality: 에이전트는 나쁜 데이터 냄새를 못 맡는다

  • Simon Willison의 표현대로 언어 모델은 gullible하다 — 넘겨받은 것을 믿고 그것에 따라 행동한다. 틀린 값을 먹이면 멈춰서 의심하지 않고, 그 숫자를 써서 자신 있고 틀린 답을 낸다
  • 구체적 시나리오: pricing 에이전트가 Product X의 현재 가격을 요청받는다. 어제 가격이 59.99로 갱신됐지만 데이터 소스가 갱신되지 않아 여전히 옛 숫자를 보여준다. 에이전트는 망설이지 않는다. 10를 잃는다. 에이전트가 밟은 모든 단계가 기술적으로 옳았다. 워크플로를 완벽히 따랐다. 문제는 접근한 데이터였다
    • 인간 영업 담당자였다면 멈췄을 것이다: “잠깐, 지난주에 이거 갱신하지 않았나?” 제도적 기억과 뭔가 이상할 때의 감각이 있다. 에이전트는 둘 다 없다. 오류가 경고를 트리거하지 않고 워크플로를 통해 조용히 캐스케이드된다
  • 해법: 스키마는 법 — 코드로서의 data contract. 이것은 “schemaless가 유연하다”는 10년의 사고를 뒤집는다. 인간 소비자에게 느슨한 스키마는 단지 불편할 뿐이지만, AI 에이전트에게는 위험하다
    • Open Data Contract Standard로 작성 (Data Contract CLI가 쓰는 포맷, Thoughtworks tech radar 33 권고). product_pricing contract 예:
      • 엄격한 logical type의 property
      • price > 0 품질 규칙
      • currency가 USD/EUR/GBP 밖이면 거부
      • 결정적으로 freshness SLA — 가격 데이터는 최근 24시간 내에 갱신되었어야 한다
      slaProperties:
  - property: latency
    value: 24
    unit: h
    element: product_pricing.ingested_at
    • 집행은 세 차원: 스키마 집행(타입·제약을 contract가 명시) / freshness SLA(데이터셋별 최대 허용 staleness. 에이전트가 실시간으로 답할 때 야간 배치 갱신으로는 부족하다. ⚠️ SLA를 값이 마지막으로 바뀐 시점이 아니라 데이터가 마지막으로 성공적으로 적재된 시점에 키잉하라 — 그래야 변화 없는 데이터가 stale로 플래그되지 않고, 멈춘 파이프라인이 fresh인 척할 수 없다) / 품질 게이트(CI/CD에서 contract 검증, 실패 시 배포 차단)
    • 가격 시나리오가 설계로 방지된다 — 24시간 내 갱신이 없으면 에이전트가 데이터를 보기 전에 contract가 위반된다
  • quarantine 패턴 — circuit breaker: raw 데이터가 소스 시스템·API·DB·스트림에서 도착 → 에이전트 접근 가능 스토어에 들어가기 전에 contract validation gate (스키마 일치? freshness SLA 내? 품질 규칙 통과?) → 셋 다 통과하면 certified, agent-ready tier로, 하나라도 실패하면 quarantine — 인간 리뷰용 dead letter queue로 라우팅하고 알림 발사
    • 핵심은 에이전트가 나쁜 데이터를 결코 보지 않는다는 것. 가격 시나리오에서 ingested_at이 24시간보다 오래되면 레코드가 격리되어 에이전트는 “현재 가격 데이터가 없습니다”라고 말한다 — 자신 있게 틀린 숫자를 인용하는 대신. 훨씬 나은 실패 모드다
    • 그리고 이것은 모델이 아니라 데이터 아키텍처의 일이다. 더 나은 모델이 나쁜 데이터에서 당신을 구해주지 않는다
  • 에이전트를 위한 Medallion 아키텍처 + 네 번째 tier:
    • Bronze — raw, 불변 인제스션. 감사 추적과 리니지를 위해 전부 보관
    • Silver — 검증·중복 제거. 스키마 적용, data contract 집행, quarantine 패턴이 사는 곳
    • Gold — certified. 시맨틱 모델이 컴파일하는 대상, 접근이 거버넌스되고 지표가 신뢰됨
    • Adaptive Gold (신규) — 에이전트가 소비만 하는 게 아니라 데이터를 큐레이션한다. 자기 쿼리 패턴을 관찰해 계속 손을 뻗는 조합을 materialize하고, 실제 사용에서 warehouse view를 만든다. 가설이 아니다 — DataHub CONTEXT 2025 서밋에서 Apple이 자사 데이터 카탈로그의 “digital steward” 로 행동하며 메타데이터를 지속 스캔하고 격차를 플래그하고 갱신을 제안하는 에이전트를 설명했다. Apple의 에이전트는 카탈로그를 큐레이션하고, Adaptive Gold는 같은 패턴을 데이터셋에 겨눈다
    • 핵심 아키텍처 원칙: 에이전트는 Gold tier 이상에만 접근해야 한다. Bronze와 Silver는 리니지·디버깅·인간 조사를 위해 존재한다. raw나 부분 검증된 데이터를 에이전트에 노출하는 것은 가격 문제를 다시 초대하는 것
  • 비정형 데이터에도 같은 규칙: 에이전트가 소비하는 것 대부분은 표가 아니라 문서·위키·PDF·서포트 티켓이고, chunk되어 vector store에 임베딩된다. 문단에 price > 0을 쓸 수는 없지만 패턴은 그대로 이전되고 품질 차원만 바뀐다
    • stale-price 시나리오의 쌍둥이: 정책 문서가 갱신됐는데 vector index가 재임베딩되지 않아 에이전트가 옛 버전을 가져와 자신 있게 답한다 — 행이 아니라 임베딩일 뿐 같은 실패
    • freshness SLA가 이전되되 시계가 무엇을 재는지 정확히 하라 — 콘텐츠가 마지막으로 바뀐 때가 아니라 인덱스가 소스에 대해 마지막으로 성공적으로 재구축된 때다. 24시간 SLA는 재인덱싱 잡이 최근 24시간 내에 완료되었어야 한다는 뜻이고, 아니면 아무것도 안 바뀐 것처럼 보여도 인덱스가 stale이고 격리된다. 조용히 실패한 indexer야말로 뭔가 바뀌었는지 알 수 없는 바로 그 상황이기 때문이다. 그 heartbeat 하나가 갱신됐지만 인덱싱 안 된 문서와 조용히 멈춘 파이프라인을 둘 다 잡는다
    • contract는 콘텐츠에서 주변 메타데이터로 옮겨간다 — 산문을 제약할 수는 없지만 모든 chunk가 source·version·timestamp·access scope를 지니도록 요구하고 없는 것을 거부할 수 있다. 그 메타데이터가 나중에 검색을 traceable하고 governable하게 만드는 것이기도 하다
    • 품질 게이트는 텍스트에 맞는 검사로 — 빈/잘린 chunk 거부, 검색을 왜곡하는 near-duplicate 문서 포착, 실패한 추출·OCR 쓰레기 플래그, embedding drift 감시. 잘못되거나 빈 임베딩이 유사도 검색을 왜곡하므로 store에 도달하지 않게 한다 — 나쁜 가격이 에이전트에 도달하지 않는 것과 같은 이유로, 왜곡된 인덱스는 에이전트가 자신 있게 틀린 콘텐츠를 검색하게 만든다
  • confidence-threshold routing — 회색 지대: contract·quarantine·medallion이 명확한 케이스를 다루지만 명백히 나쁘지도, 완전히 신뢰할 만하지도 않은 회색 지대가 있다
    • 에이전트가 요청을 처리하며 모델 confidence만이 아니라 freshness·completeness·consistency 같은 데이터 수준 신호를 확인한다. 임계(예: 85%) 이상이면 자율 진행, 미만이면 인간에게 위임. 임계는 유스케이스별로 설정 — pricing은 90%, 사내 FAQ는 70%로도 충분
    • 가격 데이터가 3일 stale이고 SLA가 24시간이면, 모델 자신이 답에 얼마나 확신하든 상관없이 SLA 위반이 자동으로 confidence를 임계 아래로 끌어내린다 → “이 가격이 현재 것인지 확신할 수 없습니다. 검증을 위해 사람에게 라우팅합니다”
    • 데이터 품질 신호가 임계를 주도해야 한다. 모델은 stale한 답에 확신할 수 있고, freshness SLA가 그 잘못된 확신을 무효화한다
    • 어려운 부분은 그 품질 신호를 단일 점수로 바꿔 모델 자신의 confidence와 저울질하는 것이고, 이것은 열린 설계 문제이지 풀린 문제가 아니다. 매끄러운 composite보다 hard gate로 시작하라 — 어떤 contract·SLA 위반이든 다른 신호가 어떻게 보이든 인간을 강제한다. 가중 점수는 나중에, 그것이 그 단순 규칙을 이긴다고 보여줄 수 있을 때만 추가하라
  • 어디서 시작할까: ① 에이전트가 건드리는 모든 데이터셋에 freshness SLA 정의 (같은 데이터셋도 소비자별로 요구가 다를 수 있다 — 대시보드에는 야간 배치로 충분한 가격 테이블이 quoting 에이전트가 의존하면 근실시간 갱신이 필요할 수 있다) ② quarantine gate 구현 (가격·재고·고객 레코드 같은 최고 위험 데이터셋부터) ③ Data Contract CLI로 시작 (contract 거버넌스를 CI/CD로, YAML로 정의, 자동 검증, 실패 시 배포 차단. API contract에 줄 것과 같은 엄격함으로 data contract를 다뤄라) ④ confidence threshold routing 추가 (90% 정도로 높게 시작해 신뢰를 쌓고 정확도를 추적하며 낮춰라)

주제 2 — Traceability and Governance: 자율 에이전트 감사하기

  • audit gap: 은행이 trade finance에 agentic AI를 돌린다. 에이전트가 letter of credit을 처리하고 KYC를 확인하고 제재 목록을 검증하고 신용 조건을 평가해 $2.4M 거래를 약 30초 만에 승인한다. 6개월 뒤 규제 당국이 단순한 질문을 한다: “왜 승인되었나?”
    • 전통적 감사 로그는 무엇이 일어났는지 — 어떤 테이블이 언제 어떤 서비스 계정으로 쿼리되었는지 — 말할 수 있지만 왜는 말할 수 없다. 왜 신용 조건보다 제재 목록을 먼저 확인했나? 왜 사소한 문서 불일치에도 승인했나? 어떤 대안을 고려하고 기각했나? “무엇”과 “왜” 사이의 격차가 규제 리스크가 발생하는 곳이고, EU AI Act Article 12가 고위험 시스템에 자동 로그를 요구하는 것이 정확히 그 이유다
  • agentic lineage: 전통 리니지가 어떤 소스가 접근되었는지를 추적한다면, agentic lineage는 왜 에이전트가 X에 접근하기로 결정했는지 — 소스 Z에서 Y를 찾았기 때문에 를 추적한다
    • trade finance 케이스에서 하나의 trace가 LC-4892 처리의 end-to-end 워크플로를 나타내고, 각 span이 개별 단계다:
      • Span 1: compliance DB에서 고객 KYC 검색 → verified
      • Span 2: OFAC API로 제재 목록 확인 → clear
      • Span 3: 정책 엔진에 신용 조건 평가 → 한도 내
      • Final span: APPROVE 결정, 94% confidence, 전체 추론 체인 첨부
    • 이것이 정확히 규제 당국이 필요로 하는 것이다. “에이전트가 14:32:07 UTC에 compliance DB에 접근했다”가 아니라 “에이전트가 KYC를 먼저, 그다음 제재, 그다음 신용 조건을 확인했고 셋 다 통과해서 승인했다”
    • traces and spans 모델은 분산 시스템 관측성에서 직접 빌려온 것이므로 엔지니어는 Jaeger·Zipkin으로 이미 멘탈 모델을 안다. agentic 등가물로 Langfuse, Arize Phoenix, OpenTelemetry for AI (Thoughtworks Radar: OpenTelemetry는 Adopt, Langfuse는 Trial, Arize Phoenix는 Assess)
  • 규제의 이빨은 실재한다: EU AI Act Article 12 — 고위험 AI 시스템은 운영을 추적할 수 있도록 수명 전체에 걸쳐 이벤트를 자동 로깅해야 한다. Article 19 — 제공자는 그 로그를 최소 6개월 보관해야 한다. 위반은 중간 벌칙 tier — 최대 €1,500만 또는 전 세계 연매출의 3% 중 큰 쪽. 대기업이면 3%도 수억 유로
    • 아키텍처에 대한 세 가지 의무: 수명 전체 이벤트 자동 로깅(고립된 타임스탬프가 아니라 어떻게 운영되었는지 추적할 만큼) / 최소 6개월 보관(관측성 인프라가 장기 저장을 다뤄야) / 사후 “왜”의 재구성 가능 (법은 로그를 요구하고, 그것이 규제 당국의 질문에 답하게 만드는 것은 당신 몫이다 — 어떤 소스를 참조했고 어떤 로직이 적용됐고 어떤 대안을 저울질하고 기각했는지 를 포함한 전체 추론 체인 포착)
    • EU가 가장 앞서 있고 지금은 다른 관할권에 이런 법이 없다. 하지만 규제가 어디에 착지할지에 베팅할 필요는 없다. 조만간 무언가가 — 규제 당국이든, 감사인이든, 결정에 이의를 제기하는 고객이든, 그냥 디버깅하려는 당신 팀이든 — 에이전트가 왜 그랬는지 묻게 만들 것이다. 설명할 수 없는 시스템은 완전히 신뢰하거나 방어하거나 고칠 수 없는 시스템이다
  • staged autonomy — 자율성은 단계적으로 얻는 것:
단계에이전트인간모니터링
Shadow Mode행동을 추천추천을 리뷰하고 적절하면 실행모든 추천을 로깅해 정확도 추적
Supervised행동을 준비하고 승인 대기리뷰 후 승인/거부제안된 행동과 인간 결정 모두 로깅
Autonomous with guardrails정의된 경계 안에서 행동 (경계는 거래 금액이 아니라 reversibility로 그리는 게 최선)guardrail 정의모든 행동 로깅, 예외 시 알림
Full autonomy모든 행동 수행spot check다른 에이전트와 인간에 의한 지속적 감시
  • 신입에게 첫날 법인카드를 주지 않는다. 구매 요청으로 시작해 감독받는 지출로 올라가고 결국 한도가 있는 카드를 얻는다. 에이전트도 같은 방식으로 신뢰를 얻어야 한다
  • 이 사다리를 오르는 승진은 감이 아니라 증거에 달려야 한다. 프로덕션에서 지켜보는 것만이 아니라 각 단계 전에 테스트해야 한다. 에이전트는 테스트하기 어렵다 — 비결정적이고, 호출 비용이 크고, 실제 부작용이 있는 도구를 통해 행동한다. 그래서 팀은 도구·모델 상호작용을 mock하거나 replay해 CI에서 결정적으로 테스트를 돌리고, 매번 라이브 서비스를 호출하는 대신 eval로 에이전트 결정을 점수화한다
  • 위임 접근과 just-in-time 자격증명 — 세 가지 보안 패턴:
    • Delegated Access — Alice가 자기 계정을 확인해달라고 하면 에이전트는 모든 고객 데이터를 볼 수 있는 넓은 서비스 계정이 아니라 Alice의 권한으로 행동해야 한다. 공유 서비스 계정은 귀속(attribution)을 파괴한다. “누가 이 고객 데이터에 접근했나?”에 “서비스 계정”은 거의 아무것도 말해주지 않는다. 위임 접근으로는 “Alice의 에이전트가 Alice를 대신해 Alice의 권한으로”
    • Just-in-time Credentials — 만료되지 않는 영속 API 키 대신 각 작업에 단명 토큰. 제재 목록 확인이 필요하면 그 특정 고객에 대한 OFAC API 읽기로 스코프된 5분짜리 토큰. 작업 완료 시 만료. 탈취되기를 기다리는 상시 자격증명이 없다
    • Least Privilege — 작업이 요구하는 최소 접근. letter of credit 처리에 HR 시스템이나 마케팅 데이터가 필요하지 않다
    • 이 셋이 agentic 시스템에서 가장 날카로운 보안 위험을 방어한다. Simon Willison이 lethal trifecta라 부르는 것 — ① 비공개 데이터 접근 ② 신뢰할 수 없는 콘텐츠 노출 ③ 외부와 소통하는 수단 을 동시에 가지는 순간 에이전트가 위험해진다. 셋이 합쳐지면 오염된 문서나 웹페이지 하나가 prompt injection으로 에이전트를 하이재킹해 닿을 수 있는 것을 조용히 유출할 수 있다. 세 패턴이 하이재킹된 에이전트가 닿을 수 있는 범위를 줄여 trifecta를 깬다
  • 어디서 시작할까 — 자율성과 관측성을 혼동하지 마라: 자율성은 단계적으로 얻는 것이라 아무도 한 번에 다 주기를 기대하지 않는다. 관측성은 전혀 단계적이지 않다. 자율성 수준이 무엇이든 첫날부터 완전한 강도로 들어가야 한다 — 돌아가는 시스템에 나중에 붙이는 것은 고통스럽기 때문이다. 위에 만드는 것은 의도적으로 보수적으로 남아도 되지만, 아래의 계측은 그럴 수 없다
    • ① 첫날부터 계측 (모든 에이전트 워크플로가 각 단계에 대해 추론과 참조 소스를 포함한 span이 있는 trace를 방출. 자체 구축보다 OpenTelemetry 같은 검증된 도구에 기대라) ② shadow mode로 시작 (최저 위험, 최고 학습. 컴플라이언스에 필요해지기 전에 감사 추적을 만들고, 자율성을 주기 전에 정확도를 측정) ③ 위임 접근 구현 ④ 설명 가능하게 만들어라 (규제 당국이 묻든 안 묻든, “왜”에 답하는 감사 추적이야말로 나쁜 결정을 디버그하고 좋은 결정을 방어하고 자율성을 넓힐 만큼 시스템을 신뢰하게 해준다)

주제 3 — The Context Layer: 에이전트에게 데이터의 의미를 가르치기

  • 에이전트는 “revenue”가 뭔지 모른다: “Product X의 Q3 revenue가 얼마였나?” 를 물으면 인간 분석가는 어떤 테이블을 쿼리할지, revenue가 gross인지 net인지, Q3가 회계 캘린더에서 무엇에 매핑되는지 정확히 안다. 수년의 제도적 지식, tribal 문서, Slack 스레드로 흡수했다. 에이전트는 아무것도 없다. 제품→주문→revenue를 잇는 조인도, 회계연도가 2월에 시작한다는 것도 모른다. 그 컨텍스트가 없으면 답을 환각하거나 포기한다
  • context layer는 세 개의 별도 정의 본체다 — 명사, 숫자, 동사:
모델무엇을 말하는가실행 여부
domain model무엇이 존재하는가 — 엔티티, 관계, 비즈니스의 의미 규칙 (“주문은 고객에 속한다”, “활성 고객은 최근 90일 내 구매한 고객”). 요청을 해석하고 계획할 어휘를 준다참조될 뿐 실행되지 않는다. 데이터로 가는 쿼리 경로가 여기를 지나지 않는다
semantic model숫자가 어떻게 계산되는가 — 지표와 차원, 각각 하나의 버전 관리된 공식, 매번 같은 SQL로 컴파일되어 분석 스토어에 실행. 정확성을 모델의 추측이 아니라 컴파일러에 넣는 것이 일실행됨
capability model에이전트가 무엇을 해도 되는가 — 라이브 시스템에 대한 큐레이션된 연산 집합. 읽기(결제 상태 확인, 문제해결 가이드 검색)와 쓰기(환불 발행). 각각 권한과 오너를 지니고, 행동하는 것은 precondition과 reversibility class도 지님실행됨
  • 셋을 묶는 것은 다 의미에 관한 것이라서가 아니다 (capability model은 명백히 아니다). 각각이 요청마다 모델이 새로 알아내는 대신 버전 관리에서 한 번 보증이 선언되는 자리라는 점이다. 정의가 곧 레이어이고, 인터페이스는 — 오늘날 MCP는 — 그저 문일 뿐이다
  • dbt semantic model이 이미 엔티티를 선언하는데 왜 domain model을 분리하나? — 지표 레이어 안에 선언된 엔티티는 지표에 스코프되어 있고, capability model은 semantic model과 같은 어휘로 쓰이지 않으면 둘이 어긋난다. 환불은 revenue 수치가 세는 것과 같은 고객에 작용한다. 아래에 하나의 어휘를 두거나, 두 개를 갖게 되거나
  • 세 모델 모두 소스 컨트롤의 코드다. 코드 리뷰를 거치고 CI에서 테스트되고 환경을 거쳐 프로덕션에 도달한다. “revenue”의 정의나 환불 규칙이 바뀌면 한 곳에서 바꾸고 그것이 어디로든 전파된다. 에이전트는 기저 데이터에 직접 닿지 않고 context layer를 지나며, 그 레이어가 무엇을 물을 수 있고 무엇을 할 수 있는지를 둘 다 제약하고 거버넌스한다
  • metrics as code — 같은 질문, 매우 다른 SQL:
    • semantic model 없이: 테이블 이름을 추측하고, 틀린 컬럼을 쓰고, 회계 캘린더 매핑이 없고, 조인을 놓친다 
      SELECT SUM(amount) FROM sales_data
 WHERE product = 'Product X' AND quarter = 'Q3'
    • semantic model 있이: 올바른 테이블, YAML 정의의 net-revenue 공식, 올바른 회계 날짜, 유효한 조인 경로로 제약된다 
      SELECT SUM(order_amount - discount_amount)
  FROM orders o JOIN products p ON o.product_id = p.id
 WHERE p.name = 'Product X'
   AND o.order_date BETWEEN '2025-07-01' AND '2025-09-30'
    • semantic model은 에이전트를 더 똑똑하게 만들지 않는다. 추측하는 것을 멈추게 한다. 답에 따라 확인 없이 행동하는 에이전트에게는 그것이 중요한 것이다
  • 어디서 시작할까: 비즈니스 전체를 모델링한 뒤에야 뭔가 배포하려는 유혹에 저항하라. semantic model부터 시작하라 — 가치가 소수의 지표, 팀마다 다른 것을 뜻하는 논쟁적인 지표에 집중되어 있기 때문이다. 첫 에이전트 유스케이스가 스코프를 정하게 하고, 상상할 수 있는 것이 아니라 실제로 필요한 domain model과 capability를 키워라. 좁고 올바른 context layer가 넓고 반쯤 합의된 것을 이긴다
    • ① 충돌하는 지표 정의를 찾아라 (revenue가 고전 — gross vs net, 반품 포함 여부. 그 충돌이 최대의 에이전트 리스크이자 가장 빠른 승리) ② 도구를 고르되 규율에 집중 ③ 에이전트를 context layer로 라우팅, 결코 raw 스키마로 보내지 마라 (MCP가 오늘날 흔한 노출 방법이고 dbt·Cube·AtScale 모두 MCP 서버를 배포하지만 원칙은 프로토콜이 아니라 추상화) ④ 적대적으로 테스트하라 (모든 환각이 빠진 정의를 가리킨다. 프롬프트가 아니라 정의를 고쳐라)
  • domain model 순회 — 지식 그래프: semantic model은 “지역별 revenue” 같은 정형 지표 쿼리에 빛난다. 하지만 어떤 에이전트 작업은 엔티티·이벤트·시간에 걸친 풍부한 관계 추론을 요구한다. Product X를 사고 가격 변경 후 이탈한 고객 — 고정된 hop 수는 평범한 조인이다. flat 테이블이 잘 못 다루는 것은 쿼리를 쓸 때 깊이를 모르는 순회, 찾는 것을 발견할 때까지 관계 사슬을 따라가는 것이다. 그것이 domain model의 영역
    • 그 지도를 저장하고 순회하는 흔한 방법이 지식 그래프이고, 이것은 네 번째로 만들 것이 아니라 domain model의 스토리지 선택이다. GraphRAG(community detection으로 전통 RAG가 못 하는 추상적 쿼리 처리), Graphiti(진화하는 사실을 위한 시간 인식 지식 그래프) — 둘 다 2026년 기준 Thoughtworks Radar Trial
    • semantic model이 여전히 지표를 정의하고, 그래프가 시간에 걸친 고객·제품·이벤트·결정 사이의 연결을 나른다. 함께 있으면 에이전트에게 제도적 기억에 가까운 것 — 신입이 흡수하는 데 몇 달 걸릴 지식 — 을 준다

주제 4 — From Searchable to Actionable: 에이전트 준비된 데이터 접근

  • 에이전트는 읽을 수 있지만 행동할 수 없다: 직원이 PO(발주) 문제를 신고한다. 이상적 에이전트라면 ① 관련 문제해결 가이드 검색 ② PO 결제 서비스가 지금 다운됐는지 확인 ③ 필요하면 헬프데스크 티켓 생성. 대부분의 조직이 배포한 전통 RAG는 1단계만 한다. 라이브 모니터링 시스템을 쿼리할 수 없고 ServiceNow나 Jira에 티켓을 만들 수는 확실히 없다
  • 데이터 접근 스펙트럼 (Microsoft Cloud Adoption Framework for AI의 RAG + MCP-Read + MCP-Write):
    1. Retrieval — RAG, 벡터 검색, 문서 조회. 대부분의 조직이 오늘 여기 산다
    2. Real-Time Query — 라이브 시스템 쿼리, 서비스 상태 확인, 실시간 DB 읽기
    3. Write-Back — 가장 강력하고 가장 위험한 tier. 티켓 생성, 레코드 갱신, 워크플로 트리거
    • 각 단계가 능력과 위험을 더한다. agentic AI로의 전환은 대부분의 팀이 만든 retrieval만이 아니라 셋 다 요구한다
    • MCP가 이 tier들을 배선하는 기본 방법이 되었지만 메커니즘보다 구분(demarcation)이 중요하다. MCP로 노출하든 자체 네이티브 API로 하든, retrieval·실시간 읽기·write-back을 별도의 의도적으로 거버넌스된 접근 수준으로 유지하는 것이 중요하다
  • 세 프리미티브, 하나의 프로토콜: MCP 프리미티브가 위험 gradient 위에 있다 — Resources(읽기 전용)는 안전, Prompts는 행동을 형성, Tools는 상태를 바꾼다. 그 gradient가 tier에 그대로 매핑되고, 안전한 경로는 Resources를 먼저 노출하고 거버넌스 하에서만 Tools로 승격하는 것
  • 안티패턴: naive API-to-MCP 변환: 흔하고 비싼 실수는 기존 REST API를 1:1로 감싸 모든 엔드포인트를 도구로 만드는 것. 결과는 tool sprawl — get_po_payment_status, create_ticket_po_payment, create_ticket_po_payment_network 같은 이름의 도구 50개. 에이전트가 거의 구분되지 않는 50개 중에서 적은 컨텍스트로 골라야 하고, LLM은 그것을 못 한다. 도구 수가 늘수록 정확도가 급격히 떨어진다. Thoughtworks Tech Radar가 정확히 이 이유로 HOLD에 올렸다
    • 더 나은 접근은 같은 기능을 풍부한 설명과 파라미터화된 입력을 가진 소수의 잘 설계된 capability로 노출하는 것. check_service_status는 서비스명과 위치를 받아 모든 서비스·모든 위치에 대해 도구 하나. create_support_ticket은 category·priority·description으로 파라미터화
    • 원칙: 엔드포인트가 아니라 capability를 설계하라. 잘 기술된 5~10개 비즈니스 capability가 얇은 API 래퍼 50개를 거의 항상 이긴다. 그리고 이 원칙은 프로토콜 무관 — MCP든 다른 에이전트든 다음에 올 표준이든 agent-ready하게 만드는 속성은 같다: 풍부한 설명, 파라미터화된 접근, 명확한 스키마
  • capability가 선언하는 것: 풍부한 설명은 언제 손을 뻗을지 말해주지만 허용되는지, 틀렸을 때 무슨 일이 생기는지는 말해주지 않는다. 모든 capability가 permissions(누가 누구로서 호출할 수 있는가)와 owner(오작동할 때 책임질 사람)를 지니고, 행동하는 것은 둘을 더 지닌다
    • Preconditions — 행동 전에 성립해야 하는 조건, 에이전트가 계획 초기에 읽은 것이 아니라 행동하는 순간의 라이브 상태에 대해 확인된다. 환불은 원 결제가 있고, 아직 환불되지 않았고, 호출 사용자가 승인할 수 있는 금액 내여야 한다
    • Reversibility — 행동이 할 수 있는 손상의 등급: 깔끔히 되돌릴 수 있음 / 보상 트랜잭션으로 비용을 들여 되돌릴 수 있음 / 되돌릴 수 없음. 이것이 관련된 금액보다 안전한 자율성의 더 유용한 예측 변수다. 되돌릴 수 있는 200 결제보다 자동화하기 안전하다. 앞의 staged autonomy 사다리가 guardrail을 거래 금액에 키잉했다면, reversibility에 키잉하는 것을 선호하고, 되돌릴 수 없는 행동은 에이전트가 어느 단계에 도달했든 인간 승인을 요구하게 하라
  • 검색된 텍스트는 informs하지 gates하지 않는다: 비즈니스 문서는 비즈니스가 규칙을 적어두는 곳으로 남는다. 하지만 행동을 gate하는 규칙은 행동하는 순간에 읽히고 해석되어서는 안 된다. 규칙은 사전에 그 문서에서 추출되고, 인간이 큐레이션하고, capability model에 선언된 precondition으로 저장되며, 각각 유래한 구절로의 링크를 갖는다
    • 행동 시점에 에이전트는 여전히 비정형 콘텐츠(불만 티켓, 계약 조항)를 읽어 무엇을 제안할지 알아낼 수 있다. 선언된 규칙만이 무엇이 허용되는지 결정하고, 그것은 라이브 상태에 대해 결정적으로 확인된다. 경계는 informing과 gating 사이에 있다. 검색된 텍스트는 에이전트가 제안하는 것을 형성하고 인간 승인자에게 증거로 기능할 수 있지만, 결코 행동 자체를 승인할 권위를 갖지 않는다
    • 그 경계는 보안 속성이기도 하다. 검색된 텍스트를 인가 경로에서 제거하면 오염된 문서가 에이전트에게 원래 없던 권한을 부여할 수 없고, 이것은 하이재킹된 에이전트가 닿을 수 있는 범위를 줄이는 것보다 강한 주장이다. 완전한 방어는 아니다 — 주입된 텍스트가 여전히 에이전트가 제안하는 것에 영향을 줄 수 있고, 조작된 증거를 본 인간 승인자가 통과시킬 수 있다. 제거되는 것은 문서가 중간에 아무도 없이 행동을 직접 승인하는 경로다
    • provenance 링크가 문서가 아래에서 움직일 때 선언을 정직하게 유지한다. 여기서 약속에 주의하라 — 문서가 바뀐 것을 탐지하기는 쉽지만, 그 변경이 거기서 유도된 precondition을 무효화했는지 아는 것은 diff가 아니라 판단이다. 링크가 사주는 것은 리뷰 큐다 — 소스가 움직이면 유도된 규칙이 인간 재확인을 위해 플래그된다. freshness SLA를 콘텐츠가 바뀐 것처럼 보이는 때가 아니라 인덱스가 마지막으로 재구축된 때에 키잉하는 것과 같은 정신
    • 어떤 선언도 상황을 커버하지 않으면 에이전트는 자기 정책 독해로 즉흥 연주하지 않는다. 에스컬레이션한다. 앞의 hard gate와 같은 본능 — 선언되지 않은 케이스는 에이전트를 autonomous가 아니라 supervised로 격하시킨다
    • 추출과 큐레이션은 다른 것과 마찬가지로 파이프라인이고, 오너와 cadence와 리뷰 큐를 비우는 누군가가 필요하다
  • 어디서 시작할까: 안전한 진입은 tier를 오르는 것이지 write-back으로 뛰어드는 것이 아니다. ① 접근 tier 매핑 (상위 3개 유스케이스가 무엇을 필요로 하는지 분류. 대부분의 격차는 real-time query와 write-back에 있다) ② 엔드포인트가 아니라 capability 설계 (기존 API를 5~10개 잘 기술된 비즈니스 capability로 그룹화) ③ MCP Resources부터 ④ 첫날부터 계측 (write 접근을 가진 에이전트를 배포하기 전에 모든 도구 호출을 로깅 — 누가 트리거했고, 무엇이 호출됐고, 언제, 그리고 결정적으로 누구를 대신해)

종합 — AI-ready 데이터 스택과 소유권

  • 의존성은 아래에서 위로 흐른다: 신뢰할 수 없는 데이터에 의미를 붙일 수 없으므로 context가 foundation 위에 앉고, 그 의미로 제약하지 않고 에이전트가 안전히 행동하게 할 수 없으므로 access가 context 위에 앉는다. 둘 중 하나를 건너뛰면 그 위의 모든 것이 무너진다. 그것이 정확히 그렇게 많은 agentic AI 프로그램이 멈추는 이유다 — 아래의 기반을 만들지 않고 곧장 에이전트 접근으로 뛴다
    • Observability는 다르다. 위에 쌓이는 네 번째 tier가 아니라 셋 전부를 관통해 나란히 달린다. 모든 레이어가 실제 작업을 다루는 순간부터 traceable하고 auditable해야 한다. 돌아가는 시스템에 나중에 붙이는 것이 처음부터 넣는 것보다 훨씬 어렵다. 어느 쪽이든 첫날부터 배선한다
  • 누가 이걸 다 소유하나 — 다이어그램이 그릴 수 없는 의존성: 모든 레이어가 참으로 유지되어야 하는 아티팩트를 만든다 — data contract, 지표 정의, 접근 스코프, 관측성 trace. 아티팩트는 스스로 유지되지 않는다
    • 오너 없는 contract는 그것이 기술하는 소스와 어긋나 표류한다. 오너 없는 “revenue” 정의는 방금 통합한 세 개의 충돌 버전으로 다시 갈라진다. 오너 없는 접근 스코프는 조용히 넓어져 다시 상시 서비스 계정이 된다. 기술은 필요하지만 그것을 정직하게 유지하는 것은 운영 모델이다
    • 규율은 data as a product — 각 데이터셋·contract·지표가 명명된 오너, 발행된 contract와 SLA, 버전 관리된 라이프사이클을 갖는다, API가 그렇듯이. 모든 소비자를 항상 알 수는 없고, 공개·광범위 공유 데이터는 알 수 없는데, 정확히 그래서 contract가 중요하다 — 알려지지 않은 소비자가 그 위에 짓는 안정적 약속이고, deprecation 정책이 그들을 깨지 않고 바꾸는 방법이다
    • 인간 소비자는 오너 없이 표류하는 데이터셋을 알아채고 우회한다. 에이전트는 기계 속도와 규모로 그것을 소비하고 오류를 그만큼 빠르게 전파한다. 소비자가 빠르고 자율적일수록 오너 없는 데이터를 감당할 수 없다

주요 수치 / 사실

  • 2026 State of Data Integrity and AI Readiness (Precisely + Drexel LeBow, 데이터·분석 리더 505명): 87%가 자기 데이터가 AI 준비되었다고 믿었지만 43%가 데이터 준비성을 가치 창출의 가장 큰 단일 장벽으로 지목. “확신과 준비성 사이의 그 격차가 pricing 에이전트의 조직 수준 버전 — 자기 확신에 차 있고 틀렸다”
  • KPMG Global AI Pulse (리더 2,145명): 거의 절반의 임원이 이제 AI의 비용이 이익을 초과한다고 본다
  • EU AI Act: Article 12(수명 전체 자동 로깅) + Article 19(최소 6개월 보관), 위반 시 최대 €1,500만 또는 전 세계 연매출 3% 중 큰 쪽
  • AtScale text-to-SQL 벤치마크: 동일 모델에서 raw 스키마 정확도 20% 미만 → 시맨틱 레이어 적용 시 92.5% 초과
  • 자기 위치 진단 표 — 다섯 속성 × 세 단계 (Human-era / In Transition / Agent-ready). ⚠️ 행을 평균 내지 마라. 스택이 의존성 순서이므로 준비도는 가장 약한 기반 레이어에 의해 상한이 정해진다. 신뢰할 수 없는 데이터 위에 앉은 완벽한 context layer는 여전히 agent-ready가 아니다. 가장 약한 행을 찾아라, 거기가 다음 투자처다
  • 시작할 네 가지: ① 첫날부터 계측 (순서상의 단계가 아니라 모든 것 아래에서 달리는 상수) ② 모든 것에 contract (에이전트는 나쁜 데이터 냄새를 못 맡으니 데이터 아키텍처가 대신 맡아야 한다) ③ 모델보다 컨텍스트 (컨텍스트가 더 큰 모델보다 정확도를 더 멀리 움직인다 — 다만 아래 데이터를 신뢰할 수 있을 때만 값을 한다) ④ write보다 read 먼저
  • 에이전트가 데이터의 주 소비자가 될 때, 당신의 데이터 아키텍처가 곧 당신의 AI 아키텍처가 된다

관련 위키

Source: 원문 보기

그래프 뷰

백링크