6월 한 달 동안 트렌드 하 에이전트 nts/”>에이전트 ion/”>에이전트 nts/”>에이전트 ion/”>에이전트 nts/”>에이전트 ard/”>에이전트 ark/”>에이전트 %ac/”>에이전트 GitHub에서 수집한 에이전트 관련 도구는 364개다. 코드 분석, 메모리, 자동화, SEO — 도메인은 다 달라도 한 가지 공통점이 있다. 아니라 MCP 서버나 Claude Code 스킬로 포장되어 있다.

이게 그냥 “AI 붐”이 아니라는 걸 깨닫는 데는 오래 걸리지 않았다. 생태계의 기본 단위가 바뀌고 있다. 앱도 아니고, API도 아니고, 라이브러리도 아니다. 새로운 기본 단위는 에이전트가 소비할 수 있는 능력(capability)이다.

이 글은 그 패턴을 5개 도구에서 추출하고, 이게 빌더에게 무슨 의미인지 정리한 기록이다.

이 글에서 다루는 것

364개 트렌드 아이템에서 발견한 하나의 공통 패턴 코드 분석·메모리·SEO 도메인에서 동시에 일어나고 있는 일 왜 ‘기능의 차이’가 아니라 ‘발견 가능성’이 승부처가 되었는가 Drewgent의 ARD가 이 싸움에서 의미하는 것 살아남는 도구의 조건 — 4가지 기준

5개 도구, 1개 패턴

트렌드 하베스터가 keep(보류) 또는 discuss(논의 중)으로 분류한 아이템 중, 서로 완전히 다른 도메인의 5개를 골랐다. 겉보기에는 아무 연관도 없어 보인다.

도구도메인점수형태

gortex코드 인텔리전스 (257개 언어, 50x 토큰 절감)8.27MCP Server + CLI + API codegraph-rust코드 graphRAG (Rust, AST+FastML)7.73MCP Server MemOS에이전트 메모리 OS (하이브리드 검색, 35% 토큰 절감)7.05라이브러리 → MCP engram영구 메모리 (Go, SQLite+FTS5)7.86MCP Server + HTTP API + CLI geo-seo-claude생성형 검색 최적화 (GEO)7.41Claude Code Skill

5개의 도메인이 전부 다르다. 언어도 Go, Rust, TypeScript, Python으로 제각각이다. 하지만 배포 형태는 전부 같다: MCP 서버 또는 Claude Code 스킬.

이 패턴은 우연이 아니다. 364개 전체를 훑어보면 같은 현상이 반복된다. RAG 도구, 크롤링 도구, 테스트 자동화 도구 — 죄다 “에이전트가 쓸 수 있는 형태”로 포장되어 나온다.

무슨 일이 일어나고 있는가

세 가지 레이어에서 동시에 변화가 일어나고 있다.

  1. 코드 인텔리전스의 MCP화. gortex(8.27)와 codegraph-rust(7.73)는 ‘코드 검색 엔진’이라는 같은 문제를 푼다. Drewgent가 이미 codebase-memory-mcp로 해결한 영역이다. 평가 로그에서도 “competitive with codebase-memory-mcp”라고 분류됐다. 중요한 건 둘이 경쟁한다는 사실이 아니라, 둘 다 ‘독립 실행형 CLI’가 아니라 ‘에이전트용 MCP 서버’라는 점이다. 더 이상 개발자가 터미널에서 수동으로 검색하는 시대가 아니다. 에이전트가 컨텍스트 창에 필요한 정보만 주입받는 시대다.
  1. 메모리 시스템의 범람. MemOS, engram, cognee — 셋 다 에이전트를 위한 영구 기억 장치다. “에이전트가 세션 간에 뭘 기억하게 할 것인가”는 지금 업계 전체의 미해결 숙제다. Drewgent는 gbrain + Obsidian vault(P0-P6) + Karpathy compile 패턴으로 이미 구조화했지만, 이 도구들은 저마다 다른 접근을 시도 중이다. MemOS는 하이브리드 검색, engram은 SQLite+FTS5, cognee는 지식 그래프. 아직 정답은 없다. 다만 모두가 MCP 서버로 나온다는 건, 정답이 뭐든 간에 배포 방식만은 정해졌다는 뜻이다.
  1. 도메인 특화 스킬의 등장. geo-seo-claude는 Claude Code용 스킬이다. AI 검색 엔진(ChatGPT, Claude, Perplexity, Google AI Overview)을 겨냥한 웹사이트 최적화를 수행한다. 전통 SEO가 아니라 GEO(Generative Engine Optimization) — AI가 콘텐츠를 인용할 확률을 높이는 작업이다. 이건 SEO 도구가 아니라, 에이전트가 직접 실행하는 SEO 스킬이다. 도메인 지식을 코드로 박아서 Claude Code에 주입한 셈이다.

