codebase-memory-mcp(리포지토리를 지식 그래프(knowledge graph)로 인덱싱하고, 158개 언어를 지원하며, 1밀리초 미만의 쿼리 속도를 제공한다는 것)가 화제가 되는 것을 보고,

흥미로운 점은 두 접근 방식 모두 매번 완벽했다는 것입니다. 네 번의 실행에서 어느 쪽도 실수가 없었습니다. 일반 텍스트 검색만으로도 Claude가 저희 코드베이스에서 필요한 모든 것을 찾아냈습니다. 따라서 화려한 그래프는 고칠 실수가 없었습니다. 즉, 존재하지 않는 문제를 해결하고 있었던 것입니다. 그래프 지도의 구멍이 있었습니다. 한 연결고리가 빠져 있었습니다. 우리의 AI 래퍼를 직접 호출하는 함수가 단순히 연결되지 않았던 것입니다. 이 그래프를 사용하는 에이전트가 뭔가 이상하다는 것을 감지하고 평범한 검색으로 모든 것을 재확인했습니다. 그래서 그래프는 '정답'이라기보다는 '스스로 검증해야 하는 대략적인 지도'가 되었습니다. 그래도 약간의 시간을 절약해 주지만, 무언가를 놓치는 것이 정말 치명적일 때는 그래프만 믿을 수 없다는 의미입니다. 질문할 때는 훌륭하지만, AI 에이전트가 그것을 사용해 코드를 작성할 때는 그다지 좋지 않습니다. 저는 '이 함수를 변경하면 앱의 어떤 부분이 영향을 받을까요?'라고 물었고, 프론트엔드의 버튼부터 네트워크 경계를 넘어 백엔드 함수까지 추적하여 한 번에 답변했습니다. 심지어 일반 검색으로는 놓치는 연결고리 하나도 잡아냈는데, 그곳의 코드가 다른 이름을 사용했기 때문입니다. 이것을 수동으로 하는 것은 검색하고, 읽고, 다시 검색하는 과정을 반복해야 한다는 의미입니다. 하지만 에이전트가 무언가를 구축할 때는 결국 그래프의 답변을 일반 검색으로 재확인하게 되므로 절반의 이점은 사라집니다. 도움이 되는지는 전적으로 작업 유형에 달려 있습니다. 만약 작업이 주로 코드 편집이라면, 그래프는 오히려 속도를 늦춥니다. 변경 사항을 타이핑하는 데 드는 비용은 어느 쪽이나 같기 때문에 더 빠른 검색은 거의 중요하지 않습니다. 만약 작업이 주로 무언가를 찾는 것이라면, 그래프가 승리합니다. 하지만 과대광고되는 '게임 체인저'라기보다는 13% 차이로 말입니다. 주의사항: n=1 조건당, 코드베이스 하나 제출자 /u/bowenator [링크] [댓글]