블록체인 데이터가 AI 컨텍스트가 되면, 오래된 상태(Stale State)는 보안 위험이 됩니다

*자율 에이전트가 지갑(wallets), 스마트 컨트랙트(smart contracts), 그리고 탈중앙화 프로토콜(decentralised protocols)과 상호 작용할 때 정확한 검색 이상의 것이 필요한 이유는 무엇일까요?

블록체인 시스템은 거래 및 상태 변경의 공유 기록을 유지하도록 설계되었습니다. AI 에이전트는 정보를 해석하고, 목표에 대해 추론하며, 다음에 무엇을 할지 결정하도록 설계되었습니다. 이론적으로 두 가지를 결합하는 것은 간단해 보입니다. 에이전트에게 블록체인 데이터 접근 권한을 주고, 현재 상황을 이해하게 하며, 행동할 수 있도록 허용하는 것입니다.

하지만 그 워크플로우 안에는 문제가 숨어 있습니다. AI 에이전트가 검색한 데이터는 가져올 때는 정확할 수 있지만, 에이전트가 이를 기반으로 행동할 때는 여전히 안전하지 않을 수 있습니다.

지갑 잔액이 변경되었을 수 있습니다. 보류 중인 것으로 보이던 거래가 확정되었을 수 있습니다. 탈중앙화 거래소 풀(decentralised exchange pool)의 유동성이 손실되었을 수 있습니다. 대출 포지션이 청산에 더 가까워졌을 수 있습니다. 프로토콜의 인덱싱된 뷰는 아직 최신 블록을 반영하지 못했을 수도 있습니다.

이러한 상황들 중 어느 것도 모델이 환각(hallucinate)을 일으킬 필요를 반드시 요구하는 것은 아닙니다. 에이전트는 모든 필드를 올바르게 해석하고, 지침을 따르며, 더 이상 자신이 상호 작용하려는 시스템을 설명하지 않는 정보에 기반하여 완벽하게 합리적인 계획을 생성할 수 있습니다.

이것이 제가 프로덕션 AI 시스템을 생각할 때 특히 중요하다고 느끼는 실패의 유형입니다. 우리는 종종 모델 품질, 검색 정확도, 에이전트가 처리할 수 있는 컨텍스트 양에 집중합니다. 이러한 것들은 중요하지만, 더 근본적인 질문에 답하지 못합니다. 즉, 시스템이 사용할 때 그 컨텍스트가 여전히 유효한가?

이것은 블록체인 애플리케이션에서 특히 중요해집니다. 왜냐하면 AI 에이전트는 정보 읽기(reading information)를 넘어 거래를 시작하는(initiating transactions) 단계로 이동할 수 있기 때문입니다. 챗봇에서의 오래된 답변은 수정될 수 있습니다. 하지만 확정된 금융 거래를 초래하는 오래된 결정은 복구하기가 훨씬 어려울 수 있습니다.

그렇다면 문제는 단순히 AI 에이전트에게 더 많은 블록체인 데이터를 제공하는 것이 아닙니다. 그 데이터가 어디에서 왔는지, 어떤 현실 버전(version of reality)을 나타내는지, 그리고 다음 행동을 지원하기에 충분히 신뢰할 수 있는지 이해하는 시스템을 설계하는 것입니다.

블록체인은 정확하지만 에이전트가 틀릴 수 있다 (The blockchain can be correct while the agent is wrong)

분산 금융(DeFi) 포트폴리오를 모니터링하는 역할을 맡은 가상의 AI 에이전트를 가정해 봅시다. 이 에이전트는 지갑 잔액을 검색하고, 대출 프로토콜을 확인하며, 두 개의 탈중앙화 거래소에서 유동성을 비교하고, 포트폴리오의 일부를 다른 포지션으로 이동할 것을 권장합니다. 그 계산은 정확합니다. 관련 컨트랙트 주소(contract addresses)도 정확합니다. 준비하는 트랜잭션은 설정된 지출 한도를 준수합니다.

하지만 이 결정은 여전히 안전하지 않습니다. 왜일까요? 트랜잭션을 구성하는 데 사용된 정보가 서로 다른 시점의 것이었기 때문입니다.

지갑 잔액은 몇 초 전에 검색되었습니다. 거래소 유동성은 최근 이벤트를 아직 처리 중이던 인덱서(indexer)에서 왔습니다. 대출 포지션은 별도의 RPC 엔드포인트(endpoint)에서 읽어왔습니다. 그 사이에 다른 트랜잭션이 지갑 잔액을 변경했고, 시장도 움직였습니다.

