메모리와 상태 설계

AI 에이전트에게 메모리를 준다는 말은, 단순히 "더 많이 기억하게 하자"는 뜻이 아니다. 진짜 질문은 따로 있다. 이 에이전트가 무엇을 잊지 말아야 하며, 무엇은 과감히 잊어도 되는가 하는 질문이다. 사람도 머릿속에 모든 일을 다 넣고 살지 않는다. 당장 처리할 일은 책상 위에 두고, 자주 쓰는 지식은 서랍에 넣고, 끝난 일은 문서함으로 보낸다. 에이전트의 메모리와 상태 설계도 이와 비슷하다. 정리가 안 된 기억은 똑똑함이 아니라 잡음이 된다.

이 장에서는 단기 기억, 장기 기억, 작업 상태를 구분하고, 무엇을 저장하고 무엇을 버릴지에 대한 판단 기준을 정리해본다. 핵심은 간단하다. 기억은 많을수록 좋은 것이 아니라, 오염되지 않고 다시 찾을 수 있어야 가치가 있다.

메모리와 상태는 같은 것이 아니다

많은 팀이 에이전트를 만들면서 대화 기록, 사용자 정보, 진행 중인 작업 정보를 한 바구니에 넣어버린다. 그러면 처음에는 편해 보이지만, 시간이 갈수록 문제가 생긴다. 에이전트가 예전 대화의 분위기와 오늘 해야 할 실제 작업 단계를 구분하지 못하고, 이미 끝난 일과 아직 처리해야 할 일을 섞어버리기 때문이다.

메모리와 상태는 비슷해 보이지만 역할이 다르다.

메모리는 "무엇을 알고 있는가"에 가깝고, 상태는 "지금 무엇을 하고 있는가"에 가깝다. 이 둘을 구분하지 않으면, 에이전트는 기억은 많은데 일은 못하는 상태가 된다. 마치 메모장은 가득한데 할 일 체크박스는 비어 있는 사람과 비슷하다.

단기 기억: 지금 일하기 위해 잠깐 쥐고 있는 것

단기 기억은 현재 작업의 작업대 위에 올려둔 재료다. 지금 막 받은 지시, 최근 대화 맥락, 직전에 검색한 결과, 직전 단계의 출력처럼 당장 이어서 처리할 때만 필요한 정보가 여기에 들어간다.

예를 들어 일정 관리 에이전트가 "다음 주 화요일 오후에 가능한 회의 시간을 찾아줘"라는 요청을 받았다고 하자. 이때 단기 기억에는 다음과 같은 정보가 들어갈 수 있다.

• 사용자가 원하는 주간 범위

• 현재 확인 중인 캘린더 후보 시간

• 방금 조회한 참석자들의 가능 시간

• 아직 확정되지 않은 임시 제안안

이 정보는 중요하지만 영구 보관할 필요는 없다. 오히려 오래 들고 있으면 문제가 된다. 지난주 회의 후보 시간이 이번 주 작업에 끼어들어 잘못된 제안을 만들 수도 있기 때문이다.

단기 기억 설계에서 중요한 것은 용량보다 정리 방식이다. 에이전트가 최근 대화 전체를 무조건 길게 들고 있기보다는, 현재 작업과 관련된 핵심만 압축해서 들고 있어야 한다. 단기 기억은 풍부해야 하지만, 느슨하면 안 된다.

장기 기억: 다시 쓸 가치가 있는 것만 남긴다

장기 기억은 에이전트가 시간이 지나도 유지할 가치가 있는 정보다. 여기서 중요한 단어는 "오래"가 아니라 "가치"다. 오래 남길 수 있어도 쓸모가 없으면 장기 기억이 아니다.

장기 기억의 대표적인 예는 다음과 같다.

• 사용자의 안정적인 선호

• 팀이나 조직의 고정된 규칙

• 반복적으로 쓰는 워크플로 설정

• 도메인별 용어집과 문서 링크

• 특정 작업에서 검증된 성공 패턴

