그래프 기반 에이전트 메모리: 공유 기억은 어떻게 안전해지는가
AI 에이전트가 하나일 때는 기억 문제가 단순해 보입니다. 대화 내용이나 작업 노트를 어딘가에 저장하면 됩니다. 하지만 터미널의 코딩 에이전트, 브라우저 챗봇, 백그라운드 작업 에이전트가 같은 프로젝트를 동시에 다루기 시작하면 문제가 달라집니다. 각자 따로 기억하면 맥락이 끊기고, 하나의 저장소에 모두 쓰게 하면 잘못된 정보가 곧바로 모두의 입력이 됩니다. 원문: https://newsletter.systemdesign.one/p/graph-based-agent-memory 핵심 핵심 정리 문제: 공유 폴더는 텍스트 더미가 되고, 벡터 데이터베이스는 관계를 모르며, 둘 다 여러 에이전트의 동시 쓰기와 잘못된 쓰기를 안전하게 다루기 어렵다. 해법 방향: 기억을 문서 묶음이 아니라 타입이 있는 그래프로 만들면, 에이전트가 고객 -> 티켓 -> 담당자 -> 커밋처럼 연결된 사실을 따라갈 수 있다. 쓰기 안전성: Omnigraph는 S3 같은 객체 저장소 위에서 불변 버전과 manifest를 사용해 부분 반영 없이 한 번에 공개되는 커밋을 만든다. 운영 규칙: 에이전트는 공유 진실인 main에 직접 쓰지 않고 브랜치에 변경을 만든 뒤, 승인과 병합을 거쳐야 한다. 검색 방식: 그래프 탐색, BM25 기반 키워드 검색, 벡터 검색을 한 데이터 위에서 함께 사용해 구조와 의미를 동시에 찾는다. 기존 방식이 깨지는 이유 가장 쉬운 방법은 공유 폴더입니다. Notion, Google Drive, Confluence, 위키에 모든 에이전트가 문서를 남기게 하는 방식입니다. 사람에게는 익숙하지만 에이전트에게는 불리합니다. 파일은 많아지는데, 그 안의 개념이 무엇이고 서로 어떻게 연결되는지 알기 어렵기 때문입니다. ...