경쟁사 트래킹의 진짜 문제는 ‘수집’이 아니라 ‘병목’입니다. 스크래핑은 누가 대신해줄 수 있어요. 그런데 결과가 JSON/DB에 갇히는 순간, 마케팅/PM은 다시 엔지니어에게 “최신 export 한번만…”을 요청하게 됩니다. 채널 효율 분석→실행 사이가 느려지고, 결국 CAC 최적화 타이밍을 놓치죠.
dev.to의 「From Script to Spreadsheet」가 재밌는 포인트는 여기서 “와 이거다!” 싶게 병목을 정확히 찌른다는 겁니다. 유저(내부 사용자)는 스프레드시트에 경쟁사 URL을 추가하기만 하면 되고, 파이프라인이 제목/가격/샵 정보를 채워 넣습니다. 데이터가 ‘사람이 쓰는 도구(시트)’에 바로 도착하니, 대기열이 사라집니다.
맥락을 그로스 관점으로 해석하면: 이건 단순 자동화가 아니라 ‘의사결정 리드타임 단축’ 장치예요. 가격 포지셔닝, 프로모션 모니터링, 신규 상품 카피 벤치마크 같은 액션이 대부분 시트에서 시작되니까요. 시트 기반 셀프서브는 곧바로 실험 속도를 올리고(실행 빈도↑), 그게 곧 채널별 CPA/CAC 튜닝의 회전수를 늘립니다.
기술적으로도 실전형 디테일이 있습니다. Etsy처럼 동적 렌더링+안티봇이 있는 곳엔 Playwright로 “실제 브라우저”를 띄워 신뢰도를 확보하고, Google Sheets API는 gspread로 연결합니다(출처: dev.to). 그리고 핵심은 배치 업데이트와 중복 방지 로직이에요. 이미 채워진 행은 스킵하고, 새 URL만 긁어오며, 셀 단위가 아니라 batch_update로 한 번에 밀어 넣어 API 제한을 피합니다. 이런 설계가 있어야 ‘스케일 가능한 셀프서브’가 됩니다.
하지만 여기서 끝내면 위험합니다. 스크래핑은 DOM이 바뀌면 깨지고, 오류가 섞이면 의사결정도 같이 오염됩니다. 이 지점에서 두 번째 dev.to 글 「Self Auditing Data Pipeline」의 아이디어를 붙이면, 경쟁사 트래커가 한 단계 진화합니다. “기계가 만든 데이터를 기계가 검증”하는 셀프 감사(검증) 파이프라인이죠.
적용 방법은 단순합니다. 1) 무료에 가까운 룰 기반 게이트를 먼저 둡니다: 가격이 0이 비정상적으로 많지 않은지, 통화/단위가 섞이지 않았는지, 제목이 N/A 비율이 일정 임계치(예: 10%)를 넘는지, 동일 URL 중복이 증가했는지 같은 체크요. 2) 그 다음에야 LLM 감사관을 “샘플링”으로 돌립니다: 특정 샵의 가격이 갑자기 5배 튀었는데 DOM 파싱 오류인지 실제 가격 인상인지, 상품명이 숙박시설처럼 이상하게 들어왔는지 등 사람이 보던 ‘스니프 테스트’를 모델이 대신하게 하는 거죠(출처: dev.to).
시사점은 명확합니다. 셀프서브 트래커는 단순 편의가 아니라 그로스 시스템입니다. 첫째, 분석→실행 리드타임을 줄여 채널 최적화 빈도를 올립니다(실험 루프 단축). 둘째, 엔지니어 의존도를 줄여 조직 전체의 실험 처리량을 키웁니다(병목 제거). 셋째, LLM 기반 품질 게이트로 자동화를 스케일하면서도 데이터 신뢰도를 유지합니다(잘못된 인사이트로 인한 CAC 악화 방지).
전망: 이 패턴은 Etsy에만 국한되지 않습니다. “입력은 시트(또는 폼), 출력도 시트, 실행은 스케줄러(GitHub Actions 등), 검증은 게이트+LLM” 조합은 거의 모든 경쟁사 인텔리전스에 복제 가능합니다. 다음 단계로는 가격 히스토리 탭(일자별 스냅샷)로 변동 알림을 만들고, 변동이 큰 SKU만 재수집하는 ‘우선순위 크롤링’까지 붙여볼 만해요. 이거 바이럴 될 것 같은데? 내부에서 한번 맛보면, 다른 팀도 “우리도 이걸로 해요” 하면서 확산됩니다. 결국 더 빠른 실험이 더 낮은 CAC로 이어지니까요. 빨리 테스트해봐야 됩니다.