맥락에 따른 예산 책정을 진지하게 고려하는 사람들은 단순히 스킬을 무작정 쌓는 사람들보다 AI 지원 경험을 훨씬 더 잘 얻을 수 있을 것입니다.

기사 작성자 및 출처: 0x9999in1, ME News

요약

• 현재 주류 AI 프로그래밍 보조 기능/플러그인 생태계는 "급성장 후 소화불량"을 겪고 있습니다. 반복적이고 불필요하며 더 이상 사용되지 않는 기능들이 쌓여 귀중한 컨텍스트 창을 심각하게 잠식하고 있습니다.
• Lobster Dad는 Skills에 대한 "전체 점검"을 수행하도록 특별히 설계된 메타 스킬을 오픈 소스로 공개했습니다. 이 스킬은 예산 감사, 중복 감지, 유휴 항목 검사, 루트 디렉터리 감사 및 설명 간소화라는 다섯 가지 핵심 기능을 다룹니다.
• 컨텍스트 창은 대규모 AI 모델에서 가장 부족한 자원 중 하나입니다. 불필요한 스킬이 존재할 때마다 실제로 필요한 추론 공간을 의미 없는 토큰으로 차지하는 셈입니다.
• 이 도구의 핵심 가치는 "또 다른 기술"을 습득하는 것이 아니라, 하나의 기술로 모든 기술을 관리하는 데 있으며, 이는 인프라 수준에서 발휘됩니다.
• 스킬 생태계의 혼란은 단지 개별적인 현상이 아니라 구조적인 문제입니다. 감사 메커니즘이 없는 플러그인 시스템은 결국 엔트로피 증가로 이어질 것입니다.
• 오픈 소스는 커뮤니티가 이 기반 위에서 반복적으로 개선해 나갈 수 있음을 의미하며, 이는 스킬 거버넌스의 표준화를 위한 출발점이 될 수 있습니다.

먼저 현재 상황에 대해 이야기해 보겠습니다. 여러분의 스킬 인벤토리는 이미 쓸모없는 아이템들로 가득 차 있을지도 모릅니다.

그렇게 말하는 건 좀 냉정하게 들릴 수도 있지만, AI 비서 설정에 들어가서 설치된 스킬이 몇 개인지 세어보고, 마지막으로 어떤 스킬을 사용했는지 생각해 보세요.

그 답을 들으면 아마 말문이 막힐 겁니다.

2025년 하반기부터 Cursor, Windsurf, Codex, Claude Code와 같은 AI 프로그래밍 도구들은 집단적으로 "기술 경쟁"에 돌입할 것입니다. 커뮤니티 참여자들은 엄청난 양의 콘텐츠를 생산하고, 공식 내장 라이브러리는 계속 확장되며, 개인 설정은 서로 겹겹이 쌓여갈 것입니다.

그 결과는 어땠을까요?

일반적인 헤비 유저는 50개 이상의 스킬을 보유하는 경우가 흔합니다. 하지만 실제로 매일 사용하는 스킬은 10개도 채 되지 않습니다. 나머지 40개는 대화가 시작될 때마다 컨텍스트에 조용히 로드되어 토큰 예산을 소모할 뿐, 아무런 기능도 하지 않습니다.

이건 낭비가 아니야. 이건 범죄야.

왜 이렇게 말하는 걸까요? 컨텍스트 창이 무한하지 않기 때문입니다. 2026년에도 주류 모델의 유효 컨텍스트 길이는 12만 8천에서 20만 토큰 사이일 것입니다. 많아 보이죠? 하지만 계산해 보세요. 시스템 메시지, 대화 기록, 코드 조각, 파일 내용, 도구 정의, 스킬 설명 등... 실제로 "생각"할 수 있는 공간은 생각보다 훨씬 적습니다.

쓸모없는 스킬 설명 텍스트 하나당 200 토큰이 소모됩니다. 50개가 추가되면 총 10,000 토큰이 됩니다. 10,000 토큰이면 모델이 추가로 400줄의 코드를 읽을 수 있습니다.

