AI 에이전트 장기 메모리, 많이 저장할수록 똑똑해질까?

핵심 요약

• 세션 버퍼에는 현재 작업에만 필요한 임시 맥락을 두고, 재사용 가치가 확인된 규칙만 장기 보관 후보로 올립니다.
• 장기 메모리에는 내용만이 아니라 근거, 적용 범위, 만료·삭제 조건, 담당자를 함께 남겨야 합니다.
• 검색 결과는 “나왔는가”가 아니라 현재 규칙의 근거를 인용했는가로 확인합니다.
• 삭제 또는 대체 뒤에는 같은 질문을 다시 실행해, 폐기한 항목이 답변 근거에서 사라졌는지 기록합니다.
• 출처 추적, 삭제 확인, 규칙 충돌 판정 중 하나라도 비어 있으면 해당 기억으로 외부 발송·권한 변경·삭제 같은 실행을 시작하지 않습니다.

세션과 장기 메모리를 왜 나눌까요?

세션 버퍼는 지금 이 작업을 끝내기 위한 작업대이고, 장기 메모리는 다음 작업에서도 재사용할 수 있도록 승인된 지식입니다. 둘을 같은 곳에 계속 쌓으면 임시 지시, 실패한 시도, 개인 정보가 오래 남을 가능성이 커집니다.

Google Cloud는 장기 에이전트 메모리 구현 예시에서 단기 대화 상태와 장기 보관 계층을 구분하는 접근을 설명합니다. 이는 특정 제품의 기본 동작을 뜻하지는 않지만, 현재 작업 맥락과 재사용 가능한 기록을 분리해야 한다는 설계 출발점으로 참고할 수 있습니다. Anthropic의 공식 자료도 지속 메모리를 다루는 개발 자료가 별도의 관리 대상임을 보여 줍니다.

운영 관점: 비용은 저장 용량보다 재검색 오류를 조사하는 시간에서 커질 수 있습니다. 권한·신뢰성·품질을 함께 보려면, “기억이 있다”가 아니라 “어떤 근거로 지금 이 작업에 허용됐는가”를 답할 수 있어야 합니다.

저장 뒤까지 책임지는 FLOWIT 6칸 lifecycle 카드

메모리를 만들 때 한 줄의 규칙만 저장하지 마세요. 아래 여섯 칸을 채우면, 나중에 검색 결과가 나왔을 때 채택·보류·삭제를 재현 가능하게 판단할 수 있습니다.

1. 1. write 후보·근거
   무엇을 저장하는지와 승인된 문서, 변경 기록, 검증 결과를 함께 연결합니다. “좋아 보인다”는 인상만으로는 근거가 되지 않습니다.
2. 2. tier
   세션 전용인지, 팀 재사용인지, 특정 업무 범위의 장기 기록인지 정합니다. 범위가 넓을수록 검토 책임도 커집니다.
3. 3. retrieval query·기대 근거
   어떤 질문에서 이 메모리가 나와야 하는지와, 답변에 반드시 붙어야 할 근거 ID를 적습니다.
4. 4. freshness·TTL·삭제 trigger
   검토일, 만료일, 새 정책으로 대체되는 조건, 삭제 요청을 명시합니다. 날짜가 없으면 오래된 규칙은 사실상 영구 규칙이 됩니다.
5. 5. 권한·민감도
   누가 읽고 수정하고 삭제할 수 있는지 정합니다. 원문 전체나 비밀값은 장기 보관 후보에서 제외합니다.
6. 6. rollback owner·감사 기록
   문제가 생겼을 때 누가 어떤 ID를 되돌리고, 동일 질문 재시험 결과를 어디에 남길지 정합니다.

“검색됐다”가 아니라 “현재 근거만 인용됐다”를 시험하세요

긴 입력 안의 관련 정보 위치에 따라 모델 활용 성능이 달라질 수 있다는 연구 결과는, 많은 문서를 넣는 것만으로 일관된 활용을 보장하지 않는다는 점을 보여 줍니다. 그래서 장기 메모리도 실제 질문과 근거를 짝지은 시험이 필요합니다.

