실제로 BuyWhere 제품 검색 (product-search) API는 얼마나 빠를까요? 저는 https://api.buywhere.ai/v1/products/search를 대상으로 30개의 새롭고 다양한 쿼리를 실행하여 첫 호출 지연 시간 (first-call latency)을 측정하고 결과를 그룹화했습니다. 핵심 요약은 다음과 같습니다: 대부분의 쿼리는 1초 미만 내에 완료되지만, 콜드 캐시 (cold-cache)로 인한 꼬리 지연 (tail latency)이 실제로 존재합니다. 방법론, 실제 수치, 그리고 재현 가능한 스크립트를 포함한 전체 분석 내용을 공개합니다.

요약 (TL;DR) — 30개의 새로운 쿼리. 중앙값 (Median) 0.66초, 평균 (Mean) 3.71초. 30개 중 18개는 1초 미만 내에 완료되었고, 4개는 15초에서 타임아웃 (timeout)되었습니다. 동일한 쿼리의 웜 재호출 (Warm re-calls): 약 180ms. 병목 현상은 검색 자체보다는 콜드 캐시 쿼리 계획 (cold-cache query planning)에 있습니다.

이 벤치마크가 존재하는 이유

많은 API 마케팅 문구들이 수치를 제시하지 않은 채 "빠르다"고 말합니다. API를 에이전트 루프 (agent loop)에 연결할 때는 평균보다 지연 시간 분포 (latency distribution)가 더 중요합니다. 느린 호출의 긴 꼬리 (long tail)가 사용자가 체감하는 응답성에 지배적인 영향을 미치기 때문입니다.

저는 다음 세 가지 질문에 대해 재현 가능하고 보수적인 답변을 얻고자 했습니다:

1. 실제 쇼퍼 (shopper) 쿼리에 대한 전형적인 첫 호출 지연 시간은 얼마인가?
2. 콜드 캐시 (cold-cache) 꼬리 지연은 얼마나 심각한가?
3. 웜 캐시 (warm-cache)는 얼마나 도움이 되는가?

아래의 30개 쿼리는 모두 2026-06-23에 단일 AWS 리전에서 https://api.buywhere.ai의 공개 BuyWhere API를 대상으로 콜드 (cold) 상태(특정 쿼리에 대한 예열 없음)로 실행되었습니다. 벤치마크 스크립트는 이 글의 마지막에 있습니다.

방법론 (Methodology)

• 엔드포인트 (Endpoint): GET https://api.buywhere.ai/v1/products/search?q={query}&limit=10
• 인증 (Auth): Authorization: Bearer $BUYWHERE_API_KEY (무료 티어)
• 샘플 (Sample): 다음을 포함하는 30개의 새로운 쿼리:
  • 10개의 지역 코드 포함 (region-coded) (SG/Jakarta/Bangkok/Manila/Hanoi/KL — 싱가포르의 경우에만 빠른 로컬 인프라 경로가 있음)
  • 10개의 특정 브랜드 제품 (specific branded products) (예: iphone+15+pro+max, sony+wh-1000xm5)
  • 10개의 롱테일 (long-tail) (예: best+wireless+earbuds+under+100, 4k+monitor+for+programming)
• 예열 (Warm-up): 커넥션 풀 (connection pools)을 채우기 위해 시간 측정 배치(timed batch) 실행 전 단 한 번의 일회성 쿼리(q=warmup)를 실행했습니다. 각 측정 대상 쿼리는 정확히 한 번씩만 실행되었습니다 — 특정 쿼리에 대한 예열은 없었습니다 (이는 보수적인 케이스입니다).
• 측정 (Measurement): curl -w "%{time_total}" — 연결부터 마지막 바이트까지의 실제 경과 시간 (wall-clock).
• 제한 (Limit): 모든 쿼리에 대해 limit=10 적용 (에이전트의 첫 번째 결과 페이지에 대한 기본값).

시간 측정 배치 내에서 동일한 쿼리를 두 번 실행하지 않았습니다. 그렇게 하면 캐시 (cache)가 콜드 패스 (cold path)를 가릴 수 있기 때문입니다.

원시 결과 (Raw results) (30개의 새로운 쿼리)

분포 (Distribution)

평균값은 4개의 15초 타임아웃으로 인해 높아졌습니다. 에이전트 설계에는 중앙값 (median)이 더 유용한 수치입니다 — 전체 쿼리의 절반은 660ms 미만 내에 완료되며, 60%는 1초 미만 내에 완료됩니다.