반대로 오늘 기분이 별로라는 말, 방금 작성하다가 취소한 초안, 확인되지 않은 추측은 장기 기억이 되기 어렵다. 이런 정보는 나중에 재사용될 가능성보다 오해를 만들 가능성이 더 크다.

장기 기억은 "많이 저장하는 창고"가 아니라 "신뢰할 수 있는 재사용 자산"이어야 한다. 창고에 물건을 무작정 쌓아두면 찾기도 어렵고, 낡은 물건이 새 작업을 방해한다. AI 에이전트도 마찬가지다. 오래 보관하는 정보일수록 더 엄격하게 저장해야 한다.

작업 상태: 기억보다 더 중요한 실행 좌표

실무에서 더 자주 문제를 일으키는 것은 메모리 부족보다 상태 관리 부실이다. 에이전트가 무엇을 알고 있느냐보다, 지금 어디까지 했는지를 모르면 작업이 꼬인다.

작업 상태는 현재 진행 중인 프로세스의 좌표다. 예를 들어 리서치 에이전트가 보고서를 만드는 경우를 생각해보자. 이 에이전트는 다음과 같은 상태를 가져야 한다.

• 질문 정의 완료

• 자료 수집 진행 중

• 출처 검증 대기

• 초안 작성 완료

• 사용자 승인 대기

• 최종 요약 발송 완료

이 정보는 장기 기억과 다르다. 장기 기억은 "이 사용자는 항상 출처를 표시한 답변을 선호한다"일 수 있고, 작업 상태는 "현재 보고서는 아직 출처 검증이 끝나지 않았다"다. 둘은 모두 중요하지만 쓰임새가 완전히 다르다.

상태가 없으면 에이전트는 쉽게 같은 일을 반복한다. 이미 보낸 이메일을 또 보내거나, 끝난 분석을 다시 시작하거나, 승인 없이 다음 단계로 넘어가는 일이 생긴다. 반대로 상태가 분명하면 에이전트는 스스로 멈출 수 있다. "여기까지는 했고, 여기서부터는 승인이 필요합니다"라고 말할 수 있게 된다.

대화 기록과 업무 상태를 섞지 말라

에이전트 시스템에서 자주 보는 실수 중 하나는 대화 기록을 곧바로 상태 저장소처럼 사용하는 것이다. 대화는 자연스럽고 읽기 쉽지만, 실행 상태를 정확하게 표현하기에는 불안정하다.

예를 들어 사용자가 "일단 초안만 만들어줘"라고 말했다가, 잠시 후 "아니, 먼저 자료를 더 찾아보자"라고 바꿨다고 하자. 이 변화가 대화에는 남아 있지만, 시스템이 이를 구조화된 상태로 정리하지 않으면 에이전트는 이전 지시와 최신 지시를 혼동할 수 있다.

대화 기록은 맥락을 풍부하게 만들지만, 업무 상태는 구조적으로 관리해야 한다. 대화가 소설이라면 상태는 체크리스트다. 둘 다 필요하지만, 체크리스트 없이 소설만 읽으며 일을 진행하면 실수가 늘어난다.

실전에서는 대체로 다음처럼 나누는 편이 좋다.

• 대화 기록: 사용자의 표현, 설명, 뉘앙스, 추가 요청

• 작업 상태: 단계, 입력값, 중간 결과, 승인 여부, 실패 원인

• 장기 기억: 선호, 정책, 반복 규칙, 검증된 사실

이 구분이 되면 에이전트는 훨씬 덜 헷갈린다. 사용자가 농담한 내용은 대화에 남고, 오늘 작업의 진행률은 상태에 남고, 다음에도 계속 적용될 선호는 장기 기억으로 승격된다.

무엇을 저장할 것인가

저장 여부를 결정할 때는 "기억할 수 있는가"보다 "기억해야 하는가"를 먼저 따져야 한다. 판단 기준은 생각보다 단순하다.

첫째, 다시 쓸 가능성이 있어야 한다. 한 번 쓰고 끝나는 정보는 대개 장기 기억이 아니라 작업 중간값에 가깝다.

