코드는 법이 아니다: 법적 컨텍스트 프로토콜

Key Takeaways

• 지난 6월 24일 미국중재협회(American Arbitration Association)와 인테그라 레저(Integra Ledger)를 비롯한 컨소시엄이 법적 컨텍스트 프로토콜(Legal Context Protocol)을 공개했다. 에이전트가 사람을 대신해 결제하고 약관을 수락하는 거래가 늘어나는 동안, 정작 그 거래가 어떤 약관과 어느 관할의 법 아래에서 이루어졌고 문제가 생기면 어떤 절차를 따르는지를 남기는 계층이 비어 있었다는 문제의식에서 출발한 표준이다.
• LCP는 새로운 기술을 제안하는 표준이 아니라 약관이 놓이는 위치를 표준화하는 표준이다. 모든 서비스가 고정된 경로에 약관 문서의 주소를 담은 JSON 파일을 두도록 하고, 그 위에 해시 검증과 서명된 동의, 분쟁 해결 연동을 선택적으로 쌓는 네 단계 구조를 갖는다. LCP는 블록체인을 의무적으로 요구하지 않으며, HTTPS를 지원하는 웹 서버만 있으면 구현된다.
• 흥미로운 지점은 LCP가 에이전트 거래를 온체인에서 종결하는 대신 기존 인간 법체계로 되돌려 연결한다는 데 있다. 표준은 어떤 체인의 사용도 의무적으로 요구하지 않지만 검증과 서명, 저장으로 올라가는 상위 단계는 해시와 콘텐츠 주소화 같은, 블록체인이 더 신뢰가능한 방식으로 제공 가능한 방식을 사용한다. 또한 창립 기여자로 모인 체인 다수가 실물 자산과 결제를 겨냥해 온 곳들이며, 그중 수이(Sui)는 자신들의 저장 및 암호화 스택을 그 상위 단계에 곧바로 연결할 수 있는 위치에 있다.

1. 에이전틱 커머스의 법적 계층, LCP

Source: AAA

지난 6월 24일, 미국중재협회(American Arbitration Association, 이하 AAA)와 인테그라 레저는 법적 컨텍스트 프로토콜(Legal Context Protocol, 이하 LCP)이라는 개방형 표준을 공개했다. LCP는 에이전트가 사람이나 조직을 대신해 거래할 때 법적 약관과 동의, 분쟁 해결 절차를 발견 가능하고 검증 가능하게 만드는 것을 목표로 하며, 구글, IBM, 서클(Circle), 미스텐 랩스(Mysten Labs), 세이 랩스(Sei Labs), 앱토스(Aptos), 아바 랩스(Ava Labs), 스텔라(Stellar)를 비롯한 여러 인프라 및 블록체인 기업이 초기 기여자로 참여했다.

지난 1년간 에이전틱 커머스(agentic commerce) 영역에서는 결제와 신원 인증을 위한 프로토콜이 빠르게 등장했다. 스트라이프와 템포 랩스의 기계 결제 프로토콜(MCP), 코인베이스와 클라우드플레어가 주도하는 x402, 오픈AI와 스트라이프의 에이전틱 커머스 프로토콜(ACP), 구글이 여러 유통 기업과 함께 만든 범용 커머스 프로토콜(UCP), 비자의 신뢰 에이전트 프로토콜(Trusted Agent Protocol), 마스터카드의 검증 가능 의도(Verifiable Intent)에 이르기까지, 에이전트의 결제와 신원 증명에 대한 인프라는 이미 다수가 등장한 상태이다.

그러나 다수의 프로토콜들의 등장에도 불구하고 아직까지 법적인 영역은 비어있었다. 결제 프로토콜은 얼마가 지불되었는지를 다루고, 신원과 권한 프로토콜은 누가 그 거래를 승인했는지를 다루지만, 그 거래가 어떤 약관 아래에서 어느 나라 법의 지배를 받으며 잘못되었을 때 어떤 구제 수단을 갖는지는 어느 쪽도 기록하지 않았다. LCP는 이 영역을 채우기 위해 등장한 프로토콜이다.

