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 코딩 설정이 계속 작동하는지는 아무도 점검하지 않는다. 며칠 전 처음으로 내 설정을 전수 점검했다. 몇 달 동안 잘 굴러간다고 믿었던 설정이다. 다 열어보고 든 생각은 하나였다. 절반이 조용히 죽어 있거나, 가짜로 작동하고 있었다. 가장 충격적인 건 보안 훅이었다. API 키가 새는 걸 막으려고 달아둔 훅이, 필드명 오타 하나 때문에 설치된 날부터 한 번도 실행된 적이 없었다. 개발 에이전트 11개는 주석 한 줄 때문에 세션에 등록조차 안 되고 있었다. 설정도 코드처럼 썩는다. 만들고 방치하면 죽은 참조와 작동 안 하는 안전장치가 쌓인다. 영어로는 이걸 설정 부패(config rot)라고 부른다. 누가 읽으면 좋은가 Claude Code·Cursor에 CLAUDE.md·에이전트·훅을 세팅해 본 사람 설정을 한참 전에 만들어두고 그 뒤로 열어본 적 없는 사람 “에러가 안 나니까 잘 돌고 있겠지”라고 믿고 있는 사람 한 줄로 요약하면, 설정 파일에 등록돼 있다는 것과 그 기능이 실제로 작동한다는 것은 전혀 다른 문제였다. 주석 한 줄에 사라진 에이전트 11개 점검에서 가장 먼저 걸린 건 개발 에이전트들이었다. architect, planner, code-reviewer… 정의 파일은 멀쩡히 다 있었다. 그런데 세션에서 단 하나도 호출되지 않고 있었다. 원인은 파일 맨 위에 무심코 넣은 주석 한 줄이었다. # Part of … 같은 한 줄이 그 아래 frontmatter 파싱을 깨뜨렸고, 시스템은 그 파일들을 에이전트로 인식하지 못했다. 정의는 있는데 시스템은 그들을 보지 못한 것이다. 11개가 이 상태였다. 에러도, 경고도 없었다. 그냥 명단에서 빠져 있었다. 한 번도 돌지 않은 보안 훅 더 무서운 건 보안 훅이었다. 시크릿이 화면에 노출되는 걸 막으려고 만든 훅인데, 코드는 tool_result 라는 필드를 보...