Skip to main content
원문: Data-Native AI Agents: Why Agents Must Move to Your Data 저자: Kaan Kuguoglu, John Karlsson 게시일: 2026년 7월 15일

​
요약

  • 외부 에이전트는 규모에서 무너진다 — 데이터를 거버넌스 시스템 밖 별도 AI 스택으로 빼내면 거버넌스가 약해지고, 지연 시간이 누적되며, 비용이 파편화된다.
  • 사후(post-hoc) 거버넌스는 에이전트에 통하지 않는다 — 에이전트는 데이터를 단순히 조회하는 것이 아니라 계산하기 때문에, 정책은 쿼리 계획 시점에 적용되어야 한다.
  • 데이터 네이티브 접근 — Unity AI Gateway, Unity Catalog, MLflow, Lakebase, AI Search를 통해 에이전트를 데이터와 같은 플랫폼 안에서 거버넌스가 적용되는 워크로드로 실행한다.
대부분의 엔터프라이즈 AI 파일럿은 똑같이 낮은 기준을 넘는다. LLM을 데이터에 연결하고, 벡터 데이터베이스를 끼워 넣고, 경영진에게 데모를 보여준다. 어려운 부분은 나중에 드러난다. 보안팀은 거버넌스 구멍을 지적한다. 멀티 스텝 에이전트의 지연 시간이 사용자 경험을 망친다. 모델 제공업체가 보내는 청구서는 계속 늘어난다. 이런 문제들은 대개 하나의 결정으로 거슬러 올라간다. 바로 데이터를 거버넌스가 적용되는 시스템 밖으로 빼내어, 당신의 정책을 강제하도록 설계되지 않은 AI 스택 안으로 옮긴 결정이다. 이 글은 다른 아키텍처 방향을 제안한다. 데이터를 모델과 에이전트로 옮기지 말고, 모델과 에이전트를 데이터로 옮기라는 것이다. 병렬 AI 인프라를 구축하고 이를 다시 레이크하우스에 연결하는 대신, 에이전트를 데이터 플랫폼 안에서 실행되는 네이티브 워크로드로 취급한다. 이미 데이터에 대해 신뢰하고 있는 것과 동일한 거버넌스, 보안, 관측 가능성(observability) 제어 아래에서 말이다. 레이크하우스는 데이터를 거버넌스하는 단일 지점을 제공했다. 다음 질문은 당신의 에이전트가 그 경계 안에 사는지, 밖에 사는지다. 여기에는 두 가지 부상하는 패러다임이 있다.

​
외부 에이전트 (External agents)

에이전트와 LLM이 별도의 AI 스택에서 실행된다. 데이터는 외부 벡터 데이터베이스, SaaS LLM, 또는 맞춤형 서빙 레이어로 내보내지거나 네트워크를 거쳐 쿼리된다. 거버넌스, 보안, 관측 가능성은 AI를 위해 별도로 다시 구현된다.

​
데이터 네이티브 에이전트 (Data-native agents)

에이전트, 모델, 도구, 검색(retrieval), 에이전트 메모리가 데이터 자체와 동일한 플랫폼 안에서, 통합된 거버넌스 및 보안 레이어 아래에서 실행된다. AI는 기존 데이터 스택 위의 또 하나의 워크로드가 된다.

​
외부 에이전트의 숨은 세금 (The Hidden Tax of External Agents)

데이터에는 중력이 있다. 컴퓨팅은 재배치 비용이 저렴하지만, 데이터는 그렇지 않다. 특히 용량이 커지고 모달리티가 다양해질수록 그렇다. 데이터를 밖으로 빼내면 익숙한 여러 대가가 따라온다.
  • 거버넌스가 약해진다. 접근 제어, 계보(lineage), 데이터 소재지(residency)를 모든 통합 지점마다 다시 구현하면, 감사(audit)에서 발견되는 구멍이 남는다.
  • 지연 시간이 쌓인다. 외부 벡터 스토어, LLM, 그리고 되돌아오는 각 홉(hop)이 멀티 도구 에이전트 전반에 걸쳐 복합적으로 누적된다.
  • 비용이 파편화된다. 이그레스(egress), 중복 스토리지, 벤더별 토큰 단위 과금이 세 방향에서 예산을 압박한다.
  • 라이프사이클이 벤더 조율 작업이 된다. 스키마, 인덱스, 모델이 배포 파이프라인을 공유하지 않는 시스템들 사이에서 서로 어긋난다(drift).
  • 관측 가능성이 파편화된다. 하나의 요청을 엔드투엔드로 추적하려면 서너 개 도구의 로그를 이어 붙여야 한다.
  • 비즈니스 맥락은 뒤에 남는다. 지표 정의, 비즈니스 용어집(glossary), 도메인 그룹핑은 거버넌스 레이어에 살아 있지만, 외부 에이전트는 이를 컬럼 이름으로부터 재구축하거나, 추측한다.