사람 간의 거래를 생각해보면, 법적인 기록은 의도적으로 만들어내는 것이 아니라 상호작용의 부산물로 자연스럽게 남게 된다. 상호간에 주고받은 메시지나 서명된 계약서가 남고, 나중에 무엇을 합의했는지 증언할 수 있는 사람이 존재한다. 약관을 둘러싼 다툼이 오래도록 해결 가능했던 것은 입증에 필요한 흔적이 거래 과정에서 저절로 생겨났기 때문이다.

그런데 에이전트가 하루에 수백만 건의 거래를 기계 속도로 처리하기 시작하면 이 전제가 흔들릴 수 밖에 없다. 부산물로 남던 기록은 당사자마다 어긋나거나, 파편화되거나 유실될 수 있으며, 사람 규모에서는 일상적이고 복구 가능했던 일이 에이전틱 커머스로 확장되며 관리가 어려운 규모의 계약 처리로 인해 새로운 법적 리스크가 발생할 수 있다.

예를 들어, 어떤 회사가 수백 개의 구매 에이전트를 돌려 필요한 서비스를 자동으로 조달하는 상황을 생각해보자. 그중 한 에이전트가 인도의 어느 공급업체로부터 인공지능 학습용 데이터셋을 사들였는데, 거래는 양측 에이전트가 사람의 검토 없이 몇 초 만에 끝냈다. 며칠 뒤 데이터의 절반이 약속과 다른 손상된 파일이었음이 드러나고, 환불을 받으려는 순간 곤란한 질문들이 쏟아진다. 그 거래에는 어떤 약관이 적용되었는지, 에이전트가 동의를 누른 약관이 지금도 같은 내용인지, 아니면 공급업체가 사후에 바꿨는지, 분쟁은 인도 법으로 처리해야 하는지 아니면 한국 법으로 처리해야 하는지, 애초에 어디에 항의를 접수해야 하는지 등등... 손에 쥔 것이라고는 돈이 오갔다는 결제 기록뿐인데, 정작 그 돈이 어떤 조건 아래 오갔는지를 말해주는 기록은 어디에도 없다.

LCP는 이러한 거래의 흔적을 표준화되지 않은 부산물에 맡기지는 데에서 벗어나, 거래 과정의 설계에서 하나의 기본 요소로 포함시키고자 한다.

2. LCP는 어떻게 동작하는가

LCP의 명세와 함께 공개된 깃허브 저장소에는 JSON 스키마와 단계별 예제 파일이 들어 있어, 표준이 실제로 어떤 형태로 작동하도록 설계되었는지를 비교적 구체적으로 확인할 수 있다. 이 장에서는 발견 문서의 구조부터 검증이 일어나는 시점, 그리고 다른 프로토콜에 끼워 넣는 방식까지를 차례로 살펴본다.

2.1 약관 문서의 구조

표준이 요구하는 것은 사실상 하나다. 서비스를 운영하는 주체가 자신의 도메인 아래 고정된 경로에 작은 JSON 파일을 올려두는 것이다.

공개된 JSON 스키마는 이 문서에서 반드시 채워야 하는 항목으로 terms 하나만을 지정한다. 약관 문서가 어디에 있는지를 가리키는 절대 주소이다. 스키마는 이 값이 반드시 https://로 시작하도록 강제하는데, 이는 도메인의 TLS 인증서를 신원 확인 장치로 사용하기 위함이다. 이로써 별도의 공개키 기반구조 도입 없이 다른 파일들이 이미 쓰고 있는 신뢰 모델을 그대로 따르도록 하는 구현이 가능해진다.

이러한 발상 자체는 새로운 것이 아닌 것이, 웹에서는 이미 robots.txt가 크롤링 규칙을 모두에게 같은 방식으로 알리고 있으며, /.well-known/openid-configuration이 신원 설정을 발견 가능하게 만들어 온 전례가 있기 때문이다. LCP는 같은 방식을 법적 맥락에 적용해, 약관이 /terms , /tos , 또는 별도의 PDF 내에 숨겨져 있는 파편화되어있던 상황을 항상 같은 자리에 두도록 강제한다.

