상태 관리 개요

🧠

상태의 기초

턴과 세션 · messages[] · 왜 상태 관리인가

PART 1 · 상태의 기초

에이전트 대화의 구조 — 턴 · 세션 · 기억

메시지가 모여 턴, 턴이 모여 세션 — 그리고 그 전부를 기억하는 곳

Session — 대화 전체 (턴들의 묶음)


👤 사용자
🤖 에이전트






턴 1
메시지 2개

"오늘 저녁 2명 예약하고 싶어요"
user 메시지

이탈리안 2곳을 추천드려요
assistant 메시지




턴 2
메시지 4개 — 도구 호출 포함

"코스 요리 포함으로 바꿔줘"

🔧 도구 호출 — 예약 변경
toolUse · toolResult 메시지 2개 추가

코스 구성으로 변경해 예약했어요




messages[]
이 대화의 메시지 6개를
순서대로 기록
저장 위치: 프로세스 메모리
⚡ 프로세스 종료 = 전부 소멸


기억이 여기뿐이라면 대화는 재시작과 함께 사라집니다 — 그래서 상태 관리가 필요합니다

PART 1 · 상태의 기초

기억의 실체 — messages[]

모델은 아무것도 기억하지 않음 — 매 턴, 지금까지의 대화 전체를 재전송

이미 보낸 메시지 — 매번 다시 전송

이번 턴의 새 질문

도구 메시지 — 이력에 남아 재전송




턴 1


messages[]

질문 1

배열 통째로 전송 — 1개




턴 2


messages[]

질문 1

답변 1

질문 2

배열 통째로 전송 — 3개


턴 2에서 도구 사용 → 도구 요청·결과 메시지 2개가 messages[]에 추가




턴 3


messages[]

질문 1

답변 1

질문 2

도구 요청

도구 결과

답변 2

질문 3

— 7개



모델
stateless
호출 사이에 아무것도
저장하지 않음
기억은 모델 밖 —
messages[]에 있음


모델이 기억하는 게 아니라, 큰 도구 결과까지 매 턴 다시 들려주는 것 — messages[] 전체가 기억의 실체입니다

PART 1 · 상태의 기초

상태가 없으면 생기는 세 가지 문제

인메모리 messages[]를 그대로 프로덕션에 두면 생기는 문제

맥락 유실

재시작·콜드 스타트·배포 = 기억 상실

• 서버 재시작 후 "아까 그거"를 모름
• 사용자가 처음부터 다시 설명해야 함

토큰 폭발

매 호출에 전체 히스토리 전송

• 50턴이면 매번 수만 토큰 과금
• 비용과 지연이 대화 길이에 비례 증가

윈도우 초과

컨텍스트 한도를 넘으면 호출 실패

• 긴 대화·큰 도구 결과가 한도를 넘김
• 정리 전략 없이는 대화가 중단

takeaway

이 세 문제의 해법이 곧 상태 관리입니다.
Strands는 이를 네 계층으로 풀어냅니다 — 저장은 Session, 길이는 Conversation, 기억은 Memory, 조립은 Context

PART 1 · 상태의 기초

네 가지 이름의 실체

저장·길이·기억·조립 — 각 이름이 Strands에서 실제로 가리키는 것

Session

저장 — 대화 전체를 영속화·복원

Conversation

길이 — 쌓이는 대화 이력과 그 관리

Memory

기억 — 세션을 넘어 남는 사실과 선호

Context

조립 — 이번 호출에 실제로 들어가는 입력

takeaway

Strands에 "상태 관리"라는 단일 API는 없습니다 — 위 네 계층의 조합이며, 별도로 agent.state(모델에 전송되지 않는 key-value 저장소)가 세션과 함께 저장됩니다.

🗺️

상태 관리 계층

Session → Conversation → Memory → Context

PART 2 · 상태 관리 계층

4계층 지도 — 쌓아가는 선택

워크로드가 복잡해질수록 아래부터 하나씩 쌓이는 계층

Session— 저장·복원Conversation— 길이 정리Memory— 장기 기억Context— 모델 입력 조립

Context

단발성 질의

Lambda — 대화 없음

Conversation

SlidingWindow

Session

Context

챗봇

세션 유지

Memory

Conversation

Summarizing

Session

Context

개인 비서

장기 기억

Memory

Conversation

Summarizing

Session

Context

context_manager='auto'

멀티턴 분석

대용량 — 한도 방어까지

왼쪽에서 오른쪽으로 — 대화가 길고 깊어질수록 계층이 하나씩 쌓입니다

PART 2 · 상태 관리 계층

모델 입력이 되기까지 — Context 조립 라인

네 계층이 각자의 기여물을 꽂아 넣는, 매 호출 새로 조립되는 Context

1

Session
저장소에서 messages[] 복원
(Agent 생성 시 1회)


2

Conversation
정책대로 이력 정리
최근 N개 유지 또는 요약



3

Memory
질문과 관련된 장기 기억 검색
관련될 때만 주입



4

새 질문
이번 턴의 사용자 입력




Context — 모델 입력

System Prompt
매 호출 동일 (고정)

정리된 대화 이력
Session 복원 + Conversation 정리

주입된 장기 기억
Memory recall 결과

새 질문
이번 턴의 입력
+ 턴 중 생기는 도구 결과









모델
조립된 Context만 봄
매 호출 새로 조립


복원·정리·주입은 계층이 알아서 — 개발자는 질문만 넣으면 Context가 조립됩니다