​
사후 거버넌스가 에이전트에 통하지 않는 이유 (Why Post-Hoc Governance Fails for Agents)

이 모든 대가 중에서도 거버넌스는 특별히 주목할 만하다. 사후에 패치할 수 없는 유일한 문제이기 때문이다. AI 거버넌스에 대한 대부분의 접근 방식은 이를 에이전트가 이미 데이터에 접근한 이후에 적용되는 필터로 취급한다. 예를 들어 응답에서 민감한 필드를 편집(redact)하거나, 출력 레이어에서 특정 주제를 차단하거나, 사후에 로그를 감사하는 식이다. 이는 단순한 Q&A 데모에서는 통한다. 그러나 에이전트가 데이터에 대해 계산을 시작하는 순간 무너진다. 행 수준 보안(row-level security)의 적용을 받는 행들에 걸쳐 재무 요약을 계산하는 에이전트를 생각해 보자. 집계 자체(합계, 평균, 추세)는 어떤 행이 포함되는지에 따라 형태가 결정되는 파생값이다. 쿼리가 실행되기 이전에 거버넌스가 적용되지 않으면, 그 결과에는 이미 사용자가 영향을 미쳐서는 안 되는 데이터가 인코딩되어 있다. 아무리 다운스트림에서 편집해도 그 계산을 되돌릴 수는 없다. 정책 결정은 응답 렌더링 시점이 아니라 쿼리 계획(query planning) 시점에 이루어졌어야 한다. 이것이 경계(perimeter) 기반 또는 사후 거버넌스의 근본적인 허점이다. 데이터가 에이전트에 도달한 뒤에도 안전하게 검열될 수 있다고 가정하는 것이다. 실제로는 집계나 변환이 한 번 일어나고 나면 거버넌스 의도는 이미 사라진다. 소급 적용되는 제어는 근본적으로 불완전하다. 이를 잘못하면 두 번째 비용이 있고, 그것은 청구서에 나타난다. 문제는 에이전트가 무엇을 만질 수 있느냐만이 아니다. 물론 그것도 일부지만 말이다. 거버넌스가 원천에서가 아니라 사후에 해결되면, 에이전트가 스스로 그 조정 작업을 하게 된다. 감사 로그를 뒤지고, 외부 시스템에 흩어진 조각들을 조인하고, 같은 레코드를 여러 곳에서 끌어와 자신이 사용해도 되는지 따지고, 모든 부분 결과에 대해 다시 추론한다. 그 어느 것도 원래 과제가 아니다. 앞서 주어지지 않은, 거버넌스가 적용된 답을 에이전트가 보상하려 애쓰는 것이다. 차단되거나 편집된 출력은 이 악순환을 더 부추길 뿐이다. 에이전트가 이를 실패로 읽고 다시 시도하기 때문이다. 세션은 길어지고, 각 홉마다 더 많은 맥락이 모델에 실리며, 하나의 요청은 조용히 수천 개의 과금 토큰으로 바뀐다. 이것이 토큰 소각 루프(token-burning loop)이며, 사후 거버넌스가 이를 돌게 만드는 원인이다. 데이터 네이티브 에이전트는 정책 강제를 쿼리 계획과 계산에 직접 내장함으로써 이 문제들을 해결한다. 모든 중간 결과가 동일한 거버넌스 제약을 반영한다. 거버넌스는 실행 이전과 실행 도중에 평가되어야 하며, 계산이 완료된 뒤에 사후적으로 적용할 여유가 없다. Unity AI Gateway의 Custom Guardrails가 이것의 구체적인 형태다. 게이트웨이가 모든 요청과 응답에 강제하는, 조합 가능하고(composable) 결정론적인(deterministic) 정책이지, 모델에게 사후에 따르라고 요청하는 필터가 아니다. 이미 하나의 거버넌스 지점에 존재하는 데이터에 대해 계획 시점에 정책을 결정한다는 것은, 에이전트가 답을 조립하거나 정당화하기 위해 여러 시스템을 헤집고 다니는 대신 단 한 번의 패스로 깨끗한 답을 얻는다는 뜻이기도 하다.

​
에이전트 상태와 메모리에도 거버넌스가 필요하다 (Agent State and Memory need governance)

