매일 기록한 AI 기록

답부터 말하면 2026년 9월 13일 세 편의 운영 기록에서 deep 서브에이전트 제작은 편당 95만~117만 토큰, 11~15분으로 보고됐다. 같은 기록의 짧은 이미지 교차 검수는 편당 3.5만~5만 토큰, 약 1분이었다. 다만 이 숫자는 원시 사용량 내역이나 청구서가 아니다. 당시 작업을 마친 뒤 남긴 운영 보고값이다. 그래서 달러 비용으로 바꾸지 않고, 어떤 역할에 토큰이 몰렸는지만 본다. 글 한 편에 왜 100만 토큰 가까이 들었나? 이때 말한 ‘글 한 편’은 본문만 쓰는 호출이 아니었다. 1차 출처를 찾고, 계산과 표를 확인하고, 이미지와 렌더러를 만들고, 검증 자료까지 남기는 묶음 작업이었다. 여기서 deep은 조사와 검증까지 길게 맡기는 서브에이전트 작업 범주이고, 리드는 작업을 나눠 주고 결과를 검증하는 메인 에이전트다. 운영 보고에는 9월 13일 세 편이 각각 95만~117만 토큰을 썼다고 적혀 있다. 걸린 시간은 11~15분이었다. 9월 14일 정리한 결정 기록에는 deep 제작 비용이 편당 70만~184만 토큰으로 적혀 있다. 두 범위가 왜 다른지는 확인하지 못했다. 결정 기록에는 어떤 글 몇 편을 셌는지 적혀 있지 않다. 그래서 제목에는 같은 날 만든 세 편의 범위만 쓰고, 70만~184만은 작업마다 폭이 컸다는 보조 기록으로만 본다. 많이 쓴 만큼 무엇이 남았나? 같은 운영 기록은 9월 13일 deep 제작 세 편과, 9월 14일 리드가 서브에이전트 없이 직접 쓴 세 편의 산출물을 비교했다. deep 글은 본문 1,737~1,887자, 출처 링크 2~5개였다. 리드 작성 글은 767~908자, 출처 링크 1개였다. deep 쪽에는 evidence.md가 있었고, 예금·적금 글은 원본 HTML 9개도 보관했다. 리드 작성 쪽에는 근거 문서와 원문 아카이브가 없었다. 그래서 토큰 차이가 문장 길이만의 차이는 아니었다고 본다. 2026-09-13 deep 제작과 2026-09-14 리드 직접 작성의 당시 비교 항목 de...

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

답부터 말하면 토큰 사용량이 그대로인 API 작업은 단가 인하분(입력·출력 20%, 캐시 읽기 60%)만큼 저렴해지지만, 내 청구액이 반드시 20% 줄지는 않는다. Opus 5.5는 기본 effort가 medium이라 출력 토큰이 줄 수도 있지만, 끌 수 없는 adaptive thinking이 출력 토큰으로 과금되므로 thinking을 끄고 쓰던 작업은 출력이 늘 수도 있기 때문이다. 구독으로 Claude Code를 쓰는 사람은 더 조심해서 읽어야 한다. Pro·Max의 포함 사용량은 토큰 단가로 직접 청구되지 않으므로, 단가 인하율 대신 5시간 한도 도달 시점과 추가 사용 크레딧을 같은 기간에 기록해야 한다. 가격·사양 확인일은 2026년 9월 28일 KST다. 금액은 100만 토큰당 USD이며 세금·환율·카드 수수료와 별도 도구 비용은 포함하지 않는다. 가격표는 정확히 무엇이 20% 내렸나? Anthropic은 2026년 9월 22일 Claude Opus 5.5를 공개했다. 공식 발표 와 모델 문서 기준으로 컨텍스트는 100만 토큰, 최대 출력은 12만8000토큰이며 adaptive thinking은 항상 켜지고 기본 effort는 medium이다. Opus 5.5의 표준 API 단가는 입력 $4, 출력 $20, 5분 캐시 쓰기 $5, 1시간 캐시 쓰기 $8, 캐시 읽기 $0.20다. Opus 5의 $5·$25·$6.25·$10·$0.50과 비교하면 입력·출력·캐시 쓰기는 20%, 캐시 읽기는 60% 낮다. Anthropic은 기본 설정의 일반 작업에서는 작업당 토큰도 줄어 Opus 5보다 40% 저렴하다고 자체 시험 결과를 밝혔지만, 이 글은 그 수치를 검증하지 않았다. 모델별 표준 API 가격·사양 — 2026-09-28 조회, USD/100만 토큰 모델 입력 출력 캐시 읽기 컨텍스트 / 최대 출력 기본 effort Claude Opus 5.5 $4 $20 $0.20 1M / 128K medium Claude Opus 5 $5 $25 ...

