최근, 로컬 LLM에 과거의 대화를 기억시킬 수 없을까 하는 생각을 하게 되었다.

언뜻 보기에는 과거의 대화를 모두 읽어들이면 끝날 것처럼 보인다. 하지만 대화가 늘어날수록 문장량도 늘어나며, 처리 시간과 토큰 소비가 불어나게 된다.

필요할 때, 필요한 부분만 추출하고 싶다. 여기서 등장하는 것이 **벡터 데이터베이스 (Vector Database)**이다.

문장을 「단어」가 아니라 「의미의 유사성」으로 찾는 데이터베이스

통상적인 검색은 입력한 글자와 동일한 글자가 포함되어 있는지를 찾는다.

예를 들어, 대화 로그에 다음과 같은 문장이 저장되어 있다고 하자.

• 멀리 있는 물건을 잡으려 하면 어깨가 아프다
• 오십견 재활 치료를 다니고 있다
• 팔을 뻗는 동작이 힘들다

여기서 「손을 뻗으면 어깨가 아프다」라고 검색해도, 완전히 똑같은 단어는 존재하지 않는다. 키워드 검색으로는 찾아내기 어렵다.

하지만 벡터 검색이라면 「팔을 뻗다」, 「멀리 있는 물건을 잡다」, 「어깨가 아프다」와 같은 의미의 유사성을 판단하여 관련 대화를 찾아낼 수 있다.

다룰 수 있는 것은 문장뿐만이 아니다. 이미지나 음성도 마찬가지로 수치로 변환하여 검색할 수 있다.

벡터 데이터베이스는 커다란 주방의 식재료 선반이라고 생각하면 이해하기 쉽다.

이 선반은 이름이나 품번 순이 아니라, 맛이나 용도가 비슷한 것들이 자연스럽게 옆에 놓이도록 배열되어 있다.

그곳에 주문이 들어온다. 담당자는 주문서를 읽고, 내용에 어울릴 법한 식재료를 몇 가지 골라 조리대에 올려놓는다. 요리사는 그 조리대에 놓인 것들만 보고 요리 한 접시를 만든다.

역할을 정리하면 다음과 같다.

LLM: 조리대의 재료를 사용하여 요리 한 접시를 완성하는 요리사 -
벡터 데이터베이스 (Vector Database): 식재료를 보관하는 선반 -
Embedding 모델: 식재료를 「맛의 유사성」으로 재배열하는 메커니즘 -
RAG: 주문으로부터 재료를 모아 요리사에게 전달하기까지의 일련의 흐름

중요한 점은 선반도 담당자도 요리를 하지 않는다는 점이다. 벡터 데이터베이스는 AI의 뇌가 아니라, 재료를 꺼내오는 메커니즘에 불과하다.

그리고 이 선반의 강점은, 바질이 떨어져 있어도 깻잎을 꺼낼 수 있다는 점에 있다. 이름이 일치하지 않아도 유사한 것을 선택할 수 있다. 이것이 그대로 의미 검색의 성질이다.

컴퓨터는 문장의 의미를 그대로 이해하고 있는 것이 아니다.

문장을 Embedding 모델에 전달하면 다음과 같은 수치의 나열로 변환된다.

[0.023, -0.184, 0.771, 0.092, ...]

이를 벡터 (Vector) 또는 Embedding이라고 부른다.

비슷한 의미의 문장은 벡터 공간 안에서도 가까운 위치에 배치된다.

오늘은 폭우로 인해 귀가하기가 힘들었다
심한 비 때문에 귀가하는 데 고생했다

이 두 문장은 단어가 달라도 의미가 가깝기 때문에 비교적 가까운 벡터가 된다.

검색 시에는 질문도 동일한 모델로 수치화하여, 저장된 벡터와의 거리를 계산한다. 거리 측정 방식은 유클리드 거리나 내적 등으로, 코사인 유사도(Cosine Similarity)도 정규화된 벡터의 내적으로 다룰 수 있다.