나머지 필드는 모두 선택 사항이며, 저장소에 포함된 가장 완전한 형태인 4단계 예제를 보면 표준이 담을 수 있는 정보의 범위를 확인할 수 있다.

Source: LCP GitHub

아래는 표준에 담긴 정보들 중 특징적인 필드에 대한 간단한 정리이다.

• testFormat: 약관 문서의 형식을 미리 알려주는 항목이다. 에이전트가 읽을 약관이라면 Markdown이나 JSON, 평문처럼 기계가 곧바로 해석할 수 있는 형식을 권고하고 있으며, PDF나 HTML 같은 화면 배치 위주의 형식은 권하지 않고 있다.
• disputeResolution: 거래 분쟁 해결에 대한 조항을 다룬다. clauseId 라는 해시를 넣도록 되어있는데, 조항 원문을 source 주소에서 가져와 해시를 다시 계산하면 그 값이 일치하는지 누구나 확인할 수 있다.

2.2 네 단계의 신뢰 수준

LCP는 신뢰 보증의 강도에 따라 네 단계를 제시하며, 각 단계는 독립적으로 가치를 가지므로 아래 단계를 구현하지 않고도 특정 단계만 채택할 수 있다.

• 1단계 - 정보 제공(Informational): 정해진 주소를 통해 약관을 읽을 수 있다. 에이전트가 약관을 발견한 뒤 거래를 진행하면 그 자체가 동의로 간주되는데, 이는 우리에게 익숙한 클릭랩(clickwrap) 계약의 법리를 그대로 가져온 것이다. 해시나 서명, 블록체인은 필요로 하지 않는다.
• 2단계 - 증명 가능(Provable): 약관 문서의 SHA-256 해시(atrHash)를 함께 게시한다. 이 해시는 약관이 정확히 무엇이었는지를 지목하는 동시에 그것이 바뀌지 않았음을 입증한다. 누구든 문서를 내려받아 해시를 계산했을 때 같은 값이 나와야 하며, 값이 어긋난다면 문서가 변조되었다는 뜻이다. 다만 해시를 제공하려면 약관 문서가 매번 바이트 단위까지 동일하게 제공되어야 하므로, 세션마다 내용이 달라지는 동적 렌더링은 허용되지 않는다.
• 3단계 - 서명됨(Signed): 상대방이 약관에 대한 디지털 서명을 하도록 요구한다. 코드 예시에서는 이에 대한 예시로 이더리움 진영의 EIP-712 서명을 들고 있다. 이 단계에서는 약관이 증명 가능한 데 더해, 특정 당사자가 특정 약관에 특정 시점에 명시적으로 동의했다는 암호학적 증거가 만들어진다.
• 4단계 - 통합됨(Integrated): 분쟁 해결과 에스크로, 컴플라이언스 준수, 비공개 약관과 같은 더 무거운 법률 인프라로 연결되는 고리를 건다. api 필드를 통해 별도의 진입점을 제시하며, 이 단계에서는 약관이 공개적으로 읽히지 않고 인증된 당사자만 접근하도록 제한할 수도 있다.

2.3 검증은 언제 일어나는가

LCP는 검증이 일어나는 시점을 발견 시점과 거래 시점으로 명확히 구분한다. 발견 시점은 에이전트가 legal-context.json을 방문해 이 서비스가 약관을 어떻게 다루는지 파악하는 단계로, 어디까지나 정보 확인의 성격을 갖는다. 반면 실제로 약관을 가져와 검증하고 보관해야 하는 순간은 거래 시점이며, 해시가 의미를 갖는 것도 이 단계에 해당한다.

MCP의 402 챌린지, x402의 402 응답, ACP의 체크아웃 세션 생성처럼, 주요 에이전틱 커머스 프로토콜은 모두 제안과 실행이라는 두 단계 흐름을 갖는다. LCP는 약관 해시를 영수증이 아니라 제안 단계에 실으라고 권고하는데, 이렇게 해야 에이전트가 돈을 내기 전에 약관을 검증할 수 있기 때문이다. 2단계 이상에서 에이전트가 따르는 절차는 대략 다음과 같다.

