AI가 당신의 데이터시트를 읽지 못하는 이유

결론부터 말하면

데이터시트가 AI에게 보이지 않게 되는 경로는 네 가지이며, 하나같이 평범하다. 봇 규칙이나 로그인, 중간 안내 페이지 탓에 파일을 가져가 보기도 전에 차단된다. 파일이 텍스트 레이어 없는 스캔 이미지여서 추출기가 뽑아내는 문자가 0자다. 문서에 직접 URL이 없어 JavaScript 뷰어를 거쳐야만 닿을 수 있다. 또는 PDF가 docs.나 media. 같은 별도의 문서 호스트, DAM, CDN에 놓여 있는데, 본 사이트가 아무리 관대하든 그 호스트 자체의 robots.txt나 WAF가 거부한다.

특별할 것 없는 사례들이다. 네 가지 모두 흔하고, 그중 하나만 있어도 충분하다. 그 귀결은 분명히 짚어 둘 만하다.

데이터시트가 사양의 정본이다. 제품 페이지는 그 요약본이다. AI가 요약본은 읽으면서 원본은 읽지 못할 때, AI는 요약본을 근거로 엔지니어링 질문에 답한다. 그리고 틀린다.

여기서는 웹 페이지보다 데이터시트가 더 중요하다

제품 페이지가 싣고 있는 속성은 많아야 여덟에서 스무 개 남짓이다. 패키지, 주요 정격, 수명 주기 표시, 가격, 재고 정도다. 데이터시트는 수백 개를 싣는다. 절대 최대 정격, 온도 전 구간의 전기적 특성, 타이밍 다이어그램, 핀 설명, 열저항 수치, 권장 풋프린트, 흡습 민감도 등급, 주문용 부품 번호 해독표까지 들어 있다. 엔지니어가 어시스턴트에게 실제로 던지는 질문은 거의 전부 — 이걸 5.5 V로 구동해도 되는가, 85도에서 정지 전류는 얼마인가, 교체하려는 부품과 핀 배치가 호환되는가 — 데이터시트에 답이 있고 다른 어디에도 없다.

이 사실은 예전보다 지금 더 무겁다. 그런 질문이 이제 당신의 검색창에 입력되는 대신 어시스턴트에게 던져지고 있기 때문이다. Forrester는 2026년 1월 기업 구매 담당자의 94%가 구매 과정에서 AI를 사용한다는 사실을 확인했다. 그런데 기술적 깊이가 가장 큰 페이지들이 오히려 가장 나쁜 성적을 내고 있다. Adobe가 2026년 4월 소매 사이트의 기계 판독성을 분석한 결과, 제품 상세 페이지는 66%로 모든 페이지 유형 가운데 가장 낮았다. 홈페이지 75%, FAQ 페이지 80%보다도 아래다.

기반 데이터에 닿을 수 없을 때 나타나는 실패는 침묵이 아니라 자신에 찬 오답이다. OpenAI는 2026년 3월 가맹점 30곳가량이 붙어 있던 ChatGPT의 Instant Checkout을 접었는데, 그 핵심 이유가 부정확한 제품 데이터였다. OpenAI는 제품 정보를 얻으려 소매 사이트를 긁어 왔고, 재고와 배송, 가격 데이터가 자주 틀렸다. 잘못된 최대 정격과 완전히 같은 실패 유형이고, 걸린 것만 더 가벼울 뿐이다.

데이터시트가 읽히지 않게 되는 다섯 가지 경로

다섯 번째는 가장 자초한 실패다. 수명이 짧은 서명 URL, "다운로드하려면 등록하세요" 게이트, 일회용 토큰은 모두 보이지 않는 벽이다. 크롤러에게는 세션도 쿠키도 없고, 양식을 채우는 동작도 없다. 게다가 AI 크롤러는 JavaScript를 실행하지 않으므로, 스크립트가 DOM에 써 넣는 다운로드 링크는 크롤러 쪽 회선에서 보면 아예 존재하지 않는다.

우리 데이터시트가 읽히는지 어떻게 점검하는가?

명령어 세 줄이면 판가름 난다. 자사 문서에 직접 실행해 보라.

1. 01가져오기부터 확인하라. 브라우저가 아닌 평범한 클라이언트에게도 그 URL이 PDF를 돌려주는가?

curl -sSIL "https://example.com/datasheets/part-12345.pdf" | grep -iE "^HTTP|content-type|content-length"

최종 응답이 200이고 content-type: application/pdf여야 한다. content-type: text/html이 돌아왔다면 다운로드로 위장한 챌린지 페이지나 로그인 페이지를 받은 것이다.

