Jikji
Summary
로컬 파일 검색에서 에이전트가 grep/find 중심 탐색으로 토큰과 시간을 과도하게 소모하는 문제를 줄이기 위해, 사전 파싱·필드 인덱스·LLM Wiki·지식그래프·그래프 라우팅을 묶어 제공하는 로컬 우선 검색 도구.
개요
- 분류: 로컬 파일 탐색/색인 도구
- 주요 맥락: Hermes Agent 같은 CLI 에이전트의 파일 검색 병목 완화
- 작성자 공개 포지션: Cheol H. Jeong LinkedIn 포스트에서 직접 제작·오픈소스 공개 언급
- 공개 보강 자료: Jikji benchmark page (
nomadamas.github.io/jikji/jikji-benchmarks.html#examples) - 저장소 URL: 확인 필요 (원문은
lnkd.in단축 링크만 제시)
문제 정의
에이전트가 로컬 파일 하나를 찾기 위해 매번 폴더를 걷고, 포맷별 파서를 다시 부르고, LLM에게 여러 차례 후보를 검토시키면 다음 문제가 생긴다.
- 호출 수 증가
- 토큰 낭비
- PDF/HWP/멀티미디어 탐색 품질 저하
- 동일 저장소 재검색 시 비용 반복
Jikji는 이 반복 비용을 질문 시점이 아니라 사전 색인 시점으로 이동시키는 도구로 읽힌다.
작동 방식
1) 모든 파일을 미리 파싱
문서, 멀티미디어 파일 등 다양한 로컬 파일을 먼저 읽어 본문/메타정보를 캐시한다.
2) 탐색 지도를 만든다
folder profile, file card, duplicate hint, route row 등으로 “어디를 봐야 하는지”를 정리한다.
3) 에이전트 친화적 증거 페이지를 만든다
원본 대신 grounded markdown source page를 읽게 해 LLM 컨텍스트를 줄인다.
4) 그래프와 의미 단서로 후보를 좁힌다
source/folder/term/intent/duplicate 관계와 deterministic semantic terms를 이용해 후보 라우팅을 한다.
공개 벤치마크 기준 특징
- HippoCamp Fullset 551건에서 raw Hermes 대비:
- Hit@1:
0.6697 → 0.7949 - LLM calls:
6,420 → 551 - 총 토큰:
21.30M → 0.25M - 시간:
520분 → 19분
- Hit@1:
- 작성자는 이를 “10배~30배 절약”으로 요약하며, 일부 벤치에서는 정확도도 함께 오른다고 주장한다.
JYP Labs에서의 의미
- OMW/Obsidian/프로젝트 볼트가 커질수록, 단순 검색보다 사전 구조화된 로컬 지식 인프라가 중요해진다.
- 에이전트에게 검색을 맡기기 전에 저장소를 agent-readable 상태로 만들자는 점에서 llm-wiki 철학과 맞닿아 있다.
- 향후
Hermes + Jikji + OMW조합은 “수집 시 구조화, 질의 시 경량 탐색” 패턴의 실험 후보가 될 수 있다.
관련 개념
관련 엔티티
- hermes-agent — 비교 대상이 된 CLI 에이전트 런타임
소스
확인 필요
- canonical GitHub 저장소 URL
- 실제 설치 절차와 CLI subcommand 전체 표면
- 대규모 저장소에서의 증분 색인 비용과 업데이트 전략