ngraph TDn subgraph “과거: 개발자 중심”n A[CLI 도구] –> B[개발자가 실행]n C[라이브러리] –> D[개발자가 통합]n E[API] –> F[개발자가 호출]n endn n subgraph “현재: 에이전트 중심”n G[MCP Server] –> H[에이전트가 발견·호출]n I[Claude Code Skill] –> J[에이전트가 실행]n K[ai-catalog.json] –> L[에이전트가 검색]n H –> M[에이전트가 결과 소비]n J –> Mn L –> N[에이전트가 선택]n endn n style G fill:#1a1a35,stroke:#4a90d9n style I fill:#1a1a35,stroke:#50c878n style K fill:#1a1a35,stroke:#7b5f3dn

살아남는 조건 — 기능이 아니라 발견 가능성

도구들이 전부 MCP 서버가 되는 세상에서, 어떤 도구가 살아남을까?

더 이상 기능의 우위로 결정되지 않는다. gortex가 codegraph-rust보다 토큰을 10% 더 아낀다고 해도, 에이전트가 gortex의 존재를 모르면 아무 의미가 없다. 마찬가지로 engram이 MemOS보다 쿼리가 빠르다고 해도, 에이전트가 engram의 MCP 엔드포인트를 찾지 못하면 죽은 프로젝트다.

승부는 ‘발견 가능성(discoverability)’으로 이동했다.

이게 바로 ARD(Agentic Resource Discovery)의 문제의식이다. 에이전트가 능력을 발견하고 호출할 수 있어야 한다. 내가 6월에 ARD 구현기를 썼을 때는 Google·Microsoft가 발표하기도 전이었다. 당시에는 “선제적 taste”라고 불렀는데, 지금 보면 시장 전체가 같은 방향으로 가고 있다.

AI에게 주도권을 빼앗기지 마세요 — 두 번의 자동화 실패에서 배운 것 단일 모델 의존은 시스템 취약성이다 — AI 에이전트 모델 라우팅 설계

Drewgent가 /.well-known/ai-catalog.json을 서빙하는 건 단순한 스펙 준수가 아니다. 발견 가능성이라는 새로운 경쟁 축에 먼저 올라탄 것이다.

살아남는 MCP 서버의 조건

  1. Discoverable — 에이전트가 찾을 수 있어야 한다. ai-catalog.json이나 ARD 레지스트리가 없는 MCP 서버는 존재하지 않는 것과 같다.
  2. Reliable — stateless, idempotent, fast. 에이전트는 느린 도구를 기다려주지 않는다.
  3. Sharp — 한 가지 일을 깊게. “무엇이든 다 하는” MCP 서버는 에이전트가 기피한다. gortex가 “필요한 정보만 노출, 토큰 50x 절감”이라고 말하는 것도 같은 맥락이다.
  4. Tasteful — 좋은 판단으로 설계된 도구. 도구가 에이전트에게 뭘 숨기고 뭘 보여줄지 아는 것. Ponytail 원칙을 MCP 서버 설계에 적용하는 것.

메모리가 다음 병목이다

트렌드 하베스터에서 메모리 관련 도구가 3개나 keep/discuss에 올라온 건 우연이 아니다. 에이전트 생태계가 컨텍스트 주입(MCP로 ‘보기’) → 실행(Claude Code로 ‘하기’) → 기억(MemOS 등으로 ‘간직하기’) 순으로 발전 중이기 때문이다.

보기와 하기는 이미 MCP로 표준화됐다. 남은 건 간직하기다. 에이전트가 어제 한 일을 오늘 기억하는 것, 지난 버그 수정에서 배운 교훈을 다음 PR에 적용하는 것. engram의 README에 “agent-agnostic persistent memory”라고 적힌 이유다.

Drewgent는 이 문제를 gbrain + P0-P6 vault + Karpathy compile 패턴으로 해결했다. raw data(P2 hippocampus) → compiled wiki(P5 ego) → query-first routing. 7-layer agent brain 설계 글에서 자세히 다뤘다. 외부 도구들이 비슷한 문제를 다른 방식으로 풀고 있다는 건, 내가 짚은 문제가 진짜라는 방증이다.