지금까지는 에이전트가 데이터를 어떻게 읽는지에 집중했다. 그러나 프로덕션 에이전트는 쓰기도 한다. 대화 이력, 과제 진행 상황, 사용자 선호도, 캐시된 결과, 나중에 감사할 도구 출력 등이다. 에이전트가 더 많은 일을 맡을수록, 상태(state) 레이어는 데이터 레이어만큼이나 중요해진다. 이를 거버넌스 경계 밖에 두면, 엔드투엔드 감사 가능성에 대한 모든 약속에 구멍이 생긴다. 상태(state)는 에이전트의 단기 메모장이다. 진행 중인 대화, 수행 중인 과제, 방금 채운 캐시 같은 것들이다. 메모리(memory)는 세션보다 오래 지속되는 것이다. 에이전트가 어떤 고객을 상대했는지, 사용자가 무엇을 선호하는지, 과거 출력 중 재사용할 가치가 있는 것이 무엇인지 등이다. 둘 다 트랜잭션 스토리지가 필요하고, 둘 다 플랫폼을 떠나는 순간 거버넌스가 새어 나간다. “사용자 X는 고가치 EU 고객이다” 같은 메모리 자체가 민감한 데이터이며, 그것이 요약한 레코드와 동일한 접근 및 소재지 규칙에 묶여 있다. 그리고 이는 트랜잭션 워크로드다. Delta 테이블은 대규모 분석 스캔을 위해 만들어졌지만, 에이전트 상태는 빠른 행 단위 읽기/쓰기, 키 기반 조회, 원자적 업데이트가 필요하다. 흔한 우회책은 외부 Postgres나 Redis다. 그러나 이는 다시 이 글이 반대하는 그 문제로 되돌아간다. 에이전트 상태가 거버넌스 경계를 벗어나, 거버넌스 레이어가 볼 수 없는 시스템으로, 각자의 보안과 라이프사이클을 관리해야 하는 곳으로 나가는 것이다. 데이터 네이티브 에이전트를 만들었지만 거버넌스가 적용되지 않는 의존성을 함께 만든 셈이다. 그리고 이 문제는 하나의 에이전트가 여럿이 되는 순간 커진다. 더 큰 결과를 향해 함께 일하는 무리(swarm) — 전문가에게 위임하는 플래너, 그들의 결과를 조정하는 감독자(supervisor) — 는 공유 메모리가 필요하고, 그 위에서 정렬을 유지하는 것이 바로 이런 시스템이 무너지는 지점이다. 각 에이전트가 사적인 상태를 유지하고 맥락을 피어투피어(peer-to-peer)로 전달하면, 단일 진실 공급원(single source of truth)이 없다. 에이전트들이 발산하고, 쓰기가 충돌하며, 모든 인계(handoff)가 무리가 커질수록 배가되는 또 하나의 거버넌스되지 않은 채널이 된다. 메모리를 교환하는 일이 알고 보니 가장 어려운 부분이다. Lakebase가 이 간극을 메운다. Databricks 플랫폼 안에 있는, 완전 관리형 PostgreSQL 스토리지이며, 다른 모든 것과 동일한 거버넌스 평면(governance plane) 아래에 있다. 에이전트 상태는 거버넌스가 적용되는 자산이 된다. 플랫폼의 접근 제어를 상속하고, 에이전트의 데이터 및 도구와 나란히 존재하며, 별도의 인프라 팀이 필요 없다. 그리고 모든 에이전트가 그 동일한 트랜잭션 레이어를 읽고 쓰기 때문에, 이는 무리의 단일 진실 공급원 역할도 한다. 상태는 일관되게 유지되고, 원자적 업데이트가 두 에이전트가 같은 과제를 손상시키는 것을 막으며, 한 에이전트의 뷰에 걸린 정책이 그것이 다음 에이전트를 위해 쓰는 것에까지 이어지고, 어떤 메모리든 무리를 거슬러 추적된다. 어느 에이전트가 썼는지, 어느 에이전트가 읽었는지, 깊은 결론이 어떻게 그 원천에 도달하는지까지 말이다.

​
데이터 네이티브 에이전트를 위한 근거 (The Case for Data-Native Agents)

거버넌스 논거가 가장 날카롭지만, 이점은 그 이상으로 뻗어 나간다. 에이전트가 데이터 스택 안에서 실행되면, 그 이점은 모든 운영 차원에 걸쳐 복합적으로 커진다. 보안, 품질, 관측 가능성, 배포, 지연 시간, 비용이다. 도구와 데이터 의존성이 모델과 나란히 구성되고 로깅되므로, 전체 시스템이 기본적으로 버전 관리되고, 감사 가능하며, 재현 가능하다. 다음 비교표는 프로덕션 시스템에 가장 중요한 차원들에서 이 두 패러다임이 어떻게 다른지 요약한다.

​
Databricks에서 데이터 네이티브 에이전트는 실제로 어떤 모습인가 (What Data-Native Agents Actually Look Like on Databricks)

