저희가 추정한 바에 따르면, GPT-6.1 Sol을 사용하면 1,000개의 리뷰에 대한 태그를 1달러 미만으로 지정할 수 있습니다. 전제 조건은 strict 모드의 JSON Schema 출력을 사용하고 Batch API를 이용하며, 리뷰 1건당 추론 토큰 수를 약 50개로 설정하는 것입니다. 모델이 실제로 실행된 것은 아니므로 이 수치는 시뮬레이션 값입니다. 비용을 좌우하는 것은 데이터 자체가 아니라 요청을 어떻게 묶느냐(요약 방식)에 달려 있습니다. 2026-11-06 00:16부터 00:25 (SGT)까지 EveryInfra의 데이터 API를 실제로 7번 호출했습니다.
로봇 청소기 앱 두 개(Roborock 및 iRobot)의 Google Play 리뷰 400건과, 추가적으로 리뷰 영상에 달린 TikTok 댓글 12건을 확보했습니다. 지불한 총 금액은 $0.003334입니다. 각 호출에서 실제로 반환된 건수를 계산하면, 리뷰 1,000건당 데이터 비용은 Google Play가 $0.006945, TikTok이 $0.046704입니다.
이 컴퓨터에는 OpenAI API 키가 없습니다. 따라서 본 기사에서는 모델에 대한 설정 예시와 시뮬레이션만 제시합니다. 토큰 수는 공개된 o200k_base 인코딩으로 계산했으며, 요금은 2026-11-06에 확인한 공개 가격을 사용했습니다. 주요 결론은 간단합니다.
-
리뷰를 1건씩 개별 요청으로 보내면, 시스템 프롬프트와 스키마만으로 967 토큰이 필요합니다. 이는 입력 토큰 전체의 92%에 해당하며, 프롬프트 캐시 적용에 필요한 최소값인 1,024 토큰보다 적습니다. 따라서 같은 지시에 대해 1,000회 분량의 정규 요금을 지불하게 됩니다.
-
다음으로, 리뷰를 한 요청당 25건씩 보내고, 리뷰 1건당 추론 토큰을 50개라고 가정합니다. 그러면 1,000건에 대한 Batch 사용 모델 비용은 약 $1.74에서 약 $0.81로 낮아집니다. 추론 토큰이 없다면, 하한선은 $1.49에서 $0.56까지 내려갑니다. 다만, Sol에서는 low보다 낮은 effort를 지정할 수 없기 때문에 이 하한선에는 도달하지 못합니다.
요점 (Key Points)
- GPT-6.1 Sol은 2026-09-29에
gpt-6.1-sol로 API 제공을 시작했습니다. 컨텍스트 창(Context Window)은 1,050,000 토큰입니다. 1M 토큰당 표준 가격은 입력 $2, 출력 $10이며, Batch는 각각 $1과 $5입니다. 가장 낮은 추론 노력도(reasoning effort)는 low이며, none은 없습니다.
- strict 모드용 스키마를 문서에 명시된 규칙에 따라 스크립트로 검사했습니다. 저희 태그용 스키마에는 문제가 0건이었습니다. 손상된 테스트용 스키마에서는 문제 5건이 발견되었으며, 여기에는
allOf, if, then가 포함되어 있습니다.
- 실제 호출 7회:
google_play/reviews는 한 번의 호출로 200건을 반환했고 비용은 $0.001389였습니다. tiktok/comments는 영상 1개당 12건을 반환했습니다. amazon/reviews의 비동기 작업 2건은 0건으로 완료되어 환불되었습니다. 503 타임아웃이 발생한 2회에는 비용이 청구되지 않았습니다.
- 요청당 1건씩 보낼 경우, 리뷰 1,000건에 약 1,056,100의 입력 토큰이 필요하며, 이 중 975,000 토큰은 반복적으로 전송되는 프롬프트와 스키마입니다. 요청당 25건씩 보낼 경우, 입력량은 약 121,700 토큰까지 줄어듭니다.
- '경쟁사 언급'을 판정하는 키워드 규칙은 대략적인 1차 판단에 불과합니다. 이 규칙은 412건 중 17건에 일치했습니다. 일치한 리뷰는 각각 읽었습니다. 실제로 경쟁사를 언급한 것은 13건이었으며 (이 중 1건은 규칙이 놓친 2개 브랜드에도 언급되어 있었습니다), 3건은 오탐지(Samsung 스마트폰, Samsung 태블릿, 슬로바키아어 단어)였고, 1건은 판단할 수 없었습니다.
본 기사가 답변하는 것은 하나의 제한적인 질문입니다. 손에 리뷰 세트가 있고, GPT-6.1 Sol을 사용하여 각 리뷰에 4가지 태그(감성, 문제 카테고리, 경쟁사 언급, 액션 아이템 1개)를 지정하고 싶다고 가정합니다. 각 태그는 그대로 스프레드시트에 입력할 수 있는 형태로 출력되어야 하며, 총비용도 파악하고 싶은 상황입니다. 리뷰는 EveryInfra의 데이터 API에서 가져옵니다.
태그 지정에는 OpenAI의 Responses API와 Batch API를 사용합니다. 아래에 나오는 EveryInfra의 수치는 모두 원본 응답(raw response)에서 가져온 것이며, 재계산이 가능합니다. OpenAI 측 절차에는 모두 설정 예시 또는 가격 추정치임을 명기했습니다. 이 배치 작업은 OpenAI 상에서는 실행되지 않았습니다.
다음 표는 실제로 측정된 항목과 추정한 항목을 정리한 것입니다. 아래의 수치는 모두 이 표의 어느 한 행에 해당합니다.
| 단계 | 획득 방법 | 재계산 가능 여부 |
|---|
| 리뷰 데이터 (EveryInfra) | 2026-11-06에 실제로 7회 호출하여 원본 응답을 저장함 | 가능. 모든 수치가 응답 기반임 |
| 토큰 수 | 실제 시스템 프롬프트, 스키마, 리뷰 412건을 o200k_base로 계산 | 가능. 단, Sol의 토크나이저는 비공개임 |
| 출력 태그 | 사람이 작성한 태그 예시 12건 (GPT-6.1 Sol의 출력이 아님) | 출력 길이 추정에만 사용 |
| 추론 토큰 | 미측정. 리뷰 1건당 0, 50, 200을 가정함 | 불가능. 파일럿 실행 및 해당 usage가 필요함 |
| 모델 비용 | 상기 각 행의 수치에 2026-11-06 기준 공개 가격을 곱함 | 가능. 자체 수치로 계산 가능함 |
| 태그 정확도 | 없음 | 파일럿 실행 후 수작업으로 확인 |
GPT-6.1 Sol API란: 출시일, 컨텍스트, 가격
먼저 모델에 관한 사실을 확인합니다. OpenAI의 API changelog에는 2026-09-29자 항목이 있습니다. 이에 따르면, OpenAI는 복잡한 코딩이나 전문 업무를 위해 GPT-6.1 Sol (gpt-6.1-sol)을 출시했습니다. 가격은 GPT-6 Astra보다 낮게 책정되었습니다.
272K 토큰까지의 입력에 대해, 1M 토큰당 표준 가격은 입력 $2, 캐시 입력 $0.10, 캐시 쓰기 $2.50, 출력 $10입니다. 같은 항목에는 도구 호출(tool calling)에는 Responses API가 필요하다는 내용도 적혀 있습니다. 출시 기사 「Introducing GPT-6.1 Sol」에 따르면, Sol의 성능은 GPT-6 Astra와 유사하다고 합니다. 또한, 표준 입력/출력 가격이 Astra의 5분의 1이라고 언급합니다.
2026-11-06에 확인한 GPT-6.1 Sol 모델 페이지에는 태그 지정과 관련된 사양이 실려 있습니다. 컨텍스트 창은 1,050,000 토큰, 최대 출력은 128,000 토큰이며, 지식 차단 시점(knowledge cutoff)은 2026-04-30입니다. reasoning.effort 값은 low, medium(기본값), high, xhigh, max가 있습니다. 기능 목록에서는 Structured outputs와 Function calling이 'Supported'로 되어 있습니다.
모델 페이지에는 배치 처리와 관련된 요금 규칙이 추가로 4가지 있습니다. 캐시된 입력은 입력 요금의 5%입니다. 캐시 쓰기는 1.25배입니다. 입력 토큰이 272K를 초과할 경우, 해당 요청에서는 입력 요금이 2배, 출력 요금이 1.5배가 됩니다. Batch와 Flex는 50% 할인됩니다.
|
| 항목 | 정보 출처 내용 | 출처 (2026-11-06 열람) | 태그 지정에 미치는 영향 |
|---|
| API 출시 | gpt-6.1-sol은 2026-09-29에 출시됨 | API 변경 이력 | 작성 시점 기준, 출시 후 38일 경과 |
| 컨텍스트와 출력 | 컨텍스트 1,050,000, 최대 출력 128,000 | 모델 페이지 | 수십 개의 리뷰가 한 요청에 여유롭게 포함 가능 |
| 추론 노력 (Inference Effort) | low, medium, high, xhigh, max (none 없음) | 모델 페이지, GPT-6 가이드 | 모든 요청에서 추론 토큰이 발생하며, 출력으로 과금됨 |
| 표준 요금 | 1M당 입력 $2, 캐시 $0.10, 출력 $10 | 요금 페이지, 변경 이력 | 동기 처리 시 최소 1,000건당 약 $2.99 |
| 배치(Batch) 요금 | 1M당 입력 $1, 캐시 $0.05, 출력 $5 | 요금 페이지 | 동일한 요청이 절반 가격으로 책정됨 |
| ... | | | |
가장 간과하기 쉬운 부분은 추론 노력 항목입니다. GPT-6 가이드에는 명확하게 나와 있습니다. GPT-6 Astra와 GPT-6.1 Sol은 none에 대응하지 않습니다. 기존 요청에서 minimal을 사용하고 있다면, low로 변경하여 결과를 비교해 보십시오. GPT-6.1 Terra, GPT-6 Sol, GPT-6 Luna는 none에 대응합니다. 추론 가이드에 따르면, 추론 토큰은 출력 토큰으로 계산됩니다. | | | |
이는 태그 지정에 영향을 미칩니다. 리뷰마다 눈에 보이지 않는 출력이 발생하며, 요금은 1M 토큰당 $10, 배치(Batch)에서는 $5입니다. 이 토큰 수는 실제로 호출해 보지 않으면 측정할 수 없습니다. 따라서 비용표에서는 추론을 별도의 전제로 제시하고 있습니다.
배치(Batch) 항목을 자세히 보겠습니다. 요금 페이지에서는 Flex와 Batch가 같은 가격대에 놓여 있습니다. gpt-6.1-sol의 배치(Batch)는 1M 토큰당 입력 $1, 출력 $5, 캐시 입력 $0.05입니다. 30분 캐시 쓰기는 $1.25, 12시간 캐시 쓰기는 $2.50입니다. 아래 비용표는 모두 이 가격대를 기준으로 계산되었습니다.
gpt 6.1의 구조화된 출력(structured outputs): json_schema의 strict 모드에는 어떤 제한이 있는가
OpenAI Structured Outputs 가이드에서는 서두에 그 보장을 명시하고 있습니다. 모델의 출력은 지정한 JSON Schema에 항상 일치합니다. 필수 키가 누락되거나, enum에 없는 값을 생성하는 일이 없습니다. Responses API에서는 text.format을 {"type":"json_schema","strict":true,"schema":…}로 설정합니다. 가이드에는 strict 모드가 지원하는 것이 JSON Schema의 일부일 뿐이라고도 쓰여 있습니다. 그 범위를 벗어난 키워드를 스키마에 사용하면, strict: true 요청은 실패합니다.
태그 지정용 스키마는 일단 확정되면 수천 번 실행됩니다. 그래서 가이드 규칙 중 세거나 확인할 수 있는 모든 것을 옮겨 적었습니다. 게다가 그 위에 스키마가 이러한 규칙을 따르는지 확인하는 작은 스크립트를 작성했습니다. 기억에 의존하지 않았습니다.
OpenAI開発者ドキュメントのStructured Outputsガイドのスクリーンショット。ティール色の枠が「Objects have limitations on nesting depth and size」から「additionalProperties: false must always be set in objects」までの部分を囲んでいます。本文には、スキーマのオブジェクトプロパティは最大5000個、ネストは最大10階層と書かれています。すべてのプロパティ名、定義名、enum値、const値の文字列長の合計は120,000文字を超えられません。enum値はスキーマ全体で最大1000個です。値が250個を超える単一の文字列enumでは、enum値の文字数の合計を15,000文字以下にする必要があります。すべてのオブジェクトでadditionalPropertiesをfalseに設定する必要があり、その後に天気のサンプルスキーマが続きます。
스크린샷: OpenAI Structured Outputs 가이드, 2026-11-06 (SGT)에서 가져옴. 청록색 프레임은 당사 추가 사항. OpenAI 개발자 문서 'Structured model outputs'
청록색 프레임 안의 4개 항목은 크기 제한입니다. 프레임 바깥에도 스키마 작성에 관한 엄격한 규칙이 가이드에 적혀 있습니다.
- 루트는 객체여야 합니다.
anyOf로는 할 수 없습니다. - 모든 객체의 모든 필드는 required에 포함되어야 합니다. 필드를 선택 사항으로 만들려면, ["string","null"]와 같은 타입을 지정해야 합니다. - 가이드에 따르면, allOf, not, dependentRequired, dependentSchemas, if, then, else는 지원되지 않습니다. - 문자열에 대해서는 가이드에 기재된 것이 pattern과 format입니다.
뿐입니다. format
키워드로 지정할 수 있는 값은 date-time, time, date, duration, email, hostname, ipv4, ipv6, uuid의 총 9가지입니다. 배열에 대해서는 minItems와 maxItems가 대응됩니다. 또한 $defs와 재귀 참조도 지원됩니다.
가이드에는 새로운 스키마를 사용하는 첫 번째 요청에서는 추가적인 처리 지연 시간(latency)이 발생할 수 있다고 나와 있습니다. 동일한 스키마를 사용하는 이후의 요청에서는 발생하지 않습니다.
| 규칙 (가이드 내 섹션) | 상한 또는 요구사항 | 당사의 태그 스키마 | 잘못된 테스트용 스키마 |
|---|
| 객체 속성의 총 개수 (Objects have limitations…) | ≤ 5000 | 9 | 8 |
| ... | additionalProperties: false | 모든 객체에서 필수 | 가능 |
모든 필드를 required에 기재 | 필수 | 9개 중 9개 | required에 존재하지 않는 필드 기재 |
| 비지원 키워드 | allOf, if, then 등 | 0 | 3 |
| 지원 목록에 없는 키워드 | 경고만 | 0 | minLength, 1 |
스크립트 결과, 단일 리뷰용 스키마와 25개 항목용 스키마에서는 문제(issue)가 0건, 경고(warning)가 0건이었습니다. 잘못된 스키마에서는 문제 5건, 경고 1건이 발생했습니다. 이 잘못된 스키마는 임의로 만든 것이 아닙니다. “mentions_competitor가 true라면, competitors에는 1개 이상의 항목이 필요”라는 자연스러운 발상에서 비롯된 것입니다. JSON Schema에서는 이 규칙을 allOf와 if/then으로 작성합니다.
Strict 모드는 이를 지원하지 않습니다. 스키마만으로는 두 필드 간의 이러한 규칙을 강제할 수 없습니다. 결과가 반환된 후에 코드로 확인해야 합니다. 방법은 후술하는 “스키마로 강제할 수 없는 것”에서 설명하겠습니다.
minLength에 대해 보충 설명합니다. 가이드에서 minLength와 maxLength가 비지원이라고 되어 있는 것은 파인튜닝(Fine-tuning)된 모델에 한정되지만, 지원되는 문자 키워드 목록에는 pattern과 format만 있습니다. 따라서 스크립트는 경고를 발생시키며, 당사의 스키마에서는 사용하지 않았습니다. 액션의 20단어 제한은 description과 프롬프트에 작성하고 코드로 측정했습니다.
단일 리뷰용 태그 스키마는 다음과 같습니다. 필드는 9개이며 모두 필수입니다. other_brand_name과 action_item은 null을 허용합니다.
{
"name": "review_label",
"strict": true,
...
}
25개 항목 버전에서는 외부에 1층이 추가됩니다. 루트 객체의 필드는 labels 배열 하나뿐입니다. 배열의 각 항목은 $ref를 사용하여 $defs 내의 동일한 태그 객체를 참조합니다. 가이드에 따르면, $defs와 $ref는 지원됩니다. 중첩 깊이는 1단계에서 2단계로 늘어나지만, 최대 10단계를 크게 밑돕니다.
필드의 순서도 중요합니다. 가이드에 따르면 출력은 스키마의 키 순서를 따릅니다. 그래서 item_id를 맨 앞에 배치했습니다. action_item과 evidence는 모델이 리뷰 전체를 읽어야 작성할 수 있으므로, 끝 가까이에 배치했습니다. 출력이 중간에 잘리더라도, 가장 앞쪽에 있는 ID와 감정은 남아있습니다.
태그 설계 방법: 4가지 질문과 9개 필드
태그를 설계하기 전에 누가 사용할지 결정합니다. 로봇 청소기 브랜드의 앱 팀이 신경 쓰는 것은 Wi-Fi 연결 끊김, 로그인 실패, 지도 소실입니다. 지원팀은 보증 관련 불만을 찾습니다. 제품팀은 사용자가 어떤 경쟁사 브랜드를 비교하고 있는지 알고 싶어 합니다.
이에 따라 4가지 질문을 통해 태그를 만들었습니다. 어조는 어떠한가. 어떤 종류의 문제인가. 경쟁사 브랜드 이름이 언급되었는가.
하나의 구체적인 개선책으로 연결할 수 있는가. 문제 카테고리는 15개의 값으로 이루어진 고정된 enum입니다. 경쟁사는 12개의 값으로 이루어진 enum이며, 그 외를 처리하기 위해 other_brand
를 준비하고 있습니다.
가장 시간이 오래 걸린 부분은 문제 카테고리였습니다. 먼저, 실제 호출을 통해 얻은 412개의 리뷰를 읽었습니다. 다음으로, 실제 불만을 13개의 그룹으로 분류했습니다. 마지막으로 other와 none을 추가했습니다. 예를 들어, iRobot의 낮은 평가 리뷰 중 다수에는 “명령이 작동하지 않는다” 또는 “iRobot 클라우드에 연결할 수 없다”고 쓰여 있습니다.
이러한 내용은 app_connectivity로 분류합니다. “인증 코드가 도착하지 않는다”나 “계정 연동 실패”는 account_login입니다. Roborock의 리뷰 중 다수에는 “업데이트 후 맵이 망가졌다”고 쓰여 있습니다. 이는 firmware_update와 mapping_navigation 두 가지 모두에 해당합니다. 따라서, 하나의 리뷰에 최대 3개의 카테고리를 지정할 수 있습니다.
시스템 프롬프트에는 카테고리별로 한 줄의 가이드라인이 있습니다. 이 부분이 프롬프트의 절반 이상을 차지합니다. 후술하는 토큰 수에서 고정 접두사(fixed prefix)가 645토큰이 되는 주된 이유도 여기에 있습니다.
イラスト。左側では、金属プレス機が同じ白紙の用紙を一列に打ち出しています。どの用紙も枠が同じ位置にあり、形を固定するstrictなスキーマを表しています。右側では、1枚の用紙がティール色の枠が付いた虫眼鏡の下に置かれています。その用紙の小さなチェックボックス2つが矛盾しており、片方にはチェックが入り、もう片方は空です。これは結果が返ってきた後の確認を表しており、スキーマでは捕捉できない論理の矛盾を見つけます。虫眼鏡の横には、空欄のリストが付いたクリップボードがあります。
스키마는 모든 양식을 동일한 형태로 만듭니다. 결과가 반환된 후 확인 과정에서 서로 모순되는 필드를 찾습니다.
감정은 positive, negative, mixed, neutral의 4가지 값입니다. 시스템 프롬프트에는 “별점 평가만으로 감정을 판단하지 말 것”이라고 쓰여 있습니다. 별점 개수와 본문 내용이 일치하지 않는 경우가 자주 발생합니다. Roborock 리뷰 중에는 “앱은 매우 좋다”로 시작하는 별점 1개짜리 리뷰가 있습니다. 맵 문제에 대한 언급은 그 이후에 나옵니다. 앱을 앞부분에서 칭찬하면서도 별점 3개인 리뷰도 있습니다.
그 리뷰는 후반부에 삼성의 폴더블 스마트폰에서는 하단 버튼이 작동하지 않는다고 쓰여 있습니다. 시스템 프롬프트에서는 이러한 리뷰를 mixed로 처리합니다. TikTok 댓글에는 별점이 없습니다. “어떤 것이 가장 좋은가요?”와 같은 질문은 neutral가 됩니다.
action_item은 검증하기 가장 어려운 태그이므로, 제한을 가장 엄격하게 적용했습니다. 20단어 이내의 영어 한 문장 또는 null입니다. evidence에는 리뷰에서 최대 15단어를 원문 언어로 인용해야 합니다. 이 두 필드가 있으면, 전체 리뷰를 읽지 않아도 몇 초 만에 태그를 확인할 수 있습니다.
이 스키마를 사용하여 실제 리뷰 12건에 대한 출력 예시를 수동으로 작성했습니다. 이를 출력 토큰 추정치 계산에 사용합니다. 각 필드가 어떤 형태가 될지도 알 수 있습니다. 표에는 그중 4건을 보여드립니다.
리뷰 본문은 일부 생략하고, 게시자 정보는 삭제했습니다. 이 12건의 예시는 사람이 작성한 것이며, GPT-6.1 Sol의 출력이 아닙니다.
| 출처 | 별점 수 | 리뷰 발췌 | 감정 | 문제 카테고리 | 경쟁사 |
|---|
| Roborock 앱 | 2 | “You ruined my robot after your last update! The map is all messed up…” | negative | firmware_update, mapping_navigation | none |
| ... | | | | | |
EveryInfra에서 리뷰를 가져오기: 실제로 한 번 요청하여 응답을 받을 때까지
리뷰를 가져오는 데는 EveryInfra의 데이터 엔드포인트 POST /api/v1/social를 사용했습니다. 리퀘스트 바디에 플랫폼, 액션, 파라미터를 지정합니다. 첫 호출 전에 2026-11-06 00:15 (SGT)에 무료 기능 카탈로그를 읽어 각 리뷰 기능의 요금, 파라미터, 응답 필드를 확인했습니다.
google_play/reviews는 1회 호출당 $0.001389입니다. 동기 호출로 최대 200건을 반환합니다. language와 sort를 지정할 수 있습니다. -tiktok/comments는 1회 호출당 $0.000556입니다. 비디오 URL을 지정합니다. -amazon/reviews는 1회 호출당 $0.001389입니다. 카탈로그에 따르면, Amazon의 각 사이트 상품 페이지에는 주목받는 리뷰만 표시되며, 보통 상품당 십여 건입니다. -trustpilot/reviews는 1회 호출당 $0.001389입니다.
Google Play에 대한 요청 전체는 다음과 같습니다.
curl -s https://api.everyinfra.com/api/v1/social \
-H "Authorization: Bearer $EVERYINFRA_API_KEY" \
-H "Content-Type: application/json" \
...
이 요청은 2026-11-06 00:20:08 (SGT)에 전송되었으며, 9.45초 만에 HTTP 200 응답을 받았습니다. count는 200이었고, pagination.stop_reason은 depth_limit이었으며, has_more는 false였습니다. 청구 금액은 $0.001389입니다.
각 리뷰에는 id, text, score, thumbs_up, reply_text, reply_at, app_version, posted_at 등의 필드가 포함되어 있으며, 이는 카탈로그의 response_fields 목록과 일치합니다. 응답에는 게시자 이름과 아바타 필드도 포함되었으나, 태그 지정에 불필요하여 모델에 대한 요청을 생성하기 전에 삭제했습니다.
実際のAPIレスポンスのスクリーンショットです。ダークカードの上部にPOST https://api.everyinfra.com/api/v1/socialが表示され、00:20:08 SGT、HTTP 200、9.45秒と記されています。その下はリクエストボディで、platformがgoogle_play、actionがreviews、paramsはapp_idがcom.roborock.smart、languageがen、sortがnewest、limitが200です。さらにその下にレスポンスの一部があり、countが200、paginationはpageが1、has_moreがfalse、stop_reasonがdepth_limitです。レビューが2件、短縮表示されています。星2のレビューは、前回のアップデート以降マップがめちゃくちゃになったという内容です。星3のレビューは、アプリがSamsungの折りたたみスマートフォンの画面比率に対応していないという内容です。残りの198件は表示されていないという注記があります。下部のティール色のボックスには課金情報としてcharged true、charged_usd 0.001389が表示されています。
스크린샷: 2026-11-06 00:20:08 (SGT)의 실제 google_play/reviews 응답. 리뷰 본문은 생략하고, 게시자 필드는 삭제했습니다. 청록색 박스는 편집부에서 추가했습니다. EveryInfra의 실제 API 응답
호출은 00:16:42부터 00:24:27 (SGT)까지 총 7회 이루어졌습니다. 각 호출을 아래 표에 정리했습니다. 동기(synchronous) tiktok/comments 호출은 90.21초가 소요되었고, HTTP 200으로 12건을 반환했습니다. limit 200으로 진행한 amazon/reviews와 trustpilot/reviews에 대한 두 번의 동기 호출은 85초를 초과하여 503 타임아웃이 발생했으며, 비용이 청구되지 않았습니다. 에러 메시지에는 `
