avalayer.com/writing에서 처음 게시됨, Field Notes 002.

관련 없는 무언가를 테스트하기 위해 일회용 상점을 설정하던 중 그것을 발견했습니다. Shopify 관리자(admin), 온라인 스토어(Online Store), 설정(Preferences), 대부분의 판매자가 절대 스크롤하지 않는 페이지 하단 근처에 있는 크롤러 액세스(Crawler access) 항목입니다. 서명(signature)을 생성하여 신뢰할 수 있는 도구에 전달하면, 해당 도구가 귀하의 스토어를 크롤링할 수 있습니다.

라벨에 Signature-Agent가 언급되어 있었기에 저는 그것을 클릭했습니다. Signature-Agent는 우연히 마주치는 문구가 아닙니다. 이는 어떤 자동화된 클라이언트가 접속하고 있는지를 증명하는 것에 관한 일련의 IETF 초안(drafts)에서 유래되었습니다. Shopify는 이를 조용히 출시했습니다.

이것의 실체

Shopify가 저에게 전달한 자격 증명(credential)은 단순히 그로부터 영감을 받은 것이 아니라, 진정한 웹 봇 인증(Web Bot Auth) 산출물입니다:

Signature-Input: sig1=("@authority" "signature-agent");
  keyid="SjjyXvQ2cGhsRXs9DXEaV6ClyCun0Pj5yxjV67dLGOk";
  nonce="e5hRNIchH...Rqw==";
...

약 10줄 정도의 코드로 흥미로운 부분을 직접 확인할 수 있습니다. Shopify는 https://shopify.com/.well-known/http-message-signatures-directory (www 호스트로 리다이렉트됨)에서 하나의 Ed25519 키를 포함하며, 적절한 콘텐츠 타입(content type)으로 제공되는 키 디렉토리를 공개합니다. 해당 키를 가져와 RFC 7638 썸프린트(thumbprint)를 계산한 뒤, 위 서명의 keyid와 비교해 보십시오. 일치합니다. 저희는 자체 도구 체인(toolchains) 두 개로 이를 확인했습니다. 이는 두 개의 조직이 확인하는 것과는 다르므로, 직접 해보시기 바랍니다: crv, kty, x의 정준 JSON(canonical JSON), SHA-256, base64url, 패딩 없음(no padding).

이것은 제가 가장 저렴한 플랜으로 4분 만에 만든 스토어에서, 실제 운영 환경(production)에 적용된 초안 표준(draft standard)의 실제 배포 사례입니다. 다른 무엇이 사실이든 간에, 기반 시설(plumbing)은 여기에 갖춰져 있습니다.

주의 깊게 읽어볼 부분

서명이 무엇을 포함하는지 보십시오: @authority와 signature-agent입니다. 경로는 포함되지 않습니다. 메서드(method)도 포함되지 않습니다. 본문(body)도 포함되지 않습니다. 그리고 이 서명은 30일 동안 유효합니다.

따라서 이것은 에이전트(agent)가 매 요청마다 자신이 누구인지 증명하는 것이 아닙니다. 이것은 Shopify가 '이 세 가지 헤더(header)를 보유한 누구라도 이 상점을 크롤링(crawl)할 수 있다'는 성명서에 서명하는 것이며, 판매자(merchant)가 그 성명서를 도구(tool)에 전달하는 것입니다. 소유(possession)가 전부입니다. 크롤러(crawler) 자신의 키(key)는 어디에도 나타나지 않습니다.

이것은 해당 설계가 해결하려는 문제, 즉 '내가 이미 정문을 통해 알고 있는 이 특정 도구에게 허용한다'라는 관점에서 볼 때 완전히 합리적인 설계입니다. 이것은 검증 프로토콜(verification protocol)의 옷을 입고 있는 권한 토큰(capability token)입니다. 저는 냉소적으로 말하기보다 이 점을 정확히 짚고 넘어가고 싶은데, 그 차이가 이 에세이의 전체 주제이기 때문입니다.