각 응답은 생성되었을 당시에는 유효했을 수 있습니다. 하지만 이들이 결합된 것은 더 이상 시스템에 대한 일관된 시각을 나타내지 못합니다. 이것은 서로 다른 구성 요소들이 서로 다른 시간에 변화를 관찰하는 분산 시스템(distributed-systems) 문제의 익숙한 범주입니다. 블록체인 인프라는 애플리케이션이 종종 온체인 읽기(on-chain reads), 이벤트 스트림(event streams), 인덱싱된 데이터셋(indexed datasets), 외부 가격 피드(external price feeds), 그리고 로컬 캐시를 결합하기 때문에 이 문제를 특히 두드러지게 만듭니다. AI 에이전트는 이 과정에 또 다른 단계를 추가합니다. 정보를 검색한 직후 반드시 행동을 실행하는 것은 아닙니다. 여러 대안을 추론하거나, 추가 도구를 호출하거나, 결과를 요약하거나, 또는 다른 에이전트에게 평가를 요청할 수 있습니다. 계획이 준비될 무렵에는 원래의 관찰 내용 자체가 이미 구식이 되었을 수 있습니다.

가장 중요한 구분은 검색 시점의 데이터 정확성(data correctness at retrieval time)과 실행 시점의 결정 유효성(decision validity at execution time) 사이입니다. 이 둘은 같은 보증이 아닙니다. 블록체인 노드는 쿼리한 상태에 대한 올바른 잔액을 반환할 수 있습니다. 인덱서(indexer)는 받은 모든 이벤트를 정확하게 처리할 수 있습니다. 검색 시스템은 요청된 기록을 정확히 반환할 수 있습니다. 하지만 이러한 사실들 중 어느 것도 완전한 컨텍스트가 몇 초 후에 트랜잭션에 적합하게 유지됨을 보장하지 않습니다. 이것이 바로 AI 에이전트들이 금융 인프라와 상호 작용하기 시작할 때, 컨텍스트 엔지니어링(context engineering)이 단순한 검색 문제를 훨씬 넘어선다는 저의 믿음입니다. 컨텍스트는 시스템 상태의 표현으로 취급되어야 하며, 이 표현을 신뢰할 수 있는 명시적인 시간 제한이 필요합니다.

블록체인 데이터가 에이전트에게 도달하는 여러 경로

오래된 컨텍스트(stale context)를 관리하기 어려운 이유 중 하나는 블록체인 애플리케이션들이 모든 정보를 단일 소스에서 얻는 경우가 거의 없다는 점입니다.

특정 블록 상태에 대한 계좌 잔액을 검색할 수 있습니다. 계약 호출(contract call)은 프로토콜별 정보를 반환할 수 있습니다. 이벤트 로그(Event logs)는 기록된 변경 사항을 설명하며, 인덱서(indexer)는 이러한 이벤트를 애플리케이션 친화적인 기록으로 변환할 수 있습니다.

이러한 메커니즘들은 서로 다른 목적을 수행합니다. 예를 들어, Ethereum의 JSON-RPC 문서는 상태를 검사하는 데 사용되는 메서드와 과거 정보를 검색하고 네트워크 활동을 추적하는 데 사용되는 메서드를 구분합니다. 이러한 응답들을 결합하는 애플리케이션은 모든 결과를 현실의 상호 교환 가능한 스냅샷으로 취급하기보다는, 각 응답이 무엇을 나타내는지 이해해야 합니다.

인덱싱(Indexing)은 또 다른 고려 사항을 추가합니다. The Graph와 같은 서비스는 블록체인 이벤트를 처리하고 애플리케이션이 더 편리하게 쿼리할 수 있는 구조화된 데이터를 노출합니다. 이는 저수준 블록체인 데이터로부터 유용한 애플리케이션 상태를 재구성해야 하는 부담을 크게 줄여줍니다. 하지만 인덱싱된 표현(indexed representation)은 여전히 체인의 처리된 뷰일 뿐입니다. 이는 인덱싱의 진행 상황, 이벤트를 해석하는 데 사용된 논리, 그리고 근본적인 데이터 파이프라인의 일관성에 달려 있습니다.

성공적으로 쿼리가 반환되었다고 해서, 그것만으로는 해당 인덱서가 에이전트 결정과 관련된 블록을 따라잡았음을 입증하지 못합니다. 이러한 아키텍처 자체에 본질적인 결함은 없습니다. 인덱싱된 데이터는 가치가 있으며, RPC 접근(RPC access)은 필수적이고, 이벤트 기반 시스템(event-driven systems)은 모든 컨트랙트를 반복적으로 폴링(polling)하는 것보다 종종 더 효율적입니다.

