AI Agent Memory Design: What Works and What Doesn’t

AI 에이전트 메모리 설계: 무엇이 시스템을 살리고 죽이는가?

참고 문헌: Bala Priya C (2026), AI Agent Memory Design: What Works and What Doesn’t, Machine Learning Mastery.

원문의 저자 Bala Priya C는 에이전트 메모리의 딜레마를 이렇게 지적합니다:

“Storing everything increases cost and makes retrieval noisier.”
(모든 것을 저장하면 비용이 늘고 검색 결과는 더 지저분해집니다.)

이 말의 본질은 간단합니다. 무조건 다 기억하려다간 뇌가 마비되고, 아무것도 기억하지 않으면 매번 바보처럼 처음부터 다시 물어야 한다는 뜻입니다.

자, 그렇다면 똑똑한 AI 에이전트를 만들기 위해 우리는 메모리를 어떻게 설계해야 할까요? 하나씩 풀어보겠습니다.

1단계: 왜 이것이 중요한가? (Why It Matters)

우리가 쓰는 챗봇은 대화창을 닫으면 방금 한 말을 잊어버립니다. 이를 ‘무상태(Stateless)’라고 부릅니다.

만약 여행 계획을 세우는 에이전트에게 “난 땅콩 알레르기가 있어”라고 말했습니다. 그런데 다음 날 식당을 예약할 때 이 사실을 까먹고 땅콩 요리 전문점을 추천한다면 어떨까요? 치명적인 사고가 일어납니다.

많은 개발자가 이 문제를 해결하려고 단순히 이전 대화 전체를 프롬프트에 계속 덧붙입니다. 하지만 대화가 길어지면 토큰 비용이 폭발하고, 모델은 긴 글 속에서 길을 잃습니다.

결국 에이전트가 사람처럼 다중 세션(여러 번의 작업)을 거쳐도 일관되게 일하려면, 외부 저장소를 활용한 ‘정교한 메모리 시스템’이 반드시 필요합니다.

2단계: 핵심 개념 파헤치기 (Unpacking the Core Concept)

메모리를 그냥 하나의 큰 창고로 생각하면 실패합니다. 사람의 뇌를 떠올려 볼까요? 여러분의 기억은 한곳에 뭉쳐 있지 않습니다.

에이전트의 메모리도 성격에 따라 다음 4가지 서랍으로 나눠야 합니다.

이 서랍들을 하나로 합쳐버리면 무슨 일이 일어날까요?

가장 흔한 실패는 “모든 것을 벡터 DB 하나에 쏟아붓는 것”입니다. 의미가 비슷하다는 이유(Semantic Similarity)만으로, 과거의 쓸모없는 찌꺼기 정보가 지금 당장의 중요한 의사결정 자리에 불려 나오는 비극이 발생합니다.

또 하나의 치명적인 실수는 “긴 대화를 그냥 줄글로 요약해서 저장하는 것”입니다.

• 요약은 필연적으로 디테일을 버립니다. 이때 “예산은 100만 원 이하” 같은 핵심 제약조건이 빠지기 쉽습니다.
• 만약 에이전트가 앞선 대화에서 거짓말(환각)을 했는데 그것이 요약본에 들어가면, 다음 세션의 에이전트는 그 거짓말을 ‘절대적 진실’로 믿고 행동합니다. 실수가 눈덩이처럼 불어납니다.

3단계: 실무 적용과 증명된 해법 (Evidence and Application)

그렇다면 실제 현장에서는 어떻게 만들어야 실패하지 않을까요? 원문에서 제시하는 4가지 황금 규칙이 있습니다.

① 중요도와 신뢰도 평가 (Importance Scoring)

모든 정보를 다 저장하지 마세요. 정보를 저장하기 전, 검문소를 둡니다.

“이 정보가 단발성인가, 지속적인 제약조건인가?”

중요도 점수가 기준치(예: 0.6 이상)를 넘는 사실만 장기 메모리에 기록합니다. 또한 시간이 지나면 가치가 떨어지는 정보는 자동으로 소멸하도록 유효기간(TTL)을 설정합니다.

② 자유 요약 대신 ‘정형화된 사실 추출’

줄글로 대충 요약하지 마세요. 엄격한 데이터 형식(예: Pydantic 모델)을 지정하고, 검증 가능한 사실(Fact)만 딱딱 뽑아서 저장해야 합니다.

• 나쁜 예: “사용자는 저렴한 노트북을 찾고 있으며 예산 이야기를 나눴음.”
• 좋은 예: { item: "laptop", max_budget: 1000000, currency: "KRW" }

③ 역할별 메모리 격리 (Scoping)

여러 에이전트가 협업할 때, 한 서랍을 다 같이 쓰게 두면 안 됩니다. 자료 조사 에이전트가 끄적여 둔 거친 메모를 코드 작성 에이전트가 읽고 엉뚱한 코드를 짜버릴 수 있습니다. 오케스트레이터(총괄자)만 전체를 보고, 하위 에이전트는 자기 전용 메모리 영역만 읽고 쓰게 만들어야 합니다.

④ 출처 추적과 독극물 검사 (Provenance & Sanitization)

보안 연구에서 보고된 MemoryGraft(메모리 오염 공격)을 조심해야 합니다. 해커가 웹페이지에 숨겨둔 악의적 명령어가 에이전트의 장기 기억에 한 번 저장되면, 에이전트는 이후 모든 세션에서 영구적으로 해커의 조종을 받게 됩니다. 따라서 메모리에 쓸 때는 반드시 “누가, 어떤 도구를 통해 가져온 정보인가?”(신뢰도 레벨)를 꼬리표로 달고, 외부에서 온 데이터는 악의적 지시문이 없는지 검사(Sanitize)한 뒤에만 저장해야 합니다.

4단계: 요약 및 실천 과제 (Summary and Extension)

오늘 배운 핵심을 한 줄로 압축해 보겠습니다.
“에이전트 메모리의 성공은 검색 기술이 아니라, 무엇을 버리고 어떻게 정제해서 쓸 것인가(Write Policy)에 달려 있습니다.”

[자가 점검 퀴즈]

오늘 배운 내용을 머릿속으로 떠올려 보며 스스로 답해 보세요.

1. 에이전트 대화가 길어질 때, 단순히 이전 대화를 줄글로 요약해서 장기 메모리에 넣으면 어떤 두 가지 치명적인 문제가 생길까요?
2. 당장 계산 중인 변수값을 담는 ‘작업 메모리(Working Memory)’와 과거 작업 성공/실패 기록을 담는 ‘에피소딕 메모리(Episodic Memory)’의 저장소는 왜 달라야 할까요?
3. 외부 웹 문서를 읽고 요약해 메모리에 저장할 때, 보안상 반드시 확인해야 하는 절차는 무엇일까요?