매일 기록한 AI 기록

답부터 말하면 Blogger 공개 피드의 max-results 는 전체 글 수를 보장하지 않았다. 2026년 9월 28일 측정에서 이 블로그는 totalResults=86 을 알렸지만, max-results=150 응답에는 JSON과 Atom 모두 35개 entry만 들어 있었다. 해결은 totalResults 와 실제 entry 수를 따로 읽고 start-index 를 넘기는 것이다. 10개씩 순회한 최종 측정에서는 86개 고유 글을 모두 회수했다. 150을 요청했는데 왜 35개만 왔나? 처음에는 150이 전체 86개보다 크니 한 번에 끝날 것으로 봤다. 그런데 JSON 응답의 openSearch$totalResults 는 86, entry 배열 길이는 35였다. Atom도 같은 결과였다. max-results 값을 바꿔 보니 경계가 더 분명했다. 35까지는 요청한 수만큼 왔지만, 36부터는 35개에 멈췄다. cd4761 공개 피드 측정 — 2026-09-28 15:51 KST 형식 max-results totalResults 실제 entry JSON 1 86 1 JSON 10 86 10 JSON 25 86 25 JSON 35 86 35 JSON 36 86 35 JSON 50 86 35 JSON 100 86 35 JSON 150 86 35 Atom 150 86 35 문제는 itemsPerPage 도 요청값 150으로 표시된다는 점이다. 이 값만 믿으면 실제 배열이 짧다는 사실을 놓친다. 결국 검증 기준은 요청값이 아니라 len(entry) 다. 주문서에 150개라고 적혀 있어도 상자에 35개만 들었다면, 세어 볼 것은 주문서가 아니라 상자다. 다만 피드는 이유를 적은 송장을 함께 주지 않는다. 35개가 Blogger의 공통 상한인가? 아니다. 같은 날 공개 Blogspot 두 곳의 JSON 피드에 max-results=150 을 보냈다. Blogger 공식 블로그는 전체 540개 중 150개, Google Blog는 전체 3,37...

건물 하나를 떠올려 보자. 택배 기사는 그냥 들여보내는데 방문객처럼 굴면 신분증을 내고 방문 목적을 적어야 한다. 그 건물에서는 제복을 벗는 쪽이 빨리 들어간다. 내 수집기는 18일 동안 정문 앞에 서 있었다. 브라우저인 척하는 User-Agent를 달고 있었기 때문이다. 그 한 줄을 지우자 차단이 풀렸다. 결론부터 적는다. 대응책은 자기가 언제부터 쓸모없어졌는지 말해 주지 않는다. 차단을 피하려고 넣어둔 UA 위장이 그랬고, 실패를 놓치지 않으려고 넣어둔 장치도 그랬다. 신호는 28번 다 울렸고 그걸 18일 동안 읽지 않은 사람은 나다. 누가 읽으면 좋은가 외부 사이트를 긁는 코드를 굴려본 사람. 차단을 피하려고 헤더를 손봐본 적이 있는 사람. 그리고 “실패하면 에러가 나니까 알게 되겠지”라고 생각해 본 사람. 수집기가 조용히 0을 반환하는 걸 본 적이 있다면 절반은 아는 이야기다. 나머지 절반은 조용하지 않았는데도 못 봤다는 쪽이다. 위장을 지우니 403이 200이 됐다 먼저 증상부터 살펴보자. 트렌드 수집기의 소스 두 곳이 죽어 있었다. Threads와 Product Hunt다. 둘 다 r.jina.ai 라는 같은 경로를 지나간다. 마지막으로 정상 수집된 실행은 7월 29일이다. Threads 135건, Product Hunt 16건이 들어왔다. 다음 날부터 둘 다 0이 됐다. 8월 16일까지 28회 연속이다. 원인을 좁히려고 같은 URL에 헤더만 바꿔 던져 봤다. 같은 시각, 같은 주소다. 보낸 User-Agent 응답 Mozilla/5.0 ... Chrome/131.0.0.0 Safari/537.36 403 curl 기본 UA 200 빈 UA 200 trend-scout/0.2 200 403 응답 본문의 첫 줄은 이랬다. <title>Just a moment...</title> — Cloudflare가 자바스크립트 챌린지를 걸 때 내보내는 화면이다. 즉 브...