클로드 코드 메타 생태계의 폭발 — 에이전트의 진짜 moat은 모델이 아니라 ‘운영 지식 층’이다

“다섯 개의 레포가 같은 주에 GitHub Trending을 점령했다. 전부 Claude Code를 ‘더 잘 쓰는 법’에 관한 것이었다. 이 현상의 이름은 아직 없다.”

2026년 4월 10일 주간, GitHub Trending 페이지에 이례적인 풍경이 펼쳐졌다. 일간과 주간 랭킹을 합산했을 때, 상위권에 올라 있는 레포 다섯 개가 하나의 공통점을 가지고 있었다. 전부 Claude Code — 또는 그와 유사한 coding agent — 를 “더 잘 쓰기 위한” 도구였다는 것이다.

obra/superpowers는 143,712 스타에 하루 +2,299를 기록했다. “An agentic skills framework & software development methodology that works”라는 설명이 붙은 Shell 프로젝트다. forrestchang/andrej-karpathy-skills는 10,441 스타, 일간 +1,364, 주간 +2,230. 이 레포의 핵심 산출물은 CLAUDE.md 파일 하나다. luongnv89/claude-howto는 24,002 스타에 주간 +7,342. 복사해서 붙여넣을 수 있는 템플릿과 가이드 모음이다. YishenTu/claudian은 6,815 스타, 일간 +200. Obsidian vault 안에 Claude Code를 심는 플러그인이다. 그리고 Yeachan-Heo/oh-my-codex는 19,938 스타에 주간 +9,737 — 이번 주 GitHub 전체에서 두 번째로 빠르게 성장한 레포다. 이것은 Claude Code가 아니라 OpenAI의 Codex를 대상으로 한 도구이지만, 패턴은 동일하다.

다섯 레포의 누적 스타 합계는 204,908개. 이번 주에만 더해진 스타 수를 보수적으로 합산해도 2만 개를 넘는다. 개발자 도구 카테고리에서 이 규모의 동시 트렌딩은 전례가 없다. VS Code 확장 생태계 전성기에도, 한 주에 다섯 개의 “VS Code를 더 잘 쓰기 위한 도구”가 동시에 트렌딩에 오른 적은 없었다. 프롬프트 엔지니어링 붐이 일던 2023~2024년에도, “ChatGPT를 더 잘 쓰는 법” 레포가 다섯 개씩 동시에 올라온 적은 없었다.

무슨 일이 일어나고 있는 것인가?

이 글은 2026년 4월 10일 주간의 이 현상을 해부한다. 각 레포를 개별로 분석하고, 이 현상이 개발자 도구 역사에서 어디에 위치하는지를 살피고, 지난번 글에서 다룬 “복제 불가능한 해자” 논의를 한 층 확장한다. 이전 글의 핵심 주장은 개인의 맥락 축적이 moat이라는 것이었다. 이번 글의 주장은 다르다 — 개인의 맥락을 넘어, 집단의 운영 지식(operational knowledge)이 모델 위에 새로운 층(layer)을 형성하고 있으며, 이 층 자체가 새로운 종류의 해자가 된다.

1. 다섯 개의 레포 — 개별 해부

다섯 레포는 같은 현상의 다섯 가지 표현이다. 하지만 각각의 성격은 뚜렷하게 다르다. 하나씩 뜯어보자.

obra/superpowers — 방법론의 제품화

superpowers는 이번 주 현상의 플래그십이다. 143,712 스타. 이 숫자만으로도 이미 대다수의 프로그래밍 언어 프레임워크를 추월한다. “An agentic skills framework & software development methodology that works”라는 설명에서 핵심 단어는 두 개다. skills framework와 methodology.

superpowers가 하는 일은 Claude Code에 “기술(skills)“을 주입하는 것이다. 브레인스토밍, 플랜 작성, 코드 리뷰, 디버깅, Git worktree 관리 등 소프트웨어 개발의 각 단계에 해당하는 skills를 정의하고, 에이전트가 상황에 따라 적절한 skill을 호출하도록 구조화한다. 이것은 프롬프트가 아니다. 프롬프트는 “이렇게 해줘”라는 일회성 지시다. skill은 “이런 상황에서는 항상 이렇게 행동해라”는 구조화된 운영 지침이다.

더 중요한 것은 methodology라는 단어다. superpowers는 단순한 도구가 아니라 소프트웨어 개발 방법론을 제품으로 만든 것이다. “brainstorming 단계를 반드시 거칠 것”, “plan을 먼저 작성하고 subagent로 실행할 것”, “완료를 주장하기 전에 반드시 verification을 돌릴 것” — 이런 규율은 인간 개발자가 오랜 경험을 통해 체득하는 것이다. superpowers는 이 규율을 에이전트에게 심는다. 시니어 개발자의 암묵지가 Shell 스크립트와 Markdown 파일로 결정화된 것이다.

143,712 스타의 의미는 이 방법론에 대한 수요가 거대하다는 것이다. Claude Code 자체는 강력하지만, “Claude Code를 어떻게 써야 하는가”에 대한 답은 공식 문서에 충분히 담겨 있지 않다. superpowers가 그 공백을 메운다.

forrestchang/andrej-karpathy-skills — 파일 하나가 제품이 되다

andrej-karpathy-skills는 이번 주에서 가장 순수한 형태의 사례다. 이 레포의 핵심 산출물은 CLAUDE.md 파일 단 하나다. Andrej Karpathy가 LLM 코딩의 함정에 대해 관찰한 내용을 정리한 것이다. 10,441 스타, 일간 +1,364, 주간 +2,230.

여기서 멈춰서 이 숫자를 곱씹어야 한다. GitHub에서 10,000 스타 이상의 레포는 전체의 상위 0.01%에 해당한다. 이 레포의 내용물은 Markdown 파일 하나다. 코드가 아니다. 바이너리가 아니다. 설치할 것도, 빌드할 것도, 실행할 것도 없다. 텍스트 파일을 복사해서 자기 프로젝트의 루트 디렉토리에 놓으면 끝이다. 그럼에도 10,000명 이상이 스타를 눌렀고, 하루에 1,364명이 추가로 눌렀다.

이것이 의미하는 바는 명확하다. CLAUDE.md라는 파일 형식 자체가 제품 카테고리가 되었다. 과거에는 .vimrc나 .emacs 설정 파일을 dotfiles 레포에 공유하는 문화가 있었다. 하지만 dotfiles 레포가 10,000 스타를 받는 경우는 mathiasbynens/dotfiles (30k) 같은 극소수의 전설적 레포뿐이었고, 그마저도 수년에 걸쳐 축적된 숫자다. andrej-karpathy-skills는 한 주 만에 2,230 스타를 추가했다. dotfiles 문화의 속도와 비교할 수 없는 폭발력이다.

왜 이 파일이 이토록 가치가 있는가? CLAUDE.md는 Claude Code가 프로젝트에 진입할 때 가장 먼저 읽는 파일이다. 여기에 적힌 지침이 에이전트의 전체 행동을 규정한다. 잘 작성된 CLAUDE.md와 빈 CLAUDE.md의 차이는, 프로젝트에 시니어 개발자가 옆에 앉아 있느냐 없느냐의 차이와 비슷하다. Karpathy의 관찰 — LLM이 코드를 작성할 때 빠지기 쉬운 함정들 — 을 CLAUDE.md에 심으면, 에이전트가 그 함정을 미리 회피한다. 한 사람의 경험이 파일 하나에 결정화되고, 그 파일이 수천 명의 에이전트 행동을 교정한다. 지식의 레버리지가 극대화되는 형태다.

luongnv89/claude-howto — 템플릿의 산업화

