jikji: 에이전트의 파일 탐색 비용을 줄이는 로컬 인덱스
에이전트에게 로컬 폴더를 붙이면 가장 먼저 하는 일은 탐색이다. ls로 트리를 훑고, cat으로 파일을 열고, grep으로 내용을 뒤진다. 원하는 파일 하나를 찾을 때까지 이 과정을 몇 번씩 반복한다. 잘 정리된 코드베이스라면 몇 번의 명령으로 끝나지만, 사람의 다운로드 폴더나 회사 공유 드라이브처럼 파일명이 제각각이고 비슷한 자료가 여러 곳에 흩어진 곳에서는 이 탐색만으로 컨텍스트 예산이 줄줄 샌다. 그리고 이 낭비는 매 요청마다, 매 파일마다 다시 발생한다. Hermes 같은 에이전트에 LLM을 붙여 실제로 파일을 찾게 해본 적이 있다면 알 것이다. 파일 하나 찾을 때마다 토큰이 녹는다.
문제는 두 방향으로 더 나빠진다. 첫째, 에이전트가 쓰는 검색 도구가 grep·find 같은 기본 CLI라서, HWP나 PDF처럼 바이너리로 감싸인 문서는 내용 탐색이 아예 안 되거나 극단적으로 비효율적이다. 둘째, 이제는 문서만이 아니라 이미지·영상도 내용 기반으로 찾아야 하는데, 그러자고 임베딩 모델을 얹고 벡터 DB로 RAG를 세우는 건 구축이 까다롭고 컴퓨팅 자원도 낭비다.
이전 글에서 다룬 agentdir는 이 문제의 절반, 즉 "에이전트가 보기 좋은 파일 구조를 만드는" 쪽을 담당했다. 하지만 agentdir는 README에서 파일 파싱, 인덱싱, 검색을 명시적 비범위로 선을 그었다. 정확히 그 빈칸을 채우는 도구가 같은 팀(NomaDamas)이 만든 jikji다.
- GitHub: NomaDamas/jikji
- 역할: 에이전트가 반복 탐색 없이 로컬 파일을 찾도록, 미리 검색 인덱스와 파일 맵을 만들어두는 도구
- 핵심 명령:
jikji prepare ROOT(인덱싱) →jikji find ROOT "clue" --json(한 번의 탐색 호출)
jikji의 자기 소개는 이렇다.
"Non-destructive local file maps and instant search indexes for AI agents." 파일 하나 찾을 때마다 38,650 토큰, 57초, 11.7회 LLM 호출을 쓰던 raw agent 탐색을, 파일당 447 토큰·2.1초·1회 호출로 줄이는 비파괴 로컬 탐색 스킬.
이 글은 위 아키텍처 그림(레포 스냅샷 9ecc942 기준)을 따라가며 jikji가 무엇을 하는지 보고, 실제로 설치해 돌려본 결과를 정리한다.
jikji가 하는 일
jikji의 동작은 그림처럼 세 단계다.
- Prepare folder:
jikji prepare ROOT. 폴더를 읽어 문서(PDF, HWP/HWPX, Office, 텍스트 등)를 파싱하고, 파일 카드·폴더 프로파일·에이전트 맵·각종 캐시를 만든다. 이미지·오디오·비디오는 opt-in 미디어 브리지로 처리한다. - Build search map: 이 준비 과정이 만들어내는 산출물은 전부
.jikji/아래에 쌓인다. 파일명·경로 단서는 메타데이터 라우트로, 문서 내용 단서는 문서 텍스트 캐시로, 폴더 맥락은 에이전트 맵으로, 연관어·힌트는 위키 그래프로 각각 분리해서 인덱싱한다. - Agent finds files:
jikji find. 에이전트는 자연어 단서 하나를 던지고, 후보 슬레이트(candidate slate)·정답 경로(answer paths)·근거 팩(evidence pack)을 한 번에 받는다. 그리고 그 결과를 그대로 쓰거나(direct use), 실패 시 한 번 재시도하는 식으로 핸드오프한다.
핵심은 비파괴다. jikji는 사용자 파일을 옮기거나 이름을 바꾸거나 지우거나 재배치하지 않는다. 생성물은 전부 .jikji/ 디렉토리와 .jikji_agent_map.md로 격리된다. 그림 1단계에 non-destructive 뱃지가 붙은 이유가 이것이다.
비용 절감의 핵심
jikji가 빠르고 저렴한 이유는 단순하다. 비싼 탐색 작업을 에이전트가 물어보기 전에 미리 끝내두기 때문이다.
에이전트가 실시간으로 파일을 찾는 방식은 매번 같은 비용을 다시 치른다. 문서를 열 때마다 그 자리에서 파싱하고, 경로를 모르니 트리를 헤매고, 쿼리를 추측으로 바꿔가며 여러 번 검색한다. 이 모든 단계가 LLM 호출과 토큰으로 환산된다.
jikji는 이 비용을 prepare 시점으로 앞당긴다.
- 탐색 시점 파싱 루프 제거: 문서는
prepare때.jikji/doc_text/에 텍스트로 캐시된다. 검색 때 다시 열지 않는다. - 경로 방황 제거: 폴더 프로파일, 파일 카드, 중복 힌트, 라우트 행이 지저분한 트리를 에이전트가 읽을 수 있는 파일 맵으로 바꾼다.
- 필드 분리 검색: 경로·파일명·폴더·확장자·본문·메타데이터를 따로 인덱싱해서, 명백한 경로 단서와 본문에만 있는 단서가 둘 다 잘 랭킹된다.
- LLM 위키·지식 그래프: 소스마다 짧은 위키 요약 페이지를 만들어 두어, 에이전트가 큰 원본을 여는 대신 요약만 보고 판단할 수 있다. 노드(소스·폴더·용어·의도·중복)는
knowledge_graph.json과graph_routes.jsonl로 미리 라우팅된다.
결과적으로 jikji find 한 번은, 여러 라우트에서 모은 후보를 하나의 슬레이트로 합쳐 에이전트에게 넘긴다. 에이전트는 이 top-k 슬레이트에 대해 한 번의 판단만 하면 되고, ls/find/grep/문서 열기/쿼리 추측에 채팅 턴을 쓰지 않는다.
결정론적 검색과 멀티미디어
인트로에서 짚은 두 번째 고민, "시맨틱 검색을 하려면 결국 임베딩과 벡터 DB가 필요하지 않나"에 대한 jikji의 대답이 흥미롭다. jikji는 임베딩 모델도, 벡터 DB도, 클라우드 RAG 스택도 쓰지 않는다. README의 표현을 그대로 옮기면 이렇다.
This is RAG-style retrieval context, not a mandatory vector DB or cloud RAG stack. Jikji's default index is local and deterministic: no embeddings, cloud parser, or LLM call is required to prepare or search.
대신 prepare 단계에서 결정론적 시맨틱 용어(deterministic semantic terms)를 뽑아 필드로 인덱싱한다. 랭킹도 임베딩 유사도가 아니라 필드별로 가중치를 둔 BM25 역색인(SQLite 기반, FTS5도 벡터도 아니다)으로 이뤄진다. 앞서 직접 돌려본 find 응답에서 후보가 뽑힌 이유(why)에 intent-tag, contextual-anchor 같은 항목이 섞여 있던 것이 이 계층이다. 순수 문자열 매칭을 넘어선 의도·맥락 기반 랭킹을, LLM 추론이나 임베딩 없이 결정론적으로 만들어낸다는 것이 핵심 주장이다. 준비·검색 과정에서 LLM은 전혀 호출되지 않고, LLM은 오직 에이전트가 반환된 슬레이트에서 최종 선택을 할 때만 쓰인다.
멀티미디어도 같은 틀 위에 있다. PDF·HWP/HWPX·Office·텍스트·자막·HTML·JSON/YAML·아카이브는 기본으로 파싱·인덱싱되고, 이미지·오디오·비디오는 opt-in OCR/ASR로 내용까지 인덱싱할 수 있다. 별도 임베딩 학습 없이, 미디어 브리지가 콘텐츠를 텍스트로 뽑아 같은 검색 인덱스에 태우는 방식이다.
# 이미지·오디오·비디오 내용 인덱싱은 opt-in (CPU/RAM을 쓰므로 기본 비활성)
pip install "jikji[media]"
jikji prepare ROOT --enable-media-index --media-index-max-mb 25
이 절의 내용(결정론적 시맨틱 랭킹의 품질, 멀티미디어 OCR/ASR 검색)은 레포의 설계·주장이며, 아래 "직접 돌려본 결과"에서 내가 검증한 범위와는 구분해서 읽어달라. 나는 텍스트 문서 탐색까지만 직접 확인했다.
기본 사용법
jikji가 노리는 사용 방식은 CLI를 직접 두드리는 게 아니라, 에이전트에게 스킬로 붙여두고 에이전트가 알아서 jikji find를 쓰게 하는 것이다. 저자가 공개한 안내처럼, Claude Code·Hermes 같은 에이전트에 이렇게 자연어로 시키면 된다.
GitHub 저장소 https://github.com/NomaDamas/jikji 에서 Jikji를 설치하고,
내 CLI 에이전트들이 jikji find를 바로 쓰도록 Jikji skill까지 연결해줘.
이 자연어 지시가 실제로 매핑되는 명령은 스킬 설치 계열이다. agent-skill-install은 공용 에이전트들에 jikji 스킬 지시문을 설치하고, 필요하면 특정 에이전트로 내보낼 수도 있다.
jikji agent-skill-install --agent all --json # 공용 에이전트에 스킬 설치
jikji hermes-skill-install --json # Hermes 전용
jikji skill-export --dest /path/to/agent/skills/jikji/SKILL.md --json
이렇게 붙여두면 에이전트는 파일을 찾을 때 grep·find로 헤매는 대신 jikji find를 호출하고, 앞서 본 근거 팩과 핸드오프 정책을 그대로 받아 판단한다. (이 스킬 설치 명령들은 사용자의 실제 에이전트 설정 디렉토리에 파일을 쓰므로, 이 글에서는 동작만 소개하고 직접 실행하지는 않았다.)
직접 돌려본 결과
이 도구가 실제로 약속을 지키는지 보려고, 어지러운 코퍼스를 하나 만들어 macOS에서 돌려봤다. 현재 레포는 Rust 포팅 중인 모노레포라 crates/의 Rust CLI가 정식 구현이지만, python/jikji/가 동일 동작의 레퍼런스 구현으로 남아 있다. 이 환경엔 Rust 툴체인이 없어 Python 레퍼런스 구현(0.1.0)을 소스에서 설치해 측정했다. (주의: PyPI의 jikji 패키지는 전혀 다른 Flask 정적 사이트 생성기다. 이 도구가 아니다. 반드시 레포에서 설치해야 한다.)
코퍼스는 다운로드 폴더처럼 흩어진 파일 6개로 합성했다. 회의록_최종_진짜최종.md, report_v2_draft.txt, 고객사자료/제안서.md, random_notes.txt, temp/build_log.txt, 그리고 30MB짜리 더미 dataset.csv를 여러 하위 폴더에 뿌렸다.
1. prepare는 비파괴적이고 빠르다
$ jikji prepare ./corpus
Jikji prepared: .../corpus
- files=6 folders=4 deleted=0
- docs parsed/reused/failed=0/0/0
파일 6개 기준 약 0.17초에 끝났고, deleted=0이며 내가 만든 원본 6개는 그대로였다. 그림 2단계에 나온 산출물이 실제로 .jikji/ 아래에 생성됐다. search_index.sqlite, doc_text/, file_cards.jsonl, folder_profile.jsonl, knowledge_graph.json, graph_routes.jsonl, wiki/ 가 모두 확인됐다.
한 가지 그림에 안 나온 사실도 있다. prepare는 .jikji/ 외에 코퍼스 루트에 에이전트 포인터 파일도 쓴다. 내 경우 .jikji_agent_map.md 말고도 AGENTS.md, CLAUDE.md, .cursorrules가 루트에 새로 생성됐다. 원본을 수정·삭제하진 않지만, "생성물은 .jikji/에만"이라는 요약보다는 루트에 몇 개 파일이 더 놓인다는 점을 알고 쓰는 게 좋다.
2. find는 근거가 붙은 후보 슬레이트를 돌려준다
"분기 보고서 핵심 지표 토큰"이라는 자연어 단서로 --json을 붙여 호출했더니, 정답인 downloads/report_v2_draft.txt를 1순위로 랭킹하면서 이런 근거 팩을 돌려줬다.
{
"path": "downloads/report_v2_draft.txt",
"why": ["multi-token-overlap", "doc-type-match", "intent-tag",
"contextual-anchor", "body-coverage"],
"matched_terms": ["분기", "보고서", "핵심", "지표", "토큰"],
"evidence": ["핵심 지표: Hit@1 정확도, LLM 호출 수, 총 토큰 사용량"],
"next_read": { "kind": "original", "path": "downloads/report_v2_draft.txt" }
}
주목할 부분은 이 페이로드가 단순히 경로 목록이 아니라는 점이다. 왜 이 파일이 뽑혔는지(why), 어떤 용어가 맞았는지(matched_terms), 본문 어디에 근거가 있는지(evidence), 다음에 뭘 읽어야 하는지(next_read)까지 들어 있다. 에이전트는 이걸 보고 원본을 열지 않고도 판단할 수 있다.
3. 페이로드가 추가 탐색을 막는다
find --json의 전체 응답에서 가장 인상적이었던 건 핸드오프 정책 필드였다. 응답에는 이런 것들이 함께 들어온다.
"handoff_action": "direct_use",
"answerability": "answerable_from_payload",
"tool_call_policy": {
"stop_after_find": true,
"forbidden_tools": ["read_file", "search", "grep", "rg",
"find", "fd", "ls", "cat", "tree", "glob"],
"rerank_locked": true
},
"allowed_agent_tool_calls": 0,
"allowed_llm_calls": 0
즉 jikji는 "여기 답이 있으니, grep·ls·cat 같은 도구를 더 쓰지 말고 이 페이로드로 끝내라"고 에이전트에게 명시적으로 지시한다. 토큰 절감의 메커니즘이 여기 있다. 절감은 인덱스가 빨라서가 아니라, 에이전트의 추가 탐색 루프 자체를 막아서 나온다. 이 전체 응답은 약 5.3KB(대략 1,300 토큰 상당)였다. 파일 하나 찾자고 트리를 반복해서 훑는 것과 비교하면 작다.
4. 코퍼스를 키우면 차이가 벌어진다
위 6개짜리 코퍼스는 너무 작아서 raw와 jikji가 둘 다 쉽게 맞혔다(뒤의 벤치마크 절 참고). 그래서 지저분한 작업 폴더를 좀 더 크게 흉내 낸 합성 코퍼스(파일 530개, 폴더 42개)를 만들고, 정답을 미리 아는 자연어 질의 10개로 같은 결정론적 비교(jikji 인덱스를 쓰지 않는 raw 베이스라인 vs jikji)를 다시 돌렸다. 모델 없이 순수 검색 품질만 본 결과다.
| 지표 | raw (jikji 인덱스·파서 미사용) | jikji |
|---|---|---|
| Hit@1 | 0.60 | 1.00 |
| Hit@10 | 0.80 | 1.00 |
| MRR | 0.667 | 1.000 |
같은 폴더, 같은 질의에서 jikji가 정답 파일을 상위로 올리는 능력이 분명히 좋았다. 다만 이 표는 검색 품질의 재현이지 비용·시간의 근거는 아니다. 소형 코퍼스에서는 CLI 실행이나 함수 호출 오버헤드가 시간 지표를 왜곡하므로 시간은 비교하지 않았고, 단일 합성 코퍼스에 소표본(질의 10개)이라 절대값보다 방향으로 읽어야 한다. 또 raw 쪽이 파서 캐시를 쓰지 않아 바이너리 문서 본문을 못 읽는 비대칭이 있어, 이 차이의 상당 부분은 "미리 파싱해 둔 인덱스가 있느냐"에서 온다. 바꿔 말하면 그 인덱스가 바로 jikji가 파는 것이기도 하다.
재현 메모: macOS에서 jikji Python 레퍼런스(0.1.0)를 레포 소스(
python/jikji)에서 설치해 측정했다. 1)~3)의 근거 팩 데모는 흩어진 파일 6개(더미 30MB CSV 포함) 코퍼스에서, 4)의 검색 품질 재현은 파일 530개 코퍼스에서 각각 돌렸다. 위 수치들은 단일 데모 기준이며, 절대값보다 동작의 성격에 주목해 달라. 1)~3)의wc -c기반 바이트→토큰 환산(≈4바이트/토큰)은 정밀 토크나이저 측정이 아니라 대략적 크기 감이다.
벤치마크 결과: 모델링과 실측
그림 오른쪽 아래의 "38,650 → 447 tokens", "56.7s → 2.1s"는 레포가 제시하는 벤치마크 수치다. 이 부분은 내가 직접 재현하지 못했다. 이 숫자는 실제 LLM 에이전트(Hermes)를 붙여 raw 탐색과 jikji 탐색을 비교하는 벤치마크에서 나오는데, 그러려면 LLM 에이전트 루프가 필요하다. 이 환경에서 돌린 내장 bench-run은 LLM이 없는 결정론적 렉시컬 베이스라인이라, 6개짜리 작은 코퍼스에서는 raw와 jikji가 둘 다 Hit@1=1.0으로 나와 토큰/호출 차이를 만들어내지 못했다. 즉 "왜 답이 뽑히는가"는 위에서 직접 확인했지만, "얼마나 싸지는가"의 절대 수치는 레포의 주장으로 받아들여야 한다.
레포가 밝힌 벤치마크(HippoCamp Fullset, 551건, 동일 Hermes 태스크 범위)는 다음과 같다. 아래 표와 배수는 모두 레포의 자체 측정치다.
| 지표 | raw Hermes | Jikji find | 개선 |
|---|---|---|---|
| 케이스 수 | 551 | 551 | - |
| Hit@1 | 0.6697 | 0.7949 | 상승 |
| Hit@10 | 0.7786 | 0.7949 | 상승 |
| LLM 호출 | 6,420 | 551 | 11.65× 감소 |
| 총 토큰 | 21,296,278 | 246,316 | 86.46× 감소 |
| 벽시계 시간 | 31,231.9s | 1,164.2s | 26.83× 감소 |
케이스당 평균으로 보면 raw는 11.7회 호출·38,650 토큰·56.7초를 썼고, jikji find는 1회 호출·447 토큰·2.1초를 썼다(그림의 그 숫자다). 정확도가 떨어지는 대가로 비용을 줄인 게 아니라, Hit@1이 0.67 → 0.79로 오히려 올랐다는 점이 이 벤치마크의 핵심 주장이다.
다만 이 표를 인용할 때 한 가지는 갈라 읽는 게 정확하다. 위 "Jikji find" 행은 레포가 실제로 측정한 라이브 실행이 아니라, 반환된 후보 슬레이트를 두고 LLM이 한 번에 정답을 고른다고 가정한 모델링 값이다. 레포의 docs/jikji-value-report.json에서 확인했다. 이 행은 정답 파일이 상위 후보 안에 있으면 judge가 항상 맞힌다고 보기 때문에 Hit@1과 Hit@10이 0.7949로 같고, 토큰은 하드코딩 상수와 길이 휴리스틱으로 추정하며(리포트 자신이 "실제 프로바이더 사용량이 아니라 추정치"라고 라벨링한다), 시간은 answer-pack 검색 시간(실측)에 호출당 1.5초를 가정해 더한 값이다.
같은 리포트에서 실제로 LLM 에이전트를 붙여 측정한 라이브 실행(jikji-discover)은 더 겸손하지만 그래도 분명한 승리다. Hit@1 0.688(raw 0.670), Hit@10 0.800(raw 0.779)에, 토큰은 약 2.8배(2,130만 → 760만), LLM 호출은 약 2.8배, 벽시계 시간은 약 2배(31,232s → 15,603s) 줄었다. 반대로 LLM을 전혀 쓰지 않는 순수 검색 모드(jikji-answer-pack)의 Hit@1은 0.514로 raw(0.670)보다 낮다. 정확도 상승은 후보 slate를 두고 한 번 판단하는 LLM 호출이 있어야 생긴다는 뜻이다. 정리하면 헤드라인의 "86배·27배·Hit@1 0.79"는 이 도구를 가장 이상적으로 썼을 때의 천장으로 읽고, 붙이면 바로 나오는 실측 절감은 토큰·시간 약 2~3배에 정확도 동률 수준으로 읽는 게 정확하다. 그리고 이 수치들은 NomaDamas가 단일 모델로 한 번 돌린 self-run이며 제3자 독립 재현은 아직 없다.
시리즈와 AutoRAG의 관계 (Braincrew의 해석)
같은 팀의 두 도구를 나란히 놓으면 분업이 선명하다.
- agentdir (이전 글): 원본을 건드리지 않고 에이전트가 보기 좋은 파일 레이아웃(구조)을 만든다. 파싱·인덱싱·검색은 비범위.
- jikji: 원본을 건드리지 않고 에이전트가 파일을 찾을 검색 인덱스·맵(내용)을 만든다. 구조 재배치는 하지 않는다.
- MinSync (직전 글): 임베딩 벡터 인덱스를 운영 중에 신선하게 유지한다. 바뀐 청크만 다시 임베딩한다.
셋 다 "원본 비파괴 + 에이전트용 뷰를 따로 생성"이라는 같은 철학 위에 있지만 맡는 층이 다르다. agentdir는 배치, jikji는 발견, MinSync는 의미 인덱스의 신선도다. 특히 jikji와 MinSync는 이름이 비슷해 헷갈리기 쉬운데 겨냥하는 곳이 다르다. jikji는 임베딩 없이 결정론적으로 "어느 파일인지"를 싸게 좁히고, MinSync는 임베딩 벡터 인덱스를 최신으로 유지한다. 둘은 경쟁이 아니라 이어 붙는 관계에 가깝다. jikji가 지저분한 폴더를 몇 개 후보 파일로 좁히면, MinSync로 신선하게 유지한 벡터 RAG가 바로 그 몇 개 안에서 의미 기반 심층 검색을 하는 식이다. RAG/에이전트 파이프라인 관점에서 보면 jikji는 인제스트 이전의 탐색·후보 선정 레이어로 읽힌다. 에이전트가 코퍼스에서 관련 문서를 찾는 단계를, 매번 LLM으로 헤매는 대신 결정론적 로컬 인덱스로 대체하는 셈이다. 실제로 prepare 산출물에는 autorag_manifest.json(AutoRAG 연동 계약), chunk_map.jsonl 같은 RAG 친화적 아티팩트도 포함돼 있었다. 즉 jikji가 AutoRAG를 향해 설계되고 있다는 신호는 저장소에서 확인된다. 개발팀에 따르면 jikji는 앞으로의 AutoRAG 2.0에 포함될 계획이다.
다만 이 RAG 연결은 같은 팀이 만든 도구라는 사실과 각 도구의 설계 의도에 근거한 Braincrew의 해석이지, jikji가 스스로 주장하는 통합은 아니다. jikji README는 자신을 "AI 에이전트를 위한 로컬 파일 탐색 스킬"로 소개한다. 그리고 이 글을 쓰는 시점에 "AutoRAG 2.0"이라는 공개 릴리스나 로드맵이 발표된 것은 아니다. 확실한 것은 jikji가 AutoRAG 연동 계약을 이미 산출물로 emit한다는 사실이고, 통합의 출시는 아직 예고된 방향이다.
한계와 주의점
직접 써보며, 혹은 문서를 읽으며 확인한 지점들이다.
- 정식 구현은 Rust CLI, 내가 돌린 건 Python 레퍼런스다. 두 구현은 parity 테스트로 맞춰지지만, 세부 동작이나 성능은 다를 수 있다. Rust CLI(
cargo)로 쓰면 이 글의 설치 과정과 달라진다. - 벤치마크 수치는 재현하지 못했다. 앞서 밝혔듯 토큰/호출 절감의 절대값은 LLM 에이전트 벤치마크에서 나오며, 이 글에서는 레포 주장으로 인용했다.
- prepare는 루트에도 파일을 쓴다.
.jikji/뿐 아니라AGENTS.md,CLAUDE.md,.cursorrules,.jikji_agent_map.md가 루트에 생성됐다. 원본은 안 건드리지만, 버전 관리 중인 폴더라면.gitignore처리를 고려해야 한다. - 인덱스는 스냅샷이다. 원본이 바뀌면
refresh로 다시 준비해야 하고, jikji는 인덱스가 낡았는지(freshness) 알려주되 검색 중에 몰래 재인덱싱하지는 않는다. - jikji는 두뇌가 아니다. 무엇을 찾을지 판단하는 건 여전히 에이전트다. jikji는 후보 슬레이트와 근거를 줄 뿐이고, 최종 선택은 에이전트의 몫이다.
정리
에이전트에게 로컬 폴더를 주면 매번 탐색부터 다시 시작한다. jikji는 그 비싼 탐색을 prepare 한 번으로 앞당겨 갚아두고, 이후에는 find 한 번으로 근거가 붙은 후보 슬레이트를 돌려준다.
직접 돌려 확인한 건 세 가지다. prepare는 원본을 건드리지 않고 그림 속 산출물을 실제로 만들어냈고(단, 루트에 포인터 파일 몇 개를 추가한다), find --json은 경로가 아니라 왜·무엇이·어디서 맞았는지가 담긴 근거 팩을 돌려줬으며, 그 페이로드는 에이전트에게 grep·ls·cat을 더 쓰지 말라고 명시적으로 지시했다. 토큰 절감의 정체는 빠른 인덱스가 아니라 바로 이 "그만 찾아라" 신호였다. 반면 "38,650 → 447 토큰" 같은 절대 수치는 이 환경에서 재현하지 못했고, 레포의 자체 벤치마크 주장으로 남겨둔다.
agentdir가 에이전트에게 정돈된 파일 구조를 줬다면, jikji는 그 위에서 파일을 찾는 비용을 미리 갚아주는 인덱스 레이어다. 둘 다 원본은 그대로 둔 채로.
References
- jikji (NomaDamas/jikji) - 에이전트를 위한 비파괴 로컬 파일 탐색 인덱스
- Jikji live intro - 공개 소개 페이지
- Jikji SKILL.md - 에이전트에 붙이는 스킬 지시문
- agentdir (NomaDamas/agentdir) - 에이전트용 읽기 전용 가상 파일트리 (같은 팀의 자매 도구)
- agentdir 소개 글 (Braincache) - 이 글의 앞 이야기
- MinSync (NomaDamas/MinSync) - git 없는 증분 벡터 인덱싱 CLI (같은 팀의 자매 도구)
- MinSync 소개 글 (Braincache) - 직전 시리즈 글
- AutoRAG (Marker-Inc-Korea/AutoRAG) - 같은 계열이 만든 RAG AutoML 프레임워크