솔직히 말씀드리면 — 사람들이 AI 코딩 에이전트를 위한 "스킬 (skills)"을 구축하고 있다는 말을 처음 들었을 때, 저는 눈을 아주 세게 굴렸습니다. 솔직히 말해서, 또 다른 프롬프트 라이브러리인가요? 누군가 오픈 소스인 척 코스프레할 또 다른 .claude 파일인가요? 저는 이런 영화를 전에도 본 적이 있습니다. 2024년에는 그것을 "GPTs"라고 불렀고, 빠르게 사그라들었죠.

하지만 그 후 저는 수치를 지켜보기 시작했습니다.

단순히 스타(stars) 수뿐만이 아닙니다 — 물론 그 부분도 다루겠지만요. 제가 말하는 것은 사람들이 실제로 소프트웨어를 구축하는 방식의 **구조적 변화 (structural changes)**입니다. 좋은 README와 출시 트윗만으로는 꾸며낼 수 없는 그런 변화 말입니다.

Superpowers는 GitHub 스타 245,000개를 달성했습니다. 이것은 밈(meme) 프로젝트가 아닙니다. React보다 많고, Vue보다 많으며, Kubernetes보다도 많습니다. 제가 무엇을 말하려는지 이해하시겠습니까?

에이전트 하네스 시스템(agent harness system)인 ECC는 225,000 스타를 기록하고 있습니다. Andrej Karpathy의 스킬을 Claude Code용으로 재포장한 것은요? 5개월 만에 187,000 스타를 기록했습니다. Matt Pocock의 스킬은 155,000입니다. Garry Tan이 자신의 Claude Code 설정을 공개했을 때는 — 거의 즉시 119,000 스타를 기록했습니다.

그리고 가장 이상한 것은 무엇일까요? 토큰을 아끼기 위해 AI가 마치 석기 시대 사람처럼 말하게 만드는 스킬인 Caveman은 83,000 스타를 돌파했습니다. 당연히 그럴 줄 알았습니다.

여기서 무언가 일어나고 있습니다. 그리고 이것은 단순한 트렌드가 아닙니다.

"에이전트 스킬 (Agent Skill)"이란 실제로 무엇인가?

과장된 광고를 걷어내고 용어를 정의해 봅시다.

**에이전트 스킬 (agent skill)**은 구조화된 프롬프트 — 보통 CLAUDE.md 또는 AGENT.md 파일 — 로, AI 코딩 에이전트가 어떻게 행동할지를 결정합니다. 이것은 Claude Code에게 "React 컴포넌트를 작성해줘"라고 요청하는 것과, 프로젝트의 스타일, 제약 조건, 테스트 패턴 및 배포 워크플로우에 대한 전체 컨텍스트를 제공하는 것의 차이입니다. 이해가 되시나요?

하지만 이것을 "단순한 프롬프트"라고 부르는 것은 Kubernetes를 "단순한 YAML 파일"이라고 부르는 것과 같습니다. 추상화(abstraction)가 중요합니다.

진정한 스킬이 어떻게 생겼는지 보여드리겠습니다 (Matt Pocock의 리포지토리에서 가져옴):

~/.claude/skills/testing.md

당신은 다음의 테스트 규칙을 따릅니다:
...

무슨 뜻인지 아시겠죠?

간단하죠? 이제 이런 것들이 20개 정도 쌓여 있다고 상상해 보세요. 아키텍처(architecture), 배포(deployment), 데이터베이스 마이그레이션(database migrations), 코드 리뷰(code review)를 위해서 말이죠. 그것이 바로 스킬 프레임워크(skill frameworks)가 하는 일입니다. 이들은 조합(compose)됩니다.

Garry Tan의 gstack은 CEO, 디자이너(Designer), 엔지니어링 매니저(Engineering Manager), 릴리스 매니저(Release Manager), QA와 같이 전체 역할로 작동하는 **23개의 주관적인 도구(opinionated tools)**를 통해 이를 한 단계 더 발전시켰습니다. 각각은 고유한 메모리(memory)와 컨텍스트 윈도우(context window)를 가진 특화된 스킬입니다.