이것은 이론적인 추론이 아닙니다. 이것은 매일 일어나는 일입니다.

왜 아무도 이 문제를 해결하지 않는 걸까요? 덧셈이 뺄셈보다 백만 배는 쉽기 때문입니다.

인간에게는 덧셈 편향이라는 뿌리 깊은 심리적 편향이 있습니다.

우리는 문제 대면 본능적으로 "무언가를 빼는 것"보다는 "무언가를 더하는 것"을 생각합니다. 2021년 네이처(Nature)에 발표된 한 연구는 인간이 무언가를 개선할 때, 비록 빼는 것이 더 효과적일지라도 "빼는 해결책"을 체계적으로 무시한다는 점을 명확히 지적합니다.

스킬 생태계는 이러한 편차를 완벽하게 재현합니다.

커뮤니티 기여자가 새로운 스킬을 개발하여 공개했습니다. 사용자들은 "유용할 수도 있겠다"라고 생각하며 설치했습니다. 공식 개발팀은 "다양한 기능을 갖추고 있군"이라고 판단하여 게임에 추가했습니다.

누가 그것들을 삭제할까요? 누가 감사 할까요? 누가 "이 스킬은 저 스킬과 중복되니 하나를 삭제하세요"라고 말할까요?

아무도 없습니다.

오래된 스킬을 삭제해도 아무런 보상이 없습니다. 새로운 스킬을 습득하면 별점, 커뮤니티 인정, 그리고 이력서에 추가할 수 있는 자격을 얻게 됩니다. 하지만 오래된 스킬을 삭제하면 아무것도 얻을 수 없습니다.

이것은 구조적인 문제입니다. 기술적인 문제가 아니라, 인센티브 메커니즘의 문제입니다.

누군가가 "동기 부여 같은 건 신경 안 써, 그냥 할 거야"라고 결심할 때까지는 말이죠.

바닷가재의 아버지가 행동에 나선다: 하나의 기술로 모든 기술을 지배하라.

"랍스터의 아버지"는 누구일까요? AI 프로그래밍 도구 커뮤니티를 자주 이용하신다면 이 아이디를 잘 아실 겁니다. Codex와 Claude 생태계에서 오랫동안 활발하게 활동해 온 그는 체계적인 사고방식과 꼼꼼한 엔지니어링 접근 방식으로 유명합니다. "랍스터의 아버지"라는 칭호 자체는 커뮤니티 내에서 높은 인정을 받고 있으며, 특정 분야에서 없어서는 안 될 인물임을 의미합니다.

그가 이번에 오픈소스로 공개한 것은 본질적으로 메타 스킬 입니다 .

메타 스킬이란 무엇일까요? 바로 "스킬을 관리하는 스킬"입니다. 코드를 작성하거나 API를 호출하거나 문서를 생성해주는 스킬은 아닙니다. 메타 스킬은 오직 한 가지 기능만 수행합니다. 바로 여러분이 보유한 모든 스킬을 철저하고 정량화 가능하며 실질적인 실행 가능한 수준으로 점검해주는 것입니다.

다섯 가지 주요 기능은 각각 자세히 설명되어 있습니다.

기능 1: 스킬 힌트 예산 감사

이건 가장 하드코어한 버전입니다.

이 도구의 기능은 매우 간단합니다. 각 스킬이 차지하는 컨텍스트 토큰 공간을 계산하고, 각 스킬이 전체 예산에서 차지하는 비율을 파악한 다음, 최적화 방안을 제시합니다.

왜 이것이 중요할까요? 대다수의 사용자는 Skill이 실제로 얼마나 많은 리소스를 소모하는지 전혀 모르기 때문입니다.

