제품 크기 구조화 데이터: 아무도 채우지 않는 필드

제품 크기 구조화 데이터는 리스팅에서 눈 달린 것은 아무도 읽지 않는 영역입니다. 그리고 지금은 바로 그 영역이 우리 제품이 답변에 등장할 수 있는지 아닌지를 결정합니다. 스펙 이미지에는 600 × 320 × 720 mm라고 적어 두었습니다. 구매자는 그 숫자를 읽습니다. 하지만 크롤러와 쇼핑 피드, 그리고 "깊이 350 mm 이하인 벽장은 뭐가 있나요?"라는 질문에 답하는 어시스턴트는 아무것도 읽지 못합니다. 그 숫자가 픽셀로만 존재하기 때문입니다.

제품 크기 구조화 데이터란 제품의 물리적 크기를 기계가 읽을 수 있게 선언한 것입니다. 이름이 정해진 필드에 숫자 값과 단위를 명시해서, 제품 페이지의 JSON-LD로 발행하거나 머천트 피드의 열로 내보냅니다. 지금 그 필드를 정의하는 규격은 서로 다른 세 가지이고, 이름이 서로 어긋나며, 대부분의 카탈로그는 그중 하나도 채우지 않습니다.

아래에 필드 단위로 전부 정리했습니다. 복사해서 바로 쓰는 버전은 뒤에 있습니다.

제품 크기 구조화 데이터: 내 사이즈를 읽는 세 가지 규격

마지막 줄은 두 번 읽어 보시기 바랍니다. 거의 모든 카탈로그가 빠지는 함정이 거기에 들어 있습니다.

Google의 치수 필드는 제품이 아니라 박스를 설명합니다

shipping_length, shipping_width, shipping_height는 선택 항목이고, 센티미터 또는 인치를 받으며, 1–400 cm 또는 1–150 inches 범위로 제한됩니다. Google은 이 필드의 역할을 분명히 밝혀 두었습니다. 운송사 계산 방식을 쓸 때 배송비를 산출하기 위해 존재한다는 것입니다. 세 값은 같은 단위로 함께 넣어야 하며, 그렇지 않으면 데이터 자체가 사용되지 않습니다.

즉 이 필드가 설명하는 것은 포장 박스입니다. 완성된 제품 자체의 치수를 담을 Merchant Center 속성은 없습니다.

그 공백이 있기 때문에 이 글의 어떤 필드보다 product_detail이 중요합니다. 이 속성은 다른 속성으로 다룰 수 없는 기술 스펙을 담으며, 콜론 정확히 두 개로 구분되는 3단 형식을 씁니다.

section_name : attribute_name : attribute_value

section_name은 선택이지만 권장 사항이고, attribute_name과 attribute_value는 필수입니다. Google이 직접 든 예시는 Display:Size:13 inch, Battery:Capacity:12.5 hours 같은 형태입니다. 그렇다면 Google 피드에서 제품의 실제 크기가 들어갈 올바른 자리는 이렇게 생깁니다.

이걸 깔끔하게 유지하는 규칙이 두 가지 있습니다. 단위는 attribute_value 안에 넣으십시오. 자유 텍스트 필드이므로 "600"만 있으면 쓸 수 없습니다. 그리고 이미 전용 속성이 있는 정보는 절대 다시 적지 마십시오. Google은 다른 곳에서 다루는 정보를 중복하지 말라고 명시하고, 가격이나 배송 시점 데이터는 여기에 넣을 수 없다고 못 박아 두었습니다.

schema.org: 네 개의 필드, 그리고 아무도 안 쓰는 하나

페이지 자체에서는 schema.org가 Product에 치수 속성을 직접 제공합니다. 각 속성은 Distance 또는 QuantitativeValue를 받습니다.

• width — "아이템의 너비"입니다.
• height — "아이템의 높이"입니다.
• depth — "아이템의 깊이"입니다.
• weight — Mass 또는 QuantitativeValue입니다.

