매일 기록한 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 유...

AI가 제안한 수정 문장도 원문과 다시 대조해야 한다. 출처가 존재하는지보다 그 출처의 조건이 실제 문장에 남아 있는지가 승인 기준이다. 2026년 10월 13일 검수 기록에는 이전 검수자가 제안한 문장 두 곳을 다시 FAIL로 돌린 사례가 남아 있다. AI의 설명을 문서나 안내문에 옮기는 개발자라면 이 차이가 중요하다. 검수 요청에 “사실을 확인해”만 적지 말고, 주장·출처·문장과 반려 조건을 같이 넘겨야 한다. 검수자의 문장도 왜 틀렸을까 해당 기록에서 형식 검사와 가독성 검사는 통과했다. 그런데 원고 A의 첫 답과 원고 B의 결론은 각 원고가 보관한 근거와 맞지 않았다. 두 문장 모두 앞선 검수자가 직접 제안했던 표현이었다. 한 문장은 적용 대상을 넓혔다. 다른 문장은 특정 선택지의 기한을 모든 선택지의 소멸로 바꿨다. 문장은 매끈했지만 출처가 허용한 범위보다 강했다. 이를 특정 모델의 우열로 해석하지 않는다. 확인된 것은 두 문장의 오류와 반려 이유다. 모델별 누락률이나 검수 정확도를 비교한 실험은 이 기록에 없다. 사례 A: 처음 계약의 조건이 빠졌다 원고 A는 계약을 중간에 끝낼 수 있는 조건을 설명했다. 검수 기록에 남은 전·후 문장은 다음과 같다. > 전: “해지 특약이 없다면 세입자 혼자 계약을 끝낼 수 없어서, 합의하지 못하면 만료일까지 월세를 내야 합니다.” > > 후: “처음 정한 계약기간 중이고 해지 특약이 없다면, 합의하지 못하는 한 만료일까지 월세를 내야 합니다.” ‘후’는 그다음 검수자가 새로 제시한 수정안이다. 이 기록만으로 수정 적용이나 최종 PASS까지 확인한 것은 아니다. 빠진 부분은 “처음 정한 계약기간 중”이다. 저장된 법령의 제6조의2는 묵시적으로 갱신된 계약에서 임차인이 언제든 해지를 통지할 수 있다고 정한다. 효력은 임대인이 통지를 받은 날부터 3개월이 지나면 생긴다. 제6조의3 제4항은 갱신요구권으로 갱신된 계약의 해지에도 제6조의2를 준용한다. 그래서 ‘특약이 없다’는 조건만으...

답부터 말하면 제작자와 검수자를 나누는 이유는 문장을 더 매끈하게 만들기 위해서가 아니다. 공개를 막아야 할 오류를 이름 붙이고, 수정한 뒤에만 통과시키기 위해서다. 2026년 9월 23일의 독립 검수 기록에서는 구체적인 수정 요구 4건이 나왔다. 제작자가 고친 뒤 같은 범위로 다시 검수했고, 그제야 판정이 REVISE에서 PASS로 바뀌었다. 왜 잘 쓰는 에이전트에게 검수까지 맡기면 안 될까? 문제는 작성자가 자신의 전제를 이미 알고 있다는 점이다. 문장이 자연스러우면 빠진 조건도 머릿속에서 자동으로 보완한다. 검수자는 그 전제를 공유하지 않아야 한다. 원고와 근거 파일을 대조하고, 현재형 주장인지 과거 기록인지, 절차가 실제로 끝까지 이어지는지 따로 확인해야 한다. 2026년 9월 14일 결정 기록도 이 구분을 택했다. 익명 비교에서 deep(장시간 작업하는 제작 에이전트) 제작본은 사실 정확성과 유용성이 각각 5 대 4로 앞섰고, 리드(작업을 나누고 검증하는 주 에이전트) 제작본은 가독성이 4 대 3으로 앞섰다. 그래서 제작은 deep, 검증은 리드가 맡는 구조로 정했다. 이 수치는 모델의 보편적 우열이 아니다. 당시 여섯 글로 누가 더 잘 쓰는지를 비교한 운영 기록이며, 검수를 분리하면 오류가 준다는 증거는 아니다. 같은 조건의 재평가도 아직 하지 않았다. 제작과 독립 검수의 역할 비교 구분 제작자가 주로 보는 것 독립 검수자가 확인할 것 통과 조건 원고 설명의 흐름과 독자 질문 주장과 근거의 일치 근거 없는 현재형 주장이 없음 절차 단계가 자연스럽게 읽히는지 실제 실행에 빠진 단계가 없는지 같은 경로를 끝까지 따라갈 수 있음 용어 문맥 안에서 이해되는지 식별자·버전·범위가 일관적인지 같은 대상을 같은 이름과 범위로 설명함 판정 초안 완성 REVISE 또는 PASS PASS 전에는 발행하지 않음 독립 검수는 실제로 무엇을 잡았나? 한 번의 검수에서 잡힌 수정 항목은 네 가지였다. 맞춤법보다 주장 범위와 실행 조건에 가까운 문...

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

