MCP로 AI 에이전트를 HubSpot에 연결하기: 퍼스트파티 서버가 해결하지 못하는 것

문제: 연결은 해결하지만 의미는 해결하지 않는 12개 도구

HubSpot은 2026년 4월 13일 원격 MCP 서버를 일반 출시했습니다. Claude, ChatGPT, Cursor 또는 모든 MCP 호환 AI 클라이언트를 OAuth 2.1 with PKCE로 HubSpot 포털에 연결하며, mcp.hubspot.com 엔드포인트에서 인증합니다. 모든 허브와 티어에서 무료입니다. 표준 CRM 객체——연락처, 회사, 거래, 티켓, 제품, 라인 아이템, 인보이스, 견적, 주문, 카트, 구독, 세그먼트——및 인게이지먼트 이력(통화, 이메일, 미팅, 노트, 태스크)에 대한 읽기 및 쓰기 액세스를 제공하는 12개 도구를 노출합니다. 캠페인 지표, 랜딩 페이지, 웹사이트 페이지, 블로그 게시물도 읽습니다. HubSpot 공식 문서는 모든 액션이 연결된 사용자의 기존 HubSpot 권한을 존중함을 확인합니다——백도어가 아닙니다.

이것은 데모가 아닌 실제 제품입니다. Claude에게 "'Decision maker bought in' 단계에 있고 거래 가치가 $1,000 이상인 모든 열린 거래를 요약해줘"라고 묻는 영업 담당자에게 퍼스트파티 서버가 처리합니다. HubSpot은 또한 Claude 원클릭 커넥터(2026년 7월 16일)를 출시하여, 유료 Anthropic 구독을 가진 모든 HubSpot 사용자가 코드 작성 없이 CRM을 Claude의 채팅 인터페이스에 연결할 수 있게 했습니다. 설정은 몇 분 걸립니다.

문제는 퍼스트파티 서버가 무엇을 잘못하는지가 아닙니다. 문제는 전혀 하지 않는 것입니다. Daeda Tech의 분석(2026년 4월 14일, 5월 22일 업데이트)이 격차를 직접 지적합니다: "격차는 공식 MCP가 무엇을 잘못하는지에 대한 것이 아니라, 전혀 하지 않는 것에 대한 것입니다." 이것들은 버그가 아닙니다. 제품 범위 결정입니다. HubSpot은 견고하고 안전한 출발점을 출시했습니다. 하지만 커스텀 객체, 워크플로우 자동화 또는 멀티포털 운영을 실행하는 미드마켓 B2B 기업에게, 퍼스트파티 서버는 쉬운 절반을 커버하고 어려운 절반을 커스텀 모듈에 남깁니다.

6개의 기능 격차

Daeda Tech와 Scalekit의 비교(2026년 6월 2일)가 프로덕션 사용에서의 격차를 문서화합니다. 이들은 NetSuite MCP 모듈 분석에 나타나는 것과 동일한 구조적 패턴에 매핑됩니다: 벤더의 퍼스트파티 커넥터는 연결 문제를 해결합니다. 의미론적 계층 문제는 해결하지 않습니다——데이터가 말하는 것과 비즈니스가 의미하는 것 사이의 격차입니다.

1. 커스텀 객체 없음

원격 MCP 서버는 표준 CRM 객체 타입만 노출합니다. 포털이 갱신, 파트너십, 제품 사용 추적 또는 산업별 데이터 모델을 위해 커스텀 객체에 의존하는 경우, 공식 MCP는 그것을 보거나 만질 수 없습니다. Scalekit은 확인합니다: "엔터프라이즈 HubSpot 계정은 거의 바닐라가 아닙니다——프로페셔널 서비스 펌, 헬스케어 테크 기업, 리뉴 옵스 팀은 routinely 커스텀 객체 위에 핵심 데이터 모델을 구축합니다." 격차는 문서화가 부족합니다: "이것은 커스텀 객체입니다"라는 에러 코드가 없습니다. 에이전트는 단순히 데이터에 액세스할 수 없습니다. HubSpot 커뮤니티 포럼은 2026년 3월에 이것을 문서화했습니다——개발자들은 문서가 아닌 트러블슈팅을 통해 발견했습니다. 유일한 해결책은 직접 API이며, 이는 에이전트가 그것에 도달하기 위해 커스텀 모듈이 필요함을 의미합니다.

2. 검토 가능한 쓰기 계획 없음

퍼스트파티 서버는 manage_crm_objects를 통해 즉시 쓰기를 실행합니다. 드래프트, 배치 검토, 다단계 변경에 대한 배치로서의 실행취소가 없습니다. Claude에게 "'Demo' 단계의 모든 거래를 'Proposal Sent'로 이동해줘"라고 요청하는 영업 담당자는 즉각적이고 되돌릴 수 없는 변경을 얻습니다. 커밋 전에 배치 파이프라인 변경을 검토해야 하는 RevOps 팀에게——잘못된 단계 이동은 예측 보고를 왜곡하고 다운스트림 워크플로우 자동화를 트리거하기 때문에——검토 게이트의 부재는 프로덕션 리스크입니다. Daeda AI는 이를 "Human Review가 있는 Write Plans"라고 부릅니다——AI가 구조화된 계획을 작성하고, 인간이 검토하고 승인하며, 계획이 실행됩니다. 퍼스트파티 서버에는 동등한 것이 없습니다.

3. 연결당 하나의 포털

OAuth 2.1은 한 사용자를 한 포털에 인증합니다. 5개의 HubSpot 포털을 관리하는 에이전시나 컨설턴트는 5개의 개별 OAuth 연결, 5개의 토큰 갱신 주기, AI 클라이언트에서 5개의 컨텍스트 스위치가 필요합니다. 워크스페이스 모델이 없습니다. 여러 클라이언트 HubSpot 인스턴스를 관리하는 B2B 서비스 기업에게, 이것은 확장되지 않는 운영 제약입니다. 커스텀 모듈은 멀티포털 라우팅을 내부에서 처리할 수 있습니다——에이전트는 get_deals(portal_id, ...)를 호출하고, 모듈이 올바른 자격 증명, 토큰, 엔드포인트를 해결합니다. 퍼스트파티 서버는 할 수 없습니다.

4. 시스템 수준 설계 없음

퍼스트파티 서버는 레코드 수준만입니다. 파이프라인, 라이프사이클 단계, 워크플로우 로직, 리스트 기준을 대화형으로 설계할 수 없습니다. 에이전트에게 "'Qualified'와 'Proposal Sent' 사이에 'Procurement Review'라는 새 파이프라인 단계를 만들고 $50K 이상의 모든 거래를 그곳으로 이동해줘"라고 요청하고 싶은 RevOps 리더는 MCP 서버를 통해 할 수 없습니다. HubSpot 직접 API는 Workflow Automation API v4와 파이프라인 관리를 지원합니다——하지만 MCP 서버는 그 엔드포인트를 노출하지 않습니다. 시스템 설계는 직접 API 작업이며, 에이전트에서 도달하려면 커스텀 모듈이 필요함을 의미합니다.

5. 모든 쿼리가 API에 라이브 히트

퍼스트파티 서버에는 로컬 데이터 레이어가 없습니다. 각 도구 호출은 HubSpot 서버로 왕복합니다. Daeda Tech은 주목합니다: "대규모 분석에서는 레이턴시와 페이지네이션이 누적됩니다." search_crm_objects 도구는 페이지당 최대 200개 결과를 반환합니다. 수천 건의 레코드에 걸친 크로스 객체 분석은 수십 번의 API 호출을 페이지네이션하는 것을 의미하며, 각각 레이턴시를 추가하고 각각 레이트 제한의 대상이 됩니다. 모든 거래, 관련 연락처, 인게이지먼트 이력, 회사 속성을 추출하는 분기 파이프라인 리뷰에서, 라이브 API 전용 모델은 다음 페이지를 기다리기 위해 생각 중간에 멈추는 느린 에이전트를 생성합니다. 관리되는 데이터 레이어가 있는 커스텀 모듈은 포털 데이터를 로컬 데이터베이스에 동기화하고 크로스 객체 쿼리를 몇 초 만에 실행합니다——질문당 API 왕복 없음, 생각 중간의 페이지네이션 없음.

6. 민감 데이터 제약

HubSpot 계정에 "Sensitive Data" 토글이 활성화된 경우——헬스케어와 금융 서비스에서 흔함, 개인 건강 정보를 처리하는 계정에서 필수——MCP 서버는 모든 인게이지먼트 객체를 차단합니다: 통화, 이메일, 미팅, 노트, 태스크. CRM 객체는 여전히 액세스 가능하지만, 연락처나 거래에 컨텍스트를 부여하는 인게이지먼트 이력이 사라집니다. 공식 문서는 이를 직접 확인합니다: "Sensitive Data가 활성화된 경우, 활동 객체(통화, 이메일, 미팅, 노트, 태스크)는 MCP 서버 액세스에서 차단됩니다." Claude 커넥터 설정 가이드는 동일한 제약을 반복합니다. 특정 스코프를 가진 직접 CRM API는 민감 데이터 속성에 액세스할 수 있습니다——하지만 MCP 서버는 할 수 없습니다. 헬스케어 B2B 기업이 에이전트에게 고객 레코드의 통화 노트를 읽어야 하는 경우, 권한 레이어가 아닌 프로토콜 레이어에서 차단됩니다.

