사람이 아니라 AI를 위해 — Agentic AI를 위한 데이터 플랫폼

스스로 계획하고 조회하고 실행하는 에이전트가 데이터의 주 소비자가 될 때, 접근·의미·거버넌스·관측 네 개 계층을 어떻게 다시 설계해야 하는지 정리했습니다.

2025년을 지나 2026년으로 넘어오면서, AI 에이전트는 데모나 챗봇의 단계를 확실히 벗어났습니다. 목표 하나를 던지면 스스로 작업을 여러 단계로 나누고, 필요한 툴을 호출하고, 중간 결과를 보고 다음 행동을 다시 정하는 방식이 실제 업무에 들어오기 시작했습니다. 대부분의 조직은 여기에 열을 올립니다. 어떤 프레임워크를 쓸지, 어떤 모델을 붙일지, 프롬프트를 어떻게 설계할지 말이죠. 그런데 정작 에이전트가 발을 딛고 서는 바닥, 즉 데이터에 닿는 층은 여전히 사람을 염두에 두고 짠 설계 그대로인 경우가 많습니다.

이 지점이 이번 글의 문제의식입니다. 비유하자면 이렇습니다. 자율주행차는 아무리 성능이 좋아도 도로 인프라가 사람 운전자 기준으로만 깔려 있으면 제 실력을 내지 못합니다. 차선과 표지판, 신호가 기계가 읽을 수 있는 형태로 다시 정비돼야 자율주행이 굴러갑니다. 데이터 플랫폼도 마찬가지입니다. 소비자가 사람에서 에이전트로 바뀌면 바닥부터 다시 봐야 합니다. 이번 글에서는 에이전트를 위한 데이터 플랫폼을 접근·의미·신뢰·관측 네 개 계층으로 나눠, 설계 관점에서 무엇을 결정해야 하는지 함께 짚어 보겠습니다.

에이전트라는 새로운 '데이터 소비자'

먼저 소비자가 어떻게 바뀌었는지부터 정리하겠습니다. 지금까지 데이터 플랫폼의 소비자는 사람이었습니다. 사람은 분석 도구 앞에서 "묻고 → 본다"는 단순한 패턴으로 움직입니다. 질문을 던지고, 대시보드나 리포트로 답을 확인하고, 필요하면 필터를 바꿔 다시 봅니다.

에이전트는 다릅니다. Agentic AI는 목표를 받아 스스로 단계를 계획하고 실행하는 AI를 말합니다. 그래서 소비 패턴이 "계획 → 조회 → 실행 → 관측 → 재계획"이라는 루프를 그립니다. 이 차이는 단순히 빠르다는 수준이 아니라, 데이터 접근의 성격 자체를 바꿉니다.

• 호출 빈도가 높고 접근 경로가 비결정적입니다. 사람은 정해진 화면에서 정형화된 쿼리를 던지지만, 에이전트는 런타임에 쿼리를 스스로 생성합니다. 같은 목표라도 매번 다른 경로로 데이터에 접근할 수 있습니다.
• 컨텍스트를 런타임에 직접 조립합니다. 필요한 정보를 검색해 오고(RAG), 여러 툴을 호출해 그 결과를 엮어 다음 판단의 재료로 씁니다.
• 읽기를 넘어 쓰기와 실행까지 합니다. 조회에서 멈추지 않고 레코드를 갱신하거나 외부 작업을 트리거하는, 이른바 사이드 이펙트가 있는 행동까지 수행합니다.

핵심은 이겁니다. 소비자가 바뀌면 인터페이스도 바뀌어야 합니다. 사람에게 친절한 접점과 기계에게 친절한 접점은 같지 않습니다.

사람을 위해 지은 플랫폼은 왜 에이전트에겐 안 맞을까

흔한 통념 하나를 짚고 가겠습니다. "기존 데이터 웨어하우스와 BI 스택은 잘 갖춰져 있으니, 그 위에 에이전트만 얹으면 되는 것 아니냐"는 생각입니다. 언뜻 합리적으로 들립니다. 하지만 현실은 그렇지 않습니다.

사람을 위해 공들여 최적화해 온 지점들을 떠올려 보겠습니다. 보기 좋은 GUI 대시보드, 미리 짜 둔 프리셋 필터, 자주 보는 리포트의 캐시. 이것들은 사람에게는 훌륭한 편의성입니다. 그런데 에이전트 입장에서 보면 전부 읽어 낼 수 없는 인터페이스입니다. 화면은 픽셀일 뿐이고, 미리 짜 둔 프리셋은 사람이 클릭할 때만 의미가 있으며, 리포트의 캐시는 생성 목적을 알 수 없는 과거 데이터입니다.

