AI 에이전트 핸드오프 상태(handoff state)는 재미있는 OpenClaw 데모와 신뢰할 수 있는 멀티 에이전트 시스템(multi-agent system)을 구분 짓는 핵심 요소입니다.

에이전트 하나라면 스레드 메모리(thread memory)만으로도 충분할 수 있습니다.

하지만 에이전트 세 개라면 보통 불가능합니다.

에이전트들이 업무를 공유하기 시작하면, 사실 관계와 산출물(artifacts)을 위한 구조화된 공유 메모리(shared memory)가 필요합니다. 매주 점점 더 느려지고, 비용이 많이 들며, 신뢰도가 떨어지는 100k-토큰 분량의 대화 기록(transcript)이 아니라 말이죠.

저는 OpenClaw 설정에서 동일한 실패 패턴을 계속 목격하고 있습니다.

첫 번째 에이전트는 정말 놀랍습니다.

사양(specs)을 작성하고, 외부 발송 초안을 잡고, 버그를 분류(triage)합니다. 어려운 작업은 Claude나 GPT-5로 넘깁니다. 마치 치트키를 찾은 것 같은 기분이 듭니다.

그다음 두 번째 에이전트를 추가합니다.

그다음 리뷰어(reviewer)를 추가합니다.

그다음 리서처(researcher)를 추가합니다.

그다음 Discord나 Slack에 업데이트를 게시하는 무언가를 추가합니다.

이제 시스템은 단순히 고장 난 수준이 아닙니다. 고장 난 것보다 더 심각합니다.

불안정(flaky)해집니다.

한 에이전트가 중요한 무언가를 발견했는데, 다음 에이전트는 마치 그런 일이 전혀 없었던 것처럼 행동합니다. 혹은 잘못된 세부 사항을 기억합니다. 아니면 모든 대화 기록(transcript)을 모든 프롬프트(prompt)에 쑤셔 넣어서 이를 "해결"하려고 하는데, 그러면 이제 지연 시간(latency)이 급증하고, 토큰 사용량이 엉망이 되며, 여러분의 오케스트레이션(orchestration)은 오래된 컨텍스트(context)를 가지고 벌이는 인질 협상처럼 느껴지기 시작합니다.

그때가 바로 OpenClaw가 프롬프트(prompt)의 문제가 아니라 시스템(systems)의 문제가 되는 시점입니다.

이 문제를 조사하던 중, r/openclaw에서 누군가 올린 아주 적절한 질문이 담긴 스레드를 발견했습니다:

진정한 구분점은 단일 에이전트(one-agent) 대 다중 에이전트(multi-agent)의 문제가 아닙니다.

그것은 바로 다음과 같습니다:

• 스레드 범위 메모리 (thread-scoped memory)
• 스레드 간 공유 메모리 (cross-thread shared memory)

만약 당신의 리서치 에이전트(research agent)가 경쟁사의 가격 페이지를 찾아냈다면, 당신의 코딩 에이전트(coding agent)에게 그 결과에 도달하기까지의 전체 채팅 내용이 필요하지는 않을 것입니다.

에이전트에게 필요한 것은 다음과 같은 형태입니다:

