메모리와 상태 관리

LLM은 기억하지 않는다

AI가 사용자를 기억하는 것처럼 보일 때가 있다. 어제 말한 선호를 반영하고, 지난번 결정한 내용을 이어받고, 긴 작업의 다음 단계를 자연스럽게 수행한다. 하지만 이것은 모델이 스스로 기억해서가 아니다. LLM은 기본적으로 무상태(stateless) 시스템이다. 한 번의 호출이 끝나면 모델 내부에는 대화의 진행 상태가 남지 않는다. 다음 호출에서 무엇을 알아야 하는지는 시스템이 다시 넣어줘야 한다.¹

물론 많은 AI 제품과 API는 세션, 스레드, 메모리 같은 기능을 제공한다. 하지만 이 역시 모델 자체가 마법처럼 기억하는 것이 아니라, 플랫폼이나 애플리케이션이 이전 대화와 저장된 상태를 다시 불러와 모델 입력에 반영하는 방식으로 이해하는 편이 안전하다.

그래서 메모리 설계의 첫 질문은 "무엇을 저장할 것인가?"가 아니다. 더 정확한 질문은 이것이다.

다음 턴의 모델이 올바르게 행동하려면, 지금 어떤 상태를 다시 구성해야 하는가?

컨텍스트 엔지니어링에서 메모리는 단순 저장소가 아니다. 모델의 컨텍스트 창에 매번 들어갈 정보를 고르는 운영 체계다. 모든 대화 로그를 다시 넣는 방식은 오래가지 못한다. 비용이 커지고, 응답이 느려지고, 오래된 정보와 최신 정보가 충돌한다. 좋은 메모리 시스템은 원문을 보존하되, 모델에게는 검증된 사실과 최신 상태만 조립해 제공한다.

세션 상태와 장기 메모리를 분리하라

먼저 세션과 장기 메모리를 나누어야 한다.

세션 상태는 현재 대화나 현재 작업을 위한 임시 작업대다. 여기에는 최근 대화, 현재 목표, 열린 작업, 도구 호출 결과, 폼 입력 상태, 장바구니, 예약 진행 단계처럼 "지금 바로 필요한 정보"가 들어간다.

반면 장기 메모리는 여러 세션을 넘어 재사용할 가치가 있는 정보다. 사용자의 선호, 반복되는 업무 패턴, 프로젝트 배경, 과거 결정, 자주 쓰는 형식, 피해야 할 방식 등이 여기에 속한다.

두 개를 섞으면 문제가 생긴다. 예를 들어 사용자가 오늘만 임시로 "이번 보고서는 짧게 써줘"라고 말했다고 하자. 이것을 장기 메모리에 저장하면 앞으로 모든 보고서를 짧게 쓰는 잘못된 개인화가 발생할 수 있다. 반대로 사용자가 매번 "나는 표보다 글머리표를 선호해"라고 말했는데도 세션 안에서만 처리하면 다음 대화에서 또 물어봐야 한다.

실무에서는 다음처럼 나눌 수 있다.

핵심은 "모델에게 보여줄 컨텍스트"와 "시스템이 보관할 기록"을 다르게 보는 것이다. 세션 히스토리는 전체 기록일 수 있지만, 모델에 들어가는 컨텍스트는 매 턴 새로 컴파일된 요약본이어야 한다.

단기 메모리: 현재 작업을 잃지 않게 하는 장치

단기 메모리는 모델의 작업 기억이다. 이 영역에는 즉시 필요한 정보만 있어야 한다. 최근 사용자 의도, 아직 해결되지 않은 질문, 직전 도구 호출 결과, 현재 선택지, 다음 액션 정도면 충분한 경우가 많다.

문제는 대화가 길어질수록 단기 메모리가 쉽게 쓰레기장이 된다는 점이다. 과거에 이미 해결된 오류, 반복된 설명, 실패한 도구 결과, 더 이상 유효하지 않은 사용자의 말이 계속 남는다. 그러면 모델은 무엇이 최신 사실인지 판단하는 데 주의를 낭비한다.

대표적인 단기 메모리 관리 방법은 세 가지다.