"그렇다면 Text-to-SQL(자연어를 SQL로 바꿔 주는 기능)을 붙이면 되지 않느냐"는 반문이 나올 수 있습니다. 이 역시 만만치 않습니다. 실제로 붙여 보면 세 가지 벽에 부딪힙니다. 첫째, 스키마가 모호합니다. 비슷한 이름의 테이블과 컬럼이 여럿이면 무엇을 골라야 할지 판단할 근거가 없습니다. 둘째, 조인 경로가 폭발합니다. 테이블이 수백 개인 환경에서 A와 B를 어떤 키로, 어떤 경로로 이어야 옳은지는 스키마만 봐서는 결정되지 않습니다. 셋째, 컬럼의 의미가 데이터에 없습니다. CUST_YN 같은 컬럼이 무엇을 뜻하는지는 문서나 사람 머릿속에 있지, 데이터베이스에 적혀 있지 않습니다.

물론 기존 자산을 버리자는 이야기가 아닙니다. 웨어하우스도, 품질 관리도, 그동안 쌓은 것은 대부분 그대로 쓸모가 있습니다. 다만 사람과 기계는 데이터를 만나는 접점이 다릅니다. 그 접점을 새로 설계해야 한다는 것이 요지입니다. 그 설계를 네 개 계층으로 나눠 보겠습니다.

4계층 지도 — 전체 조감

에이전트를 위한 데이터 플랫폼은 아래 네 개 계층으로 정리할 수 있습니다. 도입에서 세운 자율주행 인프라 비유를 각 계층에 대응시켜 한눈에 보겠습니다.

네 계층은 위아래로 맞물립니다. 접근이 뚫려야 의미를 해석할 수 있고, 의미가 서 있어야 거버넌스가 정확한 판단을 내릴 수 있으며, 관측은 이 모든 층을 되먹여 계속 개선합니다. 지금부터 한 층씩 내려가 보겠습니다.

1층 · 접근 계층 — 에이전트가 데이터에 '닿는' 방식

가장 먼저 결정할 것은 에이전트가 데이터에 어떻게 손을 대게 할지입니다. 선택지는 크게 둘입니다. 하나는 에이전트에게 raw SQL 실행 권한을 그대로 여는 방식이고, 다른 하나는 데이터 접근을 툴 또는 함수로 명세화한 인터페이스로만 노출하는 방식입니다.

전자는 편해 보이지만 위험합니다. 에이전트가 임의의 쿼리를 던질 수 있다는 것은 무엇을 조회하고 무엇을 바꿀지 통제할 지점이 사라진다는 뜻이기 때문입니다. 그래서 최근의 설계는 후자로 기웁니다. 여기서 등장하는 표준이 MCP(Model Context Protocol)입니다. MCP는 모델과 외부 데이터·툴을 잇는 개방형 규약으로, 앤트로픽이 2024년 말 공개한 뒤 여러 진영이 채택하며 사실상의 표준으로 자리잡아 가고 있습니다. 어떤 툴이 있고, 무슨 입력을 받고, 어떤 권한 경계 안에서 동작하는지를 선언적으로 노출한다는 것이 핵심입니다.

여기서 중요한 발상 전환이 하나 있습니다. 데이터 접근을 함수로 노출하면, 그 함수의 명세 자체가 곧 행동 명세가 됩니다. 하나의 데이터 접근면을 툴로 정의한다고 할 때, 명세는 세 가지를 계약으로 못박습니다.

• 무슨 입력을 받는가 (예: 기간, 고객 세그먼트 같은 파라미터의 범위)
• 무엇을 반환하는가 (반환 값의 구조와 의미)
• 어떤 권한 경계 안에서 동작하는가 (조회만 되는지, 변경까지 되는지)

즉 에이전트가 볼 수 있는 접근면은 이 명세 그 자체입니다. 명세에 없는 일은 애초에 시도할 수 없습니다. 통제할 수 없는 무한한 SQL 공간이, 설계자가 정의한 유한한 계약의 집합으로 좁혀지는 셈입니다. 그리고 자연어로 들어온 요청을 이 계약으로 번역하는 자리에 시맨틱 게이트웨이를 둡니다. 사람의 말과 데이터의 물리 구조 사이에서, 무엇을 어떤 툴로 처리할지 결정하는 관문입니다.

2층 · 의미 계층 — 기계가 읽는 맥락

도로가 깔려도 문제는 끝나지 않습니다. 진짜 어려움은 여기서 시작됩니다. 에이전트가 데이터의 의미를 모르면 엉뚱한 컬럼을 고르고 잘못된 조인을 조합합니다. 앞서 든 CUST_YN 문제가 바로 이 계층의 과제입니다.