인증: 헤드리스 에이전트 문제

원격 MCP 서버는 OAuth 2.1 with PKCE를 배타적으로 강제합니다. 프라이빗 앱 토큰 경로가 없습니다. Scalekit의 분석이 결과를 지적합니다: "직접 API는 OAuth 2.0과 프라이빗 앱 액세스 토큰을 모두 지원합니다——후자는 브라우저 기반 동의 플로우를 완료할 수 없는 헤드리스, 스케줄된 또는 백그라운드 에이전트에게 유일하게 실행 가능한 인증 방법입니다."

PKCE는 브라우저 기반 동의 플로우가 필요합니다——인간이 리다이렉트 URL에서 "Allow"를 클릭하고, HubSpot이 인증 코드를 발급하고, 클라이언트가 그것을 토큰으로 교환합니다. 갱신 토큰은 일회용이며, 매번 갱신 시마다 로테이션됩니다. 이것은 인터랙티브 사용에 안전합니다. 새벽 2시에 실행되어 야간 거래 변경을 데이터 웨어하우스에 동기화하는 백그라운드 에이전트나, 매시간 지연된 거래를 확인하고 후속 태스크를 생성하는 스케줄된 워크플로우에는 실용적이지 않습니다. 토큰이 만료될 때 "Allow"를 클릭할 사람이 없습니다.

HubSpot 직접 API는 프라이빗 앱 액세스 토큰을 지원합니다——스코프가 있는 베어러 토큰으로, 리다이렉트, 브라우저, 동의 플로우가 없습니다. 이것이 헤드리스 에이전트와 스케줄된 워크플로우가 실제로 필요로 하는 것입니다. 커스텀 MCP 모듈은 무인 작업에는 프라이빗 앱 토큰으로, 인터랙티브 에이전트 세션에는 OAuth 2.1로 인증할 수 있습니다——모듈이 인증 경로를 내부에서 처리하고, 에이전트는 get_deals를 호출하며 어떤 자격 증명이 사용 중인지 알지도 못하고 신경 쓰지도 않습니다.

레이트 제한은 이것을 악화시킵니다. HubSpot의 API 사용 가이드라인은 Free/Starter의 프라이빗 앱에 10초당 100 요청, Professional/Enterprise에 10초당 190을 설정합니다. 동일한 제한이 MCP 서버 요청에 적용됩니다——그것들은 동일한 CRM Search API에 대해 실행됩니다. Free/Starter 포털에 대해 30개의 도구 호출을 병렬로 발사하는 에이전트는 3분의 1을 실패합니다. 퍼스트파티 서버는 MCP 클라이언트가 구현하는 것 이상의 구조화된 재시도 가이던스 없이 429를 반환합니다. 커스텀 모듈은 도구별 레이트 제한을 강제합니다——각 도구는 자체 제한을 선언하고, 백본이 스로틀하며, 에이전트는 크래시가 아닌 Retry-After 헤더가 있는 구조화된 429를 받습니다.

커스텀 MCP 모듈이 제공하는 것

모듈 패턴은 MCP 모듈 코드 표준을 따릅니다: 각 도구는 타입화된 입력 스키마, 타입화된 출력 스키마, 레이트 제한, 감사 로그, 에러 컨트랙트를 가집니다. 에이전트는 원시 엔드포인트에 대한 자유 형식 API 호출이 아닌, 이름과 구조화된 인수로 도구를 호출합니다.

HubSpot의 경우, 커스텀 모듈은 6개의 격차를 채웁니다:

커스텀 객체. 모듈은 커스텀 객체 스키마에 대한 타입화된 작업을 노출합니다——get_renewal_record(renewal_id), search_custom_objects(object_type, filters), update_partnership_status(partnership_id, status). 각 도구의 스키마는 커스텀 객체의 속성, 연관, 비즈니스 의미를 인코딩합니다. 에이전트는 해결책이 아닌 모듈을 통해 커스텀 객체 데이터에 도달합니다.

