LLM 에이전트를 위한 실질적인 장기 기억 (Long-Term Memory)

고객 지원 에이전트가 지난주에 재무팀에서 요금제를 다운그레이드했음에도 불구하고 고객에게 여전히 Enterprise 요금제라고 안내합니다. 코딩 코파일럿 (Coding Copilot)은 어제 학습한 저장소 (Repo) 컨벤션을 잊어버립니다. 개인 비서는 사용자의 옛날 집 주소를 기억하여 서비스 호출 예약에 사용합니다. 이것들은 모델의 문제가 아닙니다. 이것은 기억 (Memory)의 문제입니다. LLM 에이전트를 위한 장기 기억 (Long-term memory)은 당신의 시스템이 소프트웨어처럼 작동할지 아니면 단순한 데모처럼 작동할지를 결정하는 계층입니다.

대부분의 팀은 뻔한 스택으로 시작합니다: 임베딩 (Embeddings), 벡터 데이터베이스 (Vector database), top-k 검색 (Retrieval), 아마도 리랭커 (Reranker), 그리고 “다음 컨텍스트를 사용하세요”라고 말하는 프롬프트 (Prompt) 같은 것들 말입니다. 이는 문서 검색에는 효과적일 수 있습니다. 하지만 에이전트의 기억으로서는 대개 실패합니다.

이유는 간단합니다. 기억은 단순히 유사성 (Similarity)만이 아닙니다. 그것은 지속성 (Persistence), 검색 (Retrieval), 근거 제시 (Grounding), 그리고 시간 (Time)입니다.

LLM 에이전트를 위한 장기 기억에 실제로 필요한 것
만약 당신이 며칠 또는 몇 달 동안 상호작용하는 에이전트를 구축하고 있다면, 기억은 네 가지 작업을 잘 수행해야 합니다.

첫째, 현재의 컨텍스트 윈도우 (Context window)를 넘어 사실을 유지해야 합니다. 이 부분은 명확합니다. 더 어려운 부분은 무엇을 저장할 가치가 있는지 결정하는 것입니다. 가공되지 않은 채팅 기록은 노이즈가 많습니다. 유용한 기억은 모든 토큰 (Token)을 벡터 인덱스 (Vector index)에 쏟아붓는 것이 아니라, 추출 (Extraction)과 구조화 (Structure)가 필요합니다.

둘째, 현재 작업에 맞는 올바른 기억을 반환해야 합니다. 여기서 유사성만으로는 부족합니다. 만약 사용자가 “갱신 기간 동안 우리가 Acme에 무엇을 약속했었지?”라고 묻는다면, 시스템에는 의미론적으로 가까운 청크 (Chunks) 이상의 것이 필요합니다. 사실 (Facts), 엔티티 (Entities), 관계 (Relations), 그리고 이를 뒷받침하는 증거가 필요합니다.

셋째, 답변의 근거를 제시해야 합니다 (Grounding). 만약 에이전트가 고객의 계약 기간이 3월까지라고 말한다면, 당신은 그 정보가 어디에서 왔는지 알아야 합니다. 프로덕션 환경에서의 기억은 “모델이 기억한다”가 아닙니다. 그것은 “시스템이 자신의 작업 과정을 보여줄 수 있다”여야 합니다.

넷째, 시간을 이해해야 합니다. 이 지점이 대부분의 기억 구현이 무너지는 곳입니다. 사실은 변합니다. 요금제는 업그레이드되거나 다운그레이드됩니다. 관리자가 바뀝니다. 정책이 개정됩니다. 만약 당신의 기억 계층이 오직 최신 상태만을 저장한다면, 당신의 에이전트는 단순하지만 매우 중요한 질문에 답할 수 없습니다: “특정 날짜에 무엇이 사실이었는가?”

그 마지막 요구사항이 바로 검색 (Retrieval)과 기억 (Memory)의 차이입니다.

벡터 검색 (Vector search)만으로는 충분하지 않은 이유
벡터 검색은 한 가지를 잘합니다. 바로 쿼리 (Query)와 의미론적으로 유사해 보이는 텍스트를 찾는 것입니다. 이는 유용하지만, 기억 모델 (Memory model)은 아닙니다.

