파일 하나 찾을 때마다 4만개의 토큰 / 12번의 LLM 인퍼런스 실화냐???

파일 하나 찾을 때마다 4만개의 토큰 / 12번의 LLM 인퍼런스 실화냐??? — Cheol H. Jeong

Key Insight

에이전트의 로컬 파일 탐색 병목은 모델 성능보다 검색 준비를 런타임마다 다시 하는 구조에 있으며, 이를 사전 파싱 + 파일 지도 + 필드별 인덱스 + LLM Wiki + 그래프 라우팅으로 바꾸면 토큰과 시간은 줄고 정확도는 오를 수 있다는 주장입니다.

출처: LinkedIn / Cheol H. Jeong
타입: SNS 포스트
유효일: 2026-06-23 (4일 표기를 2026-06-27 수집 시점 기준으로 환산)
Raw: 2026-06-27-https-www-linkedin-com-posts-chjeong-ed-8c-8c-ec-9d-bc-ed-95-98-eb-82-98-ec-b0-b.md

핵심 Takeaway

• Hermes Agent 같은 CLI 에이전트가 기본 grep/find 중심 탐색에 의존하면 파일 1건 찾는 데도 LLM 호출과 토큰 사용량이 과도하게 커질 수 있다는 문제 제기다.
• Jikji는 로컬 파일을 미리 파싱하고, 파일 내용·메타데이터·관계 정보를 탐색 가능한 지도 형태로 준비해 에이전트 탐색 비용을 크게 줄이려는 도구로 소개된다.
• 포스트와 공개 벤치마크 페이지 기준으로, HippoCamp Fullset 551건에서 raw Hermes 대비 LLM calls 6,420 → 551, 총 토큰 21.30M → 0.25M, 시간 520분 → 19분, Hit@1 0.6697 → 0.7949를 제시한다.
• 작성자는 임베딩 모델이나 클라우드 RAG 없이도 deterministic semantic 전략과 LLM Wiki 스타일 저장 구조로 시맨틱 검색이 가능하다고 주장한다.

원문 요지

• 작성자는 Hermes Agent에 LLM을 연결해 로컬 파일을 찾을 때 평균적으로 많은 토큰·인퍼런스·시간이 낭비된다고 설명한다.
• 특히 HWP, PDF 등 비텍스트 문서 탐색이 어렵거나 비효율적이었고, 기본 CLI 검색도구 중심 구조로는 문서 외 이미지·영상 내용 기반 검색까지 확장하기 어렵다고 본다.
• 이를 해결하기 위해 Jikji를 만들었으며, 모든 종류의 로컬 파일을 미리 파싱하고, 파일 내용과 메타정보를 바탕으로 탐색 지도를 만들고, 에이전트 친화적인 LLM Wiki 스타일과 지식그래프를 함께 사용한다고 설명한다.
• 설치 후 CLI 에이전트가 jikji find를 바로 쓰도록 연결하는 흐름을 제안한다.

공개 벤치마크에서 확인된 보강 정보

• 공개 벤치마크 페이지: https://nomadamas.github.io/jikji/jikji-benchmarks.html#examples
• 페이지 설명 기준 Jikji의 절약 구조는 다음 다섯 층으로 정리된다.
  1. 사전 파싱: PDF, HWP/HWPX, Office, text, subtitles, HTML, archive, opt-in media OCR/ASR 본문 캐시
  2. 파일 탐색 지도: folder profile, file card, duplicate hint, route row
  3. Fielded index: 경로/파일명/폴더/확장자/본문/메타데이터/deterministic semantic terms 분리 점수화
  4. LLM Wiki: 각 파일을 grounded Markdown source page로 압축
  5. Knowledge graph: source, folder, term, intent, duplicate graph와 graph_routes 활용
• 동일 페이지는 “기본 코어는 벡터DB·임베딩·클라우드 RAG 없이 동작한다”고 명시한다.

JYP Labs 운영체계 시사점

스킬화

• 후보: agent-local-search-with-jikji
• Trigger: “로컬 문서/영상/이미지에서 근거 파일 찾아줘”, “Hermes가 파일 찾느라 토큰을 너무 쓴다”
• Inputs: 검색 루트 경로, 대상 파일군, 질문, 허용 포맷(HWP/PDF/영상/이미지 포함 여부)
• Outputs: 상위 후보 파일, 근거 source page, 확인 필요 항목, 후속 요약/추출 대상
• Verification: 찾은 파일 경로·근거 스니펫·원문 타입·검색 소요를 함께 남겨야 함

자동화

• Trigger: 새 프로젝트 볼트/드라이브/로컬 폴더 온보딩
• Input: 루트 폴더, 지원 파일 형식, 재색인 주기
• Output: 사전 파싱된 검색 지표, LLM Wiki source page, graph route, 에이전트 검색 엔트리포인트
• Approval boundary: 고객사 민감 문서의 외부 전송·클라우드 업로드·삭제는 사람 승인 필요

인프라

• “임베딩/RAG를 붙여야 시맨틱 검색이 가능하다”는 고정관념 대신, 결정론적 메타데이터 인덱스 + 문서 위키화 + 그래프 라우팅 조합이 로컬 환경에서 더 경제적일 수 있음을 보여준다.
• JYP Labs의 OMW/Obsidian/프로젝트 저장소에도 “질문 시 검색”보다 “수집 시 구조화”를 더 강하게 적용할 근거가 된다.

연결되는 노트

• Jikji — 본 포스트에서 소개된 로컬 파일 탐색/인덱싱 도구.
• deterministic-semantic-file-discovery — 임베딩 없이 사전 파싱·필드 인덱스·LLM Wiki·그래프 라우팅으로 검색 비용을 줄이는 접근.
• llm-wiki — 파일을 에이전트 친화적 Markdown 증거 페이지로 바꿔두는 구조.
• hermes-agent — 비교 대상이 된 CLI 에이전트 런타임.

확인 필요

• GitHub 설치 저장소의 최종 canonical URL은 원문이 lnkd.in 단축 링크로만 제시해 이번 수집 범위에서는 직접 확정하지 못했다.
• “평균 4만 토큰 / 12번 인퍼런스 / 57초” 수치는 포스트 본문 주장으로 확인되며, 동일 조건 재현 실험은 별도 필요하다.
• LinkedIn 공개 페이지 수집 특성상 본문 편집 이력, 첨부 이미지, 전체 댓글 맥락은 누락 가능성이 있다.