AI 인덱싱이 왜 필요한가
jCodeMunch와 jDocMunch가 토큰과 시간을 줄이는 방식
AI 인덱싱이 왜 필요한가:
jCodeMunch와 jDocMunch가
토큰과 시간을 줄이는 방식
AI한테 코드 좀 봐달라고 시키면 보통 웃긴 일이 벌어진다.
정작 필요한 건 함수 하나다. 근데 이놈은 파일을 통째로 연다. 심하면 폴더를 다 뜯는다.
문서도 똑같다.
설정 한 줄 물어봤는데 README부터 설계 문서까지 질질 끌고 온다.
그러면 느려진다. 토큰이 터진다. 돈이 샌다.
왜 이게 문제인가
AI는 길게 읽는다고 더 똑똑해지지 않는다.
오히려 지금 필요한 것과 필요 없는 것이 한꺼번에 들어오면 핵심이 묻힌다. 그래서 자꾸 다시 묻고, 다시 고치는 루프가 생긴다.
비용은 토큰에 비례하고, 지연은 쓸데없는 컨텍스트에 비례한다.
해결책은 단순하다. 안 넣어도 되는 걸 안 넣으면 된다.
jCodeMunch와 jDocMunch가 뭔가
둘 다 MCP 서버다.
Claude Desktop, VS Code 같은 MCP 호환 에이전트에 붙여서 쓰는 오픈소스 도구다.
jCodeMunch는 jgravelle이 만든 GitHub 오픈소스 프로젝트로, tree-sitter AST 파싱을 이용해 코드베이스를 인덱싱하고 심볼 단위로 검색하는 MCP 서버다. MIT 라이선스고,
pip install git+https://github.com/jgravelle/jcodemunch-mcp.git
으로 설치한다.
jDocMunch는 PyPI에 올라와 있는 패키지로, 섹션 단위 인덱싱으로 문서를 구조화해서 검색하는 MCP 서버다.
pip3 install jdocmunch-mcp
로 설치한다.
하나는 코드 서랍, 하나는 문서 서랍이다.
jCodeMunch: 코드를 통째로 읽지 않게 만든다
기존 방식은 이렇다.
"로그인 함수 어디 있지?"
→ 파일 6개 열어봄 → import 읽음 → 주석 읽음 → 상관없는 헬퍼 함수까지 같이 읽음
jCodeMunch는 다르다.
코드베이스를 한 번 인덱싱해두고, 그다음부터는 파일이 아니라 심볼 단위로 찾아간다. 함수, 클래스, 메서드, 상수 각각에 시그니처와 한 줄 요약을 달아두고, 필요할 때 그 부분만 byte-offset으로 꺼낸다.
"로그인 함수 어디 있지?" → search_symbols → get_symbol → 그 함수만 봄
숫자로 보면 이렇다.
마법이 아니다. 덜 읽으니까 줄어드는 거다.
jDocMunch: 문서를 통째로 먹이지 않게 만든다
문서는 코드보다 더 심하다.
코드는 그나마 함수라도 있다. 문서는 길기만 길고, 지금 필요한 내용은 보통 한 섹션 안에만 있다.
jDocMunch는 Markdown 문서를 H1~H6 기준으로 논리 섹션 단위로 쪼갠다.
섹션마다 요약을 만들어두고, 질문이 들어오면 관련 섹션만 꺼내온다.
기존 방식: README 전체 → 설치 문서 전체 → 설정 가이드 전체
jDocMunch 방식: 인증 섹션만 → 환경변수 섹션만 → 트러블슈팅 섹션만
원리는 jCodeMunch와 같다. 덜 넣으니까 빠르고 싸다.
왜 코드와 문서를 따로 처리하는가
코드는 함수, 클래스, 메서드, 타입, 호출 관계로 이루어진다.
문서는 제목, 섹션, 설명 흐름, 설정 항목으로 이루어진다.
생긴 게 다르면 서랍도 달라야 한다. 한 도구로 합치면 둘 다 어정쩡해진다.
한 줄로 끝내면 이거다
AI가 느린 게 아니다. AI가 비싼 게 아니다.
파일이랑 문서를 통째로 처먹이고 있으니까 느리고 비싼 거다.
코드는 jCodeMunch로 심볼만 꺼내고, 문서는 jDocMunch로 섹션만 꺼내라.