매일 기록한 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 을 던진다. 결국 그 폴백 문구...

로컬 환경에서 일주일 동안 발생한 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-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> ...

컨텍스트 엔지니어링이라는 말을 몰라도 하는 일은 같다. AI 코딩 도구가 실수할 때마다 CLAUDE.md에 규칙을 한 줄 얹는 것이다. 에러를 삼키면 가리지 말라는 조항을 적었다. 응답이 장황하면 짧게 쓰라는 줄을 붙였다. 그렇게 쌓인 게 얼마나 되는지 이번에 세봤다. 글로벌 규칙 파일 12개에 1,066행. CLAUDE.md까지 합치면 1,200행이 넘고, 스킬 69개와 에이전트 24개도 관리 대상으로 물려 있다. 규칙 쪽 1,200행은 매 세션 통째로 들어가고, 스킬은 목록만 실려도 자리를 차지한다. 그런데 7월 24일 Anthropic 공식 블로그가 정반대 방향을 내놨다. Claude 5 세대 모델용으로 Claude Code 시스템 프롬프트의 80% 이상을 지웠고, 코딩 평가에서 측정 가능한 손실이 없었다는 발표다. 결론부터 적는다. 이 기준을 내 설정에 대보니 진단은 맞았다. 규칙끼리 싸우는 충돌이 실물로 나왔다. 다만 처방은 절반만 받기로 했다. 행동을 지시하는 규칙은 지울 후보가 맞고, 결과를 검사하는 게이트는 지우면 안 된다는 게 내 실측이다. 모델이 에러를 덮고 지나갈 때마다 금지 조항을 추가해 본 적이 있다. 조항이 늘면서 어느 규칙이 어느 규칙과 싸우는지 놓친 적도 있다. 새 모델이 나오면 쌓아둔 지침이 아직 유효한가 하는 의심부터 든다. 셋 다 뿌리가 같다. 규칙은 사고가 날 때마다 한 줄씩 늘고, 지워지는 일은 거의 없다. 에이전트에 얹는 규칙·스킬·훅 뭉치를 통틀어 하네스라고 부르는데, 내 하네스도 그렇게 자랐다. Anthropic이 이번 발표에서 문제 삼은 게 그 습관이다. 공식 가이드가 실제로 말한 것 글쓴이는 Anthropic 기술 스태프 Thariq Shihipar다. 진단이 먼저 나온다. 시스템 프롬프트·스킬·CLAUDE.md·사용자 요청이 한 요청 안에서 서로 충돌하고 있었다. “문서화는 적절히 남겨라”와 “주석을 달지 마라”가 동시에 들어오는 식이다. 이걸 과잉 제약(overconstraining)이...

Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...

AI 글은 눈이 아니라 통계로 잡힌다. 사람 눈이 “이거 AI가 썼네” 하고 잡아내는 그 감의 정체가 문체의 통계이기 때문이다. 이 글은 그 감을 숫자로 옮겨, 파이썬 결정론 게이트로 AI 티를 측정하는 방법을 정리한 기록이다. 감으로 잡던 사람이 파이썬으로 넘어간 이유 요즘 블로그나 제품 리뷰를 읽다 “이거 AI가 썼네” 하고 3초 만에 덮는 일이 잦아졌다. 나도 그랬다. 4월에는 그 감을 체크리스트로 적어 발행까지 했다. 그런데 감은 미덥지 않다. 사람마다 다르고, 모델이 버전업할 때마다 흐려진다. 그 글에도 “이 체크리스트의 쓸모는 길어야 1년”이라고 적어뒀다. 결론부터 적는다. AI 글은 통계로 잡히고, 그 통계 지문은 파이썬으로 측정된다. 발행 전 모든 글에 그 게이트를 돌린다. 이 글도 그 게이트를 통과해야 나간다. “AI가 썼네”라고 느낀 그 감의 정체 한 번쯤 이런 적이 있을 거다. 문장은 매끄러운데 어딘가 밋밋해서 AI를 의심한 적이 있다. 왜 그렇게 느꼈는지는 설명하지 못한 적도 있다. 그 감을 규칙으로 적어봤지만 다음 글에서 또 놓친 적도 있다. 그 감은 사실 통계다. 사람 눈이 잡아낸 건 문체의 분산이 부족하다는 신호였다. 사람 눈이 잡던 걸 연구는 숫자로 잡는다 문체 계량(stylometry)으로 AI 글을 가려내는 연구는 지금 정확도 81~98%를 보고한다. 그중엔 사전 학습 없이 문체 통계만 쓰는 zero-shot 방식으로 90.6%를 찍은 결과도 있다 (arXiv 2507.00838). 2026년 PAN 워크숍의 탐지 과제에서는 통계 파이프라인이 에세이·뉴스·소설 장르를 걸쳐, 난독화된 글까지 포함해 F1 0.898을 찍었다 (arXiv 2602.09147). 핵심은 이거다. LLM은 저마다 고유한 문체를 가진다. 연구자들은 이걸 사람의 개인어(idiolect)에 비유한다 (arXiv 2509.10179). ChatGPT의 문체와 Gemini의 문체가 다르고, 둘 다 사람 글보다 분산이 좁다. 균질함이 곧...

