JSON 모드와 스키마의 토큰 비용
업데이트 September 1, 2026 · 최초 게시 September 1, 2026
모델에 구조화된 출력을 요청하는 것은 형식을 고르는 일처럼 보입니다. 청구서에서는 분량을 고르는 일이며, 그 비용은 세 곳에 동시에 쌓입니다.
스키마는 매 요청마다 입력 비용이다
응답 형식이나 도구 정의는 요청에 직렬화되어 들어갑니다. 적당한 스키마도 필드 열두 개, 각 필드의 설명, 중첩 객체 몇 개면 수백 토큰입니다. 이는 모든 호출, 모든 턴, 기능의 수명 내내 곱해지기 전까지는 작아 보입니다. 백만 번 호출에 400토큰짜리 스키마를 붙이면, 결코 바뀌지 않는 형태를 설명하기 위해 400 million 입력 토큰을 내는 셈입니다.
더 나쁜 것은, 순진한 구현에서는 스키마가 프롬프트의 가변 부분뒤에 놓이는 경우가 많다는 점입니다. 그러면 캐시된 접두부가 깨집니다. 스키마는 매번 정가를 내고동시에 그 앞의 모든 내용에 대한 할인까지 없애 버립니다.
문법은 출력 비용이다
응답의 모든 중괄호, 따옴표, 쉼표, 필드 이름은 생성된 토큰이며 출력 단가로 청구됩니다. 긴 필드 이름은 반복되는 비용입니다. customer_shipping_address_line_one은 addr1보다 영원히 더 비쌉니다. 깊이 중첩된 객체는 자체 뼈대의 비용을 냅니다. 큰 봉투에 담긴 짧은 답변이라면, 구조가 실제 내용보다 더 커질 수 있습니다.
재시도가 비싼 부분이다
주요 제공업체의 제약 디코딩 덕분에 스키마 위반은 드물지만, 검증 실패는 여전히 일어납니다. 모델이 정직하게 채울 수 없는 필드, 정답이 없는 열거형, 읽는 사람에게 모호한 스키마 같은 경우입니다. 실패할 때마다 전체 재시도 비용이 듭니다. 입력 토큰이 다시 전부 들어가고 출력 토큰도 다시 전부 생성되며, 지연 시간도 늘어납니다. 트래픽이 많은 엔드포인트에서 2% 무효율은 아무 대가 없이 2% 비용이 늘어나는 것입니다.
실제로 할 일
스키마를 안정적인 접두부에 넣어 캐시되게 하고, 호출마다 동일하게 유지하세요. 실제로 소비하는 필드만 요청하세요. 여분의 필드는 스키마에서 한 번, 응답에서 한 번, 두 번 비용을 냅니다. 짧은 필드 이름과 평평한 구조를 선호하세요. 출력이 단일 값이라면 객체로 감싸지 마세요. 그리고 검증 실패율을 측정하세요. 이 중에서 순수한 낭비는 그 부분뿐입니다.
관련 글
관련 글
이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 →