이럴 때 사람은 옆자리 동료에게 "이 컬럼 뭐예요?"라고 물으면 됩니다. 그런데 에이전트에게는 물어볼 옆자리가 없습니다. 그러니 의미가 누군가 머릿속에 있어선 안 되고, 데이터에 내장돼 있어야 합니다. 이것이 의미 계층을 세우는 이유입니다. 구체적으로는 세 겹으로 쌓입니다.

• 메타데이터와 데이터 표준: 각 항목이 무엇을 뜻하는지, 용어를 조직 전체가 어떻게 통일해 쓰는지를 정의합니다.
• 시맨틱 레이어: 물리 스키마 위에 지표(측정값), 차원, 비즈니스 용어를 정의하는 계층입니다. "매출"이 정확히 어떤 계산인지를 한 곳에 고정해, 누가 물어도 같은 답이 나오게 합니다.
• 온톨로지와 그래프: 개체와 개체 사이의 관계, 그리고 그로부터 이어지는 맥락을 다룹니다.

시맨틱 레이어와 온톨로지는 헷갈리기 쉬운데, 역할이 다릅니다. 시맨틱 레이어가 지표와 용어의 일관성을 책임진다면, 온톨로지는 개체 간 관계와 추론을 책임집니다. 전자가 "매출을 어떻게 셀 것인가"를 정한다면, 후자는 "이 고객과 저 주문과 그 상품이 어떻게 연결돼 있는가"를 다룹니다. 둘은 대체 관계가 아니라 보완 관계입니다.

이 대목이 데이터 전문 기업의 시각에서 특히 중요합니다. 엔코아가 오랫동안 다뤄 온 데이터 거버넌스, 즉 메타데이터·표준·품질을 정돈하는 일과, 그래프·온톨로지로 데이터에 의미를 부여하는 일은 결국 하나의 흐름으로 이어집니다. 데이터가 서로 어떤 의미로 연결돼 있는지를 기계가 따라 읽을 수 있게 그려 둔 '데이터 맥락 지도'가 여기서 만들어집니다. 이를 통해 의미와 맥락이 정돈돼 AI가 곧바로 활용할 수 있는 상태의 데이터를 AI Ready Data라 부릅니다. 잘 정돈되고 의미가 연결된 데이터라야 에이전트가 제대로 일한다는 것이죠. 실제 프로젝트에서도 접근 방식이 아무리 세련돼도 이 계층이 비어 있으면 에이전트가 그럴듯하지만 틀린 답을 내놓는 경우를 자주 봅니다.

3층 · 신뢰·거버넌스 계층 — 자율성에 채우는 안전벨트

에이전트가 조회만 한다면 거버넌스는 사람 때와 크게 다르지 않을지 모릅니다. 하지만 앞서 봤듯 에이전트는 쓰기와 실행까지 합니다. 그래서 거버넌스는 사람이 소비자일 때보다 오히려 더 중요해집니다. 이 계층은 세 가지를 담당합니다.

• 품질과 표준: 입력 데이터를 믿을 수 있어야 판단도 믿을 수 있습니다. 쓰레기가 들어가면 자동화된 쓰레기가 대량으로 나옵니다.
• 데이터 리니지(계보): 어떤 데이터가 어디서 와서 어디로 흘러갔는지 추적하는 것입니다. 문제가 생겼을 때 영향 범위를 짚어 내려면 반드시 필요합니다.
• 정책 기반 접근제어: 역할 단위로 권한을 주는 RBAC를 넘어, 속성 기반(ABAC)이나 행 수준 정책으로 "누가, 어떤 조건에서, 무엇을 조회·변경·실행해도 되는가"를 세밀하게 정합니다.

핵심 차이는 통제 지점이 옮겨진다는 데 있습니다. 사람은 화면 앞에서 막힙니다. 권한이 없으면 버튼이 안 눌리고 메뉴가 안 보입니다. 그런데 에이전트에게는 화면이 없습니다. 그러니 통제는 API 층에서 이뤄져야 합니다. 앞서 접근 계층에서 툴로 명세화한 그 경계와, 이 계층의 런타임 정책 결정 지점이 맞물려야 합니다. 에이전트가 어떤 툴을 호출하려 할 때마다, "이 주체가 이 조건에서 이 행동을 해도 되는가"를 판정하고 허용 여부를 돌려주는 지점이 있어야 한다는 뜻입니다. 여기에 모든 행동을 감사할 수 있게 남기고, 문제가 생기면 되돌릴 수 있는 롤백 경로까지 갖추면 안전벨트가 완성됩니다.

자율성은 분명 매력적입니다. 하지만 통제 없는 자율성은 사고를 부릅니다. 도로에 비유하자면, 신호등과 교통법규가 없는 자율주행은 자율이 아니라 방치입니다. 빠른 차일수록 제동과 규칙이 더 정교해야 하는 것과 같은 이치입니다.