스킬을 설치하는 것은 단순히 기능 하나를 추가하는 것이라고 생각할 수도 있습니다. 하지만 실제로는 각 스킬의 설명, 매개변수 정의, 샘플 코드, 트리거 규칙 등을 모두 시스템 프롬프트에 입력해야 합니다. 모델은 각 추론 반복에서 스킬을 호출할지 여부를 결정하기 전에 이 모든 정보를 "읽어"야 합니다.

마치 장비 50개를 가득 채운 배낭을 메고 다니는 것과 같아요. 처음에는 "그럴 만한 가치가 있어"라고 생각하지만, 무게가 1kg 늘어날 때마다 더 많은 에너지를 소모하게 되죠. 결국 전력 질주해야 할 때쯤이면 이미 녹초가 되어 있을 거예요.

예산 감사 란 당신의 배낭을 열어보고 "이 스위스 아미 나이프는 무게가 3kg이나 나가지만 한 번도 사용한 적이 없으니 버리세요"라고 말하는 것과 같습니다.

기능 2: 반복적인 기술 감지

이 기능이 해결하는 문제는 생각보다 더 심각할 수 있습니다.

스캔 범위는 4단계에 걸쳐 있습니다.

• Codex 내장 라이브러리
• 플러그인 캐시
• 코드 라이브러리
• 개인 기술 루트 디렉토리

레벨 전반에 걸쳐 이름이 같거나 설명이 비슷하거나 기능이 겹치는 스킬을 찾아 중복되는 항목을 태그.

왜 반복되는 부분이 있을까요? 이유는 여러 가지입니다.

공식 문서에는 내장된 "코드 서식 지정" 기능이 포함되어 있지만, 거의 동일한 기능을 하는 또 다른 기능이 커뮤니티에서 추가되었다는 사실은 모를 수도 있습니다. 같은 기능을 하는 두 개의 기능이 두 개의 예산을 소모하는 셈입니다.

또는 좀 더 미묘하게 말하자면, 6개월 전에 JSON 파싱을 처리하는 사용자 지정 스킬을 만들었는데, 나중에 공식 라이브러리가 업데이트되면서 더 나은 기능이 추가되었습니다. 이전 버전은 여전히 ​​남아 있고, 아무도 삭제하라고 알려주지 않았습니다.

중복 항목 감지는 단순히 이름만 확인하는 것이 아닙니다. 이름은 다르지만 설명이 매우 유사한 항목도 감지합니다. 이는 단순한 문자열 일치가 아닌 의미적 유사성 비교를 수행하는 진정한 기술적 부분입니다.

기능 3: 미사용 기술 선별

과거 기록을 바탕으로 오랫동안 사용되지 않은 "좀비 스킬"을 식별합니다.

논리는 명확합니다. 지난 30일, 60일 또는 90일 동안 스킬이 한 번도 사용되지 않았다면 다음 두 가지 중 하나를 의미할 가능성이 높습니다. 워크플로에 해당 스킬이 필요하지 않거나, 트리거 조건이 잘못 설계되어 모델이 해당 스킬을 선택하지 않는 것입니다.

어느 쪽이든 결론은 같습니다. 예산을 낭비하는 것입니다.

이 기능은 "깔끔하게 정리된 후보 목록"을 출력합니다. 여기서 "후보 목록"은 직접적인 삭제를 의미하는 것이 아니라, 최종 결정은 사용자에게 달려 있습니다. 이 디자인은 절제되고 영리하며, 자신의 한계를 명확히 인식하고 있습니다.

일부 기술은 사용 빈도는 낮지만 매우 중요합니다. 예를 들어, "데이터베이스 마이그레이션 지원"은 3개월에 한 번 정도만 사용될 수 있지만, 필요할 때 매우 유용할 수 있습니다. 따라서 선별 결과는 판단 기준이 아닌 참고 자료로 활용해야 합니다.

기능 4: 스킬 루트 디렉토리 감사

이 기능은 "운영 및 유지 관리" 쪽에 가깝지만 매우 유용합니다.

