Headless Context Layer: ZoomInfo 고객이 화면 대신 MCP·API로 영업 데이터를 쓰는 이유
ZoomInfo 3분기 콜에서 Henry Schuck CEO는 1만 곳 넘는 고객이 MCP 서버·CLI·새 API로 데이터를 쓰고 그 사용량이 전 분기의 두 배가 됐다고 밝혔습니다. 일부 고객은 Replit·Vercel·Claude로 자기 화면을 만들어 좌석 대신 대량 크레딧을 삽니다. AI 과제가 데이터 계층에서 멈춘 Fortune 500 복합기업은 연락처 마스터 데이터 정비부터 계약했습니다. 연락처 마스터 스키마와 6주 일정을 붙였습니다.
영업 데이터 벤더 ZoomInfo의 고객 1만 곳 이상이 벤더 화면 대신 MCP 서버, 명령줄 도구(CLI), 새 API로 데이터를 에이전트와 자체 앱에 연결하고 있고, 이 사용량은 한 분기 만에 두 배가 됐습니다. 사는 쪽이 이 흐름을 쓰려면 먼저 사내 연락처 데이터를 하나의 마스터로 합치고, 좌석 대신 크레딧으로 바뀌는 계약을 호출 단위로 관리할 장치를 갖춰야 합니다.
요약
ZoomInfo는 기업·연락처 정보와 구매 신호를 영업·마케팅 팀에 파는 회사입니다. 2026년 11월 4일 열린 3분기 실적 콜에서 창업자 Henry Schuck CEO와 Graham O’Brien CFO는 숫자와 제품 방향을 함께 설명했습니다. 매출은 3.09억 달러로 전년보다 3% 줄었지만 가이던스 상단을 넘었고, 조정 영업이익은 1.19억 달러(이익률 39%)였습니다. 전체 ACV(연간 계약 금액)의 77%가 업마켓(대기업·중견 고객)에서 나오고, 기존 고객의 매출 유지율(NRR)은 88%였습니다. 소프트웨어 업종 고객 비중은 2021년 45%에서 약 30%로 내려왔습니다. 경영진은 소프트웨어 고객의 판매 주기가 길어지고 구매에 관여하는 사람이 늘었으며 벤더 심사도 까다로워졌다고 설명했습니다.
콜에서 AX 관점으로 눈여겨볼 대목은 숫자보다 고객이 데이터를 쓰는 방식의 변화입니다. Schuck CEO는 연초에는 없던 경로인 MCP 서버, CLI, 개편한 API로 데이터를 쓰는 고객이 1만 곳을 넘었고, 이 경로의 사용량이 전 분기 대비 두 배가 됐다고 밝혔습니다. 일부 고객은 Replit, Vercel, Claude로 자기 화면을 직접 만들고, 좌석은 줄이는 대신 데이터를 대량 크레딧으로 삽니다. 산업자동화·항공 분야의 한 Fortune 500 복합기업은 AI 과제가 데이터 계층에서 멈추자 여러 CRM과 마케팅 시스템의 연락처를 하나로 합치는 마스터 데이터 작업을 계약했습니다. 회사는 CRM 기록·이메일·통화 녹취를 엮는 Workbounce와 다중 에이전트 실행을 맡는 DoubleO.ai도 인수했습니다. 아래에서는 이 변화를 네 가지 메커니즘으로 풀고, 사는 쪽이 따라 할 마스터 데이터 설계와 6주 일정을 붙입니다.
핵심 메커니즘
Headless Data Access: 화면 없이 데이터를 에이전트에 붙이는 경로
Headless는 화면(UI) 없이 기능과 데이터만 내놓는 방식을 말합니다. ZoomInfo는 같은 데이터를 세 경로로 열었습니다. MCP(Model Context Protocol, AI 모델이 외부 도구와 데이터를 부르는 표준 규약) 서버, 개발자가 터미널에서 부르는 CLI, 그리고 개편한 API입니다. 작동 방식은 단순합니다. 에이전트나 자체 앱이 “이 회사의 구매 담당자는 누구인가” 같은 요청을 보내면, 경로가 ZoomInfo 데이터를 조회해 구조화된 결과로 돌려줍니다. 결과는 고객이 만든 화면이나 워크플로 안에서 쓰입니다.
콜에서 언급된 사용처는 Grok으로 만든 봇, Vercel·Replit으로 만든 앱, n8n·Zapier 워크플로입니다. 이 경로를 쓴 고객은 1만 곳을 넘었습니다. 가장 많이 쓰는 사람은 영업 운영(sales ops), RevOps, 마케팅 운영, GTM 엔지니어였고, 새 경로에서는 BI(비즈니스 인텔리전스) 담당과 엔지니어가 가장 큰 사용자였습니다. 쓸 때: 사내에 이미 에이전트나 자동화 도구가 있고 벤더 화면을 오가는 일이 병목일 때입니다. 안 쓸 때: 사용자가 영업 담당자 몇 명뿐이고 벤더 화면으로 충분할 때입니다. 작은 예시(가상): 영업팀의 Claude 에이전트가 신규 잠재 고객 목록을 받으면 MCP로 회사 규모와 담당자를 채우고 CRM에 후보로 올립니다.
Seat-to-Credit: 좌석 대신 데이터와 AI 사용량을 사는 계약
좌석 계약은 쓰는 사람 수만큼 돈을 냅니다. 데이터가 에이전트와 자체 앱으로 흘러가면 사람 수와 사용량이 따로 놉니다. ZoomInfo는 3분기에 하이브리드 요금을 도입했습니다. CFO 설명에 따르면 전면 사용량 과금이 아니라 두 크레딧을 섞는 구조입니다. data credits는 고정 약정으로 고를 수 있고, AI credits는 첫해 사용량을 미리 정해 삽니다. 새로 인수해 만든 Agent Teams도 이 두 크레딧으로 과금합니다.
지금은 새 경로 사용 대부분이 고객이 이미 산 크레딧을 깎아 쓰는 방식이라, 매출에는 신규 ACV가 아니라 사용률로만 잡힙니다. 경영진은 고객이 산 용량을 다 쓰고 사용량 요금으로 넘어가면 추가 사용이 추가 매출이 된다고 설명했습니다. 사는 쪽에서 보면 이 구조는 비용이 사람 수가 아니라 에이전트 호출 수를 따라 움직인다는 뜻입니다. 언제 유리한가: 소수의 운영 담당자가 자동화로 많은 데이터를 쓸 때입니다. 언제 불리한가: 호출을 통제하지 않은 에이전트가 같은 조회를 반복할 때입니다.
Master Data Foundation: AI 앞에 놓는 연락처 마스터
마스터 데이터는 회사·사람처럼 여러 시스템이 함께 쓰는 기준 정보를 한 벌로 관리한 것입니다. 영업 조직은 보통 CRM, 마케팅 자동화, 이벤트 관리, 레거시 시스템에 같은 고객을 따로 들고 있습니다. 에이전트가 이 중 하나만 읽으면 같은 담당자에게 두 번 연락하거나 퇴사한 사람에게 제안서를 보냅니다. 마스터 데이터 작업은 원천마다 연락처를 모으고, 같은 사람과 회사를 찾아 합치고, 빈 값을 외부 데이터로 채워 하나의 신뢰 원천을 만듭니다.
Schuck CEO가 GTM1을 설명하며 쓴 말도 같은 방향입니다. 고객이 좌석이나 데이터 파일 대신 “entity-resolved”(같은 실체를 하나로 식별한) 시장 지도를 상시로 사게 된다는 것입니다. 쓸 때: 에이전트 시범 과제가 정확도 문제로 확대되지 못할 때, CRM이 계열사나 사업부마다 따로 있을 때입니다. 안 쓸 때: 원천이 CRM 하나이고 중복이 적을 때는 정비보다 바로 연결이 빠릅니다.
GTM Context Graph와 Agent Teams: 내부 기록과 외부 데이터를 한 맥락에
외부 데이터만으로는 “이 회사와 지난 분기에 무슨 이야기를 했나”를 알 수 없습니다. ZoomInfo가 인수한 Workbounce는 CRM 기록, 이메일, 통화 녹취 같은 비정형 내부 자료를 의미 단위로 묶는 semantic knowledge layer(의미 기반 지식 계층)입니다. 이 계층이 ZoomInfo의 기업·연락처·구매 신호와 합쳐진 것이 GTM context graph입니다. 에이전트는 이 그래프 하나를 읽고 시장 정보와 계정 이력을 함께 봅니다.
그 위에서 일하는 것이 DoubleO.ai 인수로 만든 Agent Teams입니다. 보도자료 설명으로는 역할·지침·도구가 서로 다른 에이전트들이 맥락을 공유하며 다음 행동을 고릅니다. 콜에서는 고객이 정한 통제 범위 안에서 영업 플레이 전체를 돌린다고 설명했습니다. ZoomInfo는 ClickUp·n8n과의 기본 연동을 내놓았고, Salesforce의 아웃바운드 영업 에이전트 Hunter에 핵심 데이터 파트너로 들어갔습니다.
통념과 다른 주장
흔히 이렇게 봅니다영업 데이터 서비스는 영업 담당자 수만큼 좌석을 팔아 커지고, AI 에이전트가 늘면 이런 벤더의 자리가 줄어듭니다.
ZoomInfo 경영진은 이렇게 봅니다고객은 화면보다 데이터와 맥락을 원하고, 에이전트가 늘수록 데이터 사용량은 오히려 커집니다. 다만 매출은 좌석이 아니라 크레딧으로 잡힙니다.
근거연초에 없던 MCP·CLI·새 API 경로를 1만 곳 이상이 쓰고 사용량이 한 분기 만에 두 배가 됐습니다. 자체 앱을 만든 고객은 좌석을 대량 크레딧으로 바꿨습니다.
흔히 이렇게 봅니다AI 과제가 멈추면 모델을 바꾸거나 다른 유스케이스를 찾습니다.
ZoomInfo 경영진은 이렇게 봅니다대기업 AI 과제는 데이터 계층에서 먼저 막히고, 그때 필요한 것은 흩어진 연락처를 합친 마스터 데이터입니다.
근거Fortune 500 복합기업이 AI 과제 정체를 겪은 뒤 GTM AI 프로그램의 일부로 마스터 데이터 기반 작업을 계약했습니다. Schuck CEO는 값싼 "vibe-coded"(AI로 빠르게 만든) 저가 앱은 믿기 어렵고 일부는 이미 문을 닫았으며, 업마켓 고객은 신뢰·개인정보·보안·규정 준수를 먼저 본다고 말했습니다.
콜에서 든 사례
Fortune 500 산업자동화·항공 복합기업: AI보다 마스터 데이터가 먼저
| 항목 | 내용 |
|---|---|
| 상황 | 전 세계에서 사업하는 산업자동화·항공 복합기업. AI 과제가 데이터 계층에서 멈췄고, 불완전한 데이터가 레거시 시스템 곳곳에 흩어져 있었습니다. 영업 조직은 이미 ZoomInfo로 계정 우선순위를 정하고 구매 신호에 대응하고 있었습니다. |
| 한 일 | GTM AI 프로그램의 일부로 마스터 데이터 기반 작업을 계약했습니다. 여러 CRM과 마케팅 시스템의 연락처를 하나의 신뢰 원천으로 합치는 일입니다. |
| 결과 | 콜 시점에 진행 중인 계약입니다. 기간, 금액, 정비 뒤 성과 수치는 콜에서 밝히지 않았습니다. |
| 연결 | Master Data Foundation 메커니즘의 사례입니다. 에이전트를 붙이기 전에 기준 데이터를 먼저 한 벌로 만든 경우입니다. |
자체 화면을 만든 고객들: 좌석을 크레딧으로
| 항목 | 내용 |
|---|---|
| 상황 | 여러 고객이 Replit, Vercel, Claude로 자기 프런트엔드를 만들고 싶어 했습니다. 이들에게는 좌석보다 더 많은 데이터가 필요했습니다. |
| 한 일 | ZoomInfo는 모듈형 데이터·맥락과 기본 연동을 제공하고, 좌석을 대량 크레딧 묶음으로 바꿀 수 있게 했습니다. 3분기 첫 달에는 소규모 전담팀이 하이브리드 요금을 선별 적용했습니다. |
| 결과 | 일부 고객은 같은 금액으로, 일부는 약간 줄여 갱신했습니다. 회사는 시간이 지나며 사용량이 늘기를 기대합니다. 새 경로 전체 사용량은 전 분기 대비 두 배였습니다. |
| 연결 | Headless Data Access와 Seat-to-Credit 메커니즘의 사례입니다. |
기술 디테일: 연락처 마스터와 크레딧 호출 관리
아래는 콜의 사례를 사는 쪽에서 실제로 돌릴 때 필요한 것을 정리한 내용입니다. 원문에 없는 설계이며, 수치는 모두 가상 예시입니다.
연락처 마스터(Master Data Foundation)를 만들려면 원천 시스템마다 연락처를 뽑되 원천 ID를 버리지 않습니다. 합친 뒤에도 “이 값이 어느 시스템에서 왔나”를 되짚어야 하기 때문입니다. 매칭은 결정 규칙과 확률 판단을 나눕니다. 업무 이메일이 같으면 같은 사람으로 확정합니다. 이름과 회사 도메인만 같으면 후보로 두고, LLM에게 두 레코드를 보여 같은 사람인지 판단하게 합니다. 이때 같은 쌍을 세 번 물어 답이 갈리면 사람 검토 큐로 보냅니다. temperature는 0으로 두고, 출력은 {"same_person": true, "confidence": 0.0, "evidence": ["같은 도메인", "직함 일치"]}처럼 구조화해 받습니다. evidence가 있어야 검토자가 이유를 보고 승인합니다. 처음 2주는 사람이 확정한 200쌍(가상 예시)을 정답지로 두고 LLM 판단과 비교해, 일치율이 낮은 규칙은 자동 병합에서 뺍니다.
golden record(필드마다 가장 믿을 값을 골라 만든 최종 레코드)는 아래처럼 필드별 출처와 확인 날짜를 함께 저장합니다. 외부 데이터로 빈 값을 채웠다면 source에 벤더 이름을 남깁니다.
{
"contact_id": "MDM-000123",
"company_id": "ACCT-0451",
"full_name": "string",
"work_email": {"value": "string", "source": "crm_a", "verified_at": "2026-11-01"},
"title": {"value": "string", "source": "vendor", "verified_at": "2026-10-20"},
"phone": {"value": "string", "source": "ma_tool", "verified_at": "2026-09-15"},
"source_ids": [{"system": "crm_a", "id": "003XX"}, {"system": "ma_tool", "id": "L-889"}],
"match_method": "email_exact | name_domain_llm | manual",
"match_confidence": 0.0,
"status": "active | left_company | unknown"
}
필드별 우선 원천은 미리 정합니다(가상 예시). 이메일은 최근 발송 성공 기록이 있는 원천, 직함은 확인 날짜가 가장 최근인 원천, 동의 여부는 마케팅 자동화 시스템을 우선합니다. 실패하는 경우는 대체로 셋입니다. 공용 메일(info@)을 사람으로 합치는 경우, 회사 인수로 도메인이 바뀐 경우, 같은 사람이 이직해 두 회사에 남는 경우입니다. 공용 메일은 매칭에서 빼고, 도메인 변경은 회사 매핑 표로 처리하고, 이직은 status를 바꿔 기록합니다.
크레딧 계약(Seat-to-Credit)에서 에이전트 호출을 관리하려면 모든 MCP·API 호출을 한 로그에 남깁니다. 필드는 agent_id, tool, query_hash, credits_used, called_at, result_count 정도면 충분합니다. 같은 회사를 30일 안에 다시 조회하면 캐시를 쓰고, 에이전트마다 월 크레딧 상한을 둡니다(가상 예시: 전체 한도의 80%에서 알림). 처음 4주는 읽기 전용으로 연결하고, CRM에 쓰는 권한은 사람 승인 단계를 붙인 뒤 엽니다. 이 로그가 있어야 갱신 협상 때 “좌석 몇 개를 크레딧 얼마로 바꿀지”를 실제 사용량으로 계산할 수 있습니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 맡는 일 |
|---|---|
| RevOps 리드 (책임자) | 원천 시스템 목록, 매칭 규칙 승인, 6주차 진행 판정 |
| CRM 관리자 | 연락처 추출, 시범 병합, 운영 CRM 반영 |
| 데이터 스튜어드 | 샘플 검수, 사람 검토 큐 처리 |
| 보안·IT | MCP·API 연결 권한, 호출 로그 점검 |
| 구매 | 크레딧 사용량 추정, 데이터 벤더 갱신 조건 |
시작 전 준비물은 네 가지입니다. 연락처를 들고 있는 시스템 목록과 시스템별 레코드 수, 최근 1년 이메일 반송 기록, 현재 데이터 벤더 계약서(좌석 수·갱신일·크레딧 조건), 에이전트 시범 과제 목록입니다.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 원천 시스템 목록화, 연락처 추출 | 원천별 레코드 수 표 |
| 2주 | 매칭 규칙 초안, 샘플 500건 검수 | 규칙 문서, 중복률 추정 |
| 3주 | 한 사업부 시범 병합, 검토 큐 운영 | golden record 시범본 |
| 4주 | 운영 CRM 반영, 읽기 전용 MCP 연결 | 에이전트가 읽는 마스터 |
| 5주 | 호출 로그 점검, 크레딧 사용량 추정 | 월 사용량 예측표 |
| 6주 | 진행 판정, 갱신 조건 정리 | 확대 여부 결정 |
현업 확인 질문은 이렇게 씁니다. “같은 고객사 담당자에게 두 팀이 동시에 연락한 일이 최근 분기에 몇 번 있었나?”, “에이전트가 쓴 제안서가 틀린 담당자에게 간 적이 있나?”, “벤더 화면에 매일 들어가는 사람은 좌석 수의 몇 %인가?” 진행 판정 기준(가상 예시)은 세 가지입니다. 시범 사업부에서 중복 연락처가 절반 이하로 줄었는지, 사람 검토 큐가 하루 처리량 안에 들어오는지, 크레딧 예측 사용량이 현재 좌석 비용 안에 들어오는지 봅니다.
AX 적용 제언입니다. 국내 대기업은 계열사·사업부마다 CRM과 마케팅 시스템을 따로 둔 경우가 많아, 이 Fortune 500 사례와 같은 지점에서 영업 AI 과제가 멈추기 쉽습니다. 영업 에이전트 과제를 승인하기 전에 연락처 마스터 정비를 선행 과제로 묶고, 책임자는 IT가 아니라 RevOps나 영업기획에 두는 편이 맞습니다. 데이터 벤더 갱신이 6개월 안에 있다면 지금부터 호출 로그를 쌓아 좌석과 크레딧을 섞는 계약을 실제 사용량으로 협상할 근거를 만듭니다. 이 순서는 영업 데이터뿐 아니라 협력사·자재 마스터처럼 여러 시스템이 같은 실체를 따로 들고 있는 영역에도 그대로 옮길 수 있습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표 | ZoomInfo 2026년 3분기 실적 콜(2026.11.4), Motley Fool 녹취(2026.11.5) |
| 화자 | Henry Schuck(창업자·CEO), Graham O’Brien(CFO) |
| 매출 | 3.09억 달러, 전년 대비 3% 감소, 가이던스 상단 초과 |
| 조정 영업이익 | 1.19억 달러, 이익률 39%(1.5%p 개선) |
| 업마켓 | 전체 ACV의 77%(3년간 14%p 이동), 업마켓 ACV는 전년과 같은 수준 |
| NRR | 88%(전 분기 89%) |
| 소프트웨어 업종 비중 | 2021년 45%에서 약 30% |
| 새 경로 | MCP 서버·CLI·새 API, 고객 1만 곳 이상, 사용량 전 분기 대비 2배 |
| 요금 | 3분기 하이브리드 요금 도입: data credits 고정 약정 + 첫해 AI credits |
| 고객 사례 | Fortune 500 산업자동화·항공 복합기업 마스터 데이터 작업, 소셜미디어 관리 플랫폼 다년 계약, Tishman Speyer·Audacy·Garner Health·SurveyMonkey |
| 인수 | Workbounce(semantic knowledge layer), DoubleO.ai(Agent Teams) |
| 연동 | ClickUp·n8n 기본 연동, Salesforce Hunter 핵심 데이터 파트너 |
| 기타 | 이탈 뒤 돌아온 고객 1~3분기 누적 10% 이상 증가, 100만 달러 이상 고객 수·ACV 사상 최대 |
| 4분기 가이던스 | 매출 2.94억~2.97억 달러 |
| 연간 가이던스 | 매출 12.235억~12.265억 달러로 상향 |
| 보도자료 수치 | 기업 1억 곳 이상, 연락처 5억 건 이상, ACV 10만 달러 이상 고객 1,851곳(전년 대비 2% 감소), 이 고객군 ACV 4% 증가 |
핵심 개념
- ACV (annual contract value)
- 계약 금액을 1년 단위로 나눈 값입니다. ZoomInfo는 업마켓·다운마켓 매출 구성을 이 값으로 설명합니다.
- NRR (net revenue retention)
- 1년 전 고객이 지금 내는 금액을 1년 전 금액과 비교한 비율입니다. 100%보다 낮으면 해지·축소가 확장보다 큽니다.
- GTM (go-to-market)
- 영업·마케팅·운영이 고객을 찾고 계약까지 끌고 가는 일 전체입니다. ZoomInfo의 나스닥 티커이기도 합니다.
- GTM1
- 영업·마케팅·운영이 같은 데이터와 맥락을 함께 쓰고 에이전트가 그 위에서 일하게 하는 ZoomInfo의 새 플랫폼입니다. 4분기 출시 예정이고 수십 곳이 먼저 쓰고 있습니다.
- RevOps
- 영업·마케팅·고객 성공의 도구, 데이터, 프로세스를 함께 운영하는 조직입니다.
- entity resolution
- 여러 시스템에 흩어진 레코드 가운데 같은 사람이나 회사를 찾아 하나로 묶는 작업입니다.
- vibe-coded
- AI 코딩 도구로 빠르게 만든 앱을 가리키는 말입니다. 콜에서는 신뢰성이 낮은 저가 도구를 가리킬 때 쓰였습니다.
내 메모
TODO: 내 생각 추가
원문은 The Motley Fool이 녹취한 「ZoomInfo (GTM) Q3 2026 Earnings Call Transcript」(2026.11.5, 콜은 11.4)입니다. fool.com 원문은 열리지 않아 같은 녹취를 Yahoo Finance에 재게재한 판을 읽었고, 녹취 안의 CFO 이름 표기가 엇갈려 회사 공시 기준인 Graham O’Brien으로 적었습니다. 원문 사례 표의 보도자료 수치와 Agent Teams 설명은 ZoomInfo의 3분기 실적 보도자료(SEC 8-K 첨부, 2026.11.4)에서. 요약, 핵심 메커니즘의 콜 내용, 통념과 다른 주장, 사례, 원문 사례 표는 콜 발언을 AX Review가 다시 정리했습니다. 기술 디테일과 현업 실행 디테일, golden record 스키마, 6주 일정, 판정 기준, 인포그래픽은 새로 작성했으며 표시한 가상 예시는 AX Review가 만든 것입니다. 전체 내용은 원문에서 볼 수 있습니다.