Denodo와 AWS 통합, 에이전트 데이터의 신뢰 경계

AI 요약

• 무슨 일: Denodo가 Amazon Bedrock AgentCore, Amazon SageMaker Catalog, Amazon Quick과의 신규 통합을 발표했습니다.
  • 발표일은 2026년 5월 18일이며, Denodo는 live data access, semantic layer, MCP 지원, AWS의 에이전트 통제를 하나로 묶겠다고 설명했습니다.
• 핵심 의미: 에이전트 인프라의 병목이 MCP 서버 연결 자체에서 데이터 의미, 권한, 최신성, lineage 관리로 이동하고 있습니다.
• 실무 영향: 기업 AI 팀은 에이전트가 어떤 데이터를 볼 수 있는지뿐 아니라 그 데이터가 현재 업무 규칙과 사용자 권한 안에서 해석되는지 확인해야 합니다.
• 주의점: 발표는 제품 통합 뉴스에 가깝습니다. 실제 효과는 MCP 서버 구성, 카탈로그 품질, 접근 정책, 감사 로그 설계가 따라올 때 검증됩니다.

2026년 5월 18일, Denodo가 AWS와의 신규 통합을 발표했습니다. 한 문장으로 줄이면 "에이전트가 기업 데이터에 더 안전하게 접근하게 하겠다"입니다. 하지만 이 문장을 너무 빨리 지나치면 중요한 변화가 흐려집니다. 이번 발표의 핵심은 데이터 연결 수가 늘었다는 데 있지 않습니다. AI 에이전트가 실제 업무 시스템을 읽고 행동하려면 어떤 데이터가 신뢰 가능한지, 어떤 사용자가 어떤 맥락에서 접근할 수 있는지, 그 데이터의 비즈니스 의미가 무엇인지, 나중에 누가 무엇을 근거로 실행했는지 증명할 수 있어야 한다는 문제를 정면으로 건드립니다.

Denodo는 이 문제를 자기 영역인 logical data management와 semantic layer로 풀려 합니다. AWS 쪽에서는 Amazon Bedrock AgentCore, Amazon SageMaker Catalog, Amazon Quick이 등장합니다. AgentCore는 에이전트의 인증, 라우팅, 접근 통제 같은 실행 경계를 담당합니다. SageMaker Catalog는 데이터와 AI 자산의 발견, 메타데이터, lineage, 거버넌스를 다룹니다. Amazon Quick은 생성형 BI와 에이전틱 워크플로가 사용자를 만나는 표면입니다. Denodo는 이 세 층 사이에 자사 플랫폼을 끼워 넣어 하이브리드·멀티클라우드 데이터에 live, zero-copy, governed access를 제공하겠다고 말합니다.

이 뉴스가 흥미로운 이유는 최근 AI 에이전트 시장의 반복되는 구호와 맞물리기 때문입니다. 요즘 거의 모든 벤더가 MCP를 말합니다. "우리 도구를 MCP 서버로 노출합니다", "에이전트가 내부 시스템을 호출할 수 있습니다", "Slack, GitHub, Salesforce, 데이터베이스를 연결합니다" 같은 문장이 보도자료와 문서에 넘칩니다. 연결이 쉬워지는 것은 분명 좋은 일입니다. 그러나 연결이 많아질수록 다음 질문은 더 날카로워집니다. 에이전트가 방금 조회한 데이터는 최신입니까? 같은 단어를 재무팀과 영업팀이 다르게 쓰고 있지는 않습니까? 사용자 A에게 허용된 열과 사용자 B에게 허용된 열이 다를 때 MCP 서버는 그 차이를 어디에서 강제합니까? 에이전트가 만든 결론이 틀렸을 때 어떤 원천 데이터와 정책을 따라갔는지 추적할 수 있습니까?

