Cognee: AI Agent에 기억을 붙이는 오픈소스 메모리 엔진

요즘 Agent를 만드는 팀이 가장 빨리 마주치는 벽은 모델 성능이 아닙니다.
오히려 기억의 부재입니다.

프롬프트를 잘 짜도, 벡터 DB를 붙여도, 에이전트는 여전히 “지금 이 질문에 필요한 맥락”만 겨우 꺼내올 뿐입니다. 세션이 바뀌면 잊어버리고, 문서 간 관계를 깊게 이해하지 못하고, 시간이 지나 데이터가 바뀌어도 기억은 잘 자라지 않습니다.

Cognee는 바로 이 지점을 정면으로 겨냥합니다.
단순한 RAG 라이브러리가 아니라, AI Agent를 위한 지식 엔진이자 메모리 레이어를 만들겠다는 접근입니다. 저장된 문서를 검색하는 수준을 넘어서, 데이터를 그래프와 벡터, 그리고 추론 가능한 구조로 바꿔 “에이전트가 쓸 수 있는 기억”으로 재구성하려는 프로젝트입니다. 

 

GitHub - topoteretes/cognee: Knowledge Engine for AI Agent Memory in 6 lines of code

 

---

프로젝트 소개

Cognee는 오픈소스 기반의 AI memory/knowledge engine입니다. 프로젝트 설명 그대로 보면, 다양한 형식의 데이터를 받아 지속적으로 학습 가능한 컨텍스트로 바꾸고, AI agent가 적절한 맥락을 꺼내 쓸 수 있게 만드는 도구입니다. 핵심은 벡터 검색 + 그래프 저장소 + 인지적 구조화를 결합해, 데이터가 “의미로도 검색되고 관계로도 탐색되는 상태”가 되도록 만든다는 점입니다. (GitHub)

리포지토리 메타데이터 기준으로 패키지 이름은 cognee, 현재 공개된 pyproject.toml에는 버전 0.5.5가 기록되어 있고 저자로 Vasilije Markovic, Boris Arzentar가 명시되어 있습니다. GitHub 저장소는 2026년 3월 16일 기준 약 13.9k 스타와 1.4k 포크를 보여줍니다. (GitHub)

개발 환경은 꽤 현실적입니다.
기본 설치만으로도 SQLite + LanceDB + Kuzu 조합을 로컬에서 바로 쓸 수 있고, Python 3.10~3.13을 지원합니다. 내부 의존성을 보면 OpenAI, LiteLLM, Pydantic, SQLAlchemy, FastAPI, LanceDB, Kuzu, NetworkX, Uvicorn 같은 구성요소가 들어 있어, SDK 성격과 서비스 백엔드 성격이 동시에 보입니다. CLI와 로컬 UI도 함께 제공됩니다. (GitHub)

즉, Cognee를 한 문장으로 요약하면 이렇습니다.

“LLM 애플리케이션이 쓰는 데이터를, 일회성 컨텍스트가 아니라 지속 가능한 메모리 구조로 바꾸는 오픈소스 엔진”

---

왜 이 프로젝트가 등장했을까

Cognee가 등장한 배경은 꽤 명확합니다.
기존 RAG는 문서를 임베딩해서 유사한 청크를 찾는 데는 강하지만, 다음 문제를 자주 남깁니다.

1. 문서 간 관계를 잘 표현하지 못한다.
2. 비즈니스 도메인 구조를 장기적으로 축적하기 어렵다.
3. 세션을 넘나드는 기억, 사용자별 분리, 피드백 기반 진화가 약하다.
4. 시간이 지나 데이터가 바뀌면 “정적인 인덱스”처럼 굳어버리기 쉽다.

Cognee 문서도 이 문제를 비슷하게 지적합니다. 복잡한 데이터, 부족한 비즈니스 컨텍스트, 정적인 RAG의 한계를 주요 배경으로 들고 있습니다. 그리고 이를 해결하기 위해 통합 메모리 레이어를 제안합니다. 이 레이어는 벡터 검색만이 아니라 지식 그래프를 함께 사용해, 의미 기반 검색과 구조 기반 추론을 동시에 가능하게 합니다. (Cognee Documentation)

이 접근이 중요한 이유는 Agent에서 더 분명해집니다.
Agent는 단순 QA보다 훨씬 많은 걸 요구합니다. 이전 상호작용을 기억해야 하고, 서로 다른 출처의 정보를 연결해야 하고, 특정 사용자나 프로젝트 범위 안에서만 검색해야 하고, 때로는 결과의 출처와 추적 가능성까지 필요합니다. Cognee는 이런 요구를 “검색 라이브러리”가 아니라 knowledge infrastructure 문제로 본다는 점에서 흥미롭습니다. README에서도 persistent/learning agents, cross-agent knowledge sharing, traceability, tenant isolation, OTEL 기반 관측성을 핵심 가치로 내세웁니다. (GitHub)

