에이전트 메모리에는 데이터베이스만 한 게 없다
Nothing beats a database for agent memory
핵심 요약
에이전트 메모리 관리 방식으로 마크다운 파일보다 쿼리 가능한 데이터베이스가 장기적으로 훨씬 효율적이라는 주장입니다.
- 데이터베이스 활용 — 에이전트가 필요한 정보만 쿼리하여 컨텍스트 오염을 방지함
- 메모리 확장성 — 티켓 시스템처럼 구조화된 데이터는 에이전트가 관리하기에 최적임
- 마크다운의 한계 — 파일 전체를 읽어야 하는 방식은 토큰 낭비와 컨텍스트 오염을 유발함
- RAG와 임베딩 — 로컬에서 벡터 검색을 통해 시맨틱 매칭을 수행하는 방식이 대안으로 제시됨
에이전트 메모리를 구현하는 방식은 진짜 너무 많지. 난 보통 단순한 게 최고라고 생각하는데, 에이전트한테 Jira나 Linear 같은 티켓팅 시스템, 아니면 SQLite처럼 로컬에서 관리할 수 있는 대중적인 데이터베이스를 쓰게 하는 게 마크다운 파일 뭉치나 레포지토리 같은 거 쓰는 것보다 장기적으로 훨씬 나은 결과를 가져다줄 거야.
조직들이 그동안 왜 그렇게 귀찮은 툴들을 써왔겠냐? 제대로만 활용하면 조직 전체의 정보와 소통을 확장하는 데 그만한 게 없거든.
에이전트한테 메모리를 심어주고 싶다면, 애초에 쿼리가 가능하고 문제 해결에 필요한 맥락을 끌어오기 좋게 설계된 걸 추천해. 에이전트는 Jira 같은 툴을 활용해서 티켓을 생성하거나 찾는 일을 인간보다 훨씬 잘할 수 있거든.
에이전트는 완벽한 중간 관리자야.
난 내 에이전트한테 로컬 SQLite를 쓰게 하고, 지가 알아서 티켓이랑 컬럼을 관리하게 시켜. 그래야 내가 새로운 기능이나 버그를 던져줬을 때 뭘 어떻게 쿼리해야 할지 알거든. 이렇게 하면 맥락이 계속 쌓여. 버그나 기능 하나하나가 티켓으로 남으니까, 내가 티켓을 해결할수록 메모리의 가치가 자연스럽게 올라가는 거지.
Linear 같은 툴을 쓰든, 아니면 칸반이나 테이블 뷰를 위해 직접 뭘 만들든, 네가 주도적으로 이 방식을 활용해 보면 딱 맞을 거야.
