에이전트가 쓰는 데이터는 달라야 한다 — 품질 계약·문맥·실행 권한의 설계

TL;DR

• 사람이 해오던 데이터의 이상 징후 확인과 업무 문맥 보충을 에이전트의 추측에 맡겨서는 안 된다. 저자들은 신뢰성·문맥·추적 가능성·거버넌스·실행 가능성을 갖춘 데이터를 요구한다. 모델을 바꾸기 전에 데이터가 잘못된 행동을 유도하지 않는지 확인하는 접근이다.
• 데이터 계약은 스키마뿐 아니라 품질과 신선도를 다룬다. 위반한 데이터는 에이전트가 읽기 전에 격리하고 불확실한 경우에는 사람에게 넘긴다. 모델이 자신 있게 답한다는 사실은 오래된 데이터의 결함을 상쇄하지 못한다.
• 문맥 계층은 업무 개념, 지표 계산, 허용된 행동을 나눈다. 같은 매출 정의와 같은 고객 개념을 코드로 관리하고 행동에는 권한·실행 전 조건·가역성을 붙인다. MCP는 그 정의를 전달하는 인터페이스이며 안전성 자체를 대신하지 않는다.
• 검색된 문서는 행동을 제안하는 근거가 될 수 있지만 권한을 부여하지는 못한다. 실행 허용 여부는 사람이 검토한 명시적 규칙을 현재 상태와 대조해 결정한다. 규칙이 다루지 않는 상황에서 에이전트가 정책을 즉석 해석해 권한을 넓혀서는 안 된다.
• 자율성은 단계적으로 늘려도 관측과 감사 기록은 처음부터 필요하다. 데이터 기반 위에 문맥과 접근 계층을 쌓고 모든 계층에 책임자를 둔다. 준비 수준은 점수의 평균보다 가장 약한 기반이 제한한다.

오래된 가격을 정확하게 읽어도 결과는 틀릴 수 있다

상품 가격이 바뀌었는데 에이전트가 읽는 데이터는 갱신되지 않았다면, 에이전트는 요청된 조회 절차를 그대로 따르고도 잘못된 가격을 안내할 수 있다. Pramod Sadalage와 Prem Chandrasekaran은 이런 상황을 출발점으로 삼는다. 사람은 최근 가격 변경을 기억하거나 이상한 값을 의심해 동료에게 확인할 수 있지만 시스템 설계가 그런 보완을 에이전트의 판단에 기대서는 안 된다는 주장이다. 오류가 있는 데이터를 빠르게 처리하는 능력은 업무의 신뢰성을 높이지 못한다.[4]

글이 요구하는 속성은 신뢰할 수 있는 데이터, 명시적인 문맥, 추적 가능성, 통제된 접근, 실제 업무를 수행할 수 있는 연결이다. 이를 구현하는 논의는 데이터 계약과 품질, 추적과 거버넌스, 문맥 계층, 읽기에서 쓰기로 이어지는 접근 방식으로 나뉜다. 시스템의 의존 관계는 데이터 기반 위에 문맥을 두고 그 위에 접근을 얹는 구조다. 관측 가능성은 마지막에 추가하는 층이 아니라 이 모든 층에서 처음부터 작동해야 한다.[4]

데이터 계약을 위반하면 에이전트 앞에서 멈춘다

데이터 계약은 필드의 타입과 필수 여부를 정하는 데서 끝나지 않는다. 가격이 양수인지, 통화 코드가 허용된 값인지, 필요한 시간 안에 데이터를 성공적으로 불러왔는지까지 검사한다. 신선도의 기준은 값이 마지막으로 바뀐 시각과 구별해야 한다. 값이 그대로인 정상 데이터와 갱신 파이프라인이 멈춘 데이터를 구분하려면 마지막 수집 성공 시각을 확인해야 하며 같은 데이터라도 실시간 가격 안내와 배치 보고서의 허용 지연은 다를 수 있다.[4]

