매일 기록한 AI 기록

지난 글에서 WSJ 보도로만 본 Anthropic 상장신고서(Form S-1)가 2026-10-26 미국 SEC에 공개 제출됐다. 그때 쓴 어림값을 공시 원문과 다시 대조했다. 2026년 상반기 순손실은 807.48억 달러였지만 영업활동 현금은 +39.29억 달러 순유입이었다. Anthropic S-1 정식 공시와 WSJ 보도 비교 이번 문서는 나스닥(심볼 ANT) 상장을 신청하는 단계의 예비 신고서다. 공모가와 발행주식수, 공모 일정은 아직 빈칸이다. 아래 표는 WSJ가 전한 어림값과 S-1의 정밀값을 나란히 놓은 것이다. 단위는 억 달러이고 근거는 S-1 p.22, p.168, F-7, F-12다. 항목 WSJ 보도(10/20) S-1 공시(10/26) 2026 상반기 매출 약 163 162.86 2025 상반기 매출 11 11.63 상반기 매출 배수 약 14.8배 약 14.0배 2026 상반기 순손실 807 807.48 2026 상반기 컴퓨팅·인프라 약 90 89.45 2025 연간 매출 / 컴퓨팅 46 / 73 45.85 / 73.26 비용 ÷ 매출(2025 연간 → 2026 상반기) 약 159% → 약 55% 159.8% → 54.9% 2026 상반기 영업활동 현금 이전 글에 없음 +39.29 전년 동기 매출이 11.63억 달러로 정밀해져 상반기 매출 배수는 14.8배에서 약 14.0배가 됐다. 보도된 어림값과 공시된 정밀값의 차이이고, 실적을 정정했다는 근거는 없다. 2025년은 12개월, 2026년은 6개월 수치다. 컴퓨팅·인프라는 감가상각을 포함한 회계 비용이다. 출처: Anthropic S-1 p.22·F-7 차트의 2026년 막대는 6개월 수치여서 12개월인 2025년과 길이를 그대로 견줄 수 없다. 또 S-1(p.145)은 이 비용에 클라우드 비용, 리스료, 서버 감가상각을 넣는다. 그래서 지난 글의 '지출' 표현과 달리 이 숫자는 현금 지급 총액이 아니다. 매출원가나 현금 소진액으로 바꿔 읽어도 안 된다. ...

2026년 10월 2일, 텔레그램으로 블로그 작업을 넘기는 봇의 응답이 끊겼다. 운영 기록에 남은 원인은 텔레그램 메시지를 받아 세션에 넘기는 프로세스가 아니라, 브리지가 의존하는 herdr의 멈춤이었다. 대상은 텔레그램 봇을 에이전트 세션에 붙여 쓰다가 "프로세스는 살아 있는데 답장이 안 온다"는 상황을 만난 개발자다. 목표는 프로세스가 살아 있는지와 메시지가 실제로 오가는지를 따로 판정하는 것이다. 아래 내용은 10월 2일 내 환경 한 건의 기록이고, 같은 증상이 모두 herdr 때문이라는 뜻은 아니다. 기록된 증상과 복구 내 구성에서 텔레그램 메시지는 OpenClaw 플러그인과 게이트웨이를 거쳐 블로그 작업 세션으로 넘어간다. 세션 쪽에서 요청을 가져가는 프로세스를 여기서는 소비 프로세스라고 부른다. 이 브리지는 herdr에 의존한다. 10월 2일 응답이 끊겼을 때 herdr 창에는 다음 오류가 떠 있었다. Failed to continue queued messages: Cannot continue from message role: assistant herdr는 launchd 항목 sh.brew.herdr 로 새 PID를 받아 다시 떴다. 그러자 텔레그램 응답도 바로 돌아왔고, 텔레그램 쪽에서 실제로 답장을 받는 것까지 확인했다. 기록에 없는 것도 분명히 해 둔다. herdr를 내가 다시 띄웠는지 launchd가 자동으로 다시 띄웠는지는 남기지 않았다. 응답이 언제부터 얼마나 끊겼는지도 기록에 없다. 위 오류 문자열이 정확히 무엇을 뜻하는지, herdr가 왜 멈췄는지도 이 기록으로는 알 수 없다. 살아 있는 PID가 말해 주지 않는 것 이 사고에서 남긴 교훈은 이렇다. 소비 PID가 살아 있고 ready.json 과 consumer.lock 이 그 PID를 가리키고 있어도 정상이라는 뜻은 아니다. PID와 락 파일은 "소비 프로세스가 떠 있고 자기가 담당이라고 표시했다"는 것까지만 알려 준다. 메시지가...

