AI 도구 매일 노트 — 해고된 개발자의 기록

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

MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준 AI 코딩 에이전트에 도구를 붙이는 방식을 두고 MCP냐 CLI냐 하는 글이 늘었다. 나는 양쪽을 다 쓴다. 코드 검색은 MCP 서버로 하고, 시크릿 차단과 블로그 발행은 CLI 쪽에 맡긴다. 그런데 오늘 평소와 다른 디렉토리에서 세션을 열었다가, 늘 쓰던 MCP 서버가 조용히 빠져 있는 걸 발견했다. 에러 한 줄 없었다. 이 사건까지 겹치고 나서야 정리가 됐다 — 판단 기준은 도구의 모양이 아니라 “무엇을 통제해야 하는가”였다. 먼저 요약. 세션 안에서 반복되는 조회는 MCP가 이기고, 실행을 막거나 검증해야 하는 작업은 CLI가 이긴다. 그리고 내 환경에서 제일 잘 굴러가는 구조는 둘 중 하나를 고르는 대신, CLI 훅이 MCP 사용을 강제하는 조합이었다. 누가 읽으면 좋은가 Claude Code나 Codex에 MCP 서버를 몇 개 붙였는데, 컨텍스트만 커지고 체감 이득이 없던 적이 있다. 에이전트가 cat과 grep으로 코드를 통째로 읽어대서, 토큰 사용량이 신경 쓰인 적이 있다. .env 노출 같은 사고를 막고 싶은데, MCP 서버를 잘 고르면 될 거라고 기대한 적이 있다. 셋 다 내가 직접 겪은 일이다. 같은 상황이라면 아래 기준을 그대로 가져다 써도 될 것 같다. 내 환경에서 두 방식이 놓이는 자리 MCP(Model Context Protocol)는 에이전트가 세션 안에서 도구를 함수처럼 호출하는 연결 방식이고, CLI는 에이전트가 셸에서 명령을 실행하는 방식이다. 아래 표의 훅은 그 실행 앞뒤에 끼어드는 검사 스크립트를 말한다. 내 환경에서 실제로 돌아가는 작업을 연결 방식별로 나누면 이렇다. 작업 연결 방식 이유 코드 구조 파악·검색 pluck (MCP) 반복 조회, 토큰 절감 브라우저 조작·검사 chrome-devtools (MCP) 세션 상태 유지 시크릿 노출 차단 secret-output-gu...