계약 검사를 통과한 데이터만 에이전트가 접근하는 저장소로 보내고 실패한 데이터는 별도 격리 큐와 사람의 검토로 넘긴다. 원문의 medallion 구조에서는 원본 Bronze와 검증 중인 Silver를 거쳐 인증된 Gold부터 에이전트에 노출한다. 사용 패턴을 보고 데이터 조합을 정리하는 Adaptive Gold는 그 위에 검토할 확장 구상이다. 이런 단계가 모든 의미상의 오류를 자동으로 없애지는 않지만 명백한 품질 위반을 모델이 알아서 눈치채기를 기다리는 구조에서는 벗어나게 한다.[4]

문서와 벡터 인덱스도 같은 원칙을 따른다. 정책 문서가 바뀌었는데 검색 인덱스가 갱신되지 않으면 에이전트는 예전 규칙을 정확하게 인용하면서 틀린 답을 할 수 있다. 각 문서 조각에 출처와 버전, 시각, 접근 범위를 붙이고 빈 조각·잘린 문장·추출 오류·중복을 검사해야 한다. 여러 품질 신호를 하나의 신뢰 점수로 합치는 방법은 아직 열린 설계 문제이므로, 저자들은 우선 계약이나 신선도 위반 하나만 있어도 사람에게 넘기는 강제 차단 규칙부터 시작하라고 권한다.[4]

문맥은 업무의 개념·숫자·행동을 따로 정의한다

매출을 묻는 질문에는 총매출인지 순매출인지, 할인과 반품을 어떻게 반영하는지, 회계 분기가 언제 시작하는지가 숨어 있다. 글의 domain model은 고객과 주문 같은 개체와 관계, 업무 어휘를 정의하고 semantic model은 지표·차원·계산식을 정의한다. capability model은 그 개체에 대해 허용할 조회와 행동을 정한다. 하나는 무엇이 존재하는지, 하나는 숫자를 어떻게 계산하는지, 나머지는 무엇을 해도 되는지를 담당한다.[4]

이 정의들은 버전 관리와 코드 검토, 테스트를 거쳐 공유한다. 정량 질문은 승인된 지표와 조인 경로를 이용해 제한된 SQL로 바꾸고 결과에는 어떤 정의와 데이터에서 나왔는지 추적할 정보를 붙인다. 모든 업무를 한 번에 포괄하는 거대한 모델을 만들기보다 첫 에이전트가 쓰는 논쟁적인 지표부터 합의하는 편이 낫다. 지식 그래프는 관계를 여러 단계로 탐색해야 할 때 domain model을 표현하는 선택지로 설명된다. 별도의 필수 계층은 아니다.[4]

자율성을 늘리기 전에 누가 무엇을 했는지 남긴다

조회한 테이블과 시각만 남긴 로그로는 왜 거래가 승인됐는지 충분히 설명하기 어렵다. 에이전트의 전체 작업을 하나의 trace로 묶고 각 조회·정책 검사·도구 실행을 span으로 남기면 사용한 출처와 판단 조건을 연결할 수 있다. 승인이나 거절, 사람이 개입한 내용도 같은 흐름 안에서 추적할 수 있어야 한다. 글은 이런 기록을 규제 대응뿐 아니라 잘못된 결정을 디버깅하고 접근 범위를 확대할 근거로 본다.[4]

자율성은 추천만 하는 shadow mode에서 사람의 승인 후 실행, 명시된 경계 안의 자동 실행으로 늘린다. 단계가 높아져도 관측을 줄이는 것은 아니다. 실제 사용자 대신 넓은 공용 서비스 계정을 쓰기보다 요청자의 권한을 위임받고 작업에 필요한 범위와 수명을 가진 자격증명을 사용한다. 여기에 최소 권한을 적용하면 탈취되거나 잘못 유도된 에이전트가 접근할 수 있는 범위를 줄일 수 있지만 프롬프트 인젝션 자체가 완전히 사라지는 것은 아니다.[4]

읽을 수 있는 것과 실행해도 되는 것을 구분한다

