Sensor Tower, Apptopia, data.ai, 42matters, AppstoreSpy. 5개 벤더, 하나의 제품: 국가별로 세분화되어 타인이 비용을 들여 유지 관리하는 일정에 맞춰 제공되는 최신 앱 스토어 데이터입니다. 이들이 공유하는 시장 규모는 2025년에 9억 7,500만 달러에 달했으며 올해는 12억 1,000만 달러에 이를 것으로 예상됩니다 (Global Growth Insights, 2025).
인접 분야의 서비스(ASO 도구, 모바일 애드테크를 위한 경쟁 벤치마크, 모바일 전문 VC를 위한 포트폴리오 스코어링 모델)를 구축하다 보면 결국 같은 갈림길에 마주하게 됩니다. 벤더 비용을 지불하거나, 데이터를 직접 수집하거나 둘 중 하나입니다.
과제
앱 스토어 데이터는 겉보기에 단순해 보입니다. 공개되어 있으니까요. Apple은 기존 iTunes JSON 조회를 통해 대부분의 데이터를 제공합니다. Google Play는 브라우저에 이를 렌더링합니다. 얼마나 어렵겠습니까?
하지만 이를 프로덕션 규모로 실행하려고 하면 모든 가정이 무너집니다.
가장 먼저 깨지는 것은 지리적 위치입니다. 미국 인기 차트에서 특정 게임의 순위는 브라질에서의 순위와 무관하며, 일본과도 완전히 다릅니다. 가격은 국가마다 바뀝니다. 제공 여부도 국가마다 다릅니다. 설명은 현지화되며, 때로는 완전히 다른 마케팅 스토리로 바뀌기도 합니다. 미국 전용 퍼블리셔를 위해 앱을 벤치마킹한다면 수집 리전이 하나여도 괜찮습니다. 하지만 글로벌 진출을 노리는 대상을 벤치마킹한다면 수십 개의 수집 리전이 필요하며, 실제로 해당 국가에서 요청이 발생하는 것처럼 확인되어야 합니다. 스토어 CDN이 이를 검증합니다.
두 번째로 무너지는 것은 최신성입니다. 카테고리 순위는 매시간 바뀝니다. 새 릴리스에 대한 리뷰 감성은 패치로 인해 문제가 생길 경우 하루 만에 뒤집힐 수 있습니다. 데이터가 하루 전 것이라면 고객은 이미 Twitter에서 그 변화를 확인했을 것입니다. 여러분의 플랫폼은 인텔리전스가 아니라 후행 지표가 됩니다.
세 번째는 수집 예산입니다. Apple의 공개 endpoint는 안정적인 트래픽을 견뎌냅니다. Google Play는 그렇지 않습니다. Play의 상세 페이지는 JavaScript를 렌더링하고, 차트 페이지는 로테이션되는 어뷰징 방지 token이 포함된 XHR 호출로 페이지를 넘기며, 두 스토어 모두 header를 확인하기 전에 TLS 계층에서 스크레이퍼의 핑거프린트를 식별합니다. 수집 규모가 단일 IP로 처리 가능한 수준을 넘어서는 순간 두 스토어 모두 유의미한 응답 반환을 중단합니다. 빈약한 상세 페이지가 오거나, 리뷰 페이지가 누락되거나, 아무것도 반환되지 않습니다.
네 번째는 리뷰 파이프라인입니다. Play의 인기 앱 하나는 출시된 모든 로케일에 걸쳐 하루에 수천 개의 리뷰를 생성합니다. 신뢰할 수 있는 감성 신호를 원한다면 샘플링으로는 부족합니다. 국가별로, 끊김 없이 전체 스트림을 지속해서 가져와야 합니다. 이는 대규모 제품 리뷰 수집에서 다룬 것과 형태가 같은 문제이며, 플랫폼만 달라졌을 뿐입니다.
이 중 어느 것도 단순 스크레이퍼 문제가 아닙니다. 인프라 문제입니다.
접근 방식
다행인 점은 네 가지 문제를 분리하고 나면 각각에 대한 명확한 해답이 나온다는 것입니다.
지리적 위치와 관련해서는 request별로 출구 국가를 고정할 수 있고, 해당 출구가 실제로 표기된 위치로 확인되는지 검증하는 proxy 계층이 필요합니다. 저가형 proxy pool은 국가 정보를 속이는 경우가 많습니다. 네덜란드로 geo-resolves되는 IP로 독일 Play 순위를 수집하면, 독일 메타데이터가 포함된 네덜란드 결과를 받게 되며 이를 알아채지 못합니다. FourA 같은 플랫폼은 Proxy Finder 계층에서 이 문제를 해결합니다. 국가를 선택하면 실제로 해당 국가에 위치한 출구를 제공하며, 후속 호출에서도 동일한 출구를 재사용하여 session 일관성을 유지합니다.
데이터 최신성의 핵심은 스크래퍼 수를 늘리는 것이 아니라 더 나은 스케줄링입니다. 순위 페이지는 빠른 주기(국가별로 중요한 카테고리에 대해 몇 분마다), 상세 페이지는 중간 주기(순위 변동이 감지될 때만 매시간), 리뷰는 느린 주기를 기본으로(매일 전체 수집) 순위나 평점 변동 시 빠른 주기 트리거를 결합합니다. 이러한 스케줄러는 데이터 플랫폼 자체가 아니라, 플랫폼 위에서 구동되는 수백 줄의 코드만으로 충분합니다.
Play 데이터 수집 예산 관리에서는 필요한 곳에만 JS 렌더링 경로를 사용하고, 그렇지 않은 곳에는 직접 요청 경로를 써야 합니다. 일부 Play 페이지는 올바른 request를 보내면 깨끗한 JSON을 반환하지만, 다른 페이지는 실제 브라우저와 실제 cookie가 없으면 검증 페이지만 반환합니다. FourA에서는 Auto가 이 결정을 조율합니다. 비용이 적게 드는 경로를 먼저 시도하고 실패하면 Browser로 격상합니다. 프로덕션에서는 매 호출마다 orchestrator 비용을 지불하지 않도록, 성공한 경로를 Single 또는 Browser에 직접 재실행합니다.
리뷰 파이프라인에서는 기교 있는 코드보다 처리량과 idempotency가 더 중요합니다. 매번 일관된 구조화된 응답("어떨 때는 JSON, 어떨 때는 HTML, 어떨 때는 검증 페이지"가 아닌 형태)을 반환하는 request 계층, 데이터를 누락 없이 처리하는 재시도 로직, 그리고 고객이 오래된 데이터를 보기 전에 특정 국가의 품질 저하를 감지할 수 있는 request별 결과 추적이 필요합니다.
결과
이 네 가지를 제대로 구축한 사내 팀은 외부 벤더 구독 서비스 대비 극히 일부의 비용으로 대등한 성과를 낼 수 있습니다. 손익분기점을 넘어서면 비용 구조가 빠르게 바뀝니다. 중간 규모의 ASO 좌석 구독료는 지원 국가당 월 수만 달러에 달하지만, FourA 스타일의 인프라 기반 소규모 수집 스택을 사용하면 극히 적은 비용으로 동일한 국가들을 처리할 수 있습니다(공개된 ASO 도구 가격 기준 예시 시나리오).
비용보다 더 중요한 점은 파이프라인의 주도권을 직접 갖는다는 것입니다. 고객이 "왜 화요일에 순위가 급등했나요?"라고 물었을 때, 벤더 대시보드를 보며 난처해하는 대신 가공되지 않은 raw response 이력을 바탕으로 명확히 답할 수 있습니다.
이 분야에서 성공한 팀들에게는 세 가지 공통된 습관이 있습니다. 국가별 성공률을 최우선 지표로 모니터링한다는 점입니다. 특정 국가에서 성공률이 98%에서 82%로 떨어지는 것은 사소한 문제가 아니라 조기 경보입니다. 파서 변경 시 기존 버그를 새로운 코드에 맞춰 다시 실행해야 하므로, 파싱된 필드뿐만 아니라 원시 response도 저장합니다. 또한 단일 수집 기간의 리뷰 수를 절대 신뢰하지 않습니다. 모든 스토어에는 불안정한 시간대가 존재하므로, 이동 평균을 기준으로 삼아야 합니다.
핵심 요약
앱 스토어 인텔리전스는 단순한 스크래핑 문제가 아닙니다. 양대 스토어가 차단을 시도하는 상황에서도 안정성을 유지하는 request 계층 위에서 동작하는 스케줄링, 지리적 위치, 세션 일관성의 문제입니다.
앱 스토어 데이터를 판매하는 벤더들도 여러분과 동일한 인프라 비용을 치릅니다. 문제는 이 비용을 자체적인 기준에 맞춰 한 번만 지불할 것인지, 아니면 그들의 기준에 맞춰 매달 지불할 것인지입니다.