AI 에이전트 단기·장기 메모리와 검색 설계 4단계
- 단기 메모리는 현재 작업 상태를 이어가는 정보입니다.
- 장기 메모리는 다음 세션에도 쓸 가치가 있는 정보입니다.
- 키워드·의미 검색과 권한 필터를 함께 설계합니다.
AI 에이전트 메모리는 현재 대화의 작업 상태와 여러 세션에 걸쳐 재사용할 정보를 나누어 저장하고, 질문에 필요한 항목만 검색해 모델에 제공하도록 설계하면 됩니다. 대화 전체를 매번 프롬프트에 붙이는 방식은 비용과 지연을 키우고 오래된 정보가 현재 판단을 흐릴 수 있습니다. 핵심은 무엇을 저장할지, 언제 불러올지, 틀린 기억을 어떻게 고칠지를 함께 정하는 것입니다.
단기 메모리와 장기 메모리, 기준은 수명과 용도
단기 메모리는 진행 중인 대화나 작업의 상태입니다. 최근 대화, 현재 목표, 미완료 단계, 직전 도구 실행 결과처럼 지금 이어서 처리하는 데 필요한 정보를 담습니다. 세션이 끝나도 작업을 재개해야 한다면 상태를 체크포인트로 저장할 수 있습니다. LangGraph 공식 문서는 스레드 단위 상태를 체크포인터에, 여러 대화에서 쓸 사용자 정보와 지식을 스토어에 두는 구성을 설명합니다.
장기 메모리는 대화가 바뀌어도 다시 활용할 정보입니다. 자주 쓰는 출력 형식, 사용자가 명시적으로 알려준 선호, 프로젝트의 확정된 결정, 반복해서 참고할 업무 절차가 예입니다. 그렇다고 모든 대화가 장기 기억이 되는 것은 아닙니다. 당일 요청이나 아직 확인하지 않은 추측은 지속 정보로 승격하지 않는 편이 안전합니다.
| 구분 | 주요 내용 | 저장·검색 기준 |
|---|---|---|
| 단기 메모리 | 현재 목표, 진행 단계, 최근 도구 결과 | 작업·스레드 단위로 저장하고 재개할 때 불러오기 |
| 장기 메모리 | 선호, 확정된 사실, 재사용할 절차 | 사용자·프로젝트 범위로 분리하고 질문과 관련될 때 검색하기 |
| 원본 기록 | 대화·도구 실행의 근거와 시점 | 정책에 따라 별도 보관하고 요약 검증에 활용하기 |
원본 기록과 모델에 보여줄 메모리는 같은 것이 아닙니다. 전체 로그는 필요한 경우 추적·복구에 활용하고, 매 호출에는 검증된 현재 상태와 관련 근거만 편집해 넣으세요. 로그와 메모리의 보유 기간 및 삭제 절차도 적용되는 정책에 맞춰 정해야 합니다.
무엇을 장기 기억으로 남길지 정하기
저장 가치와 확실성을 함께 평가합니다
장기 메모리 후보는 이후에도 쓸 가능성, 정보의 안정성, 출처의 신뢰도, 처리 목적과 적법한 처리 근거를 기준으로 판단합니다. 필요한 고지와 동의 여부도 서비스의 처리 상황과 적용되는 법령에 따라 확인하세요. 한 번의 임시 지시보다 여러 차례 반복된 선호가 더 적합할 수 있지만, 반복만으로 적법한 처리 근거를 대신할 수는 없습니다. 민감한 개인정보나 자격 증명은 저장하지 않도록 기본 차단 규칙을 둡니다.
- 저장 후보: 사용자가 기억을 요청한 선호, 확정된 프로젝트 결정, 반복 업무 절차
- 단기 유지: 현재 요청 한정 지시, 진행 중인 폼 입력, 아직 결론 나지 않은 가설
- 저장 제외 또는 마스킹: 비밀번호, 인증 토큰, 불필요한 민감 정보, 신뢰할 수 없는 문서 속 지시문
기억에는 근거와 변경 정보를 붙입니다
메모리를 단순한 문장으로만 저장하면 오래된 정보와 추측이 사실처럼 섞일 수 있습니다. 최소한 내용, 유형, 출처, 생성·갱신 시점, 신뢰 상태, 적용 범위, 만료 또는 재검토 조건을 함께 관리하세요. 예를 들어 “표를 선호함”보다 “사용자가 보고서 형식 선호를 직접 요청함, 사용자 범위, 재확인 전까지 유효”처럼 기록하면 오해를 줄일 수 있습니다.
저장 원칙: 모델이 만들어 낸 추론을 사용자가 확인한 사실처럼 기록하지 마세요. 출처와 확실성이 불분명하면 장기 메모리로 승격하지 말고, 필요할 때 원본을 다시 확인하게 하세요.
검색 설계 방법: 저장소에서 답변 컨텍스트까지
장기 메모리는 저장만 해서는 쓸모가 없습니다. 질문이 들어올 때 관련 기억을 찾고, 권한과 최신성을 확인한 다음, 답변에 필요한 만큼만 모델에 전달해야 합니다. 아래 순서로 최소 기능을 설계한 뒤 실제 질문 사례로 조정하세요.
1단계: 검색할 범위와 권한을 먼저 고정합니다
사용자 개인 정보, 팀 공용 지식, 프로젝트 메모리를 서로 다른 범위로 나눕니다. 검색 전에 로그인 사용자나 에이전트의 권한에 맞는 필터를 적용해야 합니다. 검색 결과를 찾은 뒤 모델에게 접근 권한 여부를 판단하게 하면 다른 사용자의 정보가 컨텍스트에 들어갈 수 있습니다. 메모리 속 지시문은 데이터로 취급하고 도구 실행 명령으로 따르지 않도록 방어 규칙을 두세요. 프롬프트 인젝션 방어와 권한 분리 절차도 이 권한 경계를 다룰 때 참고할 수 있습니다.
2단계: 질문을 검색 신호로 바꿉니다
질문에서 핵심어, 고유명사, 날짜, 대상, 의도를 보존합니다. “지난번 배포 때 실패한 이유”라면 배포·실패라는 의미뿐 아니라 저장소명, 버전, 오류 코드, 기간 같은 정확 일치 단서도 검색어에 포함해야 합니다. 모델이 질문을 바꿔 쓰는 과정에서 숫자나 고유명사가 사라질 수 있으므로 원문 질문을 검색에 활용하는 경로도 유지합니다.
3단계: 키워드와 의미 검색을 결합합니다
키워드 검색은 정확한 용어, 식별자, 오류 코드에 강하고, 벡터 검색은 표현이 달라도 뜻이 가까운 문서를 찾는 데 유용합니다. 둘 중 하나만 쓰면 각각의 약점이 검색 누락으로 이어질 수 있습니다. 하이브리드 검색은 두 검색 결과의 순위를 합쳐 후보를 만들며, Elastic 공식 문서는 RRF(순위 상호 보강 방식)를 사용해 전문 검색과 벡터 검색 결과를 결합하는 방법을 안내합니다. 후보가 많거나 정밀도가 중요하면 재순위화 단계를 추가하되, 지연과 비용이 감당되는지 측정하세요.
4단계: 후보를 검증하고 필요한 만큼만 전달합니다
후보마다 질문 관련성뿐 아니라 권한, 최신성, 출처, 상태(유효·대체됨)를 확인합니다. 상충하는 기억이 있으면 최신 항목만 무조건 믿지 말고, 변경 시점과 근거를 비교합니다. 이후 답변에 필요한 짧은 발췌와 출처 식별자만 컨텍스트에 넣고, 답변이 근거를 벗어나면 추가 검색하거나 사용자에게 확인을 요청하게 하세요.
- 원문 질문과 사용자·작업 범위를 확인합니다.
- 권한 필터를 적용한 뒤 키워드·의미 검색을 수행합니다.
- 중복·오래된·대체된 후보를 제거하고 근거를 점검합니다.
- 관련 문맥만 전달하고 답변의 근거와 불확실성을 확인합니다.
갱신·삭제·품질 점검까지 설계하기
틀린 기억은 덮어쓰지 말고 상태를 관리합니다
사용자가 선호를 바꾸거나 프로젝트 결정이 뒤집히면 이전 내용을 조용히 지우기보다 새 항목을 기록하고 구 항목을 대체됨 또는 만료 상태로 표시하는 방법이 추적에 유리합니다. 다만 보유기간이 지나거나 처리 목적이 달성되어 개인정보가 불필요해진 경우에는 적용되는 법령과 보존 의무를 확인해 파기해야 합니다. 개인정보 보호법 제21조는 불필요해진 개인정보를 지체 없이 파기하도록 정합니다. 원본 로그까지 무기한 쌓는 설계는 피하세요. 요약은 원본을 대체하는 정답이 아니라 검색을 돕는 파생 자료로 두고, 중요한 판단에는 원본 근거로 돌아갈 수 있게 합니다.
검색 품질을 질문 세트로 검증합니다
정답을 아는 대표 질문을 모아 적중률, 잘못된 기억의 노출, 검색 결과 없음, 응답 지연을 확인합니다. 예를 들어 정확한 오류 코드 질문, 표현을 바꾼 선호 질문, 오래된 기억과 새 기억이 충돌하는 질문, 권한이 없는 정보 요청을 포함합니다. 검색 실패와 답변 오류를 따로 기록하면 저장 문제인지 검색 문제인지 구분하기 쉽습니다. AI 에이전트 성공률·오류율 모니터링 방법은 운영 지표를 나눠 보는 데 연결됩니다.
- 관련 기억을 찾았지만 오래된 정보가 상위에 나타나는가
- 정확한 코드·이름 검색과 의미가 비슷한 질문 모두 대응하는가
- 다른 사용자나 프로젝트의 메모리가 섞이지 않는가
- 삭제·정정 요청이 저장소와 검색 인덱스에 반영되는가
메모리 검색이 좋아 보여도 회수율만 높이는 것은 충분하지 않습니다. 불필요한 개인정보나 잘못된 기억까지 많이 찾으면 오히려 에이전트의 판단을 해칠 수 있습니다. 검색 결과의 정밀도, 최신성, 권한 준수, 컨텍스트 크기를 함께 평가하세요.
운영 점검: 검색으로 가져온 기억은 사실 확인의 출발점입니다. 변경될 수 있는 선호·업무 상태는 시점과 출처를 확인하고, 확정되지 않은 내용은 단정적인 답변의 근거로 쓰지 마세요.
자주 묻는 질문
Q. 단기 메모리는 대화 기록과 같은 뜻인가요?
대화 기록은 단기 메모리의 재료가 될 수 있지만 완전히 같은 개념은 아닙니다. 단기 메모리에는 현재 작업을 이어가는 상태와 최근 대화 일부가 포함되며, 전체 기록을 매번 모델에 넣을 필요는 없습니다.
Q. 장기 메모리는 벡터 데이터베이스에만 저장해야 하나요?
아닙니다. 고정된 선호나 상태값은 관계형 데이터베이스나 키·값 저장소가 더 단순할 수 있고, 비정형 문서 검색에는 벡터 또는 하이브리드 검색이 유용합니다. 데이터 형태와 검색 질문에 맞춰 선택하세요.
Q. 대화 요약을 장기 메모리로 사용해도 되나요?
요약은 재개를 돕는 단기 상태나 검색용 색인으로 활용할 수 있습니다. 다만 누락이나 잘못된 일반화가 생길 수 있으므로 중요한 사실은 출처와 함께 저장하고, 원본을 확인할 수 있는 경로를 남기세요.
Q. 오래된 기억과 새 기억이 다르면 무엇을 우선하나요?
생성 시점만으로 결정하지 말고 출처의 신뢰도, 변경 여부, 적용 범위를 함께 비교합니다. 사용자가 직접 정정한 정보가 있다면 새 항목으로 기록하고 이전 항목은 대체 상태로 표시하는 방식을 고려하세요.