claude-howto는 24,002 스타에 주간 +7,342. “Visual, example-driven guide to Claude Code with copy-paste templates”라는 설명이 이 레포의 성격을 정확히 요약한다. 이것은 문서(documentation)이면서 동시에 제품이다.

전통적으로 소프트웨어 문서는 제품에 부속되는 것이었다. 제품이 먼저 있고, 문서가 뒤따른다. claude-howto는 이 관계를 뒤집는다. 여기서는 문서 자체가 제품이다. Claude Code라는 원본 제품은 Anthropic이 만들었지만, “Claude Code를 효과적으로 사용하는 법”이라는 지식 제품은 커뮤니티가 만들고 있다. 24,002 스타는 이 지식 제품에 대한 시장 수요의 크기를 보여준다.

주간 +7,342는 특히 주목할 만하다. 이것은 이번 주 GitHub 전체에서 상위 10위 안에 드는 성장 속도다. 기업이 만든 오픈소스 프레임워크, 새로운 프로그래밍 언어, 혁신적인 라이브러리 — 이런 것들과 어깨를 나란히 하는 것이 “복사해서 붙여넣는 가이드”라는 사실. 이것은 현재 개발자 생태계가 무엇에 갈증을 느끼고 있는지를 직설적으로 말해준다. 더 좋은 모델이 아니라, 지금 있는 모델을 더 잘 쓰는 방법.

YishenTu/claudian — 에이전트의 표면 확장

claudian은 6,815 스타, 일간 +200. 다른 네 레포와 성격이 다르다. 이것은 지식이나 방법론이 아니라, Claude Code의 물리적 표면(surface area)을 확장하는 도구다. Obsidian vault 안에 Claude Code를 삽입하는 플러그인.

Obsidian은 로컬 마크다운 기반의 지식 관리 도구다. 개발자와 리서처 사이에서 두텁게 쓰이고 있다. claudian이 하는 일은, Obsidian에서 작성 중인 노트에 직접 Claude Code를 AI 협업자로 부착하는 것이다. 에이전트가 코드 에디터에만 살지 않고, 사용자의 사고 공간(thinking space) 안에 들어오는 것이다.

이것이 중요한 이유는 에이전트의 “서식지(habitat)” 확장이기 때문이다. Claude Code는 터미널에서 시작해 에디터로 확장되었고, 이제 지식 관리 도구로 진입하고 있다. 에이전트가 코드를 쓸 때만 활성화되는 것이 아니라, 사용자가 생각을 정리할 때부터 옆에 있게 된다. 이전 글에서 다룬 “깊은 통합이 만드는 해자”의 정확한 실례가 여기 있다. 에이전트가 터미널에만 있을 때의 교체 비용과, 에이전트가 에디터+터미널+지식관리 도구를 관통할 때의 교체 비용은 차원이 다르다.

Yeachan-Heo/oh-my-codex — 패턴의 전이

oh-my-codex는 이번 주의 가장 중요한 데이터 포인트일 수 있다. 19,938 스타, 주간 +9,737 — GitHub 전체에서 두 번째로 빠른 성장. 그런데 이 레포는 Claude Code를 위한 것이 아니다. OpenAI의 Codex를 위한 것이다. “OmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs.”

이름부터 의미심장하다. “Oh My”라는 접두사는 oh-my-zsh에서 왔다. oh-my-zsh는 Zsh 셸을 더 잘 쓰기 위한 커뮤니티 프레임워크로, 플러그인, 테마, 설정을 체계화한다. 180,000+ 스타의 레전드 프로젝트다. oh-my-codex가 이 이름을 의도적으로 차용한 것은, 자신이 “Codex 위의 사용자 지식 층”이라는 정체성을 선언한 것이다.

한국인 개발자 Yeachan-Heo가 메인테이너라는 점도 기록해둘 만하다. hooks, agent teams, HUD(Heads-Up Display) — 이 세 가지 키워드는 coding agent를 운영 가능한 시스템으로 만들기 위한 도구 세트다. hooks는 에이전트의 행동에 사전/사후 트리거를 거는 것이고, agent teams는 여러 에이전트를 조율하는 것이며, HUD는 에이전트의 상태를 실시간으로 모니터링하는 인터페이스다.

oh-my-codex가 이번 주 현상에서 핵심인 이유는 하나다. 같은 패턴이 다른 모델로 전이됐다. Claude Code에서 관찰된 “메타 도구 생태계” 현상이 Claude Code에 국한된 것이 아님을 증명한다. Codex 사용자도 같은 갈증을 느끼고 있고, 같은 구조의 해법을 만들어내고 있다. 이것은 특정 제품의 현상이 아니라 카테고리 수준의 현상이다. coding agent라는 도구 범주 전체에서 “운영 지식 층”이 형성되고 있다는 증거.

2. CLAUDE.md라는 파일 형식이 제품이 된 순간

다섯 레포를 관통하는 가장 놀라운 사실은, 이 중 상당수의 핵심 산출물이 코드가 아니라 텍스트라는 것이다. andrej-karpathy-skills는 Markdown 파일 하나다. superpowers의 skills도 본질적으로는 구조화된 지침 텍스트다. claude-howto는 복사해서 붙여넣는 템플릿이다. 실행 가능한 바이너리가 아니라, 읽을 수 있는 문서가 제품의 핵심이다.

이것을 이해하려면 CLAUDE.md라는 파일 형식의 본질을 짚어야 한다.

설정 파일의 진화사

소프트웨어 역사에서 “도구의 행동을 사용자가 정의하는 파일”은 항상 존재했다. Unix의 .profile, Emacs의 .emacs, Vim의 .vimrc, Zsh의 .zshrc. 이 파일들은 몇 가지 공통점을 가진다. 첫째, 도구의 기본 동작을 사용자의 선호에 맞게 수정한다. 둘째, 사용자 간에 공유 가능하다 (dotfiles 문화). 셋째, 시간이 지날수록 점점 정교해진다 — 사용자가 경험을 축적하면서 설정을 다듬는다.

하지만 .emacs나 .vimrc는 기계어에 가까운 문법으로 작성된다. Emacs Lisp이나 Vimscript를 읽으려면 해당 도구의 설정 언어를 별도로 학습해야 한다. 진입 장벽이 있다. dotfiles 레포를 공유해도, 그 내용을 이해하고 자기 환경에 맞게 수정하려면 상당한 지식이 필요하다.

CLAUDE.md는 이 전통에서 결정적으로 한 단계 도약한 형태다. 기계어가 아니라 자연어로 작성된다. “커밋 메시지는 영어로 작성할 것”, “테스트를 먼저 작성하고 구현할 것”, “추상적 서술을 피하고 구체적 숫자를 사용할 것” — 이것은 설정이 아니라 지침이다. 프로그래밍 언어를 모르는 사람도 읽을 수 있고, 수정할 수 있다. 진입 장벽이 사실상 사라졌다.

이 진입 장벽의 소멸이 andrej-karpathy-skills의 폭발적 성장을 설명한다. .emacs 파일을 GitHub에 올려서 10,000 스타를 받으려면, 그 파일이 대단히 정교하고 Emacs 사용자 전체에게 범용적으로 유용해야 한다. CLAUDE.md 파일은 다르다. 누구나 읽을 수 있고, 복사할 수 있고, 자기 프로젝트에 바로 적용할 수 있다. 소비의 마찰이 거의 0이다. 그래서 같은 시간 안에 훨씬 더 많은 사람에게 도달한다.

자연어 설정의 폭발적 레버리지