{
  "fact": "경쟁사 X는 10k 실행당 월 $99를 청구함",
  "source": "https://example.com/pricing",
...

이것이 핸드오프 (handoff)입니다.

전체 대화 기록 (transcript)은 핸드오프가 아닙니다.

네, Claude는 거대한 프롬프트를 처리할 수 있습니다. 하지만 그것이 핵심이 아닙니다.

이 지점에서 사람들이 혼란을 겪습니다.

Anthropic은 Claude가 매우 큰 프롬프트를 처리할 수 있음을 보여주었습니다. 그들의 이전 100k 컨텍스트 (context) 발표에서는 100,000 토큰을 대략 75,000 단어로 정의했습니다. 또한 그들은 '위대한 개츠비'의 72k 토큰 사본을 스캔하는 것과 같은 긴 컨텍스트 검색 (long-context retrieval) 예시를 보여주기도 했습니다.

따라서 네, 거대한 프롬프트는 실재합니다.

그리고 어떤 워크로드 (workloads)에서는 그것으로 충분합니다.

만약 다음과 같은 상황이라면:

• 단일 에이전트
• 하나의 제한된 코퍼스 (bounded corpus)
• 깔끔하게 초기화되는 하나의 워크플로 (workflow)

그렇다면 프롬프트 스터핑 (prompt stuffing)이 가장 단순하고 올바른 정답이 될 수 있습니다.

Anthropic은 또한 프롬프트 캐싱 (prompt caching)을 통해 반복되는 긴 프롬프트에 대한 지연 시간 (latency)과 비용을 상당히 줄일 수 있다고 지적합니다.

그것은 모두 사실입니다.

하지만 지속적인 다중 에이전트 (multi-agent) 작업이 시작되면, 이는 아키텍처 (architecture)로서 무너지게 됩니다.

왜냐하면 그때부터 당신의 대화 기록 (transcript)은 다음과 같이 변하기 때문입니다:

• 실행할 때마다 더 커지고
• 실행할 때마다 관련성이 떨어지며
• 실행할 때마다 신뢰하기 어려워지고
• 실행할 때마다 비용이 더 많이 듭니다.

LangGraph는 긴 히스토리 (histories)가 지연 시간과 비용을 증가시키고, 컨텍스트 윈도우 (context windows)를 초과하며, 모델이 오래되거나 관련 없는 콘텐츠에 주의를 빼앗겨 모델 성능을 저하시킨다고 명시적으로 경고합니다.

이는 사람들이 실제 운영 환경 (production)에서 목격하는 현상과 일치합니다.

Reddit 게시물들은 매우 빠르게 데모 수준을 벗어납니다

내 주의를 끈 것은 OpenClaw 사용자들이 이미 장난감 프로젝트 수준의 수치가 아닌, 실제 지출 규모에 대해 이야기하고 있다는 점입니다.

한 r/openclaw 스레드에서 한 사용자는 다음과 같이 말했습니다:

한 달에 약 3,000달러 정도입니다. GTM(Go-To-Market), 제품 개발(대부분 사양 정의, 코딩은 Claude/Codex/GHCP가 수행), 영업... 작업에 따라 멀티 모델(Multi model)을 사용합니다. 이 비용을 지불할 가치가 있는지 완전히 확신할 수는 없습니다. 하지만 많은 작업을 더 쉽고 빠르게 만들어주며, 이는 매우 귀중한 가치입니다.

다른 사용자는 다음과 같이 말했습니다:

저희는 이것을 사용하여 기본적으로 부동산 중개업, 부동산 투자 사업, 그리고 "Homies AI"라고 불리는 부동산 중개인용 OpenClaw SaaS 제품을 구축하고 운영하고 있습니다. 비즈니스 운영을 위한 비용 소모율(burn rate)은 연간 약 30,000달러 정도이며, 사업 수익은 연간 약 500,000달러 정도입니다.

그리고 또 다른 스레드에서는:

4개월 전 OpenClaw를 설치한 이후, OpenRouter를 통해 토큰(tokens) 비용으로 10,000달러 이상을 지출했습니다.

이것이 사람들이 놓치는 부분입니다.

에이전트(agents)가 실제 업무에 투입되면, 메모리 설계(memory design)는 비용 결정의 문제가 됩니다.

잘못된 핸드오프(handoffs)는 단순히 지저분한 것에 그치지 않습니다.

비용이 많이 듭니다.

그것이 바로 가격 책정이 중요해지는 이유입니다. 만약 에이전트가 끊임없이 요약(summarizing)하고, 다시 읽고(re-reading), 다시 핸드오프(re-handoffing)하며, 거대한 프롬프트(prompts)를 계속 들고 다닌다면, 토큰당 과금(per-token billing) 방식은 모든 아키텍처(architectural) 실수를 응징하게 됩니다. OpenClaw, n8n, Make, Zapier 또는 커스텀 워크플로우(custom workflows)에서 멀티 에이전트 자동화(multi-agent automations)를 실행하는 팀들은 이를 뼈저리게 느낍니다.

이것이 정액제 API 액세스(flat-rate API access)가 흥미로운 이유이기도 합니다. 에이전트 아키텍처를 반복 개선(iterating)하고 많은 재시도(retries), 요약(summarization), 라우팅(routing), 도구 호출(tool calls)을 수행하고 있다면, 예측 가능한 비용은 사람들이 인정하는 것보다 훨씬 더 중요합니다. Standard Compute는 기본적으로 이러한 종류의 워크로드(workload)를 위해 구축되었습니다: OpenAI 호환 API, 고정된 월간 가격, 그리고 에이전트 시스템을 튜닝(tuning)하는 동안 토큰당 비용에 대해 불안해할 필요가 없습니다.

한 에이전트가 실제로 다른 에이전트에게 무엇을 전달해야 하는가?

OpenAI의 Agents SDK는 이 부분에 대해 깔끔한 사고 모델(mental model)을 제공합니다.

이는 다음을 분리합니다:

• 핸드오프 (handoffs): 다음에 누가 제어권을 가질 것인가
• 세션 (sessions): 실행(run) 또는 스레드(thread)를 위한 대화 기록
• 애플리케이션 상태 (application state): 모델로 전송해서는 안 되는 로컬 상태

이러한 구분은 매우 가치가 있습니다.

모든 상태가 프롬프트(prompt)에 포함될 필요는 없기 때문입니다.

분리해서 유지해야 할 3가지 범주

1. 모델 가시적 대화 상태 (Model-visible conversational state)

다음 에이전트가 진정으로 읽어야 하는 내용입니다.

예시:

• 현재 작업 (current task)
• 최근 결정 사항 (recent decisions)
• 요약된 요약 (a compact summary)
• 명시적 제약 조건 (explicit constraints)

2. 신뢰할 수 있는 애플리케이션 상태 (Trusted application state)

앱에는 필요하지만, 모델이 글자 그대로 (verbatim) 알 필요는 없는 것들입니다.

예시:

• 인증 토큰 (auth tokens)
• 내부 ID (internal IDs)
• 워크플로 플래그 (workflow flags)
• 속도 제한 카운터 (rate limit counters)
• 고객 계정 메타데이터 (customer account metadata)

3. 공유된 영구 지식 (Shared durable knowledge)

다른 에이전트들이 나중에 필요할 수 있는 것들입니다.

예시:

• 추출된 사실 (extracted facts)
• 승인된 결정 (approved decisions)
• 소스 링크 (source links)
• 생성된 결과물 (generated artifacts)
• 검증된 출력 (verified outputs)

이 세 가지를 하나의 거대한 프롬프트 덩어리 (prompt blob)로 합쳐버리면, 최악의 조합이 발생합니다:

• 더 많은 토큰 소모
• 제어력 감소
• 신뢰도 저하
• 디버깅의 어려움

최소한의 핸드오프 패턴 (A minimal handoff pattern)

더 나은 핸드오프의 형태를 보여주는 작은 Python 예시입니다.

from dataclasses import dataclass
from typing import Literal

...

이제 다음 에이전트는 이를 생성해낸 전체 인지적 혼란 (cognitive mess)이 아니라, 유용한 출력값만을 전달받게 됩니다.

실무적인 OpenClaw 메모리 레이아웃 (A practical OpenClaw memory layout)

만약 제가 오늘 이것을 구현한다면, 다음과 같은 구조를 사용할 것입니다:

openclaw-memory/
├── threads/
│   ├── thread_123.json
...

그리고 흐름은 다음과 같을 것입니다:

1. 스레드 메모리 (Thread memory)가 현재 실행의 일관성을 유지합니다.
2. 각 에이전트는 구조화된 결과물 (structured artifacts)을 생성합니다.
3. 결과물은 중앙에 저장됩니다.
4. 검색 (Retrieval) 단계에서 다음 에이전트에게 필요한 관련 결과물만 선택합니다.
5. 오래되었거나 신뢰도가 낮은 결과물은 정리 (pruned)됩니다.

마지막 단계가 매우 중요합니다.

모든 미완성된 생각들을 공유 저장소에 넣게 되면, 공유 저장소는 두 번째 잡동사니 서랍 (junk drawer)으로 변질될 수 있습니다.

예시: 채팅을 전달하지 말고, 결과물을 전달하세요

나쁜 핸드오프:

"여기 리서치 에이전트의 마지막 메시지 14개와 8개의 웹 스니펫, 
3개의 버려진 아이디어, 그리고 요약의 요약본이 있습니다. 이 모든 것을 사용하여 명세서를 작성하세요."

더 나은 핸드오프:

{
  "task": "경쟁사 모니터링 작업을 위한 구현 명세서 작성",
  "constraints": [
...

이 방식이 더 짧고, 명확하며, 저렴하고, 디버깅하기 쉽습니다.

오후 한나절이면 로컬에서 프로토타입을 만들 수 있습니다

Python, SQLite, 그리고 JSON을 사용한 매우 간단한 설정만으로도 이 패턴을 증명하기에 충분합니다.

기본 사항 설치:

python -m venv .venv
source .venv/bin/activate
pip install sqlite-utils pydantic

작은 아티팩트 저장소 (artifact store) 생성:

import sqlite3
import json

...

다음 에이전트에게 필요한 것만 검색:

import sqlite3

conn = sqlite3.connect("memory.db")
...

이것만으로도 원본 대화 기록 (raw transcripts)을 계속 전달하는 것보다 이미 더 낫습니다.

어떤 메모리 패턴이 실제로 승리할까요?

제 의견은 간단합니다.

좁은 작업에 대해 하나의 에이전트를 테스트 중이라면, 거대한 프롬프트를 사용하고 넘어가십시오.

여러 전문가가 포함된 OpenClaw 워크플로우를 구축 중이라면, 공유 대화 기록 (shared transcript)은 잘못된 아키텍처입니다.

다음을 사용하십시오:

• 연속성을 위한 스레드 메모리 (thread memory)
• 지속적인 지식을 위한 공유 저장소 (shared store)
• 핸드오프 (handoff)를 위한 선택적 검색 (selective retrieval)

그것이 데모와 시스템을 가르는 경계선입니다.

진짜 문제는 저장 공간이 아니라 신뢰입니다

에이전트 핸드오프 (agent handoff)에서 가장 어려운 질문은 이것이 아닙니다:

"에이전트 B가 에이전트 A가 본 것에 접근할 수 있는가?"

진짜 질문은 이것입니다:

"에이전트 B가 무엇을 신뢰할 수 있는가?"

원본 대화 기록 (raw transcript)은 그 질문에 답하는 데 매우 형편없습니다.

그것은 다음을 뒤섞어 버립니다:

• 사실 (facts)
• 추측 (guesses)
• 포기된 계획 (abandoned plans)
• 일시적인 혼란 (temporary confusion)
• 세 번의 실행 전에 사라졌어야 할 오래된 컨텍스트 (old context)

구조화된 메모리 계층 (structured memory layer)이 더 나은 이유는 지식에 메타데이터 (metadata)를 붙일 수 있기 때문입니다:

• 소스 URL (source URL)
• 작성 에이전트 (authoring agent)
• 타임스탬프 (timestamp)
• 신뢰도 (confidence)
• 승인 상태 (approval state)
• 최신성 (freshness)

이것이 멀티 에이전트 시스템 (multi-agent systems)을 견고하게 만드는 요소입니다.

더 많은 컨텍스트가 아니라,
더 나은 계약 (contracts)입니다.

이번 주에 제가 OpenClaw 설정을 수정한다면

현재 설정이 불안정하다면, 저는 여기서부터 시작하겠습니다:

1. 에이전트 간에 전체 트랜스크립트 (transcripts)를 전달하는 것을 중단하십시오.
2. 사실 (facts), 결정 (decisions), 출력물 (outputs)을 위한 구조화된 아티팩트 스키마 (artifact schema)를 추가하십시오.
3. 공유 메모리 (shared memory)에는 내구성이 있는 아티팩트 (durable artifacts)만 저장하십시오.
4. 승인되었거나 신뢰도가 높은 아티팩트 (artifacts)만 검색하십시오.
5. 오래된 쓰레기 데이터가 계속 다시 나타나지 않도록 TTL (Time To Live) 또는 만료 마커 (stale markers)를 추가하십시오.
6. 앱 상태 (app state)를 프롬프트 (prompts)에서 제외하십시오.
7. 실행당 프롬프트 크기와 핸드오프 (handoff) 크기를 측정하십시오.

단 하나의 직설적인 규칙을 원하신다면 다음과 같습니다:

모든 에이전트는 다른 에이전트가 전체 배경 이야기 (backstory)를 읽지 않고도 소비할 수 있는 아티팩트 (artifacts)를 생성해야 합니다.

그것이 바로 중요한 아키텍처 (architecture)의 변화입니다.

그리고 이러한 시스템을 대규모로 운영하고 있다면, 이 지점에서 API 가격 책정은 더 이상 부차적인 문제가 아닙니다. 멀티 에이전트 (multi-agent) 워크플로우는 자연스럽게 재시도 (retries), 요약 (summaries), 핸드오프 (handoffs), 그리고 장기 실행 자동화 루프 (long-running automation loops)를 생성합니다. 토큰당 과금 방식은 이 모든 과정을 스트레스 상황으로 만듭니다. 에이전트가 24시간 내내 작동하고 모든 설계 선택이 예상치 못한 청구서로 돌아오는 것을 원치 않는다면, 예측 가능한 정액제 컴퓨팅 (flat-rate compute)이 훨씬 더 적합합니다.

이것이 바로 바로 이 사용자층을 위한 Standard Compute의 매력입니다. 이는 AI 에이전트와 자동화를 위해 구축되었으며, 정액제 월간 요금제를 제공하는 바로 가져다 쓸 수 있는 (drop-in) OpenAI 호환 API입니다. 만약 OpenClaw를 n8n, Make, Zapier 또는 커스텀 오케스트레이터 (orchestrators)에 연결하고 있다면, 무제한 컴퓨팅을 갖는 것은 메모리 아키텍처 (memory architecture)를 얼마나 공격적으로 테스트하고 개선할 수 있는지를 변화시킵니다.

중요한 변화는 이것입니다:

사람들은 더 많은 메모리가 필요하다고 생각합니다.

하지만 대개 그들에게 필요한 것은 더 나은 핸드오프 (handoffs)입니다.

그리고 일단 그것을 깨닫고 나면, 멀티 에이전트 (multi-agent) 시스템의 많은 기이한 현상들이 갑자기 이해되기 시작할 것입니다.