AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다.

그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다.

스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다.

만든 만큼 쳐내야 자산으로 남는다.

스킬은 자산으로 시작한다, 그런데

요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다.

제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다.

스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다.

결과도 매번 일정해진다. 그래서 다들 쌓는다.

그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다.

skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다.

자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다.

여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가.

다음 중 하나라도 있나

비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다.

스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다.

내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다.

셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다.

신호 1 — 어느 스킬이 뜰지 예측이 안 된다

스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다.

그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점검을 매 턴 강제하는 구조가 그 대가다.

스킬 하나하나는 잘 돈다. 문제는 그 사이의 경합이다.

개수가 늘수록 경합의 가짓수도 늘어난다. 잘 도는 부품을 많이 모았는데, 부품끼리 서로 밀친다.

신호 2 — 도구 출력이 컨텍스트를 먹는다

스킬이 부르는 도구는 출력을 컨텍스트에 쏟는다. 검색 결과, 로그, 파일 내용이 다 들어온다.

스킬이 많을수록 이 출력이 쌓여, 정작 작업할 공간을 밀어낸다.

이게 개인 취향 문제가 아니라는 증거가 있다. context-mode라는 도구는 “도구 출력을 98% 줄인다”고 소개하며 Hacker News 1위에 올랐다.

98%가 실제 수치인지는 그쪽 주장이라 확인하지 않았다. 다만 이런 걸 파는 제품이 1위에 오른다는 것 자체가, 출력이 컨텍스트를 잡아먹는 문제가 그만큼 흔하다는 뜻이다.

Q. 스킬이 많으면 왜 응답이 굼떠지나.
A. 스킬 수 자체보다, 스킬이 부르는 도구의 출력이 컨텍스트를 채우기 때문이다. 모델이 매번 읽어야 할 양이 늘고, 정작 중요한 맥락은 뒤로 밀린다.

신호 3 — 모델이 바뀌면 전부 다시 만진다

모델을 새 버전으로 올리면 지시를 해석하는 방식이 달라진다. 옛 모델의 느슨함을 이기려고 써둔 “반드시 X해라” 같은 압박 표현이, 새 모델에선 오발동을 만든다.

도구를 과하게 부르고 사소한 것마다 되묻는다.

스킬이 하나면 한 번 고치면 된다. 수십 개면 수십 번이다.

개수가 곧 다시 만져야 할 표면적이다. 모델 업그레이드 한 번이 스킬 전수 점검으로 번진다.

더 불편한 신호는 따로 있다. 쌓다 보면 자기가 뭘 만들어뒀는지 목록 없이는 못 센다.

못 세는 자산은 관리되지 않는 자산이다. 지난번 설정 감사에서 죽은 참조가 그렇게 많이 쌓여 있던 것도, 표면이 커져 추적이 안 됐기 때문이다.

손익분기 — 만들지 마라가 아니라 쳐내라

오해는 없어야 한다. 스킬이 나쁘다는 게 아니다.

처음 몇 개는 순자산이다. 반복을 지우는 값이 관리 비용을 크게 웃돈다.

문제는 손익분기다. 어느 수를 넘으면 새 스킬이 버는 값보다 전체를 유지하는 값이 커진다.

그 임계는 사람마다 도구마다 다르다. 내 임계가 남의 임계가 아니다.

그래서 답은 “만들지 마라”가 아니라 “만든 만큼 쳐내라”다. 코드에서 죽은 코드를 지우듯, 스킬도 정기적으로 센다.

한 달간 안 쓴 건 지운다. 트리거가 겹치는 둘은 하나로 합친다.

목록을 봐야 기억나는 스킬은 이미 지울 후보다.

오늘 할 일은 하나다. 스킬 목록을 열어, 최근 한 달 안 쓴 걸 세어보는 것.

그 수가 곧 갚아야 할 부채다.

관련 글

• AI 코딩 설정도 코드처럼 썩는다 — 가짜 보안 훅과 죽은 에이전트 11개 — 이 글이 “비대”라면 저건 “부패”. 방치된 스킬이 죽는 쪽
• 프롬프트 엔지니어링·에이전트·하네스, 무엇이 다른가
• MCP냐 CLI냐 — 에이전트에 도구 붙이는 방식 실측

---

글쓴이 — Jason 황재승

cd4761.blogspot.com에서 AI 도구 운영과 자동화 기록을 쓴다. 8년 차 프론트엔드.

스킬을 만드는 재미보다, 만든 걸 쳐내는 규율이 더 어렵다는 걸 매번 확인한다. 이 글의 도구·트렌드 관찰은 2026년 7월 기준이다.

태그: #AI코딩스킬 #스킬과잉 #ClaudeCode #컨텍스트관리 #스킬관리 #에이전트 #개발자동화