Inventory, Contracts, Maintained Context: 에이전트를 늘리기 전에 갖출 목록·계약·맥락 관리
데이터 거버넌스 기업 Collibra의 CEO가 에이전트를 몇 개에서 수십 개로 늘릴 때 필요한 세 가지로 에이전트 목록, 실행 전에 결정론적 규칙으로 검사하는 계약, 모델과 독립된 맥락 계층의 지속 관리를 꼽았습니다(벤더 관점). 맥락을 붙인 분석 에이전트가 두 달 만에 정답률 90%에서 60%로 떨어진 사례를 근거로, 맥락도 데이터 파이프라인처럼 운영하라고 말합니다.
에이전트가 한두 개일 때는 사람이 결과를 확인하면 됩니다. 수십 개로 늘리려면 세 가지가 먼저 있어야 합니다. 무엇이 돌고 있는지 아는 목록, 실행 직전에 규칙으로 행동을 막는 계약, 그리고 모델과 따로 관리되면서 계속 갱신되는 비즈니스 맥락입니다. 실제로 쓰려면 맥락의 주인과 갱신 주기, 계약을 코드로 적을 사람을 정해야 합니다.
요약
데이터 거버넌스 소프트웨어 기업 Collibra의 창업자이자 CEO Felix Van de Maele가 VentureBeat AI Week(뉴욕)에서 VentureBeat CEO Matt Marshall과 대담했고, VentureBeat가 이를 기사로 정리했습니다(2026.10.20, VB Staff). 출발점은 확장의 벽입니다. 기업의 75% 넘게가 copilot 하나에서 자율 에이전트 10~15개로 넘어갈 때 운영 단계에서 막힌다는 것입니다. 에이전트가 늘수록 위험·비용·감독 부담이 함께 커집니다. 그는 세 가지 처방을 내놓습니다. 첫째, 에이전트 inventory(목록)를 만들고 운영에 올리기 전 통과해야 할 관문을 정합니다. 둘째, 회사의 데이터와 그 의미, 사용 규칙을 담은 ontology(온톨로지, 개념과 관계의 정의 체계)를 모델과 독립된 context layer(맥락 계층)로 두고 계속 관리합니다. 셋째, 거버넌스 규칙을 기계가 읽는 agent contract(에이전트 계약)로 바꾸고, guardian(감시 에이전트)이 실행 직전에 행동을 검사합니다.
이유는 두 가지입니다. 하나는 사람이 검증하는 방식이 규모를 따라가지 못한다는 점입니다. 출력을 확인하고 에이전트를 재인증하고 맥락을 고치는 일을 사람이 하면, 필요한 인력이 에이전트 수에 비례해 늘어납니다. 다른 하나는 에이전트가 틀리는 원인이 데이터 부족보다 맥락 부족에 가깝다는 점입니다. 엉뚱한 테이블을 조회하고 필드 뜻을 잘못 읽는 일이 여기서 생깁니다. 근거로 한 프런티어 모델 연구소의 사내 분석 에이전트를 듭니다. 맥락 없이 약 30%, 맥락을 붙인 뒤 약 90%를 맞혔지만, 두 달 뒤에는 60%로 떨어졌습니다. 그래서 맥락은 한 번 만들고 끝나는 문서가 아니라 데이터 파이프라인처럼 운영할 대상이라고 말합니다. 같은 모델을 누구나 쓸 수 있으니 차별화는 고유 지식을 에이전트에 효율적으로 공급하는 데서 나온다는 것이 결론입니다. 아래에서 메커니즘과 사례를 정리하고 실제로 돌리는 방법을 덧붙입니다. Collibra는 이 영역의 제품을 파는 회사이므로 주장은 벤더 관점으로 읽습니다.
핵심 메커니즘
Agent Inventory와 Deployment Lifecycle: 무엇이 돌고 있는지 알고, 관문을 빠르게
무엇인가. 회사 안에서 운영 중인 에이전트의 수와 하는 일을 파악한 목록, 그리고 에이전트가 운영에 올라가기 전 통과해야 할 요건의 묶음입니다. 어떻게 작동하나. 직원 실험으로 생긴 에이전트까지 포함해 목록을 만들고(입력), 에이전트마다 출시 요건을 확인한 뒤(처리), 통과한 것만 운영에 올립니다(출력). 원문이 강조하는 조건은 속도입니다. 관문을 지키는 쪽이 피해 가는 쪽보다 시간이 덜 들어야 팀이 우회하지 않습니다. 언제 쓰나. 에이전트가 부서마다 따로 생기기 시작할 때 가장 먼저 합니다. 한 팀이 에이전트 한두 개를 직접 관리하는 단계라면 가벼운 목록으로 충분합니다. 원문의 예. Collibra AI 서밋 청중 대부분이 자기 회사 운영 에이전트의 수와 역할을 답하지 못했습니다. Van de Maele는 이를 두고 “가진 줄도 모르는 것을 어떻게 통제하나”라고 반문했습니다. 원문은 세 번째 단계가 앞의 두 관문을 통과한 에이전트를 다룬다고만 밝히고 내용은 설명하지 않습니다. 작은 예시(가상). 재무팀이 만든 월마감 요약 에이전트가 목록에 없다면, ERP 권한 변경이 생겨도 영향을 받는 에이전트로 잡히지 않습니다.
Context Layer와 Ontology: 모델이 바뀌어도 남는 비즈니스 정의
무엇인가. 회사가 가진 데이터, 그 데이터가 비즈니스에서 뜻하는 바, 데이터를 쓰는 규칙과 절차를 담은 ontology를 특정 모델이나 플랫폼 밖에 두는 계층입니다. 어떻게 작동하나. 테이블·필드, 용어 정의, 사용 규칙을 한곳에 정리하고(입력), 에이전트가 질문을 받으면 이 계층에서 정의와 위치를 먼저 찾고(처리), 그 정의에 맞는 데이터로 답합니다(출력). 원문이 플랫폼 독립을 강조하는 이유는 수명입니다. 모델과 플랫폼은 바뀌지만 ontology는 비즈니스를 설명하므로 비즈니스가 바뀔 때만 바뀌고, 이전 작업을 거쳐도 살아남습니다. 원문은 비용 효과도 듭니다. 필요한 정의를 이미 가진 에이전트는 추론을 여러 번 되풀이하지 않아 토큰을 덜 씁니다. 언제 쓰나. 매출처럼 정답이 하나뿐인 질문을 에이전트에 맡길 때 필요합니다. 소비자용 챗봇은 여러 답이 다 괜찮을 수 있지만, 기업의 매출 숫자에는 맞는 답이 하나입니다. 원문의 예. 10년 동안 데이터 플랫폼에 투자한 기업도 에이전트가 틀린 테이블을 조회하고 필드를 잘못 읽고 품질 낮은 레코드를 씁니다. Van de Maele는 이를 데이터 문제가 아니라 맥락 문제로 봅니다. 작은 예시(가상). 『순매출』의 정의(반품 차감, 부가세 제외)와 기준 테이블을 context layer에 두면, Copilot에서 묻든 사내 에이전트에서 묻든 같은 숫자가 나옵니다.
Context Drift: 맥락도 데이터 파이프라인처럼 운영
무엇인가. 배포 때 붙인 맥락이 시간이 지나며 실제 비즈니스와 어긋나 에이전트 정확도가 떨어지는 현상입니다. 어떻게 작동하나. 테이블 구조, 지표 정의, 조직, 규정이 바뀌는데(입력) 맥락이 그대로면(처리) 에이전트는 낡은 정의로 답합니다(출력). 원문은 기업이 이미 데이터 파이프라인에 들이는 유지보수를 맥락에도 똑같이 들여야 한다고 말합니다. 여기에 분절 문제가 겹칩니다. 맥락이 Anthropic의 Cowork, ChatGPT, Microsoft Copilot, 자체 agent harness(에이전트 실행 틀), 데이터 플랫폼에 동시에 흩어지면 시스템이나 사업부마다 같은 용어를 다르게 정의하게 됩니다. Van de Maele는 기업이 지난 20년 동안 데이터의 분절·사일로·품질 문제를 풀었듯, 앞으로 10년은 맥락의 같은 문제를 풀게 될 것으로 봅니다. 원문의 예. 한 프런티어 모델 연구소의 사내 분석 에이전트가 맥락을 붙여 약 90%까지 올랐다가 두 달 만에 60%로 내려갔습니다(연구소 이름은 원문에 없음).
Agent Contract: 거버넌스 규칙을 기계가 읽는 계약으로
무엇인가. 회사에 이미 있는 거버넌스 맥락을 런타임(실행 시점)에 읽고 집행할 수 있는 규칙으로 바꾼 것입니다. 어떻게 작동하나. 기존 정책과 데이터 사용 규칙을 모으고(입력), 기계가 읽는 규칙으로 옮겨(처리), 에이전트 전체에 같은 방식으로 적용합니다(출력). 원문은 두 층을 둡니다. global contract(공통 계약)는 모든 에이전트가 지킬 경계를 정하고, specialized contract(특화 계약)는 그 요건을 에이전트 유형에 맞게 조정합니다. 새 유형의 에이전트가 생기면 특화 계약을 더하는 방식으로 거버넌스가 함께 넓어집니다. 언제 쓰나. 에이전트가 여러 유형으로 늘어 같은 규칙을 에이전트마다 따로 프롬프트에 적기 어려워질 때입니다. 원문은 규칙을 누가 쓰는지, 규칙의 종류가 무엇인지는 밝히지 않습니다.
Guardian: 실행 전에 결정론적 규칙으로 행동을 막는 감시 에이전트
무엇인가. 에이전트가 하려는 행동을 실행 직전에 계약과 대조해, 계약이 금지한 행동을 막는 장치입니다. 어떻게 작동하나. 에이전트의 의도된 행동을 받아(입력), 계약의 규칙을 결정론적으로 평가하고(처리), 금지된 행동은 차단합니다(출력). 같은 행동에는 언제나 같은 판정이 나옵니다. 언제 쓰고 언제 안 쓰나. 원문은 판정에 LLM을 쓰지 않는 이유를 셋으로 듭니다. 행동마다 지연이 붙고, 비용이 붙고, 감시 대상 에이전트와 같은 불안정성을 지닌다는 것입니다. 그래서 규칙으로 쓸 수 있는 금지 사항은 규칙으로 막습니다. 원문은 이 장치 하나로 모든 빈틈이 닫히지는 않으며, Collibra를 포함한 업계가 실패 관리를 아직 연구 중이라고 덧붙입니다. 작은 예시(가상). 고객 응대 에이전트가 응답에 주민등록번호 필드를 담으려 하면 guardian이 실행 전에 막고, 차단 사유를 로그에 남깁니다.
통념과 다른 주장
흔히 이렇게 봅니다에이전트가 틀리는 것은 데이터가 모자라거나 모델이 약해서다. 데이터를 더 모으고 모델을 바꾸면 나아진다.
저자는 이렇게 봅니다데이터와 접근 권한이 충분해도 에이전트는 틀린다. 문제는 데이터가 무엇을 뜻하고 어떻게 써야 하는지에 관한 맥락이다.
근거분석 에이전트 정답률이 맥락 없이 약 30%, 맥락을 붙이면 약 90%였습니다. Collibra 조사에서는 응답자 90%가 정렬된 데이터 기반이 없는 것을 신뢰할 수 없는 결과의 원인으로 꼽았습니다.
흔히 이렇게 봅니다LLM이 만든 결과는 다른 LLM에게 검사시키면 된다. 판정 모델을 하나 더 붙이는 것이 가장 빠른 guardrail이다.
저자는 이렇게 봅니다실행 전 검사는 결정론적 규칙으로 해야 한다. LLM 판정은 감시 대상과 같은 불안정성을 지닌다.
근거LLM 판정은 모든 행동에 지연과 비용을 더합니다. Collibra의 guardian은 같은 행동에 늘 같은 판정을 내도록 규칙을 평가합니다.
저자가 든 사례
프런티어 모델 연구소의 사내 분석 에이전트
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 사내 분석 질문에 답하는 에이전트, 맥락 없이 정답률 약 30% | 비즈니스 맥락을 붙임 | 약 90%로 상승, 두 달 뒤 60%로 하락. 하락 원인의 세부는 원문에서 밝히지 않음 | Context Layer, Context Drift |
Collibra AI 서밋 청중
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 에이전트를 운영 중인 기업의 참석자들 | 운영 에이전트의 수와 역할을 물음 | 대부분 답하지 못함 | Agent Inventory |
조사로 본 확장의 벽
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 에이전트를 늘리려는 기업들 | VentureBeat 6월 조사(기술 리더 157명), Collibra 의뢰 Harris Poll, Collibra 조사 | 자동 eval만으로 운영 변경 허용 34%, eval 완전 신뢰 5%, 권한 밖 데이터 접근 적발 약 30%, 정렬된 데이터 기반 부재를 원인으로 꼽음 90%. 확장 단계에서 막히는 기업 75% 초과(출처는 원문에 없음) | Inventory, Agent Contract, Context Layer |
기술 디테일: 목록·맥락·계약을 실제로 돌리려면
아래는 원문의 세 요건을 실제 시스템으로 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드명·수치·도구는 가상 예시입니다.
Agent Inventory를 만들려면 에이전트 하나를 레코드 하나로 적고, 출시 관문의 통과 여부를 같은 레코드에 남깁니다. 목록은 수작업 설문보다 수집으로 채우는 편이 정확합니다. 사내 LLM 게이트웨이의 API 키별 호출 로그, Copilot·ChatGPT 관리 콘솔의 커스텀 에이전트 목록, MCP 서버 연결 기록을 주 1회 긁어 레코드와 대조하고, 목록에 없는 호출 주체를 미등록 에이전트로 표시합니다. 관문은 다섯 항목이면 충분합니다. 담당자 지정, 데이터 범위 명시, 연결된 계약, 골든 질문 평가 통과, 차단 로그 확인입니다. 통과에 2영업일을 넘기지 않게 자동 점검으로 돌리면 팀이 우회할 이유가 줄어듭니다.
{
"agent_id": "fin-close-summary-01",
"owner": "재무기획팀 김OO",
"runtime": "Copilot Studio",
"model": "공급사 모델명과 버전",
"tools": ["erp.read_gl", "sharepoint.write"],
"data_scopes": ["gl_monthly", "cost_center"],
"contract_ids": ["global-v3", "analytics-v1"],
"eval": { "golden_set": "fin-qa-120", "last_score": 0.91, "run_at": "2026-10-20" },
"status": "production",
"last_certified": "2026-10-01"
}Context Layer를 에이전트에 공급하려면 용어마다 정의, 계산식, 기준 테이블, 주인, 버전, 유효 시작일을 한 레코드로 둡니다. 에이전트에는 MCP 서버나 시맨틱 레이어 API로 노출해, 어떤 실행 환경에서 묻든 같은 레코드를 읽게 합니다. 실행 환경마다 정의를 프롬프트에 복사해 넣으면 원문이 말하는 분절이 그대로 생깁니다. 사업부마다 정의가 다르면 하나로 억지로 합치지 않고, 표준 정의 하나에 사업부 변형을 이름 붙여 둡니다(net_revenue, net_revenue@retail). 에이전트 응답에는 사용한 용어 ID와 버전을 함께 남겨, 틀린 답이 정의 탓인지 조회 탓인지 가를 수 있게 합니다.
{
"term_id": "net_revenue",
"definition": "총매출에서 반품·할인을 빼고 부가세를 제외한 금액",
"metric_sql_ref": "semantic.metrics.net_revenue",
"source_tables": ["dw.sales_fact", "dw.returns_fact"],
"owner": "재무기획팀",
"version": "2026.10",
"valid_from": "2026-10-01",
"variants": ["net_revenue@retail"]
}Context Drift를 잡으려면 골든 질문 세트를 만들어 정기적으로 돌립니다. 분석 에이전트라면 정답이 확정된 질문 100~150개를 재무·영업 담당자가 만들고, 매주 같은 질문을 temperature 0으로 3회씩 실행해 정답률과 실행 간 불일치율을 봅니다. 기준선 대비 5%p 넘게 떨어지거나 불일치율이 10%를 넘으면 알림을 보냅니다. 평가 주기와 별도로 변경 이벤트에도 반응해야 합니다. 데이터 카탈로그의 스키마 변경, 지표 정의 개정, 조직 개편이 생기면 해당 용어를 참조하는 에이전트를 목록에서 찾아 골든 질문을 바로 다시 돌립니다. 원문의 사례처럼 두 달 동안 아무도 보지 않으면 하락을 늦게 알게 됩니다.
Agent Contract와 Guardian을 구현하려면 규칙을 정책 언어로 적고, 에이전트의 도구 호출이 실행되기 전 단계에 정책 평가를 끼웁니다. Open Policy Agent(Rego)나 AWS Cedar 같은 정책 엔진을 쓰면 같은 입력에 같은 판정이 나오고, 판정에 걸리는 시간은 보통 밀리초 단위입니다. 평가 입력은 에이전트 ID, 호출하려는 도구, 인자, 다룰 데이터의 분류 등급, 금액 같은 수치입니다. 출력은 allow·deny·escalate 셋 중 하나와 사유 코드로 정합니다. global contract에는 개인정보 등급 데이터의 외부 전송 금지, 운영 쓰기 권한의 사람 승인 같은 공통 규칙을, specialized contract에는 분석 에이전트의 조회 가능 스키마, 결제 에이전트의 건당 금액 상한 같은 유형별 규칙을 둡니다.
{
"agent_id": "cs-reply-02",
"action": "send_message",
"args_summary": { "channel": "email", "fields": ["name", "order_id", "rrn"] },
"data_class": "PII-high",
"decision": "deny",
"reason_code": "GLOBAL-PII-EXPORT",
"contract": "global-v3",
"evaluated_ms": 2
}실패하는 경우와 대응. 넷을 미리 대비합니다. 첫째, 규칙이 너무 엄격하면 팀이 guardian을 거치지 않는 경로를 만듭니다. 차단율을 규칙별로 보고, 한 규칙의 차단이 주간 호출의 5%를 넘으면 규칙 주인과 다시 봅니다. 둘째, 맥락 계층에 없는 용어를 물으면 에이전트가 추측으로 답합니다. 정의를 찾지 못하면 답하지 말고 『정의 없음』과 담당자를 돌려주게 합니다. 셋째, 규칙으로 적기 어려운 판단(답변 어조, 문맥상 민감한 내용)은 결정론적 검사로 잡히지 않습니다. 이런 항목은 계약 대상에서 빼고 표본 검토로 돌립니다. 넷째, 목록이 실제와 어긋납니다. 게이트웨이 로그와 목록을 매주 대조해 미등록 호출 주체를 0으로 유지합니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 6주 동안 하는 일 |
|---|---|---|
| 스폰서 | CIO 또는 CDO | 대상 에이전트 범위와 관문 승인 |
| AX 추진 | AX 추진팀 1~2명 | 에이전트 목록 수집, 관문 운영 |
| 데이터 거버넌스 | 데이터 거버넌스·카탈로그 담당 1명 | 용어 레코드 설계, 주인 지정 |
| 용어 주인 | 재무·영업 등 현업 담당 각 1명 | 정의 확정, 골든 질문 작성 |
| 보안 | CISO 조직 1명 | global contract 규칙 작성, 차단 로그 검토 |
| 엔지니어 | 플랫폼 엔지니어 1~2명 | 게이트웨이 로그 수집, 정책 엔진 연결 |
시작 전 준비물: 사내 LLM 게이트웨이·Copilot·ChatGPT 관리 콘솔 접근 권한, 기존 데이터 카탈로그와 용어 사전, 데이터 분류 기준(개인정보 등급 등), 현재 운영 중인 에이전트 담당자 명단, 지난 분기 경영 보고에 쓴 핵심 지표 10~20개의 정의서.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 에이전트 목록 수집, 미등록 에이전트 표시 | 에이전트 목록 v1 |
| 2주 | 분석 에이전트 1개 선정, 핵심 용어 20개 정의와 주인 지정 | 용어 레코드 20건 |
| 3주 | 골든 질문 100개 작성, 맥락 없음·있음 정답률 측정 | 기준선 정답률 |
| 4주 | global contract 규칙 5~10개 작성, 정책 엔진 연결 | 계약 v1, 판정 로그 |
| 5주 | 관문 5항목 자동 점검, 변경 이벤트 재평가 연결 | 관문 체크리스트 |
| 6주 | 판정 회의, 확대 대상 결정 | 판정 보고서 |
확인 질문(현업·AX 추진용): 지금 회사에서 에이전트가 몇 개 돌고 있고, 각각 누가 책임집니까? 경영 보고의 핵심 지표 가운데 부서마다 계산이 다른 것은 무엇입니까? 지표 정의가 바뀌면 지금은 누가 어떤 경로로 알립니까? 에이전트가 해서는 안 되는 행동 다섯 가지를 문장으로 적을 수 있습니까? 지난 3개월 동안 에이전트가 권한 밖 데이터를 보여 준 일이 있었습니까?
진행 판정 기준(예시): 미등록 에이전트가 0개이고, 대상 분석 에이전트의 골든 질문 정답률이 맥락 연결 뒤 85% 이상이며, global contract 판정 로그에서 오탐(차단하지 말아야 할 것을 막은 경우)이 5% 이하이면 다음 에이전트 유형으로 넓힙니다. 정답률이 70% 아래면 용어 레코드를 보강해 3주차부터 다시 돌립니다.
AX 적용 제언. 이 구조가 먼저 필요한 곳은 Copilot·ChatGPT·자체 에이전트를 함께 쓰기 시작한 대기업입니다. 출발점은 정답이 하나뿐인 재무·영업 지표를 다루는 분석 에이전트가 좋습니다. 맥락 효과를 정답률로 바로 잴 수 있기 때문입니다. 순서는 목록 수집 → 핵심 지표 용어 레코드 → 골든 질문 기준선 → global contract → 유형별 계약 확대입니다. 이미 데이터 카탈로그나 거버넌스 조직이 있는 회사라면 맥락의 주인을 새로 만들지 말고 그 조직에 맡기는 편이 빠릅니다. 바꿔야 할 관행은 두 가지입니다. 에이전트 프로젝트마다 정의를 프롬프트에 따로 적는 일을 멈추고, 배포 뒤 정확도를 재는 일을 데이터 파이프라인 모니터링과 같은 운영 업무로 예산에 넣어야 합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표처 | VentureBeat(2026.10.20, VB Staff). VentureBeat AI Week 뉴욕 행사 대담 |
| 화자 | Felix Van de Maele, Collibra 창업자 겸 CEO. 진행 Matt Marshall(VentureBeat CEO) |
| 핵심 주장 | 에이전트 확장의 세 요건: 목록, 계약, 유지되는 맥락 |
| 확장의 벽 | copilot 하나에서 자율 에이전트 10~15개로 갈 때 기업 75% 넘게 운영 단계에서 막힘(출처 미기재) |
| VentureBeat 조사 | 2026년 6월, 기술 리더 157명. 자동 eval만으로 운영 변경 허용 34%, eval 완전 신뢰 5% |
| Harris Poll(Collibra 의뢰) | 에이전트의 권한 밖 데이터 접근·노출을 적발한 기업 약 30% |
| Collibra 조사 | 응답자 90%가 정렬된 데이터 기반 부재를 신뢰할 수 없는 결과의 원인으로 꼽음 |
| 분석 에이전트 | 한 프런티어 모델 연구소 사내 에이전트, 맥락 없이 약 30% → 맥락 연결 약 90% → 두 달 뒤 60% |
| 맥락 분절 | Cowork, ChatGPT, Microsoft Copilot, 자체 agent harness, 데이터 플랫폼에 맥락이 흩어짐 |
| 계약·Guardian | global·specialized contract, 실행 전 결정론적 규칙 평가로 금지 행동 차단, LLM 판정 배제 |
| 전망 | 앞으로 10년은 맥락의 분절·사일로·품질 문제를 푸는 시기 |
핵심 개념
- hallucination gap
- 벤더가 약속한 성능과 기업 현장에서 실제로 얻는 결과 사이의 차이. 원문은 에이전트가 늘 맞지 않고, 사람이 여전히 필요하고, 비용이 오른다는 점으로 설명한다.
- brute-force management
- 사람을 붙여 출력 확인, 재인증, 맥락 수정을 하는 관리 방식. 필요한 인력이 에이전트 수에 비례한다.
- automated eval
- 사람 검토 없이 자동 평가 결과만으로 에이전트의 변경을 통과시키는 방식.
- agent harness
- 모델을 감싸 도구 호출, 기억, 실행 흐름을 관리하는 실행 틀.
- deterministic(결정론적)
- 같은 입력에 언제나 같은 출력이 나오는 성질. guardian 판정의 전제다.
- runtime enforcement
- 배포 전 검토가 아니라 에이전트가 행동하는 순간에 규칙을 적용하는 것.
내 메모
TODO: 내 생각 추가
원문: VB Staff, “Scaling AI agents requires three things: Inventory, contracts and maintained context”(VentureBeat, 2026.10.20). Collibra CEO Felix Van de Maele의 VentureBeat AI Week 대담을 정리한 기사이며, Collibra는 이 영역의 제품을 파는 회사입니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON 예시, 정책 엔진 예(Open Policy Agent, AWS Cedar), 설정값, 일정·판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체는 VentureBeat에서 볼 수 있습니다.