과거의 대화를 저장한다
↓
화제별로 작게 분할한다
...

예를 들어 「전에 검토하던 외장 GPU가 뭐였지?」라고 묻는다고 가정하자.

벡터 데이터베이스가 「OCuLink 연결 방식의 eGPU를 검토하고 있었다」, 「NVIDIA의 RTX 계열이 후보였다」, 「MINISFORUM DEG1 Dock에 대해 이야기했다」와 같은 파편을 찾아내면, LLM은 그것만을 읽고 대답한다. 방대한 로그를 매번 전부 읽게 할 필요는 없다.

이 구성이 일반적으로 **RAG (Retrieval-Augmented Generation / 검색 증강 생성)**라고 불리는 것이다. LLM을 재학습시키지 않아도 사내 자료나 상품 데이터, 매뉴얼, 과거의 대화를 답변 재료로 전달할 수 있다.

대화 로그를 하나의 거대한 문장으로 저장하면 검색 정밀도가 떨어지기 쉽다. 그래서 적당한 크기로 분할한다. 이 단위를 **청크 (Chunk)**라고 부른다.

다만 기계적으로 500자씩 자르면 되는 것은 아니다. 외장 GPU 이야기, CSV 처리 이야기, 영어 학습 이야기——화제별로 구분하는 편이 찾기 쉽다.

나아가 각 청크에는 메타데이터 (Metadata)를 붙일 수 있다.

