3줄 요약

  1. Omnara 공동창업자 Ishaan Sehgal이 X 아티클로 발표한 글. 에이전트의 정체를 “실행 중인 프로세스"가 아닌 “이벤트 로그"로 정의하자는 제안이다.
  2. 로그가 올바르게 구성되어 있으면 로그만으로 에이전트를 복원하고 재개할 수 있다. 이 단일 속성에서 신뢰성, 확장성, 포크, 멀티플레이어, 마이그레이션이 모두 파생된다.
  3. 가장 깊은 종속은 모델 종속이 아닌 로그 종속이다. 로그를 소유한 자가 에이전트를 소유하므로, 자기 로그가 어디 살고 누가 들여다볼 수 있는지 알아야 한다.

모델과 도구 사이에서 로그가 중심에 놓인 다이어그램

세이브 파일 비유

글은 게임 비유로 시작한다. 스카이림이나 엘든 링에서 100시간을 플레이한 캐릭터의 정체는 무엇인가. 게임 엔진도, 플레이스테이션도, 컨트롤러도 아니다. 캐릭터는 세이브 파일이다. 플레이스테이션이 불타도 캐릭터는 죽지 않는다. 새 기기를 사서 클라우드에서 세이브 파일을 받으면 캐릭터는 칼을 휘두르던 그 순간 그대로 있다.

저자는 AI 에이전트가 같은 변곡점에 도달했다고 본다. 많은 사람이 에이전트를 모델, 런타임, 현재 실행 중인 루프라고 생각하지만, 그것들은 에이전트가 아니다. 에이전트는 그 데이터, 정확히는 이벤트 히스토리인 로그다.

로그의 정의

로그는 두 가지로 구성된다.

구성 요소내용성격
이벤트 히스토리모든 사용자 입력, 모델 출력, 도구 호출, 도구 결과append-only로 누적
세션 정의 참조시스템 프롬프트, 도구 설명, 스킬턴마다 바뀌지 않는 버전 상수

이 둘이 에이전트의 전체 상태를 이룬다. 런타임과 모델과 도구는 해석기이자 기록자일 뿐이다. 내구성 있는 상태를 읽고, 행동하고, 다음 이벤트를 기록한다. 따라서 새 실행기에 같은 로그를 건네면 에이전트가 있던 지점을 정확히 재구성하고 이어서 진행한다.

실전에서의 루프

에이전트를 로그로 정의하면 시스템의 모든 연산이 셋 중 하나가 된다. 로그를 읽거나, 로그에 덧붙이거나, 로그의 뷰를 렌더링하거나. 모델은 뷰를 읽고 다음 행동을 만든다. 도구 러너는 도구를 실행하고 결과를 덧붙인다. UI는 로그를 읽어 타임라인을 그리고, 트레이싱 시스템은 트레이스를 그리고, 감사자는 무슨 일이 있었는지 재구성한다. 테이블과 인덱스와 캐시가 모두 변경 로그 위의 프로젝션이라는, 데이터베이스가 수년 전에 정착시킨 패턴과 같다.

단순화한 루프는 이렇다.

while session_has_work:
    take_temporary_lease(session_id)
    state = reconstruct_from_log(session_id)
    response = model.next(state)
    append(response, to=session_log)

    if response.requests_tool:
        append(tool_call_started, to=session_log)
        result = run_tool(response.tool_call)
        append(result, to=session_log)
        continue

    finish_turn(session_id)

각 패스는 임시 리스를 잡고, 로그를 읽고, 한 걸음 전진하고, 결과를 기록한다. 의미 있는 상태 전이가 모두 내구성 있게 기록되는 한, 어떤 실행기든 세션을 집어 들어 이어갈 수 있다. 루프는 멱등하고 장애에 강하다.

컴팩션은 로그가 아니다

로그는 무한히 자랄 수 있지만 모델의 컨텍스트 윈도우는 유한하다. 그래서 컴팩션이 필요하다. 컴팩션이 이전 내용을 요약으로 대체한다면 “로그가 에이전트"라는 주장이 무너지지 않는가.

