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가 썼네” 하고 잡아내는 그 감의 정체가 문체의 통계이기 때문이다. 이 글은 그 감을 숫자로 옮겨, 파이썬 결정론 게이트로 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

이미지
에이전트가 ‘됐습니다’ 할 때 속으론 뭘 생각하나 — 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 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준

이미지
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...

AI 코딩 에이전트는 .env를 읽는다 — OpenAI도 10개월째 못 막은 문제

이미지
AI 코딩 에이전트는 .env를 읽는다 — OpenAI도 10개월째 못 막은 문제 AI 코딩 에이전트한테 저장소를 통째로 맡기는 사람이 늘었다. 그런데 그 저장소 안에는 보통 .env 가 같이 들어 있다. 내 경우엔 시크릿이 새는 걸 막는 보안 훅이 오타 하나로 몇 달간 돌지 않고 있었다. 그동안 에이전트가 키 파일을 읽어도 걸러낼 장치가 없었다는 뜻이다. 결론부터 적으면, .gitignore 로는 에이전트한테 시크릿을 숨기지 못한다. 막아야 할 지점은 파일이 아니라 도구 호출이다. 이 글은 그 이유를 OpenAI Codex의 공개 이슈 하나로 짚고, 내 설정에서 .env 가 읽히는지 확인하는 법까지 정리한다. AI 코딩 에이전트 보안에서 가장 자주 새는 구멍이 여기다. 다음 중 하나라도 해당되나 .env 를 .gitignore 에 넣었으니 안전하다고 생각한 적이 있다. 에이전트한테 “이 디렉터리 전체를 분석해줘”라고 시켜 본 적이 있다. API 키나 토큰을 프로젝트 루트의 설정 파일에 그대로 둔 적이 있다. 셋 중 하나라도 해당되면 이 글이 짚는 위험에 노출돼 있다. 왜 그런지는 에이전트가 파일을 읽는 방식을 보면 바로 드러난다. 에이전트가 파일을 읽는 방식 깃과 에이전트는 파일을 보는 길이 다르다. .gitignore 는 git add 단계에서만 작동한다. 깃이 추적하지 않을 파일을 지정할 뿐이다. 반면 코딩 에이전트는 깃을 거치지 않는다. rg (ripgrep)나 grep , cat 같은 도구를 직접 호출해서 파일 시스템을 읽는다. 에이전트 입장에서 .env 는 그냥 텍스트 파일 하나일 뿐이고, 깃이 무시하든 말든 상관이 없다. 그래서 “민감 파일을 .gitignore 에 넣어 뒀으니 에이전트도 안 읽겠지”라는 가정이 깨진다. 에이전트가 코드 검색을 하다가 .env 안의 문자열이 검색어에 걸리면, 그 내용은 도구 출력으로 모델에 전달된다. 모델에 전달된다는 건 외부 서버로 전송된다는 뜻이다. 핵심은 차단 지점이다. 파일에...

블로그 노출 74% 감소, 그런데 색인된 신규 글은 0개 — GEO는 답일까 가설일까