구매 주문 문제를 해결하려면 안내 문서를 찾는 일, 현재 결제 서비스 상태를 확인하는 일, 지원 티켓을 만드는 일이 필요할 수 있다. 전통적인 검색 중심 RAG는 첫 단계에 집중하며 실시간 조회와 쓰기는 별도의 능력이다. 저자들은 이를 MCP 같은 인터페이스로 연결하되 읽기·실시간 조회·상태 변경을 각각 통제하자고 제안한다. MCP Tool에도 상태 조회처럼 읽기 전용 작업이 있으므로, 프로토콜의 이름만으로 위험을 판정하지 않고 실제 동작과 부작용을 봐야 한다.[4]

기존 REST 엔드포인트를 그대로 모두 도구로 감싸면 비슷한 이름과 기능이 늘어 에이전트가 무엇을 선택할지 판단하기 어려워진다. 대신 서비스 이름과 위치를 입력받는 상태 조회처럼 업무 능력 단위로 묶고 설명과 파라미터, 스키마를 분명히 한다. 도구 수를 줄이는 자체가 목표는 아니며 어떤 상황에서 무엇을 호출할지 이해할 수 있는 설계가 중요하다. 원문이 제시한 소수의 풍부한 도구와 다수의 얇은 래퍼 비교는 이런 설계 원칙의 설명이지 모든 업무에서 성능이 보장되는 고정 개수 규칙은 아니다.[4]

쓰기 권한은 현재 상태와 되돌릴 수 있는지를 검사한다

각 capability에는 호출 권한과 책임자가 필요하고 상태를 바꾸는 행동에는 추가 조건이 붙는다. 환불이라면 원래 결제가 존재하는지, 이미 환불했는지, 호출자가 허용받은 금액 범위 안인지 실행 직전에 현재 상태로 검사한다. 계획을 세울 때 읽었던 정보만 믿으면 그 사이에 바뀐 상태를 놓칠 수 있다. 자율성의 경계도 금액만으로 정하기보다 쉽게 되돌릴 수 있는 행동인지, 보상 작업이 필요한지, 되돌릴 수 없는지를 구분하는 편이 낫다는 제안이다. 되돌릴 수 없는 행동은 자율성 단계와 무관하게 사람의 승인을 요구한다.[4]

업무 규칙이 문서에 있다고 해서 실행 순간에 모델이 그 문장을 해석해 권한을 만들어서는 안 된다. 규칙은 미리 추출하고 사람이 검토해 명시적인 실행 전 조건으로 관리하며 원문 구절에 대한 출처를 연결한다. 검색된 문서는 제안과 설명의 근거로 쓸 수 있지만 실제 허용 여부는 선언된 규칙을 현재 상태에 대조해 결정한다. 악성 문서가 제안을 오염시키거나 사람 승인자를 속일 위험은 남더라도, 문서 자체가 새 권한을 부여하는 경로는 차단하는 구조다.[4]

정의와 규칙을 유지할 책임자까지 설계한다

원문 정책이 바뀌었다고 알려주는 기능과, 그 변화가 어떤 실행 조건을 무효로 만드는지 판단하는 기능은 다르다. 출처 연결은 관련 규칙을 사람이 다시 검토할 대기열을 만드는 데 쓰며 의미상의 변경 판단을 단순 diff에 맡기지 않는다. 선언된 규칙이 다루지 않는 상황에서는 에이전트가 즉석 판단으로 범위를 넓히지 않고 사람에게 넘긴다. 추출과 검토, 변경 반영의 주기와 책임자까지 있어야 규칙이 실제 정책과 계속 맞아 있을 수 있다.[4]

데이터셋과 계약, 지표와 접근 범위에도 이름 있는 책임자와 버전·폐기 정책이 필요하다. 누가 소비하는지 모두 알 수 없는 공유 데이터일수록 계약이 안정적인 약속이 된다. 준비 수준을 진단할 때도 여러 항목을 평균내면 검증되지 않은 데이터 위의 정교한 문맥 계층을 과대평가할 수 있다. 먼저 관측을 갖추고 데이터 계약과 격리, 필요한 문맥 정의, 읽기에서 제한된 쓰기 순으로 쌓아가라는 것이 저자들의 실행 순서다.[4]

참고 자료

[4] https://martinfowler.com/articles/making-data-ready-for-agentic-ai.html — Making Your Data Ready for Agentic AI — Pramod Sadalage, Prem Chandrasekaran