AI-Ready Data Platform으로 가는 세 가지 질문

들어가며

데이터 플랫폼을 직접 탐색하고 해석하는 주체는 오랫동안 사람이었습니다.

사람은 필요한 데이터를 찾아 분석하고 비즈니스 의사결정에 활용하거나, 이를 바탕으로 모델과 데이터 기반 서비스를 만들었습니다. 이렇게 만들어진 모델과 서비스는 미리 정의된 데이터와 로직에 따라 반복적으로 동작했습니다.

이 구조에서는 테이블 이름이 다소 모호하거나 컬럼의 의미가 문서에 충분히 설명되어 있지 않더라도, 사람은 조직 안에서 쌓은 경험과 주변 맥락을 바탕으로 의미를 추론하거나 필요한 경우 담당자에게 직접 확인할 수 있었습니다. 반면 모델이나 서비스가 데이터를 사용할 때는 어떤 데이터를 어떻게 사용할지가 개발 단계에서 미리 정의되어 있었습니다.

하지만 AI Agent가 업무에 본격적으로 활용되기 시작하면서 이 전제가 조금씩 달라지고 있습니다. AI Agent는 필요한 데이터를 스스로 탐색하고, 그 결과를 바탕으로 다음 행동을 판단할 수 있지만, 사람이 조직 안에서 자연스럽게 쌓아온 경험과 암묵적인 맥락은 가지고 있지 않습니다. 동시에 기존의 데이터 기반 서비스처럼 사용할 데이터와 접근 방식이 개발 단계에서 모두 정해져 있지도 않습니다.

AI-Ready Data Platform이라는 완성된 그림을 전제로 시작한 것은 아닙니다. AI 활용이 늘어나면서 데이터 플랫폼에도 새로운 요구와 문제가 생기기 시작했고, 이를 하나씩 풀다 보니 결국 몇 가지 공통된 문제로 모이게 되었습니다.

처음에는 AI가 SQL을 작성할 수 있다면 데이터 활용의 상당 부분을 자동화할 수 있을 것처럼 보였습니다. 최근의 LLM은 자연어를 SQL로 변환하는 작업도 상당한 수준으로 수행할 수 있습니다. 하지만 SQL을 정확하게 작성하는 것과 데이터를 올바르게 사용하는 것은 같은 문제가 아닙니다. 가령 각 쿼리가 서로 독립적으로 90% 정확하다고 단순히 가정해도, 10개의 쿼리가 모두 정확할 확률은 약 35%에 불과합니다. 여러 번의 조회와 판단을 연속해서 수행하는 Agent에서는 작은 오류도 빠르게 누적될 수 있습니다.

더 근본적인 문제도 있습니다. AI가 loan_status = 3이라는 컬럼을 발견했다고 해보겠습니다. SQL을 만드는 것은 어렵지 않지만, 3이 연체를 의미하는지 상환 완료를 의미하는지는 스키마만 보고 확정할 수 없습니다. 사람이라면 조직의 경험이나 담당자 확인으로 보완했을 맥락이, AI에게는 바로 이 지점에서 빠져 있습니다. 게다가 의미를 정확히 이해한다고 해서 모든 데이터에 접근하게 할 수도 없습니다. 사용자를 대신하는 AI라면 어디까지 볼 수 있는지, 권한을 어떻게 이어받는지, 실제 조회는 어떤 통로로 이루어지는지도 함께 정의해야 합니다.

어피닛 데이터 엔지니어링 팀은 이런 문제를 겪으며 AI를 기존 데이터 활용을 자동화하는 도구로만 보지 않고, 데이터 플랫폼의 새로운 소비자(Data Consumer)로 보기 시작했습니다.

최근 Snowflake의 AI-Ready Data Framework나 AWS의 semantic ontology 관련 논의에서도 비슷한 방향을 확인할 수 있습니다. 깨끗한 데이터를 준비하거나 자연어로 쿼리할 수 있게 만드는 것을 넘어, AI가 데이터의 의미를 이해할 수 있도록 비즈니스 맥락을 제공하고, 기존의 접근 통제와 거버넌스 원칙을 AI 활용에도 적용하는 것이 AI-Ready Data Platform의 중요한 조건으로 다뤄지고 있습니다.

참고:
Snowflake, AI-Ready Data Framework: Assess and Remediate Your Data for AI
AWS, Build a semantic ontology to power AI assistants on AWS