CLAUDE.md의 두 번째 특성은, 이 파일이 단순히 도구를 설정하는 것이 아니라 에이전트의 “인격”을 형성한다는 것이다. .vimrc는 키 바인딩을 바꾸고, 문법 하이라이팅을 설정하고, 탭 크기를 정의한다. 기계적 행동의 파라미터를 조정한다. CLAUDE.md는 판단의 기준을 설정한다. “코드가 길어질 때는 함수로 분리할 것”, “사용자가 질문하면 바로 구현하지 말고 먼저 설계를 확인할 것” — 이것은 파라미터가 아니라 가치관이다. 에이전트의 의사결정 체계를 형성하는 것이다.

이전 글에서 다룬 harness 개념으로 해석하면, CLAUDE.md는 harness의 가장 바깥 층이다. Raschka가 정의한 여섯 가지 harness 요소 — Live Repo Context, Prompt Shape, Tool Access, Context Bloat 최소화, Session Memory, Bounded Subagents — 는 주로 소프트웨어 계층에서 작동한다. CLAUDE.md는 그 소프트웨어 계층 위에 놓이는 인간 지식의 결정체다. harness가 에이전트의 “어떻게(how)“를 구조화한다면, CLAUDE.md는 에이전트의 “무엇을(what)“과 “왜(why)“를 규정한다.

andrej-karpathy-skills가 10,000 스타를 받은 것은, 이 “무엇을”과 “왜”에 대한 답변이 대단히 부족하다는 의미다. Anthropic은 Claude Code라는 강력한 엔진과 harness를 만들었지만, 그 위에서 “이 엔진을 어떻게 운전해야 최선인가”에 대한 운영 지식은 커뮤니티가 스스로 만들고 있다. 모델을 만든 회사가 아니라, 모델을 매일 쓰는 사용자들이 지식의 공급자가 된 것이다.

파일 하나의 경제학

하나의 관점을 더 추가하자. andrej-karpathy-skills 레포의 핵심은 CLAUDE.md 파일 하나다. 이 파일의 크기는 수 킬로바이트에 불과할 것이다. 그런데 이 파일이 만들어내는 경제적 가치를 생각해보자.

이 파일을 적용한 Claude Code 세션에서 에이전트가 흔한 실수를 한 번 덜 저지른다고 가정하자. 그 실수를 디버깅하는 데 30분이 걸렸을 것이다. 10,000명의 개발자가 이 파일을 적용했고, 각자 주당 한 번씩 그 혜택을 본다면, 주당 5,000시간의 개발자 시간이 절약된다. 시간당 $50으로 환산하면 주당 $250,000. 연간으로 환산하면 $13,000,000. Markdown 파일 하나가.

이 계산은 과장일 수 있다. 실제 효과는 이보다 작을 것이다. 하지만 방향은 맞다. 운영 지식의 결정화와 공유가 만들어내는 가치는 코드 라이브러리의 가치와 같은 구조를 가진다. 한 사람의 경험이 파일에 담기고, 그 파일이 n명에게 복제되면, 가치는 n배가 된다. 전통적인 라이브러리가 “코드의 재사용”을 가능하게 했다면, CLAUDE.md 생태계는 “운영 지식의 재사용”을 가능하게 한다.

3. 역사적 유비: oh-my-zsh, .emacs, .vimrc — 도구 위의 사용자 지식 층

이 현상은 전례가 없는 것인가? 아니다. 비슷한 구조가 과거에도 있었다. 하지만 규모와 속도가 달라졌다.

oh-my-zsh — 가장 정확한 유비

oh-my-zsh는 2009년에 시작된 프로젝트다. Zsh 셸에 플러그인, 테마, 설정을 체계적으로 관리하는 프레임워크를 씌운 것이다. 현재 180,000+ 스타로, GitHub 전체에서 가장 많은 스타를 받은 프로젝트 중 하나다.

oh-my-zsh가 Zsh에 한 일이 정확히 superpowers가 Claude Code에 하는 일이다. 셸 자체는 강력하지만, 대부분의 사용자는 그 강력함의 10%도 활용하지 못한다. 어떤 옵션이 있는지 모르고, 어떤 플러그인이 유용한지 모르고, 어떤 설정이 워크플로를 바꾸는지 모른다. oh-my-zsh는 커뮤니티의 집단 지식을 체계화해서, 초보 사용자도 고급 기능을 즉시 활용할 수 있게 만들었다.

구조를 비교해보자.

Zsh + oh-my-zshClaude Code + superpowers
기반 도구Zsh 셸Claude Code
지식 층oh-my-zsh 플러그인/테마/설정superpowers skills/methodology
설정 파일.zshrcCLAUDE.md
핵심 가치셸을 더 잘 쓰는 법의 결정화에이전트를 더 잘 쓰는 법의 결정화
공유 메커니즘GitHub dotfiles 레포GitHub skills 레포
사용자 커스터마이징플러그인 on/off, 테마 선택skills 추가/제거, 지침 수정

유비는 구조적으로 거의 완벽하다. 다만 두 가지 결정적 차이가 있다.

첫째, 속도. oh-my-zsh가 180,000 스타에 도달하는 데 17년이 걸렸다. superpowers는 이미 143,712 스타이고, 하루에 2,299개씩 늘고 있다. 이 속도라면 oh-my-zsh를 수년 내에 따라잡을 수 있다. oh-my-zsh 시대에는 GitHub 자체의 사용자 수가 지금보다 훨씬 적었다는 보정 팩터가 있지만, 그래도 속도 차이는 뚜렷하다.

둘째, 레버리지의 크기. .zshrc 설정이 바꾸는 것은 셸의 시각적 표현(프롬프트 모양), 자동완성 동작, 히스토리 관리 같은 것이다. 유용하지만, 셸이 처리하는 작업 자체를 근본적으로 바꾸지는 않는다. ls를 실행하면 ls가 실행된다. 반면 CLAUDE.md가 바꾸는 것은 에이전트의 의사결정 체계다. 같은 “이 코드를 리팩토링해줘”라는 요청도, CLAUDE.md에 무엇이 적혀 있느냐에 따라 완전히 다른 결과가 나온다. 설정의 영향 반경이 차원이 다르다.

Emacs의 .emacs — 리스프 마법사의 탑

Emacs는 “확장 가능한 텍스트 에디터”라는 철학을 극단까지 밀고 간 도구다. .emacs 파일(또는 init.el)에 Emacs Lisp으로 거의 무한한 커스터마이징이 가능하다. 에디터를 이메일 클라이언트로, 웹 브라우저로, 파일 관리자로, 심지어 운영체제로 만들 수 있다. “Emacs is not a text editor, it’s a Lisp interpreter that happens to edit text”라는 격언이 있을 정도다.

Emacs 생태계에서 .emacs 파일은 사용자의 정체성이었다. 수년간 다듬어진 .emacs는 그 사용자의 작업 방식, 사고 방식, 심지어 미적 감각까지 담고 있었다. “내 .emacs를 보여줘, 너가 어떤 개발자인지 알려줄게”라는 반쯤 농담이 통할 정도였다.

그런데 .emacs의 문제는 진입 장벽이었다. Emacs Lisp을 모르면 다른 사람의 설정을 이해할 수 없었다. 설정을 복사해 와도, 왜 이 설정이 이렇게 되어 있는지 파악하지 못하면 충돌이 나거나 원치 않는 동작이 발생했다. 설정의 공유가 사실상 같은 수준의 Emacs Lisp 능력을 전제했다.

CLAUDE.md는 이 문제를 자연어로 해결했다. “추상적 서술을 피하고 구체적 숫자를 사용할 것”이라는 지침은, 프로그래밍 언어를 모르는 사람도 읽을 수 있다. 진입 장벽이 제거된 .emacs가 CLAUDE.md다. 그리고 진입 장벽이 제거되면 공유의 속도가 폭발한다. andrej-karpathy-skills가 한 주에 2,230 스타를 받은 것은, 이 폭발의 단면이다.

Vim의 .vimrc — 효율의 종교

