AI Skill 29개 중 23개 삭제, 남은 6개의 공통점

2주 조금 넘게 전에 나는 AI에게 8개의 직책을 맡기는 글을 썼고, 30개가 넘는 Skill을 설치했으며, 각각 명확한 분업 구상이 있었다. 오늘 아침 매일의 데이터 파이프라인을 돌리고 나서, 나는 무심코 이 기기의 30일 호출 로그를 훑어보았고, 그다음 29개 Skill 중 23개를 냉궁(대기 폴더)으로 옮겼다.

쓰기가 안 좋아서가 아니다. 로그가 내가 생각해본 적 없는 사실 하나를 알려줬다: 이 23개는 지난 30일 동안 실제 트리거된 횟수를 다 합쳐도 겨우 3회였다 — 3개가 각각 1번씩 쓰였고, 나머지 20개는 한 번도 쓰이지 않았다.

그런데 이 기기에서 매일 흔들림 없이 돌아가는 파이프라인은 겨우 6개의 Skill로 지탱되고 있다.

오늘 이 글에서는 전체 점검 과정을 펼쳐놓는다: 어떻게 점검했는지, 로그는 어디서 거짓말을 하는지, 23개는 각각 어떻게 죽었는지, 남은 6개는 무엇으로 살아남았는지. 마지막에는 내가 직접 쓰고 있는 「세 가지 질문 판정표」가 있는데, 당신도 오늘 밤 자신의 Skill 라이브러리에 바로 돌려볼 수 있다.

一、먼저 점검 방법을 밝혀둔다, 나처럼 로그만 보지 말 것

점검 자체는 복잡하지 않지만 함정이 하나 있다: 호출 로그만 보면 오판한다.

나는 처음에 두 번이나 빠졌다. 첫 번째는 dws(매일의 블로그 조간 브리핑을 딩톡으로 푸시할 때 쓰는 CLI 도구)가 로그에서 호출이 전혀 없는 것을 발견했을 때다 — 하마터면 사형 판결을 받을 뻔했다. 나중에야 나는 그것을 터미널에서 직접 실행했지, Skill 호출 채널을 거치지 않았다는 것을 기억해냈다. 두 번째는 반대 경우다: 회고 일기의 Skill 로그도 0이었지만, 내 회고 파일은 분명히 존재했고, 다만 산출물이 다른 디렉터리에 떨어졌을 뿐이었다.

그래서 최종적으로 나는 세 개의 선을 교차 검증에 사용했다:

- 디렉터리 점검: Skill 설치 디렉터리 아래의 모든 폴더를 나열하고, 먼저 플랫폼 자체 내장 3개의 관리类 도구(Skill 생성, 의존성 설치 같은 것)를 제외했고, 남은 29개가 내가 주동적으로 설치한 것이다

- 호출 로그: 세션 데이터베이스에서 최근 30일의 Skill 도구 호출 기록을 조회하고, 이름별로 그룹화해 횟수를 집계했다

- 산출물 낙점: 최근 한 달간 산출된 글, 표, 이미지를 뒤져 어느 Skill이 참여했는지 역추적했다

점검 스크립트의 핵심 로직은 아주 짧고, 세션 데이터베이스는 SQLite이며, Node로 직접 실행한다:

const { DatabaseSync } = require ( "node:sqlite" ); const fs = require ( "node:fs" ); const db = new DatabaseSync ( process. env . HOME + "/Library/Application Support/QoderWork/data/agents.db" , { readOnly : true } ); // 내가 설치한 29개(디렉터리 점검 시 플랫폼 자체 내장 3개는 이미 제외) const installed = fs. readdirSync ( process. env . HOME + "/.qoder/skills" ). filter ( ( d ) => ![ "create-skill" , "install-skill-dependency" , "qoderwork-guidance" ]. includes (d)); const since = Math . floor ( Date . now () / 1000 ) - 30 * 86400 ; const rows = db. prepare ( ` SELECT json_extract(item.value, '$.input.skill') AS name, COUNT(*) AS calls FROM messages, json_each(messages.parts) AS item WHERE messages.created_at > ? AND json_extract(item.value, '$.toolName') = 'Skill' GROUP BY name ` ). all (since); const calls = new Map (rows. map ( ( r ) => [r. name , r. calls ])); const report = installed. map ( ( d ) => ({ skill : d, calls30d : calls. get (d) ?? 0 , verdict : (calls. get (d) ?? 0 ) === 0 ? "제로 호출" : "트리거 있음" , })); console . table (report. sort ( ( a, b ) => b. calls30d - a. calls30d ));