"당신의 코딩 에이전트(coding agent)는 당신이 부여한 스킬만큼만 유능합니다." — 제가 이 글을 쓰고 있는 바로 지금 진행 중인 AI Engineer World's Fair 2026에서 흔히 들리는 구절입니다.

스킬 설계의 네 가지 학파

생태계 전반을 살펴보면, 네 가지 뚜렷한 철학이 부상하고 있는 것을 볼 수 있습니다:

1. 올인원 프레임워크 (All-In-One Framework) (Superpowers, ECC)

이들은 에이전트 중심 개발(agentic development)을 위한 완전한 운영체제(operating systems)입니다. Superpowers는 브레인스토밍(brainstorm), 명세(spec), 구현(implement), 리뷰(review), 배포(deploy)에 이르는 완전한 소프트웨어 개발 생명주기(SDLC) 방법론을 제공하며, 이 모든 과정은 스킬을 통해 오케스트레이션(orchestrated)됩니다. ECC(이 이름은 문자 그대로 아무 의미가 없으며, 이제는 그냥 브랜드일 뿐입니다)는 스킬, 본능(instincts), 메모리(memory), 보안(security)을 하나의 하네스(harness)로 묶어 제공합니다.

장점: 모든 것이 함께 작동합니다. 하나의 설정(config), 하나의 워크플로우(workflow).
단점: 타인의 철학을 그대로 받아들여야 합니다. 이것저것 섞어서 사용하기 어렵습니다.

2. 큐레이션된 컬렉션 (Curated Collection) (Matt Pocock, Addy Osmani, Karpathy Skills)

이들은 AI 에이전트를 사용하여 실제로 제품을 출시해 본 사람들이 엄선하고 프로덕션 환경에서 검증한 .claude 디렉토리들입니다. Matt Pocock의 skills 리포지토리는 말 그대로 그의 개인 ~/.claude 폴더를 오픈 소스로 공개한 것입니다. Addy Osmani의 agent-skills (68K 스타)는 Google Chrome 엔지니어링 팀의 프로덕션급 엔지니어링 패턴(engineering patterns)에 초점을 맞추고 있습니다.

장점 (Pros): 숙련된 전문가들에 의해 실전 검증됨 (Battle-tested).
단점 (Cons): 사용자의 스택(stack)이나 워크플로우(workflow)에 맞지 않을 수 있음. 작동하는 부분만 취하고 나머지는 버릴 것.

3. 주관이 뚜렷한 툴체인 (The Opinionated Toolchain (gstack))

Garry Tan의 접근 방식은 가장 급진적입니다. 각 스킬(skill)이 고유의 에이전시(agency)를 가진 하나의 완전한 역할(role)이 됩니다. "디자이너 (Designer)" 스킬은 단순히 디자인 팁을 주는 것에 그치지 않고, 와이어프레임(wireframes)부터 사양(specs)에 이르기까지 디자인 프로세스 전체를 소유합니다. "CEO" 스킬은 비즈니스 우선순위에 따라 PR(Pull Request)을 검토합니다.

장점 (Pros): 터미널(terminal) 안에 팀 전체가 있는 듯한 느낌을 줌.
단점 (Cons): 높은 오버헤드 (High overhead). 역할 정의(role definitions)를 신뢰해야 함.

4. 유틸리티 벨트 (The Utility Belt (Caveman, Graphify))

이것들은 하나의 문제를 매우 잘 해결하는, 집중적이고 거의 유희적인 스킬들입니다. Caveman은 AI가 간결하고 원시적인 언어로 응답하게 함으로써 토큰(token) 사용량을 65% 절감합니다. Graphify는 RAG(검색 증강 생성)와 Leiden 클러스터링(clustering)을 사용하여 모든 코드베이스를 쿼리 가능한 지식 그래프(knowledge graph)로 변환합니다.

장점 (Pros): 낮은 마찰(Low friction), 즉각적인 가치.
단점 (Cons): 제한된 범위. 시스템이 아닌 도구(tools)임.

Caveman 효과: 왜 83,000명의 사람들이 자신의 AI가 원시인처럼 말하기를 원하는가

이 부분에 대해서는 잠시 멈춰서 짚고 넘어가야 합니다. 왜냐하면 이것이 우리에게 중요한 무언가를 말해주기 때문입니다.