이 공통된 문제들을 정리해보니, 결국 새로운 소비자를 데이터 플랫폼에 받아들이기 위한 세 가지 질문으로 좁혀졌습니다.

1. AI는 데이터가 무엇을 의미하는지 이해할 수 있는가?

2. AI는 어디까지 데이터에 접근할 수 있어야 하는가?

3. AI는 허용된 경계 안에서 어떻게 데이터에 접근할 것인가?

저희는 각각의 질문을 Context, Governance, Interface의 문제로 보고 있습니다.

이 글에서는 이 세 가지 질문을 어떤 관점으로 바라보고 있으며, 데이터 플랫폼을 어떻게 AI-Ready한 방향으로 변화시키고 있는지 공유합니다. 모든 문제가 이미 해결된 것은 아닙니다. 일부는 운영 중이고, 일부는 구축하고 있으며, 아직 답을 찾아가고 있는 영역도 있습니다. 완성된 아키텍처보다, 새로운 데이터 소비자를 받아들이기 위해 어떤 질문을 던지고 어떤 순서로 답해가고 있는지에 초점을 맞추겠습니다.

1. AI는 데이터가 무엇을 의미하는지 이해할 수 있는가? — Context

이처럼 AI가 데이터를 제대로 사용하려면, 먼저 그 데이터가 무엇을 의미하는지 이해할 수 있어야 합니다. 최근 LLM은 테이블 이름과 컬럼 이름, 샘플 데이터만으로도 의미를 그럴듯하게 추론하지만, 그 추론을 신뢰할 수 있는지는 다른 문제입니다. 예를 들어 이름이 비슷한 여러 테이블 중 더 이상 사용하지 않는 테이블을 선택하거나, 코드값의 의미를 임의로 추정해 잘못된 조건을 만들더라도 SQL 자체는 정상적으로 실행될 수 있습니다. 결과 역시 얼핏 보면 그럴듯해 보일 수 있습니다. 이런 오류는 쿼리 실패처럼 명확한 신호를 남기지 않기 때문에 오히려 발견하기 어렵습니다.

결국 AI가 데이터를 올바르게 이해하려면, 데이터 옆에 그 의미를 함께 제공해야 합니다. 이를 두 단계로 나누어 볼 수 있습니다.

첫째, 카탈로그와 메타데이터입니다. 어떤 테이블이 있고, 각 컬럼이 무엇을 담고 있으며, 데이터가 언제 갱신되고 어떻게 관리되고 있는지 — 이런 정보가 정리되어 있어야 AI든 사람이든 데이터를 탐색하고 이해할 수 있습니다. 이를 위해 사내 데이터 플랫폼인 Data Lake Manager(DLM)를 운영하고 있습니다. Amundsen과 OpenMetadata 같은 기존 메타데이터 플랫폼도 도입해보았지만, 현재는 데이터 환경과 운영 방식에 필요한 핵심 기능을 DLM으로 직접 구현해 운영하고 있습니다. DLM의 크롤러는 주요 운영 스키마의 Glue Data Catalog를 주기적으로 훑어 테이블의 메타데이터를 자동으로 수집하고 관리합니다. 컬럼명과 타입, 등록된 설명, 데이터의 신선도와 최종 갱신 시각, 그리고 스키마가 언제 어떻게 바뀌었는지(스키마 드리프트)까지 한곳에 모읍니다. 현재 36개 주요 스키마에 걸쳐 1,600여 개의 활성 데이터셋을 DLM에서 관리하고 있습니다. 데이터를 이해하기 위한 기본 재료를 갖추는 단계라고 할 수 있습니다.

둘째, 시멘틱 레이어(Semantic Layer)입니다. 카탈로그가 "이 테이블에 이런 컬럼이 있다"를 알려준다면, 시멘틱 레이어는 그 데이터가 비즈니스적으로 무엇을 의미하고 서로 어떤 관계를 갖는지를 표현합니다. 앞의 loan_status = 3이 '연체'를 뜻한다는 조직의 약속도 여기에 해당합니다.

