데이터 네이티브 AI 에이전트: 에이전트가 데이터가 있는 곳으로 이동해야 하는 이유

대부분의 기업 AI 파일럿은 동일하게 낮은 기준을 통과합니다. LLM을 데이터에 연결하고, 벡터 데이터베이스를 도입하고, 경영진에게 데모를 보여주는 것이죠. 진짜 어려운 문제는 그 다음에 나타납니다. 보안 부서에서 거버넌스 허점을 지적합니다. 다단계 에이전트의 지연 시간은 사용자 경험을 망쳐놓습니다. 모델 제공업체가 청구하는 비용은 계속해서 치솟습니다. 이러한 문제는 대개 한 가지 결정에서 비롯됩니다. 바로 거버넌스가 적용된 시스템에서 데이터를 꺼내어, 애초에 기업 정책을 강제하도록 설계되지 않은 AI 스택으로 가져가는 결정입니다.

이 글에서는 다른 아키텍처 방향을 제안하고자 합니다. 데이터를 모델로 가져가는 것이 아니라, 모델과 에이전트를 데이터가 있는 곳으로 이동시키는 것입니다. 별도의 AI 인프라를 구축하고 이를 레이크하우스에 다시 연결하는 대신, 이미 신뢰하고 있는 데이터 플랫폼 내에서 데이터와 동일한 거버넌스, 보안, 관측 가능성 제어 하에 에이전트를 네이티브 워크로드로 실행하는 것입니다.

레이크하우스 덕분에 데이터를 한곳에서 거버넌스할 수 있게 되었습니다. 이제 다음 질문은 에이전트가 그 경계 내부와 외부 중 어디에 위치해야 하는가입니다. 여기에는 두 가지 새로운 패러다임이 있습니다.

외부 에이전트

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

데이터 네이티브 에이전트

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

외부 에이전트의 숨겨진 대가

데이터에는 중력이 있습니다. 컴퓨팅 리소스는 쉽게 이동할 수 있지만, 데이터는 그렇지 않습니다. 특히 데이터 볼륨이 커지고 모달리티가 다양해질수록 더욱 그렇습니다. 데이터를 외부로 끌어내면 다음과 같은 익숙한 문제들이 발생합니다.

• 거버넌스가 약화됩니다. 모든 통합 과정에서 액세스 제어, 리니지(lineage), 데이터 레지던시를 재구현하다 보면 감사에서 지적받을 수 있는 허점이 생깁니다.
• 지연 시간이 누적됩니다. 외부 벡터 저장소와 LLM을 오가는 각 홉(hop)이 다중 도구 에이전트 전체에 걸쳐 누적됩니다.
• 비용이 분산됩니다. 아웃바운드 트래픽(egress) 비용, 중복 스토리지, 여러 벤더의 토큰당 요금제가 세 가지 방향에서 예산에 타격을 줍니다.
• 라이프사이클 관리가 여러 벤더 간의 조율 작업으로 변질됩니다. 배포 파이프라인을 공유하지 않는 시스템들 사이에서 스키마, 인덱스, 모델의 불일치(drift)가 발생합니다.
• 관측 가능성이 파편화됩니다. 하나의 요청을 엔드투엔드로 추적하려면 서너 개의 도구에서 생성된 로그를 일일이 짜맞춰야 합니다.
• 비즈니스 컨텍스트가 유실됩니다. 메트릭 정의, 비즈니스 용어집, 도메인 그룹화는 거버넌스 레이어에 존재하지만, 외부 에이전트는 이를 컬럼 이름만 보고 재구축하거나 추측해야 합니다.

사후 거버넌스가 에이전트에 작동하지 않는 이유

이러한 모든 문제점 중에서도 거버넌스는 사후에 보완할 수 없기 때문에 특별히 주목해야 합니다. 대부분의 AI 거버넌스 접근 방식은 에이전트가 이미 데이터에 액세스한 *이후*에 필터를 적용하는 방식으로 처리합니다. 예를 들어 응답에서 민감한 필드를 가리거나, 출력 레이어에서 특정 주제를 차단하거나, 사후에 로그를 감사하는 식입니다. 이는 단순한 Q&A 데모에서는 작동할 수 있습니다. 하지만 에이전트가 데이터에 대한 *연산(computing)*을 시작하는 순간 무너집니다.

행 수준 보안(row-level security)이 적용되는 행을 대상으로 재무 요약을 계산하는 에이전트를 가정해 보겠습니다. 집계 자체(합계, 평균, 추세)는 어떤 행이 포함되는지에 따라 결정되는 파생 값입니다. 쿼리가 실행되기 *전*에 거버넌스가 강제되지 않으면, 결과에는 이미 사용자가 접근해서는 안 되는 데이터의 영향이 반영되어 버립니다. 다운스트림에서 아무리 가리기를 수행하더라도 이미 완료된 계산을 되돌릴 수는 없습니다. 정책 결정은 응답 렌더링 시점이 아니라 쿼리 계획 시점에 이루어졌어야 합니다.

