벡터 DB 없는 RAG 대안, LLM 위키로 유튜브 자막 지식베이스 만들기와 자동 적재까지

핵심 메시지

• 임베딩이나 벡터 데이터베이스 없이 마크다운 문서 몇 개와 규칙서 하나만으로 검색되는 지식베이스를 만들 수 있다.
• 아키텍처를 먼저 그리지 말고, 사용자가 실제로 무엇을 물어볼지 질문 후보부터 뽑아 도메인과 분류 체계를 역으로 설계한다.
• 원하는 검색 결과를 자연어 한 문장으로 요구하면 그 요구가 규칙서 안에 반복 가능한 규칙으로 자리 잡는다.
• 한 편으로 성공한 적재 과정을 스킬로 굳혀 에이전트에 넘기고, 예약 실행으로 하루에 한 편씩만 처리한다.
• 답변에 붙어 나온 타임스탬프는 직접 눌러 그 구간에서 실제로 그 이야기를 하는지 확인해야 한다.

쉽게 이해하기

영상은 매일 30분짜리 영상이 올라오는 채널을 다 볼 수 없다는 현실적인 문제에서 출발한다. 발표자는 한 채널의 자막을 통째로 모아 위키로 만들고, 메신저에 질문을 던지면 답변과 함께 그 답이 나온 원본 영상의 시작·끝 시각이 링크로 따라 나오게 만들었다. 여기에 벡터 데이터베이스도 임베딩도 쓰지 않았고, 마크다운 파일 몇 개와 규칙서 하나가 전부라고 밝힌다.

핵심 순서는 아키텍처가 아니라 질문이 먼저다. 발표자는 yt-dlp로 채널의 메타데이터와 자막을 먼저 모두 끌어온 뒤, 이 자료에 사람들이 물어볼 만한 질문 후보를 AI에게 역으로 뽑게 한다. 한두 영상에만 답이 있는 질문과 여러 영상에 흩어진 교차 검색형 질문을 나눠 본 다음, 그 질문 목록을 근거로 도메인과 태그 분류 체계를 정한다. 혼자 쓸 위키라면 적당히 정해도 되지만 팀이나 회사에서 쓸 위키라면 이 단계에서 합의가 필요하다고 강조한다.

그다음 규칙서에 해당하는 문서를 만든다. 발표자는 이 문서를 AI의 기억 자체가 아니라 기억을 관리하는 방법을 적어둔 회사 규정이자 데이터 설계도라고 설명한다. 처음 만들어진 규칙서에는 도메인과 태그 분류 체계밖에 없었지만, 답변에 시작·끝 시각과 원본 링크를 함께 보여 달라고 자연어로 한 문장 요구하자 계층 구분, 인용 블록, 질의 규약 같은 항목이 규칙으로 추가됐다. 표준 태그와 그 별칭을 표로 정리하는 규칙도 이 과정에서 생겼다.

마지막은 자동화다. 영상 한 편으로 성공한 수집과 적재 과정을 스킬로 만들어 에이전트 프로필에 옮기고, 질문과 결과 보고를 모두 메신저에서 받도록 연결한다. 그리고 예약 실행을 걸어 매일 새벽 정해진 시각에 새 영상이 있으면 한 편만 넣고 없으면 아무것도 건드리지 않게 했다. 한 번에 서른, 마흔 편씩 몰아넣지 말라는 조언은 문제가 생겼을 때 어디서 틀렸는지 보이게 하려는 것이다.

발표자는 이 구조가 유튜브 자막에만 해당하지 않는다고 말한다. 대본 자리에 회의록, 고객 상담 기록, 강의 자료를 넣어도 큰 구조는 그대로 돌아간다는 것이다. 다만 주식 시황처럼 시간이 지나면 사실이 뒤집히는 도메인이라면 규칙서 설계에 시간을 더 써야 한다고 덧붙인다.

주요 인사이트

• 검색이 안 되는 이유를 데이터 부족으로 돌리기 쉽지만, 발표자의 진단은 규칙의 부재다. 무엇을 어떤 이름으로 어디에 적을지 정하지 않으면 문서를 아무리 쌓아도 원하는 답이 나오지 않는다.
• 질문 후보를 먼저 뽑는 단계는 건너뛰기 쉬운 만큼 손해가 크다. 이 단계를 생략하면 분류 체계가 감으로 만들어지고, 나중에 실제 질문과 어긋난 구조를 통째로 손봐야 한다.
• 요구 사항을 자연어로 말하면 규칙으로 굳는다는 점이 이 방식의 핵심이다. 한 번 규칙이 된 요구는 이후 모든 적재에 같은 형식으로 반복 적용되므로, 사람이 매번 같은 지시를 되풀이할 필요가 없다.
• 하루 한 편이라는 적재 제한은 성능이 아니라 디버깅을 위한 선택이다. 처리 단위를 작게 유지하면 잘못된 결과가 어느 영상, 어느 규칙에서 나왔는지 추적할 수 있다.
• 출처가 붙었다고 정확한 것은 아니다. 발표자는 답변에 달린 타임스탬프를 직접 눌러 그 구간을 확인하라고 반복해서 말하며, 틀렸다면 규칙서를 고치면 된다고 안내한다.

자주 묻는 질문

관련 AI 소식