이 글에서 다루는 내용
Serena MCP와 Graphify는 둘 다 AI 코딩 어시스턴트의 토큰 절감을 노리는 도구입니다. Claude Code·Cursor·Codex 같은 도구의 가장 큰 비용 발생 지점인 "코드 검색 단계의 토큰 폭발"을 다른 방식으로 풀어냅니다. Serena는 LSP 기반 실시간 인덱스로, Graphify는 사전 컴파일된 지식 그래프로 같은 문제를 푸는데, 두 접근의 강점과 약점은 정반대 방향입니다. 이 글은 두 도구의 정체부터 동작 방식·정확도·자료 범위·한계, 그리고 어떤 상황에 어느 쪽을 써야 하는지, 마지막으로 둘을 함께 쓰는 셋업까지 비교 표로 정리합니다. 기준 시점은 2026년 5월입니다.
1. 한 줄 요약 - 정체와 패러다임
| 항목 | Serena MCP | Graphify |
|---|---|---|
| 한 줄 정체 | "IDE의 능력을 LLM에게 넘긴다" | "코드베이스를 한 번 컴파일해 둔다" |
| 패러다임 | 실시간 인덱스 (Always-Live) | Compile Once, Query Forever |
| 만든 곳 | oraios (oraios/serena) | safishamsi (safishamsi/graphify) |
| 기반 기술 | Language Server Protocol (LSP) | tree-sitter AST + Leiden 클러스터링 |
한 줄로 정리하면 둘은 같은 목표(토큰 절감)를 향해 정반대 방향에서 출발합니다. Serena는 IDE가 항상 코드를 이해하고 있는 상태를 활용하고, Graphify는 코드를 한 번 정리해 둔 산출물을 활용합니다.
2. 작동 메커니즘 - 실시간 LSP vs 정적 그래프
가장 큰 구조적 차이는 "답이 어디서 오느냐"입니다.
Serena는 백그라운드에 LSP 서버를 띄워 두고, LLM이 질문할 때마다 LSP에 실시간으로 묻습니다. VS Code·JetBrains가 자동 완성·정의로 점프·참조 찾기에 쓰는 그 LSP를 그대로 재활용합니다. 코드가 바뀌면 LSP가 자동으로 인덱스를 갱신하므로, 항상 최신 상태에 가까운 답을 반환합니다.
Graphify는 한 번 실행되면 tree-sitter로 AST를 추출하고 Leiden 알고리즘으로 클러스터링해서 그래프 한 개를 정적 산출물로 떨굽니다. 이후 모든 쿼리는 그래프만 보고 답합니다. 코드가 바뀌면 다시 빌드하거나 git commit 훅으로 자동 재빌드를 걸어야 합니다.
💡 Serena는 "살아 있는 LSP", Graphify는 "정적 그래프 산출물". 같은 코드베이스를 두 도구로 다루면 답을 끌어오는 출처가 다릅니다.
3. 사전 준비와 첫 실행
| 단계 | Serena MCP | Graphify |
|---|---|---|
| 사전 도구 | UV(uvx) | Python 3.10+ |
| 설치 | claude mcp add serena -- uvx ... 한 줄 |
pip install graphifyy && graphify install 한 줄 |
| 첫 실행 | 자동 온보딩 1~3분 (LSP 인덱싱) | /graphify . → 3-pass 컴파일 |
| 산출물 | 없음 (메모리·LSP만) | graph.html, graph.json, GRAPH_REPORT.md |
| 코드 변경 반영 | 자동 (LSP가 변경 감지) | 수동 또는 graphify hook install 자동 재빌드 |
Serena는 "한 번 등록하면 늘 살아 있는" 형태이고, Graphify는 "주기적으로 컴파일하는" 형태입니다. 자동화 관점에선 Serena가 손이 덜 가지만, Graphify는 산출물(그래프 시각화·리포트)이 따로 남는다는 부수 효과가 있습니다.
4. 정확도 보증의 출처가 다르다
Serena의 정확도는 LSP가 보증합니다. 함수 정의·참조·이름 변경은 LSP가 컴파일러 수준으로 정확히 파악하므로, 호출 위치 검색에서 False Positive가 거의 0에 수렴합니다. 다만 LSP가 모르는 영역 — 주석·문서·일부 동적 바인딩 — 은 비어 있습니다.
Graphify의 정확도는 두 단계로 갈라집니다.
- Pass 1·2 (AST·전사) — 결정론적이라 100% 정확
- Pass 3 (의미 추출) — LLM이 만들어내므로 환각 가능. 단,
INFERRED플래그와 신뢰도 점수가 붙어 사후 구분 가능
요약하면 Serena는 코드 구조에서 더 정확하고, Graphify는 문서·의미적 연결까지 포함하지만 그 영역에서 약간의 잡음을 감수합니다.
5. 다루는 자료의 범위
두 도구의 활용 영역이 의외로 다른 부분입니다.
| 자료 유형 | Serena | Graphify |
|---|---|---|
| 애플리케이션 코드 (30+ 언어) | ✅ (LSP 지원 범위) | ✅ (tree-sitter 19+ 언어) |
| SQL 스키마 | ❌ | ✅ |
| 인프라 설정 (Terraform·YAML) | ❌ | ✅ |
| 문서 (Markdown·PDF) | ❌ | ✅ |
| 영상·음성 전사 | ❌ | ✅ (faster-whisper) |
| 이미지·다이어그램 | ❌ | ✅ (Pass 3, LLM 처리) |
Serena는 "코드만" 봅니다. Graphify는 앱 코드 + DB 스키마 + 인프라 + 문서 + 영상 + 이미지가 한 그래프에 들어간다는 점이 결정적 강점입니다. 코드와 비코드 자료가 섞인 R&D 프로젝트나 큰 모노레포에서 이 차이가 가장 크게 벌어집니다.
6. 토큰 절감 메커니즘 - 같은 작업의 흐름 비교
예시 작업: "getUserById 호출 모든 곳을 새 시그니처로 바꿔 줘."
| 단계 | 기본 (grep + Read) | Serena | Graphify |
|---|---|---|---|
| 정의 찾기 | grep 30건 + 파일 5개 통째로 읽기 | find_symbol 1건만 반환 |
그래프 노드 1개 조회 |
| 호출 위치 | grep -r → 호출·주석·문서·테스트 모두 매칭 | find_referencing_symbols 정확 |
그래프 엣지 N개 조회 |
| 실제 편집 | LLM이 부분 편집, 매번 파일 재읽기 | replace_symbol_body가 LSP로 원자 편집 |
위치 정보 제공, 편집은 LLM 몫 |
핵심 차이는 편집까지의 토큰 효율성입니다. Serena는 검색·이해·편집을 모두 토큰 효율적으로 끝내고, Graphify는 검색·이해 단계에서 강하지만 실제 편집은 LLM이 직접 해야 합니다. 둘 다 grep 기반보다 압도적으로 적은 토큰으로 끝나지만, "편집이 많은 작업"은 Serena가 한 단계 더 유리합니다.
7. 프로젝트 규모별 효과
| 규모 | 권장 |
|---|---|
| 50K LOC 이하 소규모 | 둘 다 오버킬에 가까움. 기본 grep/Read로 충분 |
| 50K~500K LOC 중규모 | Serena가 1순위. 편집·리팩터 위주라면 효과 즉시 체감 |
| 500K LOC+ 또는 비코드 자료 다수 | Graphify의 그래프가 지도 역할. 새 개발자 온보딩·아키텍처 이해에 강력 |
8. 한계 - 어디까지가 약점인가
| 관점 | Serena | Graphify |
|---|---|---|
| 언어 약점 | LSP가 약한 언어(일부 DSL)에선 효과 제한 | tree-sitter 미지원 언어 누락 |
| 자원 사용 | 프로젝트당 LSP 인스턴스 → RAM 점유 | 초기 컴파일에 LLM 토큰 한 번 크게 |
| 코드 외 자료 | 전혀 다루지 못함 | Pass 3에서 LLM 환각 가능 (INFERRED 플래그로 표시) |
| 갱신 지연 | 없음 (자동) | 재빌드 필요 (훅으로 완화) |
| 관리 부담 | LSP 품질 편차 일부 존재 | 의미적 연결 사람이 주기 검토 권장 |
한 줄 결론: Serena는 "코드 외 자료"를 못 다루고, Graphify는 "최신성 유지"에 손이 듭니다. 둘 다 조건부로 작동하므로 도입 전에 본인 환경의 자료 비율과 변경 빈도를 한 번 확인해 보시기 바랍니다.
9. 어떤 상황에 어느 쪽을 쓰나
| 상황 | 추천 |
|---|---|
| 일상 리팩터·이름 변경·심볼 점프가 많다 | Serena |
| 새 저장소 처음 이해, 아키텍처 지도가 필요 | Graphify |
| 코드 + DB + 인프라 + 문서가 한 저장소에 섞여 있다 | Graphify |
| Claude Code 토큰 한도가 자주 닿는다 | Serena (즉시 효과) |
| 카파시 LLM 위키 패턴을 코드에 적용하고 싶다 | Graphify (구조적으로 같은 패턴) |
| 큰 프로젝트의 영상·문서 자료까지 정리 | Graphify |
10. 함께 쓰면 - 두 도구를 층위로 쌓기
두 도구는 배타적이지 않습니다. 가장 강력한 셋업은 Graphify를 지도로, Serena를 편집기로 쓰는 층위 구조입니다.
- Graphify로 큰 그림을 그립니다. 코드 + DB + 인프라 + 문서 자료를 한 그래프에 모아 두면, 새로운 작업이 들어왔을 때 "어디를 건드려야 하는지"부터 빠르게 잡을 수 있습니다. 주/월 단위로 재빌드합니다.
- Serena로 정확한 편집을 합니다. Graphify가 알려준 위치를 LSP가 정확히 찍고 원자적으로 수정합니다.
두 도구를 함께 쓰는 셋업의 셸 명령은 다음과 같습니다.
# 1) Serena 등록 (실시간 편집용)
cd /path/to/project
claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context ide-assistant --project $(pwd)
# 2) Graphify 설치 + 그래프 빌드 (지도용)
pip install graphifyy && graphify install
graphify hook install # git commit 자동 재빌드Graphify의 --wiki 옵션으로 마크다운 위키를 산출하면, 이 위키가 카파시 LLM 위키 패턴의 wiki/ 폴더 역할을 그대로 합니다. 그 위에서 Serena의 LSP 도구가 코드를 정확히 다룹니다 — "검색이 필요 없는 산출물"(Graphify)과 "실시간 IDE 능력"(Serena)을 함께 가져가는 구도입니다.
마무리
Serena와 Graphify는 같은 문제를 정반대 방향에서 풉니다. 두 도구의 차이를 한 줄로 정리하면 다음과 같습니다.
Serena는 "정확한 편집"의 도구, Graphify는 "넓은 지도"의 도구다.
한도가 빠르게 닳는 리팩터 작업이 많으면 Serena부터, 새 저장소를 빠르게 이해하고 싶으면 Graphify부터, 큰 프로젝트라면 둘 다 — 이 한 문장이 도입 순서의 가장 단순한 답입니다. 둘은 같은 코드베이스 위에서 충돌 없이 동시에 동작하므로 상황에 따라 골라 쓰시거나, 큰 프로젝트라면 처음부터 함께 쓰는 셋업을 잡으셔도 좋습니다.
- Serena GitHub: github.com/oraios/serena
- Serena 공식 문서: oraios.github.io/serena
- Graphify 공식: graphify.net
- Graphify GitHub: github.com/safishamsi/graphify
- MCP 표준 문서: modelcontextprotocol.io
'AI & LLM' 카테고리의 다른 글
| Claude Code 토큰 절약 시리즈 ① Serena MCP - 의미 기반 검색으로 토큰 폭발 막기 (0) | 2026.05.12 |
|---|---|
| Karpathy의 LLM 위키 - RAG의 한계를 넘는 새 패턴과 Graphify 사례 (0) | 2026.05.11 |
| Claude Cowork - 데스크탑에서 파일과 앱을 직접 다루는 Claude의 새 인터페이스 (1) | 2026.05.10 |
| Google Antigravity란? - Claude Code와의 차이와 함께 쓰는 법 (1) | 2026.05.09 |
| Playwright MCP - Claude Code가 직접 브라우저를 다루게 만들기 (0) | 2026.05.08 |
