매일 기록한 AI 기록

Claude 호출이 실패하면 요금제부터 올리고 싶어진다. 그 전에 실패가 정말 모델 사용량 문제인지, 내 컴퓨터의 하네스가 쥐고 있는 인증 슬롯이 모두 막힌 것인지 먼저 확인해야 한다. 2026년 9월 15일과 16일, Claude를 쓰는 에이전트 하네스 omo에서 겪은 실패는 로컬 인증 슬롯 단계에서 먼저 드러났다. 15일에는 두 슬롯이 모두 rate-limit로 차단돼 있었고, 16일에는 한 슬롯이 응답하는데도 여러 세션이 슬롯을 나눠 잡아 추가 요청이 막혔다. 이 글은 여러 세션에서 Claude를 돌리다 호출이 막힌 개발자를 위한 확인 순서다. 목표는 결제 여부를 판단하기 전에 오류 문자열, 로컬 슬롯 상태, 실패·성공 시각, 동시 호출 수를 차례로 보고 다음 행동을 고르는 것이다. 먼저 범위를 밝힌다. 아래 오류는 omo 런타임의 인증 슬롯 장애 조치에서 나온 것이다. Claude Code 공식 /usage 화면이나 공식 한도 안내와 같은 오류가 아니고, 9월 기록의 일회성 사례다. 지금 모든 계정에서 같은 일이 생긴다는 뜻도 아니다. 무슨 일이 있었나 2026년 9월 15일, 텔레그램으로 보낸 요청 세 건이 작업 세션에 정상적으로 들어갔다. 그런데 회신은 세 건 모두 요청 처리가 끝났지만 최종 답변을 확인하지 못했습니다 였다. 처음에는 텔레그램 연결 문제처럼 보였다. 같은 시각의 인증 상태를 보니 원인은 다른 곳에 있었다. omo의 credential pool에서 Claude용 claude-sdk-oauth 슬롯 두 개가 모두 rate-limit 상태였다. default 슬롯은 15:42:46 KST까지 차단돼 있었고 failureCount는 5였다. account-2 슬롯은 15:31:28까지 차단, failureCount 3이었다. 런타임(Senpi)의 장애 조치 함수 runCredentialFailover 는 사용할 수 있는 후보 슬롯이 0개면 No credential slots available 을 던진다. 결국 그 폴백 문구...

출시 개요 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 유...

로컬 환경에서 일주일 동안 발생한 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의 사용량만 따로 떼어 계산을 진행했다. 총량이 ...

답부터 말하면 붙여넣기 이벤트가 받아들여졌는지가 아니라, 편집기 본문이 넣으려던 전체 글과 같아졌는지를 완료 조건으로 삼아야 한다. 이벤트를 보내기 전에 변경 감시를 시작하고, 제한 시간 안에 정규화한 누적 본문이 정확히 일치할 때만 다음 단계로 넘어가는 방식이다. 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")); ...

2026-10-13 dev 브랜치 기준(커밋 origin/dev b78527c )으로 omo 의 프롬프트 구성을 검토했습니다. 저장소에 실제로 분리된 프롬프트 파일이 존재하는지와 그 분리가 실제 런타임에서 어떤 성능 차이를 내는지는 구분하여 살펴보아야 합니다. 분리의 존재와 효과의 차이 omo 의 코드베이스에는 모델별 전용 프롬프트 파일이 실제로 나뉘어 있습니다. 공통 뼈대를 유지하면서도 모델별 보정 지시가 별도의 Markdown 파일로 관리됩니다. 다만 파일이 분리되어 있다는 사실 자체가 프롬프트 분리의 실질적인 효과를 입증하지는 않습니다. 파일 안에 적힌 내용은 모델에 내리는 지시문일 뿐이며, 그 지시가 모델의 행동 변화나 성능 향상으로 이어졌는지는 런타임 결과로 측정해야 합니다. 이번 검증 범위에서는 모델 변형별 A/B 테스트 결과나 런타임 성능 측정치를 확인하지 못했습니다. Atlas 파일 여덟 개의 비교 Atlas 영역에는 총 8개의 Markdown 프롬프트 파일이 존재합니다. atlas-prompts.ts 파일은 각 모델 변형을 이 파일들에 연결하는 라우팅 역할을 담당합니다. 라우팅 대상 중 swe-2 항목은 kimi-k3.md 파일을 재사용하므로, 라우팅 항목의 개수와 실제 물리적 파일 수는 다릅니다. 8개 파일의 줄 수는 다음과 같습니다. 파일명 줄 수 gemini.md 526줄 default.md 496줄 opus-4-7.md 494줄 kimi.md 478줄 gpt.md 461줄 glm.md 402줄 kimi-k2-7.md 326줄 kimi-k3.md 326줄 파일의 줄 수나 파일 개수의 차이만으로 프롬프트의 품질이나 실행 효과의 우열을 판단할 수는 없습니다. 저장소의 커밋 활동 이력 또한 이번 검증 대상에 포함되지 않았습니다. 모델별로 적힌 보정 방향 각 파일에 담긴 프롬프트 지시는 모델별로 보정 의도를 보입니다. gemini.md 파...