타임아웃 이야기는 무엇인가? (What's the timeout story?)

15초의 벽은 API의 하드 cURL 타임아웃 / 요청 데드라인 (request-deadline)입니다. 타임아웃이 발생한 쿼리들(sg+birthday+cake+delivery, iphone+15+pro+max, sony+wh-1000xm5, nike+pegasus+40)을 살펴보면 — 이들은 높은 선택도 (high selectivity)와 큰 후보군 (large candidate sets)을 가진 쿼리들입니다. 즉, 10만 개 이상의 일치하는 제품을 반환하는 일반적인 용어(예: "iphone")는 서버가 더 깊은 스캔(scan)과 랭킹 패스(ranking pass)를 수행하도록 강제합니다.

에이전트(agent)의 경우, 이는 구체성(specificity)이 승리한다는 것을 의미합니다. 30개의 쿼리 혼합에는 단일 단어로 된 광범위한 쿼리와 3~4단어로 된 구체적인 쿼리가 모두 포함되어 있으며, 구체적인 쿼리들이 빠른 응답 구간(fast end)을 지배합니다.

실질적인 규칙: 만약 에이전트의 쿼리 문자열이 2단어 미만이라면, 카테고리나 지역 한정어(qualifier)를 추가하세요. 이를 통해 타임아웃이 발생하기 쉬운 꼬리 부분(tail)에서 중앙값(median) 영역으로 이동할 수 있습니다.

웜 캐시(Warm-cache) 동작

동일한 쿼리를 두 번째로 실행하면 지연 시간이 한 자릿수(an order of magnitude)만큼 감소합니다. 제가 즉시 다시 실행한 8개의 새로운 쿼리에 대한 결과는 다음과 같습니다:

에이전트가 쿼리를 재사용하는 경우(예: 사용자가 클릭할 때마다 다시 쿼리되는 인기 상품 페이지), 웜 캐시(warm cache)를 통해 에이전트 루프(agent loop)에서 "즉각적"이라고 느껴지는 임계값인 200ms 미만으로 성능을 유지할 수 있습니다.

상태 및 통계 엔드포인트 (참조용)

검색 이외의 공개 엔드포인트(non-search public endpoints)는 매우 빠릅니다. 참고를 위한 수치는 다음과 같습니다:

두 엔드포인트 모두 반복적인 호출 시에도 일관되게 200ms 미만을 유지합니다.

벤치마크 재현하기

전체 스크립트는 아래와 같습니다. curl, bash, 그리고 BUYWHERE_API_KEY(무료 티어로 충분함)가 있는 환경이라면 어디서든 실행할 수 있습니다.

#!/bin/bash
# 30개의 새롭고 다양한 쿼리 — 첫 번째 호출 지연 시간 측정
declare -a queries=(
...

카탈로그가 성장하고 캐시 커버리지(cache coverage)가 변경됨에 따라 날짜별로 수치가 달라질 수 있습니다. 하지만 분포의 형태(작고 빠른 클러스터 + 길고 느린 꼬리)는 모든 전체 텍스트 상품 검색 엔진(full-text product search engine)의 구조적 특성이며, 에이전트 루프가 반드시 이 형태를 고려하여 설계되어야 합니다.

이것이 에이전트 설계에 의미하는 바

BuyWhere를 에이전트에 연결하려는 모든 분들을 위한 세 가지 핵심 사항입니다:

1. 중앙값(median)을 기준으로 구축하고, p99를 위해 제한을 두세요. 에이전트 루프를 약 700ms의 전형적인 지연 시간(latency)을 기준으로 계획하되, 호출당 16초의 엄격한 타임아웃(timeout)을 설정하고 타임아웃 발생 시 한 번 재시도하세요. 4/30의 콜드 테일(cold-tail) 비율은 발생할 수 있으며, 단 한 번의 재시도만으로도 보통 웜 캐시(warm cache)에 도달할 수 있습니다.
2. 사용자 쿼리의 구체성을 장려하세요. 쿼리가 2단어 미만이거나 범위가 지정되지 않은 경우, 에이전트는 검색 API를 호출하기 전에 이를 재작성해야 합니다. 타임아웃이 발생하기 쉬운 테일(tail) 구간을 벗어날 수 있도록 카테고리("laptop", "shoes")나 지역("sg", "jakarta")을 추가하세요.
3. 에이전트 측에서 쿼리 문자열(query string)별로 캐싱하세요. 서버 측 웜 캐시(warm cache)는 이미 약 180ms의 재호출 지연 시간을 제공하며, 그 위에 프로세스 내 LRU(Least Recently Used)를 추가하면 인기 있는 쿼리에 대해 한 자릿수 ms 단위의 지연 시간을 얻을 수 있습니다.

훌륭한 에이전트로 가는 가장 빠른 길은 API에 더 빨라지라고 요구하는 것이 아니라, 비용이 저렴할 만큼 이미 충분히 구체적인 쿼리를 제공하는 것입니다.

API 키 받기

BUYWHERE_API_KEY 무료 티어는 이 글의 모든 수치를 재현하기에 충분합니다. buywhere.ai에서 가입하세요. 무료 티어는 신용카드 등록 없이 분당 60회의 요청을 제공합니다.

벤치마크 스크립트의 전체 소스 코드는 위 기사에 있습니다. 다른 날에 다시 실행했을 때 수치가 실질적으로 다르게 나타난다면 의견을 듣고 싶습니다. 결과물을 댓글로 남겨주시면 비교 분석을 통해 이 글을 업데이트하겠습니다.