Data + AI Platform은 이를 실천에 옮긴다. 별도의 “AI 스택”을 구축하고 이를 데이터에 연결하는 대신, 데이터 스택 자체 안에서 AI 에이전트를 구축한다. Databricks에서 데이터 네이티브 에이전트는 다음과 같은 에이전트다.
  • 모든 모델 및 에이전트 트래픽을 Unity AI Gateway를 통해 라우팅한다. 여기서 모든 요청은 실행 전에 검사되고 모든 응답은 이후에 점검되며, 결정론적인 ALLOW / DENY / ASK 정책이 사후의 최선 노력식(best-effort) 필터링을 대체한다. 접근 제어, 속도 제한(rate limiting), 페이로드 로깅, 비용 추적이 모두 동일한 제어 평면에 존재하며, 외부 LLM 제공업체와 코딩 에이전트에 대한 호출까지 포함한다.
  • 모든 AI 프리미티브(모델, 에이전트, MCP, 스킬, 그리고 그것들이 호출하는 도구)를 테이블 및 함수와 나란히 Unity Catalog 자산으로 취급하여, 아이덴티티, 계보, 접근 제어가 AI 표면 전체에 걸쳐 균일하게 적용된다.
  • MLflow 3을 통해 전체 요청 추적을 포착한다. 모든 LLM 호출, 도구 호출, 점수(score), 평가(eval), 검색된 문서, 엔드투엔드 모니터링 루프가 컴플라이언스를 위해 감사 가능하고 디버깅을 위해 관측 가능해진다.
  • Databricks 보안 경계 안의 Model Serving에서 추론을 실행하며, 서드파티 AI 스택으로 거버넌스되지 않는 데이터 이동이 없다.
  • AI Search로 구동되는, Unity Catalog ACL을 존중하고 계보를 자동으로 추적하는 Delta 기반 인덱스에서 맥락을 검색한다.
  • Lakebase 기반 상태와 메모리를 통해 세션 간에 기억한다. 단기 대화 맥락, 멀티 스텝 과제 진행 상황, 장기 사용자 선호도, 과거 도구 호출에 대한 에피소드 기억이 에이전트가 추론하는 데이터와 나란히 존재한다.
  • Unity Catalog Semantics(Metrics, Business Glossary, Domains)와 Genie Ontology — 팀이 이미 사용하는 테이블, 쿼리, 대시보드, 앱으로부터 추출되어 자동 유지되는 지식 그래프 — 를 통해 비즈니스 맥락에 추론을 정초한다(ground).
  • 구조화된 데이터 질문에 대해서는 Genie를 포함한 다른 에이전트에게 전문화된 추론을 위임하며, 플랫폼 경계 안에서 도메인을 넘나드는 멀티 스텝 조율을 수행한다.
  • Omnigent를 통해 동일한 거버넌스를 코딩 에이전트로 확장한다. Omnigent는 Claude Code, Codex, Cursor를 공유 세션과 공통 감사 추적(audit trail)과 함께 Unity AI Gateway를 통해 라우팅하는 메타 하네스(meta-harness)다.
image1.png

​
어디서 시작할까 (Where to Start)

일부 기업은 이미 이렇게 구축하고 있다. 그들의 에이전트는 데이터와 동일한 경계 안에서 실행되고, Unity Catalog 정책이 둘 다를 커버하며, 상태는 Lakebase에, 트래픽은 Unity AI Gateway를 통과한다. 그들 중 누구도 단일 재플랫폼(re-platforming) 프로젝트로 거기에 도달하지 않았다. 레이크하우스와 AI 스택 사이의 이음새를 파일럿 하나씩 닫아 나갔고, 그다음 새 이음새를 여는 것을 멈췄다. 경로의 더 이른 단계에 있는 팀에게 그 작업은 극적이지 않다. 대부분의 조각은 이미 플랫폼 쪽에 존재한다. Model Serving, Unity Catalog, Lakebase, MLflow다. 빠진 것은 이들을 병렬 스택을 위한 데이터 소스가 아니라 에이전트의 집으로 취급하겠다는 결정이다. 그 결정이 대개 가장 어려운 부분이다. 가장 유용한 출발점은 이미 경계 밖에서 실행 중인 것들의 목록(inventory)을 만드는 일이다. 다음 거버넌스 사고가 나올 곳이 바로 거기이며, 나머지 모든 것을 가능하게 하는 작업이 바로 그것이다. 올바른 가드레일과 패턴으로 데이터 네이티브 에이전트를 운영화하는 방법을 더 깊이 파고들고 싶다면, 다음 리소스가 훌륭한 다음 단계다. 이 글에서 논의한 플랫폼 기능들을 더 탐색하려면: