에이전트 대응 제품 카탈로그란 무엇인가?

"에이전트 대응"이란 실제로 무엇을 뜻하는가?

제품 카탈로그가 에이전트 대응이라는 말은, 사람이 브라우저를 조작하지 않아도 기계가 그것을 찾아내고, 읽고, 질의하고, 정확하게 인용할 수 있다는 뜻이다.

이것은 "우리 웹사이트는 잘 만들어져 있다"보다 훨씬 까다로운 시험이며, 페이지 속도 리포트에는 결코 잡히지 않는 이유들 때문에 통과하지 못한다. 검색 순위도 좋고 전환도 잘 나오고 보기에도 흠잡을 데 없는 카탈로그가, 정작 AI 어시스턴트가 실제로 사용하는 클라이언트에는 빈 문서를 돌려주고 있을 수 있다. 이 격차는 겉모습의 문제가 아니라 구조의 문제다.

무게도 분기마다 커지고 있다. Forrester는 2026년 1월 자사 구매자 여정 조사를 정리하면서, 기업 구매 담당자의 94%가 이제 구매 과정에서 AI를 사용하며, 생성형 AI나 대화형 검색을 다른 무엇보다 의미 있는 정보원으로 꼽은 구매자가 두 배 많았다고 보고했다. 공급사 웹사이트도, 제품 전문가도, 영업 담당자도 그보다 뒤였다. 어시스턴트가 당신의 제품에 대해 읊는 사양이 곧 당신의 구매자가 믿는 사양이 되어 가고 있다.

이 주제를 다루는 대부분의 글이 혼란스러운 이유는 "에이전트 대응"을 하나의 무엇으로 취급하기 때문이다. 그것은 네 가지이고, 소비자도 넷으로 갈린다.

어떤 어시스턴트가 어떤 접점을 소비하는가?

1. 구조화 데이터를 담은 서버 렌더링 페이지

아무것도 설정하지 않은 어시스턴트 사용자에게 닿는 접점은 이것 하나뿐이다.

여기서 가장 중요한 기술적 사실은 하나다. AI 크롤러는 당신의 JavaScript를 실행하지 않는다. Vercel의 크롤러 분석 — 한 달 동안의 GPTBot 요청 5억 6,900만 건과 Claude 요청 3억 7,000만 건 — 은 이 크롤러들이 JavaScript 파일을 내려받기는 하지만(각각 요청의 11.50%와 23.84%) 그것을 실행하지는 않는다는 사실을 확인했고, OpenAI와 Anthropic, Meta, ByteDance, Perplexity를 지목하며 "현재 주요 AI 크롤러 가운데 JavaScript를 렌더링하는 곳은 없다"고 결론지었다. 2026년 내내 이어진 독립적인 재검증도 같은 판정에 이르렀다. 당신의 파라메트릭 표나 재고 표시, 문서 목록이 클라이언트 측에서 주입된다면, 이 클라이언트들에게 그것은 존재하지 않는다. Googlebot은 JavaScript를 렌더링하며 여전히 예외로 남아 있고, Google에서 자사 노출을 확인한 팀이 아무 문제 없다고 잘못 결론짓는 이유가 정확히 여기에 있다.

나머지에 대해서는 Google 자신의 안내가 반갑도록 단도직입적이다. AI Overviews나 AI Mode에 등장하려면 "페이지가 색인되어 있고 Google 검색에 스니펫과 함께 표시될 자격이 있어야" 하며, 그 밖의 추가 기술 요건도, AI 전용 스키마도, 특별한 파일도 없다. 그럼에도 구조화 데이터가 제 몫을 하는 이유는, 어느 숫자가 정격 전류이고 어느 숫자가 피크값인지에 대한 모호함을 없애 주기 때문이다. 다만 그것은 중의성을 걷어내는 도구이지 마법의 방아쇠가 아니다.

마지막으로, 크롤러 계층에는 대부분의 카탈로그가 무시하는 정책 차원이 있다. OpenAI는 서로 다른 세 개의 에이전트를 문서화한다. 기반 모델 학습용 GPTBot, ChatGPT 검색에 사이트를 노출하기 위한 OAI-SearchBot, 그리고 사용자가 직접 촉발한 조회를 담당하는 ChatGPT-User다. Anthropic도 같은 방식으로 ClaudeBot과 Claude-User, Claude-SearchBot을 문서화한다. 이들은 robots.txt에서 서로 독립적인 항목이다. 학습을 겨냥해 일괄 차단을 걸면, 당신을 인용해 줄 수 있었던 리트리벌 크롤러까지 함께 꺼진다.

2. 마크다운과 클린 텍스트 뷰

2026년에 가장 과장되게 이야기된 접점이 이것이므로, 여기서는 정확히 짚고 가자.

"Accept: text/markdown으로 보내 주면 그쪽을 우선하겠다"고 밝힌 콘텐츠 협상 규약을 공개한 주류 소비자용 어시스턴트는 하나도 없다. llms.txt 관행은 기술적으로 앞뒤가 맞고 개발자 문서 사이트에서는 실제로 자리를 잡았지만, Google은 자사 AI 기능에 노출되기 위해 AI용 텍스트 파일이 필요하지 않다고 명시하고 있으며, 2026년까지의 도입 조사에서도 OpenAI와 Google, Anthropic의 크롤러가 이 파일을 유의미한 규모로 요청하지 않는다는 결과가 나왔다.

진짜로 참인 부분은 그보다 좁지만, 여전히 해 둘 만하다. 내비게이션과 스크립트가 잔뜩 붙은 페이지에서 뽑아낸 텍스트는 산문으로 제공된 텍스트보다 잡음이 많으므로, 깔끔한 뷰가 추출 과정을 더 잘 견딘다. 그리고 바로 그 깔끔한 렌더링이야말로 당신의 MCP 도구가 페이로드로 돌려주어야 할 것이다. 마크다운 뷰를 성장 전술이 아니라 정본 레코드를 재사용해 만든 부산물로 두면, 실망할 일은 없다.

3. 밀어 넣는 제품 피드

대부분의 로드맵 순서를 뒤바꾸는 사실은 이것이다. ChatGPT의 쇼핑 영역은 크롤링이 아니라 판매자가 밀어 넣는 데이터로 채워진다. 공개된 피드 명세에 따르면 판매자는 TSV나 CSV, XML, JSON을 상호 합의된 허용 목록 엔드포인트로 암호화된 HTTPS를 통해 전달하고, 시스템은 15분마다 갱신을 받아들인다. Perplexity의 판매자 프로그램도 형태는 같다. 지정된 형식의 CSV 또는 XML 파일로 제품 데이터를 제공하되, 전달하는 쪽은 판매자다. 온페이지 최적화를 아무리 쌓아도 프로그램 등록을 대신하지는 못한다.

산업용 카탈로그에 대해 솔직히 덧붙일 단서는, 이 스키마들이 소매의 모양을 하고 있다는 점이다. GTIN과 표시 가격, 그리고 바로 살 수 있는 변형이 있다고 전제한다. 취급 품목이 4만 개이고 고객별 계약 단가를 쓰며 절반은 GTIN조차 없는 유통사라면 잘 맞을 리 없다. 피드는 공개된 가격으로 신원이 분명한 최종 구매자에게 판매하는 경우에 값어치가 크고, 견적으로 파는 경우에는 대체로 무관하다.

4. MCP 엔드포인트

MCP는 충실도가 가장 높은 접점이자, 오늘 기준으로는 독자가 가장 좁은 접점이다. 도달 범위가 어시스턴트마다 크게 다르므로 여기서는 정확히 구분해야 한다.

