D&B가 보유한 6억 4천 2백만 기업 데이터베이스는 인간용으로 설계됐지만, AI 에이전트를 위해 다시 만들었다.
Source: VentureBeat
Dun & Bradstreet는 180년 넘게 포괄적인 상업 데이터베이스를 구축해 왔습니다. 6억 4천2백만 기업과 그 관계, 기업 계층 구조 및 위험 프로필을 포함하는 Commercial Graph는 사람을 위해 설계되었습니다. 신용 분석가, 위험 관리자, 영업 전문가가 쿼리 결과를 기다리고 모호한 엔터티 매치를 직접 해결할 수 있도록 만든 것이죠. AI 에이전트는 그런 작업을 할 수 없습니다.
고객이 신용, 조달 및 공급망 워크플로에 에이전트를 도입하기 시작하면서, 전 세계 거의 20만 명의 고객에게 신뢰받아 온 Commercial Graph가 문제가 되었습니다. 인간 분석가를 위해 만든 시스템은 기계에 맞는 아키텍처가 아니었습니다. 그래서 D&B는 재구축했습니다.
“우리는 에이전트를 새로운 소비자 카테고리로 생각해야 합니다. 기존의 신용 분석가나 영업·마케팅 전문가에서 시작해 이제는 이 고객들의 에이전트까지도 만족시켜야 합니다.”
— Gary Kotovets, Dun & Bradstreet 최고 데이터·분석 책임자, VentureBeat 인터뷰
에이전트가 쿼리를 시작했을 때 무너진 점
Commercial Graph는 단일 데이터베이스가 아니었습니다. 서로 다른 사용 사례와 시장을 위해 만든 별도 시스템들의 집합이었으며, 맞춤형 통합으로 연결되어 있었습니다. 인간 분석가는 SQL 쿼리나 사전 구축된 인터페이스를 통해 이 파편화를 극복했지만, 에이전트는 할 수 없었습니다.
기본 데이터 규모가 문제를 더욱 키웠습니다. 데이터베이스는 5년 사이에 거의 두 배로 늘어나 3억 개가 넘던 기업 레코드가 6억 4천2백만 개가 되었으며, 레코드당 11,000개의 필드를 보유하고 있다고 D&B는 말합니다. 현재 이 기업은 레코드가 시스템을 통과할 때마다 월 약 1천억 건의 데이터 품질 검사를 수행합니다. 에이전트가 요구하는 서브초 지연 시간으로 파편화된 아키텍처를 쿼리하는 것은 현실적이지 않았습니다.
그래프가 추적하던 관계 역시 잘못된 유형이었습니다. 레거시 시스템은 엔터티 간의 정적 연결만 기록했습니다. 예를 들어 CEO가 특정 회사와 연결되는 것이 전부였습니다. 신용 평가나 제3자 위험 분석을 수행하는 에이전트는 동적 관계가 필요합니다. CEO가 새로운 회사로 옮겨갈 때 그들의 실적 기록은 어디로 이어지는가? 자회사의 소유권이 바뀌면 기업 계층 구조 전체에 어떻게 전파되는가? 이러한 질문은 이전에 분석가가 맞춤형 작업을 통해 해결해야 했으며, 에이전트는 기다릴 수 없습니다.
이 문제는 D&B만의 고유 현상이 아닙니다. Kotovets는 지난 6개월 동안 수백 명의 CDO와 CIO와 대화하면서 “AI에 필요한 것을 구축하려면 데이터 기반이 표준화·정규화·에이전트가 쿼리할 수 있는 형태여야 한다”는 동일한 제약을 반복해서 들었다고 말합니다. D&B는 인간 분석가를 위해 수십 년에 걸쳐 만든 기반을 이미 보유하고 있었지만, 에이전트를 위해서는 다시 구축해야 했습니다.
실제로 구축한 내용
재구축은 통합부터 시작되었습니다. D&B는 파편화된 데이터베이스를 클라우드 인프라로 이전하고, 기본 스키마를 재설계했으며, 시장별 레코드를 정규화하면서도 지역 규제 요구사항을 유지하는 데이터 패브릭 레이어를 구축했습니다. 그 결과 6억 4천2백만 기업에 걸쳐 수십억 개의 관계를 추적하는 통합 지식 그래프가 탄생했으며, AI 기반 데이터 처리에 의해 지속적으로 업데이트·보강됩니다.
이 그래프 위에 D&B는 에이전트를 위한 구조화된 접근 레이어를 만들었습니다. 에이전트가 요구하는 대량 쿼리와 지연 시간에 raw SQL 접근을 제공하는 것은 해결책이 아니었습니다. 대신 D&B는 MCP(Managed Cloud Platform)를 통해 데이터에 컨텍스트를 입히고, 특정 쿼리에 맞는 레코드로 에이전트를 라우팅하는 도구와 기능을 제공했습니다. 모든 쿼리 뒤에는 매치·엔터티 해상도 엔진이 있어, 에이전트가 기업을 물어볼 때 이름 매치가 아니라 검증된 특정 엔터티로 답변이 반환됩니다.
D&B가 에이전트 정체성을 양방향으로 해결한 방법
그래프 재구축과 MCP 접근 레이어 도입으로 데이터 검색 문제는 해결됐지만, 정체성 문제는 남아 있었습니다. 에이전트는 인간이 아니며, 인간 사용자를 위해 만든 인증 모델을 그대로 적용할 수 없었습니다.
D&B는 에이전트를 위한 새로운 등록 모델을 만들었습니다. 에이전트는 검증된 IP 주소와 개별 액세스 키를 매핑해야 하며, 이는 인간 사용자와 동일한 파이프라인에서 인증된 정체성으로 취급됩니다.
“우리는 ‘Know Your Agent(에이전트를 알라)’라는 개념을 가지고 있습니다. 이는 고객을 알듯이 추가 검증을 수행합니다.” — Kotovets
이 모델은 인바운드 문제, 즉 어떤 기업에 속한 에이전트인지, 어떤 데이터에 접근 권한이 있는지를 파악합니다. 동시에 아웃바운드 문제도 해결했습니다. 고객 자체의 다중 에이전트 워크플로가 어느 기업을 분석하고 있는지 놓치는 상황을 방지합니다.
예를 들어 신용 체크 에이전트, KYC 에이전트, 제3자 위험 에이전트가 순차적으로 D&B에 쿼리한다면, 각 단계에서 동일한 엔터티를 참조하고 있는지 확인하는 메커니즘이 없으면 서로 다른 레코드를 기반으로 워크플로가 완료될 수 있습니다.
“그들은 여전히 같은 엔터티에 대해 대화하고 있는지 확인하기 위해 우리 검증 에이전트에 다시 돌아와야 합니다. 일종의 디지털 핸드셰이크와 같습니다.” — Kotovets
D&B의 비즈니스 검증 에이전트는 어떤 워크플로에도 지속적인 참조 지점으로 삽입될 수 있으며, 고객이 사용하는 오케스트레이션 도구와 무관하게 Google의 A2A 프로토콜을 통해 제공됩니다.
AI 에이전트를 배포하기 전에 기업이 반드시 맞춰야 할 네 가지
재구축 과정에서 드러난 요구사항은 D&B 자체 스택을 넘어섭니다.
-
데이터 기반이 에이전트 인프라보다 먼저
Kotovets가 최근 6개월간 대화한 CDO·CIO들은 모두 “데이터가 깨끗하고 정규화·통합되지 않으면 AI를 구축할 수 없다”는 동일한 장벽에 부딪혔다고 말합니다. D&B는 이미 그 기반을 갖추고 있었지만, 대부분의 기업은 아직 그렇지 않으며, 곧 그 차이를 체감하게 될 것입니다. -
정적 관계가 아닌 동적 관계를 설계
전통적인 기업 데이터 시스템은 시점별 연결만 기록합니다(예: 사람은 회사에 속한다, 자산은 자회사에 속한다). 신용·위험·공급망 의사결정을 담당하는 에이전트는 시간이 흐름에 따라 변하는 관계를 이해해야 합니다. 데이터가 정적 라인만 담고 있다면 에이전트 역시 한계에 부딪힙니다. -
다중 에이전트 워크플로에 엔터티 일관성 검증을 내재
여러 에이전트가 서로 다른 단계에서 같은 엔터티를 다룰 때, 워크플로가 끝날 때까지 모두 동일한 레코드를 참조하고 있다는 보장이 없습니다. 이 격차는 명시적으로 설계에 포함시켜야 합니다. 엔터티 검증은 선택적인 가드레일이 아니라 워크플로 설계의 필수 요소입니다. -
라인지(데이터 출처 추적)를 사후가 아니라 처음부터 삽입
모든 에이전트가 만든 답변에는 원본으로 되돌아갈 수 있는 추적 가능한 경로가 포함되어야 합니다. 신용·위험·공급망 의사결정에서 오류 비용은 매우 큽니다. 라인지는 규모를 확장하기 전에 내재돼야 하며, 문제가 발생한 뒤에 추가해서는 안 됩니다.
“언제든 클릭해서 출처를 확인하고 원본까지 검증할 수 있어야 합니다. 이것이 우리에게 다른 많은 역량을 열어준 핵심이었습니다. 왜냐하면 우리는 우리가 만든 것에 대해 그 수준의 확신을 가지고 있기 때문이죠.” — Kotovets