AI 에이전트용 데이터 준비, 무엇이 달라야 하나

출처: martinfowler.com (Pramod Sadalage, Prem Chandrasekaran / Thoughtworks)
원문: https://martinfowler.com/articles/making-data-ready-for-agentic-ai.html
작성자: 팔복소프트-김팔복

한눈에 보기

• Thoughtworks의 데이터 아키텍트 두 사람이 2026년 8월 27일 martinfowler.com에 "에이전트가 쓸 데이터는 사람이 쓰던 데이터와 달라야 한다"는 장문의 글을 올렸다.
• 핵심 논지는 하나다. 사람은 이상한 숫자를 보면 멈추지만, 에이전트는 그대로 실행한다.
• 그래서 사람이 머릿속에서 하던 일(검증, 맥락 해석, 판단 근거 기억, 권한 절제)을 전부 데이터 쪽으로 옮겨야 한다고 주장한다.
• 이를 위해 데이터 계약(Data Contract), 관측성(Observability), 컨텍스트 계층(Context Layer), 접근 계층(Access Layer)의 네 가지를 아래에서 위로 쌓으라고 제안한다.
• 에이전트 프레임워크나 프로토콜보다 데이터 기반이 먼저라는 것이 글 전체의 결론이다.
• 팔복소프트 관점: 국내 대부분의 팀은 "RAG까지 해봤는데 다음이 안 보이는" 단계에 있고, 이 글은 그 다음 단계의 지도로 쓸 만하다. 다만 제시된 도구 스택이 국내 현실과 거리가 있는 부분도 있다.

배경

지난 몇 년간 기업 데이터 아키텍처의 소비자는 대시보드를 보는 사람, SQL을 짜는 분석가였다. 데이터가 조금 틀려도 사람이 "어, 이 숫자 이상한데?" 하고 되묻는 것으로 시스템이 버텼다. 그런데 LLM 기반 에이전트가 데이터를 읽고, 판단하고, 티켓을 만들거나 환불을 실행하는 주체가 되면 그 완충 장치가 사라진다. 국내에서도 RAG 챗봇을 넘어 "실제로 뭔가를 하는" 에이전트 PoC가 늘고 있는데, 정작 그 에이전트가 참조하는 데이터가 준비됐는지는 잘 묻지 않는다. 이 글은 바로 그 질문을 다룬다.

주요 내용

에이전트 시대의 "AI-ready"는 다섯 가지 속성이다

원문은 사람이 공짜로 해주던 일을 데이터의 속성 다섯 개로 바꿔 정의한다. 표로 정리하면 다음과 같다.

저자들이 강조하는 점은 이 다섯 개가 독립적이지 않다는 것이다. 신뢰할 수 없는 데이터 위에 의미 계층을 얹어봐야 소용없고, 의미 없는 데이터를 에이전트가 조작하게 두면 더 위험하다. 그래서 계약 → 컨텍스트 → 접근의 순서로 쌓고, 관측성은 처음부터 끝까지 옆에서 같이 가야 한다고 말한다.

1층: 데이터 계약과 격리

원문이 드는 사례는 단순하다. 가격이 어제 바뀌었는데 에이전트가 보는 테이블은 갱신되지 않았고, 에이전트는 옛 가격을 자신 있게 고객에게 안내한다. 워크플로우는 완벽하게 돌았고 데이터만 틀렸다.

이를 막는 장치가 데이터 계약이다. 스키마 타입, 값의 범위(가격 > 0 등), 그리고 신선도 SLA(예: 24시간 이내 적재)를 YAML로 선언하고 CI/CD에서 검증한다. 원문은 Open Data Contract Standard와 Data Contract CLI를 예로 든다. 계약을 위반한 데이터는 에이전트가 접근하는 저장소로 들어가지 못하고 별도 큐로 격리된다. 결과적으로 에이전트는 틀린 가격을 말하는 대신 "현재 가격 정보가 없다"고 답하게 된다. 저자들은 이 실패 방식이 훨씬 낫고, 이건 모델이 아니라 아키텍처가 해야 할 일이라고 못 박는다.

계층 구조로는 Databricks가 퍼뜨린 메달리온 아키텍처(Bronze/Silver/Gold)를 가져오되, 에이전트는 검증이 끝난 Gold 이상만 보게 하라고 한다. 흥미로운 제안은 그 위에 "Adaptive Gold"라는 4번째 층을 두어, 에이전트가 자주 조회하는 조합을 스스로 뷰로 만들게 하자는 것인데, 저자들도 아직 초기 단계라고 인정한다.