Caveman은 AI가 말 그대로 원시인(caveman)처럼 응답하도록 프롬프트(prompt)를 주는 Claude Code 스킬입니다. 저자의 슬로건은 이렇습니다: "왜 많은 토큰 사용하나, 적은 토큰으로 충분한데 (why use many token when few token do trick)."

언뜻 보기에 이것은 농담처럼 보입니다. 네, README 파일도 아주 웃깁니다. 하지만 83,000명의 사람들이 원시인 농담이 재미있어서 스타(star)를 누른 것이 아닙니다. 그들이 스타를 누른 이유는 토큰 비용(token costs)이 실재하기 때문입니다.

토큰을 65% 줄인다는 것은 API 비용을 65% 줄인다는 것을 의미합니다. Claude Code나 Codex를 헤비 유저(heavy users)로 사용하는 사람들에게 이것은 사소한 문제가 아닙니다. 한 달에 수백 달러에 달하는 금액입니다. Caveman은 밈(meme)으로 위장된, AI 지원 개발의 경제성에 대한 선언입니다.

그리고 솔직히 말해서? 몇몇 예시들은 진심으로 가독성이 더 좋습니다:

이전 (장황하고 장황함):

요청을 분석한 결과, 데이터 일관성을 유지하면서 상당한 성능 향상을 제공할 수 있는 Redis를 사용한 캐싱 레이어 (caching layer)를 구현하는 것이 최적의 접근 방식이라고 판단했습니다.

이후 (원시인 스타일):

Redis 캐시 사용. 빠름.