실수는 에이전트가 성공적인 검색을 신선함의 증거로 해석하도록 허용하는 것입니다. 컨텍스트 파이프라인은 단순히 값이 무엇인지뿐만 아니라, 어디서 왔는지, 어떤 상태를 설명하는지, 그리고 애플리케이션이 안전하게 추론할 수 있는 것이 무엇인지를 전달해야 합니다.

신선함(Freshness)은 단지 타임스탬프가 아니다

오래된 컨텍스트(stale context)에 대한 첫 번째 대응은 종종 타임스탬프를 추가하거나 시간 제한(time-to-live), 즉 TTL을 구성하는 것입니다. 이는 유용한 출발점이지만, 블록체인 애플리케이션에는 더 신중한 접근 방식이 필요합니다.

에이전트가 10:00:00에 토큰 잔액을 검색하고 10:00:03에 트랜잭션을 준비하는 상황을 상상해 보십시오. 저위험 모니터링 작업의 경우 3초는 완벽하게 허용될 수 있습니다. 하지만 같은 지연 시간은 급변하는 거래 가격이나 청산 임계값 근처의 대출 포지션에 의존하는 작업에서는 용납되지 않을 수 있습니다. 이제 반대 상황을 고려해 봅시다. 인덱싱된 기록이 1분 전에 생성되었지만, 이는 완전히 확정된 블록(fully finalised block)을 나타내며, 애플리케이션은 단지 과거 보고서가 필요할 뿐입니다. 이 기록은 그 목적에 전적으로 적합할 수 있습니다.

정보의 안전성을 결정하는 것은 단순히 나이(age)만은 아닙니다. 신선도(freshness)는 의사결정, 출처, 관련 상태가 변경될 수 있는 속도, 그리고 잘못된 가정에 따라 행동했을 때의 결과에 달려있습니다. 블록체인 인식 에이전트(blockchain-aware agents)에게는 최소한 네 가지 차원을 구분할 필요가 있습니다.

시간적 신선도 (Temporal freshness): 관측(observation)을 수행한 시점으로부터 얼마나 많은 시간이 지났습니까?

체인 신선도 (Chain freshness): 해당 관측이 어떤 블록을 나타내며, 이 블록은 네트워크의 현재 상태와 어떻게 관련됩니까?

출처 신선도 (Source freshness): 관련 RPC 엔드포인트(RPC endpoint)나 인덱서(indexer)가 이 결정을 위해 필요한 변경 사항들을 처리했습니까?

결정 신선도 (Decision freshness): 제안된 행동을 정당화했던 가정이 계획 및 실행 전반에 걸쳐 유효하게 유지되었습니까?

네 번째 차원은 특히 중요합니다. 에이전트는 최신 데이터를 검색하고, 이에 대해 추론하는 시간을 할애한 다음, 그 가정들이 무효화된 계획에 따라 행동할 수 있습니다. 단순한 TTL(Time To Live)로는 이 문제를 완전히 해결할 수 없습니다. 더 유용한 설계는 행동 유형별로 신선도 요구사항을 할당합니다. 포트폴리오 요약을 위해 과거 이체 내역을 읽는 것은 스왑(swap) 제출이나 대출 프로토콜에서 담보물 변경을 시도하는 것과는 다른 기준을 필요로 할 수 있습니다.

시스템은 단순히 “이 관측은 3초 전의 것이다”라고 말할 수 있는 것을 넘어, “이 관측은 이 결정을 위한 요구사항을 충족한다” 또는 “실행 전에 이 정보는 새로 고쳐져야 한다”와 같이 말할 수 있어야 합니다. 그것이야말로 신뢰할 수 있는 자율성(reliable autonomy)을 위한 훨씬 강력한 기반입니다.

블록 번호는 타임스탬프가 제공할 수 없는 맥락을 제공한다

블록체인 애플리케이션은 신선도를 관리할 때 추가적인 이점을 가집니다. 바로 관측들을 체인별 식별자(chain-specific identifiers)와 연관시킬 수 있다는 점입니다.

