AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

에이전틱 메모리 팁 – AI 에이전트 메모리 레이어를 설계하는 실전 구조

agentic-memory는 에이전트를 단순 챗봇에서 장기 작업 파트너로 바꾸는 핵심 인프라다. 이 글은 메모리를 “대화 기록 저장”이 아니라 연속성, 작업 컨텍스트, 학습을 동시에 담당하는 별도 시스템으로 보고, 어떤 메모리를 어디에 저장하고 언제 검색·갱신·삭제할지 실무 관점에서 정리한다.

왜 메모리 레이어가 필요한가

LLM API 호출은 기본적으로 무상태(stateless)다. 새 대화가 시작되면 모델은 이전 세션에서 어떤 결정을 내렸는지, 어떤 도구 호출이 실패했는지, 사용자가 어떤 스타일을 선호하는지 알지 못한다.

단순 QA에서는 큰 문제가 아닐 수 있다. 그러나 에이전트가 코드를 고치고, 장기 프로젝트를 관리하고, 여러 도구를 호출하며, 사용자에게 맞춰 점점 더 나은 전략을 선택해야 한다면 이 “기억상실”은 바로 제품 한계가 된다.

좋은 메모리 시스템은 세 가지 일을 한다.

역할질문예시
연속성이 사용자는 누구이고 무엇을 선호하는가?선호 언어, 프로젝트 규칙, 반복 의사결정
컨텍스트지금 작업에서 무엇이 방금 일어났는가?도구 호출 결과, 실패한 명령, 현재 계획
학습이전에 무엇이 잘 됐고 무엇이 실패했는가?성공한 접근법, 비용이 컸던 전략, 품질 점수

네 가지 메모리 유형

1. 인컨텍스트 메모리

인컨텍스트 메모리(in-context memory)는 현재 컨텍스트 창 안에 있는 모든 정보다. 시스템 프롬프트, 최근 대화, 도구 호출 결과, 검색된 문서, 스크래치패드가 여기에 들어간다.

장점은 명확하다. 모델이 한 번의 추론에서 바로 접근하므로 검색 누락이 없다. 단점도 명확하다. 토큰 비용과 지연 시간이 커지고, 컨텍스트 창을 넘기면 오래된 정보가 잘린다.

따라서 긴 세션에서는 다음 전략이 필요하다.

  • 오래된 대화를 요약해 짧은 상태로 치환한다.
  • 결정, 에러, 도구 결과처럼 재사용 가치가 높은 턴만 남긴다.
  • 장기 보관이 필요한 사실은 외부 메모리로 추출한다.

2. 외부 메모리

외부 메모리(external memory)는 모델 밖에 영속적으로 저장되는 데이터다. PostgreSQL, Redis, SQLite, 파일, 벡터 데이터베이스, 지식 그래프가 모두 후보가 된다.

외부 메모리는 크게 두 방식으로 나눌 수 있다.

방식장점적합한 데이터
구조적 저장소키·ID·SQL로 정확 조회 가능사용자 프로필, 설정, 권한, 상태
벡터 저장소의미 기반 유사도 검색 가능회의 메모, 작업 에피소드, 비정형 노트

여기서 병목은 저장보다 검색이다. 메모리를 저장해도 필요한 순간에 올바른 기억을 불러오지 못하면 에이전트 입장에서는 존재하지 않는 것과 같다. 실무에서는 “무엇을 저장할까”보다 “어떤 쿼리로 어떤 기억을 검색하게 할까”가 더 큰 설계 문제다.

3. 에피소딕 메모리

에피소딕 메모리(episodic memory)는 과거 작업의 사건과 결과를 저장한다. 단순 사실이 아니라 “어떤 일을 어떤 방식으로 했고 결과가 어땠는가”를 기록한다.

예시는 다음과 같다.

{
  "task": "50페이지 PDF를 3개 핵심 bullet로 요약",
  "approach": "2,000토큰 단위 순차 청킹",
  "outcome": "success",
  "duration_ms": 4820,
  "token_cost": 12400,
  "quality_score": 0.91,
  "notes": "계층적 청킹을 쓰면 더 빠를 수 있음"
}

새 작업이 들어오면 비슷한 과거 에피소드를 검색하고, 그때의 접근법과 결과를 참고해 전략을 고른다. 이는 수작업 few-shot 예시 대신 에이전트 자신의 작업 이력에서 few-shot을 구성하는 방식에 가깝다.

4. 파라메트릭 메모리

파라메트릭 메모리(parametric memory)는 모델 가중치 안에 들어 있는 지식이다. 별도 검색이 필요 없고 항상 사용할 수 있지만, 학습 시점 이후 정보는 모르며 런타임에 직접 업데이트할 수 없다. 내부 상태를 검사하기 어렵고, 빈틈은 그럴듯한 환각으로 채워질 수 있다.

