매일 기록한 AI 기록

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

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

For months I believed my Claude Code setup was fine. Hooks, agents, rules, automations. Everything looked healthy, because nothing threw errors. Then I audited the whole thing for the first time since building it. Roughly half of it was either dead or faking it. The worst find: a security hook that had never run. Not once. Since the day I installed it. The security hook that never fired I wrote a hook to stop secrets (API keys, tokens) from leaking into tool output. The code checked a field called tool_result . The actual field in the payload is named tool_response . One word. The match never succeeded, so the hook silently did nothing on every single call, for months. No error, no warning. A guard that never fires looks exactly like a guard with nothing to catch. Fixing the typo would not have been enough, though. The hook ran after the tool executed. By the time it could mask anything, the model had already read the output, secret included. Post-hoc masking is too late by des...

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

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는 아무것도 쓰지 않고 활성값 안에서 조용히 돈다. ...