1. 동일한 업무 규칙의 최신 항목과 폐기 항목을 준비하고 각각 고유한 근거 ID와 상태를 둡니다.
2. 실제 업무에서 나올 질문으로 검색합니다. 예: “이 저장소의 배포 전 검사는 무엇인가요?”
3. 답변이 최신 항목의 근거 ID를 제시하고, 폐기 항목을 현재 규칙처럼 권하지 않는지 확인합니다.
4. 결과, 인용된 ID, 실행 시각, 사용한 scope를 기록합니다. 기대와 다르면 원인을 확인하기 전에는 실행으로 넘기지 않습니다.

삭제·대체 뒤에는 같은 질문으로 다시 확인해야 합니다

삭제 요청을 처리했다는 기록만으로 충분하지 않습니다. 저장소, 인덱스, 캐시, 도구가 참조하는 별도 목록 중 어디에서 결과가 다시 나오는지 확인하지 않으면, 폐기한 정보가 다음 작업에 재등장할 수 있습니다.

대체 또는 삭제 뒤에는 앞의 retrieval 질문을 같은 범위에서 다시 실행하세요. 기대하는 결과는 “해당 항목이 없다” 또는 “폐기 상태로만 설명되고 현재 실행 근거로는 채택되지 않는다”입니다. 결과와 provenance를 함께 남기면, 나중에 오류가 났을 때 저장 문제인지 검색 문제인지 운영자가 분리해 볼 수 있습니다.

실패 조건: 삭제 후에도 폐기 항목이 최신 규칙처럼 나오거나, 왜 그 항목이 선택됐는지 추적할 수 없거나, 새 규칙과 옛 규칙의 충돌을 판정할 수 없다면 그 답변을 외부 시스템에 전달하지 마세요. 재인덱싱, 권한 재확인, 근거 보완 후에만 다시 시험하는 것이 좋습니다.

이 세 경우에는 자동 실행을 멈추세요

이 기준은 장기 메모리가 불필요하다는 뜻이 아닙니다. 오히려 반복 업무에서 신뢰할 수 있는 도움을 받기 위한 최소한의 운영선입니다. 저장 후보를 고르는 기준이 필요하다면 메모리 승격 증거 카드를 먼저 확인해 보세요. 작업 종료 뒤 기록을 정리하는 범위는 세션 보존·삭제 계약, 압축 전후의 단기 맥락 확인은 컨텍스트 압축 인수 스냅샷에서 이어서 볼 수 있습니다.

자주 묻는 질문

장기 메모리에 대화 원문을 통째로 넣어도 되나요?

권하지 않습니다. 재사용 목적과 범위가 분명한 요약·규칙·근거 연결을 우선하고, 비밀값·개인 정보·사용자 원문 전체는 별도 보존·권한 정책 없이 장기 메모리에 넣지 않는 편이 좋습니다.

TTL만 설정하면 오래된 기억 문제는 해결되나요?

아닙니다. 만료 시점은 필요하지만, 실제 검색 결과에서 만료·대체된 항목이 현재 근거로 채택되지 않는지 재시험해야 합니다. 적용 범위와 우선순위가 없으면 TTL만으로 충돌을 해결할 수 없습니다.

삭제한 항목이 검색 결과에 보이면 무조건 실패인가요?

현재 규칙의 근거로 사용되거나 상태를 설명하지 않은 채 추천된다면 실패로 보아야 합니다. 다만 감사 목적의 이력 조회처럼 제한된 화면에서 폐기 상태로 보이는 경우는 권한·용도를 분리해 판단할 수 있습니다.

retrieval 시험을 통과하면 외부 실행을 맡겨도 되나요?

아닙니다. 이 시험은 기억을 사용하는 과정의 일부만 확인합니다. 실행 권한, 입력 검증, 승인 절차, 변경 영향은 별도로 점검해야 합니다.

처음 시작할 때 가장 작은 단위는 무엇인가요?

반복되는 규칙 하나를 골라 6칸 카드를 채우고, 최신·폐기 항목을 함께 둔 동일 질문 시험을 한 번 만드는 방식이 좋습니다. 한 번의 결과를 기록한 뒤 범위를 조금씩 넓히세요.