642M 기업 그래프, 에이전트 데이터 병목의 실명표

AI 요약

• 무슨 일: D&B가 6억4200만 기업 데이터를 AI 에이전트가 쓰기 좋은 Commercial Graph 구조로 재정비한 흐름이 공개됐습니다.
  • 공식 조사에서는 기업의 97%가 AI 이니셔티브를 진행 중이지만, 데이터가 충분히 준비됐다는 응답은 5%에 그쳤습니다.
• 의미: 에이전트의 다음 병목은 프롬프트가 아니라 기업 신원, 소유 구조, 리스크 데이터를 같은 실체로 묶는 검증 계층입니다.
• 실무 영향: Claude MCP 연동처럼 KYC/KYB, 공급망 리스크, 감사 문서화가 에이전트 워크플로 안으로 들어오고 있습니다.
  • 다만 데이터 권한, 최신성, 설명 가능성, 감사 로그가 없으면 자동화 속도만 빨라지고 책임 소재는 더 흐려질 수 있습니다.

Dun & Bradstreet, 흔히 D&B로 부르는 오래된 기업 데이터 회사가 꽤 흥미로운 방향 전환을 보여주고 있습니다. VentureBeat는 2026년 5월 22일 D&B가 6억4200만 개 기업과 그 관계를 담은 데이터베이스를 AI 에이전트가 사용하기 쉬운 형태로 다시 정비했다고 보도했습니다. 표면적으로는 데이터베이스 현대화 이야기처럼 보입니다. 하지만 AI 개발자 입장에서 보면 더 큰 신호가 있습니다. 에이전트 경쟁이 모델, 컨텍스트 길이, 툴 호출 수에서 멈추지 않고 "행동할 대상이 누구인지 정확히 아는 데이터 계층"으로 내려가고 있다는 점입니다.

그동안 기업용 AI 에이전트 데모는 보통 이렇게 흘렀습니다. 사용자가 "이 회사를 온보딩해줘"라고 말하면 에이전트가 문서를 읽고, 웹을 검색하고, CRM을 갱신하고, 리스크 보고서를 작성합니다. 그런데 실제 기업 시스템에서는 이 단순한 문장이 금방 복잡해집니다. 같은 회사가 CRM, ERP, 조달 시스템, 결제 시스템, 제재 리스트, 법인 등기 데이터에서 서로 다른 이름으로 존재합니다. 지점, 자회사, 최종 모회사, 거래 상대, 공급사, 실소유자가 따로 움직입니다. 사람 분석가는 화면을 넘겨 보며 맥락을 보정하지만, 에이전트는 그런 암묵지를 안정적으로 갖고 있지 않습니다.

D&B가 강조하는 지점은 바로 여기입니다. 회사는 2026년 5월 4일 발표한 AI Momentum Survey에서 기업 AI 도입이 이미 실험 단계를 넘어섰지만, 데이터 준비도는 따라오지 못한다고 밝혔습니다. 조사 대상은 32개국 10,000개 기업입니다. 이 중 97%가 AI 이니셔티브를 진행 중이라고 답했고, 56%는 향후 12개월 동안 AI 투자를 늘리겠다고 했습니다. 하지만 "데이터가 AI를 충분히 지원할 준비가 됐다"는 응답은 5%에 불과했습니다.

이 숫자 조합은 요즘 AI 인프라 시장을 읽는 데 유용합니다. 모델의 품질은 계속 올라가고, 에이전트 프레임워크는 파일 시스템, 브라우저, 코드 실행, MCP 서버를 빠르게 흡수하고 있습니다. 그러나 기업 환경에서는 "무엇을 할 수 있는가"보다 "어떤 대상에 대해 해도 되는가"가 더 중요해집니다. 신규 거래처가 실제 존재하는 법인인지, 제재 대상과 연결되어 있지는 않은지, 최종 모회사가 누구인지, 이미 내부 시스템에 다른 이름으로 등록되어 있지는 않은지 모르면 에이전트는 자신 있게 틀린 결정을 내릴 수 있습니다.

D&B의 공식 표현은 이 병목을 "verified commercial identity foundation"이라고 부릅니다. 회사는 D-U-N-S Number를 1963년에 만들었고, 이를 글로벌 상업 실체 식별 표준으로 설명합니다. Commercial Graph는 이 식별자를 기반으로 기업 신원과 관계를 여러 시스템에 걸쳐 일관되게 연결하는 데이터 계층입니다. 홍보 문구만 보면 평범한 마스터 데이터 관리처럼 들릴 수 있습니다. 하지만 에이전트 시대에는 의미가 달라집니다. 예전 MDM은 사람이 쓰는 리포트와 대시보드를 깨끗하게 만들기 위한 작업이었습니다. 지금은 AI가 API를 호출하고 문서를 만들고 워크플로를 진행하기 전에 같은 실체를 같은 실체로 알아보게 만드는 실행 조건이 됩니다.