따라서 시간 민감 정보, 사내 지식, 사용자별 선호, 프로젝트별 규칙은 파라메트릭 메모리에 맡기면 안 된다. 이런 정보는 외부 메모리나 인컨텍스트 메모리로 명시적으로 관리해야 한다.

에이전트 루프에서 메모리는 어디에 들어가나

메모리 작업은 LLM 호출의 앞뒤에 배치된다.

  1. 사용자 요청을 받는다.
  2. 요청과 현재 상태를 바탕으로 관련 메모리를 검색한다.
  3. 검색된 메모리를 시스템 프롬프트나 컨텍스트 블록에 주입한다.
  4. LLM이 응답하거나 도구 호출 계획을 만든다.
  5. 실행 결과, 사용자 피드백, 중요한 결정만 선별해 메모리에 쓴다.
  6. 에피소드 로그를 남겨 다음 유사 작업의 전략 선택에 활용한다.

핵심은 모델 자체가 상태를 갖는 것이 아니라, 검색과 기록 레이어가 모델 앞뒤에서 상태가 있는 것처럼 보이게 만든다는 점이다.

최소 구현 구조

로컬 개발에서는 ChromaDB 같은 벡터 저장소와 임베딩 API만으로도 작은 메모리 레이어를 만들 수 있다.

pip install chromadb openai anthropic python-dotenv

기본 저장소는 세 가지 책임만 가지면 된다.

class MemoryStore:
    def remember(self, content: str, memory_type: str, metadata: dict) -> str:
        """텍스트를 임베딩하고 메타데이터와 함께 저장한다."""

    def recall(self, query: str, k: int = 5, memory_type: str | None = None) -> list[dict]:
        """쿼리를 임베딩해 관련 메모리 Top-K를 검색한다."""

    def forget(self, memory_id: str) -> None:
        """오래됐거나 잘못된 메모리를 삭제한다."""

그 위에 에피소드 로거를 얹는다.

@dataclass
class Episode:
    task: str
    approach: str
    outcome: str
    duration_ms: int
    token_cost: int
    quality_score: float
    notes: str = ""

에이전트 실행 시에는 일반 메모리와 유사 에피소드를 함께 검색해 컨텍스트를 만든다.

memories = memory.recall(user_message, k=4)
episodes = episodes.recall_similar(user_message, k=2)

이 구조는 단순하지만 중요한 패턴을 포함한다. 사실 기억과 작업 경험을 같은 저장소에 넣더라도 memory_type, outcome, quality_score, timestamp 같은 메타데이터를 붙이면 검색 필터링과 품질 관리가 가능해진다.

메모리 관리는 저장보다 중요하다

메모리는 많이 쌓일수록 좋아지는 데이터베이스가 아니다. 중복, 오래된 사실, 낮은 품질의 기록이 늘어나면 검색 결과가 흐려지고 에이전트가 서로 모순되는 정보를 참고한다.

프로덕션에서는 최소 세 가지 관리 전략이 필요하다.

시간 감쇠

오래된 메모리일수록 점수를 낮춘다. 관련도만 보지 말고 중요도와 최신성을 함께 계산해야 한다.

score = relevance * 0.4 + importance * 0.3 + recency * 0.3

저장 시 중요도 평가

모든 대화를 저장하지 않는다. 인사, 잡담, 중간 추론, 실패한 임시 시도는 대부분 장기 메모리에 부적합하다. 저장 시점에 LLM이나 규칙 기반 필터로 “나중에 다시 쓸 만한 정보인가”를 평가한다.

주기적 병합

비슷한 메모리가 여러 개 쌓이면 하나의 대표 요약으로 합친다. 예를 들어 사용자가 같은 코딩 스타일 선호를 여러 번 말했다면 원문 전체를 계속 저장하기보다 최신 대표 기억 하나로 통합하는 편이 낫다.

설계 체크리스트

  • 사용자 선호, 프로젝트 규칙, 작업 결과를 같은 방식으로 저장하지 않는다.
  • 검색 실패가 곧 기억 실패이므로 쿼리 생성과 메타데이터 필터를 함께 설계한다.
  • 원시 대화 전체 저장은 기본값으로 삼지 않는다.
  • 잘못된 기억을 삭제하거나 덮어쓸 수 있는 경로를 제공한다.
  • 에피소드에는 결과와 비용을 함께 남겨 다음 전략 선택에 쓰게 한다.
  • 민감 정보는 저장 전 분류하고, 삭제 요청과 감사 로그를 지원한다.

누구에게 유용한가

이 구조는 agentmemory, mem0, mempalace, supermemory 같은 메모리 도구를 평가하거나 직접 에이전트 메모리 레이어를 만들려는 개발자에게 유용하다. 특히 “벡터 DB를 붙이면 메모리가 생긴다”는 수준을 넘어, 무엇을 기억하고 무엇을 잊게 할지까지 제품 요구사항으로 다루는 팀에 필요하다.

관련 문서

참고 자료



AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)