이 도구는 모든 스킬의 소스 디렉터리 수를 세고, 활성화/비활성화 상태를 표시하며, 로딩 과정을 추적합니다.

왜 이것이 필요할까요? 스킬은 다양한 소스에서 제공되기 때문입니다. 일부는 전역 설정에서, 일부는 프로젝트 수준 설정에서, 일부는 자동 플러그인 삽입에서, 그리고 일부는 수동 사용자 생성에서 제공됩니다.

스킬 개수가 적을 때는 상황을 파악하기 쉽지만, 수십 개로 늘어나면 "이 스킬은 어디서 얻었는지", "안전하게 삭제할 수 있는지", "삭제하면 다른 것에 영향을 미치는지"를 파악하기 어려워집니다.

루트 디렉터리 감사 마치 지도를 그려주는 것과 같습니다. 각 스킬이 어디에 있는지, 누가 로드했는지, 그리고 현재 활성화 상태인지 비활성화 상태인지 알려줍니다.

이 지도를 이용하면 안전하게 수술을 진행할 수 있습니다.

기능 5: 설명 간소화 및 최적화

마지막 기능은 가장 "작아" 보이지만 실제로는 엄청난 영향력을 발휘합니다.

이 도구는 설명이 지나치게 긴 기술을 식별하고 간결한 해결책을 제시합니다.

스킬 설명 길이가 왜 그렇게 중요할까요? 앞서 언급했듯이 스킬 설명은 시스템 프롬프트에 포함됩니다. 각 단어는 토큰입니다. 스킬 설명을 200개의 토큰에서 80개의 토큰으로 압축할 수 있다면, 절약되는 공간은 스킬 개수에 따라 상당한 양이 됩니다.

커뮤니티에서 제공하는 많은 기술들은 마치 학술 논문 초록처럼 배경, 동기, 적용 시나리오, 주의사항, 예시 입력 및 출력 등 매우 상세하게 설명되어 있습니다. 작성자들은 많은 노력을 기울였지만, 엔지니어링 관점에서 보면 이는 과도한 설계입니다.

모델에 필요한 설명은 정확하고, 독창적이며, 구별 가능해야 합니다. 모델이 "이 스킬이 무엇을 하고 언제 사용해야 하는지" 이해할 수 있도록 최소한의 단어만 사용하는 것으로 충분합니다. 불필요한 단어는 맥락적 자원을 낭비하는 것입니다.

설명을 간소화하는 기능은 본질적으로 "프롬프트 엔지니어링의 역 최적화"입니다. 즉, 더 나은 프롬프트를 작성하는 것이 아니라 기존 프롬프트를 정보 손실 없이 더 짧게 압축하는 것입니다.

그것의 가치는 어디에 있을까요? 기능성에 있는 것이 아니라, 사고방식에 있습니다.

다섯 가지 기능은 다음과 같이 세분화되었습니다. 개별적으로 보면 어느 기능도 특별히 획기적으로 보이지 않습니다. 그러나 이 기능들을 결합하면 사고방식의 패러다임 전환을 의미합니다.

"더 많은 기술을 창출하는 것"에서 "기존 기술을 관리하는 것"으로.

이 문제의 중요성은 코드의 양이나 알고리즘의 복잡성에 있는 것이 아니라, 마침내 누군가가 이 문제를 "일류 문제"로 다루기 시작했다는 사실에 있습니다.

지난 2년간 AI 도구 생태계는 오로지 "기능 추가"에만 집중해 왔습니다. 더 많은 모델, 더 많은 기능, 더 많은 플러그인, 그리고 더 많은 스킬들이 빠르게, 그리고 공격적으로 발전해 왔고, 뒤돌아보는 사람은 아무도 없었습니다.

하지만 엔지니어링 경험이 있는 사람이라면 누구나 시스템의 복잡성이 일정 수준 이상으로 증가하면 그에 상응하는 관리 메커니즘이 없으면 시스템이 붕괴될 것이라는 사실을 알고 있습니다.