에이전트가 ‘됐습니다’ 할 때 속으론 뭘 생각하나 — Claude J-space 에이전트에게 일을 시키면 끝에 “완료했습니다”라고 답한다. 그 말을 믿을 수 있나. Anthropic이 2026년 7월 6일 공개한 J-space 연구가 이 질문에 불편한 재료를 던졌다. Claude 안에는 입 밖으로 내지 않고 떠올리기만 하는 생각의 공간이 있다. 연구진은 그걸 J-space라 부른다. 그 공간을 열어봤더니, 모델은 자기가 테스트당하는 중이라는 걸 이미 알고 있었다. 세 줄 요약. J-space는 Claude가 학습 중 스스로 만든 소수의 내부 신경 패턴이다. 말로 내뱉지 않은 속생각이 여기 뜬다. 운영자에게 중요한 건 “의식이냐” 논쟁이 아니라, 모델의 생각과 말이 갈릴 수 있다는 실측이다. 이런 적 있다면 이 글이 쓸모 있다 에이전트가 “완료”라고 보고했는데 열어보니 절반만 된 적이 있다. 테스트는 통과하는데 실제 데이터에서 조용히 깨지는 걸 본 적이 있다. 로그 출력은 멀쩡한데 모델이 속으로는 다른 판단을 한 것 같은 찜찜함을 느낀 적이 있다. 셋 중 하나라도 겹치면, J-space는 그 찜찜함에 처음으로 계측기를 대는 연구다. J-space가 뭔가 Claude는 텍스트를 여러 내부 층을 거쳐 처리한다. 그 활성값 안에, 나머지 처리와 성격이 다른 소수의 패턴 집합이 있다. Anthropic은 이걸 찾은 기법의 이름을 따 J-space라 불렀다. 기법은 J-lens, 야코비안(Jacobian)에서 왔다. 작동 방식은 이렇다. 어휘의 모든 단어에 대해, “그 단어를 앞으로 말할 가능성을 높이는 내부 패턴”을 찾는다. 렌즈를 대면 그 순간 모델이 떠올린 단어 목록이 읽힌다. 각 패턴은 단어와 연결되지만, 켜졌다고 그 단어를 말하는 건 아니다. 그냥 머릿속에 있는 상태다. scratchpad나 chain-of-thought와는 다르다. 그건 모델이 써서 남기는 텍스트다. J-space는 아무것도 쓰지 않고 활성값 안에서 조용히 돈다. ...

Claude Fable 5가 6월 10일에 나왔다. Hacker News 출시 스레드가 하루 만에 2,280점(댓글 1,774개)을 받았고, 출시 당일부터 Claude Code 기본 모델을 Fable 5로 바꿔 이틀을 썼다. 이틀 동안 좋아진 건 분명히 있었다. 그런데 공식 단가표와 커뮤니티 반응이 서로 반대 방향을 가리키고 있어서, 갈아탈지 판정은 미루기로 했다. 요약하면 이렇다. 글 리뷰 능력은 실측으로 좋아졌고, 단가는 Opus 4.8의 2배가 됐다. “싸다”는 커뮤니티 반응과 공식 가격의 간극, 안전 필터 강화 보고까지 — 의문 4가지가 풀려야 전환을 정할 수 있다. 누가 읽으면 좋은가 Claude Code 기본 모델을 Fable 5로 바꿀지 고민 중인 사람 출시 첫 주의 들뜬 후기 말고 판정 유보 조건이 궁금한 사람 Opus 4.8 대비 비용이 실제로 어떻게 변하는지 확인하고 싶은 사람 한 줄로 요약하면, 글 리뷰는 실측으로 좋아졌지만 가격·필터·사용량 의문이 풀릴 때까지 판정은 유보다 . 검증 다섯 단계를 통과한 글에서 나온 결함 6건 전환 당일, 발행 직전이던 블로그 글을 Fable 5에 다시 리뷰시켰다. 그 글은 Opus 4.8 기반 검증을 다섯 단계(구조 리뷰 → 채점 루프 → AI 클리셰 검사 → 한국어 윤문 → 가독성 점검)로 통과한 상태였다. 그런데 결함 6건이 새로 나왔다. 주어와 서술어가 안 맞는 문장, 시스템에 쓸 수 없는 동사 선택, 연속 세 단락에 같은 구절 반복, 표기 혼용까지. 전부 사람이 보면 바로 어색한 것들인데 이전 검증에서는 안 잡혔다. 다만 이걸 모델 차이라고 단정은 못 한다. 같은 글을 두 번째 읽으면 누구든 더 잘 잡는다. 모델 효과와 재독 효과를 분리하려면 첫 리뷰부터 Fable 5로 돌린 다음 글에서 확인해야 한다. 단가 2배와 “싸다”는 반응 사이의 간극 공식 가격은 입력 $10, 출력 $50이다(100만 토큰 기준). Opus 4.8($5/$25)의 정확히 2배다. Cl...