이것이 바로 경계 기반 또는 사후 거버넌스의 근본적인 한계입니다. 즉, 데이터가 에이전트에 도달한 후에도 안전하게 검열할 수 있다고 가정하는 것입니다. 실제로는 집계나 변환이 한 번 일어나고 나면 거버넌스의 의도는 이미 상실됩니다. 사후 통제는 근본적으로 불완전할 수밖에 없습니다.

이를 잘못 처리했을 때 발생하는 두 번째 비용이 있으며, 이는 청구서에 고스란히 나타납니다. 문제는 에이전트가 어떤 데이터에 접근할 수 있는지에만 국한되지 않습니다. 물론 그것도 일부이긴 합니다. 거버넌스가 소스에서 해결되지 않고 사후에 처리되면, 에이전트가 직접 조정 작업을 수행하게 됩니다. 감사 로그를 탐색하고, 외부 시스템 전반의 파편을 조인하고, 여러 곳에서 동일한 레코드를 가져와 사용할 수 있는지 확인하고, 모든 부분적인 결과에 대해 다시 추론하는 식입니다. 이 중 어느 것도 에이전트의 본래 작업이 아닙니다. 이는 사전에 제공되지 않은 거버넌스가 적용된 답변을 보완하기 위해 에이전트가 헛되이 애쓰는 것뿐입니다. 차단되거나 가려진 출력은 악순환을 부추길 뿐입니다. 에이전트는 이를 실패로 인식하고 다시 시도하기 때문입니다. 세션이 길어지고, 각 홉마다 모델에 더 많은 컨텍스트가 로드되며, 하나의 요청이 어느새 수천 개의 유료 토큰으로 변합니다. 이것이 바로 '토큰 소모 루프'이며, 사후 거버넌스가 바로 이 루프를 작동시키는 원인입니다.

데이터 네이티브 에이전트는 정책 강제를 쿼리 계획 및 연산에 직접 내장함으로써 이러한 문제를 해결합니다. 모든 중간 결과에는 동일한 거버넌스 제약 조건이 반영됩니다. 거버넌스는 실행 전과 실행 중에 평가되어야 하며, 연산이 완료된 후에 사후에 적용할 여유가 없습니다. Unity AI Gateway의 Custom Guardrails가 바로 이러한 형태의 구체적인 예입니다. 이는 모델이 사후에 준수하도록 요구받는 필터가 아니라, 게이트웨이가 모든 요청과 응답에 강제하는 조합 가능하고 결정론적인 정책입니다. 이미 거버넌스가 적용된 한곳에 존재하는 데이터를 대상으로 계획 시점에 정책을 결정하면, 에이전트가 시스템을 뒤져가며 답변을 조합하거나 정당화할 필요 없이 단 한 번에 깔끔한 답변을 얻을 수 있습니다.

에이전트 상태 및 메모리에도 거버넌스가 필요합니다

지금까지는 에이전트가 데이터를 읽는 방식에 초점을 맞추었습니다. 하지만 프로덕션 에이전트는 대화 기록, 작업 진행 상황, 사용자 선호도, 캐시된 결과, 나중에 감사를 위한 도구 출력 등 쓰기 작업도 수행합니다. 에이전트가 더 많은 역할을 수행할수록 상태 레이어는 데이터 레이어만큼 중요해집니다. 이를 거버넌스 경계 밖에 두면 엔드투엔드 감사 가능성에 대한 모든 약속에 구멍이 생기게 됩니다.

상태(state)는 에이전트의 단기 메모장과 같습니다. 진행 중인 대화, 처리 중인 작업, 방금 채워진 캐시 등이 이에 해당합니다. 메모리(memory)는 세션보다 오래 유지되는 정보입니다. 에이전트가 상대한 고객, 사용자가 선호하는 사항, 재사용할 가치가 있는 과거 출력 등이 여기에 속합니다. 둘 다 트랜잭션 스토리지가 필요하며, 플랫폼을 벗어나는 순간 거버넌스 누출이 발생합니다. "사용자 X는 고가치 EU 고객입니다"와 같은 메모리 자체도 요약 대상 레코드와 동일한 액세스 및 레지던시 규칙의 적용을 받는 민감한 데이터입니다. 또한 이는 트랜잭션 워크로드입니다. Delta 테이블은 대규모 분석 스캔용으로 구축되었지만, 에이전트 상태에는 빠른 행별 읽기 및 쓰기, 키 기반 조회, 원자적 업데이트가 필요합니다.