Vim 사용자들은 .vimrc를 종교적 헌신으로 다듬었다. 키 바인딩 하나, 매핑 하나가 초 단위의 효율성 차이를 만들었고, 그 차이가 하루에 수천 번 반복되면 유의미한 생산성 격차가 됐다. “나는 hjkl이 아니라 jkl;를 쓴다”는 선언이 정치적 입장처럼 논쟁을 불렀다.

.vimrc 문화에서 주목할 것은, 최적의 설정이 사용자의 맥락에 깊이 의존한다는 점이다. Python 개발자의 .vimrc와 C++ 개발자의 .vimrc는 전혀 다르다. 터미널에서 작업하는 사람과 GUI를 선호하는 사람의 설정도 다르다. 범용적으로 “최고”인 .vimrc는 존재하지 않았다.

CLAUDE.md 생태계에서도 같은 분화가 시작되고 있다. andrej-karpathy-skills는 범용적 지침이지만, 실무에서는 프로젝트 성격에 따라 CLAUDE.md가 달라져야 한다. 프론트엔드 프로젝트와 시스템 프로그래밍 프로젝트의 최적 지침은 다르다. 팀의 규모, 코딩 컨벤션, 테스트 전략에 따라 지침이 갈라진다. .vimrc의 분화와 같은 과정이 CLAUDE.md에서 가속화되고 있다.

세 세대의 공통 구조와 결정적 차이

.emacs → .vimrc → .zshrc → CLAUDE.md. 이 진화 라인에서 일관된 것은, 사용자가 도구의 행동을 정의하는 파일이 항상 존재했다는 사실이다. 도구가 강력할수록 이 파일의 중요성은 커졌고, 이 파일을 공유하는 문화가 형성됐다.

CLAUDE.md 세대가 이전 세대와 결정적으로 다른 점은 세 가지다.

첫째, 자연어. 이전 세대의 설정 파일은 전용 문법이나 프로그래밍 언어를 요구했다. CLAUDE.md는 일상 언어로 작성된다. 공유의 마찰이 소멸했다.

둘째, 영향 반경. 이전 세대의 설정은 도구의 외관이나 기계적 동작을 변경했다. CLAUDE.md는 에이전트의 판단 체계를 변경한다. 같은 요청에 대해 완전히 다른 산출물이 나올 수 있다. 설정의 중요도가 차원이 다르다.

셋째, 경제적 가치. .vimrc가 잘못되어도 최악의 경우 키 바인딩이 엉킬 뿐이다. CLAUDE.md가 잘못되면 에이전트가 코드베이스에 구조적 문제를 심을 수 있다. 반대로 CLAUDE.md가 잘 작성되면 에이전트의 생산성이 체감될 수준으로 올라간다. 이 파일의 품질과 경제적 결과 사이의 상관이 과거 어떤 설정 파일보다 강하다.

이 세 가지 차이가 합쳐져서 CLAUDE.md 생태계의 폭발적 성장을 만들어내고 있다. 누구나 쓸 수 있고, 효과가 크고, 공유하기 쉽다. 바이럴 확산의 세 가지 조건이 동시에 충족된 것이다.

4. oh-my-codex의 의미 — 같은 패턴이 다른 모델로 전이됐다

oh-my-codex에 대해 더 깊이 파고들 필요가 있다. 이 레포가 이번 주 현상의 열쇠이기 때문이다.

표면적 사실

oh-my-codex는 OpenAI의 Codex CLI를 위한 도구다. hooks, agent teams, HUD를 추가한다. 19,938 스타에 주간 +9,737. 이번 주 GitHub에서 두 번째로 빠르게 성장한 레포다. 메인테이너는 한국인 개발자 Yeachan-Heo.

이 레포가 왜 중요한가 — 카테고리의 증거

만약 superpowers, andrej-karpathy-skills, claude-howto, claudian만 트렌딩에 올랐다면, 이 현상을 “Claude Code 특수 현상”으로 해석할 수 있었을 것이다. Anthropic이 특별히 잘 만든 제품에 사용자가 열광하고 있다는 이야기. 제품 수준의 이야기로 끝날 수 있었다.

oh-my-codex가 이 해석을 불가능하게 만든다. 같은 패턴이 OpenAI의 Codex에서도 발생하고 있다. Codex와 Claude Code는 경쟁 제품이다. 만든 회사도 다르고, 기반 모델도 다르고, 아키텍처도 다르다. 그런데 사용자들이 같은 구조의 해법을 만들어내고 있다.

이것은 특정 제품의 현상이 아니라 카테고리(category) 수준의 현상이다. coding agent라는 도구 범주 자체가 “운영 지식 층”을 필요로 하고 있으며, 사용자 커뮤니티가 그 층을 독립적으로 형성하고 있다.

oh-my-zsh 유비의 정확성

oh-my-codex의 이름은 우연이 아니다. oh-my-zsh의 구조를 의도적으로 차용한 것이다. oh-my-zsh가 Zsh 위에 커뮤니티 지식 층을 올린 것처럼, oh-my-codex는 Codex 위에 커뮤니티 지식 층을 올린다.

oh-my-zsh는 왜 성공했는가? Zsh 자체는 강력했지만, 대부분의 사용자는 기본 설정에서 벗어나지 못했다. 수백 개의 유용한 기능이 문서에 묻혀 있었다. oh-my-zsh가 한 일은 그 묻힌 기능들을 발굴하고, 체계화하고, 플러그인으로 패키징하고, 초보자도 한 줄의 설치 명령어로 즉시 활용할 수 있게 만든 것이다. 도구 제작자가 만들지 못한(또는 만들지 않은) “사용법의 체계”를 커뮤니티가 만들었다.

coding agent 생태계에서 정확히 같은 역학이 작동하고 있다. Claude Code도, Codex도, 공식 문서에는 기본적인 사용법만 담겨 있다. “이 도구를 어떻게 써야 생산성이 극대화되는가”에 대한 답은 — 어디에서도 공식적으로 제공되지 않는다. superpowers가 Claude Code에 대해, oh-my-codex가 Codex에 대해 그 공백을 메우고 있다.

hooks의 의미 — 에이전트 거버넌스의 시작

oh-my-codex의 세 가지 핵심 기능 중 hooks에 주목하자. hooks는 에이전트가 특정 행동을 수행하기 전이나 후에 사용자 정의 로직을 실행하는 메커니즘이다. 예를 들어, 에이전트가 파일을 삭제하려 할 때 사전 확인을 요구하거나, 커밋을 만들기 전에 lint를 강제로 실행하거나, 특정 디렉토리에 대한 쓰기를 차단하는 것이다.

이것은 사실상 에이전트에 대한 거버넌스(governance)다. 에이전트가 무엇을 할 수 있고 무엇을 할 수 없는지를 사용자가 세밀하게 제어하는 것이다. 이전 글에서 다룬 coding agent의 harness 개념 — Tool Access와 Validation — 의 사용자 측 확장이다. Anthropic이 만든 harness가 기본적인 안전 장치를 제공한다면, oh-my-codex의 hooks는 사용자가 자기 환경에 맞는 추가 거버넌스를 설치하는 것이다.

이 거버넌스 층의 출현은 coding agent가 “도구”에서 “시스템”으로 전환되고 있음을 보여준다. 도구는 사용자가 직접 조작한다. 시스템은 자율적으로 행동하되 정책에 의해 제한된다. hooks는 그 정책을 사용자가 정의하는 메커니즘이다.

agent teams와 HUD — 단일 에이전트에서 에이전트 시스템으로

oh-my-codex의 agent teams 기능은, 단일 에이전트가 아니라 여러 에이전트를 조율하는 구조를 만든다. 하나의 에이전트가 설계를 담당하고, 다른 에이전트가 구현을 담당하고, 또 다른 에이전트가 테스트를 담당하는 식이다. 이것은 인간 개발팀의 구조를 에이전트 시스템에 투사한 것이다.