가능성이 아니라, 확실하다.

소프트웨어 엔지니어링에는 "기술 부채"라는 개념이 있습니다. 모든 임시방편적인 해결책, "일단 여기까지 하자"라는 결정, 남아있는 모든 중복 코드는 일종의 부채입니다. 빌리는 것이 많을수록 이자도 커지다가, 결국 모든 에너지를 빚 갚는 데 쏟아붓느라 새로운 것을 할 에너지가 남지 않게 되는 것입니다.

스킬 생태계 내의 기술적 부채가 해결해야 할 시점에 이르렀습니다.

바닷가재의 아버지라고 불리는 사람이 설명한 도구는 본질적으로 채무 감사 입니다 . 빚을 갚는 데 직접적인 도움을 주지는 않지만, 빚의 액수, 빚의 출처, 그리고 어떤 빚을 먼저 갚아야 하는지를 알려줍니다.

이는 "유용한 기술을 하나 더 익혔다"는 말보다 훨씬 더 가치 있는 일입니다.

오픈 소스의 중요성: 개인용 도구부터 커뮤니티 표준까지

바닷가재의 아버지가 오픈소스를 채택한 결정 자체는 논의해 볼 가치가 있다.

그는 이 도구를 유료 플러그인으로 쉽게 만들 수도 있었습니다. 시장 수요는 분명했고, 문제점은 실재했으며, 유료 사용자도 부족하지 않았을 것입니다. 하지만 그는 오픈 소스로 공개하기로 결정했습니다.

왜?

제 생각에는 두 가지 고려 사항이 있는 것 같습니다.

첫 번째 단계: 이 도구가 진정한 가치를 발휘하려면 커뮤니티 협력이 필수적입니다. 다양한 AI 플랫폼은 스킬 로딩 메커니즘, 로그 형식, 디렉토리 구조가 서로 다릅니다. 한 사람이 모든 것을 조정하기는 어려울 수 있지만, 100명의 기여자가 함께라면 가능합니다.

두 번째 측면: 그는 단순히 도구가 아닌 표준을 홍보하고 싶어할 수도 있습니다 . 스킬 관리 체계는 어떻게 운영되어야 할까요? 감사 범위는 어떻게 설정해야 할까요? 예산 배분을 위한 최적의 방법은 무엇일까요? 이러한 질문에 대한 답을 찾으려면 커뮤니티의 합의가 필요합니다.

오픈 소스는 합의에 도달하는 가장 좋은 방법입니다.

소프트웨어 엔지니어링의 역사를 되돌아보면, ESLint는 자바스크립트 코드 스타일의 사실상 표준이 되었고, Black은 파이썬 포맷팅의 표준이 되었으며, Prettier는 프런트엔드 코드 스타일의 표준이 되었습니다. 이는 오픈 소스 덕분에 커뮤니티가 규칙 제정에 참여할 수 있었기 때문입니다.

"랍스터의 아버지" 메타 스킬이 스킬 관리를 위한 ESLint로 등록될 수 있을까요?

지금 판단하기에는 너무 이르지만, 방향은 올바릅니다.

더 근본적인 질문은 이것입니다. 스킬 시스템 자체를 재설계해야 할까요?

감사 도구는 기존 문제를 해결합니다. 하지만 관점을 넓히면 더욱 근본적인 문제를 발견하게 될 것입니다.

스킬은 왜 통제 불능 상태가 되었을까요?

답은 간단합니다. 현재의 스킬 시스템에는 생명주기 관리 기능이 부족합니다.

스킬이 생성되면 영구적으로 존재합니다. 만료 메커니즘도 없고, 버전 삭제도 없으며, 활동 감소도 없습니다. 마치 누군가가 수동으로 종료할 때까지 리소스를 계속 점유하는, 절대 끝나지 않는 프로세스와 같습니다.

운영 체제의 프로세스 관리와 비교해 보세요. 운영 체제는 생성, 스케줄링, 최대 절전 모드, 종료를 포함하며, 완전한 폐쇄 루프 생명주기를 가지고 있습니다.