간단한 예를 들어보겠습니다. 사용자가 “내가 선호하는 알림 방식은 SMS입니다”라고 말합니다. 2주 후 사용자는 이를 이메일로 변경합니다. 만약 두 문장을 모두 임베딩 (Embedding)하고 유사도에 따라 검색한다면, 문구, 청킹 (Chunking), 점수 산정 방식에 따라 둘 중 하나를 가져오거나 둘 다 가져올 수 있습니다. 이제 당신의 에이전트는 상충하는 증거를 갖게 되며, 이를 해결할 내재적인 방법이 없습니다.

팀들은 보통 프롬프트 지시 사항 (Prompt instructions), 메타데이터 필터 (Metadata filters), 커스텀 랭킹 로직 (Custom ranking logic), 또는 수동으로 구축한 요약 작업 (Summarization jobs)으로 이를 임시방편으로 해결합니다. 그 결과는 취약합니다. 당신은 정작 필요했던 것은 메모리 레이어 (Memory layer)였음에도 불구하고, 메모리 스택 (Memory stack)을 구축하는 데 엔지니어링 시간을 허비하게 됩니다.

에이전트를 위한 진정한 장기 기억 시스템은 벡터를 저장하는 것 이상의 일을 해야 합니다. 소스 자료를 수집하고, 사실을 추출하며, 버전을 추적하고, 하이브리드 방식 (Hybrid methods)으로 검색하며, 관련성을 위해 리랭킹 (Rerank)을 수행하고, 인용 (Citations)과 함께 근거 있는 답변을 반환해야 합니다. 시간이 중요하다면, 시간적 의미론 (Temporal semantics) 또한 내장되어야 합니다.

벡터 스토어 (Vector store)가 아니라, 메모리 레이어 (Memory layer)가 필요합니다.

어려운 부분은 시간에 따른 사실의 진화 (Fact evolution)입니다
대부분의 에이전트 기억에 관한 논의는 영속성 (Persistence) 단계에서 멈춥니다. 프로덕션 환경에서 영속성은 기본 중의 기본입니다. 진짜 문제는 변화입니다.

사내 IT 어시스턴트를 상상해 보십시오. 1월에는 VPN 정책상 하드웨어 키가 필요합니다. 4월에는 정책이 변경되어 패스키 (Passkeys)를 허용합니다. 6월에 한 사용자가 “제 액세스 요청이 거부되었던 2월에는 요구 사항이 무엇이었나요?”라고 묻습니다. 만약 당신의 기억 시스템이 현재의 정책을 반환한다면, 검색 품질이 높더라도 답변은 틀린 것이 됩니다.

이것이 바로 이시점 기억 (Bi-temporal memory)이 중요한 이유입니다. 이는 사실 그 자체뿐만 아니라, 그 사실이 실제 세계에서 언제 유효했는지, 그리고 시스템이 그것을 언제 학습하거나 기록했는지를 모두 추적합니다. 이 둘은 서로 다른 타임라인 (Timelines)입니다.

그러한 구분은 감사 가능성 (Auditability), 고객 이력 (Customer history), 또는 운영상의 정확성 (Operational correctness)이 필요하기 전까지는 학술적인 이야기처럼 들릴 수 있습니다. 하지만 그 요구사항이 발생하는 순간, 이는 필수 사항이 됩니다. 이러한 구분 없이는 에이전트가 최신 값은 말해줄 수 있어도, 특정 시점에 무엇이 사실이었는지는 말해줄 수 없습니다.

고객 지원 (Support), 영업 (Sales), 컴플라이언스 (Compliance), 그리고 워크플로 (Workflow) 에이전트들에게 이것은 예외적인 사례가 아닙니다. 이는 매일 발생하는 트래픽입니다.

LLM 에이전트를 위한 장기 기억 (Long-term memory)의 아키텍처 선택지
팀들이 이 문제에 접근하는 방식에는 크게 두 가지가 있습니다.

