Deep Dive · 중급

AI 에이전트 메모리 설계: 대화 기억·업무 상태·장기 기억을 어떻게 분리할까?

대화 이력, 실행 중인 업무 상태, 사용자 장기 기억, 원본 업무 데이터를 별도 저장소와 수명 주기로 분리하고 장기 기억은 출처·동의·만료·수정 가능성을 갖춘 검증된 사실만 저장해야 한다.

30초 답변

AI 에이전트의 메모리는 하나의 대화 로그가 아니라 현재 컨텍스트, 세션 이력, 업무 상태, 장기 기억, 원본 업무 데이터로 분리해야 한다. 모델에는 현재 판단에 필요한 최소 정보만 넣고, 결재 단계나 도구 실행 결과는 구조화된 업무 상태로 저장하며, 사용자 선호나 반복 업무 사실은 출처·동의·유효기간·수정 가능성을 갖춘 경우에만 장기 기억으로 승격해야 한다. 원본 고객·계약·재고 정보는 기억에 복사하지 말고 권한을 적용해 원천 시스템에서 다시 조회한다.

이 글의 핵심

  • “지난 대화를 모두 다시 넣기”는 메모리 전략이 아니라 비용과 혼선을 키울 수 있는 기본 구현이다.
  • 대화 이력과 업무 상태는 다르다. 결제가 승인 대기 중이라는 사실은 요약문이 아니라 상태 머신에 저장해야 한다.
  • 장기 기억은 모델이 자유롭게 쓰는 메모장이 아니다. 후보 추출, 검증, 민감정보 필터, 범위·만료 설정을 거쳐야 한다.
  • 검색된 기억에는 소유자, 출처, 생성 시점, 신뢰도와 테넌트 경계가 따라야 한다.
  • 사용자는 무엇이 기억됐는지 보고, 고치고, 삭제하고, 이번 대화에서 제외할 수 있어야 한다.

먼저 ‘메모리’라는 한 단어를 다섯 저장소로 나눈다

OpenAI Agents SDK의 Sessions 문서는 세션을 대화 이력을 유지하는 계층으로 설명하고, Agent memory 문서는 과거 실행의 교훈을 다음 실행에 사용하는 기억을 대화 세션과 별개로 구분한다. 제품과 프레임워크가 달라도 이 분리는 유용하다.

계층저장하는 것일반적인 수명모델에 넣는 방식원칙
현재 컨텍스트지금 질문, 필요한 지침·근거·도구 결과한 번의 모델 호출직접 입력작고 관련성 높게
세션 이력사용자와 시스템의 최근 대화대화 또는 티켓 기간최근 항목·요약대화 연속성용
업무 상태단계, 완료 항목, 승인 대기, 실행 결과 ID업무 완료·보존 기간까지필요한 필드만 렌더링구조화·멱등·재개 가능
장기 기억확인된 선호, 반복 규칙, 지속되는 사용자 사실동의·정책에 따른 기간관련 기억 검색출처·범위·만료·수정 가능
원본 업무 데이터고객, 계약, 재고, 규정 원문원천 시스템 정책권한 있는 Tool/RAG 조회기억에 복제하지 않음

이 구분을 하지 않으면 “대화에서 사용자가 배송지를 바꿨다”는 문장이 곧바로 고객 마스터를 바꾸거나, 반대로 실제로 저장해야 할 승인 상태가 대화 요약에서 사라질 수 있다.

1. 현재 컨텍스트: 모델의 작업대

현재 컨텍스트는 모델이 지금 판단할 수 있도록 전달된 토큰 전체다. 시스템 지침, 사용자 요청, 도구 정의, 검색 문서, 대화 일부와 도구 결과가 포함된다. 컨텍스트 창이 커도 모두 넣는 것이 최선은 아니다.

Anthropic의 컨텍스트 엔지니어링 가이드는 컨텍스트를 유한한 자원으로 보고, 원하는 행동을 만들 가능성이 높은 고신호 정보의 최소 집합을 구성할 것을 권한다. 긴 작업에는 압축, 구조화된 노트, 하위 에이전트 같은 방법을 제시하지만, 각 방법에는 정보 손실과 조정 비용이 있다.

