블로그 자동화에서 예약 발행 시간을 바꾼다고 해보자. 화면에 보이는 스케줄러만 고치면 끝날 것 같지만, 실제로는 파이프라인이 발행 시간을 넘기고, 데이터베이스가 작업 상태를 저장하고, WordPress 클라이언트가 미래 날짜를 전송한다. 코드가 익숙하지 않다면 어느 파일부터 읽어야 할지 찾는 데 시간이 든다.

소셜에서 추천되는 코드 그래프 도구가 이 시간을 줄여준다는 이야기는 많다. 이번에는 Codebase Memory MCP 0.10.8을 현재 블로그 자동화 코드의 복사본에 직접 붙여봤다. 운영 폴더를 건드리지 않도록 51개 파일만 별도 폴더에 복사했고, 공식 릴리스의 Windows 실행 파일은 공개된 SHA-256과 일치하는지 확인했다.

51개 파일을 처음 색인하는 데 89초가 걸렸다

실행한 일	이번 PC에서 걸린 시간	결과
일반 텍스트 검색	0.307초	관련 줄 33개를 바로 찾음
첫 색인	89.205초	노드 273개, 관계 1,084개 생성
구조·이름 질의	17~27초	구조 요약과 함수 노드를 반환
발행 함수 호출 추적	17.105초	직접 테스트 호출 2곳과 하위 호출 9개, 실제 Protocol 호출 1곳 누락

실행 시간만 비교하면 텍스트 검색이 훨씬 빨랐다. 함수 이름을 이미 알고 한 번 찾는 일이라면 별도 그래프를 만들 이유가 거의 없다. 색인과 각 질의 시간에는 이 Windows 환경에서 일회성 CLI를 시작하고 보안 경로를 준비하는 시간도 포함됐다. 저장소가 공개한 내부 그래프 질의 벤치마크와 조건이 다르므로 두 수치를 같은 성능 기준으로 비교할 수는 없다.

그래프 질의는 속도 대신 패키지와 호출 관계를 한 번에 보여줬다. 어떤 패키지가 중심인지, 진입점과 클래스가 어떻게 묶였는지, create_scheduled_post가 내부에서 무엇을 호출하는지 한 화면에서 확인할 수 있었다. 처음 보는 저장소에서 관련 파일을 하나씩 열어 구조를 메모하는 작업을 줄이는 데 도움이 됐다.

예약 발행 함수를 바꿀 때 영향을 받는 파일을 얼마나 찾는지 확인했다

예약 발행 함수의 이름을 정확히 지정해 호출 관계를 추적했다. 결과에는 이 함수를 직접 검사하는 테스트 두 곳과, 함수 안에서 이어지는 인증·요청·오류 처리 경로가 들어 있었다. 수정 전 읽을 목록을 만드는 데는 꽤 편했다.

다만 실제 파이프라인의 DailyPipeline._execute는 호출자로 나오지 않았다. 파이프라인이 구체 클래스가 아니라 Publisher Protocol을 통해 메서드를 부르기 때문이다. 동적 연결과 추상 인터페이스를 쓰는 Python 코드에서는 그래프가 모든 실제 호출을 맞히지 못할 수 있다는 뜻이다.

그래프 결과만 확인했다면 Publisher 인터페이스를 통해 이어지는 파이프라인 호출을 놓칠 수 있었다. 그래프 질의로 후보 파일을 좁힌 뒤 함수명과 인터페이스명을 텍스트로 검색해 누락을 확인하는 방식이 더 안전했다.

작은 프로젝트는 텍스트 검색부터 하고 반복 분석할 때 그래프를 쓴다

상황	먼저 쓸 방법
함수·설정 이름을 이미 안다	텍스트 검색
처음 보는 저장소에서 진입점과 핵심 모듈을 찾는다	Codebase Memory의 구조 요약
한 기능의 호출자·하위 호출을 반복해서 본다	그래프 추적 후 소스 확인
동적 호출·Protocol·의존성 주입이 많다	그래프와 테스트·검색을 함께 사용
파일이 몇 개뿐인 단발성 스크립트다	도구 추가 없이 직접 읽기

