TechToast

20k 문서를 실제로 읽어들이기 — 로더 지옥

앞 편에서 문서 2만 개를 만나 설계를 고친 이야기를 썼다. 벡터 검색 계층을 얹고, 청크로 쪼개서 임베딩하면 된다고 적었는데, 그 문장에는 앞 단계가 하나 빠져 있다. 파일에서 텍스트를 꺼내는 일. 이게 이 프로젝트에서 제일 지루하고, 제일 오래 걸리고, 블로그에서 아무도 안 쓰는 부분이다. RAG 튜토리얼은 대부분 PyPDFLoader 한 줄로 끝난다. 실제 자료는 그렇게 생기지 않았고, 공문 하나만 열어봐도 한글 파일이 나오고, 구형 오피스 파일이 나오고, 스캔 이미지가 나온다. 이 글이 그 삽질을 반복하지 않게 해주면 좋겠다. 처리해야 했던 포맷드라이브에서 당겨온 파일의 확장자를 세어보고 정리한 목록이다. pdf docx pptx xlsx csv txt mdhwp hwpx..

개인 세컨드브레인을 RAG 없이 시작한 이유

의료영상 AI 연구를 하다 보니, 논문이며 회의록, 연구계획서, 강의자료, 과제 문서가 몇 년치 쌓였는데, 어느 순간부터는 어디에 뭐가 있는지 내 머리로 감당이 안 되기 시작했다. 검색을 해도 파일명이 기억나야 찾아지고, 파일명은 당연히 기억나지 않고. 그래서 개인 연구용 세컨드브레인을 만들기로 했다. 2026년 6월 2일이었다. 이 글은 그 첫날에 내린 설계 결정 하나에 관한 이야기다. 요즘 이런 걸 만든다고 하면 거의 자동으로 나오는 답이 있는데, 문서를 청크로 쪼개 임베딩하고 벡터DB에 넣어두고, 질문이 들어오면 비슷한 조각을 꺼내 LLM에 물리는 방식, 그러니까 RAG다. 나는 그걸 안 하기로 시작했다. 두 달 뒤에 이 시스템은 "아무짝에도 쓸모없다"는 말을 듣게 되는데, 미리 밝혀두면 그 원인은..

20,000개 문서 앞에서 설계가 무너진 날

앞 편에서, 개인 연구용 세컨드브레인을 벡터 RAG 없이 시작한 이야기를 썼다. 소스가 들어올 때 LLM 이 한 번 읽고 링크 걸린 마크다운으로 다시 쓰는 방식(Karpathy 의 LLM-Wiki 패턴)이고, 근거 중 하나가 "개인 규모에서는 사전합성이 RAG 를 이긴다" 였다. 2026년 6월 2일에 그게 엔드투엔드로 돌아가는 걸 확인했다. 같은 날 설계가 깨졌다. 이 편은 그 이야기고, 시리즈에서 제일 중요한 편이라고 생각한다. 산수 한 줄로 끝났다구글드라이브에는 대학 두 곳에서 일하며 만든 자료가 예전부터 쌓여 있었다. 브레인에 넣을 대상으로 그 폴더를 지정하고, 규모를 세어봤다. 폴더 두 개를 합쳐 문서 20,500개에, 약 53 GiB 였다. 이하 이 글에서는 약 2만 개라고 부르자. 앞 편에..