등록된 스킬이 30개를 넘어가면서, 저조차도 이름을 기억할 수 없게 되었습니다.

AI 코딩 CLI (Claude Code나 Codex 등)에는 정형화된 작업을 절차서로 만든 “스킬 (Skill)”을 심어둘 수 있습니다. 기사 쓰기, 아이콘 만들기, 릴리스하기 등. 편리해서 계속 늘려가다 보니, 막상 사용할 때 “어라, 기사 쓰는 게 이름이 뭐였더라?”라며 직접 만든 것을 찾아 헤매는 상황이 발생했습니다.

매번 스킬 이름을 정확하게 입력하는 것이 은근히 번거로웠던 것입니다.

결국 이렇게 해결했다

먼저 결론부터 말씀드리겠습니다. 제가 한 일은, “현재 대화 흐름에 어울릴 법한 스킬을, 유사도와 근거가 포함된 번호 리스트로 출력하여 선택만 하면 되게끔” 만드는 라우터 (Router)를 하나 제작한 것입니다.

동작 방식은 다음과 같습니다.

> S?
현재 상황에 어울리는 스킬:
1. write-article (높음): 「기사로 쓰고 싶다」가 실행어와 일치
...

S?라고 입력하기만 하면 됩니다. 그다음 번호를 선택하세요. 이름을 기억할 필요가 없습니다.

왜 “알림에 맡기는 방식”은 안 됐을까

처음에는 “AI가 문맥을 읽고 알아서 좋은 스킬을 제안해 주면 되지 않을까”라고 생각했습니다.

실제로 많은 CLI에는 “지금 이 스킬을 사용할 수 있습니다”라는 후보 알림 메커니즘이 있습니다. 하지만 이것이 매 턴(turn) 기계적으로 필터링되어 놓치는 경우가 생깁니다. 과거에 “HTML로 설명해 줘”라고 요청했는데, HTML 작성용 스킬이 알림에 뜨지 않아 AI가 처음부터 HTML을 직접 쓰기 시작한 적이 있었습니다.

알림은 믿을 수 없습니다. 그렇다고 매 턴 “후보를 대조하라”는 명령을 삽입하는 훅 (Hook)을 걸면, 이번에는 무관한 입력에서도 판정이 실행되어 문맥에 노이즈가 쌓이게 됩니다.

그래서 능동적으로 “S?”라고 한마디 입력했을 때만 후보를 출력하는 반자동 방식으로 타협했습니다. 입력하는 수고는 거의 제로에 가깝고, 필요 없을 때는 조용히 있습니다. 딱 적당한 균형이었습니다.

정밀해 보이는 “적합도 숫자”를 포기한 이야기

처음에는 후보에 마치 정밀해 보이는 퍼센트(%) 숫자를 붙였습니다. 하지만 작성하다 보니 깨달았습니다. 이거, 계산하는 게 아니라는 것을요.

내용은 허무할 정도로 소박합니다. 스킬의 인덱스(실행어와 한 줄 설명이 나열된 표)를 읽고, 최근 대화와 의미적으로 대조하고 있을 뿐입니다. 점수를 내는 함수 같은 건 어디에도 없으며, AI가 “가깝네”, “멀네”라고 감각적으로 판단하고 있을 뿐입니다. 그것을 두 자리 숫자로 표현하면 실제보다 더 정확해 보일 뿐입니다. 오히려 가짜 같습니다.

그래서 숫자를 없앴습니다. 지금은 이 3단계로 운영합니다.

• 높음: 실행어가 거의 그대로 포함되어 있거나, 거의 유사한 표현임
• 중간: 의미는 맞지만 단어가 다름
• 낮음: 스치듯 관련됨. 이보다 낮은 단계는 출력하지 않음

그리고 반드시 “왜 그렇게 생각했는지”를 한 줄 덧붙입니다. “『기사로 쓰고 싶다』가 실행어와 일치”와 같이 말이죠. 숫자를 지우고 근거를 제시하도록 바꾸니, 훨씬 납득하며 선택할 수 있게 되었습니다.

