상세 컨텐츠

본문 제목

흩어진 AI 대화 수백 개를 검색 가능한 개인 지식베이스로 묶기

개발

by 코드스키 2026. 7. 28. 10:56

본문

Claude, Codex, Cursor 같은 도구를 번갈아 쓰다 보니 대화가 수백 개 쌓였다. 문제는 저장 여부가 아니라 찾는 일이었다. “그때 결정한 SSH 방식이 뭐였지?”라고 떠올라도 어느 도구에서 언제 얘기했는지 기억이 안 났다. 그래서 대화 로그를 한곳에 모으고, 키워드와 의미 검색을 같이 쓰는 개인 지식베이스를 만들었다. 대화 원문과 개인정보는 공개하지 않고 구조만 정리한다.

여러 AI 대화를 검색 가능한 개인 지식베이스로 묶은 과정 대표 이미지
여러 AI 대화를 검색 가능한 개인 지식베이스로 묶은 과정 대표 이미지

원본 로그와 현재 결론을 분리했다

처음에는 export한 대화를 한 폴더에 넣고 전부 색인했다. 검색 결과는 금방 소음투성이가 됐다. 같은 프로젝트 이야기가 날짜마다 반복되고, 중간에 폐기된 결정도 최신 결론처럼 섞였다.

그래서 문서를 두 층으로 나눴다.

  • 날짜별 세션 로그: 언제 어떤 도구에서 무슨 일을 했는지 추적하는 원본 기록
  • 주제별 정리 노트: 프로젝트의 현재 상태·결정·다음 행동을 한곳에 모은 문서

질문이 들어오면 먼저 정리 노트를 보고, 근거가 더 필요할 때만 세션 로그로 내려간다. 로그는 append-only에 가깝게 보존하고, 정리 노트는 최신 상태가 보이도록 갱신한다.

Markdown Guide의 기본 문법 문서 — 노트 저장 형식의 기반
Markdown Guide의 기본 문법 문서 — 노트 저장 형식의 기반

키워드 검색과 의미 검색을 같이 쓴 이유

프로젝트명, 함수명, 파일 경로처럼 정확한 문자열은 키워드 검색이 잘 잡는다. 반대로 “원격 작업을 끊어도 계속 돌린 방법”처럼 당시 표현을 기억하지 못하는 질문은 임베딩 검색이 유리하다. 한쪽만 쓰면 빈틈이 생겼다.

SQLite FTS5 공식 문서 — 로컬 키워드 검색 계층
SQLite FTS5 공식 문서 — 로컬 키워드 검색 계층

키워드 계층은 SQLite FTS5로 두고, 의미 검색 결과와 순위를 합쳤다. 희귀한 고유명사는 FTS 점수를 높게 보고, 자연어로 비슷한 기억을 찾을 때는 임베딩 결과가 보완한다. 인덱스가 망가져도 원본 Markdown은 그대로 남기 때문에 다시 구축할 수 있다.

Ollama 임베딩 모델 안내 — 로컬 의미 검색 구성 참고
Ollama 임베딩 모델 안내 — 로컬 의미 검색 구성 참고

너무 잘게 쪼개면 검색이 오히려 나빠졌다

초기에는 대화 한두 문장마다 청크를 만들었다. 그러면 비슷한 조각이 결과 상단을 점령하고, 하나의 결정이 나온 앞뒤 맥락을 읽기 어려웠다. 이후 세션 요약과 문서 섹션 단위로 압축하고, 결과에는 원문 경로와 날짜를 함께 붙였다. 검색 점수만 보여주는 대신 “어느 기록에서 나온 말인지”를 바로 열 수 있게 한 것이다.

도구마다 같은 검색 규칙을 적용한다

Model Context Protocol 공식 문서
Model Context Protocol 공식 문서

저장소를 하나 만들고 끝내면 새 도구가 그 기억을 사용하지 않는다. 그래서 “과거 작업·사람·결정·경로가 필요한 요청이면 먼저 검색한다”는 규칙을 문서로 만들고, MCP 도구로 같은 검색 함수를 노출했다. 어느 에이전트를 쓰더라도 같은 정리 노트와 로그를 본다.

기억이 충돌할 때의 규칙

오래된 대화와 현재 결정이 다르면 현재 사용자의 말이 가장 우선이다. 노트에서는 과거 결론을 몰래 지우기보다 언제 무엇으로 바뀌었는지 남긴다. 최신 상태는 문서 상단에서 명확히 표시하고, 이유가 필요하면 변경 이력으로 내려간다.

개인 지식베이스에서 더 중요한 것

  • 비밀번호·쿠키·토큰·복구 코드는 색인 전에 제거한다.
  • 외부에서 가져온 문서는 출처와 검증 상태를 따로 기록한다.
  • 검색 결과가 없으면 과거를 추측해 만들지 않는다.
  • 중요한 결정에는 날짜와 근거를 남긴다.
  • 인덱스는 파생물로 보고 원본 Markdown을 백업한다.

이 구조를 만들고 나니 대화가 많아질수록 부담이 커지는 대신, 이전 시행착오를 다시 쓰는 일이 줄었다. 완벽한 기억 장치라기보다 “현재 결론에서 원본까지 되짚을 수 있는 검색 가능한 작업 기록”에 가깝다.

공식 자료

실제로 둔 디렉터리 역할

SecondBrain/
├── 00_Inbox/          # 분류 전 메모
├── 10_Projects/       # 프로젝트별 현재 상태
├── 20_Areas/          # 계속 관리할 영역
├── 30_Knowledge/      # 재사용 지식
├── 40_Decisions/      # 결정과 변경 이력
├── 50_Conversations/  # 날짜별 도구 세션 로그
└── AI_CONTEXT/        # 검색·기억 운영 규칙

폴더 번호는 중요도 순서가 아니라 문서 역할을 고정하기 위한 장치다. 새 정보가 들어오면 Inbox나 세션 로그에 먼저 남기고, 반복해서 쓸 가치가 생겼을 때만 프로젝트·지식 노트로 승격한다. 모든 대화를 정리 노트로 만들면 또 다른 소음이 된다.

검색 결과를 답으로 바로 쓰지 않았다

query → FTS 후보 + embedding 후보
      → 점수 병합·중복 제거
      → 상위 문서 원문 확인
      → 최신 상태·날짜·출처 비교
      → 답변 또는 노트 갱신

검색 결과는 “어디를 읽을지” 정하는 후보일 뿐이다. 오래된 로그가 최신 정리 노트와 충돌하면 현재 상태를 다시 확인한다. 검색이 비어 있을 때는 기억을 만들어내지 않고 모른다고 남긴다.

같이 읽기

여러 에이전트의 실행 상태 자체를 한 화면에서 본 과정은 AI 에이전트 로컬 관제 대시보드 제작기에 정리했다.

관련글 더보기