Pro를 결제했는데 API 비용이 또 나왔다면? 요금제를 올리기 전에 로그인과 청구 경로부터 확인한다. 구독의 포함 사용량, 구독용 추가 사용 크레딧, Console/API 과금은 같은 항목이 아니다. 아래 가격표는 2026-09-14 조회값이며, 예시 토큰은 실제 사용량이 아닌 계산 가정이다. 편집 보완: 2026-09-23. 이번에는 청구 경로 확인 순서와 비교 기록 양식을 추가했다. 가격표 전체나 한국 계정 결제액을 이날 다시 검증한 것은 아니다. 이중 청구처럼 보일 때의 확인 순서 실행한 CLI의 버전과 로그인 계정을 기록한다. ANTHROPIC_API_KEY 의 설정 여부를 확인하되 키 값은 출력하거나 공유하지 않는다. 공식 Pro·Max 도움말은 이 변수가 있으면 구독 대신 API 키로 인증한다고 안내한다. 구독으로 쓰려던 개인 환경에 불필요한 키 설정이 있다면 설정 위치를 확인하고, Claude Code를 실행할 환경에서 해당 변수를 해제한 뒤 다시 실행해 구독 계정으로 로그인한다. 쉘 시작 파일이나 IDE에서 다시 주입되는지도 확인한다. 조직에서 관리하는 키는 임의로 제거하지 말고 관리자에게 인증 경로를 확인한다. Claude Code의 /usage 에서 구독 사용량과 세션 비용 추정치를 구분한다. 세션 달러 수치만으로 추가 청구가 발생했다고 판단하지 않는다. 구독의 추가 사용 크레딧 내역과 Console/API 사용 내역을 각각 확인한다. 최종 API 청구 판단은 Console 내역으로 하고, 구독료와 별도 사용료를 같은 기간으로 맞춰 비교한다. 이 절차의 문서 근거: Pro·Max에서 Claude Code 이용 , 공식 비용 관리 문서 (해당 인증·사용량 설명은 2026-09-23 조회). 독자의 계정에 로그인하거나 유료 작업을 실행한 검증은 아니다. 내 비용을 비교할 기록 양식 같은 기간에 작업과 완료 조건 / 모델 / 인증 방식 / 일반 입력·캐시 쓰기·캐시 읽기·출력 토큰 / 추가 사용료 / 한도에 막힌 시점 / ...