{
"date": "2026-08-05",
"category": "AI",
...

「category가 AI인 것만」, 「2026년 이후만」과 같은 필터링이 가능해진다. Chroma에서는 이러한 메타데이터를 통한 필터링과 벡터 검색을 조합할 수 있다.

AI에게 기억을 갖게 할 때, 정말 어려운 것은 저장하는 부분이 아니다.

• 무엇을 기억하고, 무엇을 기억하지 않을 것인가
• 언제 떠올릴 것인가
• 오래된 정보를 어떻게 업데이트할 것인가
• 어떤 정보를 잊게 할 것인가

예를 들어 과거에 "Go 언어를 중심으로 학습한다"라고 말했더라도, 나중에 "Rust를 중심으로 한다"라고 방침이 바뀔 수 있다. 두 가지를 동일한 강도로 저장하고 있다면, AI는 오래된 방침을 꺼내올 수도 있다.

그렇기 때문에 개인용 AI의 기억은 이층 구조로 다루는 것이 용이하다.

원래의 대화 로그 (증거로서 남김)
+
현재의 방침이나 취향을 정리한 장기 기억 (Long-term Memory)

저장·검색·요약·갱신·망각까지 포함되어야 비로소 기억 시스템이 된다.

주방에 비유하자면, 식재료 선반과는 별도로 재고 장부가 있는 것과 같다. 개수나 원가, 유통기한은 맛의 유사성으로 나열해도 의미가 없다.

Yahoo Shopping의 상품 관리로 비유하자면, 상품 코드, 재고 수, 매입 가격, 단종 플래그와 같은 정확한 값이 이에 해당한다. 이러한 데이터는 CSV나 SQLite, PostgreSQL이 더 적합하다.

정확한 값을 찾는다 → 일반적인 데이터베이스 (Database)
의미가 가까운 정보를 찾는다 → 벡터 데이터베이스 (Vector Database)

이미 PostgreSQL을 사용하고 있다면, pgvector를 추가함으로써 두 가지를 동일한 데이터베이스 내에 둘 수 있다. pgvector는 정확한 최근접 이웃 검색 (Exact Nearest Neighbor Search)과 근사 최근접 이웃 검색 (Approximate Nearest Neighbor Search)을 모두 지원한다.

Chroma: Python에서 간편하게 테스트할 수 있다. 초기 학습용으로 적합 -
Qdrant: 서버형. Docker로 구동하기 쉽고, Rust나 Go 클라이언트도 있다 -
PostgreSQL + pgvector: 기존 시스템에 의미 검색을 추가하고 싶을 때 편리 -
Faiss: 엄밀히 말하면 라이브러리. 검색 알고리즘을 배우고 싶을 때 적합 -

이 외에도 Milvus, Weaviate, Pinecone, LanceDB 등이 있다. 다만 제품 비교에 시간을 쓰기보다는, 소량의 데이터를 실제로 검색해 보는 것이 이해가 빠르다.

갑자기 수만 건을 넣을 필요는 없다. 20건에서 50건 정도의 짧은 메모면 충분하다.

Python으로 CSV의 가격 차이를 확인하고 있음
Go 언어의 포인터를 공부하고 있음
Rust의 소유권에 관심이 있음
...

이에 대해 "최근 공부하고 있는 프로그래밍 언어는?"라고 검색해 본다. Go나 Rust 메모가 상위에 나온다면, 의미 검색의 감각을 잡을 수 있다.

구성(Configuration)은 이 정도면 충분하다.

Python + Chroma + 로컬 임베딩 (Embedding) 모델 + 20~50건의 메모

중요한 것은 프로그램을 완성하는 것이 아니다. 질문을 조금씩 바꿔가며,

어떤 문장이 검색되었는가
왜 그 문장이 선택되었는가
관련 없는 문장이 섞여 있지는 않은가

를 살펴보는 것이다. 이 작업이 가장 빠른 지름길이 된다.

벡터 검색은 의미의 유사성을 찾는 메커니즘이지, 정확성을 보장하는 메커니즘이 아니다. 비슷하지만 관련 없는 문장이 섞일 수도 있다.

정밀도는 임베딩 (Embedding) 모델, 청크 (Chunk) 분할 방식, 저장하는 문장의 품질, 검색 건수, 메타데이터 (Metadata), 질문 작성 방식에 따라 좌우된다. LLM에 전달하기 전에 관련도를 평가하거나, 날짜나 카테고리로 필터링하는 등의 궁리가 필요하다.

마법의 기억 장치가 아니다. 그럼에도 키워드가 일치하지 않아도 관련 정보를 찾을 수 있다는 점은 기존 검색에는 없는 강점이다.

장래에 벡터 검색이나 RAG는 AI 시스템의 표준 기능이 되어, 직접 다룰 기회는 줄어들지도 모른다.

그럼에도,

• AI에게 기억을 갖게 하는 기술
• 의미의 유사성으로 검색된다
• 필요한 정보만 LLM에 전달된다
• 청크나 메타데이터에 따라 정밀도가 변한다
• 기억에는 갱신과 망각도 필요하다

라는 원리를 알고 있다면, "왜 관련 없는 기억을 꺼내왔는가", "왜 필요한 대화를 떠올리지 못했는가"를 생각할 수 있다.

벡터 데이터베이스에 대한 지식 자체는 언젠가 일반화될 것이다. 하지만, AI에게 무엇을 기억시키고, 무엇을 잊게 하며, 언제 떠올리게 할지를 설계하는 능력은 앞으로도 남을 것이다.

벡터 데이터베이스란 문장이나 이미지를 수치로 변환하여, 의미의 유사성으로 정보를 찾는 메커니즘이다. LLM과 조합하면 과거의 대화나 자료를 필요할 때만 꺼내어 답변에 사용할 수 있다.

단, 목적은 벡터 데이터베이스를 사용하는 것이 아니다.

AI가 필요한 정보를, 필요한 상황에서 떠올릴 수 있게 하는 것

우선은 소량의 메모를 저장하고, 말을 바꾸어 검색해 본다. 그 작은 실험으로부터 임베딩 (Embedding), 유사 검색, RAG, 그리고 AI의 기억이라는 메커니즘이 조금씩 연결되어 보일 것이다.