실무 조립 순서는 다음처럼 명시할 수 있다.

  1. 변하지 않는 시스템 정책과 현재 사용자 권한
  2. 현재 업무 목표와 완료 조건
  3. 구조화된 업무 상태의 핵심 필드
  4. 최근 대화 중 현재 요청에 필요한 부분
  5. 권한 검사를 통과한 장기 기억
  6. 이번 단계에서 검색한 원문과 도구 결과

각 블록에 출처와 시점을 붙이고, 서로 충돌하면 우선순위를 정한다. 최신 원천 데이터가 과거 기억보다 우선하고, 조직 정책이 사용자 선호보다 우선해야 한다.

2. 세션 이력: 대화를 이어가기 위한 기억

세션 이력은 “아까 말한 문서”, “두 번째 안으로 진행해줘” 같은 후속 요청을 이해하게 한다. 모든 메시지를 무기한 재전송하면 입력 비용, 지연, 관련 없는 지시의 재등장, 민감정보 노출 범위가 함께 커진다.

세션 정책에는 다음이 필요하다.

  • 세션 키를 사용자만이 아니라 테넌트·업무·채널과 결합한다.
  • 최근 N개 항목 또는 토큰 한도를 두되, 숫자는 실제 대화 평가로 정한다.
  • 오래된 대화는 요약하되 결정, 미해결 질문, 사용자가 수정한 사실을 보존한다.
  • 원본 메시지는 감사·보존 정책에 따라 별도 저장하고, 요약과 혼동하지 않는다.
  • “새 대화”와 “기억 없이 대화”를 제품에서 구분한다.

요약은 사실의 원본이 아니다. 요약문이 “사용자가 계약을 승인했다”고 적혀 있어도 승인 로그와 전자서명 기록을 대신할 수 없다.

3. 업무 상태: 대화가 아니라 상태 머신

장시간 실행, 사람 승인, 재시도, 외부 API 변경이 포함된 에이전트는 대화와 별도로 작업 레코드가 필요하다. 최소 필드는 다음과 같다.

필드목적
task_id·tenant_id·requester_id작업과 권한 경계 식별
goal·completion_criteria무엇을 끝내야 하는지 정의
current_step·status실행, 승인 대기, 실패, 완료 등 상태
completed_actions이미 수행한 행동과 결과 ID
pending_action승인 또는 재시도가 필요한 구체적 호출
tool_and_policy_version재개 시 동일 계약인지 확인
idempotency_key중복 실행 방지
created_at·expires_at수명과 오래된 상태 처리

사용자가 승인 화면을 닫았다가 다음 날 돌아와도 이 레코드로 재개한다. 재개 전에는 권한, 대상 값, 정책과 도구 버전을 다시 검사한다. 자세한 승인 경계는 Human-in-the-loop 설계와 연결한다.

4. 장기 기억: 저장보다 ‘승격 정책’이 중요하다

장기 기억 후보는 다음 대화에서도 유용한 정보다. 예를 들면 사용자가 명시한 언어, 보고서 형식, 자주 쓰는 프로젝트 이름이 있다. 반면 일회성 기분, 모델의 추론, 검색 결과 전체, 계좌번호나 비밀번호는 자동 장기 기억의 대상이 아니다.

안전한 쓰기 파이프라인은 다음과 같다.

  1. 후보 추출: 대화에서 지속 가능성이 있는 사실이나 선호를 구조화한다.
  2. 분류: 개인 선호, 프로젝트 사실, 조직 규칙, 민감정보, 일회성 상태로 나눈다.
  3. 검증: 사용자가 명시했는지, 신뢰할 수 있는 원천에서 왔는지 확인한다. 모델이 추론한 내용은 사실로 승격하지 않는다.
  4. 정책 검사: 저장 목적, 동의, 보존 기간, 지역·업무별 규정을 적용한다.
  5. 중복·충돌 처리: 기존 기억과 비교해 새 버전으로 교체할지, 함께 둘지, 사용자에게 물을지 결정한다.
  6. 저장: 원문 전체보다 필요한 최소 필드와 출처 포인터를 저장한다.
  7. 검색·사용: 현재 사용자·테넌트·업무 범위에서 관련 기억만 가져온다.
  8. 피드백: 사용자가 수정·삭제하면 즉시 반영하고 관련 캐시도 무효화한다.