2026-10-13 dev 브랜치 기준(커밋 origin/dev b78527c )으로 코드베이스를 확인했습니다. omo 프롬프트 체계에서 Claude 전용 파일이 어떻게 배치되어 있는지, 실제 코드 구성과 라우팅 로직을 바탕으로 살펴봅니다. 제목의 범위는 Atlas 제목에서 언급된 'Opus 4.7에만'이라는 범위는 omo 전체 Claude 프롬프트가 아니라 Atlas 에이전트의 파일에 한정된 내용입니다. Atlas의 마크다운 프롬프트 파일은 총 8개입니다. default.md , gpt.md , gemini.md , glm.md , kimi.md , kimi-k2-7.md , kimi-k3.md , opus-4-7.md 로 구성되어 있습니다. 이 중 Claude 전용 파일은 opus-4-7.md 하나입니다. 여기서 파일 수와 라우팅 키 수는 구분해야 합니다. atlas-prompts.ts 의 swe-2 항목은 새로운 파일 대신 kimi-k3.md 를 재사용하기 때문입니다. Atlas의 파일과 Opus 매처 Atlas 에이전트의 getAtlasPromptSource() 는 resolveVariant() 에 atlasPromptVariants 를 전달하여 모델에 적합한 프롬프트를 결정합니다. 이 과정에서 variant-resolver.ts 는 opus-4-7 변형을 isClaudeOpus47Model 에 연결합니다. 해당 판별을 담당하는 detector는 model-family-detectors.ts 에 위치합니다. 지정된 모델이 Opus 4.7 모델 계열에 해당하면 전용 변형인 opus-4-7.md 가 연결되며, 그 외 매칭 변형이 없는 모델은 default.md 를 사용합니다. Opus 파일의 두 보정 지시 분량 면에서 Atlas opus-4-7.md 는 494줄, default.md 는 496줄로 큰 차이가 나지 않습니다. opus-4-7.md 에는 <opus_47_counter_defaults> ...

2026-10-13 dev 브랜치 기준(commit b78527c ) 코드베이스를 바탕으로 omo의 GPT 프롬프트 구성 방식을 살펴봅니다. 모델을 강하게 압박하는 경고문 대신 명확한 제약과 작업 범위를 사전에 정의하는 서술 구조가 사용됩니다. 본문에서 언급하는 계약은 법적 성격의 계약이 아니며, 프롬프트 파일에 명시된 동작 조건과 처리 규칙을 설명하는 표현입니다. 경고 대신 범위와 조건을 명시하는 방식 Ultrawork GPT의 gpt.md 에는 <output_verbosity_spec> , <scope_constraints> , <uncertainty_handling> 블록이 선언되어 있습니다. 각 블록은 기본 출력 길이, 작업 범위 제한, 불확실성이 발생했을 때의 처리 기준을 명시합니다. 이 방식은 모호한 주의를 주는 대신 프롬프트 자체에 동작 경계를 직접 부여합니다. 다만 파일에 적힌 프롬프트 지시와 시스템이 실제로 작동할 때 나타나는 관측된 효과는 명확히 구분해야 합니다. 프롬프트에 조건이 작성되어 있다는 사실이 실제 모델 동작의 품질을 직접 대변하지는 않습니다. Atlas의 불변식과 정지 조건 Atlas GPT의 gpt.md 에 위치한 <gpt_family_calibration> 블록은 4가지 불변식을 규정합니다. 독립 작업 병렬화 위임 뒤 검증 검증 뒤 체크박스 갱신 실패한 동일 세션 재개 작업의 정지 조건으로는 최상위 체크박스가 모두 - [x] 로 채워지고, Final Wave reviewer 전원이 APPROVE 판정을 완료하는 상황을 요구합니다. 이는 해당 Atlas 프롬프트 내부에 명시된 완료 기준이며, omo 전체 실행을 아우르는 전역 정지 조건이 아닙니다. 현재 줄 수와 백그라운드 위임 각 모델 변형 프롬프트 파일의 줄 수를 확인하면 다음과 같습니다. Ultrawork gpt.md : 192줄 Ultrawork default.md :...

