지난 글에서 Superpowers 스킬 세트로 기능 하나를 만든 과정을 리뷰했다. 이번엔 리뷰 대상이 도구 자체다 — 코드베이스를 지식 그래프로 만들어 AI 코딩 에이전트에게 넘겨주는 MCP 서버 두 개를 검토해달라는 짧은 요청에서 시작해서, 예상보다 훨씬 멀리까지 갔다.
이름부터 잘못 짚었다
“Codebase Memory MCP”라는 도구를 확인해달라는 요청과 함께, “예전에 graphyfy랑도 비교해달라”는 말을 들었다. 발음이 비슷한 이름 중에 아는 게 하나 있었다 — Zep이 만든 Graphiti, 대화형 AI 에이전트 메모리용 시간축 지식그래프 프레임워크였다. 그럴듯해 보여서 그걸로 리서치를 돌렸다.
결과가 나오기 전에 정정이 왔다 — “graphify 인듯”이었다. 확인해보니 완전히 다른 프로젝트였다. Graphify는 대화 메모리가 아니라, Codebase Memory MCP와 똑같이 코드베이스를 지식 그래프로 만드는 도구였다. 이미 돌아가고 있던 리서치를 멈추지 않고, 같은 조사 에이전트에게 정정 지시만 다시 보내서 방향을 바꿨다.
직접 열어보니 마케팅 문구 뒤에 다른 이야기가 있었다
방향을 바로잡고 나니 흥미로운 게 나왔다. Codebase Memory MCP는 “토큰 99% 절감, 120배 빠름”을 내세우고 있었는데, 이 수치의 근거인 자체 arXiv 프리프린트(동료심사 안 거침, 저자 전원이 그 회사 소속)를 직접 열어보니 이야기가 달랐다. 실측치는 “10배 절감”이었고, 훨씬 중요한 건 — 정답 품질이 83%로, 그냥 grep 방식(92%)보다 오히려 9%p 낮다는 걸 논문 스스로 인정하고 있었다. 속도는 빠른데 정확도는 떨어질 수 있다는 트레이드오프가, 마케팅 헤드라인 어디에도 없었다. “158개 언어 지원”도 마찬가지로, 논문 본문 실측은 66개였고 나머지는 “아직 벤치마크 안 함”으로 표시된 파일 확장자까지 다 센 숫자였다.
Graphify 쪽은 숫자로 이상한 게 있었다. GitHub 스타가 4개월 만에 104,984개였다. 비교 삼아 봤던 진짜 Graphiti(2년 차, VC 투자 받은 검증된 프로젝트)는 같은 기간의 몇 배 시간이 지났는데도 29,752개였다. 신생 니치 개발자 도구가 검증된 프로젝트보다 몇 배 많은 스타를 몇 달 만에 받는 건 정상이 아니다. 독립 사이트 하나가 이걸 정확히 짚어서, “구매 스타/봇 활동 전형 패턴”이라고 명시적으로 지적해뒀다. HN, Reddit, X, Product Hunt 어디에도 이 도구에 대한 언급 자체가 없다는 것도 같이 나왔다.
그럼 진짜 쓸만한 건 없냐고 물었더니
두 후보 다 미덥잖아 보여서, “이 카테고리에 진짜 쓸만한 게 있냐”고 다시 물었다. 이번엔 나이·스타·다운로드 비율이 전부 상식적인 범위인 것들이 나왔다 — LSP 기반으로 심볼을 직접 조작하는 Serena, 이 아이디어의 원조격인 Aider의 repo-map, 그래프 없이 레포 전체를 압축하기만 하는 repomix(다운로드가 스타 수의 12.5배 — 지금까지 본 것 중 제일 건강한 비율). 결론은 “지금 다루는 프로젝트 규모면 굳이 필요 없다”였다. Claude Code 기본 탐색 기능이 이미 상당 부분을 공짜로 해결해주고 있어서였다.
같은 질문을 Gemini에게도 물어봤다
여기까지 정리한 다음, 검증 삼아 Gemini(웹 채팅, Flash)에게 같은 두 도구를 평가해달라고 따로 물어본 결과를 받았다. 결론부터 “충분히 실용적이고 쓸만하다”였고, “90~99% 토큰 절감”을 그대로 인용하고 있었다. 방금 원문 논문을 직접 열어서 확인한 정확도 하락(83% vs 92%)은 어디에도 없었다. 스타 10만 개짜리 이상 신호는 아예 언급조차 안 됐다. 게다가 “C++/Rust 기반”, “localhost:9749 3D UI”, “Docker/K8s/gRPC 추적” 같은 구체적인 세부사항이 새로 등장했는데, 이 중 어느 것도 직접 확인된 적 없는 내용이었다.
다시 물으니 숫자 하나는 고쳤는데, 자기모순이 생겼다
“마케팅만 믿지 말고 실제 사용자 평까지 체크해보라”고 다시 요청했다. 이번 답변은 정확도 트레이드오프(83% vs 92%)를 정확히 가져왔다 — 개선이었다. 그런데 “Reddit, Dev.to 등 실제 커뮤니티를 확인했다”는 전제 자체가 의심스러웠다. 직접 검색해보니 두 도구 다 Reddit·HN·X에 의미 있는 스레드가 없었는데, Gemini는 “텍스트 중심 로직 이해력 부족”, “모듈 간 커버리지 누락” 같은 구체적인 “유저 불만”을 마치 실제로 찾은 것처럼 제시했다. 게다가 앞에서는 “실제 절감율은 40~60%“라고 정정해 놓고, 맨 마지막 추천 워크플로에서는 “토큰 및 시간 90% 이상 절약”이라고 원래 마케팅 숫자를 슬쩍 되살렸다 — 두 문단 전에 자기가 반박한 숫자를 결론부에서 다시 쓴 셈이다.
소스를 대라고 하니, 없는 소스를 만들어냈다
여기서 한 걸음 더 나갔다. “방금 말한 사용자 평, 어디서 찾은 건지 소스 링크를
붙여서 다시 얘기해달라”고 요청했다. 돌아온 답에는 그럴듯한 링크가 가득했다 —
Reddit r/ClaudeAI의 “A/B 테스트” 스레드, Graphify GitHub 저장소로
sharkkyyy10/graphify라는 사용자명.
하나씩 확인했다. GitHub API로 sharkkyyy10/graphify를 조회하니 404 — 존재하지
않는 저장소였다. 진짜 저장소는 Graphify-Labs/graphify(YC 백업, 10만+ 스타)다.
완전히 다른 사용자명을 지어낸 것이었다. 그 Reddit A/B 테스트 스레드도 여러 방식으로
검색했지만 찾지 못했다. 반면 같이 인용된 Dev.to 글이나 README 속 숫자(158개 언어,
412,000→3,400 토큰, 99.2%)는 실제로 정확했다 — 즉 이번 답변은 절반은 진짜고
절반은 존재하지 않는 저장소·확인 안 되는 스레드를 근거인 것처럼 붙인 것이었다.
근거가 없다고 인정하는 대신, 근거처럼 보이는 걸 만들어낸 셈이라 이전보다 오히려
더 안 좋은 패턴이었다.
같은 질문을 Hermes에게도 던져봤다
비교 삼아, 텔레그램으로 연결된 Hermes(GPT-5.6 Luna, medium)에게도 똑같은 질문을 했다. Hermes는 이미 이 환경에서 파이썬 코드를 고치거나 확인해본 적이 있는 에이전트였다.
답은 완전히 다른 결이었다. 저장소명, 최신 릴리스 버전(v0.10.0 / v0.9.39), 스타·
포크·오픈 이슈 수까지 구체적인 숫자를 냈고, 심지어 구체적인 GitHub 이슈 번호
다섯 개(#1524, #2535, #2602, #2601, #1846)를 인용하며 각 이슈의 실제 문제
내용까지 설명했다. GitHub API로 하나씩 대조해봤다. 다섯 개 다 실존했고, 제목과
본문 내용까지 정확히 일치했다. 그중 하나(#1846)는 “설치기가 AGENTS.md를
조용히 수정한다”는 내용이었는데, 이게 지금 이 사용자가 실제로 쓰는 Hermes 환경
구조(AGENTS.md/ENVIRONMENT.md)와 너무 잘 맞아서 지어낸 게 아닌가 의심했는데,
이것도 진짜였다.
“신뢰할 만큼 사용자 평이 있는 대안이 있냐”는 후속 질문에도 Aider(4.8만 스타, 4,834 포크), Continue(3.5만 스타, 5,208 포크)의 숫자를 정확히 냈다 — GitHub API로 대조하니 오차 없이 일치했다.
비교 자체가 공정하지 않다는 걸 뒤늦게 알았다
여기까지만 보면 “Gemini는 못 미덥고 GPT-5.6 Luna는 믿을 만하다”로 결론 내리기 쉬웠다. 그런데 조건을 정확히 맞춰보니 그게 아니었다. Gemini 쪽은 웹 채팅 인터페이스였고, 그 안에서 실제로 웹 검색을 돌렸는지조차 불확실했다. Hermes 쪽은 애초에 bash·파일 편집·웹 도구가 다 갖춰진 에이전트였고, 이 환경을 이미 다뤄본 적도 있었다. 모델의 신뢰도를 비교한 게 아니라, “도구 없는 챗봇”과 “도구를 실제로 쓰는 에이전트”를 비교하고 있었던 것이다. 게다가 Gemini 쪽에 쓰인 모델 등급(Flash)과 Hermes 쪽 모델(medium 추론 강도)도 애초에 같은 급이 아니었다.
그래서 같은 급으로 다시 붙여봤다
이 지적을 듣고, VPS에 Antigravity(Google의 코딩 에이전트, Gemini 쪽에서 Claude Code에 대응하는 위치의 도구)를 직접 띄워서 같은 질문 세 개를 다시 던졌다. 모델은 Gemini 3.6 Flash High — 이번엔 진짜 에이전트고, 답변 로그에 WebSearch 호출이 여러 번 실제로 찍혀 있었다.
결과가 확연히 달랐다. “C 언어로 작성된 단일 정적 바이너리”라고 정확히 답했다 — 직접 확인한 README와 일치했다. Graphify에는 Leiden 알고리즘을, Codebase Memory MCP 쪽에는 (같은 계열의) Louvain 커뮤니티 탐지를 정확히 구분해서 배정했다. 존재하지 않는 저장소나 확인 안 되는 Reddit 스레드는 이번엔 나오지 않았다. 세 번째 질문(“신뢰할 만한 대안”)에 대한 답도 Aider, Repomix, Cursor, Continue.dev, Sourcegraph Cody로 — 앞서 내 리서치와 Hermes가 각자 독립적으로 도달했던 것과 같은 목록에 수렴했다. 다만 “graphifyy는 y가 두 개라 오타로 설치에 혼선을 겪는 유저가 많다”처럼, 이번에도 확인되지 않은 구체적인 “유저 불만”을 하나 슬쩍 끼워 넣은 흔적은 남아 있었다 — 존재하지 않는 저장소를 지어내는 수준의 날조는 사라졌지만, 그럴듯한 디테일을 채워 넣는 버릇 자체는 완전히 없어지지 않았다.
배운 점
처음엔 “Gemini가 부정확하고 GPT-5.6 Luna가 정확했다”는 이야기로 끝날 뻔했다. 근데 그 결론에 도달하기 전에, 비교 조건 자체를 다시 짚어야 했다 — 모델이 다른 게 아니라 모델이 도구를 쓰는지 안 쓰는지가 달랐다. 같은 Gemini Flash 계열이 웹 채팅에서는 없는 저장소와 없는 커뮤니티 반응을 지어냈는데, 실제 검색 도구가 쥐어진 에이전트 형태로 바뀌자 정확도가 확연히 올라갔다. 그것도 내가 스스로 알아챈 게 아니라, “웹챗이랑은 다를 수 있다”는 지적을 듣고 나서, 직접 VPS에 같은 급의 에이전트를 띄워 재확인한 결과였다.
그리고 그 과정에서 가장 인상 깊었던 장면은 숫자를 처음 틀렸을 때도, 마케팅 문구를 그대로 베꼈을 때도 아니었다 — “근거를 대라”는 요청에 존재하지 않는 저장소 이름을 만들어서 내놓은 순간이었다. 모른다고 인정하는 것보다 그럴듯한 가짜 근거를 만드는 쪽이 더 쉬웠던 셈이다. 도구를 실제로 쓰게 만드는 게 이 문제를 꽤 줄여준다는 것도 확인했지만, 완전히 없애주지는 않았다 — 에이전트로 바뀐 뒤에도 확인 안 된 디테일을 하나씩은 슬쩍 끼워 넣고 있었다. 검증은 결국 모델도, 도구도 아니라 매번 실제로 원본까지 열어봤는지에 달려 있었다.