HUD(Heads-Up Display)는 이 에이전트 시스템의 상태를 사용자가 실시간으로 관찰할 수 있게 하는 인터페이스다. 어떤 에이전트가 무엇을 하고 있는지, 어디서 병목이 발생하는지, 얼마나 진행됐는지를 시각적으로 보여준다.

agent teams + HUD의 조합은, coding agent의 사용 패러다임이 “나와 에이전트의 1:1 대화”에서 “내가 에이전트 팀을 운영하는 관리자”로 진화하고 있음을 시사한다. 이 진화에서 필요한 것은 더 강력한 모델이 아니다. 에이전트 팀을 효과적으로 운영하기 위한 운영 지식이다. 누구를 언제 투입하고, 어떤 순서로 진행하고, 어떤 기준으로 결과를 검수하는가. 이것은 프로젝트 관리의 지식이다.

oh-my-codex가 하는 일은, 이 운영 지식을 도구화하는 것이다. 그리고 19,938 스타는 이 도구화에 대한 수요가 거대하다는 것을 말한다.

5. 기존 moat 논의의 한계와 확장 — 개인 맥락에서 집단 운영 지식으로

지난번 글 “복제당해도 살아남는 에이전트의 조건”에서 나는 세 가지 해자를 논했다. 첫째, 맥락의 축적 — 사용자와의 상호작용을 통해 쌓이는 개인화된 지식은 복제할 수 없다. 둘째, 피드백 플라이휠 — 출력 → 반응 → 학습 → 개선의 루프가 시간과 함께 가속된다. 셋째, 깊은 통합 — 에이전트가 워크플로우의 접착제가 되면 교체 비용이 기하급수적으로 증가한다.

이 세 가지 해자는 여전히 유효하다. 그런데 2026년 4월 10일 주간의 현상은, 이 프레임워크가 놓치고 있는 새로운 층을 드러낸다.

이전 논의의 한계 — 개인 수준에 갇힌 해자

이전 글의 세 해자는 모두 개인 또는 팀 수준에서 작동한다. 내 CLAUDE.md에 쌓인 맥락, 내 플라이휠의 관성, 내 워크플로우의 통합. 이것은 강력한 lock-in을 만들지만, 개별 사용자의 개별 경험에 묶여 있다. A라는 개발자의 맥락은 B라는 개발자에게 전이되지 않는다. 각자의 해자는 각자만의 것이다.

그런데 superpowers, andrej-karpathy-skills, claude-howto, oh-my-codex가 보여주는 것은 다른 차원이다. 개인의 운영 지식이 파일로 결정화되고, GitHub을 통해 공유되고, 수천 명의 사용자에게 즉시 적용된다. 개인의 맥락이 집단의 지식이 되는 과정이다.

이것을 정리하면 이렇게 된다.

층위이전 글의 moat이번 글의 새로운 moat
단위개인/팀커뮤니티/생태계
형태암묵지(tacit knowledge)형식지(explicit knowledge)
저장 매체사용자 프로필, 대화 히스토리CLAUDE.md, skills, templates
전이 가능성불가능 (해자의 핵심)가능 (지식의 결정화)
축적 속도개인의 사용 시간에 비례커뮤니티의 기여 속도에 비례

집단 운영 지식이라는 새로운 층

2026년 4월 현재, GitHub에서 관찰되는 현상을 하나의 개념으로 요약하면 **“집단 운영 지식 층(collective operational knowledge layer)“**이 된다. 이 층은 모델 위에, 그리고 개인 맥락 옆에 존재한다.

구조를 그려보면 이렇다.

[개인 사용자의 맥락] ← 이전 글의 moat
        ↑
[집단 운영 지식 층: superpowers, karpathy-skills, claude-howto, oh-my-codex] ← 이번 글의 주제
        ↑
[Harness/Agent 소프트웨어: Claude Code, Codex CLI]
        ↑
[Foundation Model: Opus 4.6, GPT-5.x 등]

개인 맥락은 축적되면 이전 불가능하다 — 이것이 이전 글의 moat이었다. 집단 운영 지식은 축적되면 즉시 공유 가능하다 — 이것이 이번 글의 새로운 발견이다. 두 층은 대립하는 것이 아니라 보완한다. 집단 운영 지식이 “기본 수준(baseline)“을 끌어올리고, 개인 맥락이 그 기본 수준 위에서 개인화를 추가한다.

andrej-karpathy-skills를 적용하면 모든 사용자의 Claude Code 경험이 한 단계 올라간다. 이것은 집단 운영 지식의 역할이다. 그 위에서 개인 사용자가 자신만의 CLAUDE.md를 다듬으면 경험이 한 단계 더 올라간다. 이것은 개인 맥락의 역할이다.

시사점 — 두 종류의 moat이 결합할 때

이전 글에서 “피드백 플라이휠과 깊은 통합이 결합하면 해자가 완성된다”고 했다. 이번 글은 여기에 한 차원을 추가한다. 개인 맥락의 moat과 집단 운영 지식의 moat이 결합하면, 생태계 수준의 해자가 형성된다.

구체적으로 설명하자. 한 개발자가 Claude Code를 쓰기 시작한다. 먼저 superpowers를 설치하고, andrej-karpathy-skills의 CLAUDE.md를 프로젝트에 복사한다. 이것으로 “커뮤니티가 검증한 모범 사례”가 즉시 적용된다. 그 뒤 몇 주간 사용하면서 개인 맥락이 쌓인다 — “이 프로젝트에서는 이 패턴을 쓰지 않는다”, “이 팀은 리뷰 코멘트를 한국어로 단다” 같은 것들. 동시에 이 개발자가 발견한 새로운 모범 사례가 있다면, 그것을 GitHub에 PR로 올리거나 자체 skills 레포를 만들어 공유한다. 이것이 집단 운영 지식 층에 기여하는 행위다.

이 순환이 돌수록 세 가지가 동시에 강화된다. Claude Code라는 제품의 가치, 개인 사용자의 switching cost, 그리고 커뮤니티 전체의 지식 수준. 세 바퀴가 맞물려 돌아가는 복합 플라이휠이다.

6. 양면 해석: Anthropic의 네트워크 효과 vs 모범사례의 상품화

여기까지 읽으면 “결국 Anthropic이 가장 큰 수혜자 아닌가”라는 결론으로 흐를 수 있다. Claude Code를 더 잘 쓰는 법이 커뮤니티에 의해 결정화되고 공유될수록, Claude Code의 가치가 올라가고, 더 많은 사용자가 유입되고, 더 많은 운영 지식이 쌓인다. 전형적인 네트워크 효과. 맞다. 하지만 이야기의 절반만 맞다.

해석 A — Anthropic의 네트워크 효과

이 해석은 직관적이다. superpowers가 Claude Code를 더 잘 작동하게 만들수록, Claude Code의 실질적 성능은 올라간다. andrej-karpathy-skills가 LLM 코딩의 함정을 교정해줄수록, Claude Code 사용자의 만족도는 높아진다. claude-howto가 진입 장벽을 낮출수록, 신규 사용자 확보가 용이해진다. claudian이 Obsidian으로 표면을 확장할수록, Claude Code의 서식지가 넓어진다.

이 모든 것은 Anthropic이 직접 만들지 않은 것들이다. 커뮤니티가 자발적으로 만든 것들이 Anthropic의 제품 가치를 높이고 있다. 이것은 Android 생태계에서 앱 개발자가 Google의 플랫폼 가치를 높인 것과 같은 구조다. npm 패키지가 Node.js의 가치를 높인 것과 같은 구조다. 플랫폼의 가치는 그 위에 쌓이는 생태계의 두께에 비례한다.

