목록만 긁는 크롤러로는 '신상'을 판정할 수 없었다

목록에는 사이즈가 없었다

쇼핑 데이터 서비스에 붙여둔 수집기는 목록 페이지만 돌고 있었다. 상품명, 가격, 썸네일, 링크. 화면을 채우기엔 충분했다. 문제는 옷을 실제로 고를 때 필요한 게 그 넷이 아니라는 거였다. 실측 사이즈, 소재 혼용률, 세탁 방법. 전부 상세 페이지 안쪽에 있었다.

목록만 긁는 구조는 편하다. 요청 한 번에 수십 건이 딸려 온다. 상세는 정반대다. 상품 하나에 요청 하나. 수집량이 그대로 곱해진다. 그래서 계속 미뤄뒀는데, 미뤄둔 채로는 이 서비스가 하는 일이 "링크 모아주기"에서 더 올라가지 않았다. 며칠 전 증분 수집이 조용히 멈춰 있던 걸 고치고 나니, 안정적으로 도는 파이프라인에 정작 담을 게 없다는 게 더 눈에 띄었다.

파서를 상품마다 따로 두지 않으려고 했다

상세 페이지는 판매자가 만든다. 같은 카테고리라도 표 형태가 제각각이었다. 어떤 곳은 표로, 어떤 곳은 이미지 안에 글자로, 어떤 곳은 본문 문장 사이에 흘려서 적어놨다.

판매자별 파서를 만들기 시작하면 끝이 없다는 건 해보기 전에도 알았다. 그래서 항목을 먼저 고정했다. 실측, 소재, 세탁 세 종류만 뽑는다. 그 외에 뭐가 적혀 있든 버린다. 뽑는 대상을 줄이니 규칙도 줄었고, 못 뽑은 건 못 뽑았다고 비워두는 쪽을 택했다. 억지로 채우면 틀린 값이 들어가고, 틀린 실측 사이즈는 없는 것보다 나쁘다.

'신상'은 등록일로 판정되지 않았다

같이 넣은 게 신상 판정이었다. 처음엔 등록일 하나면 되는 줄 알았다. 아니었다.

신호	그대로 믿었을 때
상품 등록일	재등록·품절 복구 상품이 전부 신상으로 올라온다
판매자가 붙인 '신상' 문구	아무 때나 붙는다. 기준이 없다
최초 수집 시각	수집기가 늦게 발견한 오래된 상품도 신상이 된다

셋 다 단독으로는 못 쓴다. 결국 최초 수집 시각을 기준선으로 두되, 등록일이 그보다 한참 앞서 있으면 제외하는 식으로 조합했다. 판매자 문구는 참고만 하고 판정에는 넣지 않았다.

남은 이야기

배포까지는 마쳤다. 다만 조합 규칙의 경계값이 맞는지는 아직 모르겠다. "한참 앞서 있으면"의 기준을 며칠로 잡을지는 데이터가 좀 더 쌓여야 판단이 될 것 같다.

다음에 비슷한 걸 만든다면 순서를 바꿀 것 같다. 수집 범위를 넓히기 전에 "이 데이터로 사용자가 무슨 결정을 하는가"를 먼저 적어두는 것. 목록 데이터는 화면을 채우고, 상세 데이터는 결정을 만든다. 비용은 후자가 훨씬 비싸지만 서비스를 서비스로 만드는 건 후자 쪽이었다.