*이 장을 다 읽고 나면 알게 될 것: Agent의 기억이 왜 Agent의 정체성인지, 기억을 어떻게 저장하고 검색하고 잊게 만드는지, 그리고 개인 데이터를 다루는 Agent가 반드시 풀어야 할 프라이버시 문제가 무엇인지*
도입: 나를 기억하지 못하는 비서
2023년 가을, 나는 ChatGPT에게 같은 질문을 세 번 했다.
"지난주에 내가 물어본 반도체 공급망 보고서 정리해줘." ChatGPT는 매번 이렇게 답했다. "죄송하지만 이전 대화 내용에 접근할 수 없습니다." 세 번째에는 웃음이 나왔다. 그리고 곧 진지해졌다.
나는 수많은 비서, 조수, 주니어 컨설턴트와 일했다. 좋은 비서의 첫 번째 조건은 무엇인가. 일을 잘하는 것? 아니다. 나를 기억하는 것이다. 내가 어떤 보고서를 중요하게 봤는지, 어떤 고객사와 어떤 이슈가 있었는지, 어떤 표현을 싫어하는지. 이런 것을 기억하는 비서가 좋은 비서다. 기억 없이는 매번 처음부터 시작해야 한다.
AI Agent도 마찬가지다. 기억이 없는 Agent는 매번 낯선 사람을 만나는 것과 같다. 아무리 똑똑해도 쓸모가 제한된다. 반대로, 기억이 있는 Agent는 시간이 지날수록 나를 더 잘 안다. 내 맥락을 이해한다. 내 습관을 파악한다. 그것이 범용 챗봇과 개인 Agent의 결정적 차이다.
그런데 여기에 역설이 있다. Agent가 나를 더 잘 기억할수록, 나의 프라이버시는 더 위험해진다. 기억은 Agent의 힘이자 약점이다. 기억을 잘 설계하면 분신이 된다. 기억을 잘못 설계하면 감시자가 된다.
이 장에서는 그 둘 사이의 길을 찾는다.
12.1 기억은 Agent의 정체성이다
같은 LLM을 쓰더라도 Agent마다 다르다. 무엇이 그 차이를 만드는가. 프롬프트? 도구? 물론 중요하다. 그러나 가장 근본적인 차이는 기억이다.
비유를 들겠다. 쌍둥이를 생각해보자. 유전자가 같다. 뇌의 구조도 거의 같다. 그러나 20년을 다른 환경에서 살면 완전히 다른 사람이 된다. 왜? 기억이 다르기 때문이다. 겪은 일이 다르고, 배운 것이 다르고, 실패한 경험이 다르다. 기억이 정체성을 만든다.
Agent도 마찬가지다. 같은 GPT-4o 모델을 기반으로 만든 Agent라도, 내 3년치 대화 기록을 가진 Agent와 빈 상태의 Agent는 전혀 다르다. 전자는 내가 반도체 분석에 관심이 많다는 것을 안다. 내가 "그 건"이라고 하면 어떤 프로젝트를 말하는지 안다. 내가 보고서에서 표보다 서사를 좋아한다는 것을 안다. 후자는 이 모든 것을 처음부터 설명해야 한다.
그래서 Personal Memory는 개인 Agent 설계의 핵심이다. 9장에서 아키텍처를, 10장에서 기술 스택을, 11장에서 첫 구현을 다뤘다. 이 장에서는 그 Agent에 기억을 심는다. 기억 없는 Agent는 껍데기다. 기억이 있어야 비로소 분신이 된다.
잠시 멈추고 생각해보자
당신이 매일 쓰는 AI 도구는 당신을 기억하는가? 기억한다면 무엇을 기억하는가? 기억하지 못한다면 그 때문에 불편한 적이 있는가?
12.2 기억의 세 가지 종류
인간의 기억은 세 종류로 나뉜다. 심리학의 오래된 분류다. Agent의 기억도 이 분류를 따른다.
9장에서는 실용적 관점에서 사실 기억, 선호 기억, 에피소드 기억으로 나눴다. 여기서는 인지심리학의 전통적 분류를 따른다. 9장의 사실 기억은 의미적 기억에, 에피소드 기억은 일화적 기억에 대응한다.
첫째, 일화적 기억(Episodic Memory). 구체적인 사건의 기억이다. "2025년 3월 15일에 사용자가 삼성전자 HBM 공급 이슈에 대해 물어봤다." "지난주 수요일에 보고서 초안을 검토하면서 '이 부분은 너무 장황하다'고 말했다." 대화 기록, 요청 이력, 피드백 내용이 여기에 속한다. Agent가 "지난번에 이렇게 말씀하셨는데"라고 할 수 있는 것은 일화적 기억 덕분이다.
둘째, 의미적 기억(Semantic Memory). 사실과 지식의 기억이다. "사용자는 경제학자다." "사용자는 반도체 공급망에 관심이 많다." "사용자가 선호하는 보고서 형식은 결론 먼저, 근거 나중이다." 구체적 사건에서 추출된 일반화된 지식이다. 개별 대화를 다 기억하지 않아도 이 정보만 있으면 Agent는 맥락을 이해한다.
셋째, 절차적 기억(Procedural Memory). 행동 패턴의 기억이다. "사용자가 '정리해줘'라고 하면 표 형식으로 만들어야 한다." "이메일 초안을 쓸 때는 항상 인사말로 시작한다." "코드 리뷰를 요청하면 보안 이슈를 먼저 본다." 반복된 상호작용에서 학습된 행동 규칙이다.
이 세 가지가 어떻게 다른지 실제 예를 보자.
사용자가 "지난달 SK하이닉스 분석 다시 보여줘"라고 한다. Agent는 일화적 기억에서 해당 대화를 찾는다. "2025년 4월 12일 대화: SK하이닉스 HBM3E 양산 일정과 NVIDIA 납품 계약 분석." 이것을 찾아서 보여준다.
같은 사용자가 "반도체 보고서 하나 써줘"라고 한다. Agent는 의미적 기억에서 이 사용자의 관심사를 꺼낸다. "이 사용자는 메모리 반도체, 특히 HBM에 관심이 많다. 공급망 관점을 선호한다." 그래서 HBM 중심의 공급망 보고서를 쓴다. 파운드리 이야기부터 시작하지 않는다.
보고서를 다 쓰면 Agent는 절차적 기억을 따른다. "이 사용자는 보고서 끝에 항상 '핵심 시사점 3개'를 원한다. 표보다 문장을 선호한다." 그래서 자동으로 그 형식으로 마무리한다.
세 기억이 함께 작동할 때 Agent는 비로소 분신처럼 움직인다.
12.3 단기 기억과 장기 기억 — 컨텍스트 윈도우의 한계
기억에는 또 다른 축이 있다. 시간의 축이다.
단기 기억(Short-term Memory)은 현재 대화의 맥락이다. LLM의 컨텍스트 윈도우가 바로 이것이다. GPT-4o는 약 128K 토큰, Claude는 최대 1M 토큰의 컨텍스트 윈도우를 가진다. 이 안에 들어 있는 것은 기억한다. 밖에 있는 것은 모른다.
128K 토큰이면 꽤 많아 보인다. 영어 기준으로 책 한 권 분량이다. 그러나 Agent를 6개월 운영하면 대화 기록만 수백만 토큰이 된다. 컨텍스트 윈도우에 다 넣을 수 없다. 넣더라도 비용이 폭발한다. 넣더라도 정확도가 떨어진다. 긴 컨텍스트에서 LLM은 중간 부분을 잘 놓친다. "Lost in the Middle"이라고 불리는 현상이다.
그래서 장기 기억(Long-term Memory)이 필요하다. 장기 기억은 컨텍스트 윈도우 밖에 별도로 저장된다. 필요할 때만 꺼내서 컨텍스트 윈도우에 넣는다. 이것이 RAG(Retrieval-Augmented Generation)의 핵심 원리다. 11장에서 첫 Agent를 만들 때 이미 이 구조를 썼다.
장기 기억의 저장소는 벡터 데이터베이스다. 텍스트를 임베딩 모델로 벡터로 변환해서 저장한다. 검색할 때는 질문도 벡터로 변환해서 가장 유사한 벡터를 찾는다. 코사인 유사도(두 벡터가 가리키는 방향이 얼마나 비슷한지를 0에서 1 사이로 나타내는 수치)를 기준으로. 이것이 의미 기반 검색(Semantic Search)이다.
정리하면 이렇다. 단기 기억은 LLM의 컨텍스트 윈도우다. 빠르지만 용량이 제한된다. 장기 기억은 벡터 DB에 저장된 외부 기억이다. 용량은 사실상 무한하지만, 검색의 정확도가 관건이다. 좋은 Agent는 이 둘을 매끄럽게 연결한다.
잠시 멈추고 생각해보자
당신이 6개월간 Agent와 나눈 대화 중에서, 오늘 꺼내 쓸 만한 것은 몇 퍼센트나 될까? 나머지는 잊혀도 되는 것인가, 아니면 언젠가 필요할 수 있는 것인가?
12.4 기억의 저장 — pgvector, ChromaDB, Pinecone
장기 기억을 저장하는 벡터 데이터베이스는 여러 가지가 있다. 2025년 기준으로 가장 많이 쓰이는 세 가지를 비교한다.
pgvector. PostgreSQL의 확장이다. 기존 PostgreSQL에 벡터 저장과 검색 기능을 추가한 것이다. 가장 큰 장점은 익숙함이다. PostgreSQL을 쓰는 개발자라면 새로운 것을 배울 필요가 거의 없다. 일반 데이터와 벡터 데이터를 하나의 DB에서 관리할 수 있다. SQL로 벡터 검색을 할 수 있다. 온프레미스 설치가 자연스럽다. 단점은 대규모 벡터(수천만 건 이상)에서 전용 벡터 DB보다 느릴 수 있다는 것이다. 그러나 개인 Agent 수준에서는 충분하다.
ChromaDB. 오픈소스 벡터 데이터베이스다. 설치가 간단하고, Python과의 통합이 쉽다. 로컬에서 돌릴 수 있어 프라이버시에 유리하다. 프로토타이핑에 좋다. 단점은 대규모 운영 환경에서의 안정성이 아직 검증 중이라는 것이다. 개인 프로젝트나 소규모 서비스에 적합하다.
Pinecone. 완전 관리형 클라우드 벡터 DB다. 설치와 운영의 부담이 없다. 확장성이 뛰어나다. 대규모 서비스에 강하다. 단점은 비용이다. 그리고 데이터가 외부 클라우드에 저장된다. 개인의 기억 데이터를 외부 서버에 두는 것이 괜찮은가? 이 질문은 뒤에서 다시 다룬다.
나의 시스템에서 우리는 pgvector를 선택했다. 이유는 세 가지였다. 첫째, 이미 PostgreSQL을 쓰고 있었다. 사용자 정보, 분석 결과, 로그가 다 PostgreSQL에 있었다. 벡터만 따로 빼면 관리 포인트가 늘어난다. 둘째, 개인 데이터의 민감성 때문이었다. 나의 시스템의 기업정보 분석 시스템(SAF)은 고객사의 재무 데이터를 다룬다. 이 데이터가 외부 클라우드로 나가는 것은 고객이 원하지 않았다. 셋째, 개인 Agent 수준의 벡터 수(수십만 건)에서 pgvector의 성능은 충분했다. HNSW 인덱스를 쓰면 밀리초 단위로 검색된다.
선택은 상황에 따라 다르다. 중요한 것은 이것이다. 개인 Agent의 메모리 저장소를 고를 때, 성능보다 먼저 따져야 할 것은 데이터의 위치다. 내 기억이 어디에 저장되는가. 내 노트북인가, 회사 서버인가, 미국의 클라우드인가. 이 선택이 프라이버시의 출발점이다.
12.5 기억의 검색 — 임베딩과 유사도 검색
기억을 저장했으면 꺼내 써야 한다. 여기서 핵심은 임베딩(Embedding)이다.
임베딩이란 텍스트를 숫자 벡터로 바꾸는 것이다. "삼성전자 HBM 공급 이슈"라는 문장을 768차원(또는 1536차원)의 숫자 배열로 변환한다. 이 숫자 배열에는 문장의 의미가 담겨 있다. 비슷한 의미의 문장은 비슷한 벡터를 갖는다. "SK하이닉스 고대역폭메모리 납품 문제"도 비슷한 벡터를 갖는다. 키워드는 다르지만 의미가 비슷하기 때문이다.
검색은 이렇게 작동한다. 사용자가 "HBM 관련해서 내가 뭐 말한 적 있지?"라고 묻는다. 이 질문을 임베딩한다. 벡터 DB에서 이 벡터와 가장 유사한 벡터를 찾는다. 코사인 유사도가 0.85 이상인 것을 상위 5개 가져온다. 그것이 관련 기억이다.
좋은 검색을 위해 몇 가지 기법이 중요하다.
청킹(Chunking). 긴 대화를 적절한 단위로 자르는 것이다. 대화 전체를 하나의 벡터로 만들면 의미가 뭉개진다. 주제 단위로 자르면 검색 정확도가 올라간다. 보통 300~500 토큰 단위로 자르되, 의미가 끊기지 않도록 겹침(overlap)을 둔다.
메타데이터 필터링. 벡터 유사도만으로 검색하면 한계가 있다. "지난주에 말한 것"이라는 시간 조건은 벡터로 표현되지 않는다. 그래서 각 기억에 날짜, 주제, 대화 유형 같은 메타데이터를 함께 저장한다. 검색할 때 메타데이터로 먼저 범위를 좁히고, 그 안에서 벡터 유사도로 찾는다.
하이브리드 검색. 벡터 검색(의미 기반)과 키워드 검색(BM25 같은 전통 방식)을 결합하는 것이다. "NVIDIA"라는 고유명사를 찾을 때는 키워드 검색이 더 정확하다. "반도체 공급망의 구조적 변화"를 찾을 때는 벡터 검색이 더 정확하다. 둘을 합치면 더 좋다. pgvector와 PostgreSQL의 전문 검색(Full-Text Search)을 결합하면 이것이 가능하다.
검색의 정확도가 Agent의 품질을 결정한다. 아무리 많은 기억을 저장해도, 필요한 순간에 올바른 기억을 꺼내지 못하면 소용없다. 반대로 잘못된 기억을 꺼내면 Agent가 엉뚱한 맥락으로 답한다. 그래서 기억의 저장보다 기억의 검색이 더 어렵고 더 중요하다.
잠시 멈추고 생각해보자
당신의 머릿속에서 기억을 꺼내는 방식과, 벡터 DB에서 기억을 꺼내는 방식은 어떻게 다른가? 인간은 감정과 연결된 기억을 더 잘 떠올린다. Agent도 그래야 하는가?
12.6 기억의 망각 — 잊는 것도 설계해야 한다
인간은 잊는다. 그것은 버그가 아니라 기능이다.
모든 것을 기억하는 사람은 행복하지 않다. 러시아의 기억술사 솔로몬 셰레셰프스키(Solomon Shereshevsky)는 한 번 본 것을 절대 잊지 못했다. 그는 그 능력 때문에 고통받았다. 과거의 사소한 기억이 끊임없이 밀려들어 현재에 집중할 수 없었다. 잊는 것은 뇌의 핵심 기능이다. 중요한 것을 부각시키기 위해 중요하지 않은 것을 버린다.
Agent의 기억도 마찬가지다. 모든 대화를 영원히 저장하면 두 가지 문제가 생긴다.
첫째, 검색 품질이 떨어진다. 기억이 많아질수록 노이즈도 많아진다. 3년 전의 사소한 대화가 오늘의 검색 결과에 끼어든다. 관련 없는 기억이 관련 있는 기억을 밀어낸다.
둘째, 프라이버시 리스크가 커진다. 오래된 기억일수록 민감할 수 있다. 2년 전에 "이 고객사 재무 상태가 좀 위험해 보여"라고 한 말이 그대로 남아 있다면? 그 고객사가 지금은 회복했더라도, 과거의 기록이 유출되면 문제가 된다.
그래서 망각을 설계해야 한다. 몇 가지 전략이 있다.
시간 기반 만료. 일정 기간이 지나면 자동으로 삭제한다. 일화적 기억은 6개월, 의미적 기억은 2년, 절차적 기억은 갱신될 때까지 유지. 이런 식의 규칙을 둘 수 있다.
중요도 기반 유지. 자주 참조되는 기억, 사용자가 명시적으로 "기억해"라고 한 것, Agent의 핵심 행동을 결정하는 기억은 오래 유지한다. 한 번 나오고 다시 참조되지 않는 기억은 점진적으로 우선순위를 낮춘다.
요약 후 압축. 오래된 대화 기록을 그대로 저장하는 대신, 핵심만 요약해서 보관한다. "2024년 하반기에 사용자는 주로 자동차 산업 공급망을 분석했다. 특히 현대자동차의 전기차 전환 전략에 관심이 많았다." 이런 식으로 디테일은 버리고 의미만 남긴다. 인간의 뇌가 하는 것과 비슷하다.
사용자 주도 삭제. 사용자가 특정 기억을 지울 수 있어야 한다. "어제 대화 잊어줘", "이 고객사 관련 기록 전부 삭제해줘." 이것은 단순한 편의 기능이 아니다. 법적 권리다. 뒤에서 다룰 '잊힐 권리'와 직결된다.
12.7 프라이버시 — 가장 불편하지만 가장 중요한 질문
여기서부터가 이 장의 진짜 주제다.
Agent가 나를 잘 기억하려면 나의 데이터가 필요하다. 대화 기록, 문서, 이메일, 일정, 건강 정보, 재무 정보. 이 데이터를 많이 줄수록 Agent는 더 똑똑해진다. 그러나 이 데이터를 많이 줄수록 내 프라이버시는 더 취약해진다.
이것은 트레이드오프가 아니다. 풀어야 할 설계 문제다.
현실을 보자. 2025년 현재 대부분의 AI 서비스는 클라우드 기반이다. ChatGPT를 쓰면 대화가 OpenAI 서버에 저장된다. Claude를 쓰면 앤트로픽 서버에 저장된다. 구글 제미나이를 쓰면 구글 서버에 저장된다. 이 서버들은 대부분 미국에 있다.
솔직히 말하면, 나도 그렇게 쓴다. 나의 시스템의 내부 시스템을 설계할 때는 데이터 위치를 엄격하게 통제한다. 그러나 개인적으로 ChatGPT를 쓸 때는 편의에 밀려 그냥 쓴다. 대부분의 사람이 그렇다. 이것이 문제다.
개인 Agent는 일반 챗봇보다 훨씬 더 많은 데이터를 다룬다. 챗봇은 한 번의 대화만 본다. 개인 Agent는 수년간의 대화, 습관, 선호, 감정 패턴까지 축적한다. 이 데이터가 유출되면? 단순한 비밀번호 유출과 차원이 다르다. 디지털 자아가 통째로 노출되는 것이다.
그래서 개인 Agent를 설계할 때 프라이버시는 선택이 아니라 전제다.
12.8 온프레미스 vs 클라우드 — 데이터를 어디에 둘 것인가
프라이버시의 첫 번째 결정은 물리적 위치다.
온프레미스(On-Premises). 내 기기, 내 서버에서 모든 것을 처리한다. 데이터가 밖으로 나가지 않는다. 가장 안전하다. 그러나 제약이 크다. 강력한 LLM을 로컬에서 돌리려면 GPU가 필요하다. Qwen3-32B 같은 오픈소스 모델을 쓸 수 있지만, 성능은 GPT-4o에 미치지 못한다. 2026년 기준 그 격차는 줄어들고 있지만 여전히 존재한다.
클라우드. 외부 서버에서 처리한다. 강력한 모델을 쓸 수 있다. 관리 부담이 적다. 그러나 데이터가 밖으로 나간다. 그 서버가 어느 나라에 있는지, 누가 접근할 수 있는지, 얼마나 오래 보관되는지를 완전히 통제하기 어렵다.
하이브리드. 민감한 데이터는 로컬에서 처리하고, 덜 민감한 작업만 클라우드로 보낸다. 현실적인 절충안이다. 예를 들어, 기억의 저장과 검색은 로컬 pgvector에서 하고, 응답 생성만 클라우드 LLM을 쓴다. 이때 클라우드로 보내는 것은 검색 결과의 요약이지, 원본 데이터 전체가 아니다.
나의 시스템에서 우리가 택한 방식이 이 하이브리드다. 고객사의 원본 데이터는 절대로 외부 API로 보내지 않는다. pgvector에 저장된 벡터와 메타데이터는 자체 서버에 있다. LLM 호출 시에는 검색된 청크만 전달한다. 그것도 필요할 때는 민감 정보를 마스킹한 후 보낸다. 완벽하지는 않다. 그러나 현실적으로 가능한 최선이다.
개인 사용자라면 선택지는 더 단순해진다. 돈을 쓸 수 있다면 로컬 GPU(NVIDIA RTX 4090이나 5090)에 오픈소스 모델을 올려 완전 온프레미스로 갈 수 있다. 돈보다 편의를 원한다면 클라우드를 쓰되, 무엇이 어디로 가는지를 의식해야 한다. 중요한 것은 무의식적 선택을 하지 않는 것이다.
잠시 멈추고 생각해보자
당신의 Agent에 들어갈 데이터 중 가장 민감한 것은 무엇인가? 그것이 미국 서버에 저장되어도 괜찮은가? 만약 괜찮지 않다면, 성능의 어느 정도를 포기할 수 있는가?
12.9 법과 제도 — GDPR, 개인정보보호법, 그리고 잊힐 권리
기술만으로는 프라이버시를 지킬 수 없다. 법이 필요하다.
EU의 GDPR(General Data Protection Regulation)은 2018년에 시행된 개인정보 보호법이다. 전 세계 프라이버시 법의 기준이 되었다. 핵심 원칙은 간단하다. 개인 데이터의 주인은 본인이다. 기업은 그것을 빌려 쓰는 것이다. 그래서 본인이 요구하면 삭제해야 한다. 이동을 요구하면 옮겨줘야 한다. 동의 없이 쓸 수 없다.
한국의 개인정보보호법도 비슷한 방향이다. 2024년 개정을 거치면서 AI 시대에 맞게 보강되었다. 자동화된 의사결정에 대한 설명 요구권, 프로파일링 거부권 같은 조항이 추가되었다. 아직 GDPR만큼 강력하지는 않지만, 방향은 같다.
여기서 Agent 메모리와 직결되는 조항이 잊힐 권리(Right to be Forgotten)다. GDPR 제17조에 명시되어 있다. 개인은 자신의 데이터를 삭제해달라고 요청할 수 있다. 기업은 합리적 기간 내에 삭제해야 한다.
이것을 Agent 메모리에 적용하면 어떻게 되는가. 사용자가 "내 모든 대화 기록 삭제해줘"라고 하면 Agent는 그것을 실행할 수 있어야 한다. 벡터 DB에서 해당 벡터를 삭제해야 한다. 의미적 기억에서 추출된 사용자 프로필도 삭제해야 한다. LLM이 파인튜닝에 사용했다면? 그것은 더 복잡한 문제다. 모델에 이미 녹아든 데이터를 삭제하는 것은 현재 기술로는 쉽지 않다.
이것이 개인 Agent를 설계할 때 중요한 이유다. 기억의 구조가 삭제 가능하게 설계되어 있어야 한다. 처음부터 그렇게 만들어야 한다. 나중에 고치기는 매우 어렵다.
실무적으로 몇 가지 원칙이 있다.
첫째, 기억은 모듈화한다. 사용자별, 주제별, 기간별로 분리 저장해야 특정 부분만 삭제할 수 있다.
둘째, 원본과 파생물을 구분한다. 대화 원본, 그것에서 추출한 요약, 그것에서 학습된 프로필. 원본을 삭제할 때 파생물도 함께 삭제되어야 한다.
셋째, 삭제 로그를 남긴다. 무엇을 언제 삭제했는지의 기록은 남겨야 한다. 삭제 자체를 증명하기 위해서다. 역설적이지만 필요하다.
12.10 디지털 자아 — 기억이 곧 나다
이 장의 마지막 질문이다. Agent의 기억은 누구의 것인가.
단순한 질문 같지만, 깊이 들어가면 복잡해진다. Agent의 기억은 내 데이터에서 만들어졌다. 그러니 내 것이다. 그러나 그 기억을 구조화하고 검색 가능하게 만든 것은 기술이다. 기술을 제공한 회사는 그 구조에 대한 권리를 주장할 수 있는가? 임베딩 모델이 만든 벡터는 원본 텍스트와 같은 것인가, 다른 것인가?
이런 법적 논쟁은 아직 정리되지 않았다. 그러나 한 가지는 분명하다. 기술적으로 내 Agent의 기억을 내가 완전히 통제할 수 있어야 한다. 내보내기(export), 삭제, 이동이 자유로워야 한다. 특정 플랫폼에 잠기지 않아야 한다. 이것이 데이터 이동성(data portability)이다.
더 깊은 차원에서, 이 문제는 정체성의 문제다.
Agent가 3년간 나와 대화하면서 축적한 기억은 무엇인가. 내 관심사, 사고방식, 감정 패턴, 의사결정 습관의 기록이다. 그것은 사실상 디지털 자아다. 내가 어떤 사람인지를 데이터로 재구성한 것이다.
이 디지털 자아는 나보다 나를 더 잘 알 수 있다. 내가 어떤 주제에서 감정적이 되는지, 어떤 유형의 의사결정에서 실수를 반복하는지, 어떤 사람과의 대화에서 에너지를 얻는지. 나는 이런 패턴을 잘 모른다. 그러나 데이터는 안다.
그래서 Agent의 메모리 설계는 기술적 문제를 넘어선다. 내 디지털 자아를 어떻게 다룰 것인가의 문제다. 누구에게 보여줄 것인가. 어디에 저장할 것인가. 내가 죽으면 어떻게 될 것인가. 이 질문들은 아직 답이 없다. 그러나 Agent를 만드는 사람이라면 한 번은 마주해야 할 질문이다.
기억은 Agent의 기능이 아니다. 기억은 Agent의 존재다. 그리고 그 기억이 내 데이터로 만들어졌다면, 그것은 곧 나의 확장이다.
핵심 정리
Agent의 기억은 세 종류로 나뉜다. 일화적 기억(대화 기록), 의미적 기억(축적된 지식), 절차적 기억(행동 패턴). 세 기억이 함께 작동할 때 Agent는 분신이 된다.
기억은 단기와 장기로 나뉜다. 단기 기억은 LLM의 컨텍스트 윈도우이고, 장기 기억은 벡터 DB에 저장된다. pgvector, ChromaDB, Pinecone 같은 도구가 장기 기억의 저장소다. 선택의 기준은 성능보다 데이터의 위치다.
기억의 검색은 임베딩과 유사도 검색으로 이루어진다. 청킹, 메타데이터 필터링, 하이브리드 검색이 정확도를 높인다. 저장보다 검색이 더 어렵고 더 중요하다.
망각도 설계해야 한다. 시간 기반 만료, 중요도 기반 유지, 요약 후 압축, 사용자 주도 삭제. 모든 것을 영원히 기억하는 것은 좋은 설계가 아니다.
프라이버시는 Agent 메모리의 전제 조건이다. 온프레미스, 클라우드, 하이브리드 중 어떤 구조를 택하든 데이터의 위치와 통제권을 의식해야 한다. GDPR과 개인정보보호법의 잊힐 권리는 기억 구조가 삭제 가능하게 설계될 것을 요구한다.
Agent의 기억은 궁극적으로 디지털 자아다. 그것을 어떻게 설계하고 보호할 것인가는 기술을 넘어 정체성의 문제다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 Agent가 기억해야 할 가장 중요한 것은 무엇인가? 반대로, 절대 기억하면 안 되는 것은 무엇인가? 그 경계를 어떻게 정할 것인가?
질문 2. 3년간 축적된 Agent의 기억이 유출된다면, 당신의 삶에 어떤 영향이 있겠는가? 비밀번호 유출과 비교하면 그 심각성은 어느 정도인가?
질문 3. 성능이 20% 떨어지더라도 완전 온프레미스를 선택하겠는가, 아니면 편의와 성능을 위해 클라우드를 쓰겠는가? 그 판단의 기준은 무엇인가?
질문 4. 잊힐 권리를 Agent에 적용한다면, "이 대화 잊어줘"라고 했을 때 정말로 완전히 삭제되었는지를 어떻게 확인할 수 있는가? 확인할 수 없다면 그 권리는 실질적인가?
질문 5. 당신이 죽은 후 Agent의 기억은 어떻게 되어야 하는가? 삭제되어야 하는가, 가족에게 전달되어야 하는가, 아니면 디지털 유산으로 보존되어야 하는가?
더 깊이 탐구하기
엔델 털빙(Endel Tulving), 「Elements of Episodic Memory」 (1983). 일화적 기억과 의미적 기억의 구분을 처음 제안한 고전. Agent 메모리 설계의 이론적 뿌리.
Patrick Lewis 외, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」 (2020). RAG의 원논문. 장기 기억을 LLM에 연결하는 핵심 아이디어.
EU GDPR 제17조 원문과 해설. 잊힐 권리의 정확한 범위와 한계를 이해하기 위한 필수 자료.
개인정보보호위원회, 「AI 시대 개인정보 보호 가이드라인」 (2025). 한국의 AI 관련 개인정보 규제의 최신 방향.
pgvector 공식 문서 및 HNSW 인덱스 가이드. 개인 Agent의 장기 기억 저장소를 직접 구축할 때의 실무 참조.
다음 장에서는 Physical AI가 가정으로 들어오는 이야기를 한다. 시니어 케어 RC카 사례를 통해, 기억을 가진 Agent가 물리적 몸을 얻었을 때 무엇이 달라지는지를 본다.