( node:sqlite 는 Node 22+가 필요하고, 구버전은 DatabaseSync 를 better-sqlite3 로 바꿔도 똑같이 돌아간다.)

돌려본 결과는 절벽이었다: 1위 35회, 2위 2회, 그다음 다섯 개는 각각 1회, 나머지는 전부 0이었다.

二、23개는 어떻게 죽었나: 네 가지 죽음의 방식

제로 트리거 20개와 외톨이 트리거 3개를 하나하나 훑어보니, 사인(死因)이 매우 집중되어 있었다. 나는 「설치할 때 내가 무슨 생각을 하고 있었나」를 기준으로 네 가지로 분류했다.

죽음의 방식 1: 「나중에 쓸 일이 있을 것」형

그것을 설치하던 그 순간 나는 진심이었다. 남의 워크플로 공유를 보고 이 사고방식 정말 좋다 싶어서, 설치하면 마치 내가 그 능력을 가진 것만 같았다.

생활 계획류, 사고 방법류의 몇몇 Skill이 전부 이 등급에 속한다. 설치 날짜는 내가 「AI가 내 삶을 치유했다」류 글을 몇 편 본 그 주에 집중되어 있다. 그 후 30일, 제로 트리거.

「나중에 쓸 일이 있을 것」은 거짓말이고, 그것의 진짜 의미는 「나는 지금 불안하니 일단 저장해두고 좀 완화하자」다. 이것은 브라우저 즐겨찾기 폴더 속 그 2000개의 「나중에 볼」 웹페이지와 같은 심리다.

죽음의 방식 2: 일회성 작업 잔여물형

어떤 Skill은 VM 오류가 났던 날 설치했고, 그날 실제로 문제를 해결했다. 내부망 디버깅, 특정 프로젝트 재현용 몇 개도 전부 이런 상황이다 — 문제가 해결된 그날이 곧 그것이 퇴역하는 날이었다, 하지만 그것은 계속 상주 디렉터리에 누워 있으면서 심력을 차지하고 있었다.

이 유형이 가장 헷갈리는데, 왜냐하면 그것은 「쓴 적 있고, 게다가 잘 썼기」 때문이다. 이것을 판정하려면 물어야 할 것은 「좋은가」가 아니라 「같은 문제가 얼마나 자주 나타나는가」다. 1년에 한 번 나오는 문제라면, 꺼내 쓰는 방식의 해법 하나로 충분하고, 상주시킬 필요는 없다.

죽음의 방식 3: 저빈도 포맷 변환형

docx, pdf, pptx 몇 개는 30일 동안 총 1번 쓰였다. 안 쓰인 게 아니라, 사용 빈도가 상주를 지탱하지 못하는 것이다.

이 유형은 내가 가장 단호하게 처리했다: 냉궁. 쓸 때 다시 설치하는 것은 30초면 되는 일이고, 상주의 대가는 매번 Skill 목록을 나열할 때마다 내가 머릿속으로 「이게 뭐 하는 거였지」를 한 번 훑어야 한다는 것이다. 저빈도 도구의 저장 비용은 디스크가 아니라 주의력이다.

죽음의 방식 4: 기능 중복형

점검 중에 두 개의 Skill 기능이 거의 중복된다는 것을 발견했는데, 둘 다 「새로운 Skill을 하나 생성」하는 스캐폴딩이었다. 하나는 플랫폼 자체 내장, 하나는 내가 나중에 커뮤니티에서 설치한 것이다. 커뮤니티 버전은 설치하고 나서 내가 잊어버렸고, 그 후 모든 신규 생성 동작은 내장된 그것을 사용했다.

