당신은 Claude Code와 함께 코드베이스를 다룬 지 3개월이 되었습니다. 당신이 검색 기능을 추가해달라고 요청하자, Claude Code는 Elasticsearch를 제안합니다. 당신의 팀은 지난 봄에 Elasticsearch를 검토했으나 비용 문제로 거절하고 넘어갔습니다. 리포지토리(repo) 어디에도 그 내용은 기록되어 있지 않고, 그 결정을 내렸던 사람은 이제 다른 팀에 있으며, 에이전트(agent)는 이를 알 방법이 없습니다. 그래서 당신은 똑같은 논쟁을 다시 반복하게 됩니다.

이것이 바로 AI 보조 개발(AI-assisted development)에서 아직 그 누구의 툴링(tooling)도 완전히 해결하지 못한 부분입니다. 에이전트는 코드를 유창하게 작성합니다. 하지만 에이전트가 할 수 없는 것은 왜 당신의 코드가 현재의 형태를 갖게 되었는지, 당신의 팀이 이미 무엇을 시도했는지, 그리고 무엇이 제외되었는지를 기억하는 것입니다. 그러한 지식은 사람들의 머릿속과 죽어있는 채팅 스레드에 존재하며, 모든 새로운 세션은 제로(zero) 상태에서 시작됩니다.

당연한 해결책은 메모리 레이어(memory layer)를 덧붙이는 것입니다. 좋은 것들이 있습니다. mem0, Graphiti, 그리고 Cognee가 가장 먼저 접하게 될 세 가지입니다. 이들은 모두 알 가치가 있습니다. 하지만 당신이 실제로 원하는 것이 코딩 에이전트(coding agent)에 연결된 팀의 의사결정 공유 기록이라면, 이들은 각각 관련 있는 문제를 해결할 뿐, 바로 그 문제를 해결하는 것은 아닙니다. 또한 이들을 사용하여 당신의 업무를 수행하게 한다는 것은 그들의 복잡성을 떠안는 것을 의미합니다. 여기 그 솔직한 이유가 있습니다.

이 도구들이 구축된 목적

세 가지 모두 에이전트와 애플리케이션을 위한 메모리 레이어(memory layers)입니다. 이들의 역할은 사용자나 에이전트에 대한 사실(facts)을 기억하고, 이러한 사실들이 시간이 지남에 따라 어떻게 변하는지 추적하는 것입니다. 그것은 실제적이고 어려운 문제이며, 이 도구들은 그 일을 잘 수행합니다. 다만, 그것은 소프트웨어를 구축하는 동안 팀이 내리는 의사결정을 기록하는 것과는 다른 문제입니다.

mem0는 가장 접근하기 쉽습니다. 이는 벡터 우선 (vector-first) 메모리 레이어이며, Apache-2.0 라이선스를 따르고, 호스팅 플랫폼과 MCP를 통한 깔끔한 Claude Code 통합을 제공하여 자동으로 정보를 캡처하고 회상합니다. 우리의 사용 사례에서 문제는 그것이 무엇을, 어떻게 저장하느냐 하는 점입니다. 이 도구는 텍스트를 사용자 범위의 사실 (user-scoped facts)로 추출하며, 새로운 사실이 기존 사실과 모순될 경우 기존 사실을 업데이트하거나 삭제함으로써 이를 조정합니다. 개인화 (personalization)를 위해서는 정확히 적합한 방식입니다. 하지만 의사결정 이력 (decision history) 측면에서는 형태가 잘못되었습니다. 왜냐하면 우리가 가장 보존하고 싶은 것, 즉 '왜 접근 방식 A가 거부되었는가'에 대한 이유가 덮어쓰여지는 대상이기 때문입니다.

Zep 팀이 만든 Graphiti는 세 가지 중 가장 풍부한 기능을 제공하며, 의사결정 메모리가 필요로 하는 정신에 가장 가깝습니다. 이는 시간적 지식 그래프 (temporal knowledge graph)를 구축하는 그래프 우선 (graph-first) 프레임워크입니다. 새로운 정보가 기존 사실과 모순될 때 기존 에지 (edge)를 삭제하지 않고, 이를 무효로 표시한 뒤 시간 경계 (time boundaries)를 유지합니다. 따라서 '당시에는 무엇이 사실이었고 지금은 무엇이 사실인가'를 물을 수 있습니다. 또한 사용자 정의 엔티티 (entity) 및 에지 타입을 정의할 수 있게 해줍니다. 이러한 시간적이고 비파괴적인 (non-destructive) 모델은 진정으로 올바른 원시 구성 요소 (primitive)입니다. 비용은 운영 측면에서 발생합니다. 그래프 데이터베이스 (Neo4j, FalkorDB 또는 Neptune), LLM, 그리고 임베딩 파이프라인 (embedding pipeline)을 실행해야 하며, 데이터를 구조화된 에피소드 (structured episodes)로 인입해야 합니다. 강력하지만, 구축하고 계속 실행하기에는 부담이 큽니다.

Cognee는 그 중간에 위치합니다. 이는 데이터를 지식 그래프로 변환하는 Apache-2.0 라이선스의 오픈 소스 메모리 엔진이며, 단일 Postgres 인스턴스부터 전체 그래프+벡터 스택에 이르기까지 어디에서나 실행할 수 있습니다. Claude Code 플러그인을 보유하고 있으며 커스텀 온톨로지 (custom ontologies)를 지원합니다. 하지만 내장된 버전 관리 (versioning)나 사실의 대체 (supersession) 기능이 없기 때문에, 이전 의사결정을 보존하면서 새로운 의사결정이 이전 것을 대체하는 부분은 직접 구축해야 합니다.

팀 의사결정 지식을 위한 두 가지 간극

차이점들을 제외하고 나면, 세 가지 모두에서 동일한 두 가지 간극이 나타납니다.

첫 번째는 의미론적 (semantic)인 문제입니다. 이들 중 어떤 것도 의사결정을 '일급 객체 (first-class thing)'로 모델링하지 않습니다. 의사결정, 그 근거 (rationale), 고려되었으나 거절된 대안들, 또는 새로운 의사결정과 그것이 대체하는 이전 의사결정 간의 연결에 대한 내장된 개념이 없습니다. Graphiti에서 가장 깔끔하게 구현할 수 있듯이 사용자 정의 온톨로지 (custom ontology)를 정의함으로써 이를 일부 근사할 수는 있지만, 이는 모델을 사용하는 것이 아니라 직접 구축하는 것입니다.

두 번째는 운영적 (operational)인 문제입니다. 이것들은 사실 (facts)을 위한 메모리 계층이며, 이를 팀 전체가 사용할 수 있게 하려면 모든 사람이 읽고 쓸 수 있고 검토 (review) 개념이 포함된 공유된 다중 작성자 (multi-author) 백엔드를 실행해야 합니다. 즉, 벡터 저장소 (vector store)나 그래프 데이터베이스 (graph database), 혹은 둘 다가 필요하며, 모든 쓰기 작업에 대해 추출 (extraction)을 수행하는 LLM과 이를 전면에 내세운 서비스가 추가로 필요합니다. 의사결정이 반복적으로 재논쟁되는 것을 막고 싶은 팀에게 이는 첫 번째 의사결정이 기록되기도 전에 이미 거대한 인프라 프로젝트가 되어버립니다.

이것은 도구들에 대한 비판이 아닙니다. 설계되지 않은 특정 작업을 위해 범용 메모리 계층을 사용할 때 발생하는 현상일 뿐입니다.

의사결정 메모리에 실제로 필요한 것

코딩 팀의 유스케이스 (use case)가 실제로 요구하는 것을 적어보면 목록은 짧고 구체적입니다:

• 제자리에서 수정되는 사실이 아닌, 불변의 기록 (immutable record)으로서의 의사결정
• 결정을 내린 사람이 떠나더라도 '왜'가 살아남을 수 있도록 의사결정에 결합된 근거 (rationale)
• 결정이 뒤집히더라도 이전 의사결정과 그것이 폐기된 이유를 유지할 수 있도록 하는 일급 링크로서의 대체 (supersession)
• 거절된 접근 방식과 막다른 길을 의도적으로 유지하는 것. 왜냐하면 "우리는 X를 시도했고 하루를 허비했지만, 중단한 이유는 다음과 같다"라는 정보는 X가 조용히 누락되는 것보다 훨씬 가치 있기 때문입니다.
• 팀 전체와 그들의 에이전트 (agents)가 읽고 쓸 수 있는 공유 저장소
• 이 모든 것이 코딩 루프 (coding loop) 내부에 존재하며, 에이전트가 특정 영역을 건드리기 전에 회상(recall)되고 의사결정이 내려질 때 캡처되는 것

이것은 "사용자에 대한 모든 것을 기억하라"는 목표보다 훨씬 좁은 타겟이며, 이 타겟을 좁히는 것이 대부분의 복잡한 기계 장치들을 건너뛸 수 있게 해줍니다.

kgai가 다른 점

우리는 kgai를 구축하고 있습니다. 따라서 이 글을 관심 있는 당사자의 관점으로 다루되, 설계 방식은 앞서 언급한 목록에서 직접적으로 도출됩니다.

kgai는 범용 메모리 계층 (general memory layer)이 아니며, 바로 그 점이 핵심입니다. kgai는 단 한 가지, 즉 팀이 코딩하는 동안 내리는 구조적 결정 (structural decisions)을 불변의 그래프 (immutable graph)로 기록합니다. 모든 결정에는 그 근거 (rationale)가 포함됩니다. 어떤 결정이 번복되면, 새로운 결정은 명시적인 링크를 통해 이전 결정을 대체하며, 이전 결정은 왜 폐기되었는지에 대한 이유와 함께 이력에 남습니다. 막다른 길 (dead ends)은 의도적으로 유지됩니다. 회상 (Recall) 기능은 현재 효력이 있는 결정만을 반환하므로, 에이전트 (agent)는 코드를 변경하기 전에 현재의 상황을 파악할 수 있으며, 대체된 결정들은 방향이 왜 바뀌었는지 감사 (auditing)할 때 사용할 수 있습니다. 저희 자체 리포지토리 (repo)에 접수된 첫 번째 이슈는 회상 기능이 대체된 결정들을 반환한다는 것이었습니다. 이를 통해 막다른 길을 유지하는 것과 이를 제공하는 것은 별개의 문제라는 점을 뼈아프게 배웠습니다.

운영 측면의 이야기는 위의 도구들과 가장 크게 다른 부분입니다. kgai는 로컬 우선 (local-first) 방식입니다. 저장소 (store)는 프로젝트 디렉토리 내부에 존재합니다. 벡터 데이터베이스 (vector database), 그래프 서버 (graph server), 임베딩 파이프라인 (embedding pipeline), 그리고 운영해야 할 서비스가 전혀 없습니다. 단 두 번의 명령어로 Claude Code 플러그인으로 설치됩니다. 캡처 (Capture)는 세션 내에서 발생하며, 턴 (turn)이 끝날 때 후크 (hook)가 모델이 기록하는 것을 잊은 모든 것을 잡아냅니다. 그래프는 로그 (log)로부터 결정론적 (deterministically)으로 재구축되므로, 동일한 결정은 모든 팀원의 기기에서 동일한 그래프를 생성합니다. 팀 동기화 (Team sync)는 사용자가 소유한 S3 버킷을 통해 선택적으로 참여 (opt-in)할 수 있으며, 마지막 작성자 승리 (last-writer-wins) 방식이 아닌 충돌 인식 (conflict-aware) 방식을 따릅니다. Git-remote 동기화도 지원되지만 아직 실험적 단계이므로, 현재로서는 S3를 사용하는 것을 권장합니다. 1.0 버전부터는 kg remote --global을 통해 기기 전체의 기본 원격 저장소를 설정할 수 있어, 각 프로젝트마다 별도의 설정 없이도 새로운 프로젝트가 동기화됩니다. 30명의 작성자가 생성한 100만 개의 결정이 저장된 저장소에서도 결정 조회 (decision lookup)는 약 100밀리초 내에 완료됩니다.

kgai는 2026년 7월에 1.0 버전에 도달했으며, 해당 릴리스부터 온디스크 로그 형식 (on-disk log format), kg CLI 인터페이스, 그리고 JSON 출력 형태는 유의적 버전 (semver)을 따릅니다. 따라서 이 중 어느 하나라도 파괴적 변경 (breaking change)이 발생하면 메이저 버전 업데이트가 이루어집니다. 라이선스는 MIT 라이선스입니다.

솔직한 트레이드오프 (tradeoff)는 범위 (scope)의 이면입니다. 만약 에이전트가 임의의 사실, 대화 기록, 또는 여러 제품에 걸친 사용자의 선호도를 기억하기를 원한다면, kgai는 이를 수행하지 않으며 mem0, Graphiti, Cognee가 이를 수행합니다. 그런 용도로는 해당 도구들을 사용하십시오. kgai는 당신이 계속해서 잃어버리는 것이 팀의 결정 사항이며, 이를 보관하기 위해 메모리 서비스 (memory service)를 구축하는 것이 부담스러운 경우를 위한 것입니다.

어떤 것을 선택해야 하는가

변화하는 사실에 대해 일반적인 에이전트 또는 개인용 메모리가 필요하다면 이 도구들이 강력하며, 특히 Graphiti는 시간과 이력에 대해 가장 진지한 모델을 가지고 있습니다. 만약 당신이 백엔드 (backend)를 운영하지 않고도 Claude Code 내부에서 팀의 결정, 그 근거, 번복, 그리고 막다른 길(dead ends)들이 살아남아 회상되기를 구체적으로 원한다면, 그 더 좁은 범위의 형태가 바로 kgai가 구축된 목적입니다.

이 플러그인은 오픈 소스이며, v1.0.0 기준으로 안정적이고, 두 개의 명령어로 설치할 수 있습니다. 상세 내용, 벤치마크 (benchmark), 그리고 여전히 잘 작동하지 않는 부분은 kgai.dev에서 확인할 수 있습니다.

claude plugin marketplace add kgaidev/kgai
claude plugin install kgai@kgai-marketplace