AI 에이전트 메모리 설계: 기억할 정보와 잊어야 할 정보

많이 저장하는 것보다 유효한 기억을 쓰는 것이 중요합니다

GitHub는 2026년 에이전트 메모리 글에서 저장한 사실에 코드 위치를 연결하고 사용 시점에 근거를 확인하는 접근을 소개했습니다. 과거 브랜치에서 맞았던 규칙이 현재 코드에서는 달라질 수 있기 때문입니다. 사내 업무 에이전트도 기억의 양보다 범위와 유효성을 관리해야 합니다.

예를 들어 '이 고객의 담당자는 김 매니저'라는 정보를 저장했더라도 조직이 바뀌면 잘못된 사람에게 업무가 연결됩니다. 사용자의 취향, 현재 작업의 진행 상태와 회사 정책을 같은 저장소에서 같은 규칙으로 다루지 마세요. 확인해야 할 빈도와 삭제 기준이 서로 다릅니다.

정보의 수명에 따라 저장 방식을 나눕니다

기억에는 근거와 적용 범위를 붙입니다

저장 항목에는 사실, 근거 위치, 확인 시각, 적용 사용자나 프로젝트를 연결해 보세요. 모델의 추정과 확인된 사실을 구분하지 않으면 추정이 다음 대화에서 확정된 정보처럼 쓰일 수 있습니다. 외부 문서에서 가져온 내용이 조직 정책을 바꾸는 규칙으로 저장되지 않도록 정보의 역할도 구분합니다.

모든 내용을 영구 저장할 필요는 없습니다. 반복해서 도움이 되는 정보인지, 원천 데이터에서 쉽게 다시 가져올 수 있는지 판단하세요. 자주 바뀌는 주문 상태를 기억하는 것보다 주문 ID를 남기고 현재 상태를 조회하는 방식이 적합할 수 있습니다.

수정과 삭제도 메모리 기능의 일부입니다

사용자가 정보를 고치거나 삭제하면 파생된 요약과 검색 저장소에도 반영되어야 합니다. 조직이나 프로젝트가 바뀐 뒤 이전 범위의 기억을 불러오지 않는지도 확인하세요. 운영 로그와 메모리의 보관 목적을 구분하고 필요 이상의 대화 원문을 저장하지 않도록 정책을 정합니다.

서로 충돌하는 기억을 발견하면 단순히 마지막에 저장된 값을 선택하지 마세요. 고객이 직접 수정한 연락처와 과거 문서에서 추출한 연락처는 근거의 성격이 다릅니다. 어떤 원천을 우선하는지 정하고, 우선순위만으로 해결할 수 없는 경우에는 현재 정보를 다시 확인합니다.

메모리 품질 검수 항목

• 잘못된 기억을 넣었을 때 현재 근거로 바로잡는가
• 근거가 사라지면 기억의 신뢰도를 낮추거나 사용을 보류하는가
• 사용자·조직·프로젝트 간 기억이 섞이지 않는가
• 수정·삭제 요청이 관련 저장소에 반영되는가
• 메모리 사용 전후 반복 질문과 오류가 실제로 줄었는가