SKU.md v0.8 계층 아키텍처 읽기: 자체 호스팅 정보와 플랫폼 승인 거래

SKU.md v0.8 아키텍처는 기술을 단순한 것부터 고급 순서로 쌓아 올린 구조가 아닙니다. 통제권이 어디에서 바뀌는지를 보여 주는 지도입니다. AI 에이전트는 판매자 도메인에서 출발해 공개 탐색과 판매자가 게시한 상품 맥락을 거친 뒤, 외부 프로토콜, 플랫폼, 신원 시스템 또는 거래 백엔드에 의존할 수 있는 기능에 도달합니다.

색상은 이 경계를 드러냅니다. 청록색은 판매자가 자신의 도메인에서 직접 게시하거나 구현할 수 있는 영역이고, 산호색은 제3자의 참여뿐 아니라 가입 승인, 자격 증명, 권한 부여 또는 실행이 필요한 영역입니다. 정보를 공개적으로 찾을 수 있다고 해서 그 정보가 가리키는 동작까지 모든 호출자에게 열리는 것은 아닙니다.

색상은 권한 경계를 나타냅니다

흰색 상자는 파일, 데이터 구조 또는 작동 방식을 표시합니다. 바깥쪽 색상은 누가 그 방식을 실제로 만들고 운영할 수 있는지를 답합니다.

청록색 계층에서는 게시 권한을 판매자가 가집니다. 판매자는 robots.txt를 설정하고, Sitemap을 제공하며, llms.txt와 루트 sku.md를 게시하고, 파티션 인덱스와 상품 문서를 추가하고, 페이지 런타임 도구를 제공할 수 있습니다. 올바른 호스팅, 안전한 파싱과 정확한 데이터는 여전히 필요하지만 파일의 존재 자체에 상거래 플랫폼의 사전 승인이 필요한 것은 아닙니다.

산호색은 프로토콜 사양이 폐쇄적이라는 뜻이 아닙니다. 실제 사용에 상대방이 필요하다는 뜻입니다. 프로토콜 Profile에는 판매자 등록, 신원 검증, 자격 증명, 지원 서비스 또는 플랫폼 검토가 필요할 수 있습니다. 결제, 지불, 주문 완료에는 사용자 승인과 상거래 상태를 확정할 수 있는 외부 시스템이 반드시 관여합니다.

따라서 이 그림은 흔히 혼동되는 두 가지, 선언을 게시하는 일과 그 선언을 실행할 권한을 갖는 일을 분리합니다.

거버넌스와 탐색은 판매자가 통제합니다

첫 번째 계층은 robots.txt, llms.txt, sitemap.xml을 포함합니다. 세 파일 모두 소비자가 사이트 자원을 찾고 이해하는 데 도움이 되지만 역할은 서로 다릅니다.

robots.txt는 크롤링 규칙과 Sitemap 위치를 알릴 수 있지만 일반적인 신원 인증이나 접근 승인 프로토콜은 아닙니다. Sitemap은 URL을 일괄 발견하기 위한 것이며 각 URL의 주장이 최신이고 정확하며 신뢰할 수 있음을 증명하지 않습니다. llms.txt는 AI 소비자를 위한 간결한 안내를 제공할 수 있지만 어떤 모델이나 에이전트가 읽고, 받아들이고, 인용하거나 순위를 높인다고 보장하지 않습니다.

그래서 이 계층은 신뢰가 아니라 거버넌스와 탐색이라고 부릅니다. 판매자는 무엇을 게시하고 어디로 연결할지 통제하지만, 소비자는 크롤링 허용 여부, 응답의 출처, 그 콘텐츠에 어느 정도의 증거 가치를 부여할지를 따로 판단해야 합니다.

SKU-MD 문서군은 루트 매니페스트를 제한된 크기로 유지합니다

두 번째 청록색 계층은 SKU-MD 문서군입니다.

• 루트 /sku.md 카탈로그 매니페스트.
• 크거나 분할된 카탈로그를 위한 선택적 파티션 인덱스.
• 상품별 *.sku.md 문서.

