매일 기록한 AI 기록

2026년 10월 13일, 이 블로그의 Blogger 통계와 Google Search Console(GSC)을 읽기 전용으로 열어 봤다. Blogger의 지난 7일 조회는 1.51천, GSC의 최근 3개월 클릭은 4였다. 두 숫자를 한 줄에 놓으면 "천오백 명이 왔는데 검색으로 온 사람은 넷"처럼 읽힌다. 이 기록으로는 그렇게 읽을 수 없다. 대상은 블로그 발행을 자동화해 놓고 그 성과를 Blogger 조회수로 판단하려는 개발자다. 목표는 두 숫자를 기간과 측정 대상별로 나눠 적고, 국가·리퍼러 표만으로 사람의 검색 유입을 확정할 수 있는지 판정하는 것이다. 아래 값은 모두 이 블로그 한 곳의 2026년 10월 13일 화면 기록이다. 두 숫자는 기간도, 세는 대상도 다르다 지표 화면 기간 값 세는 것 조회 Blogger 통계 지난 7일(차트 2026-10-07~10-13) 1.51천(표시값) 페이지뷰 클릭 GSC 실적, 검색 유형 웹 최근 3개월(2026-07-11~10-10) 4 Google 웹 검색 결과 클릭 Blogger 쪽은 7일이고 GSC 쪽은 약 3개월이다. 날짜만 비교하면 두 기간이 겹치는 날은 10월 7일부터 10일까지다. 게다가 Blogger 통계 화면에는 블로그 시간대 GMT-07:00이 표시됐지만, GSC 화면의 날짜 기준 시간대는 기록하지 않았다. 그래서 "4 ÷ 1,511" 같은 비율은 계산하지 않는다. 분모와 분자가 같은 기간, 같은 대상을 세지 않기 때문이다. GSC 쪽도 기간을 바꾸면 값이 달라진다. 같은 날 읽은 최근 28일(2026-09-13~10-10)은 클릭 1, 노출 74였다. 최근 3개월은 클릭 4, 노출 798, 평균 CTR 0.5%, 평균 게재순위 2.3이었다. 1.51천도 정밀값이 아니다. 주간 조회 카드에는 "1.51천"으로만 표시됐고, 같은 주간 상세 화면의 검색 키워드 표, 국가 표, 추천 URL 표의 합계가 각각 1,511이었다. 카드의 정밀값을...

2026년 10월 13일, 이 블로그의 공개 페이지를 점검하다가 모든 표본 페이지가 3,427,910바이트(약 3.43MB)짜리 프로필 이미지를 참조하고 있는 것을 확인했다. 같은 날 최대 400x400 WebP로 바꿔 올렸다. 교체 완료는 업로드한 파일 크기가 아니라 공개 페이지의 이미지 참조와 응답 상태로 판정했다. 대상은 Blogger를 운영하면서 프로필이나 사이드바처럼 모든 페이지에 붙는 이미지 용량을 줄이려는 개발자다. 목표는 원본과 교체 파일의 크기를 기록하고, 교체 완료는 공개 페이지가 실제로 새 이미지를 참조하는지로 확인하는 것이다. 아래 숫자는 내 블로그 한 번의 교체 기록이다. 이 교체로 페이지 속도가 얼마나 좋아졌는지는 재지 않았다. 1. 모든 페이지에 붙는 큰 이미지를 찾는다 교체 전 감사는 로그인이나 설정 변경 없이 공개 페이지를 GET으로 받아서만 했다. 표본 페이지는 모두 프로필 가젯의 같은 PNG( <img alt='내 사진'> )를 참조했고, 그 응답 본문이 3,427,910바이트였다. 압축을 푼 텍스트 크기가 아니라 PNG 응답 본문의 바이트 수다. 비교 대상도 함께 쟀다. 최신 5편의 본문 cover·diagram 이미지는 56,723~83,411바이트, 인기글 썸네일은 108,006바이트와 165,802바이트였다. 감사는 본문 대표 이미지 대다수가 56~138KB인 데 비해 공통 프로필이 더 큰 정적 부담이라고 정리했다. 다만 감사도 한계를 적어 두었다. 브라우저가 이 이미지를 실제로 언제 요청하는지, lazy loading·cache·srcset으로 어떤 변형을 고르는지는 HTTP 실측으로 확정하지 않았다. 페이지별 무게 합계도 HTML이 직접 참조한 자원만 더한 근사이며, 브라우저 전체 전송량이나 CWV가 아니다. 2. 작게 만들어 같은 자리에 올린다 감사가 제시한 수정 위치는 Blogger → 레이아웃 → 프로필 가젯이었다. 표시 크기에 맞춘 작은 이미지로 바꾸고, 목표는 수십 KB...