Denodo의 발표는 바로 이 지점에 붙어 있습니다. 회사는 AI 에이전트가 실시간 인식이 부족하거나, 불완전한 데이터로 작동하거나, 거버넌스 경계를 벗어나면 신뢰할 수 있는 결과를 내기 어렵다고 설명합니다. 중요한 표현은 "이는 모델 문제가 아니라 데이터 문제"라는 프레임입니다. 프런티어 모델을 바꿔도 데이터의 의미가 흔들리거나 권한 정책이 우회되면 업무 자동화는 안전해지지 않습니다. 더 큰 모델이 잘못된 데이터에 더 그럴듯한 문장을 붙일 수는 있지만, 그 자체로 데이터 품질과 권한 경계를 해결하지는 않습니다.

Denodo가 AWS 세 층에 붙인 것

첫 번째 축은 Amazon Bedrock AgentCore입니다. AWS는 AgentCore를 "효과적인 에이전트를 안전하게 규모 있게 구축, 배포, 운영하는 플랫폼"으로 설명합니다. AgentCore FAQ와 문서에서 반복되는 키워드는 identity, gateway, scoped access, secure permissions delegation, observability입니다. Denodo 발표에서는 이 중 인증, 요청 라우팅, 접근 제어가 특히 중요합니다. 에이전트가 데이터에 접근할 때 Denodo가 데이터의 의미와 사용 가능 범위를 제공하고, AgentCore가 해당 요청을 어떤 신원과 정책으로 처리할지 관리하는 그림입니다.

두 번째 축은 Amazon SageMaker Catalog입니다. AWS의 SageMaker Catalog 공식 페이지는 데이터, AI 모델, BI 대시보드, 애플리케이션을 한 곳에서 발견하고 거버넌스하겠다고 설명합니다. 이때 generative AI-created metadata, business glossary, fine-grained access controls, data classification, data and ML lineage가 함께 언급됩니다. Denodo는 SageMaker Catalog의 business metadata와 context를 Denodo 쪽 데이터 접근에 연결해 에이전트가 데이터를 "열 이름"이 아니라 "업무 의미"로 해석하도록 돕겠다고 말합니다.

세 번째 축은 Amazon Quick입니다. Amazon Quick의 MCP 서버 문서는 MCP가 Quick에 커스텀 도구와 통합을 붙이는 표준이라고 설명합니다. 사용자는 MCP 서버를 연결해 데이터베이스, 내부 API, 개발 도구 같은 외부 시스템을 대화와 scheduled agents에서 사용할 수 있습니다. Denodo 관점에서는 Quick이 사용자와 에이전트가 만나는 표면이고, Denodo MCP가 데이터 접근 도구가 되며, AWS와 Denodo의 정책 계층이 그 아래에서 접근을 조율하는 구조입니다.

이 표에서 눈여겨볼 점은 각 제품이 모두 "에이전트 플랫폼"이라고 말하지 않는다는 것입니다. AgentCore는 런타임과 통제면에 가깝고, SageMaker Catalog는 데이터 거버넌스와 자산 발견에 가깝고, Quick은 업무 사용자의 분석·자동화 표면에 가깝습니다. Denodo는 이들을 데이터 의미 계층으로 묶습니다. 에이전트 시대에는 이 분업이 중요합니다. 하나의 MCP 서버가 모든 문제를 해결한다기보다, MCP는 도구 호출의 문법이고, 실제 신뢰는 데이터 catalog, semantic model, identity, masking, lineage, runtime policy가 같이 움직일 때 생깁니다.

MCP 연결의 다음 문제

MCP는 AI 에이전트 생태계에서 빠르게 기본 언어가 되고 있습니다. 데이터베이스를 연결하고, 내부 API를 호출하고, SaaS 기능을 도구로 노출하는 방식이 표준화되면 개발자는 매번 전용 플러그인을 만들 필요가 줄어듭니다. 하지만 MCP가 표준 호출 형식을 제공한다고 해서 호출 대상의 의미와 권한이 자동으로 올바르게 관리되는 것은 아닙니다.

