DKG V10, AI 에이전트의 공유·검증 메모리

DKG V10, AI 에이전트의 공유·검증 메모리

— 세션마다 사라지는 컨텍스트를 프로젝트의 자산으로 바꾸는 구조

들어가며

AI 에이전트는 코드를 작성하고, 자료를 조사하고, 문서를 검토하며 실제 업무를 수행하기 시작했다. 하지만 세션이 끝나거나 다른 도구로 넘어가면 앞에서 쌓은 맥락은 쉽게 끊어진다.

Claude Code에서 확인한 내용을 Codex가 알지 못하고, Cursor가 정리한 설계 결정을 다른 에이전트가 다시 조사한다. 에이전트는 늘어났지만 프로젝트의 기억은 여전히 각 도구와 세션 안에 갇혀 있다.

DKG V10은 이 문제를 단순한 메모리 기능이 아니라 공유되고 검증 가능한 메모리 인프라의 문제로 다룬다.

에이전트가 만든 지식은 개인 작업에서 시작해 팀과 공유되고, 필요한 경우 출처와 무결성을 확인할 수 있는 영구 기록으로 발전한다.

기억 기능과 메모리 인프라는 다르다

일반적인 AI 메모리는 한 사용자와 한 플랫폼을 중심으로 작동한다. 이전 대화나 선호도를 기억하는 데는 유용하지만, 여러 에이전트가 같은 프로젝트에서 협업하기 시작하면 한계가 드러난다.

한 플랫폼의 기억은 다른 도구에서 바로 사용할 수 없고, 저장된 정보의 출처와 신뢰 수준도 확인하기 어렵다.

DKG V10은 메모리를 특정 에이전트 안에 두지 않는다.

Working Memory와 Shared Working Memory는 사용자가 운영하는 노드에 남고, 장기적으로 보존할 지식은 Knowledge Asset으로 발행된다. 모델이나 도구가 바뀌더라도 프로젝트의 기억은 같은 지식 그래프 위에 유지된다.

핵심 질문은 “AI가 기억하는가”가 아니다.

• 다른 에이전트가 이전 작업을 이어받을 수 있는가

• 그 기억의 출처와 무결성을 확인할 수 있는가

• 플랫폼을 바꿔도 프로젝트의 맥락이 남는가

DKG V10은 이 문제를 하나의 메모리 구조로 묶는다.

평면적인 기록을 지식 그래프로 바꾸는 이유

대화 로그나 벡터 검색은 비슷한 문장을 찾는 데 유용하다. 하지만 여러 발견 사이의 관계를 연결하는 데는 한계가 있다.

DKG V10은 지식을 단순한 문장이 아니라 관계로 저장한다.

한 에이전트가 기업의 인수 사실을 찾고, 다른 에이전트가 관련 인물의 소송 이력을 확인했다면, 두 결과는 서로 떨어진 문서가 아니라 같은 그래프 안에서 연결될 수 있다.

이 구조에서는 “비슷한 문서가 무엇인가”뿐 아니라 다음과 같은 질문이 가능해진다.

• 이 결정과 연결된 모듈은 무엇인가

• 이 주장에 사용된 출처는 무엇인가

• 어떤 에이전트가 이 결과를 만들었는가

• 현재 프로젝트에서 검증이 끝난 내용은 무엇인가

한 에이전트의 결과가 다음 작업의 출발점이 되고, 새로운 발견이 기존 관계에 연결되면서 프로젝트의 지식은 계속 확장된다.

Context Graph, 여러 에이전트가 함께 일하는 공간

DKG V10에서 협업은 Context Graph를 중심으로 이뤄진다.

Context Graph는 하나의 프로젝트, 연구, 애플리케이션 또는 에이전트 팀이 공유하는 지식 공간이다. 참여 범위와 발행 권한을 설정하고, 필요하면 여러 참여자의 승인을 요구할 수도 있다.

리서치 에이전트가 출처를 확인해 그래프에 남기면, 개발 에이전트는 그 결과를 바탕으로 구현하고, 검수 에이전트는 기존 정책과 결정 근거를 조회해 결과를 확인할 수 있다.

Context Graph는 단순한 공유 폴더와 다르다.

파일 자체뿐 아니라 파일에서 추출한 사실, 설계 결정, 출처, 변경 이력과 관계가 함께 쌓인다. 새로운 에이전트가 합류하더라도 과거 대화를 모두 다시 읽지 않고 현재 프로젝트의 맥락을 직접 질의할 수 있다.

공유된 기억과 검증된 기억은 다르다

같은 기억을 공유한다고 해서 그 내용이 자동으로 신뢰할 수 있는 것은 아니다.

잘못된 정보가 공유되면 오류도 더 빠르게 확산될 수 있다. 그래서 DKG V10은 공유된 지식과 검증 가능한 지식을 구분한다.

장기적으로 보존할 지식은 Knowledge Asset으로 발행된다. 여기에 그래프 데이터, Merkle 증명, 발행자와 발행 시점이 연결되며, 이후 내용이 발행 뒤 변경되지 않았는지 확인할 수 있다.

다만 블록체인이 내용의 진실을 자동으로 판정하는 것은 아니다.

블록체인은 누가 어떤 내용을 언제 발행했고, 이후 조작되지 않았는지를 증명한다. 실제 타당성은 출처와 검토 과정, 승인 구조를 함께 봐야 한다.

필요한 경우 여러 참여자 중 일정 수가 동의해야 최종 확정되는 M-of-N 검증도 적용할 수 있다.

기존 AI 도구를 같은 기억에 연결한다

DKG V10은 기존 AI 워크플로우를 대체하기보다 하나의 기억에 연결한다.

MCP를 통해 Claude Code, Cursor, Windsurf, Copilot Chat, Cline, Codex CLI 같은 도구를 연결할 수 있고, OpenClaw와 Hermes를 위한 연동 방식도 제공한다.

코드 작성에는 Codex를 사용하고, 리서치에는 Claude를 사용하더라도 프로젝트의 기억은 같은 DKG 노드와 Context Graph에 남는다.

에이전트가 메모리를 소유하는 것이 아니라, 사용자가 메모리를 소유하고 여러 에이전트가 그 위에서 작업하는 구조다.

이렇게 되면 도구를 바꿀 때마다 프로젝트를 다시 설명하지 않아도 되고, 담당 에이전트가 달라져도 이전 결정과 출처를 이어받을 수 있다.

에이전트가 많아질수록 공유 메모리는 더 중요해진다

멀티에이전트 협업은 여러 AI를 동시에 실행한다고 완성되지 않는다.

각 에이전트가 같은 정보를 다시 조사하고 별도 문서에 결과를 남긴다면 활동량은 늘어도 지식은 충분히 축적되지 않는다.

OriginTrail이 공개한 코딩 스웜 실험에서는 DKG 공유 그래프를 사용한 방식이 특정 복합 작업에서 마크다운 인계 방식보다 더 빠른 완료 시간과 낮은 토큰 사용량을 기록했다. 이는 특정 실험 환경의 결과이며 모든 작업에서 동일하게 보장되는 수치는 아니다.

중요한 것은 작동 원리다.

이미 확인된 사실과 결정 관계를 다시 읽지 않고 그래프에서 필요한 부분만 질의할 수 있다면, 중복 탐색과 불필요한 컨텍스트 로딩을 줄일 수 있다.

에이전트 수가 많아질수록 “더 긴 컨텍스트”보다 현재 유효한 지식과 출처를 구분하는 구조가 더 중요해진다.

현재 단계에서 확인해야 할 것

DKG V10은 Working Memory, Shared Working Memory, Verifiable Memory, Context Graph, 파일 수집, SPARQL 질의, 에이전트 메시징, MCP 연결 등 주요 기능을 포함하고 있다.

동시에 빠르게 업데이트되는 단계이기 때문에 API, 기능, 호환성 조건은 바뀔 수 있다. 실제 업무 시스템에 적용할 때는 최신 릴리스와 네트워크 설정, 보안 요구사항을 다시 확인해야 한다.

DKG V10을 완성된 최종형으로 과장할 필요는 없다.

중요한 것은 이미 방향이 분명하다는 점이다.

• 기억은 특정 세션이나 플랫폼에 종속되지 않아야 한다

• 여러 에이전트가 함께 사용할 수 있어야 한다

• 중요한 지식에는 출처와 검증 이력이 남아야 한다

마무리

DKG V10은 에이전트에게 더 많은 내용을 기억시키는 기능이 아니다.

한 에이전트의 작업을 다음 에이전트의 출발점으로 만들고, 프로젝트의 컨텍스트를 세션 밖에 남기며, 중요한 지식에 출처와 책임을 붙이는 공유·검증 메모리 인프라다.

AI 에이전트가 실제 업무와 장기 프로젝트를 맡게 될수록 중요한 것은 기억의 양이 아니다.

그 기억이 공유되고, 재사용되고, 검증될 수 있는가.

DKG V10은 그 질문에 대한 OriginTrail의 답이다.