당신이 결제한 AI 모델을 받지 못했습니다 — 라우팅 시대의 “정체성 위기”

1. 응답 객체 안의 한 줄 — 비밀은 항상 거기 있었다

개발자가 API에 model: "claude-fable-5"를 보내면, API는 평범한 JSON을 돌려줍니다. 그 안에 "model": "claude-opus-4-8"이라는 필드가 있습니다. 에러도 아니고, 재시도 로그도 아닙니다. 그저 실제로 돌고 있던 모델 이름을 응답 객체가 거짓말 없이 적어 둔 것뿐입니다.

이게 바로 예의 바른 버전입니다. 대규모로 배포되는 라우팅 서비스들 중에서, 사용자에게 “응답 자체에” 진실을 알려주는 거의 유일한 사례이기 때문입니다.

2주 뒤 Cursor는 Router를 출시합니다. 60만 건의 실제 요청으로 학습한 분류기가 “질문의 맥락·복잡도·도메인”을 보고 모델을 골라 보냅니다. 얼리 액세스 계정 세 곳에서 Opus 4.8로 전부 라우팅했을 때 대비 30~50% 비용 절감을 보고했습니다. 라우팅 규칙은 공개했지만, “이 작업엔 이 모델”이라는 작업별 배정표는 공개하지 않았습니다.

그리고 그 아래 집계 계층에서 OpenRouter는 가중치의 양자화(quantization)를 통해 더 싼 공급자가 더 낮은 가격에 응답을 돌려줄 수 있고, 그 응답은 “원래 정밀도로 돌렸을 때의 결과”와 다를 수 있다고 경고합니다. 사용자 로그에는 “저정밀도로 돌았다”는 사실이 남아 있지 않습니다.

서로 다른 세 제품. “모델이란 무엇인가”에 대한 서로 다른 세 가지 답. 그러나 어떤 답이 법적으로 받아들여지는지에 대한 판례는 아직 단 하나도 없습니다.

2. 이름이 더 이상 의미를 갖지 않게 되는 세 가지 방식

모델의 신원(model identity)은 사실 세 개의 독립적인 축을 따라 무너지는데, 보통은 구분되지 않습니다. 하나씩 풀어보겠습니다.

엔지니어링 커뮤니티는 이 셋을 “신뢰성 문제”로 다룹니다. 하지만 이건 그보다 한 단계 더 깊은 정체성 문제입니다. 정체성은 결국 계약, 보증, 공시, 증거 규칙이 짜이는 토대이기 때문입니다.

3. 당신은 실제로 무엇을 산 건가?

상거래법에서 가장 오래된 질문을 꺼내보겠습니다. “그 설명이 계약의 조건이었나?”

만약 API 호출이 ‘상품의 매매’라면 답은 거의 자명합니다. 미국 UCC §2-313(1)(b)는 “거래의 기초(basis of the bargain)”의 일부가 된 상품 설명을 곧 명시적 보증으로 만듭니다. 인도의 1930년 상품매매법 §15도 같은 결론입니다.

“상품의 설명이 거래의 기초의 일부가 될 때, 그 상품이 그 설명에 부합한다는 명시적 보증이 자동적으로 성립한다.”
— UCC §2-313(1)(b), Cornell Law LII

문제는 추론 API는 거의 확실히 ‘상품’이 아니라는 점입니다. 법원은 보통 호스팅 소프트웨어를 서비스로 봅니다. 그러면 보증법 영역을 빠져나가 일반 계약법으로 들어가고, 답은 전적으로 “문서에 무엇이라 적혀 있었는가, 구매자가 얼마나 구체적으로 협상했는가”에 달려 있습니다.

4. 공시의 기울기 — 다크 패턴의 시대

미국 FTC의 기만법은 두 부분으로 적용됩니다. 허위표시는 그것이 중대하고 합리적으로 행동하는 소비자를 오인할 가능성이 있을 때 소구 가능합니다. 객관적 성능 주장은 추가로 배포 이전에 합리적 근거가 요구됩니다. 세 제품을 이 축에 놓으면 다음과 같습니다.