예를 들어 영업 데이터베이스에 revenue라는 열이 있다고 합시다. 어떤 팀은 예약 매출을 revenue로 부르고, 다른 팀은 인식 매출만 revenue로 부를 수 있습니다. 어떤 지역은 세금 포함 금액을 보고, 어떤 지역은 제외 금액을 볼 수 있습니다. 임원은 전체 고객을 볼 수 있지만, 계정 담당자는 자기 담당 고객만 볼 수 있습니다. 고객명은 볼 수 있어도 계약 조건은 마스킹되어야 할 수 있습니다. 에이전트가 "이번 분기 위험 고객을 찾아 조치안을 만들어줘"라고 요청받았을 때, 단순 SQL 생성 능력만으로는 이 차이를 감당하기 어렵습니다.

Denodo가 내세우는 semantic layer와 governance는 이 문제를 겨냥합니다. 발표에 따르면 Denodo는 SAP, Oracle, Salesforce 같은 엔터프라이즈 시스템을 포함해 200개 이상의 native connection을 제공하고, attribute-based access controls, dynamic data masking, end-to-end lineage capture 같은 통제를 갖고 있습니다. 이런 기능은 전통적인 BI와 데이터 가상화에서도 필요했습니다. 그러나 에이전트가 등장하면서 중요도가 달라졌습니다. 사람이 대시보드를 보며 판단할 때는 중간에 해석과 의심이 끼어들 수 있지만, 에이전트는 같은 데이터를 근거로 다음 시스템을 호출하거나 워크플로를 진행할 수 있기 때문입니다.

RAG 인덱스와 live data의 차이

지난 2년 동안 기업 AI 도입의 기본 답은 RAG였습니다. 문서와 데이터를 벡터 인덱스에 넣고, 사용자의 질문과 가까운 조각을 찾아 모델에 전달합니다. 이 방식은 여전히 중요합니다. 하지만 업무 시스템의 현재 상태를 다루는 에이전트에는 한계가 있습니다. 재고, 거래, 계약 상태, 고객 세그먼트, 보안 권한, 승인 단계는 계속 변합니다. 어제 인덱싱한 문서가 오늘의 운영 상태를 보장하지 않습니다.

Denodo가 강조하는 live, zero-copy access는 이 지점에서 의미가 있습니다. 데이터를 모두 복제해 하나의 AI 전용 저장소로 옮기기보다, 원천 시스템과 정책을 유지한 채 필요한 순간에 접근하겠다는 방향입니다. 물론 이것이 항상 더 쉽거나 빠르다는 뜻은 아닙니다. live query는 지연시간, 원천 시스템 부하, 캐시 정책, 장애 전파라는 현실 문제를 만납니다. 그러나 규제가 강한 조직이나 데이터가 여러 클라우드와 온프레미스에 흩어진 조직에서는 복제 기반 접근이 더 큰 위험을 만들 수도 있습니다. 어떤 데이터가 언제 어디로 복제됐는지, 마스킹 정책이 복제본에도 반영됐는지, 삭제 요청이 모든 파생 인덱스에 전달됐는지 관리해야 하기 때문입니다.

에이전트는 이 문제를 더 어렵게 만듭니다. 사용자가 직접 쿼리를 만들 때는 쿼리 범위가 비교적 명시적입니다. 반면 에이전트는 사용자의 목표를 받아 여러 번 데이터를 조회하고, 중간 결론을 세우고, 다시 다른 도구를 호출할 수 있습니다. "현재성"과 "권한"이 한 번의 API 호출에만 적용돼서는 부족합니다. 세션 전체에서 어떤 사용자 대신 행동하는지, 어떤 예산과 정책 안에서 움직이는지, 어떤 데이터가 어떤 결과로 이어졌는지 기록되어야 합니다. 그래서 AgentCore 같은 실행 통제 계층과 Denodo 같은 데이터 의미 계층의 결합이 단순 파트너십 문구 이상으로 읽힙니다.

개발자가 확인해야 할 것은 연결 성공이 아니다

이 발표를 실무 관점에서 보면 체크리스트가 바뀝니다. 예전에는 "MCP 서버가 붙는가", "자연어 질문이 SQL로 바뀌는가", "대시보드 답변이 나오는가"가 데모의 중심이었습니다. 이제는 그 다음을 물어야 합니다.

