목차
- 멀티턴 대화 시스템의 근본적 도전
- OpenClaw 메모리 아키텍처: 다층 설계
- Context 일관성 유지 전략
- 실전 구현 패턴과 Best Practices
- 성능 최적화 및 모니터링
1. 멀티턴 대화 시스템의 근본적 도전
AI 에이전트가 실제 production 환경에서 가치를 발휘하려면 단순히 일회성 질의응답을 처리하는 것을 넘어서야 합니다. 현대의 사용자들은 인간과의 대화처럼 natural하고 continuous한 상호작용을 기대합니다. 이것이 바로 “multi-turn conversation”의 본질입니다.
그런데 멀티턴 대화는 기술적으로 엄청난 복잡성을 안고 있습니다. 사용자가 “어제 논의한 프로젝트의 예산은 얼마였어?”라고 물으면, 시스템은 단순히 이 한 문장만으로는 답할 수 없습니다. 어제의 대화 전체, 그 프로젝트의 context, 사용자의 선호도, 이전에 결정된 내용들이 모두 필요합니다. 이를 “conversation history” 또는 “dialogue state”라고 부릅니다.
1.1 멀티턴 대화의 세 가지 핵심 요소
Session State Management: 현재 대화 세션의 상태를 추적하는 것입니다. 사용자가 질문을 던질 때마다, 시스템은 “이 사용자의 현재 상황은 무엇인가?”를 알아야 합니다. 예를 들어, 고객 지원 챗봇에서 사용자가 “반품 처리를 진행해주세요”라고 하면, 시스템은 이미 반품이 승인되었는지, 배송 라벨이 발급되었는지 등을 알고 있어야 합니다.
Context Window Management: LLM (Language Model)은 finite context window를 가집니다. 예를 들어, Claude의 context window는 200K tokens이지만, 사용자와의 대화가 계속되면 언젠가는 이 한계를 초과합니다. 따라서 “어떤 정보는 long-term memory에 저장하고, 어떤 정보는 short-term conversation window에만 유지할 것인가”를 결정해야 합니다. 이것이 바로 information prioritization의 문제입니다.
Cross-turn Reasoning and Consistency: Turn이란 한 번의 사용자 입력을 의미합니다. 만약 turn 1에서 사용자가 “부산으로 배송해주세요”라고 했고, turn 5에서 “배송 주소를 확인해주세요”라고 물으면, 시스템은 부산이 여전히 선택된 주소라는 것을 알아야 합니다. 동시에, 만약 turn 3에서 “아 서울로 변경해달라”고 했다면, turn 5의 답변은 서울이어야 합니다. 이것이 “consistency”의 핵심입니다.
1.2 멀티턴 대화에서 흔하게 발생하는 문제들
Hallucination and Inconsistency: “turn 1에서 언급한 내용을 turn 10에서 완전히 다르게 해석하는 문제”입니다. 예를 들어, 사용자가 “저는 개발자입니다”라고 turn 1에서 말했는데, turn 10에서 “당신은 디자이너이군요”라고 AI가 응답하는 것입니다. 이는 context window 내에 이전 정보가 충분히 포함되지 않았거나, 모델이 실수로 잘못된 정보를 생성한 경우입니다.
Lost Context Problem: 대화가 길어지면서 이전의 중요한 정보가 사라지는 문제입니다. conversation history 전체를 context에 유지하려면 너무 많은 tokens를 사용하고, 그러면 응답 생성 속도가 느려집니다. 반대로 최근 몇 turns만 유지하면, 초기에 설정한 중요한 정보들이 forgotten context에 빠집니다.
State Explosion: 대화 중에 추적해야 할 상태 변수들이 exponentially 증가하는 문제입니다. “사용자의 선호도”, “선택된 옵션들”, “이전 결정들”, “에러 상황들”, “사용자의 감정 상태” 등이 모두 상태로 관리되어야 합니다. 이들을 정확히 추적하지 못하면 inconsistency가 발생합니다.
2. OpenClaw 메모리 아키텍처: 다층 설계
OpenClaw는 이러한 멀티턴 대화의 복잡성을 해결하기 위해 multi-layered memory architecture를 설계했습니다. 각 layer는 서로 다른 시간 스케일과 정보 밀도로 작동합니다.
2.1 Layer 1: Session Transcripts (단기 메모리)
가장 최하단에는 session transcripts가 있습니다. 이것은 현재 대화의 전체 기록입니다. 사용자 메시지와 AI 응답이 시간 순서대로 저장됩니다.
특징:
– Retention: 현재 세션이 지속되는 동안만 유지
– Granularity: turn-by-turn 기록 (모든 세부사항 포함)
– Access Pattern: 매우 빠름 (in-memory storage)
– Storage Size: context window 크기까지만 관리 가능
예시:
User: "서울에서 부산으로 배송할 상품을 찾아줄 수 있어?"
AI: "물론입니다. 어떤 상품을 찾으시나요?"
User: "전자제품이고, 2만원대 가격대입니다"
AI: "(검색 결과 제시)
User: "이 상품으로 주문 진행할게"2.2 Layer 2: Daily Notes (중기 메모리)
OpenClaw의 혁신적인 설계 중 하나는 daily notes입니다. 이것은 한 날짜(YYYY-MM-DD) 동안의 모든 상호작용을 요약한 것입니다. “오늘 사용자와 무엇을 논의했는가?”를 한눈에 파악할 수 있습니다.
Key Features:
Automatic Summarization: 각 session 종료 시, AI가 그 session의 key points를 추출합니다. 예를 들어:
“2026-02-28: (1) 부산 배송 상품 검색 – 전자제품 2만원대 선택 (2) 배송 주소 확인 및 변경 (3) 결제 수단 설정 완료”
Searchability: “지난주에 부산으로 뭔가 주문했었나?”라는 질문에 대해, 시스템은 daily notes를 검색하여 “2026-02-22의 일일 기록에 부산 배송 관련 내용이 있다”는 것을 빠르게 찾을 수 있습니다.
Temporal Ordering: 시간의 흐름을 보존합니다. “처음에는 X를 선택했다가 나중에 Y로 변경했다”는 사실이 명확하게 기록됩니다.
2.3 Layer 3: Long-term Memory (MEMORY.md)
가장 중요한 layer는 long-term persistent memory입니다. OpenClaw에서는 이것을 MEMORY.md라는 파일로 관리합니다.
MEMORY.md는 단순한 노트 파일이 아닙니다. 이것은 다음과 같은 정보를 저장합니다:
User Profile:
– 이름, 선호도, 관심사
– 이전에 중요하다고 판단된 의사결정
– 반복적인 패턴들 (예: “항상 저녁 7시 이후에 연락을 원함”)
– 신뢰 관계 (예: “이 사용자는 A라는 추천에 매우 신뢰한다”)
Domain Knowledge:
– 사용자의 비즈니스 또는 관심사에 대한 배경지식
– 이전에 수행한 프로젝트들의 결과
– 중요한 제약조건들 (예: “예산은 최대 1000만원”)
Decision Logs:
– “2월 25일에 프로젝트 A에 가입하기로 결정함”
– “SOUL.md에서 중요 원칙들이 수정됨”
– “사용자의 우선순위가 변경됨”
예시 MEMORY.md 구조:
## User Profile
- Name: 김개발
- Role: DevOps Engineer
- Key Interest: Cloud Architecture, Cost Optimization
- Decision Pattern: 데이터 기반 의사결정을 선호하며, ROI를 매우 중시함
## Domain Knowledge
- Current Project: K사 클라우드 마이그레이션 (진행률 60%)
- Constraint: 월 클라우드 비용은 50만원 이하로 제한
## Recent Decisions
- 2026-02-25: AWS RDS 대신 Aurora Serverless 선택
- 2026-02-23: 자동 스케일링 활성화2.4 Layer 4: Persistent Database (초장기 메모리)
최상단에는 완전한 backup을 위한 database layer가 있습니다. 모든 대화, 의사결정, 상태 변화가 영구적으로 저장됩니다. 이것은 system failure recovery나 audit trail을 위해 필수적입니다.
3. Context 일관성 유지 전략
3.1 Dynamic Context Window Population
LLM에 전달하는 context를 동적으로 구성하는 것이 핵심입니다. 사용자의 질문이 들어오면, 시스템은 다음과 같은 결정을 합니다:
Step 1: Relevance Scoring
“사용자의 이번 질문과 관련된 정보는 무엇인가?”를 판단합니다. 예를 들어, “배송 주소 확인해주세요”라는 질문이 들어오면, 시스템은 배송 관련 정보를 높은 점수로 평가합니다.
Step 2: Temporal Weighting
최근 정보가 오래된 정보보다 중요하다고 가정합니다. 하지만 모든 경우에 그런 것은 아닙니다. “사용자는 서울에 산다”는 초기에 언급된 정보는 최근 정보보다 더 중요할 수 있습니다.
Step 3: Conflict Resolution
만약 turn 1에서 “서울에 산다”고 했는데, turn 5에서 “부산으로 이사했다”고 했다면, 어느 것이 현재의 truth인가? 시스템은 최신 정보를 우선하되, 변경 사실 자체를 모델에 알립니다: “사용자는 원래 서울에 살았으나, 최근 부산으로 이사했습니다.”
3.2 Explicit State Tracking
implicit하게 정보가 숨어있는 것보다, explicit하게 state를 선언하는 것이 훨씬 안전합니다.
예를 들어:
CURRENT_SESSION_STATE {
shipping_address: "서울시 강남구",
shipping_address_updated_at: "turn 3",
product_selected: true,
product_id: "PROD-12345",
payment_method: "CARD",
payment_method_last_confirmed: "turn 7"
}이렇게 명시적으로 상태를 추적하면, 모델은 “지금 배송 주소는 무엇인가?”를 추측할 필요가 없습니다. JSON 또는 structured format으로 상태를 선언합니다.
3.3 Memory Update Protocol
conversation이 진행되면서 memory를 업데이트하는 protocol이 필요합니다:
After Each Turn:
1. 사용자의 입력과 AI의 응답을 session transcript에 저장
2. 상태 변화가 있었는지 감지
3. 상태 변화가 있었다면 CURRENT_SESSION_STATE 업데이트
4. 새로운 정보 학습 (예: “이 사용자는 저녁 시간을 선호한다”)
After Session Ends:
1. 전체 session을 요약
2. daily notes에 추가
3. MEMORY.md를 업데이트할 필요가 있는지 판단 (장기적으로 중요한 정보만)
4. database에 완전한 기록 저장
4. 실전 구현 패턴과 Best Practices
4.1 System Prompt Design
멀티턴 대화에서 consistency를 유지하려면, system prompt에서 명확히 지시해야 합니다:
You are an AI assistant managing a multi-turn conversation. When responding:
1. ALWAYS reference the CURRENT_SESSION_STATE to understand the current context
2. If there's a conflict between old and new information, prioritize new information
3. EXPLICITLY ACKNOWLEDGE state changes (e.g., "I see you've changed the shipping address to Busan")
4. If you're uncertain about current state, ask for clarification instead of guessing
5. Maintain consistency with previous decisions unless explicitly told otherwise4.2 Conversation Flow Management
turn-by-turn processing에서 consistent하게 유지하기:
Input Processing:
User Input → Parse Intent → Extract Entities → Check Against Current State
Response Generation:
Generate Response → Validate Against State → Check for Conflicts → Output
State Update:
After each turn, update session state based on new information
4.3 Error Recovery
만약 inconsistency가 감지되면 어떻게 할 것인가?
Detection: “시스템이 생성한 응답에 이전과 모순되는 정보가 포함되었다”를 감지
Recovery: “죄송합니다. 제가 실수했습니다. 현재 배송 주소는 [정확한 주소]입니다.”로 재응답
Logging: 이러한 error를 기록하여 추후 분석
5. 성능 최적화 및 모니터링
5.1 Context Window 효율화
context가 한정되어 있으므로, 가장 중요한 정보들만 priority 높게 할당합니다:
Priority 1 (Critical): Current session state, explicit user constraints
Priority 2 (Important): Today’s notes, recent decisions
Priority 3 (Background): User profile, domain knowledge
Priority 4 (Reference): Historical data, past decisions
5.2 Retrieval-Augmented Generation (RAG)
만약 사용자가 “3주 전에 논의한 프로젝트의 예산이 뭐였어?”라고 물으면, system은:
1. Query embedding 생성
2. Daily notes에서 semantic search
3. 관련 notes들을 context에 추가
4. 응답 생성
이 방식으로 전체 대화 기록을 context에 올리지 않고도 필요한 정보만 efficiently 검색할 수 있습니다.
5.3 모니터링 메트릭스
Consistency Score: “AI가 생성한 응답이 이전 정보와 얼마나 일관성 있는가?”를 측정. 0~1 사이의 값으로 표현
Memory Hit Rate: “사용자의 질문에 필요한 정보가 몇 %의 시간에 memory에서 correctly retrieved되었는가?”
State Freshness: “current session state가 실제 상황과 얼마나 up-to-date한가?”
Context Utilization: “사용되는 context의 token 수”와 “응답 품질” 사이의 trade-off 분석
결론
멀티턴 대화 시스템은 단순한 chat interface를 넘어, 복잡한 state management와 memory architecture의 orchestration을 요구합니다. OpenClaw의 다층 메모리 구조 (Session Transcripts → Daily Notes → MEMORY.md → Database)는 이러한 복잡성을 체계적으로 관리합니다.
핵심은 다음과 같습니다:
1) 명시적인 state tracking을 통해 guessing을 최소화
2) 다양한 시간 스케일에서 정보를 효율적으로 저장
3) dynamic context population으로 context window 활용 최적화
4) 감지된 inconsistency에 대한 빠른 recovery
5) 지속적인 모니터링과 개선
이러한 principles을 따르면, 단순히 “응답하는” AI가 아니라 “기억하고 학습하며 일관성 있게 대응하는” AI 에이전트를 만들 수 있을 것입니다. Production 환경에서 사용자와 장시간 신뢰 관계를 유지하는 것이 가능해집니다.
Tags: AI에이전트,멀티턴대화,메모리아키텍처,Context관리,SessionState,LongTermMemory,MEMORY관리,ConversationConsistency,DialogueSystem,ProducationAI