---

Cognee의 핵심 아이디어

Cognee를 이해하는 가장 쉬운 방법은 API 이름 4개를 보는 것입니다.

• add
• cognify
• memify
• search

문서 설명상 전체 워크플로는 이 네 단계로 압축됩니다. 데이터를 넣고(add), 이를 지식 엔진 관점으로 변환하고(cognify), 메모리 레이어를 더 풍부하게 만들고(memify), 마지막으로 질문을 던져 검색합니다(search). (Cognee Documentation)

여기서 중요한 포인트는 add만으로 끝나지 않는다는 점입니다.
Cognee는 데이터를 그냥 저장하지 않고, “에이전트가 쓸 수 있는 형태”로 변환하는 중간 단계를 명시적으로 갖습니다. 이게 일반적인 벡터 인덱싱 라이브러리와 다른 결입니다.

---

핵심 기능 분석

1) 벡터 검색과 그래프 탐색을 함께 쓴다

Cognee의 중심 설계는 dual storage가 아니라, 문서상으로는 사실상 triple storage에 가깝습니다.

• relational store: 문서, 청크, provenance 추적
• vector store: 임베딩 기반 의미 검색
• graph store: 엔티티와 관계 기반 구조 탐색

검색 시에는 벡터가 관련 조각을 찾고, 그래프가 구조를 제공하며, LLM이 이를 답변으로 조합합니다. 이 설계 덕분에 단순 “유사 문장 회수”가 아니라 관계가 있는 컨텍스트 회수가 가능해집니다. (Cognee Documentation)

개발자 입장에서 이게 중요한 이유는 명확합니다.
예를 들어 “A 서비스 장애가 B 배포와 어떤 관련이 있는가?” 같은 질문은 단순 임베딩 유사도만으로는 애매합니다. 하지만 엔티티(서비스, 배포, 장애, 담당 팀)와 관계가 그래프에 들어 있으면, 질의가 훨씬 구조적으로 바뀝니다.

---

2) 메모리를 데이터셋과 NodeSet으로 조직할 수 있다

Cognee는 node_set 개념을 제공합니다.
데이터를 넣을 때 태그처럼 붙인 값이 단순 메타데이터로 끝나는 것이 아니라, 그래프 안에서 실제 노드로 물질화되고 belongs_to_set 관계로 연결됩니다. 그리고 검색 단계에서 이 범위만 제한해 탐색할 수 있습니다. (Cognee Documentation)

이건 실전에서 꽤 유용합니다.

• 프로젝트별 지식 분리
• 사용자별 메모리 분리
• 도메인별 검색 범위 제한
• 에이전트 역할별 컨텍스트 필터링

즉, “우리 회사 전체 문서”를 한 번에 다 뒤지는 게 아니라,
projectA, finance, support_bot 같은 경계를 그래프 레벨에서 관리할 수 있습니다. 단순 필터링보다 더 발전된 “지식 구조의 영역화”에 가깝습니다. (Cognee Documentation)

---

3) 로컬 개발부터 프로덕션까지 확장 폭이 넓다

기본값은 개발 친화적입니다.

• relational: SQLite
• vector: LanceDB
• graph: Kuzu

이 조합은 외부 서버 없이 로컬에서 바로 시작할 수 있습니다. 문서도 이 점을 명시하고 있습니다. 반면 프로덕션으로 가면 Postgres, PGVector, Qdrant, Redis, ChromaDB, Neo4j, Neptune, Memgraph 같은 선택지가 열립니다. 특히 그래프 저장소는 Kuzu에서 Neo4j/Neptune 계열로, relational은 SQLite에서 Postgres로 자연스럽게 넘어가는 그림입니다. (Cognee Documentation)

이 구조는 “처음엔 로컬 실험, 나중엔 서비스화” 흐름에 잘 맞습니다.
오픈소스 AI 인프라에서 자주 필요한 덕목이 바로 이 점입니다. 데모는 쉬워야 하고, 프로덕션 이전에 갈아엎지 않아야 합니다.

---

4) Agent 운영에 필요한 기능을 꽤 의식하고 있다

Cognee의 search 문서를 보면 단순 retrieval 이상을 염두에 둔 흔적이 많습니다.

• dataset-aware 검색
• permissions/access control
• session 기반 conversational memory
• observability/telemetry
• traceability/provenance

즉, “답을 잘 찾는다”보다 “누가 어떤 범위에서 무엇을 왜 찾았는지 관리 가능한 메모리 시스템”에 가깝습니다. 특히 세션 ID를 통해 검색 히스토리를 유지하는 방식은, 챗봇보다는 지속형 에이전트 런타임에 더 잘 어울립니다. (Cognee Documentation)

