PageSpeed API 429, 18번 요청이 모두 막힌 이유

블로그 속도를 숫자로 남기려고 PageSpeed Insights API를 스크립트로 호출했다. 2026년 10월 13일, 홈과 최신 글 2개를 mobile과 desktop으로 나눠 6개 조합을 만들고 조합마다 3번씩, 모두 18번 요청했다. 18번 모두 HTTP 429 RESOURCE_EXHAUSTED였고, 응답에는 quota_limit_value: "0"이 들어 있었다.

이 글은 PageSpeed API에서 429를 받고 "블로그가 문제인가" 하고 멈춘 사람을 위한 판독 순서다. 목표는 응답 필드로 사이트 문제와 측정 도구의 quota 문제를 가르고, 점수를 추정하지 않고 미측정으로 남긴 뒤, 다음 측정 경로를 고르는 것이다.

먼저 범위를 밝힌다. 이 글은 차단을 해결한 기록이 아니다. 이 날 점수는 끝내 얻지 못했고, 아래의 다음 경로도 아직 시도하지 않았다.

무슨 일이 있었나

호출한 것은 PageSpeed Insights API v5의 runPagespeed 메서드였고, 요청 경로는 /pagespeedonline/v5/runPagespeed?url=<인코딩한 URL>&strategy=mobile|desktop 형식이었다. 요청 주소에는 url과 strategy 두 파라미터만 있었다.

스크립트는 429를 받으면 2초, 다시 받으면 4초를 기다렸다가 재시도했다. 조합마다 3번, 6개 조합이라 18번이다. 결과는 하나도 다르지 않았다. 18번 모두 429였고, Lighthouse 점수도, LCP·INP·CLS도, CrUX 실사용 값도 받지 못했다.

같은 날 같은 블로그의 공개 페이지는 정상이었다. Chrome 일반 UA와 Googlebot UA로 표본 11개 URL과 모바일 변형을 요청한 44번이 모두 HTTP 200이었다.

1단계: 응답의 service·reason·quota 필드를 읽는다

받은 응답 하나를 옮긴다. consumer와 project 번호는 지웠고, 반복되는 message와 한도 상향 안내(Help) 블록은 줄였다.

{
  "error": {
    "code": 429,
    "message": "Quota exceeded for quota metric 'Queries' and limit 'Queries per day' of service 'pagespeedonline.googleapis.com' for consumer '<삭제>'.",
    "errors": [
      { "message": "(위와 같음)", "domain": "global", "reason": "rateLimitExceeded" }
    ],
    "status": "RESOURCE_EXHAUSTED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "RATE_LIMIT_EXCEEDED",
        "domain": "googleapis.com",
        "metadata": {
          "quota_limit_value": "0",
          "quota_limit": "defaultPerDayPerProject",
          "consumer": "<삭제>",
          "service": "pagespeedonline.googleapis.com",
          "quota_location": "global",
          "quota_unit": "1/d/{project}",
          "quota_metric": "pagespeedonline.googleapis.com/default"
        }
      }
    ]
  }
}

필드를 하나씩 읽으면 판정이 나온다.

필드값읽는 법
HTTP 상태, error.code429요청이 거절됐다. 측정 대상 페이지의 응답 코드가 아니다.
statusRESOURCE_EXHAUSTED호출 쪽 자원(quota)이 바닥났다는 분류다.
reasonrateLimitExceeded, RATE_LIMIT_EXCEEDED한도 초과로 거절했다.
servicepagespeedonline.googleapis.com막힌 것은 PageSpeed API 서비스 사용량이다. 내 블로그 주소가 아니다.
quota_limitdefaultPerDayPerProject프로젝트당 하루 기본 한도에 걸렸다.
quota_unit1/d/{project}하루 단위, 프로젝트 단위로 센다.
quota_limit_value"0"그 하루 한도 값이 0으로 기록돼 있다.
messageQueries per day일일 쿼리 한도 초과라는 같은 내용을 문장으로 다시 적었다.

판정에서 중요한 것은 consumer와 service다. 오류가 붙은 대상은 요청을 보낸 쪽(consumer)이 쓰는 PageSpeed API 서비스다. 측정하려던 블로그 URL에 대한 판정은 응답 어디에도 없다. 그래서 이 429는 "블로그가 느리다"도 "블로그가 죽었다"도 뜻하지 않는다. 같은 날 공개 페이지 44번이 모두 200이었던 기록도 같은 방향을 가리킨다.