1. 제안 단계에서 서버가 제시한 atrHash(약관 전체에 대한 해시)를 받는다.
2. terms 주소에서 약관 문서를 내려받는다.
3. 내려받은 문서의 SHA-256 해시를 직접 계산한다.
4. 계산한 값을 제시된 atrHash와 비교하고, 일치하지 않으면 거래를 중단한다.
5. 문서를 로컬에 사본으로 저장한다.
6. 결제를 진행한다.
7. 동일한 해시가 담긴 영수증을 받아, 합의된 내용을 사후에 확인한다.

LCP는 이러한 구조를 통해 악의적인 동작이 발생할 수 있는 환경인 발견 시점과 거래 시점 사이에 약관이 바뀌는 경쟁 상태(race condition), 그리고 서버가 사후에 다른 약관을 주장하는 상태를 동시에 차단한다고 설명한다. 검증이 결제 직전이라는, 실제로 의미가 있는 순간에 이루어지기 때문이다. 1단계에서는 비교할 해시가 없으므로 에이전트가 변경을 탐지할 수단은 없지만, 그 경우에도 거래 시점에 본 약관을 사본으로 저장해 증거로 남겨두도록 권고하고 있다.

2.4 다른 에이전틱 프로토콜과의 조합성

LCP는 새로운 결제망이나 체인을 만들지 않는 대신, 이미 존재하는 프로토콜 안에 끼워 넣을 수 있는 참조 형식을 함께 정의한다. 프로토콜마다 데이터를 담는 방식이 다르기 때문에 하나의 형식으로 통일하지 않고, 문자열 / 해시 / json 등 여러 형태를 지원하도록 하고 있다. 어느 경우든 받는 쪽이 인식하지 못하는 필드는 무시하도록 설계되어 있어, 기존 프로토콜의 핵심 명세를 고치지 않고 통합이 가능하도록 설계되어 있다.

LCP를 다른 프로토콜과 결합시킨 시나리오를 예시로 들어보겠다.

1. 어떤 사용자가 구매 에이전트에게 일정 한도 안에서 클라우드 API 사용권을 구매하도록 위임했다고 가정하자.
2. 사용자의 위임은 구글 AP2의 카트 권한 위임(Cart Mandate)으로 서명되어, 에이전트가 어떤 품목을 얼마까지 살 수 있는지에 대한 고정이 이루어진다.
3. 에이전트가 판매자 서버에 접근하고, 결제 직전 단계인 402 응답에 판매자의 LCP 참조가 함께 첨부된다.
4. 에이전트는 그 약관 문서를 내려받아 해시를 대조한 뒤 명시된 관할과 분쟁 절차를 확인하고, 필요한 경우 3단계 서명으로 동의를 남긴 다음 결제를 진행한다.
5. 거래가 끝나면 두 갈래의 증거가 남는다. AP2 권한 위임은 사용자가 무엇을 승인했고 에이전트가 그 한도를 지켰는지를 증명하고, LCP 기록은 판매자가 어떤 약관을 내걸었으며 양측이 그 약관에 동의했는지를 증명한다.
6. 이후 납품이 이루어지지 않아 분쟁이 생기면, 권한 프로토콜 쪽 증거는 에이전트가 정당하게 권한을 받아 한도 안에서 움직였는지에 답하고, LCP 쪽 증거는 그 거래가 어떤 약관과 관할 아래 있었으며 어디로 분쟁을 가져가야 하는지에 답한다.

한편 LCP 예제는 모델 컨텍스트 프로토콜(Model Context Protocol)을 통한 전달 방식도 함께 제시하고 있다. LCP를 하나의 MCP 서버로 구현하면 약관을 가져오는 get_legal_context, 약관이 게시된 해시와 일치하는지 확인하는 verify_terms, 동의를 기록하는 accept_terms, 분쟁을 제기하는 initiate_dispute 같은 도구를 노출할 수 있다. 이 경우 MCP를 지원하는 에이전트는 어떤 결제 프로토콜로 거래하든 동일한 방식으로 법적 맥락을 조회할 수 있게 된다.