둘째, 의사결정에 영향을 주는 정보여야 한다. 에이전트의 행동을 앞으로도 바꿀 수 있는 정보라면 저장 가치가 있다. 예를 들어 사용자가 "나는 요약보다 원문 링크를 먼저 보여주는 형식을 선호한다"고 말했다면, 이는 다음 응답 방식에 직접 영향을 준다.

셋째, 다시 계산하기 어려운 정보일수록 저장 가치가 커진다. 쉽게 다시 검색할 수 있는 정보보다, 사람이 승인한 결과나 사용자가 명시한 선호처럼 재수집 비용이 높은 정보가 더 중요하다.

넷째, 출처와 시점이 분명한 정보가 더 안전하다. 누가 언제 제공했는지 모르는 정보는 장기 기억으로 남길수록 위험해진다.

다섯째, 개인정보와 민감도를 고려해야 한다. 유용하다고 해서 모두 저장할 수는 없다. 저장의 이익보다 보안과 프라이버시 위험이 크다면 저장하지 않는 편이 맞다.

이 기준으로 보면, 좋은 메모리 설계는 사실 저장 기술보다 편집 기술에 가깝다. 무엇을 남길지보다 무엇을 남기지 않을지 결정하는 능력이 더 중요하다.

무엇을 버릴 것인가

버리는 설계는 종종 저장 설계보다 더 중요하다. 에이전트가 실패하는 많은 이유는 잊지 않아서가 아니라, 잊어야 할 것을 계속 들고 있기 때문이다.

다음 정보는 대체로 장기 저장에 신중해야 한다.

• 일시적인 감정 표현이나 분위기 정보

• 확인되지 않은 추측과 임시 해석

• 오래된 사실 정보와 만료된 작업 맥락

• 중복된 요약본과 재가공된 파생 메모

• 민감하지만 앞으로 필요하지 않은 개인 데이터

특히 "요약의 요약의 요약"이 쌓이는 구조는 위험하다. 처음 정보가 조금만 틀려도, 압축이 반복되면서 왜곡이 커진다. 사람이 전해 들은 말을 또 전해 듣다가 내용이 달라지는 것과 같다. 에이전트 메모리도 이런 식으로 오염될 수 있다.

버려야 할 정보를 잘 버리면 두 가지 이점이 생긴다. 첫째, 컨텍스트가 가벼워져 추론 비용이 줄어든다. 둘째, 오래된 정보가 현재 판단을 오염시키는 일을 막을 수 있다. 잘 버리는 시스템은 잘 기억하는 시스템만큼 중요하다.

메모리 오염은 어떻게 생기는가

메모리 오염은 단순히 틀린 정보를 저장하는 문제만이 아니다. 맞는 정보라도 잘못된 위치에, 잘못된 형태로, 잘못된 수명으로 저장되면 오염이 된다.

예를 들어 이런 경우를 생각해볼 수 있다.

• 한 번의 예외 상황을 사용자의 일반적 선호로 저장함

• 특정 프로젝트의 규칙을 모든 프로젝트의 규칙처럼 기억함

• 오래된 가격표나 정책을 최신 정보처럼 계속 사용함

• 다른 사용자의 정보가 비슷한 이름 때문에 섞여 들어감

• 중간 추론 결과를 확정 사실처럼 저장함

메모리 오염이 무서운 이유는, 틀린 답보다 더 그럴듯한 틀린 행동을 만들기 때문이다. 에이전트는 자신감 있게 잘못된 파일을 열고, 익숙한 방식으로 엉뚱한 작업을 수행할 수 있다. 그래서 메모리 시스템에는 저장 기능뿐 아니라 정정 기능, 만료 정책, 출처 추적, 사용 범위 표시가 필요하다.

좋은 장기 기억 항목은 최소한 다음 질문에 답할 수 있어야 한다. 누가 준 정보인가? 언제 저장했는가? 어느 범위에서만 유효한가? 바뀔 수 있는가? 검증되었는가? 이 정보가 없으면 기억은 자산이 아니라 잠재적 결함이 된다.

