글

처음 읽는다면

설정의 시작부터 막힌 문제, 도구에 드는 비용까지.

최근 보완: 2026-09-23 · 위 핵심 글 4편. 점검 순서와 관련 글을 보완했습니다. 실측·코드 분석·가정 계산은 구분해 표시합니다.

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 번호는 지웠고, 반복되는 mess...

Blogger 검색 설명, 분명 넣었는데 비어 있던 이유

Blogger 글 편집 화면의 검색 설명 칸에 값을 넣었다. 그런데 공개된 글의 HTML <head> 를 열어 보니 name="description" 메타 태그가 3개였다. 첫 번째는 입력한 설명이었고, 두 번째는 빈 문자열, 세 번째는 글자 그대로 false 였다. 2026년 10월 13일 이 블로그의 공개 HTML을 받아 확인한 결과다. 이 글은 검색 설명을 분명히 입력했는데 결과가 비어 보이는 Blogger 사용자를 위한 확인 순서다. 목표는 편집기에 넣은 값과 head에 실제로 찍힌 값을 따로 세고, 정상 값과 빈 값이 head의 어느 출처에서 나오는지 나누고, 고친 뒤 같은 기준으로 다시 재는 것이다. 먼저 결론의 범위를 밝힌다. 같은 날 테마를 고쳐 저장했고, 글 91편을 검사 스크립트로 다시 재서 91편 모두 기준을 통과했다. 이 기준은 head 태그의 개수와 빈 값을 보는 것이다. 검색 결과나 유입이 달라졌는지는 확인하지 않았다. 그리고 검색 설명 칸이 빈 글에는 지금도 description 태그가 아예 없다. 증상: 입력한 설명 뒤에 빈 값과 false가 붙는다 당시 감사에서 최근 글 5개와 오래된 글 2개는 description을 3개씩 출력했다. 정상 검색 설명, 빈 문자열, false 순서였다. 나머지 오래된 글도 description이 2개로 중복됐고, 홈은 같은 내용의 description을 2번 출력했다. OG 태그도 같은 모양이었다. 가장 최근 글 하나를 기준으로 세면 다음과 같다. 태그 개수 값 description 3 정상 설명, 빈 값, false og:description 3 정상 설명, 빈 값, false og:title 2 정상 제목, 빈 값 og:url 2 정상 주소, 빈 값 og:type 2 둘 다 article 편집기에서 보면 설명은 정상으로 들어가 있다. 문제는 입력값이 아니라 템플릿이 head에 무엇을 몇 번 출력하느냐였다. 검색엔진이나 공유 미리보기가 이 중 어느 값...

Anthropic 순손실 807억 달러는 현금 소진일까? WSJ 보도 초안 기준으로 따져봤다

이미지
월스트리트저널(WSJ)이 2026-10-20 보도한 상장신고서(S-1) 초안 수치로 계산하면, Anthropic의 매출 대비 컴퓨팅 지출 비율은 2025년 연간 약 159%에서 2026년 상반기 약 55%로 낮아졌다. 비공개 초안 수치는 확정 공시가 아니어서 바뀔 수 있다. 나는 Anthropic의 Claude를 매일 사용한다. 출처와 보도 검증: 어디까지 확인된 사실인가 이번 수치의 1차 출처는 WSJ Anissa Gardizy 기자의 2026-10-20 단독 보도다. 기자는 비공개 상장신고서 초안을 입수해 기사를 썼고, Anthropic 측은 논평을 거부했다. 따라서 아래 수치는 모두 보도된 초안 기준의 조건부 수치다. 내가 확인한 후속 보도는 2026-10-20 로이터·블룸버그와 2026-10-21 전자신문 기사다. 이 글이 사용한 초안 재무 수치는 이들 기사에서도 모두 WSJ 보도를 인용한 것이다. 로이터는 기업가치 논의처럼 자체 취재한 내용도 함께 전했다. 즉 나는 S-1 원문이 아니라 WSJ가 전한 초안 수치를 읽고 있다. 매출과 컴퓨팅 지출: 규모가 커지면 인프라 부담 비율은 줄어드는가 매출이 빠르게 늘면서 매출 대비 컴퓨팅 지출 비율은 뚜렷하게 낮아졌다. 2025년에는 컴퓨팅 지출이 매출보다 컸지만, 2026년 상반기에는 매출의 절반을 조금 넘는 수준이다. WSJ가 입수한 상장신고서 초안에 따르면, 2026년 상반기 매출은 163억 달러로 전년 동기 11억 달러에서 크게 늘었다. 같은 기간 컴퓨팅 용량 및 인프라 지출은 약 90억 달러로, 전년 동기에는 23억 달러였다. 2025년 연간으로는 매출 46억 달러, 컴퓨팅 지출 73억 달러였다. 초안에는 향후 수년간 컴퓨팅 용량 확보에 7,500억 달러를 쓸 가능성도 담겼다. 여기에는 현재 협상 중인 계약이 포함돼 있어 전액 확정된 금액이 아니다. 기업공개(IPO) 기업가치가 최대 2조 달러에 이를 가능성도 WSJ가 보도했지만, 확정된 바는 없다. 로이터는 2026-10-20 일부 ...

