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

PTY 기반 에이전트 세션에서 브라우저 자동화 CLI의 aside repl 을 장기 실행한 뒤 응답이 끊긴다면, REPL을 더 만지기 전에 출력 경로부터 확인해야 한다. 2026년 10월 12~13일 운영 기록에는 REPL을 띄운 지 1분 안에 세션이 세 번 멈췄고, 메인 스레드가 write(2) 에서 기다렸다고 남아 있다. 우회는 장기 REPL을 메인 세션 PTY에서 빼고 단발 실행이나 PTY 밖 FIFO 입력으로 돌리는 것이고, 커널 수준의 원인은 증명하지 못했다. 살아 있는 프로세스가 답하지 않았다 터미널 화면과 텔레그램 응답이 함께 멈췄다. 운영 메모에는 세 번 모두 메인 세션에서 REPL을 띄운 뒤 1분 안에 같은 정지가 나타났다고 적혀 있다. 한 번의 긴 작업이 아니라, 같은 실행 방식 뒤에 반복된 정지였다. 이 세션은 감시기(supervisor)가 띄운 PTY 안에서 돈다. 감시기가 PTY 출력을 계속 읽어 pty.log 에 남겨야 세션이 다음 출력을 쓸 수 있다. 그 pty.log 가 더 이상 진행하지 않았다. sample 로 본 메인 스레드는 쓰기 대기 상태였고, 감시기 쪽 PTY에는 읽을 출력이 없었다. REPL을 종료해도 응답이 돌아오지 않아 세션을 재시작해야 했다. 이 세 가지는 서로 다른 관찰이다. 로그 정지는 출력이 진행하지 않는다는 신호이고, 스택은 어느 호출에서 기다리는지를 보여 준다. REPL 종료 뒤에도 풀리지 않았다는 사실은 자식 프로세스 하나를 끄는 것으로 복구되지 않았다는 뜻이다. 처음에는 감시기를 잘못 의심했다 이틀 동안 정지는 네 번이었다. 그중 세 번이 aside repl 을 띄운 지 1분 안에 일어났고, 처음에는 이 연관을 보지 못했다. 첫 가설은 감시기가 빈 읽기를 한 번 만나면 출력 감시를 끊는다는 것이었다. 빈 읽기 뒤에도 감시를 다시 걸고, 그때마다 pty_eof 기록을 남기도록 고쳤다. 다음 정지 때 이 기록은 한 번도 남지 않았다. 두 번째 가설은 kqueue 가 "읽을 출력이 ...

답부터 말하면 제작자와 검수자를 나누는 이유는 문장을 더 매끈하게 만들기 위해서가 아니다. 공개를 막아야 할 오류를 이름 붙이고, 수정한 뒤에만 통과시키기 위해서다. 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...

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

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”. 제목만 봤다. 그래서 남의 도구 말고 직접 굴리는 것부...

컨텍스트 엔지니어링이라는 말을 몰라도 하는 일은 같다. 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 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...

에이전트가 ‘됐습니다’ 할 때 속으론 뭘 생각하나 — 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는 아무것도 쓰지 않고 활성값 안에서 조용히 돈다. ...