위 그림처럼 단계는 대략 3개입니다. 숫자 대신 “왜 맞다고 생각했는지”를 반드시 덧붙이는 단순한 구조입니다.

“낮음”보다 낮은 단계는 잘라내는데, 이는 후보가 너무 많아지면 선택하는 쪽이 피로해지기 때문입니다. “일단 이것도...”라며 나열되면 결국 전부 다시 읽어야 합니다. 상위 2~5개로 압축한다는 제약이 은근히 효과적이었습니다.

가장 신경 쓴 부분은 “모든 CLI에서 동일하게 동작하는 것”

저는 Claude Code뿐만 아니라 Codex, Cursor, Grok, Copilot 등 여러 CLI를 오가며 사용합니다. 그래서 “Claude 전용 편리 기능”을 만들어봤자, 옆에 있는 CLI로 옮기는 순간 사용할 수 없게 되는 것이 가장 곤란했습니다.

여기서 효과를 본 것이, 스킬의 저장소를 한 곳으로 지정하고, 각 CLI에는 정션 (Junction, 디렉터리의 별칭 링크)을 통해 동일한 선반을 보여주는 방식이었습니다. 이는 이전부터 해오던 구성이었습니다.

skills/ ← 실체는 여기 한 곳
write-article/
make-icon/
...

선반은 하나이고, 거기서 여러 개의 선이 각 CLI로 뻗어 나가는 것이 이 구성의 핵심입니다. 책 한 권을 추가하면 모든 장소에 동시에 놓이게 됩니다.

덕분에 라우터 본체(SKILL.md 파일 하나)를 선반에 두는 것만으로 모든 CLI에 일제히 전달되었습니다. CLI마다 따로 작성할 필요가 없습니다. 추가한 뒤, 5개의 경로 모두에서 파일이 보이는지 확인하면 끝입니다.

실체는 하나로 유지하되, 입구는 각 CLI의 방식에 맞춘 형태입니다.

만들어보며 느낀 점

대단한 구현은 아닙니다. 제가 한 일은 "인덱스를 읽고, 유사도와 근거를 출력하여, 번호로 선택하게 한다"는 것뿐입니다. 새로운 라이브러리도, 훅 (Hook)도 사용하지 않았습니다.

그럼에도 불구하고, S?

라는 3스트로크(3-stroke)만으로 끝낼 수 있게 된 것만으로도, 스킬을 늘리는 것에 대한 심리적 장벽이 상당히 낮아졌습니다. "이름을 기억하지 못하면 호출할 수 없다"라는 제약이 사라지면, 도구는 순수하게 늘려 나갈 수 있습니다.

아직 유사도 판단은 직관에 의존하고 있고, 상위 몇 개까지 출력할지도 당분간 사용하면서 수정해 나갈 생각입니다. 완벽한 채점 로직을 만들기보다는, "대체로 맞고, 틀리면 번호로 다시 선택할 수 있다" 정도의 느슨함이 딱 적당하다는 생각도 듭니다.

도구를 만드는 것보다, 도구를 떠올리는 비용을 먼저 없앤다. 그런 작은 처방을 앞으로도 계속해 나가겠습니다.

※ 헤더 이미지와 인포그래픽은 AI (이미지 생성)로 작성했습니다.

※ 본문의 삽화도 AI (이미지 생성)로 작성했습니다.

작성자: ishizakahiroshi

군마 북부에서 보호 고양이 2마리와 함께 살고 있는 재택 엔지니어 (잡무 해결사)
X (업무 위탁·각종 상담은 이쪽으로):

백엔드·인프라·AI 연동 관련 업무 위탁 상담을 받고 있습니다. 풀 리모트 (Full-remote)입니다. 스팟(Spot)이나 주 2~3시간부터라도 환영하며, 다양한 프로젝트에 참여할 수 있다면 기쁘겠습니다. 이런 상담도 환영합니다.

Discussion