비정형 데이터에도 같은 원칙이 적용된다. 문서는 바뀌었는데 벡터 인덱스가 재구축되지 않은 상황은 가격 사례와 똑같은 실패다. 여기서 신선도 SLA의 기준은 "문서가 바뀐 시점"이 아니라 "인덱싱 잡이 마지막으로 성공한 시점"이어야 한다는 지적이 실용적이다. 조용히 죽은 파이프라인을 잡아내는 건 그 기준뿐이기 때문이다.

2층: 왜 그랬는지를 남기는 관측성

기존 로그는 "무엇을" 했는지만 남긴다. 에이전트는 "왜" 그랬는지까지 남겨야 한다. 원문은 분산 추적의 trace/span 모델을 그대로 빌려와, 각 단계(고객 확인 → 제재 목록 조회 → 신용 조건 평가 → 승인)를 span으로 기록하고 최종 span에 판단 근거를 붙이는 방식을 제안한다. 도구로는 OpenTelemetry, Langfuse, Arize Phoenix를 언급한다.

규제 근거로는 EU AI Act 12조와 19조를 든다. 고위험 시스템은 자동 로그를 남기고 최소 6개월 보관해야 하며, 위반 시 최대 1,500만 유로 또는 글로벌 매출의 3%까지 벌금이 가능하다. 다만 저자들은 규제와 무관하게, 설명할 수 없는 시스템은 디버깅도 신뢰도 못 한다는 점을 더 강조한다.

자율성은 단계적으로 부여한다. 추천만 하는 Shadow → 승인 후 실행하는 Supervised → 가드레일 내 자율 → 완전 자율 순이다. 권한은 공용 서비스 계정이 아니라 요청한 사용자의 권한을 위임받고, 작업 단위로 몇 분짜리 단기 토큰을 발급하라고 한다. Simon Willison이 말한 "치명적 삼중 조합"(비공개 데이터 접근 + 신뢰할 수 없는 입력 + 외부 통신)을 끊는 실질적 수단이기도 하다.

3층: 컨텍스트 계층 — "매출"의 뜻을 가르치기

원문에서 가장 분량이 많은 부분이다. 저자들은 흔히 "시맨틱 레이어"로 뭉뚱그리는 것을 세 개로 쪼갠다.

셋 다 Git에 코드로 두고 리뷰와 CI를 거친다. 에이전트는 원시 테이블을 직접 만지지 않고 반드시 이 계층을 통해 질의한다. 근거로 제시된 AtScale 벤치마크에서는 같은 모델로 텍스트-SQL 정확도가 원시 스키마 기준 20% 미만에서 시맨틱 레이어 적용 후 92.5% 이상으로 올라갔다. 저자들의 표현을 빌리면 시맨틱 모델은 에이전트를 똑똑하게 만드는 게 아니라 추측을 못 하게 막는다.

Palantir Foundry Ontology나 Databricks Genie Ontology 같은 제품과의 차이도 짚는다. 이들은 행동까지 온톨로지에 묶는 반면, 저자들은 쓰기 경로의 리스크가 다르므로 역량 모델을 분리해서 따로 거버넌스하자는 입장이다.

4층: 검색에서 실행으로

대부분의 조직은 RAG, 즉 "읽기"에 머물러 있다. 원문은 Microsoft의 프레임워크를 빌려 접근을 세 단계(검색 → 실시간 조회 → 쓰기)로 나누고, MCP의 Resources/Prompts/Tools가 이 위험도 순서와 맞아떨어진다고 설명한다.

여기서 나오는 안티패턴이 실무자에게 가장 와닿을 것이다. 기존 REST 엔드포인트를 하나씩 MCP 도구로 감싸면 50개짜리 도구 목록이 생기고, LLM은 비슷한 이름 사이에서 헤맨다. Thoughtworks Tech Radar가 이 방식을 HOLD로 분류했다. 대신 5~10개의 잘 설명된 업무 역량으로 묶으라는 것이다. 그리고 각 역량에는 권한, 담당자, 사전조건, 되돌림 가능성 등급을 선언한다. 저자들은 자율 실행의 허용 기준을 거래 금액이 아니라 되돌릴 수 있는가로 잡으라고 조언한다. 되돌릴 수 있는 5만 달러 장부 수정이 되돌릴 수 없는 200달러 외부 송금보다 안전하다.