그리고 **size**가 있습니다. 성격이 다른 필드인데 늘 잘못 쓰입니다. 정의상 XL이나 32Wx34L 같은 일반 텍스트 문자열, unitCode를 가진 QuantitativeValue, 또는 완전한 SizeSpecification을 허용합니다. 그러면서 그런 값이 맞지 않을 때는 "width, height, depth, weight 속성이 더 적절할 수 있다"고 직접 말합니다. 의류가 아닌 것을 파는 사람을 위해 옮기면 이렇습니다. size는 의류 사이즈 체계에만 쓰고, 물리적 상품에는 네 개의 치수 속성을 쓰고, 600x320x720을 문자열로 size에 넣지 마십시오.

아무도 안 쓰는 필드는 **hasMeasurement**입니다. Product에 붙는 QuantitativeValue로, 아이템의 각종 측정값을 담으라고 만들어졌습니다. schema.org가 든 예시는 바지 인심, 자전거 휠 사이즈, 나사 게이지입니다. 배열을 받기 때문에 모든 부가 치수가 들어갈 자리가 바로 여기입니다. 내부 선반 너비, 좌면 높이, 고정 피치, 개구부, 나사 피치 같은 값입니다. 구매자가 메일로 물어보는 숫자가 정확히 이것들인데, 거의 모든 카탈로그에서 이 표준 필드는 빈칸으로 남아 있습니다.

단위는 unitCode에 UN/CEFACT 3자리 공통 코드를 넣습니다. MMT 밀리미터, CMT 센티미터, INH 인치, KGM 킬로그램, LBR 파운드입니다. 코드가 확실하지 않다면 일반 문자열을 넣은 unitText도 유효하며, 틀린 코드보다 낫습니다.

복사해서 쓰는 JSON-LD 치수 블록

기존 Product 노드 안에 그대로 넣으십시오. 검증을 통과하고, 빠진 것이 없고, 제품 크기와 박스 크기를 의도적으로 분리해 두었습니다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wall cabinet, 2-door, 600 mm",
  "sku": "WC-600-2D",
  "material": "Birch plywood, white melamine",
  "width":  { "@type": "QuantitativeValue", "value": 600, "unitCode": "MMT" },
  "height": { "@type": "QuantitativeValue", "value": 720, "unitCode": "MMT" },
  "depth":  { "@type": "QuantitativeValue", "value": 320, "unitCode": "MMT" },
  "weight": { "@type": "QuantitativeValue", "value": 14.2, "unitCode": "KGM" },
  "hasMeasurement": [
    { "@type": "QuantitativeValue", "name": "Internal shelf width",
      "value": 564, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Wall fixing centres",
      "value": 512, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Carton, longest side",
      "value": 760, "unitCode": "MMT" }
  ]
}

ChatGPT 피드는 같은 숫자를 다른 이름으로 요구합니다

Agentic Commerce 제품 피드 규격 — 판매자가 ChatGPT 쇼핑 영역에 올리는 그 파일 — 은 치수를 두 가지 방식으로 받고, 의존 규칙이 엄격합니다.

규격은 물리적 특성과 분류 정보가 카테고리 분류, 필터링, 검색 관련성에 도움이 된다고 밝힙니다. 이는 치수가 없는 제품은 결과 목록으로 걸러 들어올 수 없는 제품이라는 말을 그대로 한 것입니다. 구매자가 깊이 350 mm 이하 캐비닛을 찾는데 depth 필드가 비어 있다면, 순위가 낮은 게 아닙니다. 아예 없는 것입니다.

솔직한 빈틈 하나. 규격은 포장 치수를 위한 별도 필드를 정의하지 않았고, dimensions가 제품인지 박스인지도 말해 주지 않습니다. 어느 쪽인지 사람과 모델이 모두 읽을 수 있는 자리에 선언하고, 카탈로그 전체에서 일관되게 유지하십시오.

Google이 보여주지 않는데도 이 필드를 채워야 하는 이유

여기서부터는 모순처럼 들립니다. 리치 결과를 받는 조건을 정리해 둔 Google의 Product 구조화 데이터 문서에는 width, height, depth, weight, hasMeasurement가 들어 있지 않습니다. 지원 목록은 가격, 재고 여부, 리뷰 평점, 배송, 반품 정책, 의류 사이즈, 식별자, 장단점까지입니다.