판매자들이 실제로 하고 있는 일

우리는 AI 쇼핑 에이전트(agent)가 하는 방식과 동일하게 사이트들을 조사하는 스캐너(scanner)를 실행하며, ClaudeBot 및 GPTBot이라고 정직하게 식별한 뒤 돌아오는 응답을 기록합니다. 지금까지 스캔한 소규모 전국 소매업체부터 1인 서비스 기업까지 총 22개의 사이트 전반에 걸쳐 결과는 다음과 같습니다.

• 16개는 모든 자동화된 방문자를 허용했습니다.
• 5개는 강력한 403 오류나 CAPTCHA 게이트를 통해 모두 차단했습니다.
• 1개는 판단할 수 없었으며, 우리는 추측하는 대신 그렇다고 명시합니다.
• 0개는 에이전트(agent)를 구분했습니다.

22개는 적은 숫자이며, 저는 이를 설문 조사인 것처럼 꾸미지 않을 것입니다. 하지만 이 결과의 형태는 진지하게 살펴볼 가치가 있습니다. 왜냐하면 양 끝단의 결과는 서로 반대 방향으로 내려진 동일한 결정이기 때문입니다. 모든 것을 차단하는 것과 모든 것을 신뢰하는 것은, 누가 문을 두드리는지 알 수 없을 때 행하는 두 가지 방식입니다.

이 모든 것이 도구가 존재하지 않기 때문에 발생하는 문제는 아닙니다. robots.txt는 수년 동안 에이전트(agent)별 규칙을 표현해 왔으며, user-agent 허용 목록(allowlist)은 그보다 더 오래되었습니다. 해당 샘플에 포함된 모든 사이트는 특정 에이전트(agent)의 이름을 명시하는 규칙을 작성할 수 있었습니다. 문제는 이러한 메커니즘이 권고 사항(advisory)일 뿐이며 인증(unauthenticated)되지 않는다는 점입니다. 어떤 클라이언트(client)든 user-agent 헤더에 어떤 이름이든 입력할 수 있으며, 이를 막을 수 있는 것은 아무것도 없습니다. 낯선 이에게 누구인지 묻고 그 대답을 믿는 것은 보안 제어(security control)가 아닙니다. 그것은 단지 형식(formality)일 뿐입니다.

새로운 것은 어떤 에이전트(agent)가 노크하고 있는지에 대한 암호학적 증명(cryptographic proof)입니다. 그것이 바로 Shopify가 출시한 것이며, 진정으로 유용한 기능입니다.

그리고 아무도 답하지 않은 질문

여기서부터 흥미로워지며, 업계가 앞으로 몇 년간 혼란스러운 시간을 보낼 것이라고 생각되는 지점이 나옵니다.

증명이 작동한다고 가정해 봅시다. 당신의 문 앞에 있는 에이전트가 검증 가능한 ChatGPT이거나, 혹은 당신이 들어본 적 있는 회사의 검증 가능한 쇼핑 어시스턴트라고 가정해 봅시다. 그다음에는 무엇을 해야 할까요?

관리자 화면(admin screen)의 그 어떤 것도 당신에게 알려주지 않습니다. 초안(drafts)에서도 마찬가지이며, 이는 당연한 결과입니다. 왜냐하면 그것은 그들의 역할이 아니기 때문입니다. 정체성(Identity)은 프로토콜(protocol)의 문제이며 프로토콜적인 해답을 가집니다. 검증된 방문자가 무엇을 '벌어야(earn)' 하는가는 비즈니스(business)의 문제이며, 오직 비즈니스적인 해답만을 가집니다.

검증된 에이전트가 당신의 가격을 볼 수 있어야 할까요? 할인을 받을 수 있을까요? 구매를 완료할 수 있어야 할까요, 아니면 사람이 확인하는 장바구니 채우기까지만 허용되어야 할까요? 운영자를 증명하지만 고객이 이 특정 구매를 승인했다는 증거를 가지고 있지 않은 에이전트가, 승인 증거를 가진 에이전트와 동일한 대우를 받아야 할까요? 이것들은 다섯 가지의 서로 다른 정책(policy)이며, 상점은 이 중 어떤 것이든 합리적으로 선택할 수 있습니다.

