The Log Is The Agent: 로그 중심 AI 에이전트 아키텍처
AI 에이전트의 지속성, 소유권, 재현성, 포크, 디버깅 가능성을 모델이 아니라 append-only 이벤트 로그 중심으로 재설계해야 한다는 주장과 근거를 정리한 리포트.
The Log Is The Agent: 로그 중심 AI 에이전트 아키텍처
한 줄 요약
AI 에이전트를 오래 실행하고, 중단 뒤 재개하고, 다른 모델로 옮기고, 여러 갈래로 실험하고, 누가 무엇을 했는지 검증하려면 모델 호출 루프가 아니라 사용자가 소유한 append-only 이벤트 로그를 시스템의 원장으로 삼아야 한다.
먼저 읽을 결론
영상의 핵심 주장은 "로그를 잘 남기자"가 아니다. 더 정확한 주장은 에이전트의 지속 가능한 정체성은 모델, 런타임, 샌드박스가 아니라 append-only session event log에서 나온다는 것이다.
이 주장은 기존 소프트웨어 아키텍처의 Event Sourcing, 데이터베이스 commit log, durable execution과 같은 계보 위에 있다. Martin Fowler는 Event Sourcing을 애플리케이션 상태 변경을 이벤트 시퀀스로 저장하고 그 로그로 과거 상태를 재구성하는 패턴으로 설명한다. Jay Kreps도 로그를 append-only, ordered record sequence로 보며 데이터 시스템의 핵심 추상화로 설명했다. Temporal은 Workflow Event History를 crash recovery와 replay의 기반으로 사용한다.
AI 에이전트에 이 관점을 적용하면 구조가 선명해진다.
Canonical event log
-> model context projection
-> UI transcript projection
-> memory / vector index projection
-> audit / trace / eval projection
-> fork / replay / migration adapter
-> effect ledger for external side effects
중요한 보정은 하나다. 에이전트의 정체성을 "로그만"으로 좁히면 외부 세계의 부작용을 놓친다. 실제 프로덕션에서는 원본 event log + projections + effect ledger + artifact store를 함께 설계해야 한다. 로그는 세상 전체가 아니라 에이전트가 본 것, 결정한 것, 시도한 것, 승인받은 것, 실패한 것을 보존한다. 이메일 발송, 파일 수정, 결제, GitHub PR 생성처럼 되돌릴 수 없는 일은 별도의 effect ledger로 추적해야 한다.
왜 저장했나
에이전트 인프라는 2026년 현재 "모델을 어떻게 부르느냐"보다 "실행 기록을 누가 소유하고, 어떻게 재개하고, 어떻게 검증하고, 어떻게 옮길 수 있느냐"가 더 중요한 문제로 이동하고 있다. Anthropic Managed Agents는 session, harness, sandbox를 분리하며 session을 append-only log로 설명한다. LangGraph는 checkpoint와 time travel을 제공하고, OpenAI Agents SDK는 run state, interruptions, tracing을 제공하며, Google ADK는 session events와 state, memory를 구분한다.
따라서 이 영상은 제품 홍보성 주장을 넘어, 장기 실행 에이전트 설계에서 기록 계층을 어떻게 잡아야 하는지 묻는 좋은 출발점이다.
정리한 질문
AI 에이전트의 신뢰성, 포크, 마이그레이션, 멀티플레이어 협업, 소유권을 보장하려면 "에이전트는 로그다"라는 관점을 어떤 아키텍처와 운영 원칙으로 구체화해야 하는가?
핵심 답변
좋은 에이전트 시스템은 대화 transcript를 나중에 저장하는 시스템이 아니라, 처음부터 모든 상태 전이를 typed event로 기록하는 시스템이다. 모델은 로그에서 파생된 context projection을 읽고 다음 행동을 제안한다. 도구 실행기는 그 행동을 실행하고 결과를 다시 로그에 추가한다. UI, 요약 메모리, 벡터 DB, trace, eval dataset은 모두 원본 로그에서 파생된 projection이어야 한다.
이렇게 설계하면 worker는 disposable해진다. 한 worker가 세션을 읽고 한 턴을 진행한 뒤 사라져도, 다른 worker가 같은 로그에서 상태를 재구성해 이어갈 수 있다. 포크도 자연스러워진다. 특정 event까지의 prefix를 공유하고, 그 뒤를 다른 모델, 다른 prompt, 다른 tool policy로 실행하면 된다.
다만 로그 중심 설계가 모든 문제를 자동 해결하지는 않는다. compaction은 손실이 있는 projection이고, 외부 tool side effect는 로그만으로 rollback되지 않는다. 따라서 프로덕션 설계의 핵심은 "로그를 원장으로 둔다"에서 멈추지 않고 schema, lineage, idempotency, approval, side-effect settlement, export, encryption, retention까지 함께 잡는 것이다.
증거 지도
| 주장 | 근거 유형 | 대표 근거 | 신뢰도 | 주의점 |
|---|---|---|---|---|
| 상태 변경을 이벤트 로그로 저장하면 재구성, temporal query, replay가 가능하다. | primary / expert | Martin Fowler, Jay Kreps, Microsoft Azure Event Sourcing pattern | 높음 | 일반 소프트웨어 패턴이지 LLM 에이전트 전용 검증은 아니다. |
| 장기 실행 workflow는 event history와 replay를 통해 crash recovery를 구현할 수 있다. | primary | Temporal Event History docs | 높음 | Temporal의 결정론 제약은 LLM tool call과 다르게 설계해야 한다. |
| Managed Agents 계층에서도 session, harness, sandbox 분리가 중요해지고 있다. | primary vendor docs | Anthropic Managed Agents | 중간-높음 | 벤더 문서이므로 제품 우수성 주장은 별도 검증 필요. |
| 에이전트 실행에서 replay, fork, lineage를 event log 중심으로 구현할 수 있다. | academic / code | ActiveGraph paper and repo, AgentGit | 중간 | 2025-2026 preprint 성격이 강하고 peer review 상태 확인 필요. |
| 외부 tool side effect는 로그 replay만으로 안전해지지 않는다. | academic | Atomix transactional tool use | 중간 | 논문 제안이며 실제 플랫폼별 구현 난도는 별도 검증 필요. |
| 장기 memory는 poisoning과 provenance 문제가 있다. | academic / security | Memory Poisoning, MemLineage | 중간 | 공격 조건, 모델, 데이터셋에 따라 위험도와 방어 성능이 달라진다. |
| tracing/observability는 필요하지만 canonical state log와 다르다. | primary docs | OpenTelemetry GenAI, Langfuse, Phoenix, OpenAI tracing docs | 높음 | trace는 보통 관측 projection이며 원장 역할을 자동 보장하지 않는다. |
영상 논지 재구성
에이전트는 모델이 아니라 지속되는 작업 이력이다
영상은 게임 캐릭터 비유로 시작한다. 콘솔이나 게임 엔진이 캐릭터의 정체성이 아니라 save file이 캐릭터를 이어가게 한다는 비유다. AI 에이전트도 마찬가지로 모델, runtime, sandbox, tool runner가 중요하지만 그것들이 정체성은 아니다. 정체성은 세션을 복원할 수 있게 하는 데이터, 더 구체적으로는 append-only event history에 있다.
로그에는 사용자 입력, 모델 출력, 도구 호출, 도구 결과, 권한 요청, 실패, 외부 관찰, 정책 판단, 요약, branch 생성 같은 상태 전이가 순서대로 들어간다. 모델과 도구는 이 로그를 해석하고 다음 event를 쓰는 컴포넌트일 뿐이다.
Projection을 원본으로 착각하면 안 된다
에이전트 시스템에서 흔히 원본처럼 보이는 것들은 대부분 projection이다.
| 계층 | 원본인가 | 설명 |
|---|---|---|
| Model context | 아니다 | 원본 로그 중 현재 모델에 넣을 부분만 골라 만든 view다. |
| UI transcript | 아니다 | 사용자가 보기 좋게 렌더링한 대화 화면이다. |
| Summary memory | 아니다 | 원본 로그를 손실 압축한 요약이다. |
| Vector index | 아니다 | 검색을 위해 만든 파생 색인이다. |
| Trace dashboard | 보통 아니다 | 관측과 디버깅용 projection이다. |
| Eval dataset | 아니다 | 과거 실행을 평가용 샘플로 뽑아낸 view다. |
| Canonical event log | 맞다 | 모든 projection을 다시 만들 수 있어야 하는 원장이다. |
이 구분이 compaction 논쟁의 핵심이다. context window가 유한하므로 요약은 필요하다. 하지만 요약은 원본을 대체하지 못한다. 요약 event는 어떤 event range를 요약했는지, 어떤 모델과 prompt로 만들었는지, 어떤 정보가 빠졌을 수 있는지를 lineage로 남겨야 한다.
외부 세계는 effect ledger가 필요하다
로그는 세상 전체가 아니다. 에이전트가 파일을 고치고, 이메일을 보내고, 결제를 요청하고, GitHub issue를 만들면 로그 바깥의 상태가 바뀐다. 포크로 과거로 돌아가도 보낸 이메일은 사라지지 않는다.
그래서 로그 중심 설계에는 effect ledger가 붙어야 한다. 각 tool call에 대해 다음 정보를 남긴다.
| 필드 | 이유 |
|---|---|
effect_id | 외부 부작용의 고유 식별자 |
idempotency_key | retry 중복 실행 방지 |
resource_id | 어떤 외부 자원이 바뀌었는지 추적 |
approval_event_id | 누가 어떤 근거로 승인했는지 추적 |
commit_status | pending, committed, compensated, failed 구분 |
rollback_plan | 보상 가능 여부와 방법 기록 |
branch_id | 어떤 branch에서 발생한 부작용인지 기록 |
Atomix 논문이 다루는 문제도 이 지점과 맞닿아 있다. 일반적인 orchestrator가 tool return을 곧 settlement로 취급하면 실패, speculation, 경쟁 조건에서 partial effect나 losing-branch residue가 남을 수 있다. 로그가 에이전트라는 주장에 effect ledger를 붙여야 하는 이유다.
실제 업계 움직임
Anthropic Managed Agents
Anthropic은 Managed Agents 글에서 agent component를 session, harness, sandbox로 나눈다. 여기서 session은 append-only log, harness는 Claude를 호출하고 tool call을 route하는 loop, sandbox는 코드 실행과 파일 편집 환경이다. 이 분리는 영상의 주장과 거의 같은 방향이다. agent를 프로세스나 container에 묶지 않고, session을 지속 계층으로 올리는 접근이다.
LangGraph
LangGraph는 persistence를 checkpointer와 store로 나눈다. checkpointer는 thread-scoped graph state snapshot을 저장하고, conversation continuity, human-in-the-loop, time travel, fault tolerance에 쓰인다. time travel 문서는 replay와 fork를 checkpoint 기반으로 설명한다.
영상의 관점에서 보면 LangGraph는 이미 중요한 능력을 제공하지만, checkpoint가 곧 canonical event log라는 뜻은 아니다. checkpoint는 state snapshot에 가까운 경우가 많다. 로그 중심 아키텍처를 원한다면 checkpoint 뒤에 어떤 event 원장이 있고, snapshot이 어떤 event range의 projection인지 명확히 해야 한다.
OpenAI Agents SDK
OpenAI Agents SDK는 서버가 orchestration, tool execution, state, approvals를 소유하는 경우에 맞는 경로를 제공한다. human-in-the-loop 문서는 민감한 tool call을 pending approval로 멈추고, RunState로 serialize/resume하는 흐름을 설명한다. tracing은 LLM generation, tool call, handoff, guardrail, custom event를 관측할 수 있게 한다.
여기서도 구분이 필요하다. SDK의 tracing은 매우 유용한 projection이지만, 그것만으로 사용자 소유의 canonical event store가 생기는 것은 아니다. 로그 중심 설계에서는 application이 자신의 event schema와 storage, export 정책을 명시해야 한다.
Google ADK
Google ADK는 session events, session state, long-term memory를 나눈다. 문서상 session.events는 history, session.state는 현재 대화의 scratchpad, MemoryService는 과거 세션이나 지식을 검색 가능한 장기 지식 저장소로 다룬다. 이 구분은 "memory는 원본이 아니라 projection"이라는 관점과 잘 맞는다.
Cloudflare Agents와 Workflows
Cloudflare Agents는 각 agent instance를 Durable Object와 SQLite DB 기반의 stateful execution environment로 제공한다. Workflows는 durable multi-step execution, external event/approval wait, retry, observability를 제공한다.
Cloudflare의 접근은 "agent = durable object"에 가깝고, 영상의 접근은 "agent = log"에 가깝다. 둘은 대립할 필요가 없다. Durable Object는 event log와 projection을 담는 execution/storage primitive가 될 수 있다. 다만 exportability와 migration을 원한다면 내부 상태를 vendor-neutral event log로 추출할 수 있어야 한다.
연구 계보
ReAct, Reflexion, Generative Agents, Voyager
초기 LLM agent 연구는 이미 trajectory의 중요성을 보여줬다. ReAct는 reasoning trace와 action을 섞어 외부 환경과 상호작용하는 trajectory를 만든다. Reflexion은 실패와 feedback을 언어적 reflection으로 남겨 다음 trial에 반영한다. Generative Agents는 agent experiences의 complete record를 저장하고 reflection과 retrieval을 결합했다. Voyager는 환경 feedback, execution error, self-verification, skill library를 통해 장기 학습 흐름을 만든다.
이 연구들은 "로그가 곧 에이전트"라고 말하지는 않는다. 하지만 공통적으로 agent behavior가 단일 모델 호출이 아니라 관찰, 행동, 결과, reflection, memory가 쌓인 trajectory에서 나온다는 점을 보여준다.
ActiveGraph와 The Log is the Agent
ActiveGraph 논문은 영상의 thesis와 가장 직접적으로 맞닿아 있다. 이 논문은 append-only event log를 source of truth로 삼고, working graph를 그 로그의 deterministic projection으로 정의한다. 핵심 기여는 deterministic replay, cheap fork, lineage다. 다만 논문 자체도 task accuracy 향상 같은 empirical claim을 핵심 기여로 주장하지 않고, substrate와 guarantee를 제안한다는 점을 밝힌다.
AgentGit
AgentGit은 LangGraph 위에 Git-like commit, revert, branch를 얹는 프레임워크다. 여러 trajectory를 비교하고 탐색하는 능력은 "forkable agent"의 실제 구현 방향을 보여준다. 로그 중심 아키텍처에서 branch는 부가 기능이 아니라 기본 기능에 가깝다.
Memory poisoning과 MemLineage
장기 memory를 projection으로 본다면 보안 질문도 바뀐다. "무엇을 기억할 것인가"뿐 아니라 "그 기억은 어디서 왔고, 어떤 근거를 통해 민감한 action을 정당화할 수 있는가"를 물어야 한다. Memory Poisoning 연구는 persistent memory가 공격면이 될 수 있음을 보여주고, MemLineage는 memory entry에 cryptographic provenance와 derivation lineage를 붙이는 방어 방향을 제안한다.
권장 아키텍처
1. Typed event log를 원장으로 둔다
대화 문자열을 JSONL로 쌓는 것만으로는 부족하다. event type과 schema version이 있어야 한다.
{
"event_id": "evt_184",
"session_id": "sess_42",
"branch_id": "main",
"seq": 184,
"timestamp": "2026-07-02T00:00:00Z",
"actor": {
"type": "model",
"id": "agent.coder"
},
"type": "tool.result",
"payload_ref": "artifact://tool-results/evt_184.json",
"caused_by": "evt_181",
"model": {
"provider": "openai",
"name": "gpt-5.5"
},
"effect": {
"effect_id": "eff_77",
"idempotency_key": "github-issue-123",
"external_system": "github",
"commit_status": "committed"
},
"security": {
"trust_level": "mixed",
"redaction_class": "confidential",
"provenance": ["evt_101", "evt_119"]
},
"schema_version": "1.0",
"prev_hash": "sha256:...",
"event_hash": "sha256:..."
}
최소 event type은 다음 정도가 필요하다.
| 영역 | 예시 event |
|---|---|
| 입력 | user.message, system.instruction.updated, policy.decision |
| 모델 | model.requested, model.responded, model.error, model.refused |
| 도구 | tool.proposed, tool.approved, tool.started, tool.result, tool.failed |
| 부작용 | effect.pending, effect.committed, effect.compensated, effect.failed |
| 메모리 | memory.proposed, memory.committed, memory.rejected, summary.created |
| 분기 | branch.created, branch.merged, branch.abandoned |
| 운영 | projection.rebuilt, schema.migrated, failure.recorded |
2. Projection builder를 분리한다
원본 로그를 직접 모든 화면과 모델에 먹이지 말고 목적별 projection을 만든다.
| Projection | 쓰임 | 저장소 후보 |
|---|---|---|
| Model context | 다음 model call 입력 | runtime-built ephemeral view |
| UI transcript | 사용자 화면 | Postgres, document store |
| Memory summary | 장기 기억 후보 | Postgres, object storage |
| Vector index | retrieval | pgvector, Qdrant, Weaviate |
| Audit view | 보안, 승인, 장애 조사 | ClickHouse, OpenSearch, BigQuery |
| Eval dataset | regression, judge calibration | dataset store, object storage |
| Graph state | belief, task, evidence, dependency graph | graph DB or relational projection |
Projection은 언제든 폐기하고 다시 만들 수 있어야 한다. 원본 로그를 버리고 projection만 남기면 migration, fork, audit의 힘이 크게 줄어든다.
3. Compaction은 source replacement가 아니라 summarized fork로 다룬다
Context window 때문에 compaction은 필요하다. 하지만 compaction event는 다음 정보를 가져야 한다.
- 어떤 event range를 요약했는가
- 어떤 모델, prompt, policy로 요약했는가
- 어떤 정보가 보존됐고 무엇이 빠졌을 수 있는가
- 민감 정보는 어떻게 redaction됐는가
- 다음 projection이 이 요약을 원본처럼 취급해도 되는가, 아니면 보조 정보인가
장기 실행 세션이 너무 커지면 Temporal의 Continue-As-New와 비슷하게 새 log로 넘어갈 수 있다. 이때도 parent log, cutoff event, summary lineage를 남겨야 한다.
4. Tool side effect는 transaction과 approval 문제로 본다
도구 결과가 로그에 기록됐다고 해서 외부 세계가 안전해지는 것은 아니다. 따라서 위험 도구는 다음 gate를 통과해야 한다.
- dry-run 가능한가
- idempotency key가 있는가
- user approval이 필요한가
- irreversible effect인가
- branch abandon 시 어떻게 처리할 것인가
- retry 중복 실행을 어떻게 막는가
- external system의 최종 상태를 다시 읽어 검증했는가
파일 편집, 결제, 이메일, PR 생성, 인프라 변경, 고객 데이터 조회는 모두 effect class를 나눠 다뤄야 한다.
5. Ownership은 export 버튼보다 넓다
"로그 소유권"은 단순히 다운로드 가능하다는 뜻이 아니다. 최소 조건은 다음에 가깝다.
- 전체 원본 event export
- artifact까지 포함한 reproducible bundle
- 공개된 event schema와 migration policy
- tenant별 암호화 또는 BYOK
- retention, deletion, legal hold 정책
- provider가 로그를 학습, 분석, 검색에 쓰는지에 대한 명시적 통제
- 외부 audit을 위한 hash chain 또는 signature
- model/provider별 projection adapter
이 조건이 없으면 provider migration은 "adapter 문제"가 아니라 "정체성 이전 문제"가 된다.
실제로 볼 만한 GitHub repository
| Repository | 무엇을 보면 좋은가 | 이 리포트에서의 의미 |
|---|---|---|
| omnara-ai/omnara | Claude Code, Codex CLI, n8n 등을 web/mobile dashboard와 동기화하는 구조 | 영상의 회사/제품 맥락. transcript의 Amnara 표기는 공식 repo 기준 Omnara로 보는 편이 맞다. |
| yoheinakajima/activegraph | event-sourced reactive graph, replay, fork, diff | "log as source of truth"를 가장 직접적으로 구현한 실험체. |
| MAS-Infra-Layer/Agent-Git | LangGraph agent에 Git-like commit, branch, revert를 얹는 방식 | branchable trajectory 설계 참고. |
| langchain-ai/langgraph | checkpointer, persistence, time travel, human-in-the-loop | 현업에서 가장 널리 쓰이는 stateful agent orchestration 축. |
| openai/openai-agents-python | tool, handoff, guardrail, tracing, resumable run state | SDK 기반 agent loop와 approval/resume 구조 참고. |
| openai/openai-agents-js | TypeScript SDK, tracing UI, multi-agent workflows | web/server 제품에서 agent runtime을 붙일 때 참고. |
| cloudflare/agents | Durable Objects 기반 persistent agent runtime | stateful agent primitive와 Cloudflare Workflows 결합 참고. |
| OpenHands/openhands | software engineering agent platform, sandbox, UI, audit trail | 실제 coding agent가 어떤 실행 흔적과 sandbox를 남기는지 확인. |
| SWE-agent/mini-swe-agent | 간단한 agent loop와 SWE-bench 실행 | 최소 agent loop와 trajectory logging을 비교하기 좋다. |
| SWE-bench/experiments | predictions, execution logs, trajectories, results | agent trajectory가 평가 산출물로 어떻게 저장되는지 확인. |
| huggingface/smolagents | 단순한 code-agent abstraction | log-first 구조를 붙이기 전 최소 agent loop를 이해하는 데 좋다. |
| microsoft/agent-framework | production-grade multi-agent workflow 방향 | AutoGen/Semantic Kernel 이후 enterprise agent SDK 흐름. |
| microsoft/autogen | maintenance mode와 migration 맥락 | agent framework가 교체될 때 로그/상태 이전이 왜 중요한지 보여준다. |
| crewAIInc/crewAI | role-playing multi-agent orchestration | role/task 기반 agent framework와 log-first 접근의 차이를 비교. |
| modelcontextprotocol | tool/data integration protocol과 JSON-RPC 기반 메시지 | tool boundary와 event schema 설계 참고. |
| langfuse/langfuse | open-source LLM observability, eval, prompt management | canonical log가 아니라 trace/eval projection 계층으로 참고. |
| Arize-ai/phoenix | AI observability, tracing, evaluation | trace를 model/tool/retrieval debugging view로 보는 데 참고. |
| open-telemetry/semantic-conventions-genai | GenAI spans, metrics, events naming | event/trace field naming을 표준화할 때 참고. |
추가 인사이트
로그는 지능의 정의가 아니라 continuity의 정의다
"로그가 에이전트다"라는 문장은 과장되어 들릴 수 있다. 모델의 추론 능력, tool design, planner, feedback loop도 당연히 중요하다. 다만 오늘 하던 일을 내일 이어서 같은 존재가 계속 수행한다고 말하려면 무엇이 남아야 하는가를 묻는다면 답은 로그에 가깝다. 로그는 지능의 원천이 아니라 continuity의 원천이다.
Memory는 vector DB가 아니라 provenance가 있는 projection이다
많은 구현은 memory를 곧 vector DB로 본다. 하지만 vector entry가 어느 event에서 나왔고, 어떤 정책으로 추출됐고, 어떤 신뢰 등급을 가졌는지 모르면 memory poisoning과 잘못된 recall을 디버깅할 수 없다. 좋은 구조는 다음 순서다.
raw event log
-> memory candidate extraction
-> policy and provenance check
-> memory.committed event
-> vector index projection
-> retrieval with source event citations
Fork는 A/B 테스트보다 넓다
Fork는 Claude와 GPT를 비교하는 기능만이 아니다. 같은 prefix에서 다른 prompt, 다른 approval policy, 다른 tool set, 다른 risk mode, 다른 reviewer agent를 시험할 수 있다. 실패 branch를 나중에 regression test로 바꾸는 것도 가능하다.
Observability는 원장을 대체하지 않는다
Langfuse, Phoenix, OpenTelemetry, OpenAI tracing은 모두 중요하다. 하지만 trace는 보통 "무슨 일이 있었는지 보기 좋게 보여주는 view"다. canonical event log는 "시스템이 어떤 상태를 사실로 인정하는가"를 결정한다. 둘을 같은 저장소에 둘 수는 있어도 역할은 분리해야 한다.
에이전트 공유는 transcript 공유가 아니라 log access control이다
팀원이 agent를 이어받는다는 것은 대화 내용을 복사해 붙여넣는 일이 아니다. 같은 session log에 대한 read/write 권한을 주고, 어떤 branch에서 개입했는지 남기는 일이다. 이 관점에서는 agent collaboration도 access control, event authorship, branch policy의 문제로 바뀐다.
구현 로드맵
1단계: 현재 로그 상태 진단
먼저 현재 시스템이 어디에 가까운지 본다.
| 현재 상태 | 위험 |
|---|---|
| transcript만 저장 | tool call, permission, failure 원인 추적이 어렵다. |
| trace만 저장 | 관측은 되지만 재개와 migration의 원장이 아니다. |
| local JSONL/SQLite만 저장 | 손상, 유실, cross-session query, backup 문제가 생긴다. |
| provider thread/memory에 의존 | export, schema, retention, ownership이 provider 정책에 묶인다. |
| vector memory만 유지 | provenance, deletion, trust boundary를 알기 어렵다. |
2단계: append-only event store 도입
처음부터 복잡한 graph runtime이 필요하지는 않다. Postgres table이나 object storage plus metadata DB로도 시작할 수 있다.
필수 조건은 다음이다.
session_id + sequnique constraint- optimistic concurrency control
- append-only write path
- idempotency key
- schema version
- payload hash
- artifact reference
- branch id
- redaction class
3단계: model context와 UI를 projection으로 재구성
모델 context builder와 UI transcript builder를 분리한다. UI에 보이는 것과 모델에 넣는 것은 다르다. 모델 context는 token budget, policy, recency, relevance, trust level을 반영해야 하고, UI는 사람이 읽기 좋은 설명과 audit affordance를 제공해야 한다.
4단계: approval과 effect ledger를 먼저 붙인다
가장 큰 운영 리스크는 모델 답변이 아니라 외부 세계를 바꾸는 tool call이다. 위험 tool부터 tool.proposed -> tool.approved -> effect.pending -> effect.committed 흐름으로 바꾼다.
5단계: replay, fork, eval을 붙인다
로그가 쌓였으면 그때 replay와 fork가 강력해진다.
- 실패 run을 재현한다.
- 같은 prefix를 다른 model로 실행한다.
- tool result를 freeze하고 model decision만 비교한다.
- model output까지 freeze한 deterministic replay와 새 모델로 돌리는 counterfactual replay를 분리한다.
- branch 결과를 eval dataset으로 승격한다.
유용한 운영 원칙
- 원본 event log는 삭제보다 redaction/tombstone/event-level access policy로 다룬다.
- summary는 원본을 대체하지 않고
summary.createdevent로 남긴다. - memory write는 자동 commit하지 말고
memory.proposed와 policy gate를 둔다. - 외부 side effect는 idempotency key 없이 retry하지 않는다.
- trace dashboard와 canonical event store를 같은 것으로 부르지 않는다.
- model/provider native payload와 vendor-neutral normalized event를 둘 다 보존한다.
- schema migration은 migration event로 남긴다.
- sensitive action은 retrieved memory만으로 승인하지 않는다.
- fork branch에서 발생한 irreversible effect는 branch abandon policy를 가져야 한다.
- 로그 export는 artifact, hash, schema, projection recipe까지 포함해야 한다.
한계와 불확실성
- "로그가 에이전트다"는 좋은 아키텍처 은유지만, 모델 능력, tool 품질, 환경 설계, feedback loop를 대체하는 말은 아니다.
- 2026년에 나온 ActiveGraph, AgentGit, Atomix, MemLineage 계열 자료는 유용하지만 preprint 성격이 강하다. peer review, 재현성, production adoption은 계속 확인해야 한다.
- Anthropic, OpenAI, Google, Cloudflare 문서는 각 회사의 제품 관점을 담고 있다. 아키텍처 primitive를 확인하는 근거로는 강하지만, 특정 제품 선택의 최종 근거로 쓰기에는 부족하다.
- 로그를 모두 보존하면 보안, privacy, 비용, retention 문제가 커진다. 로그 중심 설계는 "무한 보존"이 아니라 "정책 있는 원장화"에 가깝다.
- 결정론적 replay는 LLM 때문에 완전하지 않다. model response, tool response, environment observation을 content-addressed artifact로 고정할 때만 deterministic replay에 가까워진다.
검증이 필요한 주장
- Omnara의 managed agents 플랫폼이 공개된 이후 실제로 어느 수준의 full log export, schema 공개, self-hosting, artifact bundle을 제공하는지 확인해야 한다.
- ActiveGraph가 실제 장기 실행 에이전트 workload에서 deterministic replay, fork, lineage를 어느 정도 안정적으로 제공하는지 재현 테스트가 필요하다.
- AgentGit의 성능 개선과 token 절감 결과는 논문 설정과 benchmark에 묶여 있으므로 독립 재현이 필요하다.
- Atomix의 transactional tool use는 개념적으로 중요하지만, Gmail, GitHub, Stripe, filesystem, cloud infra처럼 부작용 성격이 다른 도구에 같은 방식으로 적용 가능한지 검증해야 한다.
- MemLineage와 memory poisoning 방어는 모델, 도메인, 공격 조건에 따라 결과가 달라질 수 있다.
- Cloudflare Durable Objects, Workflows, Agents SDK를 log-first architecture의 원장으로 쓸 때 export/migration 설계를 별도로 확인해야 한다.
Sources / References
원문과 제품 맥락
- The Log Is The Agent - Ishaan Sehgal, Omnara - 사용자 제공 transcript 기반.
- omnara-ai/omnara - Omnara repo. Claude Code, Codex CLI, n8n 등 agent control plane 맥락.
- Omnara blog - "The Log Is the Agent"와 portability 관련 글이 표시됨. 세부 글 페이지는 별도 확인 필요.
시스템 아키텍처 계보
- Martin Fowler, Event Sourcing - 상태 변경을 event sequence로 저장하고 과거 상태를 재구성하는 패턴.
- Martin Fowler, What do you mean by Event-Driven? - event store를 source of truth로 보고 system state를 derived state로 설명.
- Jay Kreps, The Log - 로그를 append-only ordered record sequence로 설명한 고전적 글.
- Martin Kleppmann, Turning the database inside-out - durable commit log와 derived view 관점.
- Temporal Event History and Temporal Event History encyclopedia - durable event history, crash recovery, replay.
- Azure Cosmos DB Event Sourcing Pattern - append-only event store와 CQRS/materialized view 설명.
Agent framework / platform docs
- Anthropic, Scaling Managed Agents - session, harness, sandbox 분리와 append-only session log.
- LangGraph Persistence - checkpointer와 store, short-term/long-term memory 구분.
- LangGraph Time Travel - replay와 fork.
- OpenAI Agents SDK guide - SDK track, state, approvals, tool execution 소유.
- OpenAI Agents SDK human-in-the-loop and results/run state - approval interruption과 resumable state.
- Google ADK Memory and Google ADK State - session events, state, long-term memory 구분.
- Cloudflare Agents and cloudflare/agents - Durable Objects 기반 stateful agent runtime.
- Cloudflare Workflows docs - durable multi-step execution, external event/approval wait, retries.
- Model Context Protocol specification - JSON-RPC 기반 tool/data integration protocol.
- OpenTelemetry GenAI observability and GenAI semantic conventions repo - GenAI span, metric, event naming.
- Langfuse and Phoenix - observability/evaluation projection layer 참고.
Papers
- The Log is the Agent: Event-Sourced Reactive Graphs for Auditable, Forkable Agentic Systems - ActiveGraph. Preprint.
- ReAct: Synergizing Reasoning and Acting in Language Models - reasoning/action trajectory의 초기 계보.
- Reflexion: Language Agents with Verbal Reinforcement Learning - feedback과 episodic memory buffer.
- Generative Agents: Interactive Simulacra of Human Behavior - complete record, reflection, retrieval.
- Voyager: An Open-Ended Embodied Agent with Large Language Models - skill library, environment feedback, self-verification.
- AgentGit: A Version Control Framework for Reliable and Scalable LLM-Powered Multi-Agent Systems - Git-like branching and rollback for agents. Preprint.
- Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows - transactional tool use and side-effect settlement. Preprint.
- Memory Poisoning Attack and Defense on Memory Based LLM-Agents - persistent memory attack and defense. Preprint.
- MemLineage: Lineage-Guided Enforcement for LLM Agent Memory - provenance and derivation lineage for agent memory. Preprint.
Source Fidelity Notes
- 원문 영상의 중심 주장인 "에이전트는 모델/런타임이 아니라 append-only log에 의해 지속된다"는 결론을 보존했다.
- 원문에 나온 사용자 입력, 모델 출력, tool call/result, permission, failure, compaction, external side effect, reliability, scalability, forking, multiplayer, migration, ownership 논지를 모두 공개 페이지에 반영했다.
- 첨부 초안의 확장 방향 중 event sourcing, ActiveGraph, Anthropic Managed Agents, LangGraph, OpenAI Agents SDK, Google ADK, Cloudflare, Temporal, observability, GitHub repository 목록을 보존하되, 공개 페이지에서는 중복과 약한 주장, 추적 파라미터가 붙은 링크, 긴 원문 전사 반복을 제거했다.
- 영상 transcript와 첨부 초안 전문은 public
wiki/에 싣지 않고sources/ai/2026-07-02-log-is-the-agent.raw.md에 보존했다. - 공개 글은 원문보다 구조를 압축했지만, key numbers and named details 중 ReAct의 34%/10%, Reflexion의 HumanEval 91%/80%, Temporal Event History limit 10,240 warning/51,200 termination 같은 세부 수치는 본문 주장의 필수 축이 아니라 Sources의 원문 참조로 남겼다. 수치 기반 비교가 필요한 후속 글에서는 해당 숫자를 별도 검증해 본문에 끌어올리는 편이 좋다.
- "Amnara/Umnara" 표기는 transcript에 남아 있지만, 공식 repo와 검색 결과 기준 공개 페이지에서는 "Omnara"로 정리했다.