이미지
블로그 노출 74% 감소, 그런데 색인된 신규 글은 0개 — GEO는 답일까 가설일까 블로그 조회수가 떨어졌다는 글이 요즘 부쩍 보인다. 내 블로그도 그랬다. 검색 노출이 28일 만에 376회에서 97회로 빠졌다. 74% 감소다. 어제 발행한 글 두 편은 검색에 단 한 번도 안 떴다. 데이터를 까보니 원인은 내 글이 부실해서가 아니었다. 검색이 클릭을 내주지 않는 쪽으로 바뀌는 중이었다. 대응은 GEO라고들 하는데, 정작 내 블로그에선 그게 답인지 아직 모르겠다. 먼저 결론부터 적는다. 검색 노출이 줄어드는 건 글 품질 문제가 아니라 구조 변화다. AI 검색이 답을 먼저 보여주면서 클릭 자체가 사라지고 있다. GEO(생성형 엔진 최적화 — AI가 답할 때 내 글을 인용하게 만드는 것)는 그 대응으로 거론되지만, 색인조차 안 뚫린 저권위 블로그에서 효과가 난다는 증거는 아직 없다. 이 글은 내 구글 서치 콘솔 데이터로 그 현실을 그대로 까는 기록이다. 누가 읽으면 좋은가 블로그나 사이트 검색 유입이 최근 몇 달 새 눈에 띄게 떨어진 사람 GEO·AEO 글을 봤지만 진짜 효과가 있는지 의심스러운 사람 자기 검색 데이터를 어떻게 읽어야 할지 막막한 사람 28일 만에 사라진 노출 279건 GSC(구글 서치 콘솔 — 검색에서 내 글이 몇 번 노출되고 클릭됐는지 보여주는 무료 도구)를 직접 떠봤다. 최근 28일 노출은 97회, 직전 28일은 376회였다. 279회가 빠졌다. 74% 감소다. 기간 클릭 노출 최근 28일 (5/28~6/24) 2 97 직전 28일 (4/30~5/27) 1 376 증감 +1 -279 (-74%) 90일로 늘려 봐도 클릭 3, 노출 504였다. 석 달 누적이 이 정도다. 곡선이 더 문제였다. 4월 말부터 5월 초까지는 하루 20~35회 떴는데, 6월엔 0~5회로 내려앉았다. 구글이 새 글에 잠깐 노출을 주다가 거둬가는 전형적인 감쇠 곡선이다. 노출을 떠받치는 글을 하나...

오케스트레이션이 제품이 됐다 — Sakana Fugu가 말하는 것과 안 말하는 것

이미지
Sakana Fugu는 그 오케스트레이션 자체를 모델로 만들어 파는 제품이다. 오늘(2026-06-22) 정식 출시됐다. 써보진 않았다. 그래서 후기는 아니다. 공개된 자료로 주장과 빈칸만 따졌다. 한 줄로 정리하면 이렇다. Fugu에는 진짜 새로운 한 가지와, 아직 아무도 독립 검증하지 않은 여러 빈칸이 같이 들어 있다. 누가 읽으면 좋은가 멀티에이전트·오케스트레이션을 직접 엮어본 사람 “모델이 모델을 부린다”가 마케팅인지 진짜 새 구조인지 궁금한 사람 LangGraph나 OpenRouter를 쓰면서 그다음이 뭔지 보는 사람 Fugu가 진짜 새로운 한 가지 Fugu는 라우팅 규칙을 손으로 짠 게 아니라, 오케스트레이션을 학습한 모델 이다. 작업을 받으면 직접 풀거나, 전문 모델들을 불러 팀을 꾸리고, 검증·합성까지 한다. 자기 자신을 재귀로 다시 부르며 “1차 답이 부족했다”를 인지하고 교정하기도 한다. 근거는 Sakana의 ICLR 2026 논문 두 편이다. TRINITY (arXiv 2512.04695)는 진화 전략으로 학습한 0.6B 지휘자가 Thinker·Worker·Verifier 역할을 나눠주고, The Conductor 는 7B 모델을 강화학습으로 훈련해 자연어 협응 전략을 스스로 찾게 한다. Fugu는 이 둘을 개선해 상품화한 것이다(제품 지휘자 크기는 비공개). 풀에는 Opus 4.8, Gemini 3.1 Pro, GPT-5.5가 들어간다. 그리고 이 풀을 지휘해 풀 멤버 각각보다 더 잘한다 고 주장한다. 라우터(한 개 고르기)도 프레임워크(손으로 배선)도 아닌, “훈련된 오케스트레이터 = 모델”이라는 자리는 카테고리상 분명히 새롭다. 그런데 — 빈칸들 여기서부터가 불편한 부분이다. 벤치마크는 전부 Sakana 자체 보고고 독립 검증이 아직 없다. Fugu Ultra가 SWE-Bench Pro 73.7로 Opus 4.8(69.2)을 앞선다지만, 정작 풀에 없는 Fable 5가 그 벤치와 Humanity’s Las...