CLAUDE.md라는 파일 형식이 사실상의 표준(de facto standard)이 되고 있다는 점도 중요하다. 경쟁사 — 예를 들어 OpenAI의 Codex — 도 유사한 에이전트 지침 파일을 지원하지만 (AGENTS.md 등), CLAUDE.md라는 이름 자체가 생태계를 선점하고 있다. andrej-karpathy-skills의 핵심 산출물이 CLAUDE.md라는 이름을 달고 있다는 사실 자체가, Anthropic의 브랜드가 이 생태계의 기본값(default)이 되었음을 보여준다.

이 관점에서 보면, Anthropic의 전략적 위치는 대단히 강하다. 모델 성능에서의 리드 + harness의 품질 + 커뮤니티가 만든 운영 지식 층 = 복합적 해자. 경쟁사가 모델 성능을 따라잡아도, 143,712 스타의 superpowers와 10,441 스타의 andrej-karpathy-skills가 Claude Code 생태계에 고정돼 있는 한, 사용자의 기본값은 Claude Code에 머문다.

해석 B — 모범사례의 상품화(commoditization of best practices)

그런데 반대 방향의 해석도 성립한다. 이 해석이 더 미묘하고, 더 중요할 수 있다.

superpowers, andrej-karpathy-skills, claude-howto가 하는 일은 “Claude Code를 잘 쓰는 법”을 누구나 접근할 수 있게 만드는 것이다. 과거에 이 지식은 파워 유저만이 가지고 있었다. 수백 시간의 시행착오를 거쳐 CLAUDE.md를 다듬고, skills를 정의하고, 워크플로를 최적화한 사람들. 이들은 같은 모델을 써도 초보자보다 현저히 나은 결과를 얻었다. 이 격차가 파워 유저의 경쟁 우위였다.

지금 일어나고 있는 일은 이 경쟁 우위의 민주화다. andrej-karpathy-skills를 복사해서 붙여넣으면, 어제 Claude Code를 처음 쓰기 시작한 사람도 파워 유저의 지침을 즉시 적용할 수 있다. superpowers를 설치하면, 소프트웨어 개발 방법론을 수년간 연마한 사람의 규율이 에이전트에 자동으로 심어진다.

이것은 “모범사례의 상품화”다. 이전에는 희소했던 운영 지식이 GitHub을 통해 무료로 배포되면서 희소성을 잃는다. 파워 유저가 가졌던 정보 비대칭이 해소된다. 모든 사람이 “잘 쓰는 법”을 알게 되면, “잘 쓰는 법”은 더 이상 차별화 요소가 아니다. 기본값이 된다.

이것이 Anthropic에 어떤 의미를 갖는가? 두 가지 방향의 함의가 있다.

첫째, 긍정적 방향. 기본값의 수준이 올라가면, 제품 전체의 만족도가 올라간다. 불만족 이탈이 줄어든다. 더 많은 사용자가 Claude Code에서 좋은 경험을 하고, 구독을 유지한다.

둘째, 부정적 방향. 운영 지식이 상품화되면, 그 지식은 플랫폼에 종속되지 않는다. oh-my-codex가 증명하듯, 같은 패턴이 Codex에도 적용된다. superpowers의 방법론 — brainstorming 먼저, plan 먼저, verification 필수 — 은 Claude Code에만 유효한 것이 아니다. 어떤 coding agent에든 적용 가능한 범용 지식이다. 사용자가 이 범용 지식을 체화하면, Claude Code에서 Codex로, 또는 아직 등장하지 않은 새로운 agent로 이동하는 마찰이 줄어든다. 운영 지식이 모델에 종속되지 않는 이상, 그 지식의 축적이 특정 모델의 lock-in을 강화하지 않을 수 있다.

양면이 동시에 작동한다

현실은 해석 A와 B가 동시에 작동하는 것이다. 네트워크 효과와 상품화는 모순되지 않는다. 같은 현상의 두 면이다.

단기적으로는 해석 A가 우세할 것이다. CLAUDE.md라는 이름이 생태계에 고착됐고, superpowers의 skills가 Claude Code에 최적화돼 있으며, claude-howto의 템플릿이 Claude Code 문법에 맞춰져 있다. 이 생태계에서 다른 agent로 이동하려면, 지금까지 쌓인 skills와 templates를 전부 새 환경에 맞게 변환해야 한다. 이것이 switching cost다.

장기적으로는 해석 B가 부상할 가능성이 있다. 운영 지식이 충분히 체계화되고 추상화되면, 특정 도구에 종속되지 않는 범용 프레임워크가 될 수 있다. oh-my-codex가 이미 그 방향의 첫 번째 신호다. “Claude Code를 위한 superpowers”가 아니라 “모든 coding agent를 위한 superpowers”가 등장하는 것은 시간 문제일 수 있다.

이 해석이 이전 글의 lock-in 논의와 어떻게 연결되는가

이전 글 “LLM lock-in의 균열”에서 나는 “하나의 모델에 올인이라는 전제가 흔들리고 있다”고 썼다. 이번 주의 현상은 그 균열의 다른 면을 보여준다. 운영 지식이 결정화되고 공유되면, 모델 간 이동의 마찰이 줄어든다. 반면 생태계의 네트워크 효과가 커지면, 특정 모델 생태계를 떠나는 비용이 올라간다. 두 힘이 반대 방향으로 작용한다. 어느 쪽이 우세해질지는 지금 판단할 수 없다. 3개월 뒤, 6개월 뒤의 데이터가 필요하다.

7. 실무자에게 주는 시사점

이 현상이 매일 코드를 쓰는 개발자, 팀 리드, 엔지니어링 매니저에게 어떤 의미를 갖는가? 추상적인 생태계 분석을 넘어, 구체적인 행동 지침을 도출해보자.

시사점 1 — CLAUDE.md(또는 해당 에이전트의 지침 파일)에 투자하라

andrej-karpathy-skills의 10,441 스타가 말하는 것은, 이 파일 하나가 에이전트 경험의 상당 부분을 결정한다는 것이다. 빈 CLAUDE.md로 Claude Code를 쓰고 있다면, 성능의 상당 부분을 낭비하고 있는 것이다. 엔진은 V8인데 1단 기어로만 달리는 것과 같다.

구체적 행동: andrej-karpathy-skills를 포크해서 프로젝트 루트에 놓되, 그대로 쓰지 말 것. 프로젝트의 맥락에 맞게 수정할 것. 팀의 코딩 컨벤션, 테스트 전략, 커밋 메시지 규칙, 리뷰 기준을 추가할 것. 이 파일을 정기적으로 업데이트할 것 — 에이전트와의 상호작용에서 “이건 아니었다”는 순간이 생기면, 그 교훈을 CLAUDE.md에 반영할 것.

시사점 2 — skills와 methodology를 분리해서 채택하라

superpowers는 skills(개별 기능)과 methodology(작업 흐름)를 모두 포함한다. 두 가지를 구분해서 채택하는 것이 중요하다. skills는 비교적 부담 없이 추가하고 제거할 수 있다. 특정 skill이 현재 프로젝트에 맞지 않으면 끌 수 있다. methodology는 작업 방식 자체를 바꾸는 것이므로, 팀 전체의 합의가 필요하다.

구체적 행동: superpowers의 skills 목록을 검토하고, 현재 워크플로에서 반복적으로 문제가 되는 영역에 해당하는 skill을 우선 채택할 것. 예를 들어, 코드 리뷰가 늘 부족하다면 code-review skill을, 디버깅에 시간을 많이 빼앗긴다면 systematic-debugging skill을. methodology 채택은 별도의 팀 논의로 분리할 것.

