curl -s -o /dev/null -w '%{http_code}
' -X POST https://<gateway>/v1/chat/completions \
  -H 'Content-Type: application/json' -d '{

`401`은 경로가 존재하지만 키를 누락했음을 의미하고, `404`는 경로 자체가 존재하지 않음을 의미합니다. 이 차이가 전체 테스트의 핵심입니다.

**2. 키 없이 모델 목록을 읽을 수 있으며, 날짜 정보가 포함되어 있습니까?** 카탈로그에 키가 필요하다면, 비용 지출 없이 자체 설정과 비교(diff)할 수 없습니다. 페이지에서 언제 조회했는지 언급하지 않고 개수를 인용하는 경우, 그 숫자는 이미 잘못된 것입니다.

**3. 모델 식별자(model identifiers)는 무엇이라고 불립니까?** 이것이 여러분의 이탈 비용을 결정합니다. 만약 ID가 공급업체의 공급망(`somevendor/some-relay/모델명`)을 인코딩한다면, 코드에 있는 모든 ID는 모델 자체에 대한 사실이 아니라 그들의 비즈니스에 관한 사실입니다. 공급망이 변경될 때마다 여러분의 문자열도 변경됩니다.

**4. 무료 등급(free tier) 사용 시 카드 결제가 필요합니까?** 가격 페이지를 읽어보는 방식이 아닌, 새로운 계정으로 테스트해 보세요.

**5. 상위 등급을 초과하는 요청은 거부됩니까, 아니면 조용히 청구됩니까?** 권한이 없는 것을 요청해 보세요. 여러분이 원하는 것은 요금이 부과되는 것이 아니라 `402` 응답입니다.

다섯 번째 점검에는 첫 번째보다 더 중요한 두 번째 부분이 있습니다. 즉, 게이트웨이 내부의 공급자가 실패했을 때 무슨 일이 일어나는지 확인하는 것입니다. 클라이언트에게 반환된 오류는 정직합니다. 여러분을 대신하여 모델을 교체하는 조용한 폴백(silent fallback)은 그렇지 않으며, 이는 평가 점수(eval scores)에서만 알아차릴 수 있습니다.

## ID 검사가 비용이 많이 드는 이유

저는 게이트웨이를 운영하기 때문에 저의 서비스 중단 사례를 예로 들겠습니다. 9월 22일 저희 공개 모델 목록은 477개의 항목을 반환했습니다. 9월 29일에는 동일한 엔드포인트를 인증 없이 호출했을 때 199개가 반환되었습니다. URL과 응답 형태는 같지만, 카탈로그가 달랐습니다. 그 이유는 해당 URL 뒤에 있는 구현체가 교체되었기 때문입니다.

개수(count)는 눈에 보이는 부분일 뿐입니다. 피해는 식별자(identifiers)에 있었습니다. 새 엔드포인트의 ID에는 각 모델을 제공한 상위 레레이(upstream relay)의 이름이 포함되어 있었고, 이는 이전 ID가 다르게 해석되고 한 계열의 별칭(alias)은 아예 더 이상 해석되지 않음을 의미했습니다. 목록을 캐싱했거나 모델 문자열을 하드코딩했던 모든 클라이언트는 오류 메시지조차 없이 작동을 멈췄습니다.

이것이 실제로 탈출을 시도하기 전의 '퇴장 비용'처럼 보입니다. ID가 중립적이라면, 이동은 기본 URL 변경에 불과합니다. 하지만 그렇지 않다면, 이동은 마이그레이션(migration)입니다.

## 테스트는 이식 가능합니다. 저에게 실행해 보세요.

제가 이 경주에 말을 가지고 있으니, 제가 작업하는 게이트웨이가 다섯 가지 점검 사항에 어떻게 응답하는지, 그리고 어디에서 부족한지를 알려드리겠습니다.  

마지막 줄은 우리가 점검 사항이 암시하는 것보다 의도적으로 약한 부분입니다. 특정 모델을 이름으로 호출하면 해당 모델이나 오류가 반환됩니다. 하지만 티어 별칭(tier alias)을 호출하면,