카톡 검색 도구 첫 색인: '전부 찾기'는 분모부터 정해야 했다

위키룸은 처음부터 만들려던 앱이 아니다. 7월 말, 공개된 카카오톡 검색 도구 katok을 설치해 써 보려던 게 시작이었다.

katok은 다른 개발자들이 6월부터 만들어 온 오픈소스 명령줄 도구다. 맥 카카오톡 앱이 남기는 로컬 DB를 읽어 대화를 아카이브로 옮기고, SQLite FTS5 키워드 검색과 로컬 EmbeddingGemma 임베딩으로 뜻이 비슷한 대화를 찾는다. 원문과 벡터가 맥 밖으로 나가지 않는다는 점이 마음에 들었다. 이 연재는 그 도구를 내 자료 전체를 뒤지는 앱으로 키운 두 달의 기록이다.

멈춘 줄 알았다

7월 29일, 설치를 마치고 첫 동기화와 색인을 돌렸다. 당시 아카이브는 메시지 71만 개, 검색 구간 46만 개 규모였다. 색인 명령은 한참 동안 아무 말도 하지 않았다. 터미널은 조용한데 CPU는 여러 코어를 꽉 채워 돌고 팬 소리만 커졌다.

나는 멈췄다고 판단했다. 아직 돌고 있는 터미널에 다음 검색 명령까지 쳐 넣었다. 확인해 보니 프로세스는 살아 있었고 계산도 계속되고 있었다. JSON 출력 모드가 끝날 때까지 진행률을 거의 보여 주지 않았을 뿐이다.

그날 대화에서 몇 가지 경계가 드러났다. 동기화(sync)는 카카오톡 DB에서 새 메시지를 가져오는 일이고, 색인(index)은 그걸 검색할 수 있게 벡터로 바꾸는 일이다. 둘은 끝나는 시점도, 오래 걸리는 이유도 다르다. CPU 사용률 수백 퍼센트는 고장이 아니라 코어 여러 개를 쓰고 있다는 뜻이다. 그리고 터미널에 치는 명령과 AI 에이전트에게 자연어로 부탁하는 일은 같은 게 아니었다.

상태를 먼저 묻게 했다

그 뒤로 명령줄 도구를 얇은 스킬 문서로 감쌌다. 에이전트는 검색하기 전에 먼저 진단 명령(doctor)을 돌려 아카이브가 얼마나 최신인지 확인하고, 필요하면 동기화와 색인을 하고, 그다음에 검색한다. 순서를 문서에 고정해 두니 “지금 뭘 하고 있는지 모르는 상태”가 줄었다.

계산이 진행 중이어도 쓰는 사람이 그 상태를 알 수 없으면, 쓰는 사람에게는 실패다. 로컬 도구라서 더 그렇다. 서버 대시보드도 없고, 기다리는 사람은 팬 소리밖에 들을 게 없다.

한 방이 전부가 아니었다

이틀 뒤인 7월 31일에 첫 본격 조사를 맡겼다. 카카오톡에서 GitHub 저장소, 특정 AI 모델, 이미지 생성 도구에 관한 이야기를 전부 모아 달라는 요청이었다.

결과를 보고 GitHub 링크가 왜 이것밖에 없느냐고 물었다. 첫 조사는 직전 대화에서 다루던 채팅방 하나만 뒤진 결과였다. “전부”라고 했는데 분모가 방 하나였다.

전체 방을 대상으로 다시 모았다. 주제별로 원장을 따로 만들고, 검색해서 볼 수 있는 HTML 카탈로그를 만들었다. 모으는 일은 위임 에이전트에게 나눠 맡겼고, 공개용 결과에서 대화방 이름과 보낸 사람과 원문을 지웠는지 확인하는 검토를 따로 돌렸다. 그날 위임 세션 15개와 검토 세션 7개가 기록에 남았다.

전수 조사의 첫 단계는 검색어를 고르는 게 아니었다. 어디까지가 전체인지를 먼저 정하고, 결과 개수와 함께 조사 범위와 중복과 오탐, 개인정보를 뺀 과정을 같이 내놓아야 했다. 이 순서는 이후 위키룸의 모든 조사에서 반복된다.