매일 기록한 AI 기록

출시 개요 Google이 2026년 10월 13일 플래그십 AI 모델인 Gemini 4 Argon(모델 코드 gemini-4-argon )을 정식 출시(GA)했다. 개발자가 API나 개발 환경에 적용하기 전에 확인해야 할 핵심은 세 가지다. 무료 등급(Free tier) 없이 유료 등급(Paid Tier)에서만 제공된다는 점, 2026년 11월 30일까지만 소개 가격이 적용되고 12월 1일부터는 가격이 2배로 오른다는 점, 그리고 명시적 컨텍스트 캐싱이 지원되지 않아 이를 쓰던 코드는 고쳐야 한다는 점이다. 제공 대상과 사용 환경 구분 공식 안내 문서(What's new 및 가격 안내 문서, 확인일 2026-10-15)에 따르면 Gemini 4 Argon의 제공 범위는 서비스 형태에 따라 차이가 있다. 일반 사용자는 Gemini 앱과 검색 AI 모드에서 Google AI Ultra 또는 Google AI Pro 구독을 통해 이용할 수 있다. 하지만 개발자용 API 환경에서는 정책이 다르다. Gemini API와 Google AI Studio에서는 무료 등급과 Google AI Pro 플랜으로 Gemini 4 Argon을 사용할 수 없다. 개발자가 API나 Google AI Studio에서 이 모델을 쓰려면 Gemini API 유료 등급(Paid Tier)을 이용해야 하며, Google AI Ultra 구독자는 Google AI Studio와 Google Antigravity에서 사용할 수 있다. 기업 사용자는 Gemini for business, API, Google Antigravity를 통해 접근 가능하다. 한편 과학자와 연구자는 Google Antigravity 최고 사용 등급을 6개월 무료로 쓰는 프로그램에 신청할 수 있고(1만 명, 자격·용량·선정 조건, 순차 온보딩), 보안 방어자는 Fairwind Program 신청 시 사이버 가드레일이 없는 Argon 접근을 순차적으로 제공받는다. API 가격과 캐싱 정책 Gemini API 유...

브라우저 자동화는 몇 초가 지났는지가 아니라 필요한 상태가 생겼는지를 기다려야 한다. 감시를 행동보다 먼저 등록하고, 완료 조건을 만족하면 진행하되 제한 시간을 넘으면 현재 화면을 확인한다. 이 방식은 글 작성·예약 발행을 자동화하는 개발자가 입력 반영과 저장 결과를 구분하는 데 쓸 수 있다. 2026년 10월 13일 실행 로그에는 NavigationReadinessTimeoutError 가 30초 대기에서, 이어 90초로 늘린 대기에서도 남아 있다. 그 뒤 현재 화면 스냅숏을 읽고 진행해 8편을 예약했고, 각 글을 다시 열어 확인했다. 같은 실행 안에서도 30초 준비 대기 타임아웃은 여덟 번 더 났지만, 매번 화면을 읽고 다음 단계로 갔다. 30초를 90초로 바꾸면 해결될까? 준비 완료를 기다리다가 타임아웃이 나면 제한 시간부터 늘리고 싶어진다. 그런데 대기 시간이 부족한지, 기다리는 신호가 작업의 완료 조건과 다른지 먼저 나눠야 한다. 같은 종류의 대기가 90초에서도 끝나지 않았다는 보고만으로 브라우저 내부 원인을 단정할 수는 없다. 오류 이름이 말해 주는 것은 준비 상태 대기가 제한 시간 안에 끝나지 않았다는 사실이다. 입력이 실패했다거나 저장이 취소됐다는 뜻까지 담고 있지는 않다. 타임아웃 뒤 화면을 읽지 않고 클릭을 반복하면 현재 상태와 다른 행동을 할 수 있다. 붙여넣기에서도 비슷한 구분이 필요했다. 9월 27일 SmartEditor 조사에서는 합성 paste 이벤트가 처리됐지만 직후 본문은 한 문단으로 보였다. 나중에는 시험용 두 문단이 들어왔다. 이벤트 반환과 본문 반영을 같은 순간으로 취급한 검사가 잘못된 실패 판정을 만든 것이다. 최소 재현은 단순하다. 시험용 편집기에서 붙여넣기 직후 본문을 한 번 읽고, 변경 감시가 확인한 본문과 비교한다. 앞의 읽기만으로 실패를 판정하는 순서와, 감시를 먼저 붙이는 순서를 대조하면 된다. 실제 글을 발행할 필요는 없다. 먼저 구독하고 나서 행동한다 완료 조건은 행동 전에 정한다. 붙여넣기...

로컬 환경에서 일주일 동안 발생한 Claude Code 사용 기록을 모아 공식 API 단가 기준으로 환산해 보았다. 측정 구간은 2026년 10월 7일 07시 30분부터 2026년 10월 14일 07시 30분(KST)까지 7일간이다. 주력 모델인 Opus 5.5 호출 기록만 집계해 계산한 결과, 일주일 환산 비용은 1,899.49달러 로 나타났다. 이 수치는 실제 결제된 카드 청구액이 아니다. 로컬 로그에 남은 토큰 사용량에 공식 API 요율표를 대입한 비교용 금액일 뿐이다. 동일한 사용량을 30일 기준으로 선형 환산하면 8,140.68달러 에 이른다. 월 구독료와 단순 수치를 나란히 두면 격차가 매우 커 보이지만, 이를 곧바로 비용 절감액으로 여겨서는 안 된다. 이 글은 특정 상품을 권하는 가이드가 아니라 개인의 사용량에 관한 측정 기록이다. 실제 결제 영수증이나 세부 작업 내역은 다루지 않으며, 로컬 기록 전체가 단일 구독이나 단일 계정에서 비롯되었다는 전제도 두지 않는다. 7일간 집계된 토큰 내역 측정 기준 시간대는 한국 표준시(KST)다. 시작 시각은 포함하고 종료 시각은 제외하는 방식으로 구간을 확정했다. 로컬 프로젝트 로그에서 사용량 데이터가 존재하는 행을 확인하고, 동일한 메시지 ID와 요청 식별자 조합을 전역에서 1회만 처리하여 중복 행 11,154개를 제외했다. 중복을 제외한 주력 모델 Opus 5.5의 7일간 토큰 현황은 다음과 같다. 항목 7일 토큰 수 일반 입력 28,332 출력 6,420,964 캐시 쓰기 123,576,469 캐시 읽기 3,911,733,861 합계 4,041,759,626 중복을 뺀 Opus 5.5의 호출 수는 10,149회였다. 다른 Claude 모델도 일부 구동되었으나, 일반 입력, 출력, 캐시 쓰기, 캐시 읽기라는 네 토큰 항목의 합계에서 다른 모델이 차지하는 비중은 약 0.33%에 그쳤다. 따라서 단가가 상이한 모델들을 혼합하지 않고 Opus 5.5의 사용량만 따로 떼어 계산을 진행했다. 총량이 ...

답부터 말하면 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...

답부터 말하면 붙여넣기 이벤트가 받아들여졌는지가 아니라, 편집기 본문이 넣으려던 전체 글과 같아졌는지를 완료 조건으로 삼아야 한다. 이벤트를 보내기 전에 변경 감시를 시작하고, 제한 시간 안에 정규화한 누적 본문이 정확히 일치할 때만 다음 단계로 넘어가는 방식이다. 2026년 9월 27일 한 번의 SmartEditor 자동화 기록에서 첫 구간은 48ms, 두 번째 구간은 239ms 뒤 반영됐다. 이후 다시 연 예약 글에서는 원고·주입 대상·편집기 본문이 각각 2800자로 일치했다. 그 예약은 이 실행이 아니라 동시에 돌던 다른 작업이 저장한 것이다. 48ms와 239ms는 속도 기준이나 성공률이 아니라 한 실행의 관찰값이다. 왜 paste 이벤트 성공만으로는 부족했나? 조사 중 합성 paste 이벤트는 defaultPrevented:true 를 반환했다. 그런데 직후 본문은 여전히 한 문단이었고, 조금 뒤에는 시험용 두 문단이 들어와 있었다. 문제는 이벤트 수락과 화면 반영이 같은 순간이 아니라는 점이다. dispatchEvent() 반환값, iframe 포커스, 즉시 읽은 문단 수는 모두 완료 조건이 아니었다. 선택 영역이 iframe 루트에 잡힌 관찰도 과거 60초 지연의 원인으로 확정할 수 없었다. 그렇다면 무엇을 기다려야 할까. 편집기가 실제로 만들어 낸 최종 상태를 기다려야 한다. 고정 sleep 대신 무엇을 기다렸나? 성공한 경로는 MutationObserver 를 붙여넣기 전에 등록했다. 그 다음 clipboard 이벤트를 보낸 뒤, 공백과 제로폭 문자를 정규화한 전체 본문을 매 변경마다 비교했다. 아래는 실제 코드를 줄인 형태다. const done = new Promise((resolve, reject) => { const timer = setTimeout(() => { observer.disconnect(); reject(new Error("paste timeout")); ...

📚 AI 직원 회사 빌드기 — 4부작 시리즈 ① Mac Studio 128GB로 AI 직원 회사 만든 이유 ② 외부 부작용 통제 — Discord 승인 + launchd ③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩 (현재 글) ④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI (다음 주 발행 예정) 36분짜리 자동화가 Phase 2에서 멈춘다 claude -p 로 블로그 파이프라인을 체이닝하면 특정 단계에서 subprocess가 멈추고 stdout이 비어 돌아온다. returncode는 0이다. 에러 메시지도 없다. 타임아웃까지 그냥 블로킹된다. 이게 Phase 2 트랩이다. blog-draft 스킬이 프레임·제목 후보를 제안하고 “진행 시 Phase 3 시작”이라는 텍스트를 출력한 뒤, 사용자 승인을 기다린다. subprocess.run() 안에서 승인을 기다리면 타임아웃까지 블로킹되고, 결국 md 파일이 생성되지 않은 채 다음 단계로 못 넘어간다. 이 글은 V3 5-step 파이프라인이 V3.5 6-step으로 바뀐 설계 기록이다. 트랩이 왜 발생하는지 구조적으로 분석하고, 실제 코드 변경 3가지로 어떻게 우회했는지 정리한다. 이 신호가 보이면 Phase 2 트랩이다 다음 세 가지가 동시에 나오면 코드 버그가 아니라 트랩이다: Step 2( blog-draft )가 항상 딱 720초 에서 TimeoutExpired로 죽는다. 랜덤하게 실패하는 게 아니라 매번 정확히 timeout에서 죽는다. stdout tail을 보면 “프레임 + 제목 제안” 텍스트가 마지막이고, 그 뒤로 아무것도 없다. work_dir 에 md 파일이 없어서 _latest_md_in() 이 None 을 반환한다. 세 가지가 맞아떨어지는 이유는 스킬 설계 vs 비대화형 실행 환경의 불일치에 있다. 스킬은 대화형 세션을 전제로 만들어져 있고, claude -p subprocess는 st...