1. 01내려받아서 정말 PDF가 맞는지 확인하라.

curl -sSL -o ds.pdf "https://example.com/datasheets/part-12345.pdf" -w "status=%{http_code} type=%{content_type} bytes=%{size_download}"
head -c 5 ds.pdf

앞 5바이트가 반드시 %PDF-여야 한다. <!DOC이라면 오류 페이지를 내려받은 것이다.

1. 01텍스트 레이어를 시험하라. 아무도 실행하지 않는 항목이 바로 이것이다.

pdftotext -q ds.pdf - | tr -d '[:space:]' | wc -c
pdffonts ds.pdf

PDF에 텍스트 레이어가 있는지 어떻게 알 수 있는가?

숫자 두 개면 되고, 둘 사이의 격차는 착각할 여지가 없다. 우리는 실제로 유통되는 현행 제조사 데이터시트(Texas Instruments의 LM358, 4.15 MB PDF)와 같은 문서를 래스터화한 사본을 대상으로 두 시험을 모두 돌렸다. 뒤엣것은 스캔된 구형 데이터시트가 기계에게 어떻게 보이는지를 그대로 재현한 것이다.

진단은 이것이 전부다. 추출 문자 0자, 임베드 폰트 0개라면 그 파일 안에 텍스트는 없다. 텍스트를 찍은 그림만 있을 뿐이다. 그 문서는 사람에게는 완벽하게 표시되면서 모델에게는 말 그대로 아무것도 기여하지 못한다. 아직 생산 중인 부품의 1990년대 스캔 데이터시트는 인터넷의 모든 AI 시스템에게 백지나 다름없다.

알아 둘 만한 보완점이 두 가지 있다. 문자 수가 0은 아니지만 지나치게 적을 때 — 이를테면 40쪽짜리 문서에서 수백 자 — 는 대개 본문은 스캔이고 머리글만 텍스트인 경우이며, 쓸 수 없기는 마찬가지다. 그리고 pdffonts 출력에서는 uni 열이 중요하다. ToUnicode 맵 없이 서브셋된 폰트는 문자가 기술적으로는 존재하더라도 깨진 글자로 추출될 수 있다. 문자 수만 믿지 말고 추출된 텍스트의 앞 200자를 눈으로 확인하라.

라이브러리 전체를 훑으려면 반복문으로 돌려라.

while read -r url; do
  code=$(curl -sSL -o /tmp/d.pdf -w "%{http_code}" --max-time 30 "$url")
  chars=$(pdftotext -q /tmp/d.pdf - 2>/dev/null | tr -d '[:space:]' | wc -c)
  echo "$code $chars $url"
done < datasheet-urls.txt

출력 결과를 문자 수 오름차순으로 정렬하라. 그 목록 맨 위에 올라온 것은 전부 제품 데이터에 뚫린 구멍이다.

별도 호스트라는 함정

이 함정에는 규모가 큰 조직이라면 거의 예외 없이 걸려든다. 일을 제대로 처리한 결과로 생기는 문제이기 때문이다. 문서는 DAM이나 문서 전용 서브도메인, CDN으로 옮겨지는데, 그 하나하나가 자체 설정을 가진 별개의 오리진이고 관리 주체까지 따로인 경우가 많다.

RFC 9309에 따르면 robots.txt의 적용 범위는 스킴과 호스트, 포트로 정의되는 단일 오리진이다. https://www.example.com/robots.txt는 https://docs.example.com/에 대해서도, https://cdn.example-media.net/에 대해서도 아무것도 규율하지 않는다. 본 사이트는 AI 크롤러를 환영하는데 문서 호스트는 전면 Disallow: /가 걸린 기본 템플릿 그대로 올라갔거나, 사람이 아닌 모든 접근에 챌린지를 걸도록 설정된 봇 매니저 뒤에 놓여 있다면, 마케팅 사이트가 활짝 열려 있는 동안 기술 문서 라이브러리 전체는 어둠에 잠긴다.

문서를 제공하는 오리진을 하나도 빠짐없이 확인하라.

for h in www.example.com docs.example.com cdn.example-media.net; do
  echo "--- $h"
  curl -sS --max-time 15 "https://$h/robots.txt" | head -30
done

제대로 된 모습은 어떤 것인가