패키지 관리자의 의존성 관리 방식을 비교해 보겠습니다. npm audit 보안 취약점을 검사하고, npm outdated 만료된 의존성을 확인하며, npm prune 사용되지 않는 패키지를 정리합니다. 거버넌스 도구는 이러한 생태계의 일부입니다.

스킬 시스템은 어떻습니까? 생성 → 사용 → ...이게 전부인가요? 대량 단계가 빠져 있습니다.

바닷가재의 아버지라고 불리는 사람이 개발한 도구들은 본질적으로 시스템 설계 의 결함을 보완하기 위해 외부 도구를 사용하는 것입니다 . 이러한 도구들은 유용하지만, 동시에 기술 관리 분야에서 AI 도구 플랫폼을 위한 인프라가 아직 초기 단계에 있음을 드러냅니다.

이건 비판이 아닙니다. 필연적인 발전 과정입니다. 2024년부터 2025년까지 플랫폼의 주요 목표는 "생태계를 가동시키는 것"이었고, 거버넌스는 나중에 다룰 예정이었습니다. 하지만 2026년 중반쯤 되면 생태계는 이미 가동되고 있을 겁니다. 이제는 따라잡아야 할 때입니다.

결론적으로

원래 질문으로 돌아가서, 여러분의 AI 비서에서 실제로 활성화된 기능은 몇 개나 될까요?

질문에 답할 수 없다면 신체검사를 받아야 한다는 뜻입니다.

바닷가재의 아버지께서 도구를 제공해 주셨습니다. 무료입니다. 오픈 소스입니다. 5가지 차원, 포괄적인 분석.

사용 여부는 당신의 자유입니다.

하지만 한 가지는 확실합니다. 맥락에 따른 예산 책정을 진지하게 고려하는 사람들은 단순히 스킬만 무턱대고 쌓는 사람들보다 AI 지원 경험을 훨씬 더 잘 얻게 될 것입니다.

인공지능은 전지전능하지 않기 때문입니다. 인공지능은 주의력, 기억력, 추론 능력에 한계가 있습니다. 따라서 제공하는 정보가 정확하고 깔끔할수록 더 나은 결과를 도출합니다.

이건 형이상학이 아닙니다. 이건 정보 이론입니다.

섀넌은 이미 1948년에 채널 용량에는 한계가 있으며, 잡음이 많을수록 정보 전송 속도가 낮아진다고 말했습니다.

스킬 목록에 있는 좀비 관련 스킬들은 그냥 의미 없는 것들이에요.

그들을 죽여라.

참고 자료

1. Adams, GS, Converse, BA, Hales, AH, & Klotz, LE (2021). 사람들은 체계적으로 감산 변화를 간과합니다. Nature , 592(7853), 258–261.
2. Shannon, CE (1948). 통신에 대한 수학적 이론. Bell System Technical Journal , 27(3), 379–423.
3. OpenAI. (2024). GPT-4 Turbo 컨텍스트 윈도우 및 토큰 제한 문서. https://platform.openai.com/docs/models
4. Anthropic. (2025). Claude 모델 카드: 컨텍스트 창 활용 및 시스템 프롬프트 오버헤드. https://docs.anthropic.com/en/docs/about-claude/models
5. Cursor 팀. (2025). 규칙 및 기술: 사용자 지정 지침이 컨텍스트에 로드되는 방법. Cursor 문서.
6. npm 문서. (2025). npm-audit, npm-prune: 패키지 생명주기 관리. https://docs.npmjs.com/cli
7. 바닷가재의 아버지. (2026). 스킬 건강 점검 메타 스킬 [오픈 소스 프로젝트]. GitHub 저장소.
8. Sculley, D., et al. (2015). 기계 학습 시스템의 숨겨진 기술 부채. 신경 정보 처리 시스템의 발전(NeurIPS) , 28.