한 가지 옵션은 메모리를 자체적으로 구축하는 것입니다. 이는 대개 벡터 데이터베이스 (Vector database), 커스텀 인제스션 (Custom ingestion), 청킹 규칙 (Chunking rules), 임베딩 파이프라인 (Embedding pipelines), 메타데이터 모델 (Metadata models), 리랭킹 (Reranking), 프롬프트 조립 (Prompt assembly), 그리고 엔티티 추출 (Extract entities), 사실 중복 제거 (Deduplicate facts), 기록 최신화 (Keep records up to date)를 위한 점점 늘어나는 작업 세트들을 의미합니다. 만약 시간적 회상 (Temporal recall)이 필요하다면, 버전 관리 (Versioning)와 타임스탬프 로직 (Timestamp logic)을 위한 레이어를 하나 더 추가해야 합니다. 메모리 인프라가 제품의 핵심이며 이를 무기한으로 직접 관리할 의사가 있다면 이 방식이 작동할 수 있습니다.

트레이드오프 (Trade-off)는 유지보수입니다. 모든 검색 실패 (Retrieval miss)는 여러분의 문제가 됩니다. 모든 스키마 변경 (Schema change)은 여러 시스템에 영향을 미칩니다. 모든 진실의 원천 (Source of truth)의 드리프트 (Drift)는 또 다른 디버깅 경로를 만들어냅니다. 그리고 메모리의 품질은 애플리케이션 레이어 (Application layer)에서 판단되기 때문에, 사용자는 이 모든 과정을 "에이전트가 틀렸다"라고 경험하게 됩니다.

두 번째 옵션은 인제스트 (Ingest)와 쿼리 (Query)라는 두 가지 작업 뒤로 스택을 추상화하는 전용 메모리 API를 사용하는 것입니다. 이는 실제 목표가 검색 인프라를 구축하는 것이 아니라 에이전트를 출시하는 것인 팀들에게 더 적합합니다. 여기서의 가치는 다이어그램 상의 구성 요소가 줄어드는 것이 아닙니다. 가치는 프로덕션 환경에서의 실패 모드 (Failure modes)가 줄어드는 것입니다.

이 지점이 바로 Nexusyn이 확고한 견해 (Opinionated)를 갖는 부분입니다. 단 두 개의 엔드포인트 (Endpoints). 그것이 API의 전부입니다. 소스 정보를 인제스트(Ingest)하십시오. 그리고 나중에 근거 있는 답변 (Grounded answers), 출처 인용 (Source citations), 그리고 시간적 정확성 (Temporal accuracy)과 함께 이를 쿼리(Query)하십시오. 핵심은 단순히 편의성을 위한 것이 아닙니다. 핵심은 개발자가 에이전트에게 안정적인 메모리를 부여하기 위해 청킹 (Chunking), 임베딩 (Embedding), 하이브리드 검색 (Hybrid retrieval), 리랭킹 (Reranking), 사실 추출 (Fact extraction), 그리고 버전 추적 (Version tracking)을 직접 조립할 필요가 없어야 한다는 것입니다.

프로덕션 환경에서의 훌륭한 메모리란 무엇인가
보통 세 가지 동작을 확인함으로써 메모리가 제대로 작동하는지 판단할 수 있습니다.

첫 번째는 연속성 (Continuity)입니다. 에이전트는 반복을 강요하지 않고도 안정적인 사용자 또는 시스템 사실 (Facts)을 계속해서 유지해야 합니다. 선호도, 과거 행동, 진행 중인 스레드(Open threads), 그리고 지속적인 제약 조건 (Durable constraints)은 세션이 바뀌어도 유지되어야 합니다.

두 번째는 정밀도 (Precision)입니다. 사실 관계를 묻는 질문을 받았을 때, 에이전트는 출처 근거 (Source evidence)와 연결된 뒷받침 가능한 답변을 반환해야 합니다. 만약 상충하는 기록이 있다면, 추측하는 것이 아니라 최신성 (Recency), 유효 기간 (Validity period), 또는 명시적인 불확실성 (Explicit uncertainty)을 통해 이를 해결해야 합니다.

세 번째는 시간적 정확성 (Temporal correctness)입니다. 질문이 과거의 일에 관한 것이라면 답변은 역사를 반영해야 합니다. 질문이 현재에 관한 것이라면 답변은 최신의 유효한 상태 (Latest valid state)를 반영해야 합니다. 시간 개념을 이해하지 못한다면 하나의 검색 경로 (Retrieval path)만으로는 이 두 가지를 모두 안전하게 처리할 수 없습니다.