개인화와 프라이버시의 균형

에이전트는 사용자를 기억할수록 더 친절해질 수 있다. 자주 쓰는 보고서 형식, 선호하는 언어 톤, 업무 시간대, 자주 참조하는 문서 폴더를 기억하면 확실히 편해진다. 하지만 여기에는 늘 그림자가 따라온다. 너무 많이 기억하면 편리함이 아니라 감시처럼 느껴질 수 있고, 보안 사고가 나면 피해도 커진다.

개인화는 "많이 아는 것"이 아니라 "적절하게 아는 것"이어야 한다. 실전에서는 다음 원칙이 유용하다.

• 기본값은 최소 수집으로 시작한다.

• 사용자가 반복적으로 확인한 선호만 천천히 장기 기억으로 승격한다.

• 민감 정보는 가능한 한 직접 저장하지 않고 참조 방식으로 다룬다.

• 사용자가 무엇을 기억하고 있는지 확인하고 지울 수 있게 한다.

• 사용자 단위, 조직 단위, 작업 단위의 기억을 분리한다.

예를 들어 "매주 월요일 오전에는 회의를 피하고 싶다"는 선호는 개인화에 유용할 수 있다. 하지만 건강 정보, 급여 정보, 계약상 민감 내용처럼 높은 보호가 필요한 데이터는 같은 방식으로 다뤄서는 안 된다. 모든 기억이 같은 서랍에 들어가면 안 된다.

기억보다 중요한 것은 검색 가능성이다

에이전트 설계에서 자주 나오는 오해가 있다. 더 많이 저장하면 더 똑똑해질 것이라는 오해다. 하지만 실제로는 잘 저장된 적은 양의 정보가 찾을 수 없는 많은 정보보다 훨씬 낫다.

중요한 것은 기억의 총량이 아니라 검색 가능성이다. 필요할 때 빠르게 찾을 수 있고, 최신성과 출처를 확인할 수 있으며, 작업 맥락에 맞게 꺼낼 수 있어야 한다. 이 점에서 좋은 메모리 시스템은 거대한 창고보다 잘 정리된 도서관에 가깝다.

검색 가능성을 높이려면 몇 가지 원칙이 필요하다.

• 메모리를 주제, 사용자, 프로젝트, 작업 단위로 구분한다.

• 각 항목에 생성 시점과 출처를 붙인다.

• 최신성 검사가 필요한 정보와 아닌 정보를 나눈다.

• 원문과 요약을 구분해서 저장한다.

• 검색 결과를 그대로 쓰지 말고 현재 작업과 연결해 다시 해석한다.

이 원칙이 없으면 에이전트는 기억을 많이 갖고도 매번 엉뚱한 것을 꺼내온다. 반대로 검색 가능성이 높으면 모든 것을 기억하지 않아도 된다. 필요한 순간에 정확한 정보를 다시 가져오면 되기 때문이다.

상태 저장은 재현 가능성을 위한 장치이기도 하다

메모리는 개인화와 맥락을 위해 중요하지만, 상태 저장은 운영을 위해 중요하다. 특히 제품 수준의 에이전트에서는 "왜 이렇게 행동했는가"를 나중에 설명할 수 있어야 한다. 이때 필요한 것이 구조화된 상태 기록이다.

예를 들어 데이터 분석 에이전트가 잘못된 리포트를 냈다면, 단순히 대화 기록만 봐서는 원인을 찾기 어렵다. 하지만 상태 기록이 있으면 문제를 훨씬 빨리 좁힐 수 있다. 어떤 데이터셋을 읽었는지, 어떤 쿼리를 생성했는지, 검증 단계가 건너뛰어졌는지, 재시도가 몇 번 있었는지 확인할 수 있기 때문이다.

즉, 상태는 실행을 위한 기억이면서 동시에 감사와 디버깅을 위한 흔적이다. 좋은 상태 설계는 에이전트를 더 똑똑하게 만들 뿐 아니라, 더 운영 가능하게 만든다.