이 consumer의 하루 한도가 왜 0으로 잡혀 있었는지는 이번 기록에 없다. 응답은 한도 상향 요청 안내(Request a higher quota limit.) 링크를 함께 돌려주었지만, 이번 작업에서는 계정을 만들거나 quota를 바꾸지 않았다.

2단계: 점수는 0점이 아니라 '미측정'으로 남긴다

측정이 막히면 보고서 칸을 무엇으로 채울지가 남는다. 이번에는 점수와 Core Web Vitals 칸을 모두 비워 두고 추정값을 적지 않았다.

  • 0점으로 적지 않는다. 0점은 측정했더니 나빴다는 뜻이 되기 때문이다.
  • 다른 날, 다른 도구의 값을 끌어와 채우지 않는다.
  • 이 항목을 사이트 결함이 아니라 med 등급의 검증 공백으로 분류했다. 결함 목록에 넣으면 고칠 대상이 블로그 설정처럼 보이지만, Blogger 설정을 바꿔서는 API quota 오류를 고칠 수 없다.

당시 재시도의 한계

2초, 4초 backoff는 결과를 바꾸지 못했다. 응답 필드를 다시 보면 이유가 보인다. 한도는 하루 단위(1/d/{project})이고 그 값이 0이다. 몇 초를 기다린다고 하루 한도가 다시 채워질 수 없고, 한도 자체가 0이면 하루를 기다려도 같은 결과가 나올 가능성이 크다. 이 판단은 필드 값에서 끌어낸 것이고, 다음 날 다시 호출해 확인하지는 않았다.

결국 18번의 요청이 알려 준 것은 "6개 조합 모두 같은 이유로 막혔다"는 것뿐이었다. 지금이라면 첫 429에서 quota_unit과 quota_limit_value를 먼저 읽는다. 하루 단위 한도이고 값이 0이면 그 자리에서 재시도를 멈추고, 결과를 미측정으로 기록한다. 초 단위 backoff는 분·초 단위 한도에 걸렸을 때에나 의미가 있다고 본다. 이 역시 이번에 실험으로 확인한 것은 아니다.

3단계: 다음 확인 경로 (아직 시도하지 않음)

감사 보고서에 적어 둔 재검증 경로는 두 가지다. 둘 다 이 글을 쓰는 시점에는 시도하지 않았고, 성공했다고 말할 수 없다.

  • 정상 quota가 있는 API key 또는 project로 같은 API를 다시 호출한다. 이번 요청 주소에는 key 파라미터가 없었다.
  • 공개 PageSpeed Insights 웹 화면에서 같은 URL을 실행하고 결과를 기록한다.

어느 쪽으로 점수를 얻든, 그때 비로소 블로그 속도를 이야기할 수 있다. 그 전까지 속도 항목의 상태는 "측정 실패"다.

이 기록으로 답하지 않는 것

  • 이 블로그의 실제 Lighthouse 점수나 Core Web Vitals 값.
  • 이 consumer의 일일 한도가 0이 된 이유.
  • API key를 붙이거나 웹 화면에서 실행하면 실제로 측정이 되는지.

측정 도구가 막혀도 검색 노출을 점검할 기본 항목은 남아 있다. 그 목록은 블로그 SEO 초보 실수 5가지 — GSC 등록부터 내부 링크까지에 정리했다. 도구가 내놓은 결과와 실제 상태를 구분하는 문제는 테스트 113개 다 통과했는데 실제론 0개를 긁었다 — AI가 짠 수집기의 함정에서도 다뤘다.

결론: 429는 측정 도구의 상태다

PageSpeed API의 429 RESOURCE_EXHAUSTED는 블로그가 아니라 호출한 쪽의 PageSpeed API quota가 막혔다는 응답이었다. service, quota_unit, quota_limit_value를 먼저 읽었다면 18번까지 재시도할 이유가 없었다. 점수는 0점이 아니라 미측정으로 남겼고, 다음 경로는 quota가 있는 key나 공개 웹 실행이다. 그 결과를 얻기 전까지 블로그 속도에 대한 결론은 내리지 않는다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기