첫째, 최근 N턴 유지다. 가장 단순하다. 최근 몇 개의 사용자 턴과 그에 따른 어시스턴트 응답, 도구 결과만 남긴다. 요청이 독립적인 고객 문의, 짧은 검색 작업, 단순 도구 실행에는 잘 맞는다.

둘째, 토큰 기준 트리밍이다. 정해진 토큰 예산을 넘으면 오래된 메시지부터 제거한다. 최근성이 중요한 작업에는 유용하지만, 초기에 나온 핵심 제약이 사라질 수 있다.

셋째, 요약 기반 압축이다. 오래된 대화는 구조화된 요약으로 바꾸고, 최근 대화는 원문으로 유지한다. OpenAI의 세션 메모리 예제도 긴 멀티턴 상호작용에서 트리밍과 압축을 사용해 에이전트를 빠르고 비용 효율적으로 유지하는 방식을 설명한다.²

요약은 짧게 만드는 일이 아니라 상태를 재정의하는 일이다. 좋은 요약에는 다음이 남아야 한다.

• 현재 목표

• 확정된 결정

• 사용자가 제공한 중요한 제약

• 이미 시도한 방법과 결과

• 남은 작업

• 최신 상태가 이전 상태를 덮어쓴 경우의 표시

반대로 잡담, 중복 설명, 대량의 원시 도구 출력, 이미 닫힌 하위 작업은 제거해야 한다. 특히 도구 결과는 원문 전체를 넣기보다 "무엇을 호출했고, 어떤 결론을 얻었고, 어떤 값이 후속 작업에 필요한지"만 남기는 편이 안전하다.

장기 메모리: 모두 기억하지 말고 가치 있는 것만 승격하라

장기 메모리는 개인화와 장기 일관성을 만든다. 그러나 장기 메모리가 많을수록 좋은 것은 아니다. 잘못 저장된 기억은 오래 지속되는 컨텍스트 오염이 된다. 한 번 잘못 저장된 선호나 사실이 매번 검색되어 모델의 판단을 흐릴 수 있다.

따라서 장기 메모리에 저장할 정보는 기준이 높아야 한다.

저장할 만한 정보는 보통 네 종류다.

에피소드 메모리는 특정 사건에 대한 기억이다. "지난 상담에서 사용자는 환불 대신 교환을 선택했다", "3월 회의에서 A안이 보류되었다"처럼 시간과 맥락이 있는 기록이다.

의미 메모리는 비교적 안정적인 사실이다. "사용자는 한국어 답변을 선호한다", "이 프로젝트의 핵심 고객은 B2B SaaS 팀이다"처럼 여러 상황에서 재사용된다.

절차 메모리는 일을 수행하는 방식이다. "이 사용자의 월간 보고서는 먼저 KPI 표를 만들고, 그다음 원인 분석을 붙인다"처럼 반복 업무의 순서를 담는다.

프로젝트 메모리는 특정 작업 공간에 묶인 배경지식이다. 제품 용어, 의사결정 기록, 금지된 접근, 배포 규칙 등이 포함된다.

이렇게 나누는 이유는 검색과 갱신 기준이 다르기 때문이다. 선호는 오래 유지될 수 있지만 바뀔 수 있다. 프로젝트 결정은 출처와 날짜가 중요하다. 절차 메모리는 성공 여부에 따라 강화하거나 폐기해야 한다. 에피소드 메모리는 특정 사건에는 유용하지만 일반화하면 위험하다.

개인화 에이전트에서는 무엇을 저장하고, 언제 회상하고, 어떻게 모델의 작업 기억에 주입할지를 관리해야 한다. OpenAI의 개인화 예제도 저장·회상·주입을 분리해 에이전트가 더 일관되고 개인적인 응답을 하도록 설계하는 접근을 보여준다.³

원문 로그와 모델 입력을 분리하라

운영 환경에서 가장 안전한 구조는 이중 구조다.

하나는 원문 이벤트 로그다. 사용자 메시지, 어시스턴트 응답, 도구 호출, 도구 결과, 상태 변경, 오류, 승인 기록을 시간순으로 보관한다. 이 로그는 감사, 장애 복구, 재요약, 분쟁 대응에 필요하다.