문서 깊은 곳에 묻어 있고, 사용자에게 불리하게 기본 설정된 공시 — 다른 어떤 소비자 영역에서든 규제기관이 다크 패턴이라 부르는 바로 그 구조입니다.

여기에 경쟁법의 꼬리도 있습니다. 수직적 포클로저가 일어나는 추론 시장에서 워킹페이퍼들은 라우팅 투명성, 서비스 품질 평등, FRAND식의 비차별 원칙에 토대를 둔 행동 틀을 제안합니다. 동시에 라우터를 만드는 회사가 자기선호(self-preferencing) 엔진이 될 수도 있습니다. “비용 최적화”라는 명목의 라우팅이 사실상 자기만의 모델을 밀어주는 것일 수 있다는 뜻입니다.

5. 아무도 보지 않는 부분: 인증

진짜 싸움은 결제가 아니라 증거에서 벌어집니다. 미국 연방증거규칙 FRE 902(13)·902(14)는 “전자 시스템에 의해 생성된 기록” 또는 “해시로 검증된 데이터”가 인증서를 통해 자기 인증(self-authenticate)되도록 허용합니다. 인도의 2023년 Bharatiya Sakshya Adhiniyam §63도 같은 결론입니다. 단, 모든 조항은 당신이 시스템을 명명할 수 있다고 가정합니다.

시나리오를 돌려보겠습니다. 한 변호사가 날조된 인용을 포함한 답변서를 냈습니다. 제재 절차가 시작됩니다. 법원은 묻습니다. “어떤 모델이 이 답변을 냈는가?”

• 사무소의 로그: fable-5라고 기록.
• 공급자의 로그: 분류기가 발동했고, 실제 응답은 Opus 4.8.
• 또는 요청은 이름 모를 모델을, 명시되지 않은 정밀도로, 이후 폐기된 버전에서 선택한 IDE 라우터를 거쳐 갔을 수도 있습니다.

이때 끊어지는 것은 연쇄 보관(chain of custody)이고, 그것은 모델이 아니라 라우터에서 끊어집니다. 그리고 그것은 양방향으로 끊어집니다.

• 내 산출물을 인증하려는 측은 실패합니다.
• 상대방의 산출물을 공격하려는 측은 전문가도 반박할 수 없는 독립적인 신뢰성 논거를 갖게 됩니다.

6. 해법은 조항이 아니라 서명이다

이 문제에서 계약起草로 빠져나갈 수 없습니다. 왜냐하면 당신에게 필요한 표명은 런타임 사건(runtime event)에 관한 것이고, 계약은 정적이기 때문입니다.

법이 결국 요구하게 될 것은 검증 가능한 모델 정체성(attestable model identity)입니다. 구체적으로는 이렇게 생긴 것입니다.

1. 각 응답에 “서버된 모델 식별자 + 가중치 해시 + 정밀도 + 시스템 프롬프트 해시”의 튜플을 묶어서 함께 반환.
2. 그 튜플을 하드웨어 인증으로 서명. 즉, 신뢰 컴퓨팅 GPU 플랫폼이 이미 지원하는 TEE(Trusted Execution Environment) 뿌리의 키로 서명.
3. 구매자는 판매자를 신뢰하지 않고도, 표준 라이브러리 한 번 호출로 그 서명·해시를 검증할 수 있어야 함.

응답 헤더의 해시가 모델 정체성에 대해 하는 일은, FRE 902(14)가 사본 데이터에 대해 하는 일과 정확히 같습니다. “이게 사실인가?”라는 쟁점을 “이 서명이 유효한가?”라는 인증서 문제로 바꾸는 것이 핵심입니다.

이 원시 요소는 사실 절반쯤 이미 만들어져 있습니다. 응답 객체는 “서버된 모델 이름”을 담고 있습니다. 부족한 것은 그것을 법적으로 유용하게 만드는 속성입니다. (1) 그 진술이 거짓으로 주장될 수 없고, (2) 구매자가 판매자를 신뢰하지 않고도 검증할 수 있다는 점.

용어 한 번에 읽기

더 깊이 알고 싶다면 UCC §2-313, FRE 902, Confidential Computing Consortium을 추천합니다.