2026년 10월 2일, 텔레그램 봇에 보낸 '/'로 시작하는 일반 메시지가 명령으로 오인돼, 블로그 세션이 아니라 OpenClaw의 CEO 에이전트로 갔다. 기록에 남은 예는 /Users/... 형태의 파일 경로다. 같은 날 명령 판별 조건을 좁히고 회귀 테스트를 붙였다. 그 조건과 사례표를 정리한다. 대상은 텔레그램 봇이 받은 메시지를 명령과 일반 텍스트로 나눠 서로 다른 실행자에게 보내는 개발자다. 목표는 파일 경로처럼 '/'로 시작하는 일반 텍스트가 명령으로 잡히지 않게 하고, 그 경계를 테스트로 고정하는 것이다. 아래는 내 OpenClaw 텔레그램 브리지 플러그인의 기록이며, 예시 경로는 실제 경로가 아니라 가짜다. 라우팅 규칙과 사고 전날인 10월 1일 라우팅을 바꿨다. 소유자 개인 대화에서 / 로 시작하지 않는 모든 메시지와 사진 캡션을 블로그 세션으로 보낸다. /blog , 모델 선택자, 알림 답장, 중복 방지는 그대로 두고, 다른 /명령 과 다른 사람, 단체방 메시지는 블로그로 보내지 않는다. 이 규칙에서 기준은 첫 글자 '/'였다. 파일 경로도 '/'로 시작한다. 10월 2일, '/'로 시작하는 일반 메시지가 명령어로 오인돼 블로그가 아닌 CEO 에이전트로 갔다. CEO 쪽은 gpt-5.4-mini 미지원 오류로 답하지 못했다. 수정: 명령은 "/이름[@봇] 뒤에 공백 또는 끝" 플러그인에서 다른 명령으로 보는 조건을 " /이름[@봇] 뒤에 공백이 오거나 메시지가 끝날 때"로 좁혔다. 판별 정규식은 다음과 같다. /^\/[A-Za-z0-9_]+(?:@[A-Za-z0-9_]+)?(?:\s|$)/ / 다음에 영문·숫자·밑줄로 된 이름이 오고, 선택적으로 @봇이름 이 붙은 뒤, 바로 공백이나 끝이 와야 명령이다. 단, 이 검사는 /blog 와 /blog@봇이름 을 먼저 따로 판별한 뒤에만 적용한다. 그래서 /blog hel...

2026년 9월 14일 12:55에 시작한 omo 프로세스는 9월 16일에 확인했을 때도 시작할 때 읽은 텔레그램 브리지 확장을 그대로 쓰고 있었다. 그사이 확장 파일을 두 번 고쳤지만 둘 다 실행 중인 프로세스에는 반영되지 않았다. 디스크의 파일과 실행 중인 모듈이 서로 다른 세대일 때 그 차이를 어떻게 대조했는지 기록한다. 대상은 로컬 에이전트나 봇의 Node ESM 확장을 고쳤는데 동작이 그대로인 개발자다. 목표는 수정이 실제로 올라왔는지 판정하고, 무엇을 바꿨을 때 무엇을 다시 띄워야 하는지 구분하는 것이다. 아래는 9월 당시 내 omo 하네스와 OpenClaw 텔레그램 브리지의 기록이다. Node.js ESM 캐시 동작 전반을 따로 실험해 확인한 글은 아니다. 증상: 모델만 바꾸라는 요청이 빈 요청이 됐다 이 브리지에서는 텔레그램으로 /blog --model <선택자> 작업내용 을 보내면 그 요청만 지정 모델로 처리하고, --model-sticky 를 쓰면 모델을 유지한다. 9월 15일 15:55와 16:24에 작업 내용 없이 --model 아스트라 만 보냈다. 두 번 모두 실제 소비 세션은 새 확장을 reload하지 않은 상태였고, 기존 구현이 빈 프롬프트를 세션에 넣은 뒤 최종 답변을 확인하지 못했다는 안내를 보냈다. 이것을 UX 결함으로 보고, 모델만 담긴 요청은 모델을 유지 전환하고 모델 호출 없이 바로 성공 회신하도록 세션 확장을 고쳤다. 원인: 파일은 새것, 프로세스는 9월 14일 것 9월 16일에 다시 확인하니 모델 변경 명령이 안 먹는 진짜 원인은 프로세스 세대였다. omo 프로세스는 9월 14일 12:55에 시작해 그때의 확장을 계속 쓰고 있었다. 9월 15일 16:00의 모델 단독 요청 처리 수정과 9월 16일 08:21의 em/en 대시 허용 수정이 모두 반영되지 않았다. 로더 캐시 버전을 올려도 /reload 나 재시작 전에는 적용되지 않았다. 9월 13일 날짜가 붙은 기록 절에도 이런 주의가 적혀 있다. ...

블로그 속도를 숫자로 남기려고 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 글 편집 화면의 검색 설명 칸에 값을 넣었다. 그런데 공개된 글의 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에 무엇을 몇 번 출력하느냐였다. 검색엔진이나 공유 미리보기가 이 중 어느 값...