[심층분석] 코드베이스를 밀리초 만에 통째로 외운다는 MCP 서버, 어디까지 믿어야 할까

"내 코드 전부 좀 외워줄래?" — AI 코딩 에이전트의 오랜 숙제

요즘 Claude Code, Cursor, Windsurf 같은 AI 코딩 도구 한 번쯤 써보셨을 거예요. 그런데 조금만 큰 프로젝트에서 일을 시켜보면 금방 한계를 느끼거든요. "이 함수 누가 호출해?"라고 물어보면, AI가 파일을 하나씩 열어보면서 찾아요. 마치 색인(목차)이 없는 두꺼운 책에서 단어 하나 찾겠다고 첫 장부터 끝까지 넘겨보는 거랑 비슷한 거죠.

여기서 문제가 두 가지 생겨요. 첫째는 토큰(token) 낭비예요. 토큰이라는 건 쉽게 말해 AI가 글을 읽고 쓸 때 쓰는 '글자 묶음' 단위인데요, 파일을 통째로 읽을 때마다 토큰이 쭉쭉 빠져나가요. 토큰은 곧 비용이고, AI가 한 번에 기억할 수 있는 양(이걸 '컨텍스트 윈도우'라고 해요)도 정해져 있어서 큰 코드베이스는 애초에 다 못 담아요. 둘째는 속도와 정확도예요. 파일을 일일이 뒤지니 느리고, 엉뚱한 파일을 읽다가 정작 중요한 걸 놓치기도 하거든요.

오늘 살펴볼 codebase-memory-mcp는 바로 이 지점을 노린 도구예요. 한 줄로 요약하면 "AI가 코드를 읽기 전에, 코드베이스 전체를 미리 정리해서 '지식 그래프'로 만들어 두는 엔진"이에요. 광고 문구가 꽤 화려해요. 평균적인 저장소는 밀리초(1000분의 1초) 단위로 인덱싱하고, 리눅스 커널(2800만 줄, 7만 5천 파일)도 3분이면 끝낸다고 하고요, 질의 응답은 1밀리초 이하, 토큰은 99% 절약, 158개 언어 지원, 의존성 없는 단일 실행파일이라고 해요. 들으면 솔깃한데, 이게 정확히 뭔지 그리고 이 숫자들을 얼마나 믿어야 할지 같이 차근차근 뜯어볼게요.

핵심 아이디어: 코드를 미리 '지도'로 만들어 둔다

이 도구를 이해하려면 키워드 세 개만 잡으면 돼요. MCP, 트리시터(tree-sitter), 그리고 지식 그래프예요.

먼저 MCP부터요. MCP는 'Model Context Protocol'의 줄임말인데, Anthropic이 만든 표준이에요. 쉽게 말하면 AI한테 외부 도구나 데이터를 연결하는 표준 콘센트 같은 거예요. 예전엔 도구마다 연결 방식이 제각각이라 골치 아팠는데, MCP라는 규격이 생기면서 "이 규격만 맞추면 어떤 AI 에이전트든 꽂아 쓸 수 있다"가 된 거죠. 이 프로젝트가 'MCP 서버'인 이유가 여기 있어요. Claude Code든 Cursor든 11개 에이전트에 그냥 꽂으면 AI가 "코드 검색 도구"로 인식하고 쓸 수 있게 만든 거예요.

다음은 트리시터예요. 이건 코드를 단순한 '글자 덩어리'가 아니라 문법 구조(AST, 추상 구문 트리)로 분해해 주는 파서예요. 비유하자면, 사람이 문장을 읽을 때 "주어-동사-목적어"로 자동 분석하듯이, 트리시터는 코드를 보고 "여긴 함수 정의, 여긴 클래스, 여긴 호출 부분"이라고 구조를 정확히 짚어내요. 단순 텍스트 검색(grep)과 차원이 다른 이유예요. 거기에 더해 이 도구는 파이썬, 타입스크립트, Go, 러스트 같은 주요 언어엔 LSP 기반 의미 분석까지 얹었다고 해요. LSP는 VS Code에서 변수 위에 마우스 올리면 타입이 뜨고 '정의로 이동'이 되는, 그 똑똑한 기능을 만드는 기술이에요. 즉 "이 변수의 진짜 타입이 뭔지"까지 이해한다는 거죠.

마지막이 지식 그래프예요. 이게 이 도구의 심장인데요, 쉽게 말해 코드 요소들 사이의 관계를 점과 선으로 그린 지도예요. 함수 A가 함수 B를 호출하고, 클래스 C가 인터페이스 D를 구현하고, 이 HTTP 경로가 저 핸들러로 연결되고… 이런 관계를 미리 다 그려서 데이터베이스에 저장해 둬요. 그래서 "이 함수를 누가 호출해?" 같은 질문이 오면, 파일을 읽을 필요 없이 지도에서 선만 따라가면 끝나요. 토큰을 적게 쓴다는 주장의 근거가 바로 이거예요. 파일 원문을 통째로 안 보내고, 그래프에서 뽑은 핵심 관계만 짧게 답하니까요.

화려한 숫자들, 곧이곧대로 믿어도 될까