첫째, 사용자 신원이 끝까지 전달됩니까? 에이전트가 서비스 계정 하나로 모든 데이터를 조회하면 데모는 쉬워집니다. 하지만 실제 조직에서는 사용자의 역할, 부서, 지역, 데이터 사용 목적에 따라 다른 접근 정책이 필요합니다. AgentCore Identity나 IAM, Denodo의 access control, 원천 시스템의 권한 모델이 서로 어긋나면 에이전트는 너무 많은 데이터를 보거나, 반대로 필요한 데이터를 보지 못할 수 있습니다.

둘째, semantic layer가 실제로 유지관리됩니까? "비즈니스 문맥을 붙인다"는 말은 보도자료에서는 좋아 보이지만, 현실에서는 owner, glossary, certification, lineage, deprecation, metric definition 관리가 필요합니다. 에이전트가 믿을 수 있는 데이터 계층을 만들려면 데이터팀과 업무팀이 용어를 합의하고, 모델과 카탈로그가 그 합의를 따라가야 합니다. 좋은 MCP 서버는 이 노력을 대체하지 않습니다. 오히려 더 많은 사용자가 더 쉽게 데이터에 접근하게 만들기 때문에 semantic debt를 더 빨리 드러냅니다.

셋째, 실패했을 때 추적할 수 있습니까? 에이전트가 틀린 결론을 냈을 때 단순히 "모델이 환각했다"고 말하면 문제를 고칠 수 없습니다. 어떤 데이터셋을 조회했는지, 어떤 행과 열이 마스킹됐는지, 어떤 business metadata를 참고했는지, 어떤 policy decision이 내려졌는지, 어떤 중간 답변이 다음 action으로 이어졌는지 봐야 합니다. Denodo의 lineage와 AWS의 AgentCore observability, SageMaker Catalog의 데이터·AI 자산 추적이 실제 가치가 있으려면 이 디버깅 경로가 이어져야 합니다.

경쟁은 데이터 계층으로 내려간다

이번 발표는 Denodo 하나만의 이야기가 아닙니다. Databricks는 Unity Catalog를 통해 데이터와 AI 거버넌스 경계를 잡으려 하고, Snowflake는 Cortex와 자사 데이터 클라우드를 묶어 AI 앱을 데이터 가까이에 두려 합니다. Microsoft Fabric, Google Dataplex, Collibra, Alation, Informatica, Atlan 같은 도구들도 data catalog와 governance를 AI 시대 언어로 재해석하고 있습니다. 차이는 각자가 어디에서 출발했느냐입니다. 모델 회사는 agent API와 tool calling에서 출발합니다. 클라우드는 runtime과 identity에서 출발합니다. 데이터 플랫폼은 catalog, lineage, semantic layer에서 출발합니다. 업무 SaaS는 실제 프로세스와 권한 모델에서 출발합니다.

Denodo의 위치는 흥미롭습니다. Denodo는 프런티어 모델 회사가 아니고, AWS처럼 전체 클라우드 런타임을 쥔 회사도 아닙니다. 대신 여러 데이터 소스를 논리적으로 묶고, 복제 없이 접근하고, 의미 계층을 유지하는 오래된 데이터 통합 문제를 에이전트 시대 언어로 다시 제시합니다. 이것이 시장에서 얼마나 큰 차별점이 될지는 아직 열려 있습니다. 그러나 문제 자체는 분명합니다. 에이전트가 실제 업무를 맡을수록 "모델이 똑똑한가"보다 "모델이 읽는 세계가 정리되어 있는가"가 중요해집니다.