중복 기능에 전환 비용이 없을 때, 당신은 먼저 익숙해진 것만 쓴다. 두 번째 것을 설치한 그 순간, 그것의 운명은 이미 정해져 있었다.

三、남은 6개, 모두 같은 하나의 특징이 있다

먼저 명단을 보자:

Skill 30일 증거 트리거 시점 블로그 파이프라인 35회 호출 매일 아침 9시 정시 메시지 푸시 CLI 로그 제로 호출(CLI 직접 실행) 매일 조간 브리핑 발송 후 문체 처리 1회 호출 매번 발행 전 표 처리 1회 호출 매번 고객 납품 시 UI 산출 2회 호출 매번 이미지 생성 시 회고 일기 로그 제로 호출(산출물이 다른 곳에 있음) 격일 1회

막 점검을 마쳤을 때 나는 결론이 「남은 것은 기능이 가장 강한 것들」일 거라고 생각했다. 전혀 아니다. 이 6개 중 3개는 기능이 매우 단일하고, 심지어 두 개는 호출 로그에 아예 존재하지도 않는다.

그것들의 진짜 공통점은 단 하나다: 하나같이 스스로 발생하는 흐름 속에 박혀 있다.

- 블로그 파이프라인은 매일 아침 9시의 정기 작업에 걸려 있어서, 내가 그것을 기억하든 말든 9시에 그것은 거기 있다

- 푸시 도구는 파이프라인의 마지막 고리라서, 조간 브리핑이 발송되면 반드시 그것의 차례가 온다

- 문체 처리와 표 처리는 각각 「발행일」「납품일」이라는 반드시 발생하는 두 노드에 묶여 있다

- 회고 일기는 「격일」이라는 리듬에 묶여 있다

다시 말해: 이 6개의 생존은 그것들이 얼마나 좋은지에 달려 있지 않고, 각자 하나의 숙주 흐름이 있느냐에 달려 있다. 흐름이 시점이 되면 돌아가고, 거기까지 돌아가면 트리거된다. 반면 냉궁 속의 23개는 전부 숙주가 없다 — 그것들의 유일한 트리거 조건은 「내가 어느 날 갑자기 생각나는 것」이고, 사람은 결코 갑자기 생각나지 않는다.

이 판정 기준은 내가 예상했던 것보다 유용했다. 예전에는 도구 하나의 거취를 판단할 때 무의식적으로 「좋은가」「내가 필요한가」를 물었다 — 이 두 질문은 전부 주관식이라 답은 언제나 「혹시 쓸모가 있지 않을까」였다. 「숙주 흐름이 있는가」로 바꾸면 객관식이 되어, 30일 로그를 한 번 훑으면 바로 알 수 있다.

四、세 가지 질문 판정표(오늘 밤 바로 사용 가능)

위의 것들을 한 장의 표로 수렴한다. 어떤 Skill이든, 세 가지 질문을 한다:

질문 어떻게 확인하나 위험 신호 1. 지난 30일 동안 실제 트리거가 몇 번 있었나? 호출 로그(CLI 직접 실행과 외부 산출물은 0으로 치지 않도록 주의) 0회, 또는 겨우 1회 2. 고정된 트리거 시점이 있나? 정기 작업/흐름 단계/주기적 노드에 걸려 있는가 트리거 조건이 「내가 주동적으로 생각나는 것」 3. 그 출력이 고정 산출물로 들어가나? 글, 표, 코드 저장소, 보고서에서 그 흔적을 찾을 수 있는가 출력이 어떤 다운스트림에서도 소비되지 않음

세 질문이 전부 빨간불이면, 냉궁으로. 두 개 이상 빨간불이면, 관찰 표시를 하고 다음 달 점검에서 다시 판정한다.

두 가지 패치:

- 로그는 거짓말을 한다. CLI 직접 실행 도구는 Skill 채널을 거치지 않고, 어떤 산출물은 다른 디렉터리에 떨어진다. 트리거 데이터는 세 개의 선을 교차 검증해야 한다: 호출 로그, 터미널 기록, 산출물 역추적. 어느 하나만 보면 좋은 Skill을 억울하게 만든다.

- 외톨이 트리거는 살아 있는 것으로 치지 않는다. 30일 동안 1번 쓰인 것은 0번과 본질적 차이가 없다 — 그것은 「일회성 작업 잔여물」이지, 사용이 아니다. 내 냉궁에도 이런 것이 3개 있다: 확실히 썼고, 좋았고, 하지만 그 일은 끝났다.

五、나는 「전부 비우기」파에 서지 않는다

이 글을 쓰기 전에 나는 다른 사람들은 이 문제를 어떻게 처리하는지 좀 봤는데, 대략 두 파로 나뉜다.

한 파는 반년마다 설정을 전부 비우자고 주장한다, 컨텍스트 파일에 Skill에 훅까지 함께 비우자고, 이유는 「모델이 스스로 방법을 찾을 것이고, 비우면 다시 자라날 것」이다. 이 사고방식은 순수 채팅 시나리오에서는 성립할 수도 있다. 하지만 내 파이프라인은 안 된다 — 그 6개의 숙주 Skill을 비우면, 매일 아침 9시의 정기 작업이 바로 헛돌고, 로그와 팬 데이터가 당일로 끊긴다. 비우기의 전제는 당신에게 그것에 의존하는 자동화가 전혀 없다는 것이다. 파이프라인이 있는 사람이 비우면, 태워지는 것은 중복이 아니라, 알을 낳고 있는 닭이다.

다른 한 파는 사재기파다, 28.8만 Star 저장소를 보면 설치하고 싶고, 「반드시 설치해야 할 10개」를 보면 다 갖추고 싶다. Superpowers는 지금 28.8만 Star, Anthropic 공식 Skill 라이브러리는 17.7만 Star, 생태계는 확실히 번영하고 있다 — 하지만 생태계의 번영은 공급 측의 번영이고, 내 하드디스크에 몇 개를 설치해야 하는지와는 관계가 없다. 100개의 Skill을 수집하는 것과 100개의 Skill을 습득하는 것 사이에는, 100개의 숙주 흐름이 가로놓여 있다.

나는 중간에 선다: 숙주 흐름으로 거취를 판정하고, 보관하되 삭제하지 않는다. 냉궁은 그냥 평범한 폴더이고, 23개의 Skill이 원래 모습 그대로 그 안에 누워 있으며, SKILL.md 하나도 삭제하지 않았다. 언젠가 정말 새로운 흐름이 어떤 기술을 필요로 하면, 30초 만에 다시 옮겨온다. 삭제는 감정적인 의식이고, 보관은 공학적인 결정이다 — 가역적이며, 깊은 정을 담지 않는다.

六、마지막에 쓰며

이번 점검에서 가장 큰 수확은 목록이 짧아진 것이 아니라, 그 판정 기준이다: 도구의 생존은 그것의 품질이나 나의 자율성에 달려서는 안 되고, 그것에 자동으로 발생하는 흐름이 숙주로 있는지에 달려야 한다.

반대로 말하면, 좋은 도구를 남기고 싶다면, 그냥 「설치」하는 것은 소용없고, 그것에 파이프라인 하나를 놓아줘서 스스로 그것을 반드시 써야 하는 위치까지 돌아가게 해야 한다. 내가 남긴 6개 중, 각각의 뒤에는 내가 먼저 흐름을 세우고 나서 그것이 자리를 얻은 것이다.

당신은 자신의 Skill 라이브러리가 있나? 오늘 밤 한 번 훑어보고, 댓글로 숫자를 알려달라: 몇 개를 설치했는지, 30일 제로 트리거가 몇 개인지. 나는 이 두 숫자의 격차가 대부분 사람들이 인정하고 싶어 하는 것보다 클 것이라고 생각한다.