4층 · 관측·제어 계층 — 에이전트의 행동을 지켜보기

마지막 계층은 에이전트가 무엇을 했는지 지켜보는 일입니다. 세 가지로 이뤄집니다. 첫째, 로깅과 감사입니다. 에이전트가 무엇을, 왜 조회하고 실행했는지 기록으로 남깁니다. 둘째, 데이터 옵저버빌리티입니다. 데이터의 품질과 신선도, 스키마 변화를 지속적으로 감시해 이상을 조기에 잡아내는 것을 말합니다. 셋째, 피드백 루프입니다.

여기서 통념을 한 번 뒤집어 보겠습니다. 관측을 흔히 '사고가 난 뒤 들춰 보는 사후 감사' 정도로 여깁니다. 하지만 에이전트 환경에서는 관측이 오히려 플랫폼을 계속 AI Ready 상태로 유지하는 운영 루프가 됩니다. 무슨 뜻일까요?

에이전트가 어떤 데이터에 자주 접근하다 실패하는지, 어떤 질문에서 엉뚱한 컬럼을 고르는지가 로그에 고스란히 남습니다. 이 로그는 곧 신호입니다. "어느 데이터에 의미 정비나 품질 보강이 더 필요한지"를 가리키는 지도인 셈입니다. 사람용 시스템에서는 사용자가 불편을 참거나 우회했을 뿐 기록으로 남지 않던 것이, 에이전트 환경에서는 정량적 신호로 잡힙니다. 관측 계층이 의미 계층으로 되먹임되고, 그 결과 다음 사이클에서 에이전트가 더 잘 일하게 되는 선순환이 만들어집니다.

어디서부터 시작할까 — 도입 로드맵과 한계

네 계층을 한꺼번에 다 세우려 하면 지치기 쉽습니다. 그래서 점진적으로 접근하길 권합니다.

• 먼저 에이전트가 실제로 건드릴 데이터 도메인을 하나만 고릅니다. 전사가 아니라 한 영역입니다.
• 그 도메인의 의미·품질·권한부터 정비합니다. 의미 계층과 거버넌스 계층을 좁은 범위에서 단단히 세우는 단계입니다.
• 그다음 그 도메인의 데이터 접근을 툴로 명세화합니다. 접근 계층을 얹는 것이죠.
• 마지막으로 관측을 붙여 되먹임을 확인한 뒤, 검증된 패턴을 다른 도메인으로 넓힙니다.

다만 이 4계층이 모든 상황의 정답은 아닙니다. 조직과 데이터의 성숙도에 따라 전면 구축은 과설계가 될 수 있습니다. 에이전트가 아직 실험 단계라면, 무거운 시맨틱 레이어를 처음부터 까는 것보다 기존 자산을 병행하며 필요한 만큼만 정비하는 편이 현실적입니다. 표준화에는 비용이 들고, 시맨틱 레이어와 온톨로지는 한번 만들면 끝이 아니라 계속 손봐야 하는 유지보수 대상이라는 점도 냉정히 봐야 합니다. 무엇을 지금 세우고 무엇을 미룰지 고르는 판단이, 계층을 아는 것만큼이나 중요합니다.

닿고, 이해하고, 신뢰하고, 지켜보기

지금까지의 이야기를 한 문장으로 압축하면 이렇습니다. 에이전트를 위한 데이터 플랫폼은 결국 데이터에 닿고(접근) → 이해하고(의미) → 신뢰하고(거버넌스) → 지켜보는(관측) 네 겹의 설계 문제였습니다. 그래서 처음에 던진 통념, "모델과 프레임워크만 바꾸면 된다"는 생각은 절반만 맞습니다. 위층을 아무리 정교하게 다뤄도 아래 네 계층이 사람 기준 그대로면, 에이전트는 똑똑한 채로 길을 잃습니다.

아무리 성능 좋은 자율주행차도 표지판 없는 길에선 멈춰 섭니다. 우리 데이터 플랫폼이 에이전트에게 표지판을 제대로 세워 주고 있는지, 지금 우리 조직의 에이전트가 네 계층 중 어디에서 막혀 있는지부터 진단해 보시길 권합니다. 접근이 없어서인지, 의미를 못 읽어서인지, 통제가 없어 열어 주지 못하는 것인지, 지켜볼 눈이 없어서인지 말이죠. 특히 의미 계층은 대부분의 조직이 가장 취약하면서도 가장 나중에야 손대는 곳입니다. 데이터에 맥락이라는 표지판을 새겨 넣는 일, 그 아키텍처적 사고 전환이 에이전트 시대 데이터 플랫폼의 출발점입니다.