4부 17장. 단기 메모리와 장기 메모리

지난 장에서 우리는 상태를 두 종류로 나눴다. 지금 이 대화를 붙잡는 세션 상태와 하나의 일을 끝까지 끌고 가는 작업 상태였다. 이번 장에서는 그와 비슷해 보이지만 다른 질문을 다룬다. 바로 무엇을 얼마나 오래, 어떤 방식으로 기억할 것인가다.

에이전트를 만들다 보면 금방 이런 유혹에 빠진다. "일단 다 저장하자. 많이 저장하면 똑똑해지겠지." 얼핏 맞는 말처럼 들린다. 하지만 현실은 정반대인 경우가 많다. 너무 많이 저장하면 오히려 중요한 것이 묻히고, 오래전에 했던 말이 현재 의도처럼 튀어나오고, 사용자의 취향과 회사 문서와 방금 전 도구 결과가 한데 뒤섞여 시스템이 혼란스러워진다.

좋은 메모리 설계는 많이 저장하는 기술이 아니라 다르게 저장하는 기술이다. 방금 필요한 것은 책상 위에 올려두고, 오래 기억할 것은 정리해서 서랍에 넣고, 원래부터 방대한 지식은 도서관에서 찾아오게 해야 한다. 책상, 서랍, 도서관이 다 같은 역할을 하면 일이 꼬인다.

이번 장에서는 이 세 가지를 분명히 구분해 보겠다. 작업 중 기억으로서의 단기 메모리, 사용자별로 축적되는 장기 메모리, 그리고 문서와 데이터로 이루어진 외부 지식 저장소다. 이 셋의 경계를 이해하면, 에이전트는 덜 수다스럽고 더 일 잘하는 시스템으로 바뀐다.

메모리는 상태와 어떻게 다를까

먼저 헷갈리기 쉬운 지점부터 정리하자. 상태와 메모리는 겹치는 부분이 있지만 같은 말은 아니다.

상태는 대개 현재 시스템이 움직이기 위해 필요한 값에 가깝다. 세션 상태는 지금 무슨 대화를 하고 있는지, 작업 상태는 일이 어디까지 왔는지를 붙잡는다. 반면 메모리는 앞으로의 판단에 도움이 되도록 남겨 두는 정보에 더 가깝다.

예를 들어 사용자가 방금 "표로 보여 달라"고 말했다면, 그것은 현재 세션 상태이기도 하다. 그런데 그 사용자가 늘 표 형식을 선호하고, 여러 세션에 걸쳐 일관되게 그렇게 요청한다면, 그때부터는 장기 메모리 후보가 된다. 또 현재 작업에서 방금 API 호출이 실패했고 재시도가 필요하다는 것은 작업 상태다. 하지만 그 실패 로그 전체를 영원히 장기 메모리로 남길 필요는 없을 수 있다.

즉, 상태는 지금 시스템이 돌아가기 위한 진실이고, 메모리는 앞으로 더 잘 행동하기 위해 남기는 흔적이다. 둘은 만날 수 있지만, 저장 기준은 같지 않다.

단기 메모리: 지금 이 일을 하기 위해 붙잡는 기억

단기 메모리는 에이전트가 현재 맥락을 놓치지 않도록 붙잡는 작업 중 기억이다. 사람으로 치면 책상 위 메모지와 비슷하다. 지금 당장 써야 하니 가까운 곳에 두지만, 일이 끝나면 대부분 버리거나 요약해서 남긴다.

단기 메모리에는 보통 이런 정보가 들어간다.

• 최근 대화의 핵심 요약

• 현재 목표와 하위 목표

• 아직 해결되지 않은 질문

• 방금 실행한 도구의 결과 요약

• 중간 추론에서 확정된 사실과 보류 중인 가설

• 다음 행동 후보와 선택 이유