커뮤니티 반응도 아직은 발표보다 문제의식 쪽이 더 큽니다. GeekNews와 Hacker News에서 Denodo 발표 자체가 큰 토론으로 번진 흔적은 확인되지 않았습니다. Reddit의 AWS와 MCP 관련 논의는 AgentCore를 실제 production에서 어떻게 쓰는지, MCP registry와 runtime state를 어떻게 다루는지, AWS식 제약이 다른 플랫폼과 어떻게 다른지 묻는 쪽에 가깝습니다. BI와 데이터 엔지니어링 커뮤니티에서는 AI가 SQL이나 catalog를 대체한다는 주장에 회의적이며, 오히려 AI 에이전트가 신뢰할 수 있는 metadata와 semantic layer를 더 필요로 한다는 반응이 보입니다. Denodo 발표는 그 흐름 위에 올라탄 셈입니다.

아직 검증해야 할 부분

물론 이 발표만으로 Denodo와 AWS 조합이 에이전트 데이터 문제를 해결했다고 말할 수는 없습니다. 발표는 통합 방향과 기능 범위를 설명하지만, 실제 도입에서는 세부가 성패를 가릅니다. MCP 서버가 어떤 권한 모델로 실행되는지, Quick의 scheduled agents가 사용자별 정책을 어떻게 유지하는지, AgentCore Gateway와 Denodo 정책이 충돌할 때 어떤 계층이 우선하는지, SageMaker Catalog의 metadata가 Denodo semantic model과 얼마나 자동으로 동기화되는지 확인해야 합니다. 데이터가 여러 국가와 규제권역에 흩어진 조직에서는 데이터 이동이 없다는 말만으로 충분하지 않습니다. 쿼리 실행 위치, 로그 저장 위치, 캐시 여부, 감사 보존 기간까지 따져야 합니다.

또 하나의 현실적 질문은 운영 비용입니다. live, governed, semantic access는 설계상 단순한 벡터 인덱스보다 더 많은 조직적 합의를 요구합니다. 데이터 오너를 지정하고, business glossary를 유지하고, masking rule을 테스트하고, lineage를 검증하고, 에이전트가 만드는 tool call을 관측해야 합니다. 단기 데모에는 무거운 작업입니다. 하지만 에이전트가 실제 업무를 실행하는 순간 이 비용은 피하기 어려워집니다. 신뢰 계층을 나중에 붙이려 하면 이미 만들어진 MCP 서버, 에이전트 프롬프트, 데이터 복제본, 권한 예외를 다시 정리해야 합니다.

그래서 이번 뉴스를 과장된 파트너십 발표로만 볼 필요도, 완성된 해법으로 볼 필요도 없습니다. 더 정확한 해석은 에이전트 인프라의 다음 병목이 어디로 이동하는지 보여주는 신호입니다. 2024년과 2025년에는 모델 호출, RAG, tool calling, MCP 연결이 중심이었습니다. 2026년에는 그 연결이 실제 기업 데이터와 업무 권한을 만납니다. 여기서 필요한 것은 더 많은 플러그인 목록이 아니라, 데이터 의미와 접근 정책을 에이전트 실행 경로 안에 넣는 일입니다.

Denodo와 AWS의 통합은 이 방향을 선명하게 보여줍니다. 에이전트가 기업 안에서 유용해지려면 세계를 읽어야 합니다. 그러나 기업의 세계는 파일 몇 개와 API 몇 개가 아니라, 오래된 ERP, 새 SaaS, 데이터 웨어하우스, 부서별 정의, 국가별 규제, 사용자별 권한, 감사 로그가 겹친 구조입니다. 이 구조를 정리하지 않은 채 에이전트에게 행동을 맡기면, 빠른 자동화보다 빠른 혼란이 먼저 올 수 있습니다.

이번 발표의 실무적 메시지는 그래서 단순합니다. MCP를 붙이는 것에서 멈추지 말아야 합니다. 에이전트가 읽는 데이터의 의미, 출처, 현재성, 권한, lineage를 먼저 묻고, 그 답이 런타임 정책과 사용자 경험까지 이어지는지 확인해야 합니다. Denodo가 AWS와 함께 노리는 자리는 바로 그 신뢰 경계입니다. 모델 경쟁이 계속되는 동안, 에이전트가 발을 딛는 데이터 바닥을 누가 관리할지도 조용히 중요한 전장이 되고 있습니다.