22,000개의 별, 20개의 역할 플러그인. 그리고 나는 SQLite 하나를 보고 있었다.
n
22,000개의 별. 20개 역할 플러그인. 금융, 법무, 마케팅, 바이오 연구까지. Anthropic이 Claude를 모든 지식 근로자의 전담 비서로 만들겠다고 선언했다. 근데 그 소식을 보고 든 첫 생각은 “와 대단하다”가 아니었다. “내겐 38MB짜리 SQLite 파일 하나면 충분했는데”였다.
nnnn
이건 기술 선택의 문제가 아니다. 설계 철학의 차이다. Anthropic은 지식 근로자를 위한 마켓플레이스를 만들었다. 나는 지식 근로자를 위한 원시(primitive)를 만들었다. 둘 다 같은 문제를 푼다: “AI가 내 맥락을 이해하게 하는 법.” 그런데 접근이 정반대다.
nnnn
Anthropic이 만든 것: 20개 역할, 50개+ 파트너
nnnn
knowledge-work-plugins는 Anthropic이 7월 12일에 공개한 플러그인 디렉토리다. Claude Cowork(데스크톱)와 Claude Code(CLI)에서 돌아가는 11개의 공식 플러그인과 10개 이상의 파트너 플러그인으로 구성됐다. 48시간 만에 22,000개 별. Karpathy의 autoresearch와 거의 동시에 폭발했다.
nnnn
각 플러그인의 구조는 이렇다:
nnnn
plugin-name/n├── .claude-plugin/plugin.json # 매니페스트n├── .mcp.json # MCP 서버 연결n├── commands/ # 슬래시 명령어n└── skills/ # 도메인 지식 (자동 활성화)nnnn
모든 게 파일 기반이다. 마크다운과 JSON만으로 구성됐고, 코드가 없다. 빌드도 없고 인프라도 없다. 플러그인 설치 한 번으로 Claude가 Product Manager가 되고, Sales가 되고, Legal이 된다. /write-spec을 입력하면 PRD를 쓰기 시작하고, /finance:reconciliation을 입력하면 대사 검증을 한다.
nnnn
제품 관리 플러그인의 예를 보면:
nnnn
- n
- 명령어: /write-spec, /roadmap-update, /synthesize-research, /competitive-brief, /brainstorm
- 스킬: feature-spec, roadmap-management, user-research-synthesis, competitive-analysis
- 커넥터: Slack, Linear, Asana, Jira, Figma, Amplitude, Notion, Fireflies
nnn
nnn
n
nnnn
PM이 “우리 SSO 지원을 추가해야 해”라고 말하면, Claude가 “타겟 유저는 누구?” “제약 조건은?” “성공 메트릭은?”을 질문하고 풀 PRD를 뽑아낸다. 그리고 그 PRD는 Slack으로 공유되고, Linear에 티켓이 생기고, Figma에서 디자인이 연결된다.
nnnn
인상적이다. 정말. Anthropic은 Claude를 “모든 직무의 전문가”로 만드는 생태계를 설계했다. 그들의 가정은 이렇다: “지식 근로자가 AI를 제대로 쓰려면, 각 역할에 특화된 도메인 지식과 도구 연결이 필요하다.”
nnnn
내가 만든 것: 파일 하나
nnnn
같은 기간, 나는 knowledge.db를 만들고 있었다. SQLite 파일 하나에 FTS5(전문 검색)와 Ollama nomic-embed-text 임베딩을 얹었다. 17,614개의 지식 엔트리. 375개 엔티티. 1,063개 관계. 총 38MB.
nnnn
인터페이스는 단 두 가지 프리미티브다: recall(query) — 하이브리드 검색, remember(fact) — 단건 저장. 그게 전부다. Anthropic이 20개 플러그인에 50개+ MCP 서버를 연결한 것과 비교하면, 우스울 정도로 단순하다.
nnnn
그런데 이게 더 잘 맞았다.
nnnn
왜 하나의 프리미티브가 20개 플러그인보다 효과적인가
nnnn
Anthropic의 접근과 내 접근의 차이는 추상화의 방향에 있다.
nnnn
Anthropic은 위에서 아래로 간다. “금융 전문가가 필요해” → “금융 플러그인을 만들자” → “재무제표 분석, 대사 검증, 감사 지원 스킬을 넣자” → “Snowflake, QuickBooks, Slack 커넥터를 연결하자.” 각 역할에 맞춘 수직적 추상화다. 더 많은 역할을 지원하려면 더 많은 플러그인이 필요하다. 선형적으로 확장한다.
nnnn
나는 아래에서 위로 갔다. “AI가 내 맥락을 기억해야 해” → “지식 저장 + 검색 프리미티브가 필요해” → “SQLite로 만들자, FTS5로 텍스트 검색하고, 임베딩으로 의미 검색하고.” 프리미티브는 수직 확장이 필요 없다. “금융 검색”과 “엔지니어링 검색”이 다를 이유가 없기 때문이다. 하나의 메커니즘으로 모든 도메인을 커버한다.
nnnn
| 차원 | Anthropic (마켓플레이스) | Drewgent (프리미티브) |
|---|---|---|
| 추상화 방향 | 수직 (역할별) | 수평 (기능별) |
| 확장 방식 | 플러그인 추가 (선형) | 프리미티브 고도화 (대수) |
| 러닝 커브 | 역할별 학습 필요 | 한 번 배우면 끝 |
| 자유도 | 설계된 워크플로우 내 | 무제한 조합 가능 |
| 맥락 주입 방식 | 플러그인 스킬 → 시스템 프롬프트 | SQLite 검색 → 함수 호출 |
| 유지보수 | 20개 플러그인 × 각각 업데이트 | 파일 하나 |
nnnn
이 표가 말해주는 건 단순한 비교가 아니라, 근본적인 설계 트레이드오프다. Anthropic은 사용 편의성(plug-and-play)을 선택했고, 나는 시스템 단순성(one primitive)을 선택했다. 어느 쪽이 “옳다”의 문제가 아니다. 어느 쪽이 누구에게 맞는가의 문제다.
nnnn
그런데 재미있는 건: 둘 다 파일 기반이다
nnnn
파일 기반 설계라는 공통점이 가장 흥미롭다. Anthropic의 플러그인도 마크다운+JSON 파일이고, knowledge.db도 SQLite 파일이다. 둘 다 데이터베이스 서버가 필요 없고, 둘 다 git으로 버전 관리되고, 둘 다 런타임 의존성이 없다.
nnnn
이건 우연이 아니다. 파일은 AI 에이전트에게 가장 자연스러운 저장소다. 데이터베이스 커넥션 풀도 필요 없고, 네트워크 레이턴시도 없고, 스키마 마이그레이션도 없다. 그냥 파일을 읽고 쓰면 된다. 에이전트가 파일 시스템을 이해하는 건 SQL을 이해하는 것보다 훨씬 쉽다.
nnnn
이 통찰은 최근 몇 개의 주요 프로젝트에서 동시에 나오고 있다. Graphify (82K★)는 로컬 파일 시스템에 그래프를 저장한다. ReefWatch의 Coral은 로컬 SQLite에 모든 실행 기록을 남긴다. Karpathy의 autoresearch (90K★)는 파일 기반의 knowledge base를 핵심으로 설계됐다. 파일로 돌아가는 중이다.
nnnn
마켓플레이스 vs 프리미티브: 나의 교훈
nnnn
Anthropic의 22K 플러그인을 보고 확신한 게 있다. 더 많이 가진 쪽이 아니라, 더 적은 것을 가진 쪽이 유리한 순간이 있다.
nnnn
Drewgent에서 recall/remember라는 두 개의 프리미티브를 고집한 이유는 단순하다: 어떤 질문이 들어올지 모르니까. 금융 검색, 엔지니어링 검색, 마케팅 검색 — 검색의 본질은 같다. “주어진 질문과 가장 관련 있는 정보를 찾아라.” 역할별로 검색 로직을 다르게 가져갈 이유가 없다.
nnnn
반대로 Anthropic은 “PM이 /write-spec을 입력하면 어떤 워크플로우가 필요한가?”라는 질문을 정확히 알고 있다. 그들은 사용례를 특정할 수 있을 때 플러그인이 효과적이라는 가정 위에 설계했다. 둘 다 맞다. 문제의 성격이 다를 뿐이다.
nnnn
내가 Drewgent를 1인 운영하면서 배운 건 이것이다: 혼자일수록 프리미티브에 집중해야 한다. 팀이 있으면 플러그인 생태계가 효과적이다. 각 팀원이 다른 역할을 담당하고, 각 역할에 특화된 도구가 필요하다. 하지만 혼자라면? 나는 PM, 엔지니어, 마케터, 작가를 동시에 해야 한다. 20개 플러그인을 관리할 시간이 없다. 하나의 프리미티브로 모든 역할을 커버하는 게 더 효율적이다.
nnnn
지금 나에게 더 필요한 것
nnnn
Anthropic의 knowledge-work-plugins를 연구하면서, 내 프리미티브에도 더할 게 있다는 걸 깨달았다. 예를 들어:
nnnn
- n
- MCP 커넥터 자동 발견: Anthropic의 플러그인이 `.mcp.json` 하나로 모든 도구를 연결하듯, knowledge.db도 외부 도구의 스키마를 자동으로 발견하고 연결할 수 있어야 한다.
- 상태 기반 컨텍스트: Anthropic의 ‘skills’는 에이전트가 특정 도메인에 있을 때 자동으로 활성화된다. knowledge.db의 GraphRCA도 유사한 역할을 하지만, “지금 나는 PM 모드야”라는 상태를 인식하는 계층이 더 필요하다.
- 파일 기반 템플릿: 플러그인이 명령어별로 정형화된 출력(PRD, 스펙, 경쟁사 분석)을 제공하듯, 나도 자주 쓰는 출력 형식을 프리미티브 위에 템플릿으로 얹을 수 있다.
nnn
nnn
n
nnnn
하지만 이 모든 건 프리미티브 위에 얹는 레이어여야 한다. 결코 프리미티브를 대체하면 안 된다. 22K 플러그인을 다운받기보다, 내 파일 하나를 더 잘 쓰는 쪽을 선택하겠다.
nnnn
읽어주셔서 감사합니다
nnnn
이 글은 Anthropic을 깎아내리려는 게 아니다. 오히려 반대다. 22,000명이 검증한 접근법과, 1명이 검증한 접근법을 비교할 기회가 흔치 않기 때문에 썼다. 내가 만든 프리미티브가 더 “옳다”고 생각하지 않는다. 다만, 이 한 가지는 분명히 말할 수 있다: 나 같은 1인 빌더에게는, 마켓플레이스보다 프리미티브가 더 나은 출발점이다.
nnnn
무슨 툴을 쓰든, 어떻게 접근하든, 결국 핵심은 같다: AI가 당신의 맥락을 이해하게 하라. Anthropic은 그 방법으로 20개의 플러그인을 선택했다. 나는 38MB의 SQLite를 선택했다. 그리고 둘 다 작동한다.
nnnn
다음 글에서는 knowledge.db의 내부 구조와 GraphRCA가 실제로 어떻게 에이전트의 추론을 개선하는지 더 자세히 다뤄보겠다.
nn