대부분의 상점은 아무것도 선택하지 않았습니다. 왜냐하면 대부분의 상점은 질문을 받은 적이 없기 때문입니다. 그들은 자물쇠를 건네받았을 뿐, 그 자물쇠가 무엇을 막아야 하는지에 대한 지침은 받지 못했습니다.

쉬운 절반, 그리고 쉽지 않은 절반

정체성 문제가 해결되고 나면, 나머지를 세부 사항(detail)으로 취급하고 싶은 유혹이 생깁니다. 하지만 실제로는 그 반대입니다. 정체성에는 수학적으로 확인할 수 있는 정답이 있습니다. 정책(Policy)에는 오직 트레이드오프(tradeoffs)만이 존재합니다. 수익 대 리스크, 편의성 대 제어, 개방성 대 남용과 같은 것들이며, 제품 가격을 책정해 본 모든 판매자마다 그 비중을 다르게 둡니다.

우리는 나머지 절반을 구축합니다. 이 에세이에서 이것이 우연이 아니라는 점을, 저는 중립적으로 관찰한 척하기보다는 차라리 솔직하게 말씀드리고 싶습니다. 우리의 제품 전체를 관통하는 문장은 _'검증된 정체성(verified identity)은 구매자가 이를 승인했다는 사실이 증명되기 전까지는 지출 권한이 아니다'_이며, 우리는 전환율(conversion)의 손실을 감수하더라도 이 원칙을 고수합니다. 왜냐하면 적당히 타협하는 신뢰 계층(trust layer)은 신뢰 계층이 아니기 때문입니다.

하지만 이 논점은 우리 없이도 유효합니다. 우리가 만든 그 어떤 것도 설치하지 않은 판매자라 할지라도 여전히 이 질문에 답해야 하며, 그 답은 여전히 그들의 몫입니다. 최악의 결과는 잘못된 선택을 하는 것이 아닙니다. 그 분기의 기본값(default)으로 무엇이 배포되느냐에 따라 우연히 선택이 결정되어 버리는 것입니다.

Shopify는 모든 판매자에게 열쇠를 주었습니다. 그 열쇠로 무엇을 열 것인지는 여전히 그들에게 달려 있지만, 그들 중 거의 누구도 자신이 열쇠를 쥐고 있다는 사실을 알지 못합니다.

– N.M.

방법론 참고: 프로브(probes)는 ClaudeBot 및 GPTBot으로서 정직하게 자신을 식별하며, robots.txt 지침을 실시간 응답 코드와 함께 기록합니다. 판정은 도메인당 마지막으로 확인된 깨끗한 관찰값을 사용합니다. 속도 제한(rate-limited)이 걸리거나 도달할 수 없는 프로브는 차단(blocks)으로 간주하지 않고 제외합니다. 관찰할 수 없다는 것은 관찰이 아니기 때문입니다. 특정 도메인을 반복 스캔하던 중 자체적으로 속도 제한이 트리거되었으며, 이를 통해 그 구분이 중요하다는 것을 발견했습니다.

이 조사 결과는 출판 전인 2026년 8월 1일에 IETF web-bot-auth 워킹 그룹(working group)에 보고되었습니다.

AVA Pay™는 AI 커머스를 위한 판매자 측 신뢰 게이트웨이(trust gateway)입니다. AI 쇼핑 에이전트가 이미 보유하고 있는 서명(signatures)을 검증하고, 판매자가 검증된 정체성에 어떤 권한을 부여할지 정책을 설정할 수 있게 해주는 단일 API입니다. github.com/AVA-PAY/ava-pay에서 오픈 소스로 제공됩니다. 더 많은 에세이는 avalayer.com/writing에서 확인하실 수 있습니다.