AI 에이전트가 지난 대화를 기억하면 매번 같은 설명을 반복하지 않아도 됩니다. 프로젝트 규칙, 사용자의 선호, 이미 내린 결정과 실패한 접근을 이어받을 수도 있습니다. 하지만 모든 대화와 도구 결과를 계속 붙이는 방식은 곧 느려지고 비싸지며, 오래된 정보가 현재 판단을 오염시킬 수 있습니다.
좋은 메모리는 큰 저장소가 아닙니다. 현재 작업에 필요한 정보를 정확한 범위에서 꺼내고, 틀린 기억을 고치거나 지울 수 있는 상태 관리 시스템입니다. 이 글은 특정 벡터 데이터베이스 제품을 고르는 대신 무엇을 어디에 저장하고 언제 불러오며 어떻게 검증할지를 다룹니다.
1. 먼저 다섯 종류의 상태를 분리한다
OpenAI의 Conversation state 문서는 이전 응답 식별자나 Conversation 객체로 대화 상태를 이어가는 방법을 설명합니다. Google ADK도 한 대화의 이벤트와 임시 상태를 다루는 Session과 여러 대화에서 검색할 장기 지식을 다루는 MemoryService를 분리합니다. 이 둘을 하나의 ‘기억’으로 부르면 보존 기간과 접근 권한이 뒤섞입니다.
| 층 | 저장할 것 | 수명 | 핵심 규칙 |
|---|---|---|---|
| 현재 문맥 | 지금 답에 필요한 지시·근거 | 한 요청 | 작고 관련성 높게 |
| 세션 상태 | 작업 단계, ID, 임시 선택 | 한 작업·대화 | 이벤트와 변경 이력 유지 |
| 컴팩션 | 완료 내용과 다음 행동의 압축 | 긴 작업 | 원문 대체가 아닌 작업 연속성 |
| 장기기억 | 검증된 선호·결정·절차 | 여러 세션 | 범위·출처·만료·버전 필수 |
| 외부 원본 | 계약, CRM, DB, 정책 문서 | 시스템 정책 | 최종 진실의 원천으로 유지 |
예를 들어 “사용자는 표보다 목록을 선호한다”는 장기 선호가 될 수 있지만, “오늘 3시에 회의한다”는 일정 시스템의 원본이 우선입니다. “배포 ID 123에서 테스트가 실패했다”는 세션 상태이고, “다음에는 migration 뒤 smoke test를 실행한다”는 검증된 절차 기억 후보입니다.
2. 컴팩션은 장기기억과 다르다
긴 작업에서는 도구 결과, 파일 내용과 중간 추론이 문맥을 채웁니다. OpenAI의 Compaction 가이드는 긴 대화 상태를 압축해 이후 요청에 이어 붙이는 방법을 제공하고, Anthropic은 긴 문맥일수록 정확도와 회상이 저하될 수 있어 서버 컴팩션이나 오래된 도구 결과 정리가 중요하다고 설명합니다.
컴팩션의 목적은 현재 작업을 계속할 최소 상태를 남기는 것입니다. 다음 항목을 보존하면 좋습니다.
- 사용자의 현재 목표와 완료 조건
- 이미 완료된 행동과 확인된 결과
- 결정과 그 근거, 바뀌면 안 되는 제약
- 파일·레코드·배포처럼 다시 찾아야 할 정확한 식별자
- 아직 해결되지 않은 차단 요소와 다음 한 단계
반면 원본 로그 전체, 이미 반영된 긴 검색 결과, 재생성 가능한 출력은 활성 문맥에서 뺄 수 있습니다. 압축 요약은 손실 가능성이 있으므로 계약 금액이나 고객 동의 같은 권위 있는 사실의 저장소로 사용하면 안 됩니다.
3. 무엇을 장기기억에 쓸지 계약으로 정한다
Anthropic의 Memory tool은 메모리 파일을 애플리케이션 측 저장소에서 관리하고 필요할 때 읽는 구조를 제시합니다. Google ADK는 완료 세션 전체, 일부 이벤트 또는 명시적 MemoryEntry를 기억 서비스에 넣을 수 있다고 설명합니다. 중요한 것은 모델이 말한 모든 내용을 자동 승인하지 않는 것입니다.
기억 레코드에는 최소한 다음 필드를 둡니다.
memory_id, scope, type, content
source_uri_or_record_id, observed_at, effective_from, expires_at
confidence, sensitivity, version, supersedes
created_by, approved_by, allowed_readers
| 기억 후보 | 기본 처리 | 이유 |
|---|---|---|
| 명시한 선호 | 저장 가능 | 사용자 범위와 변경 시점 기록 |
| 승인된 결정 | 저장 권장 | 근거와 승인자를 연결 |
| 검증된 절차 | 저장 권장 | 적용 조건과 버전을 함께 보존 |
| 모델의 추측 | 저장 금지 | 추론이 다음 세션에서 사실로 굳어짐 |
| 비밀번호·토큰 | 저장 금지 | 비밀 관리 시스템을 사용 |
| 원시 도구 출력 | 기본 미저장 | 크고 오래되며 인젝션을 포함할 수 있음 |
| 시세·재고·정책 | 짧은 만료 또는 참조만 | 최신 원본을 다시 조회해야 함 |
쓰기 전 질문은 단순합니다. 이 정보가 다음 세션에서도 유용한가, 출처가 있는가, 누가 볼 수 있는가, 언제 틀릴 수 있는가, 삭제 요청을 처리할 수 있는가를 모두 답하지 못하면 장기기억으로 승격하지 않습니다.
4. 검색은 ‘전부 주입’이 아니라 필요할 때 최소한으로
Anthropic은 메모리를 모두 문맥에 미리 넣지 않고 작업 중 필요한 파일을 읽는 just-in-time 검색을 설명합니다. Google ADK의 MemoryService도 장기 저장소를 검색해 관련 조각을 불러오는 역할입니다. 검색 단계는 다음 순서가 안전합니다.
- 현재 작업에서 필요한 기억 유형과 범위를 만든다.
- 사용자·조직·프로젝트 권한으로 먼저 필터링한다.
- 만료되지 않은 후보만 의미·키워드·정확 ID로 검색한다.
- 상위 소수 후보의 출처와 시간을 확인한다.
- 충돌하면 최신 레코드 또는 외부 원본을 우선하고 불확실성을 표시한다.
- 사용한 memory_id를 결과 로그에 남긴다.
벡터 유사도 하나만으로는 “비슷하지만 다른 고객”, “과거에 맞았지만 지금은 바뀐 정책”을 걸러내기 어렵습니다. 범위, 시간과 권한 필터를 검색 전에 적용하고, 정확한 식별자가 있으면 의미 검색보다 우선해야 합니다. 검색 결과는 지시가 아니라 검토할 데이터로 취급해 저장된 프롬프트 인젝션이 도구 실행으로 이어지지 않게 합니다.
5. 틀린 경험은 다음 작업의 오류를 키울 수 있다
ACL 2026에 게재된 연구는 에이전트가 검색된 과거 경험과 현재 입력이 비슷할수록 과거 행동을 강하게 따르는 경향을 보고했습니다. 그 결과 잘못된 경험이 반복되는 오류 전파와, 겉으로 성공해 보였지만 새 작업에는 맞지 않는 경험 재생 문제가 나타났습니다. 이는 “성공 로그만 저장하면 된다”는 생각도 충분하지 않다는 뜻입니다.
기억을 쓴 직후만 평가하지 말고 그 기억이 사용된 다음 작업의 결과를 다시 연결하세요. 이후 실패가 발생하면 해당 기억의 신뢰도를 낮추거나 격리하고, 잘못된 레코드를 새 레코드로 조용히 덮어쓰지 말고 supersedes 관계를 남겨야 합니다.
6. 정정과 삭제는 부가 기능이 아니라 핵심 기능이다
장기기억에는 생성뿐 아니라 조회, 수정, 폐기와 감사 이력이 필요합니다. 사용자가 선호를 바꾸거나 정책이 개정됐을 때 과거 값을 계속 검색하면 메모리가 없는 에이전트보다 위험해집니다.
쓰기: 후보 → 출처 확인 → 민감도·범위 → 만료 → 승인
읽기: 범위 필터 → 최신성 → 관련성 → 충돌 해결 → 최소 주입
정정: 새 버전 생성 → 이전 기억 연결 → 캐시 무효화
삭제: 저장소·색인·백업 정책에 따라 제거 → 삭제 영수증 기록
Anthropic의 Memory tool은 저장을 애플리케이션이 통제한다는 점을 분명히 합니다. 따라서 경로 이동 공격을 막고 사용자별 디렉터리나 키 범위를 강제해야 합니다. 개인정보는 목적과 보존 기간을 정하고, 사용자가 볼 수 있는 ‘내 기억 보기·수정·삭제’ 화면을 제공하는 편이 좋습니다.
7. 메모리 품질은 회상률 하나로 평가하지 않는다
평가 세트에는 기억이 있는 조건과 없는 기준선을 함께 둡니다. 저장된 정보와 무관한 질문도 포함해야 검색기가 불필요한 기억을 끼워 넣는지 알 수 있습니다.
| 테스트 | 성공 기준 | 대표 실패 |
|---|---|---|
| 정확 회상 | 올바른 범위·값·출처 | 다른 사용자 기억 혼입 |
| 시간 정정 | 새 값 우선, 과거 이력 유지 | 오래된 정책 재사용 |
| 모순 처리 | 충돌을 표시하고 원본 확인 | 임의로 한쪽 선택 |
| 삭제 보장 | 검색·캐시에서 재등장 없음 | 색인에 잔존 |
| 무관 질문 | 기억을 불러오지 않음 | 과검색으로 문맥 오염 |
| 공격 입력 | 저장 지시를 데이터로 격리 | 인젝션을 장기 규칙으로 저장 |
| 비용·지연 | 이득이 추가 호출비보다 큼 | 검색 때문에 더 느리고 비쌈 |
업무별로 기억이 도움을 주는 질문, 방해하는 질문, 시간이 지나 정답이 바뀌는 질문을 나누고 회상 정확도뿐 아니라 최종 작업 성공률, 잘못된 기억 채택률, 삭제 누락, P95 지연과 추가 토큰을 기록하세요.
실전 도입 순서
- 한 업무와 한 사용자 범위로 시작한다.
- 세션 상태와 장기기억 테이블을 분리한다.
- 결정·선호·검증된 절차 세 유형만 허용한다.
- 출처, 적용 시점, 만료와 버전을 필수로 만든다.
- 검색 결과를 최대 소수로 제한하고 사용 ID를 기록한다.
- 정정·삭제 API와 관리자 감사 화면을 먼저 만든다.
- 기억 없음 기준선과 동일한 평가 세트로 비교한다.
- 품질 개선이 확인된 뒤에만 자동 쓰기 범위를 넓힌다.
결론: 기억보다 중요한 것은 기억의 통제다
AI 에이전트가 모든 것을 기억할 필요는 없습니다. 현재 문맥은 작게 유지하고, 세션에는 진행 상태를, 컴팩션에는 연속성을, 장기기억에는 검증된 재사용 정보만 남기며, 계약과 고객 데이터는 외부 원본에서 다시 확인해야 합니다.
메모리 시스템의 성공 기준은 “얼마나 많이 저장했는가”가 아니라 필요할 때 맞는 기억을 찾고, 틀렸을 때 근거 있게 고치며, 요청받으면 완전히 지울 수 있는가입니다. 작은 허용 목록과 엄격한 정정·삭제 테스트로 시작하십시오.
주요 자료
- OpenAI: Conversation state
- OpenAI: Compaction
- Anthropic: Memory tool
- Anthropic: Context windows
- Anthropic: Context editing
- Google ADK: MemoryService
- Google ADK: Session
- ACL 2026: How Memory Management Impacts LLM Agents
API 기능과 데이터 보존 조건은 변경될 수 있습니다. 실제 구현 전 최신 공급사 문서, 조직의 개인정보 정책과 적용 법률을 다시 확인하세요.