Notes
18분 읽기AI & Tools

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 / expertMartin Fowler, Jay Kreps, Microsoft Azure Event Sourcing pattern높음일반 소프트웨어 패턴이지 LLM 에이전트 전용 검증은 아니다.
장기 실행 workflow는 event history와 replay를 통해 crash recovery를 구현할 수 있다.primaryTemporal Event History docs높음Temporal의 결정론 제약은 LLM tool call과 다르게 설계해야 한다.
Managed Agents 계층에서도 session, harness, sandbox 분리가 중요해지고 있다.primary vendor docsAnthropic Managed Agents중간-높음벤더 문서이므로 제품 우수성 주장은 별도 검증 필요.
에이전트 실행에서 replay, fork, lineage를 event log 중심으로 구현할 수 있다.academic / codeActiveGraph paper and repo, AgentGit중간2025-2026 preprint 성격이 강하고 peer review 상태 확인 필요.
외부 tool side effect는 로그 replay만으로 안전해지지 않는다.academicAtomix transactional tool use중간논문 제안이며 실제 플랫폼별 구현 난도는 별도 검증 필요.
장기 memory는 poisoning과 provenance 문제가 있다.academic / securityMemory Poisoning, MemLineage중간공격 조건, 모델, 데이터셋에 따라 위험도와 방어 성능이 달라진다.
tracing/observability는 필요하지만 canonical state log와 다르다.primary docsOpenTelemetry 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_keyretry 중복 실행 방지
resource_id어떤 외부 자원이 바뀌었는지 추적
approval_event_id누가 어떤 근거로 승인했는지 추적
commit_statuspending, 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 indexretrievalpgvector, Qdrant, Weaviate
Audit view보안, 승인, 장애 조사ClickHouse, OpenSearch, BigQuery
Eval datasetregression, judge calibrationdataset store, object storage
Graph statebelief, task, evidence, dependency graphgraph 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/omnaraClaude Code, Codex CLI, n8n 등을 web/mobile dashboard와 동기화하는 구조영상의 회사/제품 맥락. transcript의 Amnara 표기는 공식 repo 기준 Omnara로 보는 편이 맞다.
yoheinakajima/activegraphevent-sourced reactive graph, replay, fork, diff"log as source of truth"를 가장 직접적으로 구현한 실험체.
MAS-Infra-Layer/Agent-GitLangGraph agent에 Git-like commit, branch, revert를 얹는 방식branchable trajectory 설계 참고.
langchain-ai/langgraphcheckpointer, persistence, time travel, human-in-the-loop현업에서 가장 널리 쓰이는 stateful agent orchestration 축.
openai/openai-agents-pythontool, handoff, guardrail, tracing, resumable run stateSDK 기반 agent loop와 approval/resume 구조 참고.
openai/openai-agents-jsTypeScript SDK, tracing UI, multi-agent workflowsweb/server 제품에서 agent runtime을 붙일 때 참고.
cloudflare/agentsDurable Objects 기반 persistent agent runtimestateful agent primitive와 Cloudflare Workflows 결합 참고.
OpenHands/openhandssoftware 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/experimentspredictions, execution logs, trajectories, resultsagent trajectory가 평가 산출물로 어떻게 저장되는지 확인.
huggingface/smolagents단순한 code-agent abstractionlog-first 구조를 붙이기 전 최소 agent loop를 이해하는 데 좋다.
microsoft/agent-frameworkproduction-grade multi-agent workflow 방향AutoGen/Semantic Kernel 이후 enterprise agent SDK 흐름.
microsoft/autogenmaintenance mode와 migration 맥락agent framework가 교체될 때 로그/상태 이전이 왜 중요한지 보여준다.
crewAIInc/crewAIrole-playing multi-agent orchestrationrole/task 기반 agent framework와 log-first 접근의 차이를 비교.
modelcontextprotocoltool/data integration protocol과 JSON-RPC 기반 메시지tool boundary와 event schema 설계 참고.
langfuse/langfuseopen-source LLM observability, eval, prompt managementcanonical log가 아니라 trace/eval projection 계층으로 참고.
Arize-ai/phoenixAI observability, tracing, evaluationtrace를 model/tool/retrieval debugging view로 보는 데 참고.
open-telemetry/semantic-conventions-genaiGenAI spans, metrics, events namingevent/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 + seq unique 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.created event로 남긴다.
  • 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

원문과 제품 맥락

시스템 아키텍처 계보

Agent framework / platform docs

Papers

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"로 정리했다.