에이전트에 모델을 여러 개 물려 쓰다 보면 한 번은 이 질문에 닿는다. 모델별 프롬프트를 따로 써야 하나? 지난 다섯 편 동안 그걸 실제로 하는 공개 저장소(oh-my-openagent, 이하 omo)를 줄 단위로 읽었으니, 결산은 이 질문에 답하는 것으로 하겠다. 답부터. 대부분의 경우 갈라 쓸 필요 없다. 8벌을 운영하는 omo조차 기본값은 default 한 벌이고, 변형은 특정 모델의 실패 모드에 이름을 붙일 수 있을 때만 만들었다. 가져갈 것은 파일 8벌이 아니라 그 판단 순서다. 오늘 읽을 것은 셋이다. 변형이 언제 생기는지, 처방의 방향 다섯 가지, 그리고 갈라 쓰기 전에 밟을 순서와 그 비용. 참고로 이하의 모델 진단은 전부 omo 저자 code-yeongyu가 프롬프트 파일에 적은 관측이다 — 세부 유보는 글 끝 확인 범위에 모았다. 이런 경험이 있다면 새 모델을 물렸더니 에이전트 행동이 미묘하게 달라진 걸 본 적이 있다. 그래서 프롬프트를 모델별로 복사해 고치기 시작했는데, 곧 관리가 안 되는 것도 겪었다. 반대로 “요즘 모델은 다 알아서 하지 않나” 싶어 한 벌로 버틴 적도 있다. 양쪽 다 근거가 부족한 선택이다. 8벌짜리 저장소는 이 갈림길에서 뭘 기준으로 삼았는지부터 살펴보자. 변형은 실패 모드를 명명할 때만 생겼다 atlas 오케스트레이터 프롬프트 8벌을 다시 세면(2026-09-09 실측) default 496줄, gemini 526줄, opus-4-7 494줄, kimi 478줄, gpt 461줄, glm 402줄, kimi 신세대 2벌 각 326줄이다. 숫자보다 중요한 건 공통점이다. 여덟 벌 전부, 파일 안에 그 모델의 실패 모드를 명명하는 블록이 있다. Gemini판의 “YOUR FAILURE MODE”, Claude판의 “defaults you MUST counter”, GLM판의 카운터 3종 — 이름은 달라도 구조가 같다. 막연히 “이 모델에 맞게 다듬었다”는 변형은 하나도 없다. 관측 없이 만든 변형이 없...

모델별 프롬프트를 정성껏 갖춘 하네스라면, 가장 아끼는 모델의 전용 프롬프트가 제일 두꺼울까. omo의 Claude 사례는 반대로 답한다 — 전용 프롬프트는 현역이 아니라 구세대 몫이다. 요약부터. Atlas 오케스트레이터 프롬프트 8벌 중 Claude 몫은 opus-4-7.md 하나다(494줄, 2026-09-09 dev 브랜치 실측). 4.6 대비 4.7에서 달라진 버릇 두 개를 보정하는 파일이고, 정작 폴백 1순위 다섯 자리를 차지한 현역 Claude(opus-5·sonnet-5·fable-5-1)는 전부 default(496줄)를 받는다. 자동차 리콜 통지서를 떠올려 보자. 통지서는 최신 모델 앞으로 오지 않는다. 문제가 확인된 특정 연식 앞으로만 온다. omo 소개는 1편 , Kimi의 세대 파일 3벌은 2편 , GPT의 계약서는 4편 에서 다뤘다. 오늘 읽을 것은 넷이다. 하나뿐인 전용 변형과 그 이력을 보고, 보정하는 버릇 두 개를 읽는다. 같은 버릇을 지렛대로 돌려 쓰는 수법을 짚고, 현역 Claude가 실제로 받는 프롬프트가 뭔지로 끝낸다. 이하 진단은 전부 omo 저자 code-yeongyu가 프롬프트에 적은 관측이다. 이런 경험이 있다면 모델을 업그레이드했더니 에이전트가 서브에이전트를 덜 띄우는 걸 본 적이 있다. “모든 태스크에 적용하라”고 썼는데 첫 번째에만 적용하고 넘어가는 것도 봤다. 새 세대 모델이 나왔는데 전용 프롬프트는 옛 세대 것뿐인 저장소를 본 적도 있다. 세 가지 다 프롬프트가 아니라 모델 기본값이 움직인 경우다. 오늘 그 파일을 default와 겹쳐 읽는다. 여덟 벌 중 Claude 몫은 한 벌이다 숫자부터 살펴보자. GPT는 atlas 변형에 더해 ultrawork까지 전용 2벌을 받았고, Kimi는 세대별로 3벌을 받았다. Claude는 atlas의 opus-4-7.md 하나다. ultrawork에는 Claude 변형 자체가 없어서, Claude가 ultrawork 모드를 돌면 ...