저자의 답은 무너지지 않는다는 쪽이다. 컴팩션은 손실 압축이다. 에이전트의 상태를 작게 재현하는 것이라기보다 정보를 버리는 행위다. 이 점이 오히려 주장을 강화한다. 전체 로그가 기록이고 컴팩션은 그 위의 한 프로젝션일 뿐이다. 머티리얼라이즈드 뷰가 데이터베이스 자체가 아니듯이. 원시 로그를 보존하면 언제든 새 프로젝션을 만들 수 있지만, 원시 로그를 버리고 컴팩션만 남기면 에이전트의 일부를 잃는다. 컴팩션은 새 로그로 재개하는 손실성 포크로 취급하는 게 가장 깔끔하다.

로그는 세계 전체가 아니다

당연한 반론이 있다. 에이전트가 파일을 고치고, GitHub 이슈를 열고, 이메일을 보내면 로그 바깥에 상태가 생긴다. 저자는 이것도 주장을 침몰시키지 못한다고 답한다. 로그에서 재구성하는 것은 세계가 아닌 에이전트의 상태다. 이미 보낸 이메일은 포크해서 되돌려도 취소되지 않고, 고쳐 둔 파일은 그 사이 바뀌었을 수 있다. 로그는 세계를 결정론적으로 만들지 않는다. 에이전트가 무엇을 하고 무엇을 보았는지에 대한 충실하고 재개 가능한 기록을 지킬 뿐이며, 그것이 정확히 잃어서는 안 되는 것이다. 세이브 파일도 같다. 스카이림 엔진이나 맵을 담지 않고 플레이어를 다시 떨어뜨려 놓는 데 필요한 상태만 담는다.

따라오는 속성들

로그가 에이전트라는 하나의 가정에서 다음 속성들이 함께 파생된다.

  • 신뢰성: 지금의 Claude Code는 권한 프롬프트에 도달한 상태에서 프로세스가 죽으면, 재개해도 프롬프트가 사라지고 에이전트가 멈춰 있다. 로그가 에이전트라면 실행기는 죽어도 된다. 새 워커가 세션을 집어 상태를 재구성하면 권한 프롬프트가 그 자리에 그대로 있다. 프로세스가 죽었을 뿐 에이전트는 죽지 않았다.
  • 확장성: 대부분의 하네스는 에이전트당 프로세스 하나를 돌려 에이전트가 머신에 묶인다. 로그가 상태라면 한 프로세스가 수천 에이전트를 전진시킬 수 있고, 페일오버가 자명해지고, 스케일아웃은 워커를 늘리는 일이 된다.
  • 포크: 로그를 분기시켜 한 갈래는 Claude, 한 갈래는 GPT, 한 갈래는 로컬 Qwen 위에서 서로 다른 전략을 탐색할 수 있다.
  • 멀티플레이어: 에이전트 공유가 트랜스크립트를 슬랙에 복붙하는 일이어서는 안 된다. 그것은 데이터베이스의 스크린샷을 공유하며 복제라 부르는 격이다. 로그가 에이전트라면 공유는 남이 검사하고 재개하고 확장할 수 있는 내구성 있는 히스토리에 접근 권한을 주는 일이다.
  • 마이그레이션: 에이전트의 정체성이 프로바이더 고유 가정에 갇혀 있으면 이전이 고통스럽다. 로그가 에이전트라면 이전은 어댑터 문제로 줄어든다. 정체성 문제가 아닌 엔지니어링 문제다.

오늘의 하네스는 로그를 2급 시민으로 다룬다

저자가 보는 현실은 이렇다. Claude Code와 Codex는 트랜스크립트를 로컬 디스크에 지저분한 JSONL로 쓴다. Claude SDK 모드에서 그 쓰기는 fire-and-forget이라 완료 전에 문제가 생기면 데이터가 사라진다. OpenCode는 로컬 SQLite에 상태를 저장하는데 GitHub 이슈에 손상과 유실 보고가 올라온다. 로그가 시스템이 아닌 부산물로 취급된다. 로그를 1급 시민으로, 즉 내구성 있고 구조화되고 재생 가능하며 실행 머신에서 독립된 것으로 다루면 위의 속성들은 덧붙이는 게 아니라 구조에서 저절로 떨어져 나온다.

로그 소유권이 에이전트 소유권이다

