시세 표에서 값을 뽑아야 해서 브라우저를 띄워 구조를 확인했다. class도 id도 붙어 있지 않아서 nth-child 위치 선택자밖에 쓸 수 없는 상태였다.
Table of contents
Open Table of contents
조치 — 위치 대신 내용으로
nth-child로 지정하는 선택자는 행 순서가 바뀌면 그대로 깨진다. 대신 전 행을 순회하면서 cells[0]의 textContent로 대상 행을 찾게 했다.
const rows = [...document.querySelectorAll('tr')];
const target = rows.find(tr => /RDIMM|UDIMM/i.test(tr.cells[0]?.textContent));행 순서가 바뀌어도 되고 표가 하나 더 생겨도 된다. 내용으로 찾는 것이 위치로 찾는 것보다 구조 변경에 덜 민감하다.
검증 — 세어 본 셀 순서
행을 찾았으니 어느 셀을 쓸지를 정해야 했다. 셀 내용을 전부 출력해 보니 값이 이전 값과 함께 두 번씩 나오는 구조였다.
앞에서 몇 개를 자르면 되겠거니 했으면 고가와 저가를 가져왔을 텐데 내가 필요한 것은 cells[5]의 평균이었다. 셀 순서를 세어 보지 않으면 다른 값을 적재하게 되고 그것도 숫자여서 티가 안 난다.
주의 — 파싱과 시간대
값에 $와 천 단위 ,가 붙어 있어서 그대로 parseFloat하면 실패한다. replace(/[$,]/g, '')로 제거하고 변환하게 했다.
표 근처의 갱신 시각이 UTC 기준이라 Asia/Seoul로 바꾸지 않고 저장하면 우리 시각과 어긋난다는 것도 확인했다. 이 값은 주간 갱신이라 매일 수집해도 대부분 같은 값이 나온다.
설정 — 중복 적재와 추정치 표기
주간 갱신인데 매일 적재하면 같은 값이 일곱 번 쌓인다. 두 가지 방법이 있었는데 매일 그대로 쌓고 조회 때 중복을 걸러 내는 것과 updated_at이 직전 관측과 같으면 넣지 않는 것이다. 뒤쪽을 골랐다. 이유는 값이 바뀐 시점만 남아야 시계열이 곧바로 읽혀서다. 대신 수집이 며칠 죽어도 표에 구멍이 안 보이는 것을 감수했고 그래서 수집 실행 로그를 따로 남겼다.
필요한 용량 라인이 무료 범위에 없어서 다른 용량 값을 환산해 채운 것이 하나 있었다. 용량당 단가가 선형이 아니므로 정확한 값이 아니고 그래서 is_estimate와 estimate_basis를 별도 필드로 함께 저장했다. 추정치를 실측치와 같은 필드에 그냥 넣으면 나중에 구분할 방법이 없다.
결과 — 재현 확인과 절차 기록
추출한 값을 다른 날짜의 기존 기록과 대조하니 완전히 일치했다. 값이 맞는지 확인할 다른 방법이 없는 상황에서 독립적인 기록과의 일치가 파싱이 맞다는 근거가 됐다.
이 과정을 저장소에 docs/scraper.md로 남겼는데 셀 순서와 파싱 규칙과 시간대와 갱신 주기와 추정 표기를 적었다. 문서 없이 코드만 있으면 왜 cells[5]인지를 알 수 없고 표가 바뀌었을 때 무엇이 달라졌는지도 대조할 수 없다.
정리
- 안정적인 선택자가 없으면 전수 순회와 내용 매칭을 쓴다
- 내용 매칭이 구조 변경에 덜 민감하다
- 셀 순서를 세어 보면 값이 두 번씩 나오는 경우가 있다
- 잘못 잘라도 숫자라서 티가 안 난다
$와,를 제거하고 변환한다- 갱신 시각의 시간대와 갱신 주기를 확인한다
updated_at이 같으면 적재하지 않아야 시계열이 깔끔해진다- 추정치는
is_estimate로 실측치와 구분되게 표기한다