그림의 O(1)은 카탈로그가 커져도 루트 매니페스트의 크기가 제한되어야 한다는 뜻이지, 전체 카탈로그를 상수 시간에 조회할 수 있다는 뜻이 아닙니다. 루트는 모든 상품을 포함하는 대신 카탈로그 진입점, 파티션과 상품 문서 탐색 위치를 연결하므로 짧고 안정적으로 유지할 수 있습니다.

이 설계는 에이전트에게 예측 가능한 시작점을 제공하면서 작은 판매자에게 복잡한 인덱스를 강요하지 않습니다. 작은 카탈로그는 기존 자원을 직접 연결할 수 있고, 큰 카탈로그는 시장, 언어 또는 업무 영역별로 계층화할 수 있습니다. 상품 문서는 하나의 ProductGroup과 그 여러 Variant에 집중하므로 부분 정보가 바뀌어도 루트 파일을 다시 쓸 필요가 없습니다.

파일은 판매자가 호스팅하지만 파일 이름만으로 권한이 생기지는 않습니다. 신뢰는 도메인 통제, 정식 URL, 일관된 개정, 증거와 올바른 HTTP 전달에서 나옵니다.

상품 정보 계층은 안정적인 지식과 변하는 상태를 분리합니다

세 번째 청록색 계층은 Product JSON-LD와 SKU.md Knowledge를 함께 두고 offer_snapshot과 live_verification을 나란히 표시합니다. 안정적인 사실과 변하기 쉬운 상거래 상태를 하나의 평면적인 기록에 섞지 않기 위한 구성입니다.

Product JSON-LD는 성숙한 페이지 단위 상품 의미를 제공합니다. SKU.md Knowledge는 사실, 주장, 고지 사항, 안내, 제한 사항과 관련 증거를 정리할 수 있습니다. Knowledge는 게시하고 감사할 가치가 있는 진술을 담는 곳이며 단기 가격, 재고, 배송비 또는 프로모션을 장기 본문에 고정하는 곳이 아닙니다.

offer_snapshot은 특정 시장과 Variant에서 특정 시점에 관찰한 상태를 기록합니다. observed_at, refresh_after, 실제로 존재하는 offer_valid_until은 소비자가 신선도를 판단하는 데 도움이 됩니다. 스냅샷은 과거 관찰만 증명하며 재고를 잠그거나 의사 결정 시점에도 같은 가격과 가용성이 유지됨을 증명하지 않습니다.

live_verification은 보수적인 실시간 보완책입니다. 공개 상품 페이지를 다시 열어 같은 Variant의 현재 표시 상태를 확인합니다. 구조화된 Catalog Lookup API가 아니며 구매를 직접 실행할 수도 없습니다. 소비자가 사용 가능한 구조화 live_lookup을 식별할 수 있다면 이를 우선하고, 그렇지 않으면 판매자가 통제하는 공개 페이지에서 다시 확인합니다.

capabilities[]와 protocol_profiles[]는 서로 다른 경로입니다

상품 정보 계층 뒤에서 아키텍처는 두 갈래로 나뉩니다. 새 기술과 낡은 기술을 나누는 것이 아니라, 누가 기능을 운영하며 소비자가 사용 전에 어떤 조건을 충족해야 하는지를 구분합니다.

capabilities[]: 판매자가 게시한 런타임 기능

외부 프로토콜의 권한 있는 Profile이 없거나 기능이 페이지 런타임에 존재한다면 capabilities[]는 WebMCP 페이지 도구 같은 일반 기능을 설명할 수 있습니다. 판매자는 상점 페이지에 도구를 구현하고 범위, 상태, 탐색 방식, 접근 방식을 선언할 수 있습니다.

페이지 런타임 도구는 페이지 맥락에 묶입니다. 사용자가 현장에 있어야 할 수 있고 상품이나 장바구니 범위만 노출할 수 있으며, 매니페스트에 적었다고 원격 호출 URL이 자동으로 생기지 않습니다. 자체 통제는 무제한 호출을 뜻하지 않습니다. 브라우저, 사이트 정책, 현재 사용자 세션, 도구 Schema와 애플리케이션 코드가 실제 동작을 함께 제한합니다.

더 중요한 점은 기능 선언이 기능의 존재를 설명할 뿐이라는 것입니다. 에이전트가 사용자 동의, 결제 권한 또는 되돌릴 수 없는 작업의 허가를 얻었다는 증거가 아닙니다.