이것이 바로 메모리 평가가 top-k 검색 지표 (Top-k retrieval metrics)를 넘어서야 하는 이유이기도 합니다. 메모리 레이어 (Memory layer)는 근거 기반 답변의 정확도 (Grounded answer accuracy), 인용 품질 (Citation quality), 충돌 처리 (Conflict handling), 그리고 변화하는 사실 하에서의 역사적 회상 (Historical recall)을 기준으로 측정되어야 합니다. 최종 답변이 여전히 틀렸다면, "관련된 청크 (Chunk)가 프롬프트 어딘가에 있었다"는 것은 유용한 성공 기준이 될 수 없습니다.

흔한 구현 실수들
가장 흔한 실수는 모든 대화 턴 (Conversation turn)을 메모리로 취급하는 것입니다. 이는 노이즈를 생성하고, 저장 비용을 증가시키며, 검색 성능을 저하시킵니다. 메모리는 선택적이어야 합니다.

다음 실수는 출처 (Provenance) 없이 사실을 저장하는 것입니다. 메모리를 소스 텍스트 (Source text)로 추적할 수 없다면, 잘못된 답변을 디버깅하거나 사용자와의 신뢰를 구축할 수 없습니다.

또 다른 흔한 실패 사례는 업데이트 내용을 단일 최신 기록으로 평탄화 (Flattening)하는 것입니다. 이는 현재 상태 쿼리 (Current-state queries)를 쉽게 만들지만, 역사적 쿼리 (Historical queries)를 망가뜨립니다. 일단 이전 값이 덮어쓰여지면, 그것은 사라집니다.

마지막 실수는 충돌 해결 (Conflict resolution)을 프롬프트로 밀어넣는 것입니다. 프롬프트는 데이터 모델 (Data models)이 아닙니다. 만약 시스템이 버전 관리 (Versioning)나 유효성 로직 (Validity logic) 없이 모순된 사실을 저장한다면, 모델은 즉흥적으로 대처할 수밖에 없게 됩니다.

단순한 메모리가 충분할 때와 그렇지 않을 때
애플리케이션에 따라 다릅니다.

몇 가지 안정적인 사용자 선호도(User preferences)만 기억하면 되는 경량 어시스턴트(Lightweight assistant)를 구축하는 경우라면, 기본적인 저장소(Store)와 검색(Retrieval)만으로도 충분할 수 있습니다. 틀렸을 때의 비용이 낮다면 가끔 발생하는 모호함(Fuzziness)은 감수할 수 있습니다.

하지만 지원 에이전트(Support agents), 내부 운영을 위한 코파일럿(Copilots), 엔터프라이즈 어시스턴트(Enterprise assistants), 또는 변화하는 비즈니스 데이터에 관한 질문에 답하는 모든 에이전트를 구축하는 경우라면, 단순한 메모리로는 버틸 수 없습니다. 근거가 확실한 검색(Grounded retrieval)이 필요하며, 아마도 시간적 회상(Temporal recall) 기능도 필요할 것입니다. 사용자가 "무엇이 바뀌었나요?" 또는 "그때는 무엇이 사실이었나요?"라고 질문하는 순간, 아키텍처 선택의 방향은 명확해집니다.

유용한 규칙은 다음과 같습니다. 만약 당신의 에이전트가 시간이 지남에 따라 변하는 정보와 상호작용하고, 사용자가 답변이 정확히 맞는지 여부를 중요하게 생각한다면, 메모리는 기능(Feature)이 아니라 인프라(Infrastructure)입니다.

잊어버리는 에이전트를 만드는 것을 멈추십시오. 더 중요한 것은, 잘못된 것을 기억하는 에이전트를 만드는 것을 멈추라는 것입니다. 첫 번째 문제는 짜증을 유발할 뿐이지만, 두 번째 문제는 신뢰를 깨뜨립니다. 그리고 신뢰는 다시 구축하는 데 가장 오랜 시간이 걸리는 부분입니다.