매일 기록한 AI 기록

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> 블록을 제시합니다. 모델이 도구 호출이나 파일 탐색을 시작하기 전에 사용자의 요청을 여섯...

2026-10-13 dev 브랜치 기준(commit origin/dev b78527c )으로 코드베이스 내 모델 매칭 체인과 전용 프롬프트 구성을 검토했습니다. 본 글은 프롬프트 지시 내용과 실제 관측된 효과를 구분하여, 저장소에 등록된 사실만을 다룹니다. Kimi가 배치된 자리 새 Native 세션의 daily-normal 체인에서는 Claude Opus 5.5 → Kimi K3 → GLM 5.3 순서로 모델이 나열되어 있습니다. 각각의 모델 식별자는 claude-opus-5-5 , kimi-k3 , glm-5.3 입니다. 시스템은 연결된 provider에서 제공하는 첫 번째 후보를 선택하므로, Kimi는 단일 고정 기본값이 아닙니다. 이 내용은 agent-model-matching.md 에 명시되어 있습니다. 한편 OpenCode Sisyphus의 기본 fallback 체인은 Claude Opus 5.5 → Kimi K3 → GPT-5.6 Sol → GLM 5.2 → Big Pickle 로 구성되어 있어 Native daily-normal 체인과 다릅니다. 역할 및 카테고리별 요구 사항을 정의한 agent-model-requirements.ts 와 category-model-requirements.ts 에 따르면 모델 배치는 다음과 같이 구분됩니다. Atlas 와 Sisyphus-Junior : Claude Sonnet 5 다음 순위로 Kimi K3 가 배치됩니다. explore 및 librarian : kimi-for-coding-highspeed 가 첫 번째 후보로 지정되어 있습니다. writing : Kimi 계열 모델이 포함되지 않습니다. quick : GPT-6 Luna Fast 등으로 체인이 시작됩니다. 전용 파일 세 개와 줄 수 Atlas Markdown 파일은 전체 8개로 구성되어 있으며, 그중 Kimi 전용 파일은 3개입니다. 각 파일의 줄 수는 다음과 같습니다. kimi.md : 478줄 ...

2026-10-13 dev 브랜치 기준, origin/dev b78527c 커밋에서 omo 는 코딩 에이전트의 역할, 도구, 설정, 위임, 모델별 프롬프트를 묶는 하네스입니다. 최신 개요에는 OpenCode Ultimate , Codex Light , Native/Senpi 실행 흐름이 함께 포함되어 있으며, Team Mode 와 hyperplan 기능이 존재합니다. 하네스와 에이전트 역할 omo 는 코딩 에이전트가 수행할 작업과 도구를 조율하는 하네스 역할을 담당합니다. 문서 AGENTS.md 에 따르면 OpenCode 어댑터 내장 에이전트는 다음과 같이 11종으로 구성됩니다. Sisyphus : 주 오케스트레이터 역할을 수행합니다. Hephaestus : 자율 깊은 구현을 진행합니다. Oracle : 읽기 전용 상담을 담당합니다. Librarian : 외부 문서와 코드를 검색합니다. Explore : 코드베이스를 탐색합니다. Multimodal-Looker : PDF와 이미지를 분석합니다. Metis : 사전 계획 상담을 진행합니다. Momus : 계획을 검토합니다. Atlas : todo 오케스트레이션을 맡습니다. Prometheus : 인터뷰형 전략 계획을 수립합니다. Sisyphus-Junior : category 실행을 담당합니다. 카테고리와 Native 프로필 하네스에서 작업을 위임할 때는 category 를 활용합니다. 예를 들어 quick , deep-high , writing 등이 있습니다. task(category=...) 를 호출하면 해당 category 의 모델과 skills 를 가진 워커를 생성합니다. agent-model-matching.md 문서와 builtin-profiles.ts 파일에 따르면 Native 환경의 기본 레인은 4개입니다. daily-normal daily-heavy geeky-normal geeky-heavy 기본적으로 연결된 provider 가 제...

건물 하나를 떠올려 보자. 택배 기사는 그냥 들여보내는데 방문객처럼 굴면 신분증을 내고 방문 목적을 적어야 한다. 그 건물에서는 제복을 벗는 쪽이 빨리 들어간다. 내 수집기는 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가 자바스크립트 챌린지를 걸 때 내보내는 화면이다. 즉 브...

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...