장기 기억 레코드에는 다음 메타데이터가 필요하다.

  • 주체와 적용 범위: 개인, 팀, 프로젝트, 조직
  • 정규화된 내용과 유형
  • 출처: 사용자 명시, 업무 시스템, 승인된 문서
  • 작성자 또는 생성 프로세스
  • 생성·검증·마지막 사용 시각
  • 유효기간과 재검증 주기
  • 민감도와 사용 가능한 목적
  • 신뢰 상태: 확인됨, 임시, 충돌, 폐기
  • 이전 버전과 수정·삭제 이력

“사용자는 간결한 답을 선호한다”는 기억도 모든 상황에 적용하면 안 된다. 법무 검토나 장애 보고서에는 상세 근거가 필요할 수 있으므로 적용 범위를 “일반 Q&A”처럼 좁힌다.

5. 원본 업무 데이터: 기억하지 말고 다시 조회한다

고객 주소, 조직도, 가격, 재고, 계약 상태, 최신 규정은 변경될 수 있고 접근 권한도 다르다. 이런 정보를 장기 기억에 복사하면 오래된 값과 권한 우회가 생긴다. 기억에는 “고객 ID”나 “계약 문서 위치”처럼 다시 찾을 수 있는 참조만 두고, 답변 또는 실행 직전에 원천 시스템에서 최신 값을 조회한다.

RAG도 동일하다. 검색된 문서 조각을 사용자 개인 기억으로 저장하지 말고 문서 ID, 버전, 접근 범위를 보존한 뒤 재사용 시 권한을 다시 확인한다. 기존 기업용 AI Agent 아키텍처의 RAG 계층과 메모리 계층은 목적과 수명을 분리해야 한다.

메모리 검색과 충돌 해결 규칙

장기 기억이 쌓이면 저장보다 검색 품질이 어려워진다. 단순 의미 유사도만으로 가져오면 다른 프로젝트의 선호나 오래된 지침이 섞일 수 있다. 검색은 다음 필터를 순서대로 적용한다.

  1. tenant_id와 subject_id가 현재 요청자 범위와 일치하는가
  2. 업무·프로젝트·채널 범위가 맞는가
  3. 목적 제한과 민감도 정책을 통과하는가
  4. 만료되지 않았고 현재 시점에 유효한가
  5. 현재 목표와 관련 있는가
  6. 더 최신이거나 더 권위 있는 출처와 충돌하지 않는가

충돌 시에는 조용히 하나를 고르지 않는다. 예를 들어 과거 기억에는 “영문 보고서”가 있고 현재 요청에는 “이번에는 한국어”라고 했다면 현재 요청을 우선하고, 장기 선호를 바꿀지 사용자에게 선택권을 줄 수 있다. 조직 정책과 사용자 기억이 충돌하면 정책을 우선하고 그 이유를 설명한다.

사용자 경험·실패 시나리오

실패 1: 너무 많이 기억해 감시받는 느낌을 준다

사용자가 지나가듯 말한 개인 정보가 다음 달 다른 업무에서 나타나면 편리함보다 불쾌감이 커질 수 있다. “기억해줘”와 같은 명시적 요청, 제품 설정, 업무상 필요한 저장을 구분하고, 저장 직후 무엇을 어디에 기억했는지 알려준다.

실패 2: 잘못된 기억이 반복해서 답을 오염시킨다

한 번의 오해가 장기 기억에 들어가면 이후 답변이 계속 그 가정을 강화할 수 있다. 기억을 사용한 답변에는 관련 설정 또는 기억을 확인할 수 있는 경로를 제공하고, 사용자가 수정하면 이전 값과 파생 캐시를 폐기한다.

실패 3: 다른 사용자나 테넌트의 기억이 섞인다

세션 ID만으로 저장소를 조회하거나 공유 캐시 키에 테넌트를 포함하지 않으면 심각한 데이터 노출로 이어질 수 있다. 데이터베이스 쿼리, 벡터 인덱스, 캐시, 로그 전 구간에서 동일한 격리 키를 적용하고 교차 테넌트 테스트를 자동화한다.

실패 4: 메모리가 공격 입력을 장기 지침으로 보존한다