시사점 3 — 운영 지식의 버전 관리를 시작하라

CLAUDE.md는 코드처럼 버전 관리해야 한다. 지금 효과적인 지침이 3개월 후에도 효과적이라는 보장은 없다. 모델이 업데이트되면 최적의 지침도 바뀐다. 팀의 규모가 커지면 컨벤션도 바뀐다. 프로젝트 단계가 바뀌면 필요한 에이전트 행동도 바뀐다.

구체적 행동: CLAUDE.md를 Git에 커밋하고, 변경 이유를 커밋 메시지에 기록할 것. “에이전트가 테스트 없이 코드를 생성하는 경향이 있어서 ‘테스트 먼저 작성’ 지침 추가”처럼. 이 이력이 쌓이면, 그 자체로 팀의 에이전트 운영 히스토리가 된다.

시사점 4 — hooks를 설정하라

oh-my-codex가 hooks를 핵심 기능으로 내세운 것은 이유가 있다. 에이전트가 강력해질수록, 에이전트의 행동을 제한하는 메커니즘도 강력해져야 한다. 이것은 권한 관리의 문제이자 리스크 관리의 문제다.

구체적 행동: 에이전트가 절대 건드려서는 안 되는 파일이나 디렉토리를 정의할 것(예: 프로덕션 환경 설정, 인증 키, 데이터베이스 마이그레이션). 에이전트가 외부 서비스를 호출하기 전에 확인을 요구하는 hook을 설정할 것. 에이전트가 일정 규모 이상의 변경을 한 번에 수행하려 할 때 중단하는 hook을 설정할 것.

시사점 5 — 생태계를 관찰하라

2026년 4월 10일 주간에 다섯 개의 메타 도구가 동시 트렌딩한 것은, 이 카테고리가 급격히 성장하고 있다는 신호다. 내일은 또 어떤 도구가 나올지 모른다. 에이전트 운영 도구의 환경은 빠르게 변하고 있다.

구체적 행동: GitHub Trending의 developer tools 카테고리를 주기적으로 확인할 것. superpowers, oh-my-codex 같은 레포의 릴리스 노트를 구독할 것. 이 생태계에서 유용한 도구가 나오면 팀 내에 공유하는 채널을 만들 것.

시사점 6 — 당신의 운영 지식을 환원하라

이 생태계는 사용자의 기여로 성장한다. 당신이 프로젝트에서 발견한 효과적인 에이전트 운영 패턴은, 다른 누군가에게도 유용할 가능성이 높다. 그것을 CLAUDE.md 스니펫으로 정리해서 공유하면, 생태계 전체의 지식 수준이 올라간다. 이것은 이타적 행위이면서 동시에 이기적 행위다 — 생태계의 수준이 올라가면, 그 생태계에서 당신이 받는 도구와 지식의 품질도 올라가기 때문이다.

8. 구조적 해석 — 왜 지금, 왜 동시에

다섯 레포가 같은 주에 동시 트렌딩한 이유를 구조적으로 설명할 수 있는가? 개별 레포의 성공은 각각의 사정이 있겠지만, 동시 발생은 우연이 아니다. 배경에 세 가지 구조적 조건이 있다.

조건 1 — coding agent 사용자 인구의 임계점 도달

Claude Code가 출시된 이후, 사용자 수는 꾸준히 증가했다. 하지만 “메타 도구”가 필요해지려면, 기반 도구의 사용자가 충분히 많아야 한다. oh-my-zsh가 등장한 것도 Zsh 사용자가 일정 규모 이상이 된 후였다. npm 패키지 생태계가 폭발한 것도 Node.js 사용자가 임계점을 넘은 후였다.

2026년 4월 시점에서 coding agent 사용자 수가 이 임계점을 넘은 것으로 보인다. 정확한 수치는 공개되지 않지만, 간접 증거는 있다. superpowers의 143,712 스타는, 이 도구를 한 번이라도 사용해본 사람이 최소 수십만 명은 된다는 것을 시사한다 (스타를 누르는 사람은 실제 사용자의 일부에 불과하므로).

조건 2 — “잘 쓰는 법”의 격차가 가시화됨

coding agent를 처음 쓰는 사람과 6개월간 써온 사람의 생산성 격차는 체감될 수준으로 크다. 이전 글에서 다룬 Maganti의 사례가 이를 보여준다 — 같은 사람이, 같은 모델로, 같은 프로젝트를 만들었는데, 첫 번째 시도(운영 지식 없음)는 스파게티 코드로 전량 폐기되었고, 두 번째 시도(운영 지식 축적 후)는 성공적으로 출시되었다.

이 격차가 가시화될수록, “잘 쓰는 법”에 대한 수요가 폭발한다. andrej-karpathy-skills의 주간 +2,230 스타, claude-howto의 주간 +7,342 스타는 이 수요의 표현이다. 사용자들은 시행착오를 줄이고 싶어하고, 누군가의 검증된 운영 지식을 빨리 가져오고 싶어한다.

조건 3 — 공유 인프라의 성숙

GitHub는 이미 20년 넘게 코드 공유의 인프라로 기능해왔지만, CLAUDE.md라는 파일 형식의 등장은 새로운 종류의 공유를 가능하게 했다. 코드가 아니라 지식을 공유하는 것이다. 그것도 자연어로 된 지식을.

기존에 운영 지식을 공유하려면 블로그 글을 써야 했다. 긴 글을 읽고, 자기 환경에 맞게 해석하고, 수동으로 적용해야 했다. 마찰이 컸다. CLAUDE.md는 이 마찰을 제거했다. 파일 하나를 복사하면 즉시 적용된다. “읽고 이해하고 적용하는” 3단계가 “복사해서 붙여넣는” 1단계로 축약되었다. 이 마찰의 제거가 공유의 속도를 폭발적으로 높인 것이다.

세 조건 — 사용자 인구의 임계점, 격차의 가시화, 공유 마찰의 제거 — 이 동시에 충족된 것이 2026년 4월 10일 주간이다. 그래서 다섯 레포가 같은 주에 폭발한 것이다.

9. IDE 플러그인, 프롬프트 엔지니어링, 그리고 운영 지식 — 세 시대의 비교

이 현상을 더 넓은 역사적 맥락에 놓아보자. 개발자 도구가 “확장”되는 방식은 세 번의 질적 전환을 거쳤다.

시대 1: IDE 플러그인 (2010년대 VS Code extensions)

VS Code가 Extension API를 공개한 후, 수만 개의 확장이 쏟아졌다. Prettier, ESLint, GitLens, Live Share. 이 확장들은 에디터에 기능을 추가했다. 문법 검사, 포맷팅, 버전 관리 통합, 협업. 확장의 본질은 “도구에 기능을 부착하는 것”이다.

이 시대의 핵심 가정은, 도구가 중립적(neutral)이라는 것이다. VS Code는 파이썬도, 자바스크립트도, 러스트도 동등하게 편집할 수 있는 범용 에디터다. 확장은 그 범용성 위에 특화된 기능을 올린다. 도구의 “판단”은 존재하지 않는다. 에디터는 사용자의 키 입력을 충실하게 반영할 뿐이다.

시대 2: 프롬프트 엔지니어링 (2023~2024년)

ChatGPT가 등장한 후, 사용자들은 “어떻게 질문해야 좋은 답이 나오는가”를 탐구하기 시작했다. 프롬프트 엔지니어링이라는 분야가 탄생했다. Twitter에서 프롬프트 팁이 공유되고, GitHub gist에 “best prompts for coding”이 올라왔다.

