LLM은 원래 아무것도 기억하지 못합니다. 설계상 상태가 없어서, 보내는 프롬프트 하나하나를 완전히 독립된 사건으로 처리하죠. 그런데도 대화를 이어가다 보면 AI가 앞선 내용을 기억하는 것처럼 느껴집니다. 사실은 인터페이스가 그렇게 보이도록 꾸미고 있을 뿐입니다. 매번 지금까지의 대화 전체를 다시 모아 하나의 거대한 프롬프트로 보내면서, 기억하는 척을 시키는 것이죠.

테스트 자동화 전문가 Angie Jones가 Oracle에서 에이전트 메모리를 다뤄온 Richmond Alake와 나눈 대화를 O’Reilly Radar에 정리했습니다. 핵심은 단순합니다. 사람들이 “에이전트 메모리”라고 말할 때, 그 안에는 전혀 다른 여러 종류의 기억이 섞여 있다는 것입니다.

출처: Agent Memory – O’Reilly Radar

“메모리”라는 한 단어에 담긴 7가지

대화를 계속 프롬프트에 덧붙이는 방식은 짧은 대화에선 통합니다. 하지만 대화가 길어지면 모델은 중요한 정보, 낡은 정보, 무관한 정보가 뒤섞인 거대한 덩어리를 받게 됩니다. 정보를 가지고 있다는 것과 그걸 제대로 쓸 수 있다는 것은 다른 문제죠.

그래서 Jones는 메모리를 일곱 갈래로 나눕니다.

• 대화 메모리: 사용자와 주고받은 메시지를 담습니다.
• 의미 메모리: “이 사용자는 백엔드에 파이썬을 선호한다” 같은 지속적 사실을 저장합니다.
• 일화 메모리: “에이전트가 #4821 티켓의 초안을 작성했다”처럼 무슨 일이 일어났는지 기록합니다.
• 절차 메모리: “배포 실패를 조사할 땐 로그부터 본다” 같은 일하는 방식을 담습니다.
• 엔티티 메모리: 특정 고객·프로젝트에 묶인 사실을 다룹니다.
• 작업 메모리: 지금 작업 중에만 쓰는 임시 메모장입니다.
• 요약 메모리: 긴 맥락을 압축해 둡니다.

이렇게 쪼개 보면, 우리가 막연히 “AI가 기억한다”고 말할 때 실제로는 성격이 다른 여러 시스템을 동시에 가리키고 있었다는 게 드러납니다. 각각은 저장 방식도, 꺼내는 방식도 다릅니다. 의미 메모리는 뜻이 비슷한 것을 찾는 벡터 검색이 어울리지만, “지난 24시간 동안 실패한 도구 호출을 모두 찾아라” 같은 일화 메모리는 데이터베이스 질의에 가깝습니다.

어려운 건 저장이 아니라 판단

메모리라고 하면 “저장했다가 나중에 꺼낸다”는 단순한 그림이 떠오릅니다. 그런데 진짜 어려운 부분은 저장이 아니라 판단입니다.

무엇을 기억할 것인가. 사용자가 “보통 파이썬을 선호해요”라고 하면 기억할 만하지만, “이번 실험만 파이썬으로 해보죠”라고 하면 아닐 수 있습니다. 언제 갱신할 것인가. 사람은 마음을 바꾸고, 예전엔 FastAPI를 쓰다가 이제 자바로 옮겼다면 과거 기억을 지울지 덮어쓸지 정해야 합니다. 얼마나 꺼낼 것인가. 너무 적게 꺼내면 맥락을 놓치고, 너무 많이 꺼내면 프롬프트가 잡음으로 가득 찹니다. 맥락은 많을수록 좋은 게 아닙니다.

여기에 안전 문제도 걸립니다. 한 사용자의 기억이 다른 사용자의 응답으로 새어 나가지 않도록, 기억마다 누구의 것인지 경계를 분명히 그어야 합니다. Jones의 표현을 빌리면, 나쁜 기억은 기억이 없는 것보다 나쁩니다.

다 기억하게 할까, 어디를 볼지 알게 할까

앞서 본 판단들을 데이터베이스 안에서 정교하게 풀어내려는 방향이 한쪽 끝이라면, 정반대 쪽에서 출발하는 사람도 있습니다. AI 연구자 Louis Bouchard는 모델 바깥에 기억을 두는 접근을 제안합니다.

그가 만든 건 벡터 데이터베이스도 지식 그래프도 없는, 평범한 파일과 참조로 이뤄진 구조입니다. 원본을 그대로 보존하는 raw 계층, 무엇이 어디 있는지 알려주는 색인(index) 계층, 그리고 출처를 개념·비교·노트로 가공해 점점 자라나는 위키(wiki) 계층. 에이전트는 전체를 통째로 읽는 대신 색인을 먼저 보고, 필요한 파일만 펼쳐 봅니다.

Bouchard의 결론은 한 문장으로 압축됩니다. 모델이 모든 걸 기억하게 만들지 말고, 어디를 봐야 할지 알게 하라는 것입니다. 그는 손으로 폴더를 열어 직접 요약을 고치고 약한 출처를 덜어낼 수 있는, 들여다볼 수 있는 메모리를 원한다고 말합니다. 물론 그도 제품 단계에서는 벡터 검색과 RAG가 여전히 필요하다고 인정합니다. 두 접근은 우열의 문제라기보다, 무엇을 기억의 중심에 둘 것인가에 대한 서로 다른 선택입니다.

기억은 쌓이는 게 아니라 설계되는 것

이렇게 보면 유형을 일곱 가지로 나눈 것 자체가 핵심은 아닙니다. 분류가 드러내는 한 가지가 더 중요합니다. “AI가 알아서 기억해주겠지”라는 기대를, 내가 무엇을 기억시킬지 직접 정한다는 감각으로 바꿔야 한다는 것입니다.

에이전트를 쓰다 보면 매번 같은 맥락을 다시 설명하게 됩니다. 흔히 이걸 모델이 멍청해서라고 여기지만, 실은 기억을 설계하지 않았기 때문입니다. 무엇을 남기고 무엇을 흘려보낼지 아무도 정해주지 않으면, 에이전트는 대화 전체를 통째로 끌어안거나 아무것도 들고 가지 못합니다. Jones의 “나쁜 기억은 기억 없음보다 나쁘다”와 Bouchard의 “다 기억하게 하지 말고 어디를 볼지 알게 하라”는 결국 같은 곳을 가리킵니다. 덜 기억하되, 의도적으로 기억하라는 것이죠.

이 관점이 손에 쥐여주는 건 도구를 보는 다른 눈입니다. 새 AI 도구를 마주했을 때 “이게 얼마나 똑똑한가”만 묻는 대신, “이 도구가 무엇을, 어떻게 기억하게 해주는가”를 묻게 됩니다. 데이터베이스에 정교하게 담든 파일로 모델 밖에 두든, 그 선택이 곧 에이전트가 며칠 뒤에도 맥락을 이어갈 수 있을지를 가릅니다. 기억은 저절로 쌓이는 부산물이 아니라, 우리가 매번 내리는 작은 설계 결정의 합입니다.

참고자료: How to Build a Memory Your AI Agents Can Actually Reuse – Louis Bouchard