Blogger 예약 글이 16시간 일찍 올라갔다, 범인은 시간대

Blogger 설정의 시간대가 한국이 아니면, 예약 시간을 그 시간대로 바꿔서 넣고 싶어진다. 2026년 10월 초 그렇게 했다가 예약이 16시간 일찍 잡혔다. 한국시간을 태평양 시간으로 한 번 바꿔 넣었는데, 편집기가 그 값을 다시 한국시간으로 읽었다. 환산은 한 번이었지만, 그 값을 한국시간으로 읽는 단계에서 어긋났다. 이 글은 Blogger 예약 발행을 한국시간 기준으로 잡으려는 운영자를 위한 확인 순서다. 목표는 설정 시간대, 브라우저 시간대, 편집기 입력값, 공개 피드 값을 한 표에 놓고 내 환경에서 입력값이 어느 시간대로 해석되는지 판별한 뒤 예약을 바로잡는 것이다. 범위를 먼저 밝힌다. 아래는 10월 4일 이 블로그와 이 브라우저 환경에서 확인한 사례다. Blogger 편집기는 예약 필드 옆에 시간대를 표시하지 않았다. 그래서 모든 환경에서 입력값이 브라우저 시간대로 해석된다고 단정하지 않는다. 내 환경의 해석은 아래 방법으로 직접 확인해야 한다. 네 가지 값이 서로 달랐다 값 어디서 보나 당시 값 블로그 설정 시간대 Blogger 설정 시간대(GMT-07:00) 미 태평양 시간 – 로스앤젤레스 브라우저 시간대 브라우저의 Intl API Asia/Seoul 편집기 입력값 글 설정의 게시 날짜 2026. 10. 2. / 오후 5:00 공개 피드 published 공개 피드 2026-10-02T01:00:00.000-07:00 브라우저 시간대는 블로그 편집에 쓴 브라우저에서 다음 식의 값으로 확인했다. Intl.DateTimeFormat().resolvedOptions().timeZone 핵심은 마지막 두 줄이다. 공개 피드의 2026-10-02T01:00:00.000-07:00 을 한국시간으로 바꾸면 10월 2일 오후 5시다. 편집기에 넣은 오후 5:00 이 그대로 한국시간 오후 5시가 된 것이다. 블로그 설정은 GMT-07이었지만, 이 편집기에서 입력값은 브라우저의 한국시간으로 해석됐다. 공개 피드는 시각을 -07:00 오프셋으...

Aside CLI 맥 설치, 앱 버전만 보면 놓치는 것

Aside를 맥에 설치했다면 확인할 것이 두 가지다. 하나는 /Applications 에 들어가는 앱이고, 다른 하나는 터미널에서 부르는 aside 명령이다. 2026년 9월 8일 Apple Silicon(darwin arm64) Mac에 설치할 때 이 둘은 위치도, 버전도, 설치 방법도 달랐다. 앱이 열린다고 해서 셸에서 명령이 잡힌다는 보장은 없다. 이 글은 맥에서 Aside를 터미널 도구로도 쓰려는 개발자를 위한 확인 순서다. 목표는 앱과 CLI가 각각 어디에 있는지 확인하고, 새 로그인 셸에서 aside --version 과 aside --help 가 실행되는 상태까지 가는 것이다. 범위를 먼저 밝힌다. 아래 버전과 경로는 9월 8일 설치 당시 값이다. 버전은 이후 바뀔 수 있다. 계정 로그인과 MCP 연결은 당시 설치 검증에 포함하지 않았기 때문에 이 글에서도 다루지 않는다. 설치 대상은 두 개였다 구분 설치 위치 설치 방법 설치 당시 버전 앱 /Applications/Aside.app Homebrew cask aside (공식 배포 DMG를 Homebrew가 내려받음) 1.0.825.1 CLI ~/.local/bin/aside (심볼릭 링크) 공식 개발자 문서의 설치 스크립트 1.26.906.1630 두 버전 번호는 형식부터 다르다. 앱 버전을 확인했다고 CLI 버전까지 확인한 것이 아니라는 점을 여기서 알 수 있다. 1단계: 앱 설치를 확인한다 앱은 Homebrew cask aside 로 설치했다. 기록에는 cask 이름만 있고 실행한 명령 원문은 없다. cask 이름으로 쓰면 설치 명령은 다음과 같다. brew install --cask aside 이 cask는 Aside 공식 배포 서버의 DMG를 내려받아 /Applications/Aside.app 에 설치했다. 당시 기록에는 앱 설치 명령, 코드서명 검증 명령, 실행 확인 명령이 모두 종료 코드 0으로 끝났다고 남아 있다. 코드서명 확인에 쓴 정확한 명령은 기록에 없다....