여기서 중요한 것은 원본을 길게 쌓는 것보다 현재 행동에 필요한 형태로 압축하는 것이다. 예를 들어 사용자가 열 번에 걸쳐 요구를 조금씩 바꿨다고 하자. 단기 메모리가 그 열 번의 문장을 다 들고 있을 필요는 없다. 대신 "최종 요구: 보고서는 1페이지, 경영진용 톤, 리스크 중심, 이메일 전송은 보류"처럼 현재 유효한 결론만 붙잡는 편이 훨씬 낫다.

단기 메모리는 오래 살 필요가 없다. 오히려 너무 오래 살면 문제를 만든다. 어제 회의에서 쓰던 제약이 오늘 작업에도 잘못 적용될 수 있고, 이미 폐기한 가설이 사실처럼 남아 모델을 끌고 갈 수도 있다. 그래서 단기 메모리는 짧게 살고 자주 갱신되며, 필요하면 과감히 버려져야 한다.

장기 메모리: 사용자와의 관계에서 천천히 쌓이는 기억

장기 메모리는 여러 세션과 여러 작업을 넘어 유지할 가치가 있는 정보다. 여기서 핵심은 "오래 남는다"가 아니라 "다음에도 다시 도움이 된다"이다.

대표적인 예는 사용자별 선호도다. 어떤 사용자는 답변을 짧게 원하고, 어떤 사용자는 근거와 반례까지 길게 보고 싶어 한다. 어떤 사용자는 늘 한국어로 답변받기를 원하고, 어떤 사용자는 코드 예제를 파이썬으로 받기를 좋아한다. 이런 정보는 한 번 알고 끝나는 것이 아니라, 이후 상호작용 전반을 매끄럽게 만든다.

장기 메모리에는 대체로 다음과 같은 정보가 어울린다.

• 반복적으로 확인된 사용자 선호도

• 장기간 유지되는 제약 조건

• 자주 수행하는 작업 패턴

• 사용자 조직, 팀, 역할처럼 비교적 안정적인 배경 정보

• 여러 번의 상호작용에서 드러난 목표나 관심사

하지만 여기서 꼭 조심해야 한다. 장기 메모리는 편리하다고 해서 아무 말이나 저장하는 창고가 아니다. 사용자가 한 번 기분 내켜서 "오늘은 길게 써 줘"라고 말한 것을 영구 선호로 저장하면 오히려 성가셔진다. 장기 메모리는 일시적 발화가 아니라 반복적으로 검증된 성향을 저장해야 한다.

그래서 장기 메모리의 기본 원칙은 보수적이어야 한다. 쉽게 쓰고, 잘못 저장하면 오래 고생한다. 차라리 한 번 덜 저장하는 편이, 한 번 잘못 저장해서 계속 엉뚱한 답을 하는 것보다 낫다.

외부 지식 저장소: 기억이 아니라 찾아보는 지식

이 지점에서 가장 흔한 오해가 나온다. 회사 문서 수천 건, 위키, 매뉴얼, 제품 사양서, 법규 문서, 고객 이력 데이터 같은 것을 전부 "메모리"라고 부르는 경우다. 엄밀히 말하면 이것은 메모리라기보다 외부 지식 저장소에 가깝다.

장기 메모리가 "이 사용자는 어떤 사람인가"를 붙잡는다면, 외부 지식 저장소는 "세상과 조직에 어떤 정보가 있는가"를 담는다. 둘은 전혀 다른 층위다.

예를 들어 고객 지원 에이전트를 생각해 보자. 사용자가 환불 정책을 물어볼 때 필요한 것은 사용자 선호를 기억하는 장기 메모리가 아니라, 최신 환불 정책 문서를 조회하는 외부 지식 저장소다. 반대로 같은 사용자가 늘 답변을 표로 정리해 달라고 요청한다면, 그것은 지식 저장소가 아니라 장기 메모리 쪽에 더 가깝다.

외부 지식 저장소를 메모리와 구분해야 하는 이유는 간단하다. 이 정보는 대개

• 양이 매우 많고,

• 시간이 지나며 바뀌고,