답부터 말하면 토큰 사용량이 그대로인 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 ...

grep 두 번으로 틀린 글을 냈다 — 127일째 아무도 안 부르는 코드 죽은 코드는 에러를 내지 않는다. 그냥 거기 있다. 지난주에 발행한 글의 근거가 그런 파일이었다. 그 글은 5월에 쓴 다른 글을 정정 대상으로 지목했는데, 재보니 5월 쪽이 맞았다. 결론부터 적는다. 죽은 코드는 안 도는 데서 끝나지 않았다. 틀린 주장을 발행하게 만들었고, 그 주장은 검토를 전부 통과했다. 누가 읽으면 좋은가 새 저장소를 열면 grep 부터 돌리는 사람. 자기가 만든 도구를 글이나 문서로 설명해 본 사람. 조사 결과를 근거 삼아 무언가를 결정해 본 사람. 파일을 찾고 나서 그게 실행 경로에 있는지는 안 본 적이 있다. 오래된 저장소에 안 쓰는 파일이 몇 개인지 세어본 적은 없다. 커밋 메시지가 틀릴 수 있다는 생각은 해본 적이 없다. 두 달 전에 쓴 규칙, 50일 뒤의 위반 6월 15일 발행글에 이렇게 적었다. 설정 파일에 등록돼 있다고 그 기능이 도는 게 아니다. 같은 글에 확인 방법도 적어뒀다. “에이전트라면 실제로 호출되는지 본다.” 50일 뒤인 8월 4일. 수집기의 비용을 조사하면서 저장소를 두 번 뒤졌다. grep 으로 유료 API 키를 참조하는 파일 하나를 찾았다. 이어서 스케줄러 설정을 열어 08:17과 20:17, 하루 두 번 도는 것을 확인했다. 둘을 곱했다. “하루 두 번 유료 호출인데 회당 비용 기록이 0건이다.” 그대로 발행했다. 그 파일이 실제로 호출되는지는 안 봤다. 규칙을 쓴 사람이 그 규칙의 첫 항목을 건너뛴 셈이다. 127일째 아무도 안 부르는 파일 오늘 다시 열어보니 확인은 세 번으로 끝났다. 확인 명령·대상 결과 import 역추적 grep -rn "from trend_scout.analyzer" --include="*.py" . 0건 엔트리포인트 main.py 의 내부 import 목록 collectors·compare·models·t...

“ok” 한 마디에 $0.07 — AI 코딩 도구 비용은 어디서 새는가 정정 (2026-08-11) — 아래 네 번째 절의 근거가 틀렸다. 분석 코드는 2026-04-06 커밋에서 파이프라인에서 빠졌고, 그 뒤로는 유료 호출이 없었다. 5월 글의 “0원”은 발행 시점에 맞는 서술이었다. 해당 절을 실측대로 고쳐 적었다. Claude Code 실측(두 번째·세 번째 절)은 영향이 없다. AI 코딩 도구 비용은 월 구독료로 끝나는 것처럼 보인다. 화면에 금액이 안 뜨니 그렇게 읽힌다. 헤드리스 모드로 실험을 하나 했다. 모델에게 “ok” 한 마디만 시켰다. 청구된 금액은 $0.0697 이었다. 실제로 주고받은 토큰은 123개다. 나머지 51,386개는 지시한 적이 없다. 단 이 비율은 가장 나쁜 경우에 가깝다는 점을 미리 적어둔다. 결론부터 적는다. 비용은 대화가 아니라 함께 실려 가는 컨텍스트에 몰려 있고, 그 값은 대부분 기록되지 않는다. 같은 도구인데 실행 방식에 따라 금액이 보이기도 하고 아예 안 남기도 했다. 5월에 발행한 글에서는 이 수집기를 “비용 0원”이라고 적었다. 그 값을 재본 기록은 어디에도 없었다. 청구서를 열어보게 만든 것 한도 경고를 90%에서 처음 본 적이 있다. 어떤 작업이 비쌌는지 되짚지 못한 적도 있다. 매일 도는 자동화의 회당 비용을 모른 채 몇 달을 굴린 적도 있다. 밖에서도 같은 얘기가 올라온다. Hacker News에 “Cursor removed cost information from the usage page and CSV export”라는 글이 걸렸다. 8월 2일 작성이고, 조회 시점 기준 336점에 댓글 154개다. 스레드 본문은 안 읽었으니 제거 의도는 모른다. 같은 날 수집된 제목 중에는 이런 것도 있었다. “I don’t trust agent tools when I can’t understand what the work costs”. 제목만 봤다. 그래서 남의 도구 말고 직접 굴리는 것부...