3. 시사점

3.1 코드는 법이 아니다

LCP에서 가장 따져볼 만한 부분은 그 주도 주체와 메시지 사이의 긴장이다. 기술 측 스튜어드인 인테그라 레저는 블록체인 기업이지만, 이들이 만든 표준은 블록체인을 필수 요소로 두지 않고 있다.

크립토의 초기 서사 가운데 하나는 코드가 곧 법(Code is Law)이라는 명제였다. 스마트 컨트랙트가 분쟁의 여지 없이 자동으로 집행되며 종국에는 법률 계약과 인간의 사법 체계를 대체하리라는 전망이었다. LCP는 이 방향과 반대로 온체인에서 집행을 완결하려는 대신, 기계의 거래를 다시 인간의 법체계로 되돌려 연결하고 관할과 분쟁 기관, 구제 수단이 어디에 있는지를 명시적으로 가리키고 있다. 이는 코드가 법을 대신하는 것이 아니라 코드가 법으로 가는 길을 표시하는 수단으로 사용되는 방식이라고 정리할 수 있다.

100년의 역사를 가진 중재 기관인 AAA가 LCP의 주요 축으로 참여한 사실은 이러한 방향을 잘 보여준다. 크립토는 오랫동안 신뢰받는 중개자를 코드와 탈중앙화로 대체하려 했지만, LCP의 설계는 법적 제도를 분쟁 해결의 최종 보루로 의도적으로 다시 끌어들이고 있다. 이는 에이전트 경제의 병목이 무신뢰성(trustlessness)이 아니라 발견 가능성과 구제 가능성에 있다는 것을 전제로 하는 것이다. 에이전트가 아무리 빠르게 거래한다고 하더라도 문제가 생겼을 때 결국 호소할 곳은 현실의 법정과 중재 기관이라면, 그곳으로 가는 경로를 기계가 읽을 수 있게 표시해 두는 일이 더 시급하다는 것이다.

블록체인을 의무에서 선택으로 내린 결정도 같은 맥락에 있다. 해시와 서명, 온체인 기록은 신뢰를 보강하는 도구로 남되 표준에 진입하는 장벽이 되지는 않으며, 블록체인 기업이 자신의 핵심 기술을 부차적인 위치에 둔 이 선택은 현재 에이전트에 대한 법적 표준의 채택을 가로막는 가장 큰 장애물이 기술의 부재가 아니라 도입의 복잡성이라는 인식을 전제로 한 것으로 보인다.

따라서 이는 결코 LCP가 블록체인을 배척하는 것이 아니다. 표준의 바닥인 1단계는 어떤 체인의 사용도 요구하지 않지만, 그 위의 단계에서 사용되는 해시와 서명, 컨텐츠 주소 저장 등은 블록체인이 더 신뢰 가능한 형태로 제공 가능하기 때문이다. 더 높은 수준의 법적 제약을 제공하고자 할 수록 블록체인의 사용은 더 요구될 것이다.

3.2 참여 체인들의 성격, 그리고 수이

공식 발표 자료는 기여자를 세 개의 묶음으로 나누고 있다. 구글과 IBM, 서클, 유아이패스(UiPath), 웨이페어 같은 엔터프라이즈 및 결제 기업, 스텔라(Stellar)와 아발란체(Avalanche), 카르다노(Cardano), 헤데라(Hedera), 앱토스(Aptos), 세이(Sei), 그리고 수이와 같은 블록체인 네트워크, 마지막으로 크로스민트(Crossmint)와 피나타(Pinata) 같은 신원 및 인프라 제공자다.

블록체인 네트워크 쪽의 참여자들은 다수가 실물 자산과 결제, 기관 거래를 겨냥하고 있는 체인들이다. 스텔라는 국경 간 결제를, 헤데라는 기업 컨소시엄 거버넌스를, 수이는 결제와 기관 거래로의 확장을 지향하고 있다. 반대로 가장 큰 스마트 컨트랙트 생태계인 이더리움과 솔라나, x402를 주도하는 코인베이스 진영은 창립 기여자 명단에 보이지 않는다. LCP의 서명 예제에서 이더리움의 EIP-712가 사용되었다는 점을 생각하면 이더리움의 부재는 오히려 더 눈에 띈다.