검토 가능한 쓰기 계획. 모듈은 다단계 변경을 위한 구조화된 계획을 작성합니다——"47개 거래를 'Demo'에서 'Proposal Sent'로 이동하고, 그중 12개의 클로즈 날짜를 업데이트하고, 거래 소유자의 후속 태스크를 생성"——실행 전에 인간 검토자에게 라우팅합니다. 계획은 자유 형식 텍스트 블롭이 아닌 타입화된 객체입니다. 검토자는 승인, 거부 또는 수정합니다. 모듈은 승인된 계획만 실행하고 각 변경을 로그에 기록합니다.

멀티포털 라우팅. 모듈은 각 도구 호출에서 portal_id 매개변수를 수락하고, 올바른 자격 증명, 토큰 저장소, 엔드포인트를 내부에서 해결합니다. 에이전트는 OAuth 세션을 관리하지 않습니다. 단일 에이전트 호출이 한 패스에서 5개 포털에 걸쳐 거래 데이터를 쿼리할 수 있습니다.

시스템 수준 설계. 모듈은 파이프라인 관리, 라이프사이클 단계 구성, 워크플로우 자동화를 타입화된 도구로 노출합니다——create_pipeline_stage(pipeline_id, label, display_order, probability), update_lifecycle_stage(contact_id, stage), enroll_in_workflow(contact_id, workflow_id). 이것들은 퍼스트파티 서버가 노출하지 않는 HubSpot Automation API v4와 파이프라인 관리 엔드포인트에 매핑됩니다.

관리되는 데이터 레이어. 모듈은 스케줄에 따라 포털 데이터를 로컬 데이터베이스에 동기화합니다——거래, 연락처, 회사, 인게이지먼트, 커스텀 객체——로컬 사본에 대해 크로스 객체 쿼리를 실행합니다. 에이전트가 "'Proposal Sent'에 14일 이상 있고 지난 7일간 인게이지먼트가 없는 모든 거래를 보여줘"라고 물으면, 모듈은 분 단위의 페이지네이션 API 호출이 아닌 몇 초 만에 답을 반환합니다.

민감 데이터 액세스. 모듈은 민감 속성을 읽는 데 필요한 특정 스코프로 프라이빗 앱 토큰을 통해 인증합니다——MCP 서버의 차단된 경로가 아닙니다. 에이전트는 헬스케어 고객 레코드의 통화 노트를 읽습니다. 모듈이 올바른 스코프로 직접 API를 사용하기 때문이며, 퍼스트파티 서버의 전면 차단이 아닙니다.

의미론적 계층: 퍼스트파티 서버가 인코딩하지 않는 것

패턴은 NetSuite 분석과 동일합니다. 퍼스트파티 커넥터는 AI에게 레코드에 대한 액세스를 제공합니다. 커스텀 MCP 모듈은 AI에게 그 레코드가 무엇을 의미하는지에 대한 이해를 제공합니다. 이것이 의미론적 계층입니다——타입화된 스키마가 에이전트에게 어떤 거래 단계가 이 회사의 예측에 대한 "won revenue"에 매핑되는지, 어떤 라이프사이클 단계가 이 마케팅 팀의 "qualified lead" SLA를 구성하는지, 어떤 커스텀 객체 속성이 이 고객 성공 팀의 이탈 모델에 대한 "renewal value"인지 알려줍니다.

파이프라인 분석을 생각해 보세요. 퍼스트파티 서버는 필터 그룹과 함께 search_crm_objects를 노출합니다. 에이전트는 주어진 단계의 모든 거래를 찾을 수 있습니다. 그것이 에이전트에게 알릴 수 없는 것은, 이 회사의 경우 Sales 파이프라인의 "Closed Won" 단계는 수익에 계산되지만, Renewals 파이프라인의 동일한 단계는 그렇지 않다는 것입니다——갱신은 별도의 수익 라인 아래에 계산됩니다. 이 구분을 모르는 에이전트는 이중 계산된 예측을 생성합니다. 모듈의 타입화된 스키마는 구분을 인코딩합니다: get_revenue_pipeline_summary(period, pipeline_ids=["sales"], exclude_pipeline_ids=["renewals"]). 에이전트는 정확한 답을 받습니다. 질문하는 것이 비즈니스가 의미하는 질문이기 때문입니다.

