로그가 곧 에이전트다 (The Log Is the Agent)

The Log Is the Agent

AI agents are hitting the same inflection point. Most people think an agent is the model, the...

Ishaan Sehgal2026-06-30

개요 #

AI 에이전트를 떠올릴 때 대부분은 모델이나 런타임, 지금 돌아가고 있는 실행 루프를 먼저 생각한다. 물론 다 필요한 요소들이다. 하지만 그중 어느 것도 에이전트 자체는 아니다.

이 글의 주장은 단순하다. 에이전트는 곧 데이터이며, 더 정확히는 사건의 기록, 즉 로그(log) 다. 로그를 제대로 쌓아두면 그것만으로 에이전트를 원래 지점에서 다시 살려낼 수 있다. 그리고 이 하나의 성질이 고급 에이전트 활용을 훨씬 다루기 쉽게 만들어 준다.

에이전트란 무엇인가 #

그렇다면 로그란 무엇일까. 에이전트를 정의한다는 건 곧 로그를 정의하는 일이다. 로그의 핵심은 사건의 역사다. 사용자 입력, 모델 출력, 도구 호출, 도구 실행 결과가 에이전트가 작업하는 동안 차곡차곡 쌓인다. 일어난 모든 일을 덧붙이기만 하는(append-only) 기록인 셈이다.

로그는 세션 정의에 대한 참조도 함께 들고 있다. 시스템 프롬프트, 도구 설명, 에이전트가 따르는 스킬 같은 것들이다. 이 값들은 턴이 바뀌어도 변하지 않으므로, 스트림의 능동적인 부분이라기보다 버전이 매겨진 상수에 가깝다.

이 둘을 합치면 에이전트의 전체 상태가 된다. 에이전트를 이루는 그 무엇도 런타임이나 모델, 도구 안에 살아 있지 않다. 그것들은 해석기이자 기록기일 뿐이다. 지속적인 상태를 읽고, 그에 따라 행동하고, 다음 사건을 다시 써넣는다. 그래서 새 실행기에 같은 로그를 건네면, 에이전트가 있던 정확한 지점을 그대로 복원해 이어서 작업한다. 로그 하나면 에이전트를 되살리기에 충분하다.

로그를 실제로 다루면 #

에이전트를 로그로 정의하고 나면 시스템의 나머지 부분을 훨씬 이해하기 쉬워진다. 에이전트에 가하는 모든 연산은 로그를 읽거나, 로그에 덧붙이거나, 로그의 한 단면을 그려내는 일 중 하나다. 모델은 하나의 단면을 읽고 다음 행동을 만들어낸다. 도구 실행기는 도구 호출을 처리한 뒤 결과를 덧붙인다. UI는 로그를 읽어 타임라인을 그리고, 추적 시스템은 트레이스를 그리며, 감사 도구는 무슨 일이 있었는지 재구성한다. 데이터베이스가 오래전에 정착한 방식과 똑같다. 테이블, 인덱스, 캐시는 모두 변경 로그 위에 투영된 결과물이다. @dexhorthy의 12-factor agents 탐구에서 가져온 다이어그램이 원문에 실려 있으니 한 번 읽어볼 만하다.

실제 루프를 단순화하면 대략 이런 모습이다.

untitled

python

# 각 패스: 임시 리스를 확보하고, 로그를 읽고,
# 한 단계 전진한 뒤, 결과를 다시 써넣는다.
lease = acquire_lease(session)
state = read_log(session)
action = model.step(state)
result = run_tool(action)
append_log(session, result)

간단해 보이지만 핵심은 이렇다. 각 패스는 임시 리스(lease)를 확보하고, 로그를 읽고, 한 단계만 전진한 뒤, 결과를 되써넣는다. 이 루프는 멱등적이고 결함에 강하다. 의미 있는 상태 전이가 매번 지속적으로 기록되기만 하면, 어떤 실행기든 세션을 이어받아 계속 진행할 수 있다.

압축은 로그가 아니다 #

로그는 무한히 커질 수 있지만, 모델이 보는 단면은 그럴 수 없다. 컨텍스트 윈도우에는 한계가 있다. 매 호출마다 원본 역사 전체를 모델에 건넬 수는 없다. 여기서 압축(compaction) 이 등장한다. 그런데 압축은 이전의 모든 것을 요약으로 대체하니, 로그가 곧 에이전트라는 주장이 무너지는 건 아닐까?

그렇지 않다. 압축은 손실을 동반한다는 점을 기억하자. 압축된 요약은 에이전트의 상태를 더 작은 형태로 재현하는 게 아니라, 정보를 버린다.