이러한 참여자 구성은 LCP가 크립토의 어느 쪽을 위한 도구인지를 시사한다. 코드가 곧 법이라는 무신뢰 디파이 문화의 체인들이 아니라, 온체인 거래가 현실의 집행 가능한 법적 합의로 이어진다는 점을 기업 고객에게 설득해야 하는 실물 자산 및 기관 지향 체인들이 모였다. 이들에게 법적 계층의 부재는 추상적 결함이 아니라 실제 도입을 막는 장벽이며, LCP는 그 장벽을 낮추는 도구가 될 수 있다.

그중에서도 수이의 참여 방식은 특히 시사적이다. 수이의 원형과도 같다고 할 수 있는 메타(Meta)의 디엠(Diem) 프로젝트가 기술적 기여에도 불구하고 규제와 법적 저항에 막혀 좌초했고, 그 경험을 직접 통과한 팀이 이제 법적 계층 표준의 창립 기여자로 들어온 셈이기 때문이다.

더 구체적으로는, 수이가 이미 구축했거나 출시 중인 인프라가 LCP의 상위 신뢰 단계가 요구하는 것과 거의 그대로 겹친다. 앞서 보았듯 2단계 이상은 약관 문서를 컨텐츠 주소 기반으로 저장할 것을 권장하고 있으며, 4단계의 비공개 약관은 접근 제어와 암호화를 요구한다.

미스틴랩스의 분산 저장 프로토콜 월루스(Walrus)는 큰 이진 파일을 이레이저 코딩(erasure coding)으로 쪼개 분산 저장하고 그 참조인 블롭 ID를 수이 온체인에 기록하는데, 이는 컨텐츠의 내용에 따라 저장 위치 식별자를 결정론적으로 생성해 컨텐츠의 무결성을 검증할 수 있도록 한다. 이는 LCP가 약관 산출물을 둘 곳으로 제시한 컨텐츠 주소 저장소와 성격이 일치한다.

또한 미스틴랩스의 씰(Seal)은 무브 정책으로 누가 언제 어떤 조건에서 데이터를 복호화할 수 있는지를 온체인에서 규정하는 임계값 암호화(threshold encryption) 도구로, 암호화를 위치가 아니라 데이터 자체에 묶는다는 그 설계 원칙은 LCP가 비공개 약관 설계시 권고한 평문 해시 후 암호화 방식과 같은 결에 해당한다. 씰이 에이전트 결제를 응용 예시로 내걸고 있다는 점을 생각하면, 수이는 약관의 저장과 보호라는 측면에서 LCP의 상위 단계와 자연스럽게 맞물릴 인프라를 이미 갖추고 있다고 볼 수 있다.

수이에게 LCP는 멀리서 지지하는 추상적 표준이라기보다, 자신들이 에이전틱 커머스를 위해 이미 만들고 있던 저장과 암호화 스택 위에 곧바로 얹히는 발견 및 법률 계층에 가깝다. 다른 체인들 역시 비슷한 계산을 하고 있을 것이다. 표준 자체가 중립적이라 해도, 그 위에서 약관을 저장하고 암호화하고 앵커링하는 실제 작업이 어느 체인에서 일어나는가를 둘러싼 경쟁은 이제 막 시작되었다.

3.3 LCP는 살아남는 표준이 될 수 있을까?

LCP의 접근이 신선하고 현재 에이전틱 커머스 표준 정립 과정에서 비어있는 부분임은 분명한 사실이지만, 좋은 표준이 제안되는 것과 그 표준이 실제로 쓰이는 것은 전혀 다른 문제다. 웹의 역사에는 좋은 의도로 만들어졌지만 거의 채택되지 않은 표준들이 적지 않다 (애초에 402부터가 그렇다). 그렇다면 LCP가 표준으로 자리잡거나 사장되는 조건을 객관적으로 따져 생존 가능성을 가늠해보자.