일반적인 해결책은 외부 Postgres나 Redis를 사용하는 것입니다. 하지만 이는 이 글에서 지적하는 문제로 다시 돌아가게 만듭니다. 에이전트 상태가 거버넌스 레이어에서 볼 수 없고 자체적인 보안 및 라이프사이클 관리가 필요한 시스템으로 빠져나가기 때문입니다. 결국 거버넌스가 적용되지 않는 종속성을 가진 데이터 네이티브 에이전트를 구축하게 되는 셈입니다.

그리고 하나의 에이전트가 여러 개가 되는 순간 문제는 더 커집니다. 더 큰 결과를 위해 협력하는 에이전트 그룹(전문가에게 작업을 위임하는 플래너, 결과를 조정하는 감독자)은 공유 메모리가 필요하며, 이 메모리의 정렬을 유지하는 과정에서 시스템이 무너지기 쉽습니다. 각 에이전트가 개별 상태를 유지하고 피어 투 피어로 컨텍스트를 전달하면 단일 진실 공급원(single source of truth)이 존재하지 않게 됩니다. 에이전트가 서로 달라지고, 쓰기 충돌이 발생하며, 에이전트 그룹이 커질수록 거버넌스가 적용되지 않는 채널이 늘어납니다. 메모리를 교환하는 것이 가장 어려운 부분임이 드러납니다.

Lakebase는 이러한 격차를 해소합니다. 이는 Databricks 플랫폼 내의 완전 관리형 PostgreSQL 스토리지로, 다른 모든 요소와 동일한 거버넌스 플레인 아래에 있습니다. 에이전트 상태는 거버넌스가 적용되는 자산이 됩니다. 플랫폼의 액세스 제어를 상속받고, 에이전트의 데이터 및 도구와 함께 공존하며, 별도의 인프라 팀이 필요하지 않습니다. 또한 모든 에이전트가 동일한 트랜잭션 레이어를 읽고 쓰기 때문에 에이전트 그룹의 단일 진실 공급원 역할도 겸하게 됩니다. 상태가 일관되게 유지되고, 원자적 업데이트를 통해 두 에이전트가 동일한 작업을 손상시키는 것을 방지하며, 한 에이전트의 뷰에 적용된 정책이 다음 에이전트를 위해 기록하는 모든 내용에 전달됩니다. 또한 어떤 에이전트가 기록했는지, 어떤 에이전트가 읽었는지, 깊은 결론이 어떻게 도출되었는지 등 모든 메모리를 에이전트 그룹 전체에서 추적할 수 있습니다.

데이터 네이티브 에이전트의 당위성

거버넌스 측면의 논거가 가장 강력하지만, 장점은 여기서 끝나지 않습니다. 에이전트가 데이터 스택 내부에서 실행되면 보안, 품질, 관측 가능성, 배포, 지연 시간, 비용 등 모든 운영 차원에서 장점이 극대화됩니다. 도구 및 데이터 종속성이 모델과 함께 구성되고 기록되므로, 전체 시스템이 기본적으로 버전 관리되고 감사 가능하며 재현 가능해집니다.

다음 비교는 프로덕션 시스템에서 가장 중요한 차원에 걸쳐 이 두 패러다임이 어떻게 다른지 요약해 보여줍니다.

Databricks에서 데이터 네이티브 에이전트의 실제 모습

Data Intelligence Platform은 이를 실천에 옮깁니다. 별도의 "AI 스택"을 구축하고 이를 데이터에 연결하는 대신, 데이터 스택 자체 내부에서 AI 에이전트를 구축합니다. Databricks의 데이터 네이티브 에이전트는 다음과 같은 특징을 가집니다.

