구매자들이 계속해서 바라보는 에이전트 스택(agent stack)은 매우 지루한 부분입니다. 바로 루프(loop)입니다.

루프가 눈에 보이면, 시스템의 나머지 부분은 루프의 다른 곳에 있게 됩니다 (에이전트 루프가 사라진 것은 아닙니다). 더욱이, 에이전트가 수행한 작업의 영구적인 기록을 관리하기 위한 계층이 생성되었습니다: 상태 (state, 고객 요청을 처리하기 위해 AI 에이전트가 수행한 작업의 영구적인 기록). 이것이 기업 업무의 핵심입니다. 기업은 이러한 기록을 생성하고 유지하며, 누가 이러한 기록을 읽을 수 있는지, 얼마나 오래 보관할지, 해당 기록으로 무엇을 할 수 있는지 등을 결정하도록 시스템(AI 여부와 상관없이)을 구성할 것입니다. 상태 계층(state layer)의 도입과 함께, 이제 AI 에이전트 인프라는 상태 계층에서 분리됩니다. 모델(Model) + 프롬프트 중심의 에이전트(prompt-centered agent)는 더 이상 AI 에이전트를 위한 인프라 논거를 대변하지 않습니다.

AI 에이전트의 상태 계층은 이제 에이전트가 하나의 '제품(product)'이 되는 것과, Salesforce 등에 우연히 접근하는 '눈속임(parlor trick)'이 되는 것 사이의 경계선이 되고 있습니다.

루프는 잘못된 구매 대상입니다

더 어려운 질문들은 한 계층 아래에 존재합니다.

탭이 닫힌 후 상태(state)는 어디에 머무나요? 무엇이 체크포인트(checkpoint)를 기록하나요? 도구 호출(tool call)이 성공적으로 완료되었지만, 요약이 생성되기 전에 모델이 실패하면 어떻게 되나요? 트레이스(traces), 정책 결정(policy decisions), 권한 부여(permission grants)는 실행 과정의 어디로 유입되나요? 벤더 계약이 만료될 때 기업은 무엇을 내보낼(export) 수 있나요? 누가 메모리를 삭제할 수 있나요? 누가 메모리에 대한 소환장을 발부할 수 있나요? 두 에이전트가 동일한 고객과 함께 작업하며 동일한 파일에 기록을 남길 때, 그 기록에 대한 책임은 누구에게 있나요?

Side-by-side architecture showing a prompt-centered agent beside an agent backed by a durable state layer.

영구적인 경계(durable boundary)가 바로 에이전트가 운영 인프라(operating infrastructure)가 되는 지점입니다.

상태(State)는 에이전트의 동작을 인프라로 변화시킵니다.

데이터베이스가 백엔드가 되고 있습니다