제대로 발행된 데이터시트에는 특별할 것이 없고, 바로 그 점이 핵심이다. Texas Instruments는 LM358 데이터시트를 /lit/ds/ 아래 안정적이고 짐작 가능한 URL로 제공한다. robots.txt는 그 경로에 어떤 제한도 두지 않는다. 파일은 GPTBot을 자처하는 비브라우저 클라이언트에게도 content-type: application/pdf와 함께 200을 돌려준다. 그리고 그 PDF에는 유니코드 매핑이 된 임베드 폰트와 완전한 텍스트 레이어가 들어 있다. 로그인도, 뷰어도, 서명 URL도, 중간 안내 페이지도 없다. 세상 어떤 추출 파이프라인이든 이 문서를 읽을 수 있다.

부품 업계가 나아가는 방향은 이 일을 한층 더 쉽게 만드는 쪽이다. Microchip은 2025년 11월 사양과 데이터시트, 재고, 가격, 리드타임을 아우르는 제품 데이터용 MCP 서버를 인증 없이 무료로 공개했고, ECIA의 TrustedParts는 2026년 6월 공인 유통사의 재고 가용성을 Copilot과 ChatGPT, Claude에 노출하는 재고 AI 에이전트 서비스를 시작했다. 둘 다 같은 인식에서 나온 것이다. 기계가 싸워 가며 얻어야 하는 문서는 결국 지는 문서라는 인식이다.

어떻게 고칠 것인가?

투입 대비 효과가 큰 순서대로 정리하면 이렇다.

1. 01문서 경로의 차단을 풀어라. /datasheets/*, /lit/*, /documents/*와 그에 준하는 경로에 AI 크롤러를 허용하되, robots.txt뿐 아니라 WAF에서도 허용하라. 이 둘은 별개의 스위치이고 둘 다 켜야 한다.
2. 02공개 기술 문서에서 다운로드 게이트를 없애라. 데이터시트가 공개 사이트에 올라가 있다면 그것은 이미 공개된 것이다. 등록 양식이 막아 세우는 대상은 당신을 추천해 주었을 기계뿐이다.
3. 03텍스트 없는 PDF는 전부 OCR을 돌려 텍스트 레이어와 함께 재발행하라. 우선순위는 문서 연식이 아니라 부품 매출로 정하라. 깨끗한 300 dpi 스캔본에 최신 OCR을 적용하면 본문 텍스트는 거의 손실 없이 살아난다. 파라미터 표는 사람이 직접 검증하라.
4. 04모든 문서에 안정적이고 직접 링크할 수 있는 URL을 부여하라. blob도, 뷰어도, 만료되는 토큰도, ?token= 쿼리 문자열도 쓰지 마라.
5. 05데이터시트마다 HTML 또는 마크다운 쌍둥이를 발행하라. 사양 표는 진짜 표로 만들어라. 단일 조치로는 이것이 가장 효과가 크다. PDF 레이아웃 휴리스틱에 대한 의존을 전부 없애 주고, 정확도를 상시 모니터링할 수 있는 페이지까지 손에 들어오기 때문이다.
6. 06제품 페이지에서 문서로 가는 링크를 서버에서 렌더링한 HTML 안에 넣어라. 그래야 페이지에 도달한 크롤러가 아무것도 실행하지 않고 문서까지 도달할 수 있다.
7. 07추출한 파라미터를 구조화 데이터로 노출하라. 페이지에는 JSON-LD를, 가능하다면 질의할 수 있는 엔드포인트까지 제공하라. 그래야 에이전트가 매번 PDF를 다시 파싱하는 대신 그 값으로 걸러 낼 수 있다.

Partsgraph는 2026년 8월 북미와 유럽, 아시아에 걸쳐 전 세계 유통사·제조사 도메인 984곳을 감사했다. AI 가시성 점수 중앙값은 100점 만점에 50점이었고, 표본의 70%가 D 또는 F 등급을 받았다. 점수를 이루는 항목 가운데 문서 계층은 한결같이 가장 취약했다. 38%는 표준적인 비브라우저 클라이언트에게 읽을 수 있는 카탈로그 페이지를 단 한 장도 내주지 못했고, 문서 접근은 페이지 접근보다 더 자주 실패했다.

불편한 지점은 이 가운데 어느 것도 당신의 분석 도구에 잡히지 않는다는 사실이다. 차단당한 크롤러는 버그 리포트를 올리지 않고, 잘못된 OCR은 예외를 던지지 않으며, 당신의 데이터시트를 읽지 못한 모델은 그 사실을 구매자에게 알려 주지 않는다. 그저 PDF가 열린 경쟁사를 추천할 뿐이다.

무료 Partsgraph AI 가시성 그레이더 [/audit](/audit)에서 자사 문서 라이브러리를 이 시험 항목들에 그대로 대조해 볼 수 있다.