실전에서 유용한 메모리 계층 구조

많은 경우 메모리와 상태는 한 덩어리가 아니라 계층으로 설계하는 편이 낫다. 가장 단순한 형태만 잡아도 효과가 크다.

첫 번째 층은 세션 메모리다. 현재 대화와 현재 작업 안에서만 살아남는 정보다. 창을 닫거나 작업이 끝나면 대부분 사라져도 된다.

두 번째 층은 작업 상태 저장소다. 현재 프로세스가 어느 단계에 있는지, 어떤 입력과 중간 결과를 가졌는지 기록한다. 재시작이나 복구에 중요하다.

세 번째 층은 지속 메모리다. 사용자 선호, 조직 정책, 반복 규칙처럼 장기적으로 재사용할 지식을 저장한다.

네 번째 층은 외부 지식 저장소다. 문서, 위키, 파일, 데이터베이스처럼 에이전트가 필요할 때 검색해서 읽는 정보다. 이 영역은 꼭 "기억"으로 넣지 않아도 된다. 오히려 검색 기반으로 두는 편이 더 안전한 경우가 많다.

이 계층이 있으면 저장 정책을 세우기 쉬워진다. 방금 회의 후보 시간을 영구 저장할 필요는 없지만, 사용자의 회의 선호 시간대는 지속 메모리 후보가 될 수 있다. 승인 대기 상태는 상태 저장소에 들어가야 하고, 회사 출장 규정은 외부 지식 저장소에서 참조하는 편이 맞다.

메모리 설계의 핵심 질문

메모리와 상태를 설계할 때는 기능 목록보다 질문 목록이 더 중요하다. 아래 질문에 답하지 못하면 시스템은 곧 복잡해진다.

• 이 정보는 현재 작업을 위해 필요한가, 미래 작업에도 필요한가?

• 이 정보는 사실인가, 추론인가, 선호인가, 상태인가?

• 누가 제공했고 언제 확인했는가?

• 언제 만료되어야 하는가?

• 잘못 저장되었을 때 얼마나 위험한가?

• 삭제 요청이 들어오면 쉽게 지울 수 있는가?

• 다시 찾을 수 있는가, 아니면 저장만 되고 잊히는가?

이 질문은 기술 스택과 무관하게 유효하다. 벡터 데이터베이스를 쓰든, 전통적인 DB를 쓰든, 파일 기반 캐시를 쓰든, 결국 좋은 메모리 설계는 이 질문들에 대한 답으로 결정된다.

좋은 메모리 시스템은 똑똑하기보다 정직하다

좋은 메모리 시스템은 모든 것을 기억하는 시스템이 아니다. 자신이 무엇을 알고 있고, 무엇은 모르는지, 무엇은 오래되었고, 무엇은 아직 확인되지 않았는지를 구분할 수 있는 시스템이다. 다시 말해, 많이 기억하는 시스템보다 정직하게 기억하는 시스템이 더 좋다.

에이전트에게 필요한 것은 인간처럼 끝없이 쌓이는 기억이 아니라, 작업에 도움이 되는 구조화된 기억이다. 단기 기억은 현재를 돕고, 장기 기억은 반복을 돕고, 작업 상태는 실행을 돕는다. 그리고 이 모든 것 위에서 가장 중요한 원칙은 하나다. 저장 자체가 목적이 되어서는 안 된다. 필요할 때 정확히 꺼내 쓰기 위해 저장해야 한다.

기억을 늘리는 일은 쉽다. 하지만 기억을 정리하고, 구분하고, 만료시키고, 다시 찾을 수 있게 만드는 일은 설계가 필요하다. 에이전트의 성능은 종종 모델의 지능보다 이 설계에서 갈린다. 잘 만든 메모리는 에이전트를 유능하게 만들고, 잘못 만든 메모리는 에이전트를 고집스럽게 만든다. 실무에서 더 무서운 쪽은 대개 후자다.