그래서 치수 마크업으로 스니펫이 커지지는 않습니다. 애초에 그럴 일이 없었습니다.

달라진 것은 소비하는 쪽입니다. Google은 product_detail이 검색의 AI 모드 같은 AI 기반 기능을 포함한 여러 영역에서 제품을 이해하고 표시하는 데 도움이 되는 구조화 데이터를 제공한다고 말합니다. Agentic Commerce 피드는 채팅 안에서 제품을 찾고 걸러낼 수 있게 하려고 존재합니다. 이런 시스템은 발동할 시각 템플릿이 필요한 게 아닙니다. 조건과 비교할 수 있는 속성이 필요합니다. 치수 필드는 더 이상 검색 결과의 장식이 아닙니다. 검색 대상에 들어갈 자격 그 자체입니다.

그러면 우선순위가 다시 정리됩니다. 박스를 그려 주는 엔진이 아니라, 질문에 답하는 엔진을 위해 이 필드를 채우십시오.

전부 망가뜨리는 규칙: 숫자 하나, 장소 둘

제품 크기 구조화 데이터에서 제가 본 실패는 뿌리가 하나같이 같습니다. 피드가 말하는 값과 이미지가 말하는 값이 다른 것입니다.

악의 없이 벌어집니다. 누군가는 박스 크기를 shipping_width에 적고, 다른 사람은 스펙 도면을 그리려고 조립 완성품을 재고, 세 번째 사람은 product_detail에서 564 mm를 56 cm로 반올림합니다. 그러면 어시스턴트는 구매자에게 이 캐비닛이 640 mm 폭이라고 자신 있게 말하고, 구매자는 600이라고 적힌 이미지를 보게 되고, 신뢰 문제와 반품이 한꺼번에 만들어집니다. 더 나쁜 건 인용되는 쪽이 기계가 읽은 숫자라는 점입니다. 그쪽이 판독 가능한 값이었기 때문입니다.

해결책은 마크업이 아니라 프로세스입니다. 한 번 측정하고, 그 측정값을 필드와 이미지 양쪽에 그대로 발행하십시오. 구체적으로는 이렇습니다.

1. 도면도 박스도 아닌 완성된 제품을 측정하고, 각 수치가 어느 쪽을 가리키는지 기록합니다.
2. 각 수치를 그것이 설명하는 부위에 맞춰 이미지에 올립니다. 근처에 떠 있게 두지 말고 제품의 실제 모서리에 붙이고, 플랫폼별 스펙 도면 규격 크기로 내보냅니다. 치수 주석 전용 소프트웨어는 이 작업을 매번 같은 결과로 처리합니다. 화살표를 손으로 배치하는 일반 이미지 편집기, 또는 재 본 적도 없는 치수를 그럴듯하다는 이유로 태연히 그려 내는 이미지 생성기와 갈라지는 지점이 정확히 여기입니다.
3. 같은 수치를 width/height/depth, product_detail, 그리고 피드의 치수 필드에 복사합니다. 같은 출처, 같은 반올림, 같은 단위입니다.
4. 수치가 바뀌면 같은 커밋에서 양쪽을 함께 바꿉니다. 어긋난 한 쌍은 아예 없는 것보다 나쁩니다.

이 짝맞춤에서 이미지 쪽 절반을 실제로 해낸 예시는 제품 사이즈 라벨 사례 연구에 있고, 수출 판매자 절반이 걸려 넘어지는 단위 문제는 제품 치수를 cm로 쓸지 인치로 쓸지에서 다뤘습니다.

발행 전 체크리스트