문제는 이것을 어떻게 채우느냐입니다. 수많은 컬럼에 사람이 일일이 설명을 작성하고 최신 상태로 유지하는 방식은 지속 가능하지 않다고 보고 있습니다. 그래서 컬럼마다 독립적으로 설명을 붙이는 데 그치지 않고, User나 Loan 같은 비즈니스 개념과 실제 테이블·컬럼을 연결하는 구조를 검토하고 있습니다. 예를 들어 Loan이라는 개념을 정의하고, 어떤 테이블과 컬럼이 Loan의 상태나 속성을 나타내는지, Loan이 User와 어떤 관계를 갖는지를 연결해두는 방식입니다. 또한 데이터 소유자의 설명, dbt 문서, 서버 코드, 사내 커뮤니케이션 등 여러 곳에 흩어진 맥락을 활용하되, 출처에 따라 신뢰도를 다르게 다루는 방식도 함께 고민하고 있습니다.

시멘틱 레이어는 현재 제한된 도메인에서 PoC를 진행하며 방향을 구체화하고 있습니다. 그리고 더 어려운 것은, 의미를 만들어내는 일보다 그 의미를 검증 가능한 상태로 유지하는 일입니다. 잘못된 의미를 제공하는 순간, 시멘틱 레이어 자체가 오히려 데이터에 대한 신뢰를 떨어뜨릴 수도 있습니다. 그래서 저희는 처음부터 전체 데이터 플랫폼을 자동으로 문서화하려 하기보다, 제한된 도메인에서 데이터 소유자의 설명, dbt 문서, 서버 코드 같은 서로 다른 소스가 실제로 얼마나 일관되고 신뢰할 만한 의미를 제공하는지부터 비교해보려 하고 있습니다.

하지만 데이터를 정확하게 이해할 수 있게 되었다고 해서, 모든 데이터를 보여줄 수 있는 것은 아닙니다. 다음으로는 어디까지 접근하게 할 것인가라는 문제가 남습니다.

2. AI는 어디까지 접근할 수 있어야 하는가? — Governance

사람이 데이터를 사용할 때는 탐색과 조회, 판단의 속도가 사람에게 묶여 있었습니다. 반면 AI Agent는 짧은 시간에 여러 데이터셋을 탐색하고, 반복적으로 쿼리를 실행하며, 그 결과를 다음 행동의 입력으로 사용합니다. 이 차이는 기존의 접근 통제가 중요하지 않았다는 뜻이 아니라, 같은 권한이라도 AI를 통해 사용될 때 그 영향 범위와 속도가 달라질 수 있다는 뜻입니다.

접근의 경계가 명확하게 정의되고 강제되지 않는다면, AI가 활용될수록 민감한 데이터가 의도치 않게 드러날 가능성도 함께 커집니다. 그래서 저희는 "AI에게 데이터를 어떻게 더 많이 보여줄까"보다 "어디까지 보여줘도 되는가"를 먼저 정의해야 한다고 보았습니다. 접근을 여는 것보다 경계를 세우는 일이 먼저입니다.

이 경계를 세우기 위해 두 가지를 함께 다루고 있습니다.

하나는, 무엇이 민감한 데이터인지 식별하는 일입니다. 현재 컬럼 단위로 데이터의 성격을 자동으로 탐지하는 시스템을 운영하고 있습니다. 먼저 컬럼명의 단서와 실제 값의 패턴을 규칙 기반으로 분석해 민감정보 후보를 찾고, 오픈소스 PII 탐지 프레임워크인 Microsoft Presidio를 이용해 실제 값에서 이메일·전화번호·식별번호 등 PII에 해당할 수 있는 정보를 추가로 탐지합니다. 여기에 학습된 분류 모델을 적용해 컬럼 단위의 판정을 보강합니다. 이렇게 여러 단계의 탐지 결과를 종합해 민감정보로 의심되는 컬럼을 식별하고, 민감도에 따라 태그를 부여합니다. 이 태그는 Lake Formation과 동기화되어 실제 접근 제어에도 사용됩니다. 어떤 데이터를 보호해야 하는지 알아야 경계를 그을 수 있기 때문입니다.

다른 하나는, 이렇게 식별한 경계를 실제 접근 권한으로 강제하는 일입니다. AWS Lake Formation을 기반으로, 태그에 따라 접근을 제어하는 방식(Tag-Based Access Control)을 적용하고 있습니다. 여기서 적용하는 원칙의 핵심은 권한의 기본값을 '차단'에 두는 것입니다. 명시적으로 허용된 경우가 아니면 접근할 수 없고, 특히 보호가 필요한 민감 데이터는 기본적으로 열리지 않습니다. 사용자 인증은 사내 계정 체계와 연결하고, 인증된 사용자의 identity를 기준으로 Lake Formation 권한을 적용해 누가 어떤 데이터에 접근할 수 있는지를 사용자 단위로 관리합니다. 현재 핵심 데이터베이스를 중심으로 적용하고 있으며, 대상 범위를 점차 확대하고 있습니다.

