이번 Trend Harvester 사이클에서 8점 이상짜리 keep 아이템을 정리하다가 패턴 하나를 봤다.

gortex (8.27) — 257개 언어를 지원하는 code intelligence + MCP 서버. 내가 쓰는 codebase-memory-mcp와 정면으로 경쟁한다. Engram (7.86) — Go + MCP + SQLite 기반의 경량 agent memory. gbrain과 경쟁한다. 에이전트 anager (7.59) — 스킬 레지스트리/크로스 싱크. 내 에이전트 s-truth 접근과 경쟁한다. Chrome DevTools MCP (7.73) — 브라우저 디버깅/퍼포먼스 계측을 MCP로. 새 능력을 추가한다. claude-squad (7.32) — 멀티 에이전트 오케스트레이션. GJC Coordinator와 경쟁한다.

code intelligence, agent memory, skill registry, monitoring, multi-agent orchestration. 에이전트 툴링 스택의 모든 레이어가 동시에 MCP-ified되고, 파편화되고 있다.

패턴: 매 레이어마다 3~5개의 경쟁자가 생긴다

스택을 레이어별로 나눠보면 이렇다:

┌─────────────────────────────────────────────────────┐ │ Monitoring Layer │ │ Chrome DevTools MCP (7.73) │ Playwright MCP │ │ Puppeteer MCP │ web-perf skill │ ├─────────────────────────────────────────────────────┤ │ Orchestration Layer │ │ claude-squad (7.32) │ GJC Coordinator │ │ task() / delegate() │ A2A protocol │ ├─────────────────────────────────────────────────────┤ │ Skills Layer │ │ skills-manager (7.59) │ filesystem-as-truth │ │ .cursor/rules │ SKILL.md convention │ ├─────────────────────────────────────────────────────┤ │ Code Intelligence Layer │ │ gortex (8.27) │ codebase-memory-mcp │ │ Aider MCP │ Sourcegraph Cody │ ├─────────────────────────────────────────────────────┤ │ Memory Layer │ │ Engram (7.86) │ gbrain │ │ Mem0 │ ChromaDB │ └─────────────────────────────────────────────────────┘

각 레이어마다 3~5개씩, MCP 프로토콜로 연결 가능한 도구들이 쏟아지고 있다. 하루가 멀다 하고 새로운 게 나온다.

문제는 이거다. ‘어느 게 최고인가’는 틀린 질문이다. 3개월 뒤에 더 나은 게 나올 거고, 6개월 뒤엔 표준이 바뀔 거다. 매번 새 도구로 갈아타는 건 불가능하다. 그렇다고 아무거나 골라서 고착되는 것도 위험하다.

인사이트: 아키텍처가 도구를 이긴다

Drewgent에서 내린 결정은 이랬다.도구를 feature list로 고르지 않고, 아키텍처에 맞는지를 봤다.

code intelligence → codebase-memory-mcp. gortex가 257개 언어를 지원한다고? 좋다. 하지만 내 코드베이스는 Python + TypeScript + shell이다. tree-sitter call graph를 PGLite에 저장하고 code_callers/code_callees/code_flow로 탐색하는 접근이 filesystem-as-truth 철학과 맞았다. agent memory → gbrain. Engram이 Go로 가볍다고? 좋다. 하지만 takes, facts, typed links, Cypher 쿼리, wiki compile, dream cycle을 가진 gbrain이 layered brain(P0-P6) 설계와 맞았다. skill registry → filesystem-as-truth. skills-manager가 중앙 레지스트리로 싱크한다고? 흥미롭다. 하지만 나는 SKILL.md 파일을 디스크에 두고, skill(“name”)으로 로드하고, git으로 버전 관리하는 접근을 택했다. 파일시스템 자체가 레지스트리다. orchestration → GJC Coordinator. claude-squad가 멀티 에이전트를 팀으로 묶는다고? 좋다. 하지만 worktree isolation + tmux 병렬 실행 + structured workflow(deep-interview/ralplan/ultragoal)를 가진 GJC가 내가 원하는 격리 수준과 맞았다.

네 가지 선택 모두, ‘기능이 더 많아서’가 아니라 ‘아키텍처와 맞아서’였다.

평가 프레임워크: 기능 리스트 대신, 아키텍처 적합도

Trend Harvester에 새 도구가 들어올 때마다 나는 같은 질문을 던진다:

내 아키텍처의 어떤 레이어와 경쟁하는가? — 전체를 갈아치워야 하면 점수 깎임. 한 컴포넌트만 교체 가능하면 점수. filesystem-as-truth 원칙과 충돌하는가? — DB/API에 상태를 숨기면 탈락. 파일에 명시적으로 상태를 남기면 점수. 내가 이미 가진 것보다 2배 이상 나은가? — 20% 개선은 갈아탈 가치가 없다. 마이그레이션 비용이 더 크다. 철학이 맞는가? — Ponytail 원칙(yagni, less over more), layered brain(P0-P6), taste-driven selection과 부합하는가.

이 평가 프레임워크를 통과한 도구만 keep에 남는다. 통과하지 못한 건 applied로 보내거나 retired로 보낸다. 점수가 높다고 무조건 받아들이지 않는다.

결과: 쪼개질수록 강해지는 구조

아이러니하게도, 툴링 스택이 빠르게 쪼개질수록 아키텍처의 가치는 올라간다.

2026년 6월 현재, 내 스택은 이렇다:

Monitoring → launchd watchdog + cron health check + Chrome DevTools MCP Orchestration → GJC Coordinator (worktree + tmux + structured workflow) Skills → filesystem (~/.drewgent/skills/**/SKILL.md) Code Intel → codebase-memory-mcp (PGLite + tree-sitter call graph) Memory → gbrain (PGLite + semantic search + typed links + takes)

각 레이어가 독립적이기 때문에, 새 도구가 나타나면 해당 레이어만 평가하면 된다. 예를 들어 gortex가 codebase-memory-mcp보다 2배 나은 게 증명되면, code intelligence 레이어만 교체하면 된다. 나머지 4개 레이어는 그대로다.

이게 모놀리식 아키텍처와의 차이다. 하나의 올인원 플랫폼에 올라탔다면, 한 컴포넌트가 시대에 뒤쳐질 때 전체를 마이그레이션해야 한다. 레이어드 아키텍처에서는 그 레이어만 갈아끼우면 된다.

p.s. — 도구의 홍수 속에서 설계가 구명정이다

v0.8 simplification 포스트에서 14개 에이전트를 6개로 줄인 이야기를 썼다. 이번 인사이트는 그 연장선에 있다. 안으로는 줄이고(contraction), 밖으로는 연결하되(ARD), 선택은 아키텍처로 한다.

툴링 스택이 쪼개지는 걸 두려워할 필요는 없다. 평가 프레임워크를 가진 아키텍처가 있다면, 쪼개짐은 오히려 더 나은 부품을 고를 기회다. 기능 리스트가 아니라, 철학이 도구를 고른다.

그리고 철학은 공짜다.

이 글은 Trend Harvester 2026-06-27 사이클의 keep 아이템에서 발견한 패턴을 기반으로 썼다. gortex(8.27), Engram(7.86), Chrome DevTools MCP(7.73), skills-manager(7.59), claude-squad(7.32) — 각각 다른 레이어, 같은 질문.