AI에게 “내 노트들 뒤져서 답해 줘”라고 시키는 시대입니다. 그런데 그 ‘뒤지기’를 누가, 어떻게 하느냐는 생각보다 큰 차이를 만듭니다. 저는 노트 46,579개가 든 지식 창고(Obsidian vault)를 두 가지 방법으로 검색해 봤습니다.
하나는 LLM(대규모 언어모델)이 파일을 직접 읽어 뒤지는 방식(제 운영 하네스 ‘Sillok’의 기본기), 다른 하나는 Obsidian 전용 명령줄 도구(CLI)를 거치는 방식입니다. 질문은 단순합니다 — “무엇이 더 빠르고, 무엇이 더 정확한가?” 그리고 답을 낸 뒤, 저는 둘 중 하나를 고르지 않았습니다.
Claude Code 사용 분석 시리즈 — 추측이 아니라 실측입니다. 같은 vault·같은 쿼리 10종을 양쪽에 똑같이 던지고, 3회 평균으로 시간을 재고, 결과의 적합도까지 따져 본 기록입니다.
① 처음엔 전용 CLI가 4.5배 빨랐습니다(중앙값 533ms 대 2,397ms). 그런데 그 차이의 정체는 직접 읽기 방식이 호출할 때마다 노트 1.5만 개의 인덱스를 통째로 다시 만드는 낭비였습니다 — 느린 시간의 90%가 거기였습니다.
② 정확도는 한쪽이 이기지 않았습니다. 직접 읽기는 큐레이션·순위매김이 강했고(한 고객사 검색에서 21건 대 4건), CLI는 창고 전체 커버리지가 강했습니다. 다만 CLI는 Obsidian 앱이 꺼지면 아예 작동하지 않습니다(무인 자동화 불가).
③ 그래서 저는 교체가 아니라 결합을 택했습니다 — 인덱스 캐시 + 검색 묶기 + 전체조회 옵션. 결과는 직접 읽기 2,397ms → 433ms (5.5배), 까다로운 쿼리는 6.9배. CLI보다 빨라지면서, 순위·커버리지·무인운영 강점은 그대로 지켰습니다.
“검색이 느리면, 똑똑한 AI도 느립니다”
“AI가 내 자료를 근거로 답하게 하려면, 먼저 그 자료를 빠르고 정확하게 찾아와야 한다. 그 ‘찾아오기’가 매번 2~4초 걸린다면, 대화 한 번에 그 비용이 몇 번씩 쌓인다.”
— 지식베이스 + AI를 붙여 써 본 사람이라면 체감하는 병목
요즘 AI 작업의 절반은 ‘검색 증강 생성(RAG·Retrieval-Augmented Generation)’입니다. 모델이 똑똑한 것과 별개로, 내 노트·문서에서 맞는 자료를 꺼내 오는 단계가 빠르고 정확해야 답이 좋아집니다. 이 꺼내 오기를 저는 두 갈래로 할 수 있었습니다. 하나는 AI(정확히는 제 하네스)가 파일 시스템을 직접 읽어 뒤지는 길, 다른 하나는 Obsidian이라는 노트 앱의 전용 CLI에게 시키는 길입니다.
둘 다 “vault를 검색한다”는 같은 일을 하지만, 작동 원리가 완전히 다릅니다. 그래서 머리로 “이게 빠를 것이다” 단정하지 않고, 같은 창고·같은 질문으로 실제로 재 봤습니다. 그리고 그 결과는 제 예상과 절반만 맞았습니다.
- 무엇이 더 빠른가 — 그리고 그 속도 차이의 ‘진짜 원인’은 무엇인가
- 무엇이 더 정확한가 — 정확도는 한 단어로 답할 수 없습니다
- 운영에서 무엇이 더 튼튼한가 — 무인 자동화에서 갈리는 결정적 차이
- 그래서 어떻게 했나 — 교체가 아니라 둘을 합쳐 5.5배 당긴 하이브리드
‘직접 읽기’와 ‘전용 CLI’는 출발점부터 다릅니다
먼저 두 선수를 소개합니다. 같은 결승선을 향하지만, 달리는 방법이 다릅니다.
파일을 곧장 뒤진다
하네스가 노트 파일을 직접 읽어, 머리말(frontmatter) 정보로 거르고 ripgrep(아주 빠른 텍스트 검색 도구)으로 본문을 뒤집니다. 결과를 중요도 순위(tier)·관련도로 정렬해 돌려줍니다. 앱이 없어도, 백그라운드에서도 돕니다.
앱에게 물어본다
켜져 있는 Obsidian 앱에 작은 통로(unix 소켓)로 질문을 넘겨, 앱이 검색해 돌려줍니다. 창고 전체를 가볍게 훑어 빠릅니다. 대신 앱이 반드시 실행 중이어야 합니다.
변수를 줄이려 같은 창고에 같은 질문을 던졌습니다
공정하게 재려면 조건을 맞춰야 합니다. 같은 vault(노트 46,579개)에, 제가 실제로 자주 쓰는 쿼리 10종을 양쪽에 똑같이 던졌습니다. 한 번의 운으로 갈리지 않도록 각 쿼리를 3번 실행해 중앙값을 취했고, 캐시가 데워진 정상 상태(warm)에서 쟀습니다.
쿼리는 성격을 일부러 섞었습니다 — 넓은 주제어(“리더십”), 동의어가 많은 운영어(“RAG 검색”), 특정 고객사(“신한EZ 손해보험”), 그리고 일부러 제 직접 읽기 방식의 ‘사각지대’에 있는 주제(개인 기록·받은편지함 쪽 노트)까지 넣었습니다. 한쪽에 유리한 질문만 고르면 벤치마크가 거짓말을 하기 때문입니다.
- 속도 — 질문을 던지고 결과가 올 때까지의 실제 시간(밀리초)
- 적합도 — 상위 결과가 정말 쓸모 있는가(순위·관련도), 그리고 놓친 노트는 없는가(커버리지)
- 운영 견고성 — 사람이 안 보는 자동화·백그라운드에서도 작동하는가
CLI가 4.5배 빨랐습니다 — 그런데 원인이 허무했습니다
먼저 시간입니다. 결과는 분명했습니다.
CLI의 압승처럼 보입니다. 그런데 직접 읽기 방식이 왜 느린지 뜯어보자, 결과가 뒤집혔습니다. 검색 한 번을 시간 단위로 쪼개 보니 —
- 인덱스 다시 만들기: 2,614ms — 노트 14,879개를 매번 처음부터 읽고 머리말을 다시 해석. 전체 시간의 약 90%.
- 실제 검색(ripgrep): 단순 쿼리 229ms — 검색 자체는 원래 빨랐습니다.
→ 매번 똑같은 인덱스를 처음부터 다시 만들고 있었습니다. 도서관에 갈 때마다 장서 목록을 전권 다시 타이핑한 뒤 책을 찾은 셈입니다.
즉 “CLI가 빠른 것”이 아니라 “직접 읽기가 매번 헛수고를 하고 있던 것”이었습니다. 이 한 줄이 이 글의 전환점입니다. 느림의 원인이 검색이 아니라 매 호출 반복되는, 늘 똑같은 준비 작업이라면 — 그건 한 번만 만들어 두고 재사용하면 되는, 고치기 쉬운 낭비입니다.
정확도는 ‘코퍼스에 따라’ 갈렸습니다 — 한쪽의 압승이 아닙니다
속도는 한쪽이 이겼지만, 정확도는 단순하지 않았습니다. 어떤 노트를 찾느냐에 따라 승자가 바뀌었습니다.
“직접 읽기는 ‘내가 잘 정리해 둔 지식’을 똑똑하게 찾고, CLI는 ‘정리 안 된 것까지 전부’ 찾습니다. 컨설팅 자료처럼 큐레이션된 지식엔 전자가, 개인 기록까지 훑는 전수 검색엔 후자가 정확합니다. 둘은 다른 창고를 보고 있었습니다.“
결정타는 속도도 정확도도 아닌 ‘앱 의존’이었습니다
여기서 승부가 갈립니다. CLI가 빠른 비결은 켜져 있는 Obsidian 앱에 일을 시키는 것입니다. 바꿔 말하면 — 앱이 꺼지면 아무것도 못 합니다. CLI는 앱이 만들어 둔 작은 통로(unix 소켓)에 붙는데, 앱을 끄면 그 통로가 사라집니다.
제 하네스는 예약 작업·백그라운드 에이전트·규칙 자동 적용에서 검색을 부릅니다. 전부 사람이 안 보는 곳, 앱이 떠 있다는 보장이 없는 곳입니다. 그러니 CLI는 — 아무리 빨라도 — 제 검색의 주력이 될 수 없었습니다. 빠른 차가 있어도, 시동이 사람 손에만 걸린다면 무인 운행에는 못 쓰는 것과 같습니다.
아닙니다. Obsidian vault는 결국 마크다운 파일이 든 폴더일 뿐입니다. AI가 그 파일만 직접 읽으면 되지, Obsidian 앱이나 ‘Obsidian CLI’를 거칠 이유가 없습니다. 이름에 ‘Obsidian’이 붙은 명령줄 도구들은 사실 GUI 앱을 조종하려고 만든 것이라 앱에 묶입니다. 헤드리스 RAG에 맞는 건 ‘직접 읽기’처럼 파일을 곧장 읽는 도구이고, 그건 앱 없이 어디서든 돕니다.
→ 딱 하나, 의미(임베딩) 검색만은 흔히 앱 플러그인에 기댑니다. 글자 검색까지가 아니라 ‘비슷한 뜻’까지 앱 없이 하려면, 그 한 층만 헤드리스 임베더(임베딩을 직접 돌려 벡터 인덱스를 파일로 쌓는 도구)로 바꾸면 완전한 CLI-only RAG가 됩니다.
CLI는 빠르고 커버리지가 넓지만 앱에 묶여 주력이 못 됩니다. 직접 읽기는 순위·무인운영이 강하지만 느리고 사각지대가 있습니다. 그렇다면 답은 “둘 중 하나 고르기”가 아니라 — “직접 읽기의 느림·사각지대만 고쳐, CLI의 장점까지 흡수하기”입니다.
교체가 아니라 결합 — 세 가지 손질로 5.5배 당겼습니다
앞의 진단이 처방을 정해 줬습니다. 직접 읽기 방식에 세 가지를 더했습니다. 외부 도구로 갈아타지 않고, 약점만 도려내고 상대의 강점을 흡수하는 손질입니다.
한 번 만든 장서 목록을 저장해 두고, 노트가 바뀐 게 없으면 그대로 재사용합니다. 파일별 수정시각으로 변경을 감지하니, 노트를 고치면 그 부분만 다시 읽습니다.
동의어가 많은 쿼리는 검색을 수십 번 따로 돌리던 것을 한 번에 묶어 던집니다. 검색 도구를 부르는 횟수를 132번에서 12번으로 줄였습니다.
필요할 때만 켜는 ‘전체조회’ 스위치를 더했습니다. 평소엔 정리된 지식만(빠르고 깔끔), 켜면 사각지대까지 전부 — CLI의 강점을 옵션으로 흡수했습니다.
결과입니다. 같은 벤치마크를 손질 전후로 다시 돌렸습니다.
직접 읽기가 전용 CLI보다 빨라졌습니다. 그러면서 순위·큐레이션·무인운영이라는 원래의 강점은 그대로입니다(“신한EZ” 21건 회수, 순위 정렬 변함없음). 그리고 ‘전체조회’를 켜면 같은 질문에 1,130건 → 1,422건으로, 그동안 못 보던 개인기록·받은편지함 노트까지 292건 더 잡아냅니다 — CLI만의 강점이던 전수 커버리지를, 필요할 때 골라 쓰는 옵션으로 가졌습니다.
진짜 약점이 ‘검색 알고리즘’이었다면 큰 수술이 필요했을 겁니다. 그런데 약점은 매번 반복하던 헛수고(인덱스 재생성)였습니다. 헛수고는 없애면 그만입니다. 그래서 외부 도구 도입·앱 의존 같은 큰 대가 없이, 코드 한 파일 손질로 5.5배가 났습니다.
그래서 언제 직접 읽기, 언제 CLI, 언제 하이브리드인가
같은 고민을 하시는 분을 위해, 상황별로 정리했습니다. 핵심 질문은 하나입니다 — “사람이 보고 있나, 그리고 무엇을 찾나?”
- AI·자동화가 검색하나? → 직접 읽기(캐시). 앱 의존은 무인운영에서 깨진다.
- 잘 정리된 지식에서 핵심을 뽑나? → 직접 읽기. 순위·회수율이 이긴다.
- 사람이 보며 창고 전체를 훑나? → CLI(앱 켬) 또는 전체조회 옵션.
외부 도구가 빨라 보여도, 내 도구의 ‘낭비’부터 의심하세요
이번 벤치마크의 한 줄 교훈은 이것입니다 — “느린 외부 비교에 놀라 갈아타기 전에, 내 쪽이 매번 무슨 헛수고를 하고 있는지부터 보라.” 전용 CLI는 빨랐지만, 그 4.5배는 제 직접 읽기 방식이 매 호출 인덱스를 다시 만드는 낭비가 만든 거품이었습니다. 그 낭비를 걷어내자, 외부 도구의 앱 의존이라는 큰 대가를 치르지 않고도 더 빠르고, 더 정확하고, 더 튼튼한 검색을 가졌습니다.
가장 좋은 답은 ‘둘 중 하나’가 아니라 ‘강점의 결합’일 때가 많습니다. 직접 읽기의 순위·무인운영에, CLI의 속도·커버리지를 옵션으로 합친 하이브리드 — 그게 제가 내린 결론입니다.
※ 본 글의 수치는 필자 환경(노트 46,579개·맥)에서의 단일 실측치이며, 창고 규모·하드웨어·쿼리에 따라 달라질 수 있습니다. ‘직접 읽기’는 필자의 운영 하네스(Sillok) 기준이며, 일반적인 ‘AI가 파일을 읽는 방식’의 한 구현입니다. 핵심은 절대값이 아니라 ‘속도 차이의 원인을 분해하면 싸게 역전된다’는 패턴입니다.
여기서 5.5배 당긴 하이브리드의 마지막 한 층(앱 없이 도는 의미검색)을 독립 도구로 추출해 공개했습니다. → Obsidian 노트를 앱 없이 검색한다 — 오픈소스 byeori(벼리)
지식베이스 검색
RAG
Claude Code
캐시
벤치마크
Agentic PM