그리고 한 가지 중요한 구분이 있습니다. 사람의 데이터 접근 권한을 정의하는 것과, 그 권한을 Agent에게 위임하는 것은 같은 문제가 아닙니다. 어떤 사용자가 특정 데이터를 조회할 권한을 가지고 있다고 해서, 그 사용자를 대신하는 Agent에게 동일한 범위의 권한을 무조건 위임해야 하는 것은 아니기 때문입니다. 그렇다면 AI는 이 경계 안에서 실제로 어떻게 데이터에 접근해야 할까요.

3. AI는 허용된 경계 안에서 어떻게 데이터에 접근할 것인가? — Interface

AI가 데이터에 접근하도록 구현하는 쉬운 방법 중 하나는 데이터베이스나 쿼리 엔진에 직접 연결하는 것입니다. 실제로 사내에는 이미 여러 도구와 봇이 각자의 방식으로 데이터에 접근하고 있습니다. 문제는 이런 접근이 늘어날수록, 누가 무엇을 조회했는지를 일관된 방식으로 추적하기 어려워지고 접근 방식마다 통제 수준도 달라진다는 점입니다.

저희는 AI가 데이터 플랫폼을 사용하는 방식을 하나의 공통된 인터페이스로 모으는 방향을 잡았습니다. AI마다, 도구마다 접근 방식을 따로 만드는 대신, Data Platform MCP를 통해 데이터를 탐색하는 일부터 실제 데이터를 조회하는 일까지 일관된 방식으로 제공하는 것입니다. 다만 무엇이 있는지 찾는 일과 실제 데이터를 조회하는 일은 필요한 통제 수준이 다르기 때문에, 같은 인터페이스 안에서도 두 기능은 명확하게 구분하려고 합니다.

먼저, 디스커버리입니다. 어떤 테이블이 있고, 특정 컬럼이 어디에 있으며, 데이터가 얼마나 신선한지를 찾는 일입니다. 여기에는 실제 데이터가 오가지 않고 스키마와 메타데이터만 다뤄지므로, 실제 데이터 조회와 비교하면 필요한 통제 수준도 상대적으로 낮습니다. 앞서 이야기한 DLM의 카탈로그는 이미 이런 조회를 프로그램적으로 제공하고 있고, 이 기능을 여러 AI Agent가 공통된 방식으로 사용할 수 있도록 Data Platform MCP를 통해 제공하는 작업을 하고 있습니다. 사용자가 자신이 쓰는 AI 도구에서 "대출 실행과 관련된 테이블을 찾아줘"라고 물으면, Agent는 MCP를 통해 데이터 카탈로그를 탐색합니다. 사내 사용자가 어떤 AI 도구를 사용하더라도 같은 방식으로 데이터를 탐색할 수 있게 하는 것입니다.

다음은, 실제 데이터를 조회하는 일입니다. 디스커버리가 메타데이터를 탐색하는 일이라면, 이 단계에서는 실제 데이터에 대한 쿼리가 실행됩니다. 향후 이 기능 역시 Data Platform MCP를 통해 제공하는 것을 목표로 하고 있지만, 디스커버리와 동일하게 열 수는 없습니다. AI가 사용자를 대신해 쿼리를 실행할 때는 누구를 대신한 요청인지(identity), 어디까지 권한을 위임받았는지(scope), 그리고 무엇을 조회했는지(audit)가 함께 관리되어야 합니다. 사용자의 권한은 Agent가 가질 수 있는 권한의 상한선일 뿐, 실제 위임 범위와 같을 필요는 없습니다.

이를 위해 이 요청을 데이터베이스나 쿼리 엔진에 직접 전달하지 않고, Query Gateway를 거쳐 실행하는 구조를 설계하고 있습니다. Data Platform MCP가 Agent가 사용하는 공통 인터페이스라면, Query Gateway는 그 뒤에서 실제 데이터 조회와 권한 통제를 담당하는 실행 레이어입니다. Query Gateway는 사용자의 identity와 위임 범위를 확인하고, 앞서 정의한 Governance의 경계 안에서 쿼리를 실행하며, 조회 이력을 남기도록 설계하고 있습니다. 위임의 경계를 어떻게 강제할지가 여기서 풀어야 할 핵심 과제입니다.