2026-10-13 dev 브랜치 기준( origin/dev b78527c ) 코드베이스를 살펴보면, Atlas 와 Ultrawork 에 각각 gemini.md 전용 프롬프트 파일이 존재합니다. Atlas Gemini 와 Ultrawork Gemini 는 Gemini 모델을 다루기 위한 행동 지침을 담고 있습니다. 프롬프트가 명명한 두 실패 모드 두 프롬프트는 Gemini 모델이 나타낼 수 있는 특정한 행동 양식을 실패 모드로 명명하고 이를 통제하도록 지시합니다. 하나는 도구를 호출하지 않고 상태를 안다고 넘겨짚는 태도이며, 다른 하나는 작업 의도를 나누지 않고 곧바로 구현에 뛰어드는 성향입니다. 이 두 지시는 적용되는 단계가 명확히 다릅니다. Ultrawork Gemini 의 의도 분류는 작업 착수 전에 진행되며, Atlas Gemini 의 도구 호출 요구는 조사와 검증이라는 실제 행동 단계에서 적용됩니다. 다만 이러한 프롬프트 지시문이 존재한다는 점을 Gemini 모델 일반의 실증된 결함으로 확대하여 해석해서는 안 됩니다. 도구 호출을 요구하는 Atlas Atlas Gemini 에는 <TOOL_CALL_MANDATE> 블록이 정의되어 있으며, 그 내부에 YOUR FAILURE MODE 라는 제목의 지시문이 포함되어 있습니다. 이 블록은 실제 도구 호출 없이 파일 내용, 작업 상태, 검증 결과를 안다고 가정하는 상태 자체를 실패 모드로 규정합니다. 해당 지침에 따르면 도구 호출이 없는 응답은 실패로 취급됩니다. 또한 병렬 작업 수에 맞추어 task() 를 호출하도록 정한 규칙도 포함되어 있습니다. 이는 추측에 기반한 답변을 배제하고 도구 실행을 통해 상태를 확인하도록 요구하는 프롬프트 지시입니다. 착수 전에 의도를 나누는 Ultrawork Ultrawork Gemini 는 착수 단계에서 <GEMINI_INTENT_GATE> 블록을 제시합니다. 모델이 도구 호출이나 파일 탐색을 시작하기 전에 사용자의 요청을 여섯...

건물 하나를 떠올려 보자. 택배 기사는 그냥 들여보내는데 방문객처럼 굴면 신분증을 내고 방문 목적을 적어야 한다. 그 건물에서는 제복을 벗는 쪽이 빨리 들어간다. 내 수집기는 18일 동안 정문 앞에 서 있었다. 브라우저인 척하는 User-Agent를 달고 있었기 때문이다. 그 한 줄을 지우자 차단이 풀렸다. 결론부터 적는다. 대응책은 자기가 언제부터 쓸모없어졌는지 말해 주지 않는다. 차단을 피하려고 넣어둔 UA 위장이 그랬고, 실패를 놓치지 않으려고 넣어둔 장치도 그랬다. 신호는 28번 다 울렸고 그걸 18일 동안 읽지 않은 사람은 나다. 누가 읽으면 좋은가 외부 사이트를 긁는 코드를 굴려본 사람. 차단을 피하려고 헤더를 손봐본 적이 있는 사람. 그리고 “실패하면 에러가 나니까 알게 되겠지”라고 생각해 본 사람. 수집기가 조용히 0을 반환하는 걸 본 적이 있다면 절반은 아는 이야기다. 나머지 절반은 조용하지 않았는데도 못 봤다는 쪽이다. 위장을 지우니 403이 200이 됐다 먼저 증상부터 살펴보자. 트렌드 수집기의 소스 두 곳이 죽어 있었다. Threads와 Product Hunt다. 둘 다 r.jina.ai 라는 같은 경로를 지나간다. 마지막으로 정상 수집된 실행은 7월 29일이다. Threads 135건, Product Hunt 16건이 들어왔다. 다음 날부터 둘 다 0이 됐다. 8월 16일까지 28회 연속이다. 원인을 좁히려고 같은 URL에 헤더만 바꿔 던져 봤다. 같은 시각, 같은 주소다. 보낸 User-Agent 응답 Mozilla/5.0 ... Chrome/131.0.0.0 Safari/537.36 403 curl 기본 UA 200 빈 UA 200 trend-scout/0.2 200 403 응답 본문의 첫 줄은 이랬다. <title>Just a moment...</title> — Cloudflare가 자바스크립트 챌린지를 걸 때 내보내는 화면이다. 즉 브...