• 출처와 버전이 중요하며,

• 사용자 개인이 아니라 조직 전체의 사실인 경우가 많기 때문이다.

즉, 장기 메모리는 에이전트가 사용자를 점점 더 잘 대하기 위해 갖는 기억이고, 외부 지식 저장소는 필요할 때 조회하는 업무용 참고 자료다. 하나는 관계의 축적이고, 다른 하나는 사실의 조회다.

셋을 섞으면 왜 문제가 생길까

책상 메모지, 개인 노트, 도서관 책장을 하나의 통에 넣어 보자. 찾을 수만 있다면 괜찮을 것 같지만, 실제로는 매번 뒤적이다 지쳐 버린다. 에이전트도 똑같다.

단기 메모리, 장기 메모리, 외부 지식 저장소를 섞으면 세 가지 문제가 생긴다.

첫째, 우선순위가 무너진다. 방금 수정된 사용자 요구와 오래된 문서 조각이 같은 무게로 들어오면, 모델은 무엇이 현재 행동의 기준인지 판단하기 어려워진다.

둘째, 오래된 정보가 현재를 오염시킨다. 몇 달 전 사용자의 임시 요청이 영구 선호처럼 남거나, 예전 버전 정책 문서가 최신 규칙처럼 섞여 들어올 수 있다.

셋째, 검색 비용이 커진다. 아무 정보나 다 같은 저장소에 넣으면, 필요한 순간에 꺼내는 것도 느려지고 부정확해진다. 많이 저장한 대가를 검색 단계에서 비싸게 치르는 셈이다.

좋은 시스템은 많이 기억하는 시스템이 아니라, 기억할 대상에 따라 저장소와 검색 전략을 바꾸는 시스템이다.

단기 메모리 저장 전략: 살아 있는 맥락만 남겨라

단기 메모리는 현재 작업을 잘 수행하기 위한 기억이므로, 저장 전략도 가볍고 민첩해야 한다. 핵심은 최근성과 행동 가능성이다.

가장 실용적인 방식은 단기 메모리를 세 층으로 나누는 것이다.

• 최근 대화 원문 일부

• 최근 맥락을 압축한 요약

• 현재 작업용 스크래치패드

최근 대화 원문은 말 그대로 가장 가까운 몇 턴의 대화를 보존하는 층이다. 사용자가 방금 어떤 표현으로 정정했는지, 바로 직전 질문이 무엇이었는지 같은 미묘한 뉘앙스는 요약만으로 사라질 수 있으므로 일정량의 원문은 필요하다.

그 위에는 요약층이 있다. 대화가 길어질수록 모든 원문을 유지할 수는 없으니, 현재 유효한 제약과 목표를 압축해 둔다. 이 요약은 단순한 줄거리 요약이 아니라, 다음 행동에 필요한 결정사항 요약이어야 한다.

마지막으로 스크래치패드는 작업용 임시 메모다. 예를 들어 "데이터셋 A는 이미 읽음", "고객명 표기는 영문으로 통일", "다음 단계는 3분기 수치 검증" 같은 정보가 들어간다. 이 영역은 가장 쉽게 바뀌고, 가장 쉽게 버려져야 한다.

단기 메모리에서는 무엇을 저장하느냐만큼 언제 지우느냐도 중요하다. 작업이 끝났는데도 임시 판단을 남겨 두면, 다음 작업에서 유령처럼 따라온다. 그래서 단기 메모리에는 만료 시점이 필요하다. 세션 종료, 작업 완료, 일정 시간 경과 같은 조건을 기준으로 자동 정리하는 편이 좋다.

장기 메모리 저장 전략: 사실보다 패턴, 패턴보다 검증

장기 메모리는 단기 메모리보다 훨씬 더 신중하게 써야 한다. 여기서의 실수는 오래 간다. 그래서 장기 메모리의 저장 기준은 "흥미롭다"가 아니라 "반복적으로 유용하다"여야 한다.

