Context Engineering : Sessions and Memory

요즘 LLM 생태계에서 가장 선도에 서있는 구글에서 지난 11월에 공개한 LLM/에이전트 시스템에서 컨텍스트를 다루는 두 핵심 축인 “세션(Session)”과 “메모리(Memory)”를 체계적으로 정의하고, 설계 패턴·아키텍처·운영 상 트레이드오프를 정리한 기술 문서입니다.

출처 : https://drive.google.com/file/d/1JW6Q_wwvBjMz9xzOtTldFfPiF7BrdEeQ/view

Context Engineering: Sessions & Memory.pdf

컨텍스트 엔지니어링이란 'LLM 컨텍스트 윈도우 안에 들어갈 정보를 매 턴마다 동적으로 조합하고 관리하는 과정'으로 정의할 수 있습니다. 이를 위해 RAG DB, 세션, 메모리 등을 오케스트레이션 해야 합니다. 따라서 세션(대화 히스토리, 상태)과 메모리(장기 지속 정보)는 모두 컨텍스트 엔지니어링의 주요 대상입니다.

세션(Sessions) 이란

LLM 대화는 호출이 끝나면 아무것도 기억하지 않는 stateless 환경을 전제로 하고 있습니다. 멀티턴이라는 것도 '매번 이전 대화 전체를 다시 보내는 것'에 불과하기 때문에 단순히 LLM API를 호출하는 것이 아닌 에이전트를 구축하기 위해서는 여러 번의 호출, 툴 사용, 중간 상태까지 포함한 전체 상호작용을 안정적으로 저장하고 조회해야 하기 때문에 단순히 LLM 컨텍스트에 대화를 덧붙이는 방식이 아닌 대화 로그와 작업용 상태를 담는 객체 즉, 세션(Session)이 필요합니다.

세션은 특정 사용자와의 대화 기록이며, 각 세션은 서로 분리된 로그라고 생각하면 됩니다. 세션 안에는 대화의 시간순 히스토리와 에이전트의 워킹 메모(state)가 포함되어 있습니다. 구성 요소는 다음과 같습니다.

• 이벤트(events) : 사용자 입력, 에이전트 응답, 툴 호출, 출력 등 턴마다 발생하는  모든 사건이 시간순으로 쌓이는 로그
• 상태(state) : 현재 대화에 필요한 구조화된 데이터로서 예를 들어 장바구니 정보(상품 ID, 수량)나 현재 처리중인 프로젝트 ID 또는 이번 대화에서 선택한 옵션, 중간 계산 결과 등

일반적으로 에이전트에서는 세션에 쌓인 이벤트를 필요할 때 선택하고 요약해서 LLM 입력을 구성하고 LLM이나 툴 호출 결과를 다시 세션에 이벤트로 적재하는 루프를 수행하는 역할을 수행합니다.

메모리(Memory)란

메모리는 “여러 세션에 걸쳐 중요한 정보를 보관해 두는 장기 저장소”입니다. 즉, 특정 대화 한 번의 작업용 공간이 아니라, 과거 여러 대화에서 뽑은 핵심만 모아 두는 저장소로서 이를 통해 에이전트가 이전의 여러 번의 대화에서 알게 된 내용을 기억해 두었다가 자연스럽게 이어서 대화할 수 있도록 하는 역할이라고 할 수 있습니다.

세션은 특정 대화를 위해 책상 위에 펼쳐 둔 자료와 메모라고 할 수 있고 메모리는 그 중 중요한 것만 골라 정리해 넣는 파일 캐비닛이나 서랍이라고 할 수 있습니다. 따라서, 대화가 끝날 때 전체 세션 히스토리를 그대로 저장하는 것이 아니라, 불필요한 내용을 버리고 “나중에 다시 쓸 가치가 있는 정보”만 선별해서 요약하여 메모리에 넣어두고 이후 새 세션에서 다시 불러와서 사용하게 됩니다.​