• Claude는 Free와 Pro, Max, Team, Enterprise 요금제에서 맞춤 원격 MCP 커넥터를 지원하며, 무료 사용자는 커넥터 하나로 제한된다. 서버는 Anthropic의 IP 대역에서 공개 인터넷을 통해 닿을 수 있어야 한다.
• ChatGPT는 개발자 모드를 통해 맞춤 MCP 서버를 노출한다. 쓰기가 가능한 맞춤 커넥터는 Business와 Enterprise, Edu로 제한되고, 개인 Plus와 Pro 사용자는 읽기 전용만 쓸 수 있다. ChatGPT 안의 앱을 구동하는 Apps SDK 자체가 MCP 위에 세워져 있으며, 제출물은 디렉터리 심사를 거친다.
• Gemini는 Gemini Enterprise를 통해 맞춤 MCP 서버 연결을 제공하며, 관리자가 자사 테넌트 안에서 당신의 Streamable HTTP 서버를 데이터 스토어로 등록하는 방식이다. 일반 소비자용 기능이 아니다.

그래서 닿을 수 있는 모집단은 커넥터를 직접 설정하는 엔지니어, 그리고 IT 부서가 당신의 서버를 등록해 주는 기업 구매 담당자다. 부품이나 건축 자재 제조사에게 이는 사양 결정자와 구매팀을 놀랄 만큼 정확히 묘사한 문장이다. 다만 그것은 익명의 롱테일이 아니며, MCP 엔드포인트 하나로 "AI에 보이게 된다"고 말하는 사람은 무언가를 팔고 있는 것이다.

속이 빈 MCP 서버는 왜 쓸모가 없는가?

도구 호출은 정확성에 대한 약속이고, 도구를 통해 전달된 틀린 답은 아예 답이 없는 것보다 나쁘기 때문이다.

어시스턴트가 당신의 웹페이지를 읽을 때는 표현을 누그러뜨린다. 문서를 요약하고 있다는 것을 모델이 알기 때문이다. 반면 get_part를 호출해 {"rated_current_a": 32}를 받으면 누그러뜨리지 않는다. 그 수치를 그대로 단언한다. 당신의 PIM이 프레임 사이즈에 대해 32 A를, 해당 변형에 대해서는 25 A를 들고 있는데 도구가 잘못된 쪽으로 해소했다면, 당신이 개선한 것은 AI 가시성이 아니다. 사양 오류를 산업화하고 거기에 브랜드의 권위를 붙여 준 것이다.

오늘 출시되고 있는 신뢰할 만한 부품 MCP 서버들이 프로토콜이라는 겉치장이 아니라 검증된 데이터 계층 위에 세워져 있는 이유가 여기에 있다. 2025년 11월 공개된 Microchip의 무료 공개 MCP 서버는 검증된 제품 사양과 데이터시트, 재고, 가격, 리드타임을 Streamable HTTP로 노출한다. 발표문이 강조한 것은 전송 방식이 아니라 검증되고 최신인 데이터였다. https://{shop}.myshopify.com/api/mcp에서 닿을 수 있는 Shopify의 Storefront MCP 서버가 제대로 작동하는 것은, Shopify 스토어에 타입이 지정된 필드를 갖춘 권위 있는 제품 레코드가 이미 하나 존재하기 때문이다.

서로 어긋나는 스프레드시트 세 개와 단위를 잃어버린 PIM, 그리고 PDF가 담긴 폴더 앞에 MCP 엔드포인트를 세우는 것은 더 빨리 틀리는 방법일 뿐이다. 작업의 순서는 정본 레코드, 검증, 그다음이 프로토콜이다.

에이전트 대응 성숙도 모델

대부분의 조직은 스스로 레벨 2에 있다고 믿다가 실은 레벨 0이나 1에 있다는 사실을 발견한다. 단계를 가르는 질문은 "우리에게 구조화 데이터가 있는가?"가 아니라 "두 시스템이 이 속성을 두고 어긋날 때 어느 쪽이 옳으며, 기계가 그것을 분간할 수 있는가?"이다.

지금 어느 레벨에 있는지 어떻게 확인하는가?

순서대로 다섯 가지 점검이며, 하나하나가 몇 분이면 끝난다.

