아프니까 개발자다 아프니까 개발자다

deep-wiki의 한 페이지가 세 개의 저장소에 동시에 들어간다. 그래프 DB(SQLite + NetworkX), 벡터 DB(Qdrant), 파일 시스템(wiki-output + git). "왜 셋일까? 하나로는 안될까?"이 질문에 대한 답이 사실 가장 근본적이다. 뒤따라오는 정합성 문제도, 신뢰 계층 분리도 모두 "저장소가 여러 개"라는 사실에서 파생되기 때문이다. 결론을 먼저 말하면 이렇다 — 한 페이지의 같은 정보를 가지고 사람이 물어보는 질문이 세 종류로 본질이 다르고, 그 세 질문을 하나의 저장 엔진으로 잘 답할 수는 없다. 이 글은 그 세 질문이 무엇이고, 각 저장소가 왜 존재할 수밖에 없으며, 각자 어떤 방식으로 어떤 역할을 맡는지의 기록이다.1. 배경 — 한 페이지가 답해야 하는 세 종류..

왜 벡터 DB를 상시 띄워둘 필요가 없는가로컬 RAG 시스템을 운영하다 보면 Qdrant 같은 벡터 DB를 Docker 컨테이너로 띄워두게 된다. 검색할 때, 인덱싱할 때, 야간 배치 작업에서 모두 Qdrant가 필요하니 "그냥 항상 켜두자"가 자연스러운 선택이다.그런데 실제 사용 패턴을 보면, Qdrant에 요청이 들어오는 건 하루에 몇 번 정도다. 검색 한 번, 야간 인덱싱 한 번. 나머지 23시간 동안 컨테이너는 메모리만 차지한 채 아무것도 하지 않는다.통합 메모리 아키텍처(DGX Spark처럼 CPU와 GPU가 메모리를 공유하는 환경)에서는 이 문제가 더 부각된다. Qdrant가 잡고 있는 메모리가 GPU 작업에 쓸 수 있는 메모리를 줄이기 때문이다. 25,000개 벡터(4096차원) 정도의 컬렉..

벡터 DB가 왜 필요했나나는 Obsidian으로 지식을 관리하고 있다. 공부 노트, 읽은 글 정리, 음성 메모 전사본까지 모두 마크다운 파일로 모인다. 그런데 파일이 1,300개를 넘어가면서 "이거 예전에 정리했는데 어디 있더라?"가 일상이 됐다.Obsidian의 내장 검색은 키워드 매칭이라, "GPU 메모리 관리 방법"을 검색하면 "GPU"와 "메모리"가 들어간 모든 문서가 나온다. 내가 원하는 건 의미적으로 비슷한 내용을 찾는 것인데, 키워드 검색으로는 한계가 있었다.그래서 벡터 DB 기반의 RAG(Retrieval-Augmented Generation) 시스템을 만들었다. 모든 노트를 임베딩해서 벡터로 변환하고, 질문을 던지면 의미적으로 가까운 문서 조각을 찾아주는 시스템이다.처음에는 임베디드 모드..

Claude Code CLI를 텔레그램 봇으로 연동해서 쓰고 있다. 메시지를 보내면 claude -p로 전달하고 결과를 텔레그램으로 돌려받는 단순한 구조인데, 치명적인 단점이 하나 있었다. 기억이 없다. 매 메시지마다 새로 시작하니 "아까 말한 그거"가 통하지 않았다.그래서 인간의 기억 구조를 참고해 세 가지 메모리 레이어를 설계하고 직접 구현했다. 이 글에서는 각 메모리가 왜 필요한지, 언제 기록되고, 얼마나 유지되고, 어떻게 활용되는지를 정리한다.문제: 무상태 AI 어시스턴트의 한계텔레그램 게이트웨이의 원래 구조는 이렇다:사용자 메시지 → gateway.py → claude -p --no-session-persistence → 응답--no-session-persistence 플래그가 핵심이다. 매번 ..

로컬 RAG 시스템을 운영하면서 Anthropic이 제안한 Contextual Retrieval 기법을 적용하기로 했다. 각 청크에 "이 청크가 문서 전체에서 어떤 위치에 있는지" 설명하는 짧은 접두사를 LLM으로 생성하여 임베딩에 포함시키는 기법이다.문제는 1,381개 파일에서 만들어진 3,200개 이상의 청크에 이걸 적용해야 한다는 것이었다. 순진하게 접근하면 반나절이 걸릴 작업을, 어떻게 2시간 안에 끝냈는지 정리해본다.환경하드웨어: NVIDIA DGX Spark (GB10 GPU, 128GB 통합 메모리)벡터 DB: Qdrant (Python local mode)임베딩: Qwen3-Embedding-8B (4096차원)Context 생성 LLM: Ollama로 구동대상: Obsidian 지식 금고..

왜 벡터 검색만으로는 부족한가?"6개월 전에 정리한 Kubernetes 노트"와 "어제 작성한 Kubernetes 노트"가 있다고 합시다. 벡터 유사도(Vector Similarity)만으로 검색하면 둘 다 비슷한 점수를 받습니다. 의미적으로 비슷하니까요. 하지만 실제로는 어제 작성한 노트가 더 가치 있을 가능성이 높습니다.이것이 바로 Multi-Stage Retrieval(다단계 검색)이 필요한 이유입니다. 벡터 검색으로 후보를 넓게 뽑고, 시간 감쇠(Time Decay)로 오래된 문서의 점수를 깎고, 마지막으로 Cross-Encoder로 정밀하게 재순위를 매기는 3단계 파이프라인을 만들면, 단순 벡터 검색보다 훨씬 정확한 결과를 얻을 수 있습니다.실생활 활용 시나리오시나리오 1: 개인 지식 관리 시스..

왜 벡터 DB가 필요한가?ChatGPT에게 "지난달에 정리한 Kubernetes 트러블슈팅 노트 보여줘"라고 물어본 적 있으신가요? 당연히 못 찾아줍니다. LLM(대규모 언어 모델)은 여러분의 개인 데이터를 모르니까요.이 문제를 해결하는 게 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다. 내 문서를 벡터 DB에 넣어두고, 질문하면 관련 문서를 찾아서 LLM에게 함께 전달하는 방식이죠. 여기서 벡터 DB는 텍스트를 숫자 배열(벡터)로 변환해서 저장하고, "의미가 비슷한 것"을 빠르게 찾아주는 전문 데이터베이스입니다.그런데 벡터 DB가 워낙 많습니다. 어떤 걸 써야 할까요? 가장 널리 쓰이는 3개 — Milvus, Pinecone, Qdrant — 를 비교해보겠습니다..