OWASP의 Agentic Applications Top 10 2026은 메모리와 컨텍스트 오염을 에이전트 보안 위험으로 다룬다. OWASP의 Memory Is a Feature. It Is Also an Attack Surface는 신뢰되지 않은 내용이 지속 메모리에 들어가 이후 판단을 오염시키는 문제를 설명한다. 도구 결과와 외부 문서의 지시를 장기 기억 후보로 자동 승격하지 말고, 쓰기 주체를 제한하며, 새 기억이 도구 사용 정책이나 시스템 지침을 덮어쓰지 못하게 한다.

실패 5: 요약 과정에서 중요한 약속이 사라진다

압축은 긴 대화를 유지하는 데 유용하지만 세부 조건을 잃을 수 있다. 요약 품질을 일반 요약 점수로만 보지 말고, 결정·미해결 항목·금액·날짜·부정 조건·출처가 보존되는지 실제 장기 대화로 평가한다. 중요한 필드는 요약문이 아니라 구조화 상태에 저장한다.

실패 6: 사용자가 기억을 끌 수 없다

기억 기능이 있어도 세션 한정 모드, 장기 기억 비활성화, 항목별 조회·수정·삭제가 필요하다. 삭제 요청은 주 저장소뿐 아니라 검색 인덱스, 캐시와 비동기 복제본까지 반영되는 완료 기준을 가져야 한다.

실무 체크리스트

  • 현재 컨텍스트, 세션 이력, 업무 상태, 장기 기억, 원본 데이터를 별도 개념으로 정의했다.
  • 각 계층의 소유자, 저장소, 보존 기간과 삭제 정책이 있다.
  • 세션 키와 캐시 키에 사용자·테넌트·업무 범위가 포함된다.
  • 중요한 실행 상태는 대화 요약이 아니라 구조화 레코드에 저장된다.
  • 장기 기억 후보의 허용·금지 유형과 동의 방식을 정했다.
  • 추론된 사실과 외부의 신뢰되지 않은 지시는 자동 저장하지 않는다.
  • 기억마다 출처, 적용 범위, 검증 상태, 민감도, 만료를 저장한다.
  • 원본 업무 데이터는 기억에 복사하지 않고 권한을 적용해 다시 조회한다.
  • 현재 요청, 정책, 원천 데이터와 기억이 충돌할 때 우선순위가 있다.
  • 메모리 쓰기와 읽기를 모두 감사하고 비정상 대량 변경을 탐지한다.
  • 교차 사용자·테넌트, 오래된 기억, 충돌 기억, 악성 기억 입력을 테스트한다.
  • 사용자가 기억을 조회·수정·삭제하고 일시적으로 제외할 수 있다.
  • 요약·압축 전후에 결정과 미해결 조건이 보존되는지 평가한다.
  • 삭제가 검색 인덱스, 캐시, 복제본까지 완료됐는지 확인한다.

자주 묻는 질문

Q1. 벡터 데이터베이스를 쓰면 장기 메모리가 완성되는가?

아니다. 벡터 검색은 관련 후보를 찾는 한 방법일 뿐이다. 장기 메모리에는 주체·테넌트 격리, 출처, 유효기간, 민감도, 충돌 해결, 수정·삭제와 감사 기능이 필요하다. 정확한 키 조회가 필요한 선호나 상태는 관계형 또는 키-값 저장소가 더 적합할 수 있다.

Q2. 대화 전체를 모델의 긴 컨텍스트에 넣으면 별도 메모리가 필요 없는가?

긴 컨텍스트도 관련성, 비용, 지연, 정보 충돌과 개인정보 문제를 없애지 못한다. 승인 대기나 도구 실행 결과처럼 재개와 감사가 필요한 상태는 별도 구조화 저장이 필요하고, 장기 선호는 세션을 넘어 적용되므로 수명과 통제 정책이 필요하다.

Q3. 사용자가 “모두 기억해줘”라고 하면 모든 대화를 저장해도 되는가?

그 문장만으로 모든 목적과 기간의 저장이 정당화되지는 않는다. 제품이 기억하는 범위, 민감정보 제외, 사용 목적, 보존 기간과 삭제 방법을 명확히 해야 한다. 비밀번호·인증 정보·규제상 제한 데이터처럼 저장하면 안 되는 항목은 사용자 요청과 관계없이 차단해야 한다.

근거 자료