오히려 이 사실이 주장을 뒷받침한다. 원본 로그가 진짜 기록이고, 압축은 그 위에 투영된 하나의 단면일 뿐이다. 구체화된 뷰(materialized view)가 데이터베이스가 아니듯, 요약이 대화 자체는 아니듯. 원본 로그를 지켜두면 언제든 새 단면을 다시 만들어낼 수 있다. 원본을 버리고 압축본만 남기면, 에이전트의 일부를 잃는 것이다. 그러니 압축은 최선을 다한, 손실을 감수한 분기(fork)로 보고, 새로운 로그로 이어가는 편이 가장 깔끔하다.

로그가 세상 전부는 아니다 #

진지하게 따져볼 만한 반론이 하나 있다. 로그 바깥의 상태를 바꾸는 도구는 어떻게 할 것인가? 에이전트가 파일을 수정하고, GitHub 이슈를 열고, 이메일을 보낸다. 이제 로그가 아닌 다른 어딘가에 상태가 산다. 이건 주장을 침몰시키지 않을까?

침몰시키지 않는다. 에이전트의 상태는 세상이 아니라 로그에서 다시 끌어낸다. 이미 이메일을 보냈다면 로그를 되감아도 발송이 취소되지 않고, 수정한 파일은 그사이 다른 손에 바뀌었을 수 있다. 로그가 세상을 결정론적이거나 되돌릴 수 있게 만드는 건 아니다. 로그는 에이전트가 무엇을 했고 무엇을 보았는지, 그 잃어서는 안 될 기록을 충실하고 재개 가능하게 보관할 뿐이다.

게임 세이브 파일도 같은 방식으로 움직인다. 세이브 파일에 스카이림 엔진이나 맵이 들어 있지는 않다. 플레이어를 다시 그 자리에 떨궈 놓는 데 필요한 상태만 담겨 있다. 그사이 세계가 바뀌었다면, 에이전트는 캐릭터가 그러하듯 주변과 다시 마주하며 자신의 세계관을 갱신한다.

따라 나오는 속성들 #

에이전트를 이렇게 바라보면 시스템 차원의 좋은 속성들이 딸려 온다. 이 속성들은 서로 독립적이지 않고, 로그가 곧 에이전트라는 같은 전제에서 함께 흘러나온다.

신뢰성. 지금 Claude Code에서 벌어지는 일을 떠올려 보자. 에이전트가 권한 승인 프롬프트에 도달한 순간 프로세스가 죽고, 다시 살리면 프롬프트는 사라진 채 에이전트가 멈춰 있다. 프로덕션에서는 용납할 수 없는 상황이다. 로그가 에이전트라면 실행기는 얼마든지 실패해도 된다. 새 워커가 세션을 이어받아 상태를 복원하면, 권한 프롬프트는 있던 자리에 그대로 있다. 죽은 건 프로세스지 에이전트가 아니다.
확장성. 대부분의 하네스는 에이전트 하나에 프로세스 하나를 붙이고, 그러면 에이전트는 자신을 돌리는 머신에 묶인다. 로그가 상태라면 이 구도를 뒤집을 수 있다. 프로세스 하나가 수천 개의 에이전트를 전진시키고, 각 에이전트는 매 턴 로그에서 상태를 복원한다. 에이전트가 특정 머신이나 워커에 묶이지 않으니 장애 조치가 손쉬워진다. 확장은 워커를 더 붙이는 것으로 끝난다. 스티키 세션도, 상태 이전도, 조율 부담도 없다.
포킹. 하나의 선형 경로 대신 로그를 분기할 수 있다. 한 갈래는 Claude에서, 다른 갈래는 GPT에서, 또 다른 갈래는 로컬 Qwen에서 돌리며, 저마다 다른 전략을 다른 샌드박스에서 다른 도구로 탐색한다. 여러 접근을 동시에 시도하는 설계가 훨씬 간단해진다.
멀티플레이어. 에이전트를 공유한다는 게 대화 기록을 Slack에 복사해 붙여넣는 일이어서는 안 된다. 그건 데이터베이스 스크린샷을 찍어 공유하면서 복제라 부르는 격이다. 로그가 에이전트라면 공유는 곧 지속적인 역사에 대한 접근 권한을 주는 일이 된다. 상대가 그 역사를 들여다보고, 이어받고, 확장할 수 있다.
마이그레이션. 에이전트의 정체성이 특정 공급자의 가정 안에 갇혀 있으면 공급자를 옮기는 일이 고통스럽다. 로그가 에이전트라면 마이그레이션은 어댑터 문제로 바뀐다. 모델마다 원하는 단면이 다를 수는 있지만, 그건 정체성 문제가 아니라 엔지니어링 문제다. 연속성은 로그에 있고, 에이전트는 어떤 모델 공급자로든 서로 갈아끼우며 이어갈 수 있어야 한다.

여기 적은 건 몇 가지 예일 뿐이다. 에이전트를 이렇게 생각하기 시작하면 에이전트는 하나의 데이터 조각이 되고, 데이터로 할 수 있는 많은 일이 에이전트에도 가능해진다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.