Codebase Memory는 LLM으로 코드를 검토하는 서비스가 아니다. 로컬에서 tree-sitter 기반 그래프를 만들고, 이미 쓰는 AI 코딩 도구가 MCP를 통해 구조 질의를 보내는 방식이다. 공식 저장소는 코드와 질의가 외부로 전송되지 않는다고 설명한다. 별도 API 키 없이 로컬에서 분석할 수 있다는 점은 사내 저장소에 적용할 때 장점이 될 수 있다.

Windows에서는 설치 전에 설정 변경 범위를 확인해야 한다

공식 설치기는 실행 파일만 복사하는 것으로 끝나지 않는다. 감지된 코딩 에이전트의 MCP 설정과 보조 파일을 자동으로 구성한다. 여러 도구를 쓰는 PC라면 예상보다 변경 범위가 넓을 수 있다. 이번 테스트에서는 설치기를 실행하지 않고, 릴리스 압축에서 검증한 실행 파일만 별도 폴더에 풀어 CLI 모드로 사용했다.

설치기를 쓰더라도 먼저 내용을 읽고, 설정을 자동 변경하고 싶지 않다면 공식 문서의 --skip-config 옵션이나 수동 설치 절차를 확인하는 편이 낫다. 기존 Codex·Claude 설정 파일을 복사해 두면 되돌리기도 쉽다.

OneDrive에서는 캐시 폴더 권한 문제로 색인이 중단됐다

처음에는 OneDrive 안의 복사본을 색인했는데, Codebase Memory가 개인 캐시 폴더의 권한을 안전하지 않다고 판단해 시작을 거부했다. 일반 임시 폴더에서도 같은 문제가 났다. 프로젝트에 포함된 보호된 임시 루트 생성 스크립트로 사용자 전용 폴더를 만든 뒤에야 색인이 됐다.

Codebase Memory는 코드 구조가 담기는 로컬 캐시를 다른 Windows 계정이 변경할 수 없도록 폴더 권한을 확인한다. 회사 PC나 공유 폴더에서 색인이 시작되지 않는다면 프로그램을 다시 설치하기 전에 캐시 위치와 해당 폴더의 쓰기 권한부터 확인해야 한다.

처음 맡은 저장소를 반복 분석할 때 설치 가치가 있었다

지금 블로그 자동화 프로젝트처럼 규모가 작고, 함수 이름을 알고, 질문이 한두 번이라면 설치와 색인 비용이 더 컸다. 이 경우 일반 검색과 테스트 파일을 읽는 편이 빠르다.

처음 맡은 저장소에서 며칠 동안 여러 기능을 고치거나 호출 관계와 구조 요약을 반복해서 확인한다면, 한 번 만든 그래프로 탐색 범위를 계속 좁힐 수 있다. 다만 그래프에 나오지 않았다는 이유만으로 호출되지 않는 코드라고 판단해서는 안 된다. 최종 수정 전에는 일반 검색과 테스트로 빠진 연결이 없는지 확인해야 한다.

프로젝트가 공개한 성능·품질 수치는 Codebase-Memory 사전 논문에서 조건을 확인할 수 있다. 공개 벤치마크는 31개 저장소를 대상으로 한 결과이고, 이 글의 Windows 51파일 실험과는 환경과 측정 범위가 다르다.

AI에게 코드 수정을 맡길 때는 구조 지도를 만든 뒤에도 수정 전후에 유지할 동작을 검사하는 과정이 필요하다. 구조를 찾는 도구와 정상 작동을 증명하는 테스트는 서로 대신할 수 없다.

검증 기록: 2026-09-07, Windows, Codebase Memory MCP 0.10.8. 블로그 자동화 코드 51개 파일의 복사본을 색인했다. 시간은 명령 시작부터 종료까지의 1회 측정이며 다른 PC의 성능을 대표하지 않는다. 작성: 노트지기.