세션은 한 번의 대화를 위한 작업대(workbench), 메모리는 여러 대화를 가로질러 정리된 캐비닛(filing cabinet)이라고 비유할 수 있는데, 세션과 메모리를 통해 LLM의 stateless 특성을 극복하고 상태 있는 에이전트를 만들 수 있으며, 컨텍스트 엔지니어링은 결국 이 두 계층(세션·메모리)과 RAG·툴 출력·시스템 인스트럭션 등을 적절히 조합해, 매 턴 “필요한 만큼만, 그러나 부족하지 않게” 컨텍스트를 구성하는 설계·운영의 전체 프랙티스를 의미합니다.

이 문서에서 소개하는 에이전트를 위한 컨텍스트 관리 순서는 다음 그림과 같습니다.

1단계: 컨텍스트 가져오기 (Fetch Context)
에이전트는 사용자 질의가 들어오면 먼저 필요한 컨텍스트를 조회합니다. 여기에는 사용자 메모리(장기 기억), RAG로 가져오는 문서·지식, 최근 대화 이벤트(세션 히스토리) 등이 포함되고, 질의와 메타데이터를 조건으로 동적 검색을 수행합니다.

2단계: 컨텍스트 준비 (Prepare Context)
프레임워크가 LLM 호출에 쓸 “전체 프롬프트 페이로드(payload)”를 동적으로 조립합니다. 페이로드는, LLM에게 한 번 호출을 보낼 때 함께 보내는 전체 요청 데이터 묶음으로서 즉, 단순한 사용자 질문 한 줄이 아니라, 그 턴의 추론에 쓰이는 모든 컨텍스트를 합쳐 놓은 패키지로서 시스템 인스트럭션, 툴 정의, few-shot 예제, 장기 메모리, 외부 지식(RAG), 도구 출력, 서브에이전트 출력, 아티팩트, 현재 세션의 대화 히스토리 등에서 선택하고 요약하여 준비합니다. 

3단계: LLM·툴 호출 (Invoke LLM and Tools)
준비된 컨텍스트를 기반으로 LLM을 호출하고, 필요 시 툴을 여러 번 호출하면서 최종 사용자 응답이 나올 때까지 반복합니다. 이 과정에서 생성되는 모델 응답, 툴 호출 · 툴 출력 등이 “이 턴의 새로운 이벤트”로 컨텍스트에 계속 추가됩니다.

4단계: 컨텍스트 업로드/정착 (Upload Context)
한 턴에서 새로 얻은 정보(대화 이벤트, 상태 변화, 추출된 메모리 등)를 세션 스토어·메모리 스토어 같은 저장소에 업로드하며, 이 단계는 주로 비동기·백그라운드로 수행되며, 메모리 통합·요약 같은 후처리가 에이전트 응답과 병렬로 돌아가도록 설계하는 것을 권장하고 있습니다. 

이 전체 과정에서 세션은 현재 대화의 이벤트 로그와 워킹 스테이트를 담는 “워크벤치/책상”으로, 위 루프에서 주로 1·2·3단계에서 읽고 쓰이는 단기 컨텍스트이며, 메모리는 여러 세션에 걸쳐 축적되는 “정리된 캐비닛”으로, 1단계에서 검색·주입되고 4단계에서 새 정보가 추출·통합되어 장기적으로 저장됩니다.

이렇게 문서를 통해서 보면 간단해(?) 보이지만, 실제로 구현해 보면  멀티 유저 환경에서 세션이나 메모리 관리가 LangGraph 같은 프레임워크를 사용해도 쉽지 않습니다. 세션 식별이나 네임스페이 관리가 잘 안 되거나 단기 메모리와 장기 메모리 저장에 대한 어려움이 있으며, 무엇보다 LLM 컨텍스트 사이즈가 제한된 상태에서 세션 히스토리가 무한정 길어질 수 없고 메모리도 한계가 있기 때문에 쉬운 일이 아닙니다.

개인적으로 LLM 에이전트의 가장 어려운 지점 중 하나가 바로 컨텍스트 엔지니어링이 아닌가 싶습니다.