실무에서는 장기 메모리를 대개 세 갈래로 생각하면 편하다.

• 선호도 메모리: 답변 길이, 언어, 형식, 톤, 자주 쓰는 도구나 출력 방식

• 프로필 메모리: 소속 팀, 직무, 주요 관심 분야, 자주 다루는 업무 영역

• 관계 메모리: 어떤 프로젝트를 오래 진행 중인지, 어떤 사람들과 협업하는지처럼 상호작용 맥락을 안정적으로 이해하는 데 필요한 정보

이때 저장 규칙이 중요하다. 예를 들어 "항상 표를 좋아함" 같은 선호는 한 번의 요청이 아니라 여러 번의 반복에서 추출하는 편이 안전하다. 반대로 사용자가 명시적으로 "앞으로는 항상 한국어로 답해 줘"라고 말한 경우처럼, 강한 선언은 즉시 장기 메모리 후보가 될 수 있다.

장기 메모리에 잘 맞는 저장 규칙은 보통 이렇다.

• 일회성 지시보다 반복 패턴을 우선한다.

• 추측보다 사용자가 명시한 사실을 우선한다.

• 민감한 정보는 더 엄격한 기준과 동의를 거친다.

• 충돌하는 새 정보가 오면 덮어쓰지 말고 검증 단계를 둔다.

한마디로 장기 메모리는 많이 쓰는 노트가 아니라, 검증된 카드만 꽂아 두는 카드함에 가깝다.

외부 지식 저장소 저장 전략: 많이 넣되, 잘 쪼개고 잘 라벨링하라

외부 지식 저장소는 오히려 장기 메모리와 반대로 생각해야 한다. 장기 메모리는 적게, 엄격하게 저장하는 편이 좋지만, 외부 지식 저장소는 필요한 자료를 넓게 담을 수 있다. 다만 그냥 쑤셔 넣으면 안 된다. 검색 가능한 구조로 넣어야 한다.

여기서 중요한 것은 세 가지다.

첫째, 문서를 적절한 단위로 나누는 것이다. 너무 크게 넣으면 검색은 되었는데 필요한 대목을 찾기 어렵고, 너무 잘게 쪼개면 문맥이 끊어진다. 적당한 조각으로 나누고, 문서 제목, 섹션, 버전, 작성일 같은 메타데이터를 함께 붙여야 한다.

둘째, 출처와 권한을 분명히 해야 한다. 같은 회사 문서라도 누구나 볼 수 있는 자료와 일부 팀만 봐야 하는 자료가 있다. 검색 결과가 잘 나오는 것보다 먼저 중요한 것은 봐도 되는 정보만 보이게 하는 것이다.

셋째, 최신성 관리가 필요하다. 환불 정책이 바뀌었는데 옛 문서와 새 문서가 함께 남아 있다면, 검색 결과는 그럴듯해 보여도 답은 틀릴 수 있다. 외부 지식 저장소는 저장보다 갱신과 폐기가 더 중요할 때가 많다.

즉, 외부 지식 저장소의 핵심은 기억력이 아니라 색인력이다. 많이 아는 것이 아니라, 필요할 때 맞는 문서를 정확히 꺼내는 능력이 중요하다.

검색 전략: 무엇을 언제 꺼낼 것인가

저장은 절반이고, 나머지 절반은 검색이다. 같은 정보라도 언제 어떻게 꺼내느냐에 따라 성능이 크게 달라진다.

단기 메모리는 검색이 가장 단순하다. 현재 세션과 현재 작업에 묶인 정보를 우선 가져오면 된다. 여기서는 복잡한 의미 검색보다도 현재성이 더 중요하다. 가장 최근 요약, 아직 미해결인 질문, 방금 도구가 돌려준 결과처럼 지금 바로 행동에 영향을 주는 정보가 우선이다.