Claude Code v2.1.300 업데이트 전에 볼 것: 훅 updatedInput 검증, 종료 시 백그라운드 강제 종료

Claude Code v2.1.300이 2026-10-15 03:24 KST(2026-10-14T18:24:25Z)에 공개되었다. 직전 릴리스는 v2.1.299(2026-10-14T02:49:42Z)와 v2.1.296(2026-10-09T19:28:59Z)이었다. 매일 이 도구를 사용하는 개발자라면 훅의 updatedInput 입력 검증 강화, 세션 종료 시 백그라운드 프로세스 강제 종료, 로컬 기록(transcript)에 시스템 프롬프트가 남는 변경 사항을 먼저 확인해야 한다. 무엇이 나왔나 GitHub anthropics/claude-code 릴리스 노트 v2.1.300(2026-10-15 확인)에 따르면 이번 버전의 변경 항목은 전체 88개다. 줄머리 첫 단어 기준으로 분류하면 Fixed 41개, [VSCode] 12개, Changed 11개, Added 8개, [Claude Tag] 5개, Improved 4개, 그 외 7개(Removed 1개, Self-hosted runner 1개, [Cloud sessions] 2개, [Remote Control] 1개, [Code Review] 2개)다. 줄머리가 Fixed인 항목이 41개로 전체의 절반에 조금 못 미친다. 훅을 쓰는 사람이 볼 것 이번 릴리스에서 훅 동작에 여러 변경과 수정이 포함되었다. PreToolUse와 PermissionRequest 훅이 돌려주는 updatedInput 을 Claude 자신의 입력처럼 검증하도록 바뀌었다. 알 수 없는 키는 버려지고, 도구가 거부하는 입력이면 호출 자체를 거부(deny)한다. 이전 글인 Claude Code 훅이 안 막는 이유 — 로컬 적용 범위와 deny 점검 에서 다룬 훅 점검 흐름에 이어, 훅 스크립트가 반환하는 인자 형태를 다시 점검할 필요가 있다. 또한 agent 훅이 model 을 무시하던 문제가 수정되었다. 이제 haiku 같은 별칭이 정상 해석되고 서브에이전트 모델이 이를 덮어쓰지 않으며, 사용할 수 없는 모델일 경우 동작 허...

Gemini CLI 로그인이 막혔다, 결국 agy로 넘어간 이유

2026년 10월 4일, 블로그 원고 작성을 Gemini에게 맡기려고 Gemini CLI를 열었다가 개인 Google 계정 로그인에서 막혔다. 같은 날 Antigravity CLI( agy )를 Homebrew로 설치하고 OAuth로 로그인한 뒤, 신뢰 폴더에서 -p 비대화형 실행으로 첫 문장을 받았다. 그 순서를 기록한다. 대상은 개인 계정으로 Gemini 계열 CLI를 처음 붙이려는 개발자다. 목표는 모델 품질 비교가 아니라 설치, 로그인, 첫 출력까지 한 번 통과하는 것이다. 아래 내용은 10월 4일 당시 내 환경의 기록이다. 일반 Gemini CLI가 서비스를 끝냈다는 뜻이 아니며, 지금 모든 개인 계정에서 같은 오류가 난다고 확인한 것도 아니다. 무엇이 막혔나 당시 설치돼 있던 것은 Homebrew로 받은 gemini 0.46.0이었다. 개인 Google 계정으로 로그인하려 하자 개인용 Gemini Code Assist 로그인이 더는 지원되지 않는다는 안내가 나왔다. 기록에 남긴 문구 일부는 다음과 같고, 안내는 Antigravity 쪽으로 이어졌다. no longer supported for Gemini Code Assist for individuals 이 문구는 기록에 옮겨 둔 일부라 전체 원문은 아니다. 같은 오류를 만났다면 화면의 전체 문구와 안내 대상이 무엇인지 직접 확인하자. 나는 이 안내를 따라 Gemini CLI 로그인을 더 붙잡지 않고 Antigravity CLI로 옮겼다. 1. Homebrew로 agy 설치 설치는 cask 한 줄이었다. brew install --cask antigravity-cli 설치 결과 실행 파일은 /opt/homebrew/bin/agy 였고 버전은 1.2.16이었다. 같은 문제를 겪는다면 설치 직후 실행 파일 위치와 버전부터 기록해 두자. 나중에 동작이 바뀌었을 때 어느 버전 기준의 경험인지 구분할 수 있다. 2. Google OAuth로 로그인 로그인은 Google OAuth였다. 내...