이더리움과 호환되는 네트워크에서, 애플리케이션은 상태 관찰(state observation)과 관련된 블록 번호와 블록 해시를 기록할 수 있습니다. 이는 단순히 벽시계 시간 스탬프보다 더 유용한 정보를 제공합니다. 예를 들어, 에이전트가 대출 포지션을 읽고 그 관찰이 블록 24,000,100에서 왔다고 기록했다고 가정해 봅시다. 그런 다음 시장 데이터와 지갑 잔액을 검색합니다. 만약 이 관찰들이 서로 다른 블록을 참조한다면, 시스템은 그것들이 동일한 체인 상태를 나타내지 않을 수 있음을 알게 됩니다.

그렇다고 해서 관찰들이 자동으로 사용 불가능해지는 것은 아닙니다. 서로 다른 블록 참조는 모니터링이나 탐색적 분석(exploratory analysis)에는 완벽하게 허용될 수 있습니다. 그러나 제안된 행동이 일관된 값의 집합에 의존하는 경우, 이러한 불일치(mismatch)는 시스템에서 눈에 띄어야 합니다. 블록 식별자(Block identifier) 또한 중요합니다. 왜냐하면 블록체인 기록은 항상 즉시 최종적이지 않기 때문입니다. 네트워크와 사용되는 관찰에 따라, 처음에 체인의 헤드(head)로 간주되었던 블록이 재조직화(reorganisation) 과정에서 나중에 대체될 수 있습니다.

Ethereum의 JSON-RPC 인터페이스는 latest, safe, 그리고 finalized를 포함한 블록 태그(block tags)를 노출합니다. 이들은 체인 진행 과정에서 서로 다른 위치를 나타내며, 필요한 상태 유형을 표현하는 방법을 제공합니다. 적절한 선택은 작업에 따라 달라집니다.

모니터링 에이전트는 새로 발생하는 기회를 감지하기 위해 사용 가능한 최신 상태(latest available state)를 관찰하는 것에서 이점을 얻을 수 있습니다. 최종 회계 결과를 기록하는 시스템은 더 강력한 최종성 보장(finality guarantee)을 요구할 수 있습니다. 트랜잭션을 준비하는 에이전트는 어떤 가정이 임시적인 관찰에 의존하고, 어떤 것이 실행 전에 유지되어야 하는지 이해해야 합니다.

모든 AI 에이전트가 어떤 행동을 하기 전에 최종화된 상태(finalized state)를 기다려야 한다는 보편적인 규칙은 없습니다. 기다리는 것은 일부 애플리케이션에 불필요한 지연 시간(latency)을 초래할 수 있습니다. 엔지니어링 과제는 이러한 트레이드오프(trade-off)를 명시적으로 만드는 것입니다.

시스템은 자신이 잠정적인 관찰(tentative observation)을 하는 것인지, 충분히 안정된 상태(sufficiently stable state)를 기반으로 한 결정인지, 아니면 최종화된 데이터(finalised data)가 필요한 결론인지를 알아야 합니다. 이러한 구분이 없으면, 모델은 근본적인 블록체인 보장(underlying blockchain guarantees)이 다르더라도 모든 검색된 값을 동등하게 권위 있다고 취급할 수 있습니다.

더 위험한 문제는 일관성 없는 컨텍스트이다 (inconsistent context)

오래된 데이터(Stale data)는 문제의 일부일 뿐입니다. 에이전트(agent)는 또한 함께 속하지 않는 개별적으로 정확한 관찰값들을 받을 수도 있습니다. 대출 신청을 예로 들어보겠습니다. 한 도구는 최신 담보 가치(collateral value)를 반환합니다. 다른 도구는 더 이전 블록의 부채 잔액(debt balance)을 반환합니다. 세 번째 도구는 최근 상환 내역이 아직 반영되지 않은 인덱서(indexer)가 계산한 건강 지수(health factor)를 검색합니다.

모델은 세 가지 그럴듯한 값을 보고 일관된 설명을 구성합니다. 하지만 이 설명은 혼합된 스냅샷(mixed snapshot)을 기반으로 합니다. 이는 적절한 일관성 전략(suitable consistency strategy) 없이 관련 레코드의 다른 버전들을 읽는 데이터베이스 트랜잭션과 유사합니다. 각 레코드는 그 자체로는 유효할 수 있지만, 결합된 뷰는 단일하고 일관된 상태로 존재했던 적이 없을 수도 있습니다.

자율 에이전트(autonomous agent)에게 이러한 불일치성은 행동으로 이어질 수 있습니다. 위치가 안전하지 않은데도 안전하다고 결론 내릴 수 있습니다. 더 이상 미지급 부채와 일치하지 않는 상환 금액을 추천할 수도 있습니다. 다른 작업이 완료된 후 사용 가능한 잔액을 초과하는 트랜잭션을 준비할 수도 있습니다.