1. 01평범한 비브라우저 클라이언트로 제품 페이지를 가져와 원본 응답을 읽어라. HTML에 사양이 없다면, 브라우저에서 그 페이지가 어떻게 보이든 당신은 레벨 0이다.
2. 02`robots.txt`를 정책 문서로 읽어라. 허용하고 차단한 AI 사용자 에이전트를 하나도 빠짐없이 적어 보고, 각 줄이 학습이냐 리트리벌이냐에 대한 실제 결정을 반영하고 있는지 확인하라.
3. 03JSON-LD 블록 하나를 검증하고 모든 값을 눈에 보이는 페이지와 대조하라. 불일치는 누락보다 나쁘다.
4. 04부품 열 개를 골라, 정답을 훤히 아는 사실 질문을 어시스턴트 세 곳에 던져라. 틀린 답을 기록하라. 그 오답률이 당신의 진짜 기준선이다.
5. 05자사 데이터로 파라메트릭 질문에 답해 보라 — 세 가지 조건을 모두 만족하는 부품을 전부 찾는 질문을 — 기계가 닿을 수 있는 것만 써서. 사람이 PDF를 열어야 한다면 에이전트도 그래야 한다는 뜻이고, 에이전트는 그렇게 하지 않는다.

984개 기업을 살펴본 결과는 어땠는가?

2026년 8월 우리는 북미와 유럽, 아시아에 걸쳐 전 세계 유통사·제조사 도메인 984곳을 감사했다. 종합된 그림은 불편할 만큼 일관됐다.

• AI 가시성 점수의 중앙값은 100점 만점에 50점 안팎이었다.
• 38%는 표준적인 비브라우저 클라이언트에 읽을 수 있는 카탈로그 페이지를 단 한 장도 내주지 못했다.
• 어떤 형태로든 명시적인 AI 크롤러 정책을 공개한 곳은 19%에 그쳤고, 그중에서도 주요 크롤러를 차단한 곳이 불러들인 곳보다 두 배 넘게 많았다.
• MCP 엔드포인트를 알린 곳은 한 곳도 없었다.

중앙값보다 중요한 것은 분포다. 상위 10%와 중간층을 가른 것은 예산도 인원도 아니었다. 그 조직이 정본 제품 레코드를 하나로 갖고 있느냐, 아니면 서로 경쟁하는 여러 개를 갖고 있느냐였다. 나머지는 모두 거기서 따라 나왔다.

무엇부터 만들어야 하는가?

1. 01부품마다 정본 레코드를 하나로 세워라. 타입이 지정된 속성과 단위, 출처, 최종 검증 시각을 함께 담아라. 아래의 모든 것은 이 레코드를 투영한 결과다.
2. 02카탈로그를 서버에서 렌더링하라. 최초 HTML 응답 안에 사양 전체가 들어 있어야 한다.
3. 03페이지와 일치하는 구조화 데이터를 붙이고, 생성기를 믿는 대신 직접 검증하라.
4. 04의도가 담긴 AI 크롤러 정책을 에이전트 단위로 작성하고, 각 결정을 왜 그렇게 내렸는지 문서로 남겨라.
5. 05자사 상거래 모델에 맞는 접점이 존재하는 곳에는 피드를 밀어 넣고 — 존재하지 않는 곳에서는 솔직하게 건너뛰어라.
6. 06MCP 엔드포인트를 세워라. 파라메트릭 검색과 부품 조회, 대체품, 적합성 문서, CAD를 노출하되, 고객별로 달라지는 것은 무엇이든 OAuth로 막아라.
7. 07정확도를 상시 모니터링하라. 이 영역의 실패 양상은 침묵이 아니라 자신 있는 오답이기 때문이다.

Partsgraph는 이것을 오버레이로 구축한다. 이미 갖고 있는 카탈로그 — 데이터시트와 파라메트릭, CAD, 적합성 문서 — 를 수집해 검증된 하나의 Parts Graph로 정리하고, 당신의 웹사이트에는 손대지 않은 채 네 개의 접점 모두에 제공한다.

로드맵보다 기준선을 먼저 알고 싶다면, /audit의 무료 그레이더에 도메인을 넣어 보라. 지금 비브라우저 클라이언트가 당신의 카탈로그에서 실제로 무엇을 받아 가는지, 그리고 네 접점 가운데 어느 것이 빠져 있는지 알려 준다.