원리는 그럴듯한데, 발표된 숫자들은 좀 차분하게 볼 필요가 있어요. 프로젝트는 'arXiv 프리프린트(정식 심사 전 논문)'를 근거로 31개 실제 저장소에서 답변 품질 83%, 토큰 10배 절감, 도구 호출 2.1배 감소를 측정했다고 해요. 그런데 README 맨 위에는 "99% 토큰 절감"이라고 적혀 있죠. 같은 도구를 두고 '10배'와 '99%'가 섞여 나오는 셈인데, 마케팅 문구와 실측치가 다를 수 있다는 신호예요.

방향성 자체는 합리적이에요. 파일을 다 읽는 대신 그래프 질의로 바꾸면 토큰이 크게 주는 게 맞거든요. 하지만 '밀리초 인덱싱', '1ms 미만 질의' 같은 건 어떤 질문이냐, 저장소가 얼마나 크냐, 캐시가 데워졌냐에 따라 천차만별이에요. 결론은 하나예요. 이런 벤치마크는 남의 환경 자랑이 아니라, 내 저장소에서 직접 재봐야 의미가 있어요.

비슷한 도구들과 뭐가 다를까

코드를 AI가 잘 찾게 돕는 접근은 크게 세 갈래예요.

그냥 파일 읽기 (기본값): 지금 대부분의 에이전트가 하는 방식이에요. 정확하지만 느리고 토큰을 많이 먹어요. '책을 처음부터 넘겨 읽기'.
임베딩/벡터 검색 (RAG 방식): Cursor 인덱싱이나 Sourcegraph Cody가 쓰는 방식이에요. 코드를 '의미 비슷한 것끼리' 수치화해서 찾아요. "비슷한 느낌"은 잘 찾지만 "정확히 누가 누구를 호출" 같은 구조적 사실엔 약해요.
구조 그래프 방식 (이 도구): 호출 관계, 상속 관계를 '사실'로 박아두니 구조적 질문에 강해요. 대신 자연어 뉘앙스 검색은 임베딩보다 약할 수 있어요.

비유하자면, 임베딩은 "느낌이 비슷한 책 추천"이고, 구조 그래프는 "이 인물이 등장하는 모든 페이지 정확히 짚기"예요. 둘은 경쟁이라기보다 상호 보완에 가깝고, 실제로 잘 만든 도구는 둘을 섞어 써요.

그런데, 꼭 짚고 넘어가야 할 부분 (보안)

여기서부터는 시니어 입장에서 솔직하게 말씀드릴게요. 이 도구의 소개문엔 "이 도구는 당신의 코드를 읽고, 에이전트 설정 파일에 직접 씁니다. 그게 설계 의도입니다"라는 문장이 있어요. 그리고 "모든 릴리스 바이너리는 서명·체크섬·70개 이상 백신 검사를 거쳤고, 처리는 100% 로컬에서만 일어난다"고 강조하죠.

기능 자체는 정상이에요. 에이전트에 도구를 등록하려면 설정 파일을 건드려야 하니까요. 다만 "코드 전체를 읽을 권한 + 설정 파일을 쓸 권한 + 단일 바이너리 배포"라는 조합은, 그게 어떤 도구든 신중하게 다뤄야 하는 조합이에요. 게다가 소개문이 "믿어도 된다"고 유난히 여러 번 강조한다는 점은, 역설적으로 내가 직접 확인하고 들이는 게 맞다는 신호이기도 해요. 의심하라는 게 아니라, 권한이 큰 도구엔 원래 그만한 검증을 붙이는 게 기본이라는 뜻이에요.

실무에서 들이신다면 이렇게 해보세요. (1) 가능하면 바이너리를 받기보다 공개된 소스에서 직접 빌드하거나, 최소한 체크섬을 대조하세요. (2) 회사 코드 같은 민감한 저장소라면, 먼저 개인 토이 프로젝트에 적용해 일주일 굴려보고 도구가 설정 파일을 어떻게 바꾸는지 git diff로 눈으로 확인하세요. (3) "100% 로컬"이 진짜인지 마음에 걸리면, 실행 중 네트워크 연결을 모니터링(예: 방화벽/패킷 캡처)해서 외부로 나가는 트래픽이 없는지 직접 검증하면 깔끔해요. 이건 이 도구만의 얘기가 아니라, 권한 큰 개발 도구를 들일 때의 표준 절차예요.

마무리: '코드 메모리'는 방향이 맞다, 다만 검증은 내 몫

정리하면, codebase-memory-mcp가 가리키는 방향 — AI 에이전트에게 코드베이스의 '기억'을 미리 만들어 주자 — 는 분명히 앞으로의 흐름이에요. 에이전트가 매번 파일을 더듬는 시대에서, 잘 정리된 코드 지도를 보고 움직이는 시대로 가고 있거든요. 트리시터, 지식 그래프, LSP 같은 기반 기술도 검증된 것들이라 개념 자체는 탄탄해요.

다만 화려한 숫자는 내 저장소에서 직접 재보고, 권한이 큰 도구는 소스와 동작을 직접 확인하고 들이는 습관. 이 두 가지만 챙기면, 이런 신기술을 안전하게 누릴 수 있어요. 좋은 엔지니어링은 결국 '믿되 검증한다'니까요.

여러분은 어떠세요? AI 코딩 에이전트한테 코드베이스 전체를 이해시키려고 어떤 방법을 쓰고 계신가요? 임베딩 검색파인가요, 아니면 구조 그래프파인가요? 그리고 출처가 명확하지 않은 개발 도구를 들일 때, 여러분만의 검증 루틴이 있다면 댓글로 공유해 주세요. 같이 배워봐요!

🔗 출처: GitHub

이 글도 읽어보세요