또는 라이프사이클 단계를 생각해 보세요. 퍼스트파티 서버는 연락처의 라이프사이클 단계를 읽을 수 있습니다. 그것이 에이전트에게 알릴 수 없는 것은, 이 회사의 경우 연락처가 회사 규모 필드에 50명 이상을 입력한 양식을 제출한 후에만 "Marketing Qualified Lead"가 된다는 것입니다——이것은 라이프사이클 단계 정의가 아닌 커스텀 워크플로우에 존재하는 규칙입니다. 모듈은 도구 스키마에 규칙을 인코딩합니다: get_qualified_leads(since_date, min_company_size=50, source="form_submission"). 규칙은 스키마에 있지, 프롬프트에 있지 않습니다.

왜 이것이 일반화되는가

HubSpot 패턴——표준 객체를 커버하는 12개 도구를 가진 퍼스트파티 MCP 서버, 벤더가 제공하지 않는 의미론적 계층 격차, 헤드리스 에이전트를 차단하는 인증 제약, 단순 병렬 호출을 깨는 레이트 제한——는 CRM과 ERP 환경 전체에 나타나는 동일한 구조입니다:

• NetSuite에는 정확도 격차가 있는 퍼스트파티 AI Connector Service가 있습니다——Oracle 자체 FAQ가 경고합니다 "AI는 환각을 일으킬 수 있습니다. 항상 소스 데이터에 대해 결과를 검증하세요." 의미 격차는 어떤 GL 계정이 이 비즈니스의 "revenue"를 구성하는지입니다. NetSuite MCP 모듈 분석이 이를 깊이 다룹니다.
• Shopify에는 퍼스트파티 Storefront MCP와 Google과의 Universal Commerce Protocol이 있지만, B2B 경로——고객 티어 가격, 대량 RFQ 견적, NetSuite에 대한 재고 보류, 크로스 채널 주문 귀속——는 퍼스트파티 표면에 없습니다. Shopify 커넥터 분석이 이를 다룹니다.

Anthropic 2026 State of AI Agents Report(500+ 기술 리더, Novo Nordisk, Doctolib, L'Oréal, Shopify에서의 실제 구현)는 기존 시스템과의 통합을 에이전트 도입의 1번 장벽으로 식별합니다——46%의 조직이 그것을 인용하며, 데이터 액세스(42%), 보안(40%), 모델 인텔리전스를 능가합니다. 47%가 하이브리드 build-and-buy 접근을 사용합니다: 완전히 사전 구축된 것이 아니라, 모두 사내가 아니라, 커스텀 코드로 확장하는 플랫폼입니다. 퍼스트파티 MCP 서버는 "buy"의 절반입니다. 커스텀 모듈은 "build"의 절반입니다. 2026년에 프로덕션 에이전트를 출시하는 팀은 둘 다 하는 팀입니다——퍼스트파티 서버가 커버하는 것, 커스텀 모듈이 커버하지 않는 것입니다.

HubSpot은 견고한 퍼스트파티 서버를 출시했습니다. 표준 객체 조회와 단순 업데이트에는 충분합니다. 커스텀 객체, 검토 가능한 쓰기, 헤드리스 인증, 멀티포털 운영, 시스템 수준 설계, 민감 데이터 액세스에는, 커스텀 모듈이 프로덕션 경로입니다. MCP 모듈 코드 표준이 구조를 정의합니다. HubSpot 커넥터는 CRM 케이스의 참조 구현입니다——12개 도구로 시작하고, 의미론적 계층으로 프로덕션에 도달하는 케이스입니다.

---

5개의 클라이언트 포털에 걸쳐 HubSpot을 실행하고, 갱신과 파트너십을 위한 커스텀 객체, 파이프라인 관리를 위한 워크플로우 자동화, 매출 수익과 갱신 수익의 올바른 구분에 의존하는 분기 예측을 가진 B2B 서비스 기업은, 커스텀 객체 레코드를 해결하고, 배치 파이프라인 변경을 위한 검토 가능한 쓰기 계획을 작성하고, 스케줄된 동기화를 위해 헤드리스로 인증하고, 단일 세션에서 포털에 걸쳐 라우팅하고, 수익 단계 구분을 타입화된 스키마에 인코딩하는 에이전트를 얻습니다——각 도구 호출이 로그에 기록되고, 각 예외가 인간 검토자에게 라우팅됩니다. 그 빌드는 4단계 메서드의 Phase 2-3이며, 일반적으로 5-8주 내에 라이브됩니다.

스코프된 빌드를 요청하세요. 1주 Discovery. 시스템 인벤토리, 워크플로우 맵, 고정 스코프를 얻습니다——저희와 빌드하든 아니든.