---
title: "State and Memory Control — 상태와 기억 제어"
description: "단기 상태와 장기 기억을 분리해 정보 누수와 혼선을 방지한다."
canonical: "https://architecture.reopt.ai/ko/patterns/state-and-memory-control"
language: "ko"
alternate-markdown: "https://architecture.reopt.ai/patterns/state-and-memory-control.md"
site-index: "https://architecture.reopt.ai/llms.txt"
source: "reopt architecture"
---

# State and Memory Control — 상태와 기억 제어

> 단기 상태와 장기 기억을 분리해 정보 누수와 혼선을 방지한다.

- **Category:** 협업과 조율
- **OCLS phase:** LAYER
- **Slug:** `state-and-memory-control`

## 판단 질문

무엇을 세션에 두고, 무엇을 시스템 자산으로 승격할 것인가?

## Context

에이전트는 실행 중 상태(현재 단계, 임시 변수)와 장기 기억(학습된 패턴, 사용자 선호, 과거 결과)을 함께 다룬다. 이 둘을 가르지 않으면 세션이 끝나도 임시 상태가 남거나 중요한 기억이 세션과 함께 사라진다.

## Problem

단기 상태와 장기 기억의 경계가 없으면 묵은 세션 상태가 새 세션으로 새어 들어가 판단을 그르친다. 반대로 쓸 만한 학습 결과가 세션이 끝날 때 사라지면 시스템이 같은 실수를 되풀이한다. 멀티 에이전트 환경에서는 공유 상태의 충돌까지 다뤄야 한다.

## Forces

- 모든 것을 기억하면 검색 비용과 노이즈가 늘고, 골라서 기억하면 중요한 정보를 놓칠 수 있다.
- 상태를 중앙에서 관리하면 일관성은 높지만 병목이 되고, 분산하면 동기화 문제가 생긴다.
- 기억에 유효기간을 두면 관리가 쉬운 대신 생각보다 오래 필요한 기억이 사라질 수 있다.

## Solution

상태를 세션 범위의 단기 상태와 시스템 범위의 장기 기억으로 또렷이 가른다. 단기 상태는 세션이 끝나면 자동으로 정리하고, 장기 기억으로 올릴 항목은 명시적 기준(반복 패턴, 품질 개선 기여 등)에 따라 정한다. 멀티 에이전트 환경에서는 공유 기억의 읽기/쓰기 권한을 에이전트마다 따로 정한다. 장기 실행 에이전트에서는 compaction(압축) 메커니즘이 필수다. Anthropic의 [Effective Context Engineering for AI Agents]가 내놓은 compaction 패턴은 컨텍스트 윈도우 한계에 다다르면 대화 내용을 요약해 새 윈도우를 초기화하되, 아키텍처 결정·미해결 버그·구현 세부사항은 남기고 중복 도구 출력은 덜어내는 방식이다. 또 에이전트가 컨텍스트 바깥에 구조화된 노트를 적어두고 나중에 참조하는 structured note-taking 패턴을 쓰면 수천 단계에 걸쳐 상태를 정확히 추적한다. 긴 컨텍스트 윈도우(수십만~백만 토큰)를 쓸 수 있다고 해서 모든 정보를 한 윈도우에 다 실어야 하는 것은 아니다. '큰 윈도우에 다 담기'와 '컨텍스트 라우팅으로 좁히기'는 비용·지연·attention budget을 두고 저울질하는 선택이며, 작업 특성에 따라 고른다. 확장 사고(extended thinking) 모델의 중간 사고 흔적은 세션 범위의 단기 상태이지 장기 기억이 아니다. 사고 과정 자체를 장기 기억으로 올리지 않는다.

## 적용 시나리오

_예시 시나리오 — 본 페이지의 수치와 기업명은 패턴 설명을 위한 가상 사례이며, 실측 데이터가 아닙니다._