장기 메모리는 조금 다르다. 여기서는 사용자 ID만으로 다 가져오면 안 된다. 사용자가 가진 모든 선호와 모든 배경 정보를 한꺼번에 넣으면 오히려 답변이 무거워진다. 따라서 현재 요청과 관련 있는 장기 메모리만 골라야 한다. 예를 들어 사용자가 코드 리뷰를 요청했다면, "짧은 답을 선호함"이나 "파이썬 예제를 좋아함" 같은 정보는 유용하지만, "마케팅 팀 소속"은 별 도움이 되지 않을 수 있다.

외부 지식 저장소는 주제와 키워드, 메타데이터 필터, 권한 조건을 함께 써야 한다. 질문이 "우리 회사 환불 정책"인지 "내 주문의 환불 가능 여부"인지에 따라 가져와야 할 정보가 다르다. 전자는 정책 문서, 후자는 정책 문서와 함께 주문 데이터가 필요하다. 즉, 외부 지식 검색은 단어 맞추기보다 질문이 요구하는 사실의 종류를 맞추는 일이다.

실무에서는 검색 판단을 이렇게 단순화해 볼 수 있다.

• 지금 대화의 맥락이 필요한가? 단기 메모리부터 본다.

• 이 사용자의 습관이나 선호가 필요한가? 장기 메모리를 본다.

• 문서, 규정, 데이터, 제품 정보가 필요한가? 외부 지식 저장소를 본다.

이 순서가 중요한 이유는, 많은 실패가 사실 정보 부족이 아니라 메모리와 지식의 오용에서 나오기 때문이다. 문서가 필요한 질문에 사용자 선호를 끌어오거나, 사용자 취향이 필요한 순간에 정책 문서를 들이밀면 답변은 길어지기만 하고 맞지 않게 된다.

메모리 쓰기 정책: 모든 대화를 저장하지 마라

에이전트 시스템에서 가장 위험한 설계 중 하나는 "대화가 끝날 때마다 전부 장기 메모리에 넣기"다. 이것은 기억력이 좋은 것이 아니라 정리정돈이 안 되는 것이다.

메모리를 쓸 때는 적어도 네 가지 질문을 먼저 던져야 한다.

• 이 정보가 다음 상호작용에도 다시 유용한가

• 지금만 유효한 임시 지시가 아닌가

• 사용자가 명시했거나 반복적으로 드러난 사실인가

• 잘못 저장했을 때 피해가 큰 정보는 아닌가

예를 들어 사용자가 "오늘은 회의가 많으니 아주 짧게"라고 말한 것은 단기 메모리에는 중요하지만 장기 메모리에는 아직 이르다. 반면 "앞으로 코드 예시는 항상 타입스크립트로 보여 줘"처럼 지속 의도가 분명한 말은 장기 메모리 후보가 된다.

또 한 가지 중요하다. 장기 메모리는 업데이트가 필요하다. 사람은 바뀐다. 예전에는 영어 답변을 선호했지만, 지금은 팀 전체 공유를 위해 한국어를 더 원할 수도 있다. 따라서 장기 메모리는 비석이 아니라 최신판 프로필이어야 한다. 새 정보가 들어오면 즉시 덮어쓰기보다, 충돌 여부를 확인하고 최근성과 명시성을 반영해 갱신하는 편이 좋다.

메모리 품질은 저장량이 아니라 선별력에서 나온다

좋은 메모리 시스템을 만든다는 것은 커다란 창고를 짓는 일이 아니다. 사실 더 어려운 일은 무엇을 버릴지 결정하는 일이다.

단기 메모리에서는 이미 해결된 질문, 폐기된 가설, 의미 없는 중간 로그를 버려야 한다. 장기 메모리에서는 일시적 감정, 농담, 우연한 표현 습관을 버려야 한다. 외부 지식 저장소에서는 낡은 버전, 중복 문서, 권한 없는 자료를 걸러야 한다.

정리하면 이렇다. 단기 메모리는 현재 행동을 위한 압축, 장기 메모리는 반복 관계를 위한 검증된 축적, 외부 지식 저장소는 사실 조회를 위한 구조화된 보관이다. 셋 모두 저장이 필요하지만, 저장 철학은 서로 다르다.