이 두 단계에 공통으로 두는 원칙이 하나 있습니다. 모든 요청에서 누가 요청했는지가 식별 가능해야 하고, 무엇을 조회했는지는 기록으로 남아야 한다는 것입니다. 접근 경로를 공통화하면, 누가 어떤 AI 도구를 통해 무엇을 조회했는지를 일관된 방식으로 기록하고 통제하기 쉬워집니다. 접근을 편리하게 만드는 것만큼, 그 접근이 남긴 흔적을 볼 수 있어야 합니다.

세 가지 질문, 지금 어디까지 왔는가

여기까지가 AI라는 새로운 소비자를 두고 던진 세 가지 질문과, 그에 답해가는 방식입니다. 서두에서 말씀드렸듯 모든 것이 완성된 것은 아닙니다. 현재 상태를 정리하면 이렇습니다.

세 가지를 따로 놓고 보면 카탈로그, 접근 제어, MCP 같은 개별 기술의 문제처럼 보일 수 있습니다. 하지만 저희가 이 과정에서 만들고자 하는 것은 개별 기능의 집합이라기보다, AI와 데이터 사이에 놓이는 공통된 플랫폼 레이어에 가깝습니다.

AI Agent가 어떤 판단을 하고 어떤 순서로 도구를 사용할지를 모두 사전에 예측하거나 통제하기는 어렵습니다. 사용하는 모델과 도구도 계속 달라질 수 있습니다. 이런 상황에서 각각의 AI 애플리케이션마다 데이터의 의미와 권한, 접근 방식을 다시 정의하는 것은 지속 가능하지 않습니다. 저희는 오히려 데이터를 제공하는 플랫폼이 이 공통된 레이어를 책임져야 한다고 보고 있습니다.

Context는 AI가 데이터의 의미를 임의로 추론하지 않도록 필요한 맥락을 제공하고, Governance는 접근 가능한 범위를 정의하고 강제하며, Interface는 그 경계 안에서 데이터에 접근하는 공통된 통로를 제공합니다. AI의 모든 행동을 예측할 수는 없더라도, AI가 데이터와 만나는 지점의 가드레일은 플랫폼이 제공할 수 있어야 합니다.

저희가 생각하는 AI-Ready Data Platform은 결국 AI에게 더 많은 데이터를 여는 것이 아니라, AI가 데이터를 이해하고 안전하게 사용할 수 있는 조건을 데이터 플랫폼이 준비하는 일입니다.

이번 글에서는 AI-Ready Data Platform의 큰 그림에 초점을 맞췄지만, 각각의 영역에는 별도로 다뤄볼 만한 운영과 설계의 문제가 남아 있습니다. PII 탐지 결과를 Lake Formation의 접근 제어까지 연결하는 과정, 여러 AI 도구가 공통으로 사용할 Data Platform MCP, 그리고 실제 데이터 조회를 통제하기 위한 Query Gateway 역시 기회가 되면 후속 글에서 더 자세히 다뤄보겠습니다.

데이터 활용을 넘어, 플랫폼 운영으로

지금까지는 AI를 데이터를 사용하는 소비자로 놓고 이야기했습니다. 하지만 같은 문제는 플랫폼 운영에서도 나타납니다. AI가 플랫폼을 이해하고 운영에 참여하려면 시스템의 상태와 운영 지식이라는 Context, 허용할 행동의 경계를 정하는 Governance, 그리고 관찰과 작업을 위한 통제된 Interface가 필요합니다.

저희는 현재 이 방향으로 운영 신호와 팀의 지식을 AI가 활용할 수 있게 연결하고, 제한된 작업을 수행하는 사내 AI Agent를 실제 환경에서 활용하고 있습니다.

데이터를 사용하는 것과 마찬가지로, 운영에서도 중요한 것은 AI에게 더 많은 시스템을 여는 것이 아니라 어떤 맥락을 제공하고 어디까지 행동을 허용할지를 플랫폼 차원에서 설계하는 일입니다.

이 이야기는 다음 글에서 이어가겠습니다.