Collibra AI Command Center, 에이전트 감사가 실시간으로 이동
Collibra AI Command Center는 에이전트 스프롤을 등록, 검증, 추적, 규제 증거까지 연결하는 실시간 거버넌스 문제로 바꿉니다.
- 무슨 일: Collibra가
AI Command Center를 출시하며 agentic AI의 실시간 통제 계층을 내세웠습니다.- 발표일은 2026년 5월 6일이며, Giskard와의 검증 파트너십도 함께 공개했습니다.
- 의미: 에이전트 거버넌스가 사후 감사에서 registry, trust signal, traceability 중심으로 이동합니다.
- 실무 영향: 기업은 모델만이 아니라 에이전트, 데이터 lineage, 정책, 승인 증거를 한 lifecycle로 묶어야 합니다.
- 주의점: 실시간 command center가 효과를 내려면 실제 tool call과 권한 집행 지점까지 연결돼야 합니다.
Collibra가 2026년 5월 6일 AI Command Center를 출시했습니다. Collibra는 이 제품을 agentic AI를 위한 실시간 자동 통제 계층으로 설명합니다. 문장만 보면 또 하나의 기업용 AI 거버넌스 제품처럼 보일 수 있습니다. 그러나 이번 발표가 중요한 이유는 AI 감사의 위치를 바꾸기 때문입니다. 모델을 배포한 뒤 산출물을 확인하고 규제 체크리스트를 채우는 방식에서, 에이전트가 행동하는 동안 계속 등록하고 추적하고 검증하는 방식으로 이동하고 있습니다.
Collibra의 표현 중 눈에 띄는 단어는 두 개입니다. 하나는 agent sprawl입니다. 부서별로 에이전트가 생기고, 어떤 에이전트가 어떤 데이터와 도구를 쓰는지 중앙에서 설명하기 어려워지는 상태입니다. 다른 하나는 hallucination tax입니다. Collibra는 이를 수동 검토, 재작업, 리스크가 에이전트 수와 함께 커지는 숨은 비용으로 봅니다. 환각 자체보다 더 큰 문제는, 그 환각을 발견하고 고치고 감사 가능한 증거로 남기는 비용이 조직 전체에 퍼진다는 점입니다.
이 메시지는 최근 기업 AI 시장의 흐름과 맞물립니다. Microsoft는 Agent 365로 조직 안의 에이전트 inventory와 shadow agent discovery를 말하고, ServiceNow는 AI Control Tower로 업무 에이전트 운영을 강조합니다. Glean은 ADLC로 에이전트를 소프트웨어처럼 정의하고 운영하자고 말합니다. Honeycomb은 Agent Timeline으로 프로덕션 에이전트의 실행 경로를 되감으려 합니다. Collibra의 차이는 데이터 거버넌스 회사답게 이 문제를 data lineage, AI use case, model, agent registry, compliance evidence의 문제로 끌고 간다는 점입니다.
사후 감사가 늦어지는 이유
전통적인 AI 거버넌스는 대체로 사후 검토에 가까웠습니다. 모델을 등록하고, 사용 목적을 적고, 위험도를 분류하고, 승인자를 지정하고, 주기적으로 성능과 편향을 점검합니다. 이 방식은 모델이 주로 추천이나 분류, 요약을 할 때는 어느 정도 작동합니다. 결과가 틀려도 사람이 다음 단계를 결정하는 경우가 많기 때문입니다.
에이전트는 다릅니다. 에이전트는 답변을 생성하는 데서 멈추지 않습니다. 티켓을 닫고, CRM 필드를 바꾸고, 문서를 생성하고, 데이터베이스를 조회하고, 외부 API를 호출하고, 승인 요청을 만들 수 있습니다. 이때 "나중에 검토하자"는 말은 너무 늦을 수 있습니다. 잘못된 데이터에 근거한 액션이 이미 실행됐거나, 민감한 데이터가 잘못된 context로 들어갔거나, 사람이 승인했다고 생각했지만 실제로는 에이전트가 권한을 상속받아 행동했을 수 있습니다.
그래서 Collibra는 AI Command Center를 단일 system of record로 포지셔닝합니다. 제품 페이지는 모든 AI use case, model, agent를 한 registry에서 관리하고, full lifecycle에 걸쳐 data, policy, use case dependency를 연결한다고 설명합니다. 핵심은 목록이 아닙니다. 목록은 시작점입니다. 중요한 것은 각 에이전트가 어떤 데이터 제품과 연결되는지, 어떤 정책을 따르는지, 어떤 risk assessment와 approval을 거쳤는지, 운영 중 어떤 trust signal이 변하는지 추적하는 일입니다.
Command Center가 묶으려는 네 가지
Collibra 발표를 구조로 나누면 네 가지 레이어가 보입니다. 첫째는 registry입니다. AI use case, model, agent를 등록하고 owner, purpose, status, scope를 관리합니다. 둘째는 traceability입니다. 에이전트가 사용하는 데이터와 정책, 승인, 리스크 평가를 연결합니다. 셋째는 validation입니다. Giskard와의 파트너십을 통해 model behavior, agent performance, potential risks를 테스트와 운영 거버넌스에 연결한다고 설명합니다. 넷째는 compliance입니다. AI UC-1 assessment template, EU AI Act, NIST AI RMF 템플릿을 통해 증거와 승인을 같은 흐름에 넣으려 합니다.
이 네 가지는 따로 움직이면 약합니다. 에이전트 registry만 있으면 최신 목록은 생기지만 실제 위험은 줄지 않습니다. 검증만 있으면 테스트 결과는 생기지만 어떤 운영 시스템에 적용되는지 모호할 수 있습니다. 규제 템플릿만 있으면 문서는 채우지만 에이전트 행동을 막지는 못합니다. Collibra가 command center라는 이름을 붙인 이유는 이 조각들을 하나의 운영 화면으로 묶겠다는 뜻입니다.
Giskard와 AI UC-1의 의미
이번 발표에서 Giskard 파트너십은 단순한 로고 추가가 아닙니다. 에이전트 거버넌스는 문서만으로 해결되지 않습니다. 실제 모델과 에이전트가 어떤 입력에서 어떻게 행동하는지 테스트해야 합니다. Collibra의 공식 블로그 The end-to-end control plane for AI has arrived는 Giskard가 execution-level testing and validation을 Command Center에 연결한다고 설명합니다. 모델 행동, 에이전트 성능, 잠재 리스크가 계속 capture되고 governance로 되돌아간다는 그림입니다.
AI UC-1 템플릿도 같은 맥락입니다. Collibra는 agentic AI compliance assessment를 바로 실행할 수 있는 템플릿을 제공한다고 설명합니다. 여기에 EU AI Act와 NIST AI RMF 템플릿이 붙습니다. 기업 입장에서는 이 부분이 중요합니다. AI 에이전트 규제 대응은 "우리도 정책이 있습니다"라고 말하는 것만으로 끝나지 않습니다. 어떤 사용 사례가 어떤 위험 등급인지, 어떤 데이터가 들어갔는지, 어떤 검증을 통과했는지, 누가 승인했는지, 운영 중 어떤 신호가 바뀌었는지 증거를 남겨야 합니다.
물론 템플릿은 시작일 뿐입니다. 실제 통제는 실행 지점에 가까워야 합니다. 예를 들어 에이전트가 고객 데이터를 조회하려 할 때, registry에 등록된 정책과 실제 권한 집행이 연결돼야 합니다. 에이전트가 승인되지 않은 tool을 호출하려 할 때 command center가 알림만 띄우는지, 차단까지 하는지에 따라 제품의 의미는 달라집니다. Collibra가 말하는 real-time automated control이 진짜 차별점이 되려면, 증거 관리와 runtime enforcement 사이의 거리가 짧아져야 합니다.
MCP Server는 context 통제의 단서
Collibra가 함께 강조한 또 다른 축은 MCP Server입니다. 공식 블로그는 Collibra MCP Server를 100개 이상 고객이 production에서 사용 중이며 Databricks Marketplace에서 상위 위치에 올랐다고 설명합니다. 이 수치는 Collibra의 주장으로 봐야 하지만, 방향성은 중요합니다. 에이전트가 좋은 결정을 하려면 좋은 context가 필요하고, 기업 context는 그냥 문서 검색으로 끝나지 않습니다. 데이터 정의, 소유자, 품질 규칙, lineage, 정책, 민감도 같은 metadata가 필요합니다.
MCP는 에이전트가 외부 도구와 context에 접근하기 위한 표준 인터페이스로 자리 잡고 있습니다. 하지만 MCP 서버가 늘어날수록 또 다른 문제가 생깁니다. 어떤 서버가 신뢰 가능한지, 어떤 metadata가 최신인지, 어떤 에이전트가 어떤 context를 호출할 수 있는지 관리해야 합니다. Collibra에게 MCP Server는 단순한 개발자 편의 기능이 아니라, 거버넌스된 metadata를 에이전트 runtime에 공급하는 통로입니다. 이 지점에서 AI Command Center와 MCP Server는 서로 맞물립니다. command center는 무엇을 허용할지 정하고, MCP Server는 에이전트가 실제로 쓰는 context를 제공합니다.
개발팀 입장에서는 이 변화가 꽤 현실적입니다. 많은 에이전트 실패는 모델이 "멍청해서"가 아니라 context가 불완전하거나 낡았거나 권한 없이 섞였기 때문에 발생합니다. 데이터 카탈로그에서 정의가 바뀌었는데 에이전트가 예전 용어를 쓰거나, 고객 세그먼트의 owner가 바뀌었는데 자동 보고서가 예전 부서에 전달되거나, lineage상 민감한 필드를 downstream에서 쓰면 안 되는데 summary에 들어가는 식입니다. 에이전트가 프로덕션 업무를 맡으려면 모델 프롬프트만큼 metadata hygiene이 중요해집니다.
데이터 거버넌스 회사의 유리한 위치
Collibra가 이 시장에 들어오는 방식은 OpenAI, Anthropic, Google, Microsoft와 다릅니다. 모델 회사는 더 강한 추론과 도구 호출을 밀고, 업무 플랫폼 회사는 자신의 앱 안에서 에이전트를 배치합니다. Collibra는 데이터와 거버넌스에서 출발합니다. 그래서 AI Command Center의 강점은 모델의 똑똑함이 아니라 "어떤 데이터와 정책 위에서 행동했는가"를 설명하는 능력이어야 합니다.
이 포지션은 규제 산업에서 특히 의미가 있습니다. 금융, 보험, 의료, 공공, 제조처럼 감사와 데이터 책임이 강한 조직은 에이전트의 최종 답변보다 실행 근거를 더 중요하게 봅니다. 이 에이전트가 어떤 데이터셋을 읽었는지, 해당 데이터셋의 품질 상태가 어땠는지, 개인 정보 처리 근거는 무엇인지, 어떤 승인을 거쳤는지, 위험 평가가 언제 갱신됐는지 설명해야 합니다. 기존 데이터 거버넌스 시스템이 이 증거를 이미 일부 가지고 있다면, agentic AI governance로 확장할 여지가 있습니다.
하지만 약점도 있습니다. 에이전트 통제는 문서와 registry만으로 충분하지 않습니다. 실제 실행 환경, identity, credential, tool gateway, browser automation, API gateway와 붙어야 합니다. Microsoft는 Entra와 M365, GitHub를 가졌고, AWS는 AgentCore와 IAM을 가졌습니다. ServiceNow는 workflow와 ITSM을 가졌습니다. Collibra가 command center를 진짜 runtime control plane으로 만들려면 이 실행 계층들과 얼마나 깊게 통합되는지가 관건입니다.
지금 봐야 할 질문
Collibra AI Command Center가 던지는 질문은 제품 도입 여부보다 넓습니다. 첫째, 우리 조직은 에이전트를 자산으로 등록하고 있는가. 누가 만들었고, 누구를 대신해 행동하며, 어떤 데이터와 도구에 접근하는지 한 곳에서 볼 수 있어야 합니다.
둘째, 에이전트의 trust signal은 무엇인가. 단순 성공률이 아니라 데이터 품질, tool call 실패율, human override, policy exception, 사용자 피드백, drift를 봐야 합니다. 셋째, compliance evidence는 자동으로 쌓이는가. 배포 후 감사 시즌에 문서를 다시 만드는 방식은 에이전트 속도를 따라가기 어렵습니다. 넷째, command center가 실제 차단 지점과 연결돼 있는가. dashboard가 아무리 좋아도 실행을 멈출 수 없다면 관측성일 뿐 통제는 아닙니다.
이 흐름은 앞으로 더 커질 가능성이 큽니다. 에이전트가 많아질수록 조직은 모델별 성능표보다 agent inventory, data lineage, policy enforcement, evaluation history를 더 자주 묻게 됩니다. 개발팀에게는 귀찮은 절차처럼 보일 수 있지만, 고위험 업무에서는 이것이 배포의 전제 조건이 됩니다. "AI가 답했다"가 아니라 "어떤 등록된 에이전트가 어떤 승인된 context에서 어떤 정책 아래 행동했다"라고 말할 수 있어야 합니다.
Collibra의 발표는 그래서 조용하지만 중요한 뉴스입니다. AI 에이전트가 행동하기 시작하면 감사도 행동 시간에 가까워져야 합니다. 사후 리뷰만으로는 부족합니다. registry, validation, traceability, compliance, metadata context가 하나의 운영 루프로 묶여야 합니다. AI Command Center가 그 약속을 얼마나 실제 runtime까지 밀고 갈지는 지켜봐야 합니다. 다만 방향은 분명합니다. 에이전트 시대의 거버넌스는 문서 보관함이 아니라 실행을 보는 관제탑으로 이동하고 있습니다.