2026년 9월 30일 수정 전, 텔레그램으로 보낸 블로그 작업 요청 다섯 건이 모두 최종 답변 없이 끝났다. 요청은 다섯 건 모두 세션에 도착해 있었다. 수정 보고서가 짚은 브리지 쪽 문제는, 세션의 agent_settled 이벤트가 오면 최종 답변이 없어도 요청을 끝내고 폴백을 보내는 흐름이었다. 대상은 메신저 요청을 에이전트 세션에 넣고 답을 다시 메신저로 돌려보내는 브리지를 직접 만든 개발자다. 목표는 턴이 끝났다는 신호와 최종 답변이 생겼다는 사실을 따로 판정하는 것이다. 아래는 9월 30일 내 브리지 한 건의 수정 기록이다. 모든 에이전트 런타임의 이벤트가 이렇게 동작한다는 뜻은 아니다. 기록된 증상: 다섯 요청이 모두 도착했는데 답이 없었다 수정 보고서에 남은 원인은 이렇다. 기존 흐름은 요청의 user 메시지가 시작된 뒤 agent_settled 가 오면, 최종 assistant 텍스트가 없어도 바로 요청을 끝내고 폴백을 전송했다. 실제 요청 파일과 상태 파일이 만들어진 간격도 4~7초뿐이었다. 보고서가 대조한 세션 기록에서 다섯 요청은 모두 세션에 들어가 있었다. 한 건은 Claude 인증 차단, 나머지 네 건은 로드된 런타임의 OpenAI chunk 누락 오류가 난 뒤 assistant 최종 메시지가 없었다. 마지막 요청도 세션에서 유실된 것이 아니었다. 요청 표시가 세션 기록에 있었고, 바로 다음 줄에 provider 모듈 오류가 있었다. 정리하면 이 사고에서 두 가지가 겹쳤다. 하나는 provider 쪽 오류로 답변이 만들어지지 않은 것이다. 다른 하나는 브리지가 그 상황을 곧바로 "끝"으로 처리한 것이다. 두 오류가 왜 났는지는 이 보고서에 없다. 이 글은 두 번째, 브리지의 판정만 다룬다. 보고서는 이번 증상과 별개로 위험이 하나 더 있었다고 적었다. 기존 주입은 세션이 바쁜 상태로 바뀌는 경쟁 상황에 필요한 deliverAs 를 지정하지 않았다. 확장 API의 실제 비동기 실패는 fire-and-forg...

나는 텔레그램 /blog 명령으로 에이전트 하네스 omo의 장기 작업 세션에 블로그 작업을 넘긴다. 2026년 9월 15일, 긴 컨텍스트에서 GPT가 작업을 처리하지 못한다는 문제를 풀려고 대화 기록 없이 새로 실행하는 /blog --fresh 를 만들었다. 실전 검증에서 세 방식이 모두 timeout으로 실패했고, 나는 이 기능을 통째로 되돌렸다. 대상은 긴 세션 문제를 "새 세션으로 자동 인계"로 풀려는 개발자다. 이 글은 성공 방법이 아니라 실패 기록이다. 모델을 바꾸는 것과 세션을 분리하는 것이 어떻게 다른지, 무엇을 시도했고 어디서 멈췄는지를 정리한다. 모델만 바꾸는 것은 답이 아니었다 먼저 떠오르는 방법은 모델 전환이다. 내 브리지에는 이미 모델 선택자가 있었다. /blog --model <선택자> … 는 그 요청만 지정 모델로 처리하고 원래 모델로 돌아오며, --model-sticky 는 바꾼 모델을 유지한다. 하지만 기록에 남긴 판단은 이렇다. 모델만 바꾸는 방식은 기존 85MB 세션을 그대로 넘기므로 해결책이 아니다. --model 은 기존 장기 세션의 컨텍스트를 그대로 쓴다. 모델 전환은 "어떤 모델이 읽느냐"를 바꾸고, 세션 분리는 "무엇을 읽느냐"를 바꾼다. 컨텍스트 문제에는 후자가 필요했다. 만들었던 구조 /blog --fresh 모델별칭 작업내용 을 OpenClaw 플러그인에 추가했다. 이 경로는 요청 폴더와 장기 세션 확장을 거치지 않고 worker 스크립트를 detached process로 띄운다. worker는 omo를 세션·확장·프롬프트 템플릿 없이 별도로 실행하고, 결과만 원래 텔레그램 메시지에 답장으로 보낸다. 기록된 실행 형태는 다음과 같다. omo --no-session --no-extensions --no-prompt-templates --print 기존 세션, 파일, 예약은 지우지 않았다. fresh 실행 자체의 대화 기록만 저장하지 않았...

지난 글에서 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와 락 파일은 "소비 프로세스가 떠 있고 자기가 담당이라고 표시했다"는 것까지만 알려 준다. 메시지가...