일관성 있음. 완료.```

모든 코드를 이런 식으로 작성해야 한다는 뜻은 아닙니다. 하지만 우리의 AI 상호작용 중 얼마나 많은 부분이 낭비되는 장황함 (verbosity)으로 채워져 있는지에 대한 실질적인 통찰이 여기에 담겨 있습니다.

## 스킬의 경제학: 실제로 누가 돈을 벌고 있는가?

이 부분은 아무도 직접적으로 이야기하지 않기에, 제가 직접 말씀드리겠습니다.

이러한 스킬 저장소 (skill repos) 대부분은 무료이며 오픈 소스입니다. 하지만 진짜 돈이 되는 곳은 다음과 같습니다:

1. **엔터프라이즈 스킬 팩 (Enterprise skill packs)** — 팀의 기술 스택 (stack)에 맞춰 조정된 큐레이션된 스킬 세트에 비용을 지불하는 경우
2. **맞춤형 스킬 개발 (Custom skill development)** — 맞춤형 에이전트 워크플로우 (agent workflows)를 구축하는 컨설팅 업체
3. **스킬 마켓플레이스 (Skill marketplaces)** — 여러 스타트업이 프리미엄 스킬을 판매할 수 있는 플랫폼을 구축하고 있음
4. **토큰 절감 (Token savings)** — Caveman처럼 API 비용을 65% 절감하는 기업들은 사실상 돈을 벌고 있는 것임

Superpowers에는 상업용 티어 (commercial tier)가 있습니다. ECC에는 엔터프라이즈 지원이 있습니다. Graphify는 무료 스킬 위에 유료 지식 그래프 (knowledge-graph) 서비스를 구축하고 있습니다.

스킬 자체는 무료일 수 있지만, 그 주변의 생태계는 점점 더 수익화되고 있습니다. 만약 여러분이 이 분야에서 무언가를 구축하고 있다면, 가치 포착 (value capture)이 어디에서 일어나는지 생각해보십시오. 그것은 `CLAUDE.md` 파일 안에 있는 것이 아닙니다. 통합 (integration), 학습 (training), 그리고 워크플로우 최적화 (workflow optimization)에 있습니다.

## 어두운 면: 스킬 비대화와 프롬프트 지옥

단점들에 대해서도 솔직하게 말씀드리겠습니다. 왜냐하면 아주 많기 때문입니다.

**스킬 비대화 (Skill bloat)**가 가장 큰 문제입니다. 저는 각각의 파일이 제약 조건과 지침을 추가하는 40개 이상의 스킬 파일을 가진 팀들을 보았습니다. 에이전트는 마비됩니다. 너무 많은 상충하는 규칙, 상용구 (boilerplate)에 의해 소비되는 너무 많은 컨텍스트 (context), 그리고 너무 많은 "...하는 것을 잊지 마세요" 식의 지시 사항들 때문입니다.

**프롬프트 충돌(Prompt conflicts)**은 실제로 발생합니다. Skill A가 '항상 TypeScript를 사용하라'고 말하고, Skill B가 'plain JavaScript를 선호한다'고 말하면 어떻게 될까요? 에이전트는 이들을 조정해야 하는데, 보통 제대로 처리하지 못합니다.**유지보수 비용(Maintenance tax)**이야말로 조용한 문제입니다. Skills는 '설정해두면 잊어버리는 것(set and forget)'이 아닙니다. 스택이 진화함에 따라 여러분의 skills도 함께 진화해야 합니다. 저는 절반의 skill 파일들이 사용 중단된 라이브러리나 구식 패턴을 참조하는 저장소들을 보았습니다. 이해가 되시나요?

그리고 가장 크고 말하지 않는 문제는 다음과 같습니다: **대부분의 개발자는 실제로 좋은 skills를 작성하는 방법을 모릅니다.** skills를 작성하는 것은 코드를 작성하기보다는 법률 계약서를 작성하는 것에 가깝습니다. 정확하고, 모호함이 없으며, 엣지 케이스(edge cases)를 예측할 수 있어야 합니다. 대부분의 사람들은 이 부분에 능숙하지 않습니다.

## 플랫폼 플레이: Claude Code vs Codex vs Cursor vs Gemini CLI

현재로서는 Claude Code가 skill의 왕입니다. `CLAUDE.md` 형식이 사실상의 표준(de facto standard)이 되었으며, 심지어 Codex와 Cursor도 각각 `CODEX.md` 및 `.cursor/rules/`과 같은 방식으로 이를 지원합니다.

하지만 파편화(fragmentation)는 현실입니다:

| 플랫폼 | Skill 형식 | 에코시스템 성숙도 |
|----------|-------------|-------------------| 
| Claude Code | `CLAUDE.md` | ✅ 가장 성숙하고, 광범위하게 채택됨 |
| ... | | |

여기서 승자는 최고의 형식이 아닐 것입니다. **파편화를 줄이는** 방식이 될 것입니다. 저는 universal skill format — skills를 위한 MCP 같은 것 — 을 주시하고 있으며, 이미 몇몇 팀들이 이를 구축하고 있습니다. 만약 누군가 이 문제를 해결한다면, 그들이 에코시스템을 소유하게 됩니다. 제가 무슨 말을 하는지 아시겠죠?

## 실제로 중요하다고 생각하는 것들

skills 파일들을 너무 오래 읽고 에코시스템을 지켜본 후, 저의 솔직한 의견은 다음과 같습니다:

**skill 혁명은 실재하지만, 우리는 '너무 많은 프레임워크' 단계에 있습니다.**

제가 본 최고의 skill 설정들은 작습니다. 다음을 다루는 3~5개의 집중적인 파일들입니다:
1. **프로젝트 컨벤션(Project conventions)** — 기술 스택, 패턴, 스타일
2. **테스팅 철학(Testing philosophy)** — 테스트를 작성하고 생각하는 방식
3. **아키텍처 규칙(Architecture rules)** — 코드베이스가 유지해야 하는 불변성(invariants)
4. **배포 워크플로우(Deployment workflow)** — 코드가 PR에서 프로덕션으로 이동하는 방법

그 외의 모든 것은 소음(noise)에 불과합니다.

가장 큰 가치를 얻고 있는 팀들은 가장 많은 스킬을 가진 팀들이 아닙니다. 그들은 에이전트가 실제로 무엇을 틀렸는지에 기반하여 스킬을 반복적으로 개선(iterate)하는 팀들입니다. 그것이 진정한 메타 스킬(meta-skill)입니다: **관찰하고, 조정하고, 반복하라(observe, adjust, repeat)**.

Garry Tan의 역할 기반 스킬(role-based skills) 접근 방식은 흥미롭지만, 저는 이것이 더 단순한 무언가로 정착될 것이라고 생각합니다. CEO 스킬은 참신합니다. 하지만