목요일, LangChain과 MongoDB는 에이전트 시스템이 검색 (Retrieval), 지속성 메모리 (Persistent Memory), 운영 데이터 액세스 (Operational Data Access), 관찰 가능성 (Observability), 그리고 신뢰할 수 있는 배포 (Reliable Deployment)를 필요로 한다는 관점으로 파트너십을 발표했습니다. 실제 출시는 일련의 도구들이며, 이 파트너십이 중요한 이유는 "더 알아보기" 문구에 담겨 있습니다: ["에이전트에는 모델과 프롬프트 그 이상의 것이 필요합니다">(https://www.langchain.com/blog/announcing-the-langchain-mongodb-partnership-the-ai-agent-stack-that-runs-on-the-database-you-already-trust)]. 도구 중심의 에이전트(또는 프롬프트 중심의 빌더)는 제품이 아닙니다.

그 문장은 주변의 출시 관련 문구보다 훨씬 더 많은 의미를 담고 있습니다.

공식 LangGraph 문서에서는 지속성 메모리 (Durable Memory)가 데이터베이스 기반의 체크포인터 (Database-backed Checkpointer)를 사용해야 한다고 명시하며, Postgres, MongoDB, Redis, Oracle에 대한 예시를 제공합니다. LangSmith 배포 문서는 상태 계층 (State-layer)의 전환을 직접적으로 드러냅니다: LS_DEFAULT_CHECKPOINTER_BACKEND를 mongo로 설정하고 LS_MONGODB_URI를 제공하십시오`. 이 문구는 스토리지 (Storage), 배포 (Deployment), 데이터 레지던시 (Data Residency)와 함께 플랫폼 검토 항목에 포함되어야 마땅합니다.

지루할 수도 있지만, 바로 그 점이 핵심입니다.

상태(State)는 락인(Lock-in)이 실체화되는 지점입니다

O'Reilly의 2026년 AI 에이전트 아키텍처 다이어그램은 LLM과 실제 워크로드를 실행하는 AI 에이전트 사이의 6개 계층을 정의합니다. 메모리 / 지속성 상태 (Memory / Persistent State)는 벡터 데이터베이스 (Vector Database) 상위에 위치한 아키텍처의 첫 번째 레벨 프리미티브 (First-level Primitive)입니다. 이 아키텍처는 프레임워크 계층에 대한 시장의 실제 경험과 일치합니다. 애플리케이션의 경계가 명확할 때는 교체하기 쉽습니다. 하지만 상태 (State)를 교체하는 것은 훨씬 더 어렵습니다.

TGVP는 상태 유지 서비스(stateful services)가 메모리 그래프(memory graphs), ID 저장소(identity stores), 정책 로직(policy logic), 감사 이력(audit history)을 시간이 지남에 따라 축적함으로써 어떻게 해자(moat)를 형성하는지에 대해 유사한 논거를 제시했습니다. 저는 인프라에 대한 해자 논리(예를 들어, 엔터프라이즈 소프트웨어의 커스텀 UI가 단순히 "커넥터 카탈로그(connector catalog)"를 제공하는 것을 넘어, 이후 단일 어댑터로 대체될 수 있는 진입 장벽을 만드는 방식)를 좋아하지 않지만, 시간이 흐르며 축적되는 메모리 그래프, ID 저장소, 정책 로직, 그리고 감사 이력의 증가에는 가치가 있습니다.

저는 원래 이것을 저의 벤더 평가 기준의 일부로 작성했습니다. 첫 번째 부분은 모델 중립성(model neutrality)이었습니다. 이는 사람들이 듣고 싶어 하는 내용인 것 같습니다. 지속 가능한 메모리(Durable memory)는 데이터베이스 기반의 체크포인터(checkpointer)를 사용해야 하며, 해당 체크포인터의 구현 세부 사항(스토리지, 배포, 데이터 레지던시(data residency) 등)은 메모리 형식, 트레이스(trace, 또는 로그) 스키마, 상태의 정책 및 의사 결정 부분, 그리고 감사 내보내기(audit export)보다 훨씬 이전에 검토될 수 있도록 공개되어야 합니다. 폐쇄적인 상태(closed state) 위에 구축된 오픈 모델 라우팅(Open model routing)은 조명이 더 밝은, 더 보기 좋은 새장일 뿐입니다.

거버넌스는 상태를 따른다

상태 계층(state layer)은 또한 거버넌스(governance)를 슬라이드웨어(slideware, 발표용 슬라이드 자료)의 영역에서 끌어냅니다.

에이전트 거버넌스(Agent governance)는 정책 문서에 저장되어 있을 때는 추상적으로 들리고 슬라이드웨어(slideware)의 영역에 국한될 수 있습니다. 하지만 플랫폼을 일련의 계층(layers)으로 바라보는 순간, 팀은 에이전트의 특정 실행(run)에 대해 구체적인 질문을 던지기 시작합니다. 예를 들어: 해당 실행을 시작한 주체(principal)는 누구인가? 해당 주체에게 부여된 권한(permissions)의 범위를 좁힌 작업(task)은 무엇이었는가? 해당 작업에 의해 부여된 권한 세트를 고려했을 때, 그 주체가 허용된 범위를 실제로 넘어선 도구 호출(tool call)은 무엇이었는가? 해당 작업에 의해 부여된 권한을 바탕으로, 그 주체가 해당 도구 호출을 실제로 수행할 수 있도록 허용한 정책(policy)은 무엇이었는가? 해당 에이전트의 실행을 실제로 기록한 체크포인트(checkpoint)는 무엇이었는가? 그리고 해당 에이전트의 실행이 그 순서대로 발생했음을 실제로 증명하는 트레이스(trace)는 무엇인가?

에이전트 기반 시스템(Agent-based systems)의 보안에 관한 연구는 에이전트에게 허용된 권한과 MCP 서버가 에이전트에게 실제로 허용할 작업 사이의 경계를 탐색하기 시작한 단계에 불과합니다. AgentBound는 296개의 인기 있는 MCP 서버를 조사하였으며, 자동 생성된 권한 매니페스트(permission manifests)가 수정 없이 80.9%의 확률로 작동하며, 평균 0.6ms의 집행 오버헤드(enforcement overhead)를 가진다는 것을 발견했습니다. MCP 도구 접근 방식이 현재의 기본 신뢰(trust-by-default) 및 호스트 프로세스 실행 모델에서 벗어나, 명시적인 매니페스트와 접근 권한의 런타임 집행(runtime enforcement) 방향으로 나아가고 있음이 분명합니다.

정체성(Identity) 작업 또한 이러한 분석과 잘 맞물립니다. 2026년 AI 정체성 보고서는 AI 정체성을 에이전트가 선언하는 것과 관찰된 행동 사이의 지속적인 관계로 정의합니다. 이 관계는 선언(declaration), 관찰(observation), 그리고 그 관찰에 대한 신뢰(confidence)를 통해 확립됩니다. 따라서 생산적인 AI의 상태(state)를 추적하는 것과 동일한 아키텍처가 해당 AI의 정체성을 확립하고 추적하게 됩니다. 관찰이 없는 선언은 자격 증명(credential)에 불과합니다. 지속적인 상태 저장소(durable store of state)가 없는 관찰은 로그(log)일 뿐입니다. 에이전트가 선언한 정체성과 관찰된 행동 사이의 관계에 대한 시스템의 이해에 신뢰를 갖기 위해서는, 시스템이 지속적인 상태 저장소를 보유해야 하며, 실제로 일어난 일이 시스템이 예상했던 일과 일치하는지 비교할 수 있어야 합니다.

우리가 과거에 다루었던 주제인 작업 범위 제한 액세스 제어(Task-scoped access control) 또한 이 주제에 속합니다. TrueFoundry의 TBAC(Task-Based Access Control, 작업 기반 액세스 제어) 기능에 관한 글에서는, 현재의 정체성 중심 액세스 모델이 에이전트의 무게로 인해 어떻게 부담을 느낄 수 있는지 설명했습니다. 각 작업마다 서로 다른 권한 세트(permission set)를 호출해야 할 수도 있기 때문입니다. 이는 빠르게 발생할 수 있으며, 특히 프롬프트 주입(prompt-injection) 공격에 취약합니다. 요컨대, TrueFoundry는 작업 기반 제어가 작업이 지속되는 동안 최소한의 권한을 묶어 제공한다고 주장합니다. 비록 벤더의 패키징 측면에서 다소 아쉬운 점이 있더라도, 이는 매우 훌륭한 아키텍처입니다.

우리는 이전에 도구 호출 보안(tool-call security)과 에이전트 주체(agent principals, 예: 에이전트를 사용자로 실행)를 통해 권한 부여(authorization) 측면을 살펴본 바 있습니다. 상태 계층(state-layer)의 관점에서 보면, 권한 부여, 정체성, 메모리(memory), 체크포인트(checkpoints), 트레이스(traces), 그리고 감사 기록(audit records)은 모두 하나로 연결됩니다. 즉, 에이전트가 작업을 수행한 기록입니다.

상태 유지 루프(stateful loop)가 곧 제품이다

실행 중인 에이전트의 구동에는 일정한 리듬이 있습니다.

메모리 로드. 도구(tool) 호출 및 각 도구에 대한 정책(policy) 적용. 각 도구 호출에 대한 트레이스(trace) 작성. 감사 이벤트(audit event) 기록. 실행 상태(run state) 업데이트. 이후, 실행 중 수집된 증거로부터 실행 재개. 앞서 언급했듯이, 각 라이브 에이전트 실행은 플랫폼에 의해 검사될 수 있는 이력을 갖게 됩니다. 이러한 이력은 모델이 올바르게 답변할 수도 있고 그렇지 않을 수도 있는 프롬프트(prompt)에 의해 에이전트의 실행이 구동되는 것보다 훨씬 더 큰 가치를 제공합니다.

Flow diagram showing a stateful agent loop that loads memory, calls tools, writes traces and audit records, and resumes later.

상태(State)는 축적됩니다.

어떤 이유로든 에이전트 실행이 중단되더라도 그 작업이 "학습 취소(unlearned)"될 필요는 없습니다. 새로운 작업 실행은 이전 실행이 중단된 정확한 시점부터 시작할 수 있습니다.

하지만 에이전트의 과거 실행에서 얻은 증거가 적절히 모니터링되지 않는다면 이 모든 작업은 헛수고가 될 것입니다. 이것이 바로 에이전트 모니터링이 인프라(agent monitoring is infrastructure)인 이유입니다. 우리가 앞서 논의한 상태 유지 에이전트 루프(stateful agent loop)에 "트레이스 및 감사 기록 작성" 섹션이 포함된 데에는 이유가 있습니다. 이것은 에이전트 실행의 모든 부수 효과(side effects)가 기록되어 나중에 사람(또는 자동화된 시스템)이 검사할 수 있도록 하는 수단입니다.

따라서 실제 워크로드(real workloads)를 처리할 수 있는 에이전트 플랫폼이 플랫폼 작업에 집중하는 것은 놀라운 일이 아닙니다(앞서 설명한 바와 같이).

모델은 여전히 비용이 많이 드는 항목일 수 있습니다. 하지만 상태 계층(state layer)은 운영 신뢰성(operational trust)이 축적되는 곳입니다.

플랫폼 평가가 상태 계층으로 이동한다

구매 체크리스트가 바뀌어야 합니다.

이전 실행(run)에 대한 체크포인트(checkpoints)는 어디에 저장됩니까? 플랫폼 메모리(memory)의 형식은 무엇입니까? 스레드 ID(thread ID), 실행 ID(run ID), 트레이스 ID(trace ID), 감사 ID(audit ID)로부터 얻은 정보를 어떻게 하나로 결합합니까? 도구 호출(tool call)에 의해 내려진 권한 결정(permission decisions)을 해당 도구 호출 기록과 함께 기록합니까, 아니면 다른 곳에서 그 정보를 다시 구축해야 합니까? 플랫폼 표면(platform surfaces)에 있는 상태 정보(state information)를 내보낼(export) 수 있습니까, 아니면 고객 지원팀에 요청해야만 하는 작업입니까? (어떤 것이 상태(state)로 내보내진다고 해서, 내보내진 상태 정보가 플랫폼 표면에 상태 정보로 저장된 정보와 반드시 동일하다는 의미는 아님에 유의하십시오). 시스템이 동일한 인덱스(index)에 저장된 다른 사용자의 메모리에 영향을 주지 않고 특정 사용자의 메모리만 삭제할 수 있습니까? 시스템은 상태 정보로 저장하는 정보를 테넌트(tenant), 환경(environment), 지역(region), 보존 규칙(retention rules) 등에 따라 어떻게 분할(partition)합니까?

그다음, 불편한 질문을 던지십시오: 마이그레이션(migration) 과정에서 무엇이 손실됩니까?

프롬프트 히스토리(prompt history)와 에이전트 빌더(agent builder) 설정은 별개의 문제입니다. 체크포인트(checkpoints), 메모리(memory), 트레이스(traces), 승인(approvals), 감사 기록(audit records), 그리고 정책 히스토리(policy history)는 또 다른 문제입니다. 만약 벤더(vendor)가 이 모든 것을 고객의 새로운 백엔드(backend)로 마이그레이션할 수 없다면, 그 벤더가 에이전트의 실시간 동작(live behavior)을 통제하게 됩니다. 맞습니다, 에이전트는 고객의 클라우드에서 실행됩니다. 맞습니다, 고객이 모델 비용을 지불하고 에이전트에 로그인하기 위해 사용하는 모델 키(model key)를 보유하고 있습니다. 하지만 메모리, 에이전트 거버넌스(governance)의 기록, 에이전트 작업의 기록은 다른 어딘가에 존재합니다.

그 계층(layer)을 소유하십시오. 그렇지 않으면 에이전트의 메모리, 거버넌스, 그리고 운영 이력(operating history)은 타인의 백엔드에 속하게 됩니다.