ngraph LRn subgraph “MCP 표준화 완료”n A[코드 분석] –> D[MCP Server]n B[웹 크롤링] –> Dn C[SEO 최적화] –> Dn endn n subgraph “진행 중: 메모리”n E[MemOS] -.-> F[표준 없음]n G[engram] -.-> Fn H[cognee] -.-> Fn endn n subgraph “Drewgent의 답”n I[gbrain + P0-P6 vault] –> J[filesystem-as-truth]n I –> K[Karpathy compile]n I –> L[P2 raw → P5 compiled]n endn n D –> M{발견? ARD}n F –> N{누가 이길까?}n n style D fill:#1a1a35,stroke:#4a90d9n style F fill:#1a1a35,stroke:#f85149,stroke-dasharray: 5 5n style I fill:#1a1a35,stroke:#50c878n

빌더에게 의미하는 것

도구를 만들고 있다면, 이제 선택지가 바뀌었다.

CLI만 만드는 건 의미가 없다. 에이전트는 CLI를 못 쓴다. MCP 서버를 함께 내야 한다. 기능 경쟁은 끝났다. gortex와 codegraph-rust가 같은 걸 한다. 차이는 토큰 몇 퍼센트, 언어 몇 개 지원. 이걸로는 이길 수 없다. 발견 가능성이 무기다. /.well-known/ai-catalog.json을 서빙하지 않는 MCP 서버는 고아다. 날카로움이 방어력이다. “모든 걸 다 하는” 도구는 에이전트가 혼란스러워한다. 한 가지를 깊게 하는 도구가 선택된다. Taste로 차별화하라. 뭘 숨기고 뭘 보여줄지 아는 도구. Ponytail 원칙 — “이 정보가 정말 필요한가?”

내 선택: 발견 가능성에 먼저 투자했다

Drewgent가 ARD 카탈로그를 6월 초에 이미 구현한 건 결과론적으로 옳은 판단이었다. 364개 도구가 쏟아지는 와중에, Drewgent의 MCP 툴들은 ai-catalog.json에 정확한 capability description과 representative queries가 기술되어 있다.

에이전트가 “코드에서 auth 로직을 찾아줄 MCP 서버”를 검색하면, Drewgent의 codebase-memory-mcp가 발견된다. gortex나 codegraph-rust보다 좋아서가 아니라, 찾을 수 있기 때문에.

이게 contraction 철학과 만나는 지점이다. 덜어내는 것과 연결하는 것은 같은 작업이다. 안으로 줄이고(14→6 agents, 43→25 scripts), 밖으로 연결한다(ARD로 discoverable하게). 줄이지 않으면 연결할 게 너무 많아진다. 연결하지 않으면 줄인 의미가 없다.

Contraction + ARD = Taste Engine Contraction (안으로): 14→6 agents, 43→25 scripts, P-layer 통합, cron 30→12 → 줄여야 연결할 게 명확해진다 ARD (밖으로): ai-catalog.json, /.well-known/, MCP capability description → 연결해야 에이전트가 발견한다 둘은 같은 작업의 양면이다. 내부를 정리하는 것과 외부에 노출하는 것.

마치며

364개를 보고 깨달은 건 단순하다. 시대가 바뀌었다. 도구의 사용자는 더 이상 인간이 아니다. 에이전트가 도구를 고른다. 에이전트에게 보이지 않으면, 존재하지 않는 것과 같다.

이건 무서운 얘기가 아니다. 오히려 기능 경쟁에서 풀려난다는 뜻이다. gortex보다 토큰을 5% 더 아끼는 데 집착할 필요가 없다. 대신 “내 도구를 에이전트가 어떻게 찾게 할 것인가”에 집중하면 된다. 발견 가능성, 신뢰성, 날카로움, taste — 이 네 가지가 새로운 경쟁 축이다.

그리고 이건 이미 하고 있던 일이다. contraction으로 안을 정리하고, ARD로 밖을 연결하는 것. 에이전트 도구의 시대에 살아남는 법은 이미 Drewgent 안에 있었다.

이 글은 Season 1: Taste Engineering의 Phase 3 — ‘시장 분석’ 편이다. Phase 1은 contraction 기록, Phase 2는 모델 라우팅·7-layer brain·cron 전환·15개 프로필의 아키텍처 deep-dives였다. Phase 3에서는 시장의 움직임을 Drewgent의 설계 결정과 교차 검증한다.

데이터 출처: Drewgent Trend Harvester 2026-06-27 평가 (364개 중 keep/discuss 아이템 분석). gortex, codegraph-rust, engram, MemOS, geo-seo-claude 상세 점수는 @memory/growth/trend-harvester/analyzed/keep/ 참조.

읽어줘서 고맙다.