---

프로젝트 아키텍처 분석

Cognee의 구조를 개발자 관점에서 재구성하면 아래와 같습니다.

이 다이어그램의 핵심은 저장소가 역할별로 분리되어 있다는 점입니다.

Relational Store는 ingestion/cognification 단계에서 강합니다. 어떤 문서가 어떤 청크로 쪼개졌고, 출처가 무엇인지 추적합니다.
Vector Store는 의미 검색에 집중합니다. 질문과 비슷한 개념을 가진 텍스트 조각을 찾습니다.
Graph Store는 개체와 관계를 저장해 구조 탐색을 가능하게 합니다. 검색 시에는 벡터와 그래프가 함께 작동하고, LLM이 마지막 답변을 조합합니다. (Cognee Documentation)

이 구조를 보면 Cognee는 단순히 “RAG를 더 잘하는 도구”가 아니라,
메모리 인덱싱 레이어 + 지식 모델링 레이어 + retrieval orchestration 레이어를 한 번에 제공하려는 프로젝트라고 볼 수 있습니다.

---

실제로 어떻게 쓰는가

README의 최소 예제는 상당히 단순합니다.

import cognee
import asyncio
from pprint import pprint

async def main():
    await cognee.add("Cognee turns documents into AI memory.")
    await cognee.cognify()

    results = await cognee.search("What does Cognee do?")

    for result in results:
        pprint(result)

if __name__ == "__main__":
    asyncio.run(main())

설치도 간단합니다.

uv pip install cognee

기본 실행을 위해서는 LLM API 키가 필요합니다.

import os
os.environ["LLM_API_KEY"] = "YOUR_OPENAI_API_KEY"

그리고 CLI도 제공합니다.

cognee-cli add "Cognee turns documents into AI memory."
cognee-cli cognify
cognee-cli search "What does Cognee do?"
cognee-cli delete --all

로컬 UI는 아래처럼 열 수 있습니다.

cognee-cli -ui

이 예제만 보면 평범해 보이지만, 실제 가치는 여기에 있습니다. 개발자는 같은 흐름을 파일, URL, 구조화 데이터, dataset, node_set, 사용자별 메모리로 확장할 수 있습니다. Cognee 문서는 add가 문자열, 파일 경로, URL, 바이너리 파일, DataItem 등 여러 입력을 받을 수 있다고 설명합니다. (GitHub)

---

이런 상황에서 특히 잘 맞는다

1) 지속형 AI Agent

세션이 바뀌어도 기억이 남아야 하는 코딩 어시스턴트, 리서치 에이전트, 오퍼레이션 봇에 적합합니다. 문서도 persistent memory와 conversational memory를 주요 시나리오로 다룹니다. (GitHub)

2) GraphRAG가 필요한 도메인

문서 간 관계가 중요한 환경, 예를 들면 사내 위키 + 티켓 + 장애 이력 + 시스템 토폴로지가 얽힌 경우에 유리합니다. 벡터 검색만으로는 회수하기 어려운 “관계적 질문”에 강점을 노립니다. (Cognee Documentation)

3) 멀티테넌트/멀티프로젝트 지식 시스템

dataset-aware 검색, access control, NodeSet 구조는 SaaS형 AI 시스템이나 팀별 지식 분리 시나리오와 잘 맞습니다. (Cognee Documentation)

4) 로컬에서 빨리 실험하고 싶은 팀

초기 기본 구성이 SQLite, LanceDB, Kuzu라서 무거운 인프라 없이도 메모리 엔진 개념 검증이 가능합니다. (Cognee Documentation)

---

반대로 이런 경우엔 과할 수 있다

모든 프로젝트에 Cognee가 필요한 건 아닙니다.

문서 몇 개를 넣고 단순 FAQ 챗봇을 만드는 수준이라면,
LangChain/LlamaIndex 계열의 기본 RAG 구성이나 벡터 DB 직접 사용만으로도 충분할 수 있습니다.

Cognee가 빛나는 지점은 다음과 같습니다.

• 기억이 지속돼야 한다
• 데이터 관계가 중요하다
• 프로젝트/사용자 경계가 중요하다
• provenance와 traceability가 필요하다
• 나중에 멀티에이전트/프로덕션 구성을 고려한다

이 조건이 약하면, Cognee는 분명 더 무겁습니다.
반대로 이 조건이 강하면, 오히려 초기에 메모리 레이어를 제대로 깔아두는 편이 전체 시스템 품질을 끌어올릴 가능성이 큽니다. 이 판단은 문서가 강조하는 “knowledge infrastructure”, “persistent and learning agents”, “reliable and trustworthy agents”라는 방향성과도 맞아 있습니다. (GitHub)

---

아키텍트 관점에서 본 장점

제가 이 프로젝트를 좋게 보는 이유는 세 가지입니다.

첫째, 추상화 수준이 적절합니다.
너무 저수준 벡터 DB 래퍼도 아니고, 너무 고수준 black-box SaaS도 아닙니다. Python SDK, CLI, UI, 다양한 백엔드 선택지를 통해 개발자가 개입할 여지를 남깁니다. (GitHub)

둘째, 로컬 기본값이 훌륭합니다.
AI 인프라 프로젝트는 “데모는 멋있지만 띄우기 어렵다”는 문제가 많은데, Cognee는 기본 설치만으로 외부 서버 없이 출발할 수 있다는 점이 진입 장벽을 크게 낮춥니다. (Cognee Documentation)

셋째, 메모리를 운영 가능한 시스템으로 본다는 점입니다.
session, dataset, access control, observability, traceability 같은 요소는 장난감 데모가 아니라 실제 제품에 가까운 시각입니다. (Cognee Documentation)

---

도입 전에 알아둘 점

다만 운영 관점에서 몇 가지 체크 포인트가 있습니다.

기본 그래프 저장소인 Kuzu는 파일 기반 잠금 특성 때문에 동시성 있는 멀티에이전트 환경에는 적합하지 않으며, 문서도 이런 경우 Neo4j 같은 프로덕션용 그래프 DB를 권장합니다. relational도 SQLite 대신 Postgres를 고려해야 합니다. 즉, 로컬 기본값은 훌륭하지만, 프로덕션 아키텍처에서는 저장소 재설계가 필요할 수 있습니다. (Cognee Documentation)

또 하나는 모델/임베딩 설정입니다. 문서상 기본 OpenAI 경로가 편리하긴 하지만, 실제 서비스에서는 비용, 지연시간, 데이터 정책, 리전, rate limit을 고려해 공급자를 조정해야 합니다. Cognee는 LiteLLM 기반과 다양한 optional dependency를 통해 Anthropic, Gemini, Ollama, Groq, Hugging Face, Mistral 등 확장 폭을 열어두고 있습니다. (GitHub)

---

한 단계 더 들어가 본 해석

Cognee를 단순히 “GraphRAG 툴”로만 보면 조금 좁게 보게 됩니다.

이 프로젝트의 더 흥미로운 지점은,
LLM 애플리케이션의 상태(state)를 어디에 어떻게 저장할 것인가라는 더 큰 질문에 답하려 한다는 점입니다.

기존 챗봇 아키텍처는 보통 이렇게 흘러갑니다.

• 대화 히스토리는 Redis
• 장기 지식은 vector DB
• 구조 데이터는 RDB
• 관계형 지식은 별도 그래프
• 권한/사용자 분리는 애플리케이션 레벨

Cognee는 이 흩어진 조각을 “에이전트 메모리”라는 관점으로 다시 묶습니다. 물론 모든 것을 완전히 통합하는 것은 아니지만, 적어도 개발자에게는 하나의 메모리 파이프라인 언어를 제공합니다. add → cognify → search라는 흐름이 그 예입니다. (Cognee Documentation)

이건 앞으로 AI 애플리케이션 구조가 어떻게 변할지 보여주는 신호이기도 합니다.
RAG는 “검색을 붙인 LLM 앱”이었다면, Cognee 같은 도구는 “기억을 가진 에이전트 시스템” 쪽으로 무게 중심을 옮기고 있습니다.

---

마무리

Cognee는 단순한 문서 검색 도구가 아닙니다.
이 프로젝트가 풀고 싶은 문제는 훨씬 큽니다.

에이전트가 무엇을 기억하고,
그 기억을 어떤 구조로 저장하며,
질문이 들어왔을 때 어떤 관계를 따라 적절한 맥락을 꺼낼 것인가.

이 질문에 대해 Cognee는 꽤 설득력 있는 답을 내놓습니다.
벡터 검색만으로 부족한 부분을 그래프로 보완하고, provenance와 dataset 경계를 명시하고, 로컬 개발부터 프로덕션 백엔드까지 이어지는 경로를 제공합니다. (Cognee Documentation)

개발자 관점에서 결론은 이렇습니다.

• 단순 RAG면 과할 수 있다.
• 하지만 지속형 메모리, 관계 기반 검색, 운영 가능한 Agent 인프라가 필요하다면 꽤 진지하게 볼 만하다.

한 줄 평으로 끝내면:

Cognee는 “LLM에 검색을 붙이는 도구”가 아니라, “AI Agent에 기억을 설계하는 프레임워크”에 더 가깝다.