잊지 않는 Agent 만들기 (12분 읽기)

LLM은 본질적으로 stateless라서, 대화에서 느끼는 기억은 매번 과거 기록을 다시 붙여 넣는 방식으로 만들어진다. 이 방식은 간단한 채팅에는 충분하지만, 실제 Agent를 만들면 곧바로 한계가 드러난다.

기억이 없으면 같은 정보를 다시 묻게 되고, 개인화가 사라지며, 멀티스텝 작업 중간 상태가 끊긴다. 반복 실수도 고쳐지지 않고, 세션이 바뀔 때마다 지식이 축적되지 않으며, 컨텍스트가 넘치면 모델이 빈틈을 메우며 환각을 만들기 쉽다.

해결책으로 흔히 더 긴 컨텍스트 윈도우를 떠올리지만, 그것만으로는 부족하다. Lost in the middle 현상처럼 관련 정보가 길어진 문맥의 중간에 있으면 정확도가 떨어지고, 시스템 프롬프트, 대화 기록, 검색 문서, 출력이 모두 같은 토큰 예산을 나눠 쓰기 때문에 단순 확장에는 분명한 한계가 있다.

그래서 메모리를 인간의 기억 체계처럼 나눠 봐야 한다. Sensory memory, working memory, long-term memory가 각각 입력 보존, 현재 사고, 장기 저장을 맡듯이, Agent도 즉시 작업용 상태와 장기 기억을 분리해야 한다. 장기 기억은 다시 episodic, semantic, procedural로 갈라지며, 반복된 사건이 일반 규칙으로 굳는 memory consolidation이 중요해진다.

가장 단순한 Agent는 매 호출마다 독립적으로 동작한다. 여기에 Python list로 전체 대화 이력을 붙이면 멀티턴은 가능해지지만, 리스트가 무한히 커져 결국 컨텍스트 한계에 닿고, 프로세스가 끝나면 기억도 사라진다.

다음 단계는 Markdown 파일로 메모리를 디스크에 저장하는 방식이다. 이 방법은 사람이 직접 열어보고 수정할 수 있어 프로토타입에는 유용하지만, 데이터가 수천 개의 사실과 수백 개의 로그로 커지면 키워드 검색만으로는 의미적 동의어나 문맥 연결을 찾기 어렵다.

그다음은 vector search다. 임베딩으로 의미 유사도를 찾으면 "database"와 "PostgreSQL" 같은 표현은 연결되지만, 여러 사실을 이어 주는 관계성은 여전히 약하다. 사람, 프로젝트, 시스템, 장애처럼 두세 단계 이상 건너가는 질문은 평평한 벡터 검색만으로는 답하기 어렵다.

이 문제를 풀기 위해 필요한 것은 persistence, semantic understanding, relational reasoning을 함께 담는 메모리 계층이다. 글은 이를 위해 vector DB, graph DB, relational store, entity extractor, deduplication pipeline, edge weighting system을 직접 엮는 대신, Cognee라는 오픈소스 지식 엔진을 소개한다.

Cognee는 three-store architecture를 사용한다.

• Relational store: provenance와 접근 이력
• Vector store: 의미와 유사도
• Graph store: 엔티티 간 관계

API는 네 개의 비동기 호출로 단순화되어 있다.

• add()로 문서를 넣고
• cognify()로 knowledge graph와 embeddings를 만들고
• memify()로 메모리를 개선하고
• search()로 추론을 포함한 검색을 수행한다.

기본 스택은 SQLite + LanceDB + Kuzu처럼 임베디드 파일 기반으로 구성되어, 빠르게 시작하면서도 관계형·벡터·그래프 메모리를 한 시스템에서 다룰 수 있다는 점이 핵심이다.