소매업체의 제품 페이지가 200 상태 코드로 응답했지만 내용이 없었습니다. 파이프라인은 차단을 로깅하지 않았습니다. 빈 선반을 로깅했습니다.
이는 대안 데이터 분야에서 아무도 예상하지 못하는 실패입니다. 누락된 데이터셋이나 느린 공급업체의 문제가 아닙니다. 분석하려는 기업이 아닌 다른 것을 몰래 측정하면서 계속해서 행(row)을 전달하는 수집 레이어의 문제입니다.
과제
2026년 1월, Exabel은 미국, 영국, 싱가포르, 홍콩에 걸쳐 약 6,100억 달러를 운용하는 100명의 펀더멘털 포트폴리오 매니저와 애널리스트를 대상으로 설문조사를 실시했습니다. 71%는 대안 데이터를 다룰 때 가장 실망스러운 부분으로 다양한 출처의 데이터를 결합하는 것을 꼽았으며, 94%는 연구 프로세스 어딘가에서 이미 AI나 머신러닝을 활용하고 있다고 답했습니다.
이 두 숫자를 나란히 놓고 보면 문제의 윤곽이 드러납니다. 모델링 측면은 인력이 충분합니다. 하지만 그 기반이 되는 인프라는 그렇지 않습니다.
웹에서 수집된 패널(가격, 재고 상태, 채용 페이지, 리뷰 수, 마켓플레이스 구색)은 무엇보다도 시계열 데이터입니다. 모든 시계열에는 스펙에 명시되지 않은 가정이 존재합니다. 즉, 오늘의 관측치는 어제와 동일한 방식으로 수집되었다는 것입니다. 이 가정이 크게 깨지면 알림이 발생합니다. 조용히 깨지면 신호(signal)로 인식됩니다.
웹에서 수집된 거의 모든 패널에서 이러한 조용한 단절 세 가지가 나타납니다.
콘텐츠가 없는 200 응답. 봇 방어 시스템은 오래전에 깔끔한 403 응답을 멈췄습니다. 챌린지 페이지, 동의 창 또는 빈 결과 템플릿이 성공 상태로 도달하고, 파서(parser)는 본문을 0개의 결과로 읽습니다. 목록이 줄어든 것은 수요가 줄어든 것과 동일하게 보입니다.
관측 지점의 이동. 가격, 통화, 구색, 프로모션 배너, 때로는 페이지 렌더링 여부까지 소매업체는 요청이 시작된 위치를 기반으로 모든 것을 결정합니다. 월요일의 수집이 독일에서 발생하고 목요일의 수집이 폴란드에서 발생했다면, 소매업체가 아닌 수집 방식에 기인한 변화가 시계열에 포함됩니다.
첫 번째 응답을 수용하는 로테이션. 수집기에 성공의 의미를 지정하지 않고 exit을 로테이션하면, 응답하는 첫 번째 exit에서 멈춥니다. 거부도 응답입니다. 따라서 행이 추가되고, 작업은 성공으로 표시되며, 아무도 다시 확인하지 않습니다.
이 중 어느 것도 예외를 발생시키지 않습니다. 수집 파이프라인은 행 수를 세고, 대시보드는 정상을 유지하며, 애널리스트는 차트를 얻습니다. 그런 다음 모델은 비즈니스의 동작이 아니라 수집 인프라의 동작을 학습하는 데 분기를 소비하게 됩니다.
접근 방식
데이터 무결성을 다운스트림 파서가 아닌 request의 속성으로 취급해야 합니다. 다음 세 가지가 충족되어야 합니다.
1. 실제 페이지의 모습을 명시하십시오. 수집기는 이를 자체적으로 파악할 수 없습니다. 정상적인 콘텐츠에만 포함된 문자열과 거부 응답에만 있는 문자열을 제공하면 챌린지 페이지가 관찰 결과로 집계되지 않습니다. 이에 대해서는 validate 규칙이 도입되었을 때 다룬 바 있습니다. 즉, request 자체가 성공의 의미를 결정합니다.
import requests
r = requests.post(
"https://api.foura.ai/api/proxy",
headers={"X-API-Key": "YOUR_API_KEY"},
json={
"maxTries": 8,
"exitCountries": ["DE"],
"request": {
"method": "GET",
"url": "https://retailer.example/p/12345",
"validate": {
"status": {"accept": [200]},
"data": {
"accept": ["data-testid=\"price\""],
"fail": ["Access Denied", "Just a moment"]
}
}
}
}
).json()
observation = r["data"] # content your rules accepted, or nothing
exit_id = r["proxy"] # opaque ID of the exit that delivered it
served_from = r["exitCountry"] # verify it against what you asked for
Rotation에 이제 완료 기준(definition of done)이 생겼습니다. 처음 마주친 페이지 형태의 객체를 반환하는 대신, 설정한 규칙을 통과하는 응답을 반환할 때까지 exit 시도를 계속합니다.
2. 관측 위치를 고정하십시오. exitCountries는 타겟에서 볼 수 있는 국가 코드의 엄격한 허용 목록(allowlist)이며, 지리 정보가 없는 exit는 대체되지 않고 제외됩니다. 이를 기반으로 개발하기 전에 알아두어야 할 두 가지 주의 사항이 있습니다. 국가 메타데이터는 주기적으로(보통 약 10분 이내) 새로 고침되므로 request 시점의 실시간 조회가 아닙니다. 이 때문에 response에 확인할 수 있는 exitCountry이 포함됩니다. 또한 요청한 범위와 일치하는 풀(pool)이 없는 경우, 예외 처리가 아닌 HTTP 200과 에러 엔벨로프(error envelope)가 반환됩니다. 상태 코드(status)가 아닌 본문(body)을 읽으십시오. 범위를 넓히면 연속성이 깨지므로, 범위를 유지한 채 나중에 재시도하십시오.
3. exit의 ID를 유지하십시오. proxy 필드는 주소가 아니라 불투명한(opaque) ID입니다. 후속 Single 또는 Browser 호출에 이 ID를 전달하면, 검색 페이지를 찾은 것과 동일한 관측 위치에서 상세 페이지를 가져옵니다(how to reuse an exit). 모든 행(row)에 해당 ID와 X-FourA-Request-Id header를 함께 저장하십시오. 6주 후 분석가가 데이터 급증에 대해 의문을 제기할 때, "이게 실제 데이터인가?"라는 질문은 논쟁이 아닌 단순 조회가 됩니다.
아직 잘 모르는 소스를 온보딩할 때, 작동하는 경로를 찾는 가장 빠른 방법은 Auto입니다. 저렴한 단계부터 비싼 단계로 올라가며 성공한 단계를 알려주고 작동한 세션을 반환합니다. 이를 사용하여 경로를 찾은 다음, direct 엔진에 운영 트래픽을 할당하십시오. 렌더링이 필요 없는 곳은 Single, 렌더링이 필요한 곳은 Browser를 통해 해당 세션을 재생(replay)하십시오. 경로 탐색(path finding)과 정상 상태(steady-state) 수집은 별개의 작업입니다.
Results
수십 개의 소매업체에서 하루 수천 개의 제품 페이지 패널을 다룰 때 이 세 가지 속성이 유지되면 다음과 같은 변화가 발생합니다(업계 벤치마크 기준 예시 시나리오).
- 누락은 추측이 아니라 실제 누락입니다. 거부된 요청은 절대 0으로 패널에 들어가지 않습니다. 빈 결과 집합은 소매업체가 아무것도 표시하지 않았음을 의미하며, 이 부재(absence) 신호는 트레이딩에 활용할 가치가 있습니다.
- 비교 가능한 행. 시리즈의 모든 관측치는 해당 시리즈가 정의된 국가에서 가져온 것이므로, 가격 변동은 실제 가격 변동을 의미합니다.
- 재현 가능한 히스토리. 행마다 Exit ID와 request ID가 있으므로, 논란이 되는 데이터 포인트는 이를 생성한 정확한 호출로 추적할 수 있습니다.
- 사용 가능한 행당 비용 절감. 폐기될 관측치를 생성했을 요청은 백테스트에서 비용 지불, 파싱, 저장 후 나중에 정리되는 대신 수집 시점에 재시도됩니다.
하지만 마지막 항목은 리서치 팀이 과소평가하는 부분입니다. 잘못된 행은 가져오는 데 비용이 적게 들었다고 해서 무료인 것은 아닙니다. 이는 리서치 주기를 낭비하게 만들며, 때로는 신호(signal)를 승인해야 하는 사람의 신뢰를 잃게 합니다.
Key Takeaway
대안 데이터 구매자는 커버리지, 지연 시간, 과거 데이터 깊이를 기준으로 제공업체를 평가합니다. 하지만 패널의 거래 가능 여부를 결정짓는 핵심 질문을 하는 사람은 거의 없습니다. 소스가 응답을 거부하는 날 이 데이터 세트는 어떻게 동작할까요?
해당 행(row)을 삭제하는 벤더는 정직합니다. 안내 페이지를 관측치로 반환하는 벤더는 자사 인프라 측정값을 판매한 것이며, 여러분은 작동을 멈추기 전까지만 유효한 백테스트로 그 대가를 치르게 됩니다. 이 질문은 모든 데이터 실사 체크리스트에 포함되어야 하며, 여러분의 파이프라인에 가장 먼저 적용되어야 합니다. 데이터를 직접 수집한다면 여러분이 곧 벤더이기 때문입니다.