다른 하나는 모델 입력용 메모리 뷰다. 이것은 원문 전체가 아니라, 현재 턴에 맞게 조립된 정보 묶음이다. 예를 들면 다음과 같다.

시스템 지침
+ 현재 작업 상태
+ 관련 장기 메모리 3개
+ 최근 대화 4턴
+ 방금 실행한 도구 결과 요약
+ 사용자 최신 요청

이 방식의 장점은 명확하다. 원문은 보존하되, 모델은 불필요한 과거에 휘둘리지 않는다. 잘못된 요약이 발견되면 원문 로그에서 다시 요약할 수 있다. 개인정보나 권한 문제가 있는 데이터는 모델 입력 단계에서 필터링할 수 있다.

Anthropic은 좋은 컨텍스트 엔지니어링을 "원하는 결과 가능성을 높이는 가장 작은 고신호 토큰 집합을 찾는 일"로 설명한다.⁴ 메모리 설계도 같은 원칙을 따른다. 저장소에는 충분히 보관하되, 모델에는 작고 정확한 작업 상태만 올린다.

메모리 매니저의 역할

메모리 시스템에는 메모리 매니저가 필요하다. 메모리 매니저는 단순히 벡터 DB에 문장을 넣고 빼는 컴포넌트가 아니다. 무엇을 기억으로 승격할지, 무엇을 버릴지, 무엇을 수정할지 결정하는 정책 계층이다.

좋은 메모리 매니저는 네 가지 일을 한다.

첫째, 추출한다. 대화나 작업 로그에서 장기적으로 가치 있는 사실만 뽑는다. "사용자가 오늘 피곤하다고 했다"는 보통 장기 메모리가 아니다. "사용자는 매주 금요일 오전에 주간 보고서를 준비한다"는 장기 메모리 후보가 될 수 있다.

둘째, 통합한다. 새 정보가 기존 메모리와 중복되거나 충돌하는지 확인한다. "사용자는 짧은 답변을 선호한다"와 "사용자는 상세한 근거를 원한다"가 동시에 있으면 상황별 조건을 붙이거나 최신 발언을 기준으로 갱신해야 한다.

셋째, 검색한다. 현재 요청과 관련된 기억만 가져온다. 검색 기준은 유사도만으로 부족하다. 최신성, 중요도, 신뢰도, 출처, 사용자 범위, 프로젝트 범위를 함께 봐야 한다.

넷째, 정리한다. 오래되었거나 틀렸거나 더 이상 쓰이지 않는 기억은 삭제, 수정, 강등한다. 메모리에도 수명주기가 필요하다. 모든 기억을 영구 보존하면 개인화가 아니라 오염이 된다.

메모리 항목에는 최소한 다음 메타데이터를 붙이는 것이 좋다.

{
  "owner_id": "user_123",
  "scope": "user | project | org | session",
  "type": "preference | fact | decision | procedure | episode",
  "content": "사용자는 보고서 초안을 글머리표 형식으로 선호한다.",
  "source_event_ids": ["evt_001", "evt_014"],
  "created_at": "2026-05-20T10:00:00Z",
  "updated_at": "2026-05-20T10:00:00Z",
  "confidence": 0.82,
  "expires_at": null
}

이런 메타데이터가 없으면 메모리는 곧 출처 없는 주장 목록이 된다. 출처 없는 기억은 디버깅하기 어렵고, 사용자에게 설명하기도 어렵다.

멀티에이전트에서는 공유보다 경계가 먼저다

멀티에이전트 시스템에서는 메모리 문제가 더 복잡해진다. 여러 에이전트가 하나의 사용자나 하나의 프로젝트를 다룰 때, 무엇을 공유하고 무엇을 격리할지 정해야 한다.

모든 에이전트가 하나의 대화 로그를 공유하면 단일한 진실 공급원처럼 보인다. 하지만 곧 잡음이 많아진다. 검색 에이전트의 실패 흔적, 코딩 에이전트의 중간 추론, 리뷰 에이전트의 지적이 모두 섞이면 각 에이전트는 자기 작업과 무관한 정보를 읽게 된다.