Claude Code 훅이 등록돼 있는데 왜 로컬 명령을 못 막을까? 등록 여부, matcher, 스크립트의 조기 종료 조건을 따로 봐야 한다. 이 글은 직접 만든 원격 전용 훅이 로컬에서는 검사를 건너뛴 사례다. Claude Code 전체가 삭제 명령을 허용한다는 뜻도, 모든 deny 규칙이 무효라는 뜻도 아니다. 작성자: 닥터조지. 측정 시점: 2026-08-02 로컬 세션 / 편집 보완: 2026-09-23. 당시 CLI 버전은 이 글에 기록되어 있지 않다. 새 버전에서 재실행한 결과가 아니며, 아래 절차는 독자의 환경을 따로 확인하기 위한 점검 순서다. 훅 미작동을 구분하는 점검 순서 CLI 버전, 로컬·원격 여부, 실제로 읽힌 설정 파일을 기록한다. 사용자 설정과 프로젝트 설정을 혼동하지 않는다. PreToolUse 의 matcher가 검사하려는 도구와 일치하는지, 실행할 스크립트 경로가 맞는지 확인한다. 스크립트의 앞부분과 모든 조기 종료 조건을 읽는다. 원격 전용 환경변수가 없을 때 exit 0 이면 등록돼 있어도 해당 경로를 검사하지 않는다. 삭제·외부 전송·실제 비밀 읽기를 하지 않는 확인 명령을 골라, 평소 사용하는 Claude Code 세션에서 한 건만 요청한다. 일반 터미널에서 명령만 실행하는 것은 Claude Code 권한 검사 시험이 아니다. 요청한 도구·명령, 훅 로그, 차단 메시지, 종료 상태를 함께 남긴다. 훅 단독 호출 결과와 Claude Code 전체 경로의 결과를 다른 칸에 기록한다. 차단 주체를 구분할 수 없으면 미확인으로 남긴다. 기대 결과는 단순히 “막힘”이 아니라 어느 설정·어느 훅이 그 요청을 처리했는지 추적 가능한 기록 이다. xargs --version 지원 여부는 운영체제의 구현에 따라 다르다. 옵션 오류가 나더라도 권한 차단과 실행 후 오류를 구분해야 한다. 과거 시험의 chmod 777 을 실제 작업 파일에 따라 하지 않는다. 현재 설정 형식의 기준은 Claude Code 공식 Ho...

6월에 이렇게 썼다. 검색 노출이 28일 만에 74% 빠졌는데 내 글이 부실해서가 아니라 검색이 클릭을 안 내주는 쪽으로 바뀌는 중이라고. 두 달이 지났다. 오늘 다시 쟀더니 최근 10편 색인이 0이다. 숫자는 그대로인데, 그 진단으로는 설명이 안 되는 게 네 개 나왔다. 6월 진단이 틀렸다는 게 아니라 범위가 좁았다. 검색만 보고 있었는데, 새로 나온 증상들은 검색엔진 바깥에서 왔다. 글을 어디에 얹어뒀느냐가 문제였다. 안 뜨는 걸 겪어본 사람이면 발행하고 며칠 지나 검색해봤는데 자기 글이 안 나온 적이 있다. 서치 콘솔을 열었다가 “색인 생성됨” 대신 처음 보는 문구를 본 적도 있을 것이다. 색인 요청 버튼을 눌러놓고 며칠을 기다려본 적도 있다. 이 블로그가 두 달째 그 상태다. 다만 이번에는 원인을 검색엔진에서만 찾지 않았다. 6월 진단으로 설명 안 되는 것 넷 오늘 잰 색인 상태부터 적는다. 최근 10편 중 색인된 글은 0편이다. Redirect error가 6편, 크롤조차 안 된 게 4편이다. 어제와 오늘 사이에 움직임도 있었다. 어제 “발견됨, 색인되지 않음”이던 두 편이 오늘 “URL을 구글에서 알 수 없음”으로 내려갔다. 사이트맵에 멀쩡히 들어 있는 주소들이다. 그리고 검색과 무관한 자리에서 문제가 나왔다. 관측 6월 진단(검색 구조 변화)으로 설명되나 Hacker News가 내 도메인 제출을 거부 안 됨 — 검색엔진이 아닌 채널 영문 글이 lang='ko' 로 서빙됨 안 됨 — 블로그 테마 설정 Redirect error 6편 안 됨 — 게시 시점 주소 전환 구조 발견됨 → URL 알 수 없음 강등 부분적 — 크롤 우선순위 문제 지난주에 쓴 영문 글을 HN에 제출하려 했더니 “이 사이트는 제출할 수 없다”는 문구가 떴다. blogspot 도메인이 통째로 막힌 건 아니었다. 같은 날에도 다른 blogspot 글이 제출됐고, 최근 1년으로 보면 1만 건이 넘는다. 이...

컨텍스트 엔지니어링이라는 말을 몰라도 하는 일은 같다. 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)이...