Sensor Tower, Apptopia, data.ai, 42matters, AppstoreSpy. 5개 공급업체, 단일 제품: 국가별로 분류되고 누군가가 유지 비용을 지불하는 일정에 맞춰 제공되는 최신 앱 스토어 데이터입니다. 이들이 공유하는 시장은 2025년 기준 9억 7,500만 달러 규모였으며, 올해 12억 1,000만 달러에 달할 전망입니다(Global Growth Insights, 2025).
관련 서비스(ASO 도구, 모바일 광고 기술을 위한 경쟁 벤치마크, 모바일 전문 벤처 캐피탈을 위한 포트폴리오 스코어링 모델 등)를 구축한다면 결국 같은 분기점에 도달합니다. 공급업체에 비용을 지불하거나, 직접 데이터를 수집해야 합니다.
당면 과제
앱 스토어 데이터는 외부에서 보면 단순해 보입니다. 공개되어 있습니다. Apple은 기존 iTunes JSON 검색을 통해 대부분의 데이터를 제공합니다. Google Play는 브라우저에서 렌더링합니다. 얼마나 어려울까요?
하지만 프로덕션 규모로 시도하는 순간 모든 가정이 무너집니다.
첫 번째 문제는 지역입니다. 미국 인기 차트의 게임 순위는 브라질 순위와 무관하며, 일본과도 다릅니다. 국가별로 가격이 다릅니다. 사용 가능 여부도 국가별로 바뀝니다. 설명이 현지화되며, 때로는 완전히 다른 마케팅 스토리로 바뀝니다. 미국 전용 퍼블리셔의 앱을 벤치마킹한다면 수집 지역 하나로 충분합니다. 글로벌 목표를 가진 대상을 벤치마킹하려면 수십 개의 수집 지역이 필요하며, 실제로 해당 국가에서 접속하는 것으로 인식되어야 합니다. 스토어 CDN이 이를 확인합니다.
두 번째 문제는 최신성입니다. 카테고리 순위는 매시간 바뀝니다. 패치 오류가 발생하면 신규 릴리스에 대한 리뷰 분위기가 하루 만에 뒤집힐 수 있습니다. 데이터가 하루 전 것이라면 고객은 이미 트위터에서 변화를 확인했을 것입니다. 플랫폼이 정보가 아닌 후행 지표가 됩니다.
세 번째는 수집 예산입니다. Apple의 공개 endpoint는 지속적인 트래픽을 허용합니다. Google Play는 그렇지 않습니다. Play의 리스팅 페이지는 JavaScript를 렌더링하고, 차트 페이지는 주기적으로 변경되는 남용 방지 token을 사용하여 XHR 호출로 페이지를 넘기며, 두 스토어 모두 header를 확인하기도 전에 TLS 계층에서 스크래퍼를 핑거프린팅합니다. 단일 IP가 원활하게 처리할 수 있는 범위를 넘어서는 순간, 두 스토어 모두 유의미한 response를 반환하지 않습니다. 빈약한 리스팅이나 누락된 리뷰 페이지만 받게 되거나 아예 아무것도 받지 못합니다.
네 번째는 리뷰 파이프라인입니다. Play의 인기 앱 하나는 출시된 모든 지역에서 매일 수천 개의 리뷰를 생성합니다. 신뢰할 수 있는 감성 신호를 원한다면 샘플링을 해서는 안 됩니다. 누락 없이 국가별로 전체 스트림을 영구적으로 가져와야 합니다. 이는 규모에 맞게 제품 리뷰 집계하기에서 다룬 것과 동일한 형태의 문제입니다.
이는 스크래퍼의 문제가 아닙니다. 인프라의 문제입니다.
접근 방식
다행인 점은 네 가지 문제를 분리하면 각각 명확한 해답을 얻을 수 있다는 것입니다.
지리적 위치의 경우, 요청당 종료 국가를 고정하고 해당 종료 노드가 선언된 위치에서 제대로 확인되는지 검증할 수 있는 proxy 계층이 필요합니다. 저렴한 proxy 풀은 국가 정보를 속이는 경우가 많습니다. 네덜란드로 지리적 위치가 확인되는 IP에서 독일 Play 순위를 수집하면, 독일어 메타데이터가 포함된 네덜란드 결과를 받게 되며 이를 알아채지 못합니다. FourA와 같은 플랫폼은 이를 Proxy Finder 계층에서 해결합니다. 국가를 선택하고 실제로 해당 국가에 있는 종료 노드를 확보한 뒤, 후속 호출에서 동일한 종료 노드를 재사용하여 세션 일관성을 유지합니다.
최신성 확보를 위해 필요한 것은 더 많은 스크래퍼가 아니라 더 나은 일정 관리입니다. 순위 페이지는 빠른 레인(관심 있는 카테고리에 대해 국가별로 몇 분마다)으로 처리합니다. 세부 페이지는 중간 레인(순위 변동이 감지될 때만 매시간)으로 처리합니다. 리뷰는 느린 레인(매일 전체 스윕)을 기본으로 하되 순위나 평점이 변동할 때 빠른 레인 트리거를 적용합니다. 이러한 일정 관리는 데이터 플랫폼 자체가 아니라 그 위에서 실행되는 수백 줄의 코드일 뿐입니다.
Play의 수집 예산을 관리하려면, 중요한 곳에는 JS 렌더링 경로를 사용하고 그렇지 않은 곳에는 직접 경로를 사용해야 합니다. 일부 Play 페이지는 올바른 요청을 보내면 깔끔한 JSON을 제공합니다. 하지만 다른 페이지들은 CAPTCHA 대신 의미 있는 응답을 반환하기 위해 실제 브라우저, 실제 쿠키, 그리고 실제 봇 방어 솔루션이 필요합니다. Auto는 FourA에서 이러한 결정을 오케스트레이션합니다. 먼저 저렴한 경로를 사용하고, 실패할 경우 Browser로 에스컬레이션합니다. 프로덕션 환경에서는 모든 호출에 대해 오케스트레이터 비용을 지불하지 않도록 성공한 경로를 Single 또는 Browser에서 직접 재실행합니다.
리뷰 파이프라인의 경우, 영리한 코드보다 처리량과 멱등성이 더 중요합니다. 깔끔하고 구조화된 응답(경우에 따라 JSON, HTML, CAPTCHA가 섞이지 않은)을 반환하는 요청 계층, 조용히 실패하지 않는 재시도 로직, 그리고 고객이 오래된 데이터를 보기 전에 특정 국가의 성능 저하를 발견할 수 있는 요청별 결과 추적이 필요합니다.
결과
이 네 가지를 제대로 구현하는 사내 팀은 훨씬 적은 비용으로 벤더 구독과 맞먹는 결과를 낼 수 있습니다. 손익분기점을 넘으면 계산이 빠르게 달라집니다. 중간급 ASO 서비스는 지원하는 국가당 매월 막대한 비용이 들지만, FourA 스타일 인프라의 소규모 수집 스택은 그 비용의 일부만으로 동일한 국가를 커버합니다(공개된 ASO 도구 가격에 기반한 예시 시나리오).
비용보다 더 중요한 것은 파이프라인을 직접 소유한다는 점입니다. 고객이 화요일에 왜 순위가 급상승했는지 물어볼 때, 벤더 대시보드를 보며 모호하게 답하는 대신 원본 응답 기록을 바탕으로 명확하게 답변할 수 있습니다.
성공적인 팀들은 세 가지 습관을 공유합니다. 이들은 국가별 성공률을 최우선 지표로 모니터링합니다. 한 국가에서 성공률이 98%에서 82%로 떨어지는 것은 부차적인 문제가 아니라 조기 경고입니다. 파서는 변경되고 오래된 버그는 새로운 코드에서 다시 테스트해야 하므로, 이들은 파싱된 필드뿐만 아니라 원시 response를 저장합니다. 또한 단일 수집 윈도우의 리뷰 수를 절대 신뢰하지 않습니다. 모든 스토어에는 상태가 좋지 않은 시간대가 존재하므로, 이동 평균을 기반으로 시스템을 구축해야 합니다.
핵심 요약
앱 스토어 인텔리전스는 단순한 스크래핑 문제가 아닙니다. 이는 스케줄링, 지리적 위치, 세션 일관성의 문제이며, 양대 스토어가 능동적으로 연결을 방해하려 하는 상황에서도 안정성을 유지하는 request 계층 위에서 동작해야 합니다.
앱 스토어 데이터를 판매하는 벤더들도 여러분이 지불해야 할 인프라 비용을 동일하게 부담하고 있습니다. 중요한 것은 이 비용을 여러분의 조건에 맞춰 한 번만 구축할 것인지, 아니면 그들의 조건에 맞춰 매달 지불할 것인지 선택하는 것입니다.