이 시대의 핵심은, 지식이 일회성이었다는 것이다. “chain of thought를 유도하려면 ‘Let’s think step by step’을 붙여라” — 이것은 팁이지 체계가 아니다. 한 번 적용하면 끝이다. 다음 대화에서 또 기억해서 적용해야 한다. 프롬프트 엔지니어링의 지식은 사용자의 머릿속에 머물렀고, 도구에 반영되지 않았다. 세션이 끝나면 증발했다.

시대 3: 운영 지식의 결정화 (2026년)

지금 일어나고 있는 것은 질적으로 다르다. 사용자의 운영 지식이 파일에 담기고, 그 파일이 에이전트의 행동을 지속적으로 규정한다. 한 번 CLAUDE.md에 적으면 모든 세션에서 작동한다. 한 번 superpowers의 skill로 정의하면 모든 프로젝트에서 호출 가능하다. 지식이 증발하지 않는다. 결정화(crystallize)된다.

세 시대를 비교하면 이렇다.

시대 1: 플러그인시대 2: 프롬프트시대 3: 운영 지식
시기2010s2023~20242026~
대상에디터LLMCoding Agent
확장의 형태코드(확장 프로그램)텍스트(일회성 프롬프트)텍스트(지속적 지침)
도구의 성격중립적(사용자 입력 반영)반응적(질문에 답변)자율적(지침에 따라 판단)
지식의 지속성영구(설치되면 유지)일시적(세션 종료 시 소멸)영구(파일에 결정화)
공유의 단위패키지(.vsix)텍스트 스니펫지침 파일(CLAUDE.md)
레버리지기능 추가답변 품질 향상에이전트 행동 체계 변경

시대 3의 핵심 차이는, 도구가 자율적이라는 것이다. IDE는 사용자가 시킨 대로 한다. LLM은 사용자가 물어본 것에 답한다. Coding agent는 목표를 주면 스스로 판단하고 행동한다. 자율적인 도구에게는 “기능”이 아니라 “판단 기준”을 주어야 한다. 그래서 운영 지식의 형태가 코드 플러그인도, 일회성 프롬프트도 아닌, 지속적 지침 파일이 된 것이다.

이 관점에서 2026년 4월의 다섯 레포는 시대 3의 본격적 개막을 알리는 신호탄이다. 개발자 도구의 확장 방식이 “기능 부착”에서 “운영 지식 주입”으로 전환되고 있다.

10. 열린 질문들 — 이 폭발은 어디로 향하는가

2026년 4월 10일 주간의 현상을 정리하면 이렇다.

하나, coding agent 메타 도구 생태계가 폭발적으로 성장하고 있다. 다섯 개의 레포가 같은 주에 동시 트렌딩했고, 합산 스타 수는 20만 개를 넘는다.

둘, 이 생태계의 핵심 산출물은 코드가 아니라 운영 지식이다. CLAUDE.md 파일, skills 정의, 복사 가능한 템플릿 — 자연어로 된 지식이 제품의 형태를 갖추었다.

셋, 같은 패턴이 Claude Code뿐 아니라 Codex에서도 발생하고 있다(oh-my-codex). 이것은 특정 제품이 아니라 카테고리 수준의 현상이다.

넷, 이 현상은 새로운 종류의 moat을 형성하고 있다. 이전 글에서 다룬 개인 맥락의 moat 위에, 집단 운영 지식의 moat이 추가되고 있다. 동시에 모범사례의 상품화가 진행되면서, 운영 지식이 특정 플랫폼에 종속되지 않을 가능성도 열려 있다.

이 정리 위에서, 열린 질문을 던져본다.

질문 1 — 운영 지식 층은 모델에 종속될 것인가, 범용화될 것인가?

현재 superpowers는 Claude Code에 최적화돼 있다. oh-my-codex는 Codex에 최적화돼 있다. 둘은 같은 구조이지만 호환되지 않는다. 이 분리가 유지될 것인가? 아니면 “모든 coding agent에 적용 가능한 범용 운영 지식 프레임워크”가 등장할 것인가?

만약 범용화된다면, 운영 지식 층은 모델의 lock-in을 약화시킨다 — 어떤 agent로든 같은 skills을 적용할 수 있으니까. 만약 분리가 유지된다면, 각 모델 생태계의 lock-in을 강화한다 — 내 skills를 옮기려면 전부 다시 작성해야 하니까.

질문 2 — Anthropic은 이 생태계를 어떻게 다룰 것인가?

지금까지 Anthropic은 CLAUDE.md와 skills 생태계를 장려하는 방향으로 움직였다. 하지만 이 생태계가 커지면, 통제의 문제가 발생한다. 커뮤니티가 만든 skill이 모델의 한계를 우회하거나, 안전 장치를 약화시키는 경우가 나올 수 있다. Anthropic은 이 생태계를 공식적으로 통합(curate)할 것인가, 방치할 것인가, 아니면 특정 범위 안에서만 허용할 것인가?

Apple의 App Store 전략(엄격한 심사와 통제)과 Google의 Play Store 전략(비교적 개방적 허용)의 차이를 떠올릴 수 있다. Anthropic이 어느 쪽을 택하느냐에 따라 생태계의 성격이 달라질 것이다.

질문 3 — CLAUDE.md는 표준이 될 것인가?

현재 Claude Code는 CLAUDE.md를, Codex는 AGENTS.md를, 다른 도구들은 각자의 형식을 사용한다. 이것이 통합될 것인가? HTML이 웹의 표준 마크업이 되고, Dockerfile이 컨테이너의 표준 형식이 된 것처럼, 에이전트 지침 파일의 표준 형식이 등장할 것인가?

표준이 등장하면, 운영 지식의 이식성(portability)이 높아진다. 한 번 작성한 지침 파일을 여러 agent에서 사용할 수 있게 된다. 이것은 사용자에게는 이득이고, 특정 벤더의 lock-in에는 위협이다.

질문 4 — 운영 지식의 “적용”을 넘어 “생성”을 자동화할 수 있는가?

현재의 운영 지식은 인간이 작성한다. Karpathy가 관찰하고, 누군가가 정리하고, GitHub에 올린다. 하지만 에이전트 자체가 자기의 운영을 관찰하고, 실패 패턴을 감지하고, 최적의 지침을 자동으로 제안하는 것은 가능한가?

“이번 세션에서 에이전트가 3번 같은 실수를 반복했습니다. CLAUDE.md에 다음 지침을 추가할까요: ‘함수가 20줄을 넘으면 반드시 분리할 것‘“이라는 피드백이 자동으로 생성된다면? 이것은 현재의 정적 지식을 동적 학습으로 전환하는 것이다. superpowers 다음 세대의 도구가 이 방향을 탐색할 가능성이 있다.

질문 5 — 당신은 이 생태계에 참여하고 있는가?

마지막 질문은 독자에게 직접 향한다. 당신의 CLAUDE.md는 비어 있는가, 아니면 수개월간 다듬어진 운영 지식이 담겨 있는가? 당신은 남들이 만든 skills를 소비만 하고 있는가, 아니면 당신의 발견을 환원하고 있는가?

이전 글의 결론이 “당신의 에이전트는 사용할수록 나아지는가?”였다면, 이번 글의 결론은 하나 더 추가된다. “당신의 운영 지식은 결정화되고 있는가? 그리고 그 결정체는 다른 사람에게 도달하고 있는가?”

에이전트의 moat은 모델에 있지 않다. 모델 위에 쌓이는 운영 지식 — 개인의 맥락과 집단의 지식이 결합된 층 — 에 있다. 2026년 4월 10일 주간, 다섯 개의 레포가 동시에 그 사실을 가리켰다. 이 방향이 어디까지 갈지는 아직 알 수 없다. 다만 한 가지는 확실하다 — 모델을 잘 만드는 것과 모델을 잘 쓰는 법을 아는 것은 완전히 다른 역량이고, 후자에 대한 시장이 지금 폭발하고 있다.

출처: