에이전트 메모리와 컨텍스트 그래프, 회사에서 쓸 수 있을까 고민해본 후기

최근 회사에서 AI 에이전트를 어떻게 써볼 수 있을지 고민하면서, RAG나 tool calling만으로는 조금 부족하다는 생각을 자주 했다. 답을 한 번 잘하는 것도 중요하지만, 회사 업무에서는 “지난번에 왜 그렇게 판단했는지”, “어떤 고객사 맥락이 있었는지”, “누가 어떤 권한으로 그 정보를 봐도 되는지”가 같이 따라오기 때문이다.

그러다 Context Graph와 Neo4j Agent Memory를 설명한 영상을 보게 됐다. 바로 도입하겠다는 이야기는 아니다. 아직은 회사에서 쓸 수 있는 방법을 고민하는 단계이고, 다양한 예제를 찾아보는 중이다. 다만 컨텍스트 그래프라는 말이 왜 AI 에이전트 메모리와 같이 나오는지는 한 번 정리해둘 만했다.

요약

컨텍스트 그래프는 단순 지식 저장소라기보다, 현재 사용자·업무·상황에 맞는 맥락을 골라내기 위한 그래프 구조로 이해했다.
에이전트 메모리는 단기 메모리, 장기 메모리, 추론 메모리로 나눠 생각하면 회사 업무에 적용할 때 더 현실적이다.
사내 기술 지원, 고객사 대응, 장애 대응, 온보딩처럼 “지난 판단의 이유”가 중요한 업무에서 쓸 가능성이 있어 보인다.
다만 바로 도입하기 전에는 기억 범위, 권한, 삭제, 출처, 비용, 운영 복잡도를 먼저 봐야 한다.

컨텍스트 그래프라는 말을 왜 다시 보게 됐나
그래프, 지식 그래프, 컨텍스트 그래프의 차이
에이전트 메모리는 무엇을 기억해야 할까
회사에서 쓴다면 어디에 맞을까
최근 블로그와 커뮤니티에서 보이는 실제 고민
직접 고민하면서 느낀 장점
바로 도입하기 전에 조심해야 할 점
내가 더 찾아보고 싶은 예제들
결론
참고 자료

컨텍스트 그래프라는 말을 왜 다시 보게 됐나

요즘 AI 에이전트 이야기를 하다 보면 기억(memory)이라는 말이 자주 나온다. 처음에는 대화 내용을 오래 저장하는 정도로 생각하기 쉽다. 그런데 회사 업무에 대입하면 단순 저장만으로는 부족하다.

예를 들어 고객사 장애 대응 기록을 AI가 기억한다고 해보자. 단순히 “A 고객사는 지난달 장애가 있었다”만 기억하면 별 도움이 안 된다. 어떤 시스템이었는지, 누가 승인했는지, 어떤 임시 조치를 했는지, 나중에 왜 정식 패치를 미뤘는지까지 연결돼야 한다. 그리고 그 정보 중 일부는 특정 팀만 봐야 할 수도 있다.

그래서 컨텍스트 그래프가 흥미로웠다. “모든 정보를 LLM에 다 넣자”가 아니라, 현재 질문과 업무 상황에 맞는 일부 맥락을 골라내는 구조로 볼 수 있기 때문이다.

그래프, 지식 그래프, 컨텍스트 그래프의 차이

영상에서 정리한 흐름을 내 식으로 이해하면 이렇게 나뉜다.

구분	내가 이해한 의미	AI 에이전트에서의 역할
그래프	노드와 관계로 정보를 표현하는 구조	사람, 시스템, 이슈, 문서의 연결을 표현
지식 그래프	개념과 사실, 관계를 구조화한 지식 저장소	사내 지식, 제품, 정책, 고객사 정보를 연결
컨텍스트 그래프	현재 업무 상황에 맞는 맥락을 선택하기 위한 그래프	LLM에 지금 필요한 subgraph만 전달

이 차이가 중요하다. 회사에서 AI를 쓸 때는 정보가 많다는 것보다, 지금 질문에 맞는 정보를 고르는 것이 더 어렵다. 컨텍스트 그래프는 이 문제를 그래프 구조로 풀어보려는 접근으로 보인다.

에이전트 메모리는 무엇을 기억해야 할까

Neo4j Agent Memory 쪽 자료를 보면 메모리를 크게 세 층으로 나눠볼 수 있다. 이 구분이 마음에 들었다. 회사 업무에서 “AI가 기억한다”는 말을 너무 뭉뚱그리지 않게 해주기 때문이다.

1. 단기 메모리

현재 대화나 세션 안에서 필요한 기억이다. 메시지 순서, 현재 작업, 방금 선택한 옵션, 임시 상태 같은 것들이다. 챗봇이나 업무 에이전트가 “방금 말한 그 서버”를 알아듣는 데 필요하다.

2. 장기 메모리

사용자 선호, 반복되는 사실, 고객사 특성, 자주 등장하는 시스템 관계처럼 세션을 넘어 유지할 정보다. 다만 회사에서는 이 부분이 가장 조심스럽다. 무엇을 오래 기억할지, 누가 삭제할 수 있는지, 권한이 바뀌면 어떻게 할지까지 정해야 한다.

3. 추론 메모리

개인적으로 가장 흥미로웠던 부분이다. 단순 결론이 아니라, 어떤 도구를 호출했고, 어떤 경로로 판단했고, 어떤 근거 때문에 답을 냈는지를 남기는 기억이다. 장애 대응이나 고객사 이슈에서는 “결론”보다 “왜 그렇게 판단했는지”가 더 중요할 때가 많다.

회사에서 쓴다면 어디에 맞을까

아직 도입을 정한 것은 아니지만, 회사에서 쓸 수 있는 장면을 상상해보면 몇 가지가 떠오른다.

사내 기술 지원 에이전트: 과거 문의, 시스템 구성, 담당 팀, 해결 기록을 연결해 비슷한 이슈를 더 빨리 찾는다.
고객사 대응 기록 메모리: 고객사별 환경, 이전 요청, 예외 처리 이력을 연결해 다음 응대에서 맥락을 잃지 않는다.
장애 대응과 사후 분석: 증상, 로그, 조치, 재발 방지 항목을 그래프로 연결해 다음 장애 때 근거를 찾는다.
사내 지식 관리와 온보딩: 문서, 코드, 정책, 담당자를 연결해 신입이나 전환 배치 인력이 빠르게 맥락을 잡는다.
개인화된 업무 비서: 개인의 반복 업무와 선호를 기억하되, 회사 정책에 맞게 기억 범위를 제한한다.

이런 장면들은 RAG만으로도 일부 가능하다. 하지만 “관계”와 “판단 과정”이 중요해질수록 그래프 기반 메모리를 같이 보는 이유가 생긴다.

최근 블로그와 커뮤니티에서 보이는 실제 고민

이 글을 다시 보강하면서 공식 문서만 보지 않고, 최근 블로그와 커뮤니티성 자료도 같이 확인했다. 흐름은 꽤 분명했다. 사람들은 단순히 “AI가 오래 기억하면 좋겠다”가 아니라, 변하는 사실을 어떻게 갱신할지, 사용자별 기억을 어떻게 격리할지, 검색이 비었을 때 어떻게 알릴지, 로컬 LLM이나 다른 API와 어떻게 붙일지를 고민하고 있었다.

Graphiti / PyTorch Korea 쪽 흐름: 시간에 따라 변하는 지식을 다루는 temporal context graph 관점이 반복해서 보인다. 기존 RAG처럼 문서를 한 번 색인하고 끝내는 것이 아니라, 대화·비즈니스 데이터·문서에서 엔티티와 관계를 계속 갱신하고, 오래된 사실은 더 이상 현재 사실처럼 쓰지 않도록 관리하는 방향이다.
Mem0 쪽 흐름: 그래프를 직접 설계하기보다, AI 애플리케이션이 사용자 선호와 반복되는 맥락을 지속적으로 기억하게 해주는 메모리 레이어로 접근한다. 국내 블로그에서도 “LLM의 기억 상실” 문제를 줄이는 방식으로 Mem0를 소개하고, 공식 문서도 사용자·세션·에이전트 기억을 나눠 설명한다.
GitHub 이슈에서 보이는 현실 문제: Neo4j Agent Memory에는 사용자 식별자를 빼면 다른 사용자의 장기 기억이 조회될 수 있다는 격리 이슈와 관계 추출 품질 문제가 보인다. Graphiti에는 큰 콘텐츠 입력 시 추출 과정이 느린 문제, 로컬 LLM이나 커스텀 API 엔드포인트 연동 문제가 올라와 있다. Cognee에는 인지 처리 지연 때문에 recall이 비어 보이는 상황을 어떻게 드러낼지에 대한 논의가 있다.

그래서 이 주제는 “멋진 그래프 DB를 붙이면 끝”이 아니다. 실제 도입 관점에서는 기억 격리, 엔티티 병합 품질, 느린 추출, 빈 recall, 로컬 모델 연동, 감사 가능한 출처가 더 큰 체크포인트다.

블로그 흐름: Graphiti, Mem0 같은 도구가 RAG 이후의 memory/context 문제를 해결하려는 흐름으로 소개된다.
커뮤니티 흐름: PyTorch Korea 같은 개발자 커뮤니티에서도 temporal knowledge graph, AI agent memory가 공유된다.
GitHub 이슈 흐름: 사용자별 격리, 추출 속도, 관계 추출 품질, 빈 recall, 커스텀 LLM 연동 같은 운영 문제가 보인다.
내 결론: 회사에서 보려면 기능 데모보다 “기억을 안전하게 관리할 수 있는가”를 먼저 봐야 한다.

이 부분을 보고 나니, 회사에서 context graph를 검토할 때 첫 PoC도 바뀌어야 한다는 생각이 들었다. 멋진 질의 데모보다, 서로 다른 사용자 두 명의 기억이 섞이지 않는지, 잘못 추출된 엔티티를 고칠 수 있는지, 오래된 사실을 폐기할 수 있는지, 답변 근거를 다시 확인할 수 있는지를 먼저 봐야 한다.

직접 고민하면서 느낀 장점

내가 느낀 장점은 세 가지다.

맥락을 덜 반복해도 된다. 회사 업무는 같은 설명을 여러 번 반복하는 일이 많다. 에이전트가 필요한 맥락을 찾을 수 있다면 이 비용이 줄어든다.
출처와 관계를 같이 볼 수 있다. 벡터 검색은 비슷한 문서를 찾는 데 강하지만, 누가 어떤 시스템과 연결되는지, 어떤 의사결정이 어떤 문서에서 나왔는지는 그래프가 더 자연스럽다.
추론 과정의 감사가 쉬워질 수 있다. AI가 어떤 도구를 호출했고 어떤 근거를 봤는지 남기면, 나중에 잘못된 판단을 추적하기가 쉬워진다.

바로 도입하기 전에 조심해야 할 점

흥미롭다고 바로 회사에 넣기에는 조심할 부분이 많다.

무엇을 기억할지 정해야 한다. 모든 대화를 저장하면 편해 보이지만, 실제로는 보안·개인정보·노이즈 문제가 커진다.
권한 모델이 먼저다. 그래프가 강력해질수록 원래 분리돼 있던 정보가 연결될 수 있다. 누가 어떤 노드를 볼 수 있는지 정교해야 한다.
엔티티 추출 품질이 중요하다. 고객사명, 시스템명, 담당자, 이슈명을 잘못 합치거나 나누면 기억이 오히려 독이 된다.
삭제와 감사가 필요하다. 오래 기억하는 시스템일수록 삭제 요청, 보존 기간, 변경 이력을 설계해야 한다.
운영 비용이 생긴다. 그래프 DB, 임베딩, LLM 호출, 동기화, 평가까지 운영해야 하므로 단순 챗봇보다 복잡하다.

내 기준으로는 PoC부터 작게 시작하는 게 맞다. 고객 데이터 전체를 넣기보다 공개 문서나 내부 기술 문서 일부, 또는 장애 회고 샘플처럼 위험이 낮은 범위에서 먼저 보는 편이 안전하다.

내가 더 찾아보고 싶은 예제들

이번에 같이 찾아본 예제들은 방향을 잡는 데 도움이 됐다.

Neo4j Agent Memory: conversation, entity, fact, reasoning trace를 그래프 메모리로 다루는 예제다.
Create Context Graph: 특정 도메인에 맞는 context graph 앱을 만들기 위한 출발점으로 보인다.
Graphiti / Zep: 시간이 지나며 바뀌는 사실과 관계를 다루는 temporal context graph 접근이 흥미롭다.
Mem0: 직접 그래프를 운영하기보다 관리형 메모리 계층을 쓰는 방향으로 볼 수 있다.
LangGraph Memory: thread 단기 메모리와 namespace 장기 메모리 구분이 실무 설계에 참고된다.
Cognee: 벡터, 관계형, 그래프 저장소를 함께 쓰는 메모리/검색 구조로 볼 수 있다.

아직은 “이걸 쓰자”가 아니라 “이런 선택지가 있구나”에 가깝다. 하지만 회사에서 AI 에이전트를 진지하게 보려면, 메모리와 컨텍스트 관리는 언젠가 피하기 어려운 주제가 될 것 같다.

결론

컨텍스트 그래프와 에이전트 메모리는 단순히 AI가 대화를 오래 기억하게 만드는 기술이 아니다. 회사에서 AI를 쓰려면, 어떤 정보를 기억하고, 어떤 관계를 유지하고, 어떤 근거로 판단했는지 남기는 구조가 필요하다.

나는 아직 이 방식을 회사에 바로 도입하겠다고 정한 것은 아니다. 다만 RAG와 tool calling 다음에 고민해야 할 주제로는 꽤 설득력이 있어 보인다. 특히 고객사 대응, 장애 분석, 사내 지식 관리처럼 맥락과 출처가 중요한 업무에서는 컨텍스트 그래프를 더 찾아볼 이유가 충분하다.