자주 하는 실수

메모리 설계에서 반복해서 등장하는 실수는 의외로 비슷하다.

첫째, 단기 메모리를 대화 원문 보관소로 착각하는 경우다. 원문이 너무 많으면 지금 중요한 것이 보이지 않는다.

둘째, 장기 메모리를 사용자 로그 보관함처럼 쓰는 경우다. 사용자의 모든 말을 기억하는 것은 친절해 보이지만, 실제로는 불쾌하고 부정확해지기 쉽다.

셋째, 외부 지식 저장소를 장기 메모리처럼 다루는 경우다. 회사 정책 문서는 사용자 취향이 아니므로, 기억이 아니라 조회와 버전 관리의 문제로 풀어야 한다.

넷째, 검색 단계에서 욕심을 부리는 경우다. 불안하니까 단기 메모리도 넣고, 장기 메모리도 넣고, 문서도 왕창 넣는다. 그러면 모델은 배부르지만 판단은 흐려진다.

메모리는 많이 먹인다고 똑똑해지지 않는다. 오히려 딱 필요한 만큼만 먹였을 때 더 분명하게 행동한다.

하나의 요청을 세 저장소로 나눠 보기

예를 들어 사용자가 이렇게 말했다고 하자.

"지난 분기 영업 보고서 초안 만들어 줘. 나는 요약을 먼저 보고 싶고, 숫자는 표로 정리해 줘. 참고로 우리 팀은 보통 한국어 보고서를 써."

이때 단기 메모리에는 현재 작업 목표, 이번 초안의 요구 형식, 먼저 보여 줄 요약, 숫자 표 정리 같은 현재 지시가 들어간다. 이건 지금 보고서를 만들기 위한 기억이다.

장기 메모리 후보는 무엇일까. 사용자가 여러 번 비슷하게 요청해 왔다면 "숫자는 표로 선호함", "한국어 보고서 선호" 같은 것이 남을 수 있다. 하지만 이번 한 번만으로는 아직 후보일 뿐일 수 있다.

외부 지식 저장소에서는 지난 분기 매출 데이터, 영업 실적 문서, 기존 보고서 템플릿, 팀 내 표준 용어집을 조회해야 한다. 이건 사용자 기억이 아니라 업무 사실이다.

같은 한 문장도 이렇게 셋으로 나누면 설계가 명확해진다. 지금 필요한 것, 나중에도 유용한 것, 필요할 때 찾아와야 할 것이 서로 달라진다.

결국 메모리는 '더 많이'가 아니라 '더 다르게'다

에이전트 설계에서 메모리를 이야기하면 사람들은 종종 저장 용량부터 떠올린다. 하지만 실제로 시스템의 품질을 가르는 것은 용량보다 분류다. 무엇이 지금만 필요한 단기 메모리인지, 무엇이 사용자와의 관계 속에서 남을 장기 메모리인지, 무엇이 문서와 데이터로 관리되어야 할 외부 지식 저장소인지 구분할 수 있어야 한다.

이 구분이 서면 설계가 훨씬 단단해진다. 현재 작업은 가볍고 빠르게 움직일 수 있고, 사용자 경험은 점점 개인화될 수 있으며, 사실 정보는 최신 문서와 데이터에서 안정적으로 가져올 수 있다. 반대로 이 구분이 없으면 에이전트는 모든 것을 기억하려다 정작 필요한 순간에 헷갈리는 시스템이 된다.

좋은 에이전트는 기억력이 좋은 시스템이 아니다. 지금 붙잡을 것, 오래 남길 것, 필요할 때 찾아볼 것을 구분하는 시스템이다. 메모리 설계의 핵심은 저장량이 아니라 저장 방식에 있다. 그리고 그 차이를 이해하는 순간, 에이전트는 단순한 대화 기계를 넘어 훨씬 더 믿을 만한 작업 시스템이 된다.