또 하나 중요한 원칙은 "검색된 텍스트는 참고 자료일 뿐 권한을 부여하지 않는다"이다. 환불 정책 문서를 실행 시점에 LLM이 읽고 해석해서 허용 여부를 결정하게 두면, 오염된 문서 하나가 권한을 만들어낼 수 있다. 규칙은 미리 사람이 추출·검토해서 사전조건으로 선언해두고, 실행 시에는 그 선언만 결정적으로 검사한다.

팔복소프트 관점

• 국내 팀 대부분에게 이 글은 "다음 단계 지도"로 유용하다. 사내 문서 RAG 챗봇을 만들어본 회사는 많지만, 에이전트가 ERP에 티켓을 만들거나 정산 데이터를 고치는 단계까지 간 곳은 드물다. 그 사이에 뭘 채워야 하는지가 이 글의 목차 그대로다. 특히 "쓰기 전에 읽기, 읽기 전에 계약"이라는 순서는 PoC가 데모 이후 멈추는 팀이 왜 멈췄는지 설명해준다.
• 도구 스택은 국내 현실과 온도차가 있다. 원문의 예시는 dbt, Snowflake, Databricks, Langfuse 중심이다. Airflow + 자체 DW + 사내 BI 조합으로 운영하는 국내 팀에게는 그대로 옮기기 어렵다. 다만 저자들도 도구보다 규율이 중요하다고 반복하는데, 이 말은 사실이다. 지표 정의를 Git에 두고 리뷰하는 것, 신선도 SLA를 적재 시각 기준으로 잡는 것, 에이전트가 원시 테이블을 못 보게 하는 것은 어떤 스택에서도 할 수 있다.
• 당장 도입할 것 하나만 고르라면 관측성이다. 데이터 계약이나 시맨틱 레이어는 조직 합의가 필요해서 느리다. 반면 에이전트 워크플로우에 OpenTelemetry 기반 추적을 붙이는 건 팀 단위로 바로 가능하고, 나중에 붙이기가 훨씬 어렵다는 저자들의 지적에 동의한다. 규제 대응이 아니라 디버깅 도구로 먼저 쓰게 된다.
• 금융·공공 쪽은 위임 접근 부분을 눈여겨봐야 한다. 국내 금융권은 망분리와 접근 통제가 엄격해서, "에이전트가 사용자 권한을 위임받아 단기 토큰으로 동작한다"는 모델은 기존 보안 심사 체계와 오히려 잘 맞는다. 반대로 공용 서비스 계정 하나로 에이전트를 돌리는 구성은 심사를 통과하기 어려울 것이다.
• 규제 압박은 EU가 앞서 있다. 국내는 AI 기본법이 시행됐지만 로그 보관 기간 같은 세부 요건은 EU AI Act만큼 구체적이지 않다. 그래도 저자들의 논리대로, 고객이 "왜 내 요청이 거절됐냐"고 물었을 때 답할 수 없는 시스템은 규제와 상관없이 운영이 안 된다.
• 아쉬운 점. 가격 사례 하나를 반복해서 쓰다 보니 정형 데이터 중심으로 읽힌다. 국내 실무에서 에이전트가 주로 다루는 건 상담 기록, 계약서, 사내 위키 같은 비정형 데이터인데, 그 부분의 품질 게이트(중복 문서, OCR 오류, 임베딩 드리프트)는 상대적으로 짧게 다뤄졌다. 또 "Adaptive Gold"는 저자들 스스로 초기 아이디어라고 인정하는 만큼 검토 대상에서 빼도 된다.

정리

기억할 것은 순서다. 에이전트 프레임워크를 고르기 전에 데이터가 검증됐는지, 지표 정의가 코드로 존재하는지, 판단 과정이 기록되는지를 먼저 확인해야 한다. 이 글이 제시한 다섯 속성 표에서 가장 약한 행을 찾으면 그게 다음 투자처다. 평균을 내지 말라는 저자들의 조언처럼, 신뢰 계층이 무너져 있으면 그 위의 컨텍스트 계층이 아무리 잘 만들어져 있어도 에이전트 준비는 안 된 것이다.

• Agentic AI
• 데이터 아키텍처
• Data Contract
• MCP
• Semantic Layer