반대로 각 에이전트가 완전히 별도 메모리를 쓰면 전문성은 높아지지만 전체 일관성이 약해진다. 한 에이전트가 내린 결정을 다른 에이전트가 모를 수 있다.

실무적으로는 원문 작업 로그는 분리하고, 공유 메모리는 정제된 산출물 중심으로 운영하는 방식이 안전하다. 예를 들어 리서치 에이전트는 검색 과정 전체를 넘기지 않고 "검증된 사실, 출처, 불확실한 점"만 전달한다. 코딩 에이전트는 모든 시행착오가 아니라 "수정한 파일, 실패한 테스트, 남은 이슈"를 남긴다.

즉, 에이전트 간 공유 단위는 대화 기록이 아니라 상태 전달이다. 이 원칙은 컨텍스트 격리와도 연결된다. 각 에이전트는 자기 역할에 필요한 최소 메모리만 읽고, 공유 저장소에는 다른 에이전트가 재사용할 수 있는 형태로 정리된 결과만 남긴다.

운영에서 필요한 정책

프로덕션 메모리는 기능이 아니라 책임이다. 사용자의 장기 정보를 저장하는 순간 개인정보, 권한, 삭제 요청, 감사 가능성, 데이터 무결성을 함께 다뤄야 한다.

운영 전에 최소한 다음 질문에 답해야 한다.

• 어떤 정보는 절대 저장하지 않는가?

• 사용자가 자신의 메모리를 조회·수정·삭제할 수 있는가?

• 메모리 저장 전 개인정보를 마스킹하거나 암호화하는가?

• 조직 메모리와 개인 메모리의 접근 권한은 어떻게 다른가?

• 오래된 메모리는 언제 만료되는가?

• 잘못된 메모리가 응답에 영향을 줬을 때 추적할 수 있는가?

• 모델 입력에 들어간 메모리 조각을 로그로 남기는가?

특히 개인화 시스템에서는 "기억한다"는 경험이 편리함과 불편함의 경계에 있다. 사용자가 기대한 선호를 기억하면 만족도가 올라가지만, 민감한 발언을 예상치 못한 순간에 꺼내면 신뢰가 깨진다. 따라서 장기 메모리는 투명해야 한다. 사용자가 "왜 이렇게 답했는지" 물었을 때 어떤 메모리가 영향을 줬는지 설명할 수 있어야 한다.

기억하는 에이전트의 최소 구조

메모리와 상태 관리를 처음 설계한다면 복잡한 시스템부터 만들 필요는 없다. 다음 네 층이면 충분히 시작할 수 있다.

1. 이벤트 로그: 모든 대화와 도구 호출을 시간순으로 저장한다.

2. 세션 state: 현재 목표, 진행 단계, 열린 작업, 최신 도구 결과를 구조화한다.

3. 장기 메모리 저장소: 사용자·프로젝트·조직 범위의 재사용 가능한 기억만 저장한다.

4. 컨텍스트 조립기: 매 턴 필요한 최근 기록, 상태, 관련 메모리만 선택해 모델 입력을 만든다.

이 구조에서 중요한 것은 모델이 보는 입력이 항상 "현재 상태의 최신 뷰"가 되도록 하는 것이다. 원문 로그는 과거의 사실이고, state는 현재의 작업판이며, 장기 메모리는 반복적으로 재사용되는 배경이다. 이 셋을 구분하면 에이전트는 더 오래 일관성을 유지하고, 더 적은 토큰으로 개인화되며, 문제가 생겼을 때 복구하기 쉬워진다.

AI가 기억하는 것처럼 보이게 만드는 비결은 기억을 많이 저장하는 것이 아니다. 무엇을 저장하지 않을지, 무엇을 지금 다시 불러올지, 무엇을 모델에게 보여주지 않을지를 명확히 정하는 것이다. 메모리는 컨텍스트 창 밖에 있는 저장소가 아니라, 매 순간 더 나은 컨텍스트를 만들기 위한 선택의 시스템이다.

참고

¹Context Engineering: Sessions and Memory

²Context Engineering - Short-Term Memory Management with Sessions

³Context Engineering for Personalization - State Management with Long-Term Memory Notes

⁴Effective context engineering for AI agents