LCP에 유리한 조건은 다음과 같다.

1. 채택 비용이 사실상 0에 가깝다. JSON 파일 하나를 정해진 경로에 올리면 끝이고, 블록체인의 사용은 의무가 아니며, 수수료도 가입 절차도 없다. robots.txt 같은 선례가 보여주듯, 진입 비용이 충분히 낮은 웹 관습은 의무가 없어도 광범위하게 퍼질 수 있다.
2. LCP는 다른 프로토콜에 편승하며 확장 가능하다. 독자적인 결제망을 깔 필요 없이, x402나 기계 결제 프로토콜, ACP 같은 호스트 프로토콜이 확장 필드 하나를 받아주기만 하면 그 위에 얹혀 함께 사용될 수 있다. 표준에 대한 경쟁 상대가 없고, 쉽게 다른 프로토콜에 통합될 수 있는 구조는 분명 확장에 유리하다.
3. 풀려는 문제 자체가 시간이 갈수록 커지고 있다. 현재 에이전틱 커머스가 유의미한 규모로 확장되지 않은 상태이지만, 거래가 늘어날수록 법적 기록의 부재는 페인포인트로 작용하게 될 것이다. 구독 상품의 서비스 품질에 대한 분쟁, 구입한 상품에 대한 교환/환불 요청 과정, 에이전트 간 구매 경쟁 과정에서 발생하는 레이스 컨디션으로 발생하는 오류 등등 이미 웹2 환경에서 존재하는 다양한 분쟁 요소들이 동일하게 에이전틱 커머스에서 발생할 수 있으며, 법적 분쟁으로 확산될 시 LCP에 남긴 증거들은 강력한 증거로 활용될 수 있을 것이다.

그렇다면 LCP에 불리한 조건들은 어떤 것이 있을까?

1. 가장 큰 것은 LCP를 따르도록 강제하는 장치가 어디에도 없다는 것이다. TLS는 브라우저가 사실상 강제하고 robots.txt는 크롤러가 관행으로 존중하지만, 약관 자체에 대해서는 올리지 않는다고 당장 불이익을 받는 주체가 존재하지 않는다. 강제 장치 없이 자발적 가치 판단에만 기대는 표준은 보안 분야의 security.txt처럼 존재는 하되 채택은 들쭉날쭉한 상태에 머물기 쉽다.
2. 또한 LCP의 효용은 대체로 분쟁이라는 드문 상황에서, 그것도 거래 규모가 커진 뒤에야 실현될 수 있다. 비용은 지금 들고 편익은 나중에 가끔 발생하는 구조는 채택자(판매자)를 설득하기 어렵다.
3. 마지막으로, 호스트 프로토콜이 같은 기능을 자체적으로 흡수해버릴 위험이 있다. ACP나 UCP는 이미 약관 URL 필드를 갖고 있어, 마음먹으면 LCP 없이도 무결성과 동의를 자체 확장으로 구현할 수 있다. 이에 더해 가장 큰 커머스 프로토콜을 쥔 오픈AI와 스트라이프, 코인베이스는 LCP의 창립 기여자가 아니다. 이들이 LCP를 채택하는 대신 자기 규격에 법적 계층을 직접 넣기로 한다면, LCP는 그 자리를 잃어버릴 수 있다.

따라서 LCP는 어느 정도의 채택은 평균 이상으로 기대할 만하지만, 활발하고 광범위한 사용은 스스로가 통제하지 못하는 소수의 길목, 즉 주요 커머스 프로토콜과 에이전트 런타임이 이를 기본값으로 받아들이느냐에 달려 있다고 생각된다. 필자는 이러한 문제가 결국 100년 이상의 업력을 가진 중재기관이자 LCP의 주요 기여자인 AAA, 그리고 그 외의 명망있는 참여 기관들이 LCP가 실제 분쟁 상황에서 실질적인 법적 효력을 가질 수 있음을 증명함으로써 해소될 수 있을 것이라고 생각한다.