고객 A가 '배송 지연' 문의 뒤 같은 세션에서 '결제 수단 변경'을 이어 물어본다. 단기 상태(현재 대화 맥락, 직전 응답 결과)는 세션 안에서만 유효하다. 반면 '이 고객은 3회 연속 배송이 지연됐고 전에 10% 할인 쿠폰을 받았다'는 정보는 장기 기억으로 올려 Knowledge Agent가 관리한다. Response Agent는 장기 기억을 읽을 수는 있어도 쓰지는 못하고 승격 요청만 한다. QA Agent가 승격 기준(3회 이상 반복, 품질 개선 기여)을 검증한 뒤 장기 기억에 반영한다.

## 이렇게 하면 무너진다

상태와 기억을 가르지 않으면 지난 세션의 '배송 지연' 맥락이 새 세션의 '결제 변경' 응답으로 새어 들어가 '배송이 지연되어 죄송합니다'로 시작하는 엉뚱한 응답이 나온다. 반대로 세션이 끝날 때 모든 정보를 지우면 같은 고객이 같은 문제로 다시 물어볼 때 이전 대응 이력을 참고하지 못해 똑같은 해결책을 또 내민다.

## 구현 패턴 연결

- Session Store / Vector Memory

주로 인프라 설계 영역이다. 세션 스토어(단기)와 벡터 DB/지식 베이스(장기)의 분리, 읽기/쓰기 권한 제어가 핵심 구현 과제.

## 관련 문서

- [Context Routing — 컨텍스트 라우팅](https://architecture.reopt.ai/ko/patterns/context-routing.md)
- [Evaluation and Guardrails — 평가와 가드레일](https://architecture.reopt.ai/ko/patterns/evaluation-and-guardrails.md)

## References

- The Rise of Agentic AI: Architectures, Taxonomies, and Evaluation Metrics — Future Internet (MDPI)

## 이 패턴을 적용하기

저장소에서 리뷰 스킬을 사용하고, 관련 아티클의 구현 결정과 비교한다. 각 예제를 자신의 권한, 데이터, 실패 조건에 맞춰 검토한다.

- [리뷰 스킬: reopt-state-and-memory-control](https://architecture.reopt.ai/ko/skills/reopt-state-and-memory-control.md) — 세션 간 상태 누수가 발생할 때 사용하는 Claude Code 스킬. 기억의 수명, 장기 기억 승격 조건, 에이전트별 읽기·쓰기 권한을 점검한다.

### 관련 구현 기록

- [토큰 전략 — 효율·밸런스·공격적, 그리고 인력 배분](https://architecture.reopt.ai/ko/articles/loop-token-strategy.md) — 토큰을 아끼는 것과 태우는 것은 둘 다 전략이다. 같은 루프를 효율·밸런스·공격적 세 모드로 다르게 운영하고, 비즈니스 상황과 진화 단계에 맞춰 모드와 인력을 배분한다. 토큰 사용을 기술적 선택으로 정리한다.
- [데이터 플라이휠 — 루프를 지속이 아니라 발전시키는 것](https://architecture.reopt.ai/ko/articles/loop-data-flywheel.md) — 돈은 루프를 돌리고 토큰은 연산하지만, 다음 바퀴를 이전보다 낫게 만드는 것은 운영이 쌓은 데이터다. trace·평가·학습 신호 세 자산으로 플라이휠을 돌리고, 데이터를 모델 밖 자산으로 두어 주권을 지킨다.
- [모델 주권과 인간 주도성 — 4계층 위에서의 두 축](https://architecture.reopt.ai/ko/articles/model-sovereignty-and-human-agency.md) — 모델은 교체되고 컴퓨트는 흔해진다. 그래서 통제할 대상은 모델이 아니라 모델 위에 쌓는 학습 루프이고, 그 루프를 향하게 하는 것은 인간의 방향이다. reopt architecture의 4계층·8패턴·OCLS 언어로 두 축을 설계로 옮긴다.

---

_이 문서는 https://architecture.reopt.ai/ko/patterns/state-and-memory-control 의 마크다운 표현이다. 전체 색인: https://architecture.reopt.ai/llms.txt HTML 원본: https://architecture.reopt.ai/ko/patterns/state-and-memory-control · English: https://architecture.reopt.ai/patterns/state-and-memory-control.md_