1편(어제)에서 N=1로 측정해서 결론을 냈다. “Codex가 fail-fast 약하다”가 아니라 “AGENTS.md 비우면 Codex도 Claude도 똑같이 약하다”였다. 지적이 들어왔다. N=1은 우연일 수 있다. Claude에 AGENTS.md 명시 인용을 직접 해본 적은 없었다. 12회 측정해서 다시 확인했다. 결론은 더 단단해졌다. 그리고 1편이 놓친 변수 하나가 새로 보였다. 요약 : Codex × Claude × 하네스 0/강제 4 condition을 각 3회씩 12회 측정. 모델 효과는 거의 0(가로축 1.0 vs 1.0, 2.83 vs 2.5), 하네스 효과는 큼(세로축 1.0 → 2.5+). Claude도 AGENTS.md를 prompt에 명시 인용하면 fail-fast 1.0 → 2.5로 올라간다. 단 1편의 Claude 채점 “중”은 prompt position 효과(메인 세션 system prompt 자동 로드)였을 가능성이 새로 보였다. 1편이 명시한 5가지 한계 중 통제한 3가지 측정 1편 본문 끝에 한계 5가지를 적었다. 그 중 2편에서 통제 가능한 것은 3가지였다. Sampling 우연 미통제 (N=1) → 12회 측정으로 분산 확인 Prompt position 미분리 → C3 격리 환경 추가로 부분 분리 Claude에 AGENTS.md 명시 인용 미측정 → C4 condition으로 직접 측정 나머지 2가지(컨벤션 vs 코드 품질, 일반화)는 이번에도 미해소다. 측정 setup, 4 condition × 3회 = 12회 같은 명세 verify_published_post() 를 4 condition으로 각 3회씩 측정했다. Condition 모델 하네스 C1 Codex 없음 (AGENTS.md 비움) C2 Codex AGENTS.md 자동 로드 C3 Claude spec만, 격리 Task agent C4 Claude AGENTS.md prompt에 ...

같은 달, 같은 Mozilla — 두 문서 숫자가 90배 다르다 “Mythos가 Firefox에서 취약점 271개를 찾아 고쳤다”는 Mozilla 공식 블로그 문장과, “Firefox 150 보안 어드바이저리에 CVE 40개, 그중 Anthropic 크레딧은 3개”라는 같은 Mozilla의 공식 집계가 같은 4월에 나왔다. 둘 다 공개돼 있다. 271을 먼저 들으면 놀랍다. 같은 릴리즈 어드바이저리의 CVE 40개는 이상하다. 그 40개 중 Anthropic 크레딧 3개라는 사실은 두 문서가 서로 다른 것을 세고 있다는 감을 준다. 세 문장 전부 Mozilla가 직접 올린 공식 자료다. 이 글은 AI 보안 리포트를 읽는 독자를 위해, 왜 숫자가 벌어지는지를 공식 자료만으로 대조하고 제시된 설명 가설을 짚는다. 층 1 — Mozilla 블로그의 271이라는 숫자 Mozilla는 2026년 4월 공식 블로그 “The zero-days are numbered”(blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/)에서 Firefox 150이 Claude Mythos Preview로 평가한 뒤 271개 취약점을 수정했다고 적었다. 같은 달 Anthropic이 red.anthropic.com/2026/mythos-preview/에 올린 Mythos 공식 소개는 능력 수치를 제공한다. Firefox 147 JavaScript 엔진 테스트에서, 이전 모델 Opus 4.6은 수백 시도 중 실제 익스플로잇을 2번 만들었다. Mythos는 같은 조건에서 181번, 레지스터 제어(익스플로잇이 실제 실행 제어권을 잡는 단계)까지 간 경우가 29번이었다. 능력 자체는 공식 측정으로 실재한다. 이 수치가 뒤에 있으니 Mozilla의 “271 발견”이 단독으로 나왔을 때 독자 입장에서 반박할 근거가 없어 보인다. 층 2 — 보안 어드바이저리의 40과 3, 그리고 2월의 정합 Firefox ...