protocol_profiles[]: 외부 신뢰 시스템을 가리키는 참조

외부 프로토콜이 권한 있는 탐색 Profile을 정의했다면 protocol_profiles[]는 그 Profile을 연결합니다. 프로토콜 버전, 서비스, 전송, 엔드포인트와 Schema를 카탈로그 매니페스트에 모두 복사하지 않습니다.

그림은 UCP와 ACP를 이 경로의 예로 사용합니다. Profile을 판매자 도메인에 게시할 수 있어도 실제 참여에는 프로토콜 지원, 판매자 등록, 플랫폼 심사, 자격 증명 또는 상업 계약이 필요할 수 있습니다. 문법적으로 올바른 Profile이 다른 참여자의 승인을 만들어 내지는 못합니다.

이것이 아키텍처의 중요한 특징입니다. 열린 탐색 문서는 승인받아야 하는 실행 환경을 정직하게 설명할 수 있으며, 그 문턱이 없는 것처럼 가장할 필요가 없습니다.

두 경로는 거래 경계에서 합쳐집니다

맨 아래 산호색 계층은 Checkout, 결제, Order를 포함합니다. 에이전트가 페이지 기능 또는 프로토콜 Profile 중 어느 경로를 거치더라도 실제 거래 제출에는 자금, 재고, 세금, 이행, 위험 관리와 사용자 승인을 통제하는 시스템이 필요합니다.

SKU.md는 해당 시스템의 위치와 어떤 필드가 어느 출처를 권한으로 삼는지 알릴 수 있지만 Checkout 백엔드를 대체할 수 없습니다. 최종 금액, 결제 상태와 주문 상태는 변화를 실행하고 기록할 수 있는 시스템에서 나와야 합니다. 사용할 수 있는 출처가 없다면 안전한 결과는 정적 문서에서 거래를 추론하는 것이 아니라 “알 수 없음”으로 처리하는 것입니다.

두 경로가 여기서 합쳐진다는 점은 위험한 지름길도 막습니다. 자체 호스팅 페이지 도구를 플랫폼이나 프로토콜 통제를 우회하는 수단으로 취급할 수 없습니다. 도구는 장바구니를 준비하거나 사용자를 안내할 수 있지만 상거래 상태가 구속력을 갖기 전에는 승인된 백엔드로 넘어가야 합니다.

이 아키텍처가 피하는 다섯 가지 범주 오류

1. 탐색은 채택이 아닙니다. 파일에 접근할 수 있어도 에이전트가 소비하고 신뢰하고 추천한다는 뜻은 아닙니다.
2. 선언은 승인이 아닙니다. 기능 선언 또는 프로토콜 Profile을 적어도 외부 시스템이 이를 활성화했다는 증거가 되지 않습니다.
3. 스냅샷은 실시간 상태가 아닙니다. 가격과 가용성은 관찰 시간을 함께 평가하고 필요할 때 다시 검증해야 합니다.
4. 페이지 도구는 결제 권한이 아닙니다. 런타임 기능은 사용자 현장성, 애플리케이션 정책과 결제 시스템의 제약을 받습니다.
5. 열린 사양은 열린 거래가 아닙니다. 신원, 자격 증명, 동의, 위험 관리와 상업 계약이 여전히 필요할 수 있습니다.

작은 문서도 정직한 경계를 표현할 수 있습니다

이 아키텍처는 진입점을 단순하게 유지하면서 모든 하위 의존성을 모호한 AI 커머스라는 말로 압축하지 않습니다. 판매자는 자신의 도메인에서 탐색, 문서, 증거와 페이지 런타임 계층을 통제하고, 외부 프로토콜과 거래 시스템은 실제 승인 및 권한 요건을 유지합니다.

이것이 계층 설계의 핵심입니다. SKU.md는 상품 맥락과 실행 가능한 상거래 사이의 경계를 없애려 하지 않습니다. 판매자는 자신이 통제하는 범위를 알고, 플랫폼은 운영해야 하는 승인 절차를 유지하며, 소비자는 증거를 읽는 단계에서 동작을 요청하는 단계로 넘어가는 시점을 알 수 있도록 경계를 분명히 합니다.

더 읽기

현재의 책임 분담은 llms.txt와 agents.md, SKU.md 비교에서 확인하세요.