문제점

Model Context Protocol (MCP)는 AI 에이전트가 컨텍스트 윈도우 (context window)에 쏟아부어진 가공되지 않은 텍스트를 보고 추측하는 대신, 구조화된 도구 (structured tools)를 호출할 수 있게 해줍니다. 이론적으로는 훌륭하지만, 대부분의 MCP 통합은 단순히 "파일 읽기"와 "검색" 기능만을 노출하며, 이는 채팅창에 코드를 복사하여 붙여넣는 것보다 크게 나을 것이 없습니다.

진정한 질문은 이것입니다: 특히 코드베이스 작업을 위해 에이전트가 실제로 어떤 도구에 접근할 수 있어야 하는가?

아키텍처: 세 가지 도구 카테고리

Spiderbrain의 MCP 서버는 세 가지 기능 그룹으로 나뉜 28개의 도구를 노출합니다:

코드베이스 도구 (Codebase Tools) (17개)

평면적인 컨텍스트 윈도우 (context window)로는 도저히 답할 수 없는 구조적 질의 (structural queries):

blast_radius(path)      // 영향 범위, 호출자, 전이적 영향
score_summary()          // 핵심 요소, 사각지대, 노드 점수
communities()            // 클러스터, 경계 엣지, 경로
...

메모리 도구 (Memory Tools) (9개)

메모리 트리 (Memory Tree)에 대한 접근 — 세션 전반에 걸쳐 유지되는 프로젝트의 축적된 결정 사항 및 제약 조건:

memory_recall(files)     // 현재 컨텍스트를 위한 범위 지정 브리핑
memory_search(query)    // 전체 트리에 대한 시맨틱 검색 (semantic search)
memory_add(node)       // 명시적인 사용자 승인을 통한 쓰기
...

블루프린트 도구 (Blueprint Tools) (2개)

spiderbrain_blueprint_read()   // 현재 노드, 엣지, 주석
spiderbrain_blueprint_draw()   // AI가 캔버스 편집을 제안 — 인간의 수락 필요

구현: 어떤 도구를, 언제 호출할 것인가

매 턴마다 28개를 모두 호출하지 마세요. 그것은 컨텍스트가 아니라 노이즈입니다. 다음은 실질적인 디스패치 테이블 (dispatch table)입니다:

이러한 매핑은 도구의 개수보다 더 중요합니다. 28개의 도구를 가지고 있으면서 디스패치 로직 (dispatch logic)이 없는 에이전트는 도구를 하나도 호출하지 않거나 전부 호출하게 될 것입니다. 두 경우 모두 적절한 순간에 실제로 사용할 수 있는 5개의 도구를 가진 에이전트보다 못합니다.

학습 내용

이 특정 서버를 넘어 일반화할 수 있는 패턴은 다음과 같습니다: MCP 도구를 데이터 모델(data model) 중심이 아닌, 워크플로우(workflow)의 순간(moments)을 중심으로 구조화하십시오. "새 프로젝트(New project)", "편집 전(before editing)", "세션 시작(session start)", "리팩터링(refactor)", "온보딩(onboarding)"은 개발자나 에이전트가 실제로 마주하는 순간들입니다. 반면 "노드 가져오기(Get node)", "엣지 가져오기(get edge)", "커뮤니티 가져오기(get community)"는 그저 도구 호출(tool-call)의 탈을 쓴 데이터베이스 작업일 뿐입니다.

리소스 (Resources)

• Spiderbrain은 Local에서 무료로 사용할 수 있으며, Pro 및 Cortex에서는 호스팅된 브레인(hosted brain)을 사용할 수 있습니다.
• 관련 자료: Every AI Coding Assistant Sees Your Files, Not Your Architecture (이 도구들이 쿼리하는 기반 그래프 모델에 관한 내용)

토론: 다른 분들도 본인의 MCP 서버를 위해 "순간 기반(moment-based)" 도구 디스패치(dispatch) 패턴을 채택하셨나요? 어떤 상황에 게이트(gate)를 설정하시는지 궁금합니다.