• 모든 모델 및 에이전트 트래픽을 Unity AI Gateway를 통해 라우팅합니다. 여기서 모든 요청은 실행 전에 확인되고 모든 응답은 실행 후에 검사되며, 사후에 최선의 필터링을 수행하는 대신 결정론적인 ALLOW / DENY / ASK 정책이 적용됩니다. 외부 LLM 제공업체 및 코딩 에이전트에 대한 호출을 포함하여 액세스 제어, 속도 제한, 페이로드 로깅 및 비용 추적이 모두 동일한 제어 평면(control plane)에서 이루어집니다.
• 모든 AI 프리미티브(모델, 에이전트, MCPs, 스킬 및 이들이 호출하는 도구)를 테이블 및 함수와 함께 Unity Catalog 자산으로 취급하므로, 전체 AI 영역에 걸쳐 ID, 계보(lineage) 및 액세스 제어가 균일하게 적용됩니다.
• MLflow 3를 통해 전체 요청 추적을 캡처합니다. 모든 LLM 호출, 도구 호출, 점수, 평가, 검색된 문서 및 엔드투엔드 모니터링 루프를 규정 준수를 위해 감사하고 디버깅을 위해 관측할 수 있습니다.
• 제3자 AI 스택으로의 제어되지 않는 데이터 이동 없이 Model Serving의 Databricks 보안 경계 내에서 추론을 실행합니다.
• AI Search를 통해 Unity Catalog ACLs를 준수하고 계보를 자동으로 추적하는 Delta 기반 인덱스에서 컨텍스트를 검색합니다.
• Lakebase 기반 상태 및 메모리를 통해 세션 간에 기억을 유지합니다. 단기 대화 컨텍스트, 다단계 작업 진행 상황, 장기 사용자 선호도 및 과거 도구 호출에 대한 에피소드 기억이 에이전트가 추론하는 데이터와 함께 저장됩니다.
• Unity Catalog Semantics(Metrics, Business Glossary, Domains) 및 Genie Ontology(팀이 이미 사용하는 테이블, 쿼리, 대시보드 및 앱에서 자동으로 추출 및 유지 관리되는 지식 그래프)를 통해 비즈니스 컨텍스트에 기반한 추론을 수행합니다.
• 플랫폼 경계 내에서 도메인 간, 다단계 조정을 통해 구조화된 데이터 질문을 위한 Genie를 포함한 다른 에이전트에게 전문화된 추론을 위임합니다.
• 공유 세션 및 공통 감사 추적을 통해 Claude Code, Codex 및 Cursor를 Unity AI Gateway로 라우팅하는 메타 하네스인 Omnigent를 통해 코딩 에이전트에도 동일한 거버넌스를 확장합니다.

시작하는 방법

일부 기업들은 이미 이러한 방식으로 구축하고 있습니다. 이들의 에이전트는 데이터와 동일한 경계 내에서 실행되며, Unity Catalog 정책이 데이터와 에이전트 모두를 포괄하고, 상태는 Lakebase에 저장되며, 트래픽은 Unity AI Gateway를 통과합니다. 단 한 번의 플랫폼 재구축 프로젝트로 이 단계에 도달한 기업은 없습니다. 이들은 레이크하우스와 AI 스택 사이의 간극을 한 번에 하나의 파일럿 프로젝트씩 메워 나갔고, 더 이상 새로운 스택을 만들지 않았습니다.

이제 막 시작하는 팀의 경우, 작업이 그리 거창하지 않습니다. 대부분의 요소는 이미 플랫폼 측에 존재합니다(Model Serving, Unity Catalog, Lakebase, MLflow). 누락된 것은 이러한 요소들을 병렬 스택을 위한 데이터 소스가 아니라 에이전트의 보금자리로 취급하겠다는 결정뿐입니다. 대개 그 결정이 가장 어려운 부분입니다.

가장 유용한 시작점은 이미 경계 외부에서 실행 중인 항목의 인벤토리를 작성하는 것입니다. 다음 거버넌스 사고는 바로 그곳에서 발생할 것이며, 이 작업이 다른 모든 것을 가능하게 만듭니다.

적절한 가드레일과 패턴을 갖춘 데이터 네이티브 에이전트를 운영하는 방법에 대해 더 자세히 알아보고 싶다면 다음 리소스가 좋은 출발점이 될 것입니다.

• 전략을 구체적인 제어로 전환하려면 기업을 위한 실용적인 AI 거버넌스 프레임워크를 읽어보세요. 이 글에서는 고수준의 목표를 Databricks Data Intelligence Platform의 역할, 정책 및 워크플로우로 전환하는 방법을 보여줍니다.
• 실무에서의 책임감 있는 AI에 대한 더 넓은 관점을 보려면 AI 거버넌스 모범 사례: 책임감 있고 효과적인 AI 프로그램을 구축하는 방법에서 여러 팀에 걸쳐 채택할 수 있는 원칙과 운영 모델을 살펴보세요.

이 포스트에서 논의된 플랫폼 기능을 살펴보려면 다음을 참조하세요.

• Unity AI Gateway: Data + AI Summit 2026의 새로운 기능 — 결정론적인 ALLOW/DENY/ASK Custom Guardrails를 갖춘 모든 모델 및 에이전트 트래픽을 위한 단일 제어 평면.
• Agent Bricks: Data + AI Summit 2026 — 플랫폼에서 최고 수준의 관리형 워크로드로 제공되는 자동 최적화 에이전트.
• Omnigent: 에이전트를 결합, 제어 및 공유하기 위한 메타 하네스 — 공유 감사 추적을 통해 코딩 에이전트(Claude Code, Codex, Cursor)를 Unity AI Gateway로 라우팅합니다.
• Genie One, Genie Agents 및 Genie Ontology 소개 — 에이전트를 비즈니스 컨텍스트에 기반하게 만드는 자동으로 유지 관리되는 지식 그래프.
• AI 에이전트를 위한 메모리 확장 — 플랫폼 내부의 Unity Catalog에 의해 관리되는 Lakebase에서 에이전트 상태 및 메모리가 확장되는 방식.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)