• Product 노드에 width, height, depth가 각각 unitCode 또는 unitText를 가진 QuantitativeValue로 들어가 있습니다
• weight가 단위와 함께 들어가 있습니다
• 구매자가 실제로 물어보는 부가 치수가 모두 설명적인 name과 함께 hasMeasurement에 있습니다
• size는 의류 사이즈 체계에만 썼고 600x320x720 같은 문자열은 없습니다
• 피드: shipping_length / shipping_width / shipping_height 세 개가 모두 있고, 단위가 같고, 박스를 설명합니다
• 피드: 조립 완성품 치수가 product_detail에 있고, 단위가 값 안에 있고, 항목마다 콜론이 정확히 두 개입니다
• 피드: 이미 전용 속성이 있는 데이터를 중복하지 않았고, product_detail 안에 가격이나 배송 시점이 없습니다
• Agentic 피드: dimensions에 단위를 함께 넣었거나, length+width+height에 dimensions_unit을 더해 넣었습니다
• Agentic 피드: weight를 item_weight_unit 없이 보내는 일이 없습니다
• 제품 치수와 박스 치수를 등장하는 모든 곳에서 구분해 표기했습니다
• 마크업의 모든 숫자가 스펙 이미지에 인쇄된 숫자와 밀리미터 단위까지 일치합니다
• 그 일치를 책임지는 담당자가 한 명 지정돼 있어, 아무도 한쪽만 고치지 않습니다

FAQ

구조화 데이터에 제품 치수를 어떻게 넣나요?

JSON-LD의 Product 노드에 width, height, depth, weight를 각각 숫자 value와 unitCode를 가진 QuantitativeValue로 넣으십시오. 나머지 측정 가능한 특징은 모두 설명적인 name을 붙여 hasMeasurement 항목으로 추가합니다. Google 피드에서는 조립 후 크기가 shipping_* 필드가 아니라 product_detail에 들어갑니다.

Product 스키마의 width, height, depth를 Google이 쓰나요?

리치 결과에는 쓰지 않습니다. Google이 지원하는 제품 속성은 가격, 재고 여부, 리뷰, 배송, 반품 정책, 의류 사이즈, 식별자, 장단점까지이고 물리적 치수는 그 목록에 없습니다. 그래도 AI 기반 영역에서의 검색과 비교에는 여전히 중요하며, 이건 성격이 다르고 지금은 더 큰 역할입니다.

shipping_length와 제품 실제 크기는 어떻게 다른가요?

shipping_length, shipping_width, shipping_height는 배송 포장을 설명하며, 운송사 계산 요금을 산출할 수 있게 존재합니다. 제품의 완성 치수가 아니므로 그 값을 넣어서는 안 됩니다. Merchant Center에는 조립 후 크기를 위한 전용 속성이 없고, 그래서 그 값의 올바른 자리가 product_detail입니다.

JSON-LD 치수에는 어떤 단위 코드를 써야 하나요?

unitCode에는 UN/CEFACT 3자리 공통 코드를 넣습니다. 밀리미터는 MMT, 센티미터는 CMT, 인치는 INH, 킬로그램은 KGM, 파운드는 LBR입니다. 어떤 단위의 코드가 확실하지 않다면 일반 문자열을 넣은 unitText를 쓰십시오. 읽을 수 있는 unitText가 틀린 unitCode보다 낫습니다.

피드에 치수가 있으면 제품 이미지에도 넣어야 하나요?

넣어야 합니다. 이유는 양쪽으로 대칭입니다. 기계는 필드를 읽고 이미지는 읽지 못합니다. 구매자는 이미지를 읽고 피드는 절대 열어 보지 않습니다. 치수 도면은 이미지이고, 우리 제품이 답변에 등장할지 결정하는 모든 시스템은 텍스트를 읽습니다. 그러니 둘 다 내보내고, 밀리미터 단위까지 일치시키십시오. 구매자가 행동하게 만드는 이미지 쪽 문구는 구매자에게 제품 치수를 전달하는 방법에서 다뤘고, 틀렸을 때의 비용을 금액으로 보고 싶다면 반품 비용 계산기가 그 계산을 해 줍니다.

출처 및 참고자료

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode, unitText
• Google Merchant Center — 배송 치수 속성과 그 제한값
• Google Merchant Center — product detail [product_detail] 속성
• Google Search Central — Product 구조화 데이터와 지원 속성
• Agentic Commerce — 제품 피드 규격