글이 마지막으로 강조하는 지점이다. 로그가 에이전트라면 로그를 소유한 자가 에이전트를 소유한다. 장기적으로 가장 강한 종속은 모델 종속이 아니다. 모델은 교체할 수 있고 API와 도구는 감싸고 어댑팅할 수 있다. 가장 깊은 종속은 로그 종속이다. 프로바이더가 에이전트의 유일한 내구성 기록을 소유하면 그 프로바이더가 에이전트를 소유한다. 트랜스크립트 같은 프로젝션을 내보내도 에이전트는 잃을 수 있다. 에이전트는 최종 출력물이 아니라 그것을 만들어 낸 경로 의존적 히스토리이기 때문이다.

저자는 이것이 지금 당장 중요한 문제라고 본다. Anthropic은 Claude Managed Agents를, Google은 Gemini 관리형 에이전트를 내놓았고, 모든 주요 프로바이더가 호스팅 에이전트 루프, 관리형 메모리, 샌드박스, 컴팩션, 백그라운드 실행까지 스택을 더 많이 소유하는 방향으로 움직이고 있다. 에이전트가 유용하려면 개인 정보, 회사 데이터, 워크플로우, 의사결정에 접근해야 하고 로그는 그 모든 것의 기록이다. 그 로그가 남의 인프라에서 남의 보존 정책 아래 살면, 그들은 에이전트를 호스팅하는 게 아니라 소유하는 것이다.

관리형 인프라를 쓰지 말라는 주장은 아니라고 덧붙인다. 유용하고 대부분의 팀에게 불가피할 것이다. 단, 자기 로그가 어디 사는지, 누가 검사할 수 있는지, 재생하고 포크하고 이전하고 내보낼 수 있는지는 알아야 한다.

Omnara의 실전 적용

Omnara는 에이전트 실행을 내구성 있는 세션 로그를 중심으로 조율되는 컴포넌트 집합으로 본다. 워커가 루프를 전진시키지만 워커는 에이전트가 아닌 현재의 실행기일 뿐이다. 에이전트가 도구를 호출하면 워커는 상태를 메모리에 쥐고 기다리지 않는다. 도구 호출 시작을 로그에 쓰고, 도구를 해당 실행 환경으로 보내고, 다른 곳에서 끝나게 둔다. 도구가 완료되면 결과가 로그에 덧붙고, 어쩌면 다른 워커가 상태를 재구성해 계속한다.

워커가 죽고, 머신이 재시작하고, 샌드박스가 사라지고, 도구 호출이 길어지고, 프로바이더가 실패하고, 사용자가 끊기는 현실의 장애 앞에서, 에이전트가 실행 중인 프로세스라면 모든 것이 무섭지만 에이전트가 로그라면 전부 실행 디테일이 된다. 저자는 관리형 에이전트 플랫폼의 오픈소스 공개를 준비 중이라고 밝힌다.

가장 흥미로운 지점

기술 주장보다 종속 분석이 눈에 띈다. “모델은 갈아끼울 수 있으니 모델 종속은 약하다, 진정한 종속은 로그 종속이다"라는 프레임은, 관리형 에이전트 경쟁을 모델 성능 경쟁이 아닌 히스토리 보관소 경쟁으로 다시 읽게 만든다. 에이전트가 일하면 일할수록 로그에는 그 조직의 의사결정과 데이터 접근 패턴이 쌓이고, 그 축적분 자체가 이전 비용이 된다는 논리다.

또 하나, 이 글의 주장은 데이터베이스 커뮤니티에 오래 있던 “the log is the database” (이벤트 소싱, write-ahead log 중심 사고)를 에이전트에 그대로 이식한 것이다. 새 발명이라기보다 검증된 아키텍처 패턴의 전이라는 점이 설득력의 원천이고, 저자 본인도 12-factor agents를 인용하며 그 계보를 숨기지 않는다. 회사(Omnara)의 제품 방향과 글의 결론이 일치하는 포지션 피스라는 점은 감안하고 읽을 필요가 있다.

출처

Ishaan Sehgal (Omnara), “The Log Is the Agent”, X 아티클, 2026. 원문: https://x.com/ishaansehgal/status/2065129901427130678