우리는 지식 및 메모리 관리 (knowledge and memory management) 서브시스템의 방향성 1부터 3에 대한 최종 기록을 방금 마감했습니다. 이는 핵심 파이프라인인 인제스션 (ingestion), 저장 (storage), 검색 (retrieval), 그리고 컨텍스트 통합 (context integration)을 다룹니다. 이것이 아키텍처 측면에서 실제로 무엇을 의미하는지, 왜 특정 트레이드오프 (tradeoffs)를 선택했는지, 그리고 여러분의 스택에서 어떻게 사용할 수 있는지에 대해 설명하겠습니다.

이 프로젝트는 통합된 쿼리 인터페이스 (query interface)를 유지하면서 지식 지속성 (knowledge persistence)을 런타임 메모리 (runtime memory)로부터 분리하는 방법에 대해 반복적으로 개선해 왔습니다. 방향성 1-3은 그 기초를 형성합니다: 문서 저장소 (document store), 벡터 인덱스 (vector index), 그리고 이 둘을 결합한 구조화된 메모리 버퍼 (structured memory buffer)입니다. 더 이상 임시적인 캐싱 (ad hoc caching)이나 검색 루프 (retrieval loop)를 새로 만들 필요가 없습니다. 모든 것은 단일 KnowledgeGraph 인터페이스 뒤에서 작동합니다.

방향성 1: 원시 문서 인제스션 및 저장

우리는 직렬화된 콘텐츠를 위한 blob 컬럼을 포함한 로컬 SQLite 데이터베이스를 기반으로 하는 파티션된 문서 저장소 (partitioned document store)로 결정했습니다. 각 문서 엔트리는 UUID, 소스 URI, 원시 텍스트 또는 바이트, 콘텐츠 해시 (content hash), 그리고 타임스탬프 (timestamp)를 저장합니다. 인제스션 파이프라인은 해시를 통해 중복을 제거하며 선택적인 추출기 체인 (extractor chain, 예: PDF 파서, markdown 스플리터, 코드 청커)을 거칩니다. 설계 결정 사항은 저장 (storage)과 인덱싱 (indexing)을 완전히 분리하는 것입니다. 저장소는 단순합니다. 오직 CRUD와 메타데이터 쿼리 (metadata queries)만을 처리합니다. 이를 통해 인제스션 경로를 단순하고 테스트 가능하게 유지합니다.

방향성 2: 필터링 검색이 가능한 벡터 인덱스

자체적인 벡터 데이터베이스 (vector database)를 구축하는 대신, 기존 인프라인 Pinecone과 로컬 FAISS 폴백 (fallback)을 추상화 계층 (abstraction layer) 뒤로 래핑 (wrapped)했습니다. 최종 기록에는 모든 업서트 (upsert) 및 쿼리 호출 시 반드시 포함되어야 하는 필수 메타데이터 필터 세트가 명시되어 있습니다. 각 벡터 임베딩 (vector embedding)은 문서 UUID, 청크 인덱스 (chunk index), 그리고 자유 형식의 태그 맵 (tags map)을 포함합니다. 이를 통해 관련 없는 벡터를 스캔하지 않고도 “module == 'networking' 이고 version >= '2.0'인 모든 청크를 검색하라”와 같은 쿼리가 가능해집니다.

또한 이 최종화 과정은 유사도 임계값(similarity threshold) 0.65를 기준으로 최대 k개의 검색(max-k retrieval)을 50개로 제한합니다. 이 임계값보다 낮은 경우, 시스템은 노이즈가 섞인 쓰레기 데이터 대신 빈 집합(empty set)을 반환합니다. 저희는 런타임(runtime) 중 재계산을 피하기 위해 데이터 수집 파이프라인(ingestion pipeline) 내부에서 임베딩(embeddings)을 미리 계산하고 이를 캐시(cache)하기로 결정했습니다. 이로 인해 동기화(sync) 명령이 실행될 때까지 인덱스(index)가 최신 상태가 아닐 수 있지만, 이는 저희의 지연 시간(latency) 요구 사항 측면에서 수용 가능한 수준입니다.

방향 3: 컨텍스트 핸들(Context Handles)을 이용한 구조화된 메모리

이것이 가장 중요한 설계 방향입니다. 메모리는 더 이상 단순한 키-값 저장소(key-value store)가 아닙니다. 방향 3은 **컨텍스트 핸들 (context handles)**을 도입합니다. 이는 쿼리를 특정 지식 윈도우(knowledge window)에 연결하는 경량 객체입니다. 각 핸들은 현재 대화 세션(conversation session)에 대한 참조, 검색된 문서 청크(document chunks) 목록, 그리고 해당 청크 중 모델에 의해 이미 소비된 부분이 어디인지를 나타내는 "커서 (cursor)"를 보유합니다.

핸들은 JSON으로 직렬화(serialized)되어 런타임 메모리 버퍼(프로세스 내 LRU 캐시)에 저장됩니다. 요청이 도착하면 시스템은 기존 핸들이 있는지 확인합니다. 핸들이 존재하면 모든 것을 다시 검색하는 대신 커서에서부터 재개합니다. 핸들이 없다면 쿼리와 최신 벡터 검색(vector search) 결과를 바탕으로 새로운 핸들을 생성합니다.

다음은 컨텍스트 핸들이 생성되고 사용되는 방식을 보여주는 짧은 코드 예시입니다:

from knowledge_memory import ContextHandle, KnowledgeGraph

graph = KnowledgeGraph(doc_store="sqlite:///docs.db", vector_index="faiss")
...

이를 통해 대화 중 반복되는 쿼리가 동일한 문서를 반환하여 모델이 같은 말을 반복하게 만드는 전형적인 버그를 방지할 수 있었습니다. 또한 커서를 통해 점진적 요약(progressive summarization)이 가능해집니다. 즉, N개의 청크마다 시스템이 부분 요약을 생성하고 이를 다시 핸들에 저장할 수 있습니다.

개발자 경험(Developer Experience)에 미치는 영향

새로운 방향성(Directions)을 통해 설정(configuration)의 규모를 약 절반으로 줄였습니다. 별도의 데이터베이스 클라이언트(database clients), 임베딩 서비스(embedding services), 메모리 저장소(memory stores)를 일일이 연결하는 대신, 개발자는 KnowledgeGraph를 인스턴스화하고 요청 흐름(request flow)을 통해 컨텍스트 핸들(context handle)을 전달하기만 하면 됩니다. 이 핸들은 멀티턴 상호작용(multi-turn interactions)에 필요한 모든 상태(state)를 담고 있습니다.

여전히 주의를 드려야 할 점이 하나 있습니다. 컨텍스트 핸들은 기본적으로 스레드 안전(thread-safe)하지 않습니다. 프로덕션 래퍼(production wrapper)는 세션 키(session key)당 스트라이프 락(striped lock)을 사용합니다. 또한 벡터 인덱스(vector index)는 문서 저장소(document store)와 최종적 일관성(eventually consistent)을 유지합니다. 즉, 문서를 삭제하면 인덱스를 명시적으로 동기화해야 합니다. 방향성 1-3에 대한 최종 기록(finalization record)에서도 이 문제는 아직 해결되지 않았으며, 방향성 4(Direction 4)의 로드맵에 포함되어 있습니다.

현재로서는 기반이 견고합니다. 인제스션 파이프라인(ingestion pipeline)은 결정론적(deterministic)이며, 검색(retrieval)은 필터(filters)를 준수하고, 메모리 모델(memory model)은 정보 정체(information stalling)를 방지합니다. 숙련된 팀이라면 주말 사이에 이 패턴을 도입할 수 있습니다.