D&B가 Anthropic과 연결한 사례는 이 변화를 잘 보여줍니다. D&B는 2026년 5월 5일 Claude와의 리스크·컴플라이언스 워크플로 연동을 발표했습니다. 핵심은 D&B Commercial Graph를 Claude에 MCP 서버로 연결해 KYC/KYB 온보딩, 소유 구조 확인, 글로벌 제3자 위험 평가, 위험 결정 문서 생성을 자동화하는 것입니다. D&B는 이를 통해 금융기관이 신규 법인 고객을 몇 초 안에 검증하고 감사 가능한 문서를 만들 수 있다고 설명합니다.

여기서 중요한 단어는 "몇 초"보다 "감사 가능한"입니다. 에이전트가 업무를 빠르게 처리하는 것은 이미 흔한 약속이 됐습니다. 하지만 규제 산업에서는 속도만으로 충분하지 않습니다. 왜 이 회사를 승인했는지, 어떤 데이터에 근거했는지, 어떤 위험 신호를 봤는지, 사람이 어디서 검토했는지, 나중에 같은 결정을 재현할 수 있는지가 필요합니다. 그래서 D&B의 발표는 단순히 Claude에 더 많은 데이터를 넣는 이야기가 아닙니다. 모델이 행동하기 전에 검증된 비즈니스 맥락과 의사결정 논리를 제공한다는 쪽에 가깝습니다.

최근 기업용 에이전트 발표를 보면 비슷한 패턴이 반복됩니다. Google은 Managed Agents와 Antigravity에서 샌드박스와 실행 환경을 강조합니다. GitHub와 OpenAI 계열은 코딩 에이전트의 작업 세션, PR, 로그, 권한 통제를 이야기합니다. Anthropic은 MCP와 커넥터, self-hosted sandbox, 엔터프라이즈 데이터 연결을 내세웁니다. D&B의 위치는 조금 다릅니다. 에이전트를 직접 실행하는 런타임을 팔기보다, 에이전트가 현실 세계의 기업을 식별하고 판단할 때 필요한 "정답에 가까운 참조 계층"을 팔고 있습니다.

이 흐름은 RAG 논의와도 연결됩니다. 2024년과 2025년 기업 AI 프로젝트의 기본 처방은 대체로 문서를 쪼개고, 임베딩하고, 벡터 검색으로 관련 문서를 찾아 모델에 넣는 방식이었습니다. 그러나 KYC, 공급망, 신용, 조달, B2B 영업 같은 영역에서는 문서 유사도만으로 충분하지 않습니다. "Apple"이라는 문자열이 애플 본사인지, 지역 리셀러인지, 계열사인지, 고객사가 적은 별칭인지 구분해야 합니다. 같은 주소, 같은 사업자 번호, 같은 도메인, 같은 모회사 관계를 가진 데이터가 서로 다른 시스템에 흩어져 있으면 검색 결과는 그럴듯해도 결정은 흔들립니다.

그래서 D&B 사례는 "RAG 다음 단계는 그래프다"라는 단순한 구호보다 구체적입니다. 에이전트가 행동하려면 세 가지가 필요합니다. 첫째, entity resolution입니다. 여러 시스템의 레코드를 같은 기업으로 연결해야 합니다. 둘째, 관계 그래프입니다. 자회사, 모회사, 공급망, 실소유자, 제재 연관성을 따라갈 수 있어야 합니다. 셋째, 정책과 감사입니다. 어떤 위험 점수나 신원 정보가 어떤 결정에 쓰였는지 남아야 합니다. 벡터 DB가 문서 조각을 찾는 데 강하다면, Commercial Graph 같은 계층은 "이 행동의 대상이 누구인가"를 고정하는 역할을 합니다.

공식 조사에서 나온 장애 요인도 같은 방향을 가리킵니다. 기업의 50%는 제한된 데이터 접근을 주요 장애로 꼽았고, 44%는 개인정보와 컴플라이언스 리스크, 40%는 데이터 품질과 무결성, 38%는 시스템 간 통합 부족을 문제로 들었습니다. 즉 "모델이 더 똑똑해지면 해결된다"는 문제가 아닙니다. 에이전트가 필요한 데이터에 접근할 수 있어야 하고, 그 데이터가 정확해야 하며, 여러 시스템에서 같은 의미를 가져야 하고, 민감한 작업에서는 책임 있는 승인 흐름을 가져야 합니다.

개발팀 입장에서 이 뉴스가 주는 실무적 질문은 꽤 날카롭습니다. 지금 만들고 있는 에이전트가 CRM, 결제, 조달, 데이터웨어하우스, 고객 지원 시스템을 넘나든다면, 그 에이전트는 같은 고객이나 공급사를 어떤 기준으로 식별합니까? 이름 문자열, 이메일 도메인, 내부 ID, 외부 식별자 중 무엇이 기준입니까? 모델이 두 레코드를 같은 회사라고 판단했을 때 그 판단을 사람이 검토할 수 있습니까? 잘못 병합된 기업 정보가 자동 승인이나 자동 차단으로 이어지는 경우 되돌릴 수 있습니까?

이 질문은 특히 MCP 생태계에서 중요합니다. MCP는 도구 연결을 표준화하는 데 큰 역할을 하지만, 연결 자체가 데이터 품질을 보장하지는 않습니다. Claude가 D&B MCP 서버를 통해 Commercial Graph를 읽는다는 것은 "도구 호출"과 "검증된 도메인 데이터"가 결합되는 예입니다. 앞으로 많은 기업은 사내 데이터 소스를 MCP 서버로 포장할 것입니다. 하지만 단순 래핑만으로는 부족합니다. 에이전트가 사용할 데이터라면 식별자 정책, 권한 범위, 필드 의미, freshness, 감사 로그가 함께 설계되어야 합니다.

물론 D&B의 접근이 곧 표준이 된다는 뜻은 아닙니다. D&B는 자사의 데이터와 식별자 체계를 중심으로 시장을 해석합니다. Moody's, LexisNexis, S&P, PitchBook, OpenCorporates, 각 산업별 데이터 제공업체도 비슷한 자리를 노릴 수 있습니다. 대기업 내부에는 이미 MDM, CDP, 데이터 카탈로그, 지식 그래프, 데이터 품질 도구가 있습니다. 이들이 모두 "에이전트 준비 데이터"라는 이름으로 다시 포장될 가능성이 큽니다. 그래서 개발자는 공급업체의 AI 문구보다 실제 API 계약을 봐야 합니다. 어떤 식별자를 반환하는지, 충돌을 어떻게 표시하는지, 근거 데이터를 제공하는지, 사람 검토 상태를 기록할 수 있는지가 더 중요합니다.

커뮤니티 반응은 아직 크지 않습니다. 2026년 5월 22일 기준 HN이나 GeekNews에서 D&B 보도가 큰 토론으로 번진 흔적은 확인되지 않았습니다. Reddit에도 요약 공유가 있었지만 소규모였습니다. 다만 VentureBeat의 같은 주간 기사 배열을 보면 방향은 분명합니다. 에이전트가 잊어버리는 문제, RAG가 한계에 부딪히는 문제, 프로덕션 시스템을 깨뜨리는 AI 코딩 붐, Google의 Managed Agents API처럼 실행 계층을 클라우드 사업자가 가져가는 문제가 함께 다뤄지고 있습니다. 모두 모델 바깥의 운영 계층 이야기입니다.

이 뉴스의 의미를 한 문장으로 줄이면 이렇습니다. 기업용 AI 에이전트는 이제 "말을 잘하는 모델"에서 "검증된 현실 세계 객체를 다루는 자동화 시스템"으로 넘어가고 있습니다. 그 전환에서 데이터베이스는 더 이상 사람이 검색하는 백오피스 저장소가 아닙니다. 에이전트가 누구와 거래하고, 무엇을 승인하고, 어떤 위험을 감수하는지 결정하기 전에 참조하는 신원 인프라가 됩니다.

그래서 6억4200만 기업 그래프라는 숫자는 단순한 규모 자랑보다 다른 메시지를 줍니다. AI 도입률 97%와 데이터 준비도 5% 사이의 간극이 바로 지금의 엔터프라이즈 AI 병목입니다. 그 간극을 메우는 회사가 모델 회사일 수도 있고, 클라우드 회사일 수도 있고, D&B 같은 오래된 데이터 회사일 수도 있습니다. 확실한 것은 하나입니다. 에이전트가 실제 업무를 맡을수록, "무엇을 생성했는가"보다 "누구에 대해 어떤 근거로 행동했는가"가 더 중요한 질문이 됩니다.