동시성 문제 — 1,000개의 AI 에이전트가 동일한 체인에 접속할 때

에이전트 하나는 쉽습니다. 단일 루프, 단일 지갑, 단일 RPC 엔드포인트, 몇 분마다 한 번씩 실행되는 sendTransaction. 거의 무엇이든 문제없이 해낼 수 있습니다.

그러다 누군가 "규모를 키워보자(scale it up)"라고 말합니다. 이제 당신에게는 1,000개의 에이전트가 있고, 모두가 트랜잭션에 서명하며, 모두가 인프라를 공유하게 되며, 체인은 이에 저항하기 시작합니다. 극적인 에러가 아니라, 조용한 에러로 말이죠. 결코 컨펌(confirm)되지 않는 트랜잭션, 지갑을 먹통으로 만드는 논스(nonce) 간격(gap), 오후 시간을 통째로 잡아먹는 속도 제한(rate limits) 등이 발생합니다.

에이전트를 대량으로 실행할 때 실제로 무엇이 고장 나는지, 그리고 이를 어떻게 엔지니어링하여 해결할 수 있는지 설명하겠습니다.

첫 번째 벽: 논스 관리 (Nonce Management)

특정 지갑에서 발생하는 모든 트랜잭션은 시퀀스 번호인 논스(nonce)를 가집니다. 체인은 이 논스들이 간격 없이, 정확히 한 번씩, 순서대로 사용될 것을 요구합니다. 간격(gap)이 생기는 것은 재앙적입니다. 논스 간격이 발생하면 누락된 논스가 채굴될 때까지 그 _이후_의 모든 트랜잭션이 동결됩니다.

단순한 멀티 에이전트 설정은 다음과 같습니다:

async def run_agent(agent_id: int, wallet: Wallet):
    while True:
        tx = await build_transaction(agent_id)
...

get_next_nonce — 이것이 바로 버그의 원인입니다. 두 에이전트가 동시에 이를 호출하면, 둘 다 42를 받게 되고, 둘 다 논스 42로 트랜잭션을 제출합니다. 하나는 컨펌되지만, 다른 하나는 드롭(dropped)됩니다. 이제 당신의 지갑에는 43에서 간격이 발생하며, 이후의 모든 에이전트 트랜잭션은 무기한 정지됩니다.

해결책은 세 가지 부분으로 구성됩니다:

1. 지갑당 단일 논스 매니저(Single nonce manager). 하나의 프로세스가 논스 카운터를 소유하고 락(lock) 하에서 증가된 값을 할당합니다. 어떤 에이전트도 체인의 논스 엔드포인트에 직접 접근하지 않습니다.
2. 대기 중인 트랜잭션(Pending-tx) 추적. 노드의 pending 뷰를 신뢰하지 마세요. nonce → tx_hash에 대한 자체 맵을 유지하고 컨펌 상태와 대조하여 조정(reconcile)해야 합니다.
3. 에이전트별 지갑(Per-agent wallets). 가장 깔끔한 해결책은 에이전트당 하나의 키 쌍(keypair)을 사용하는 것입니다. 공유된 논스 공간도 없고, 에이전트 간의 오염(poisoning)도 없으며, 어떤 에이전트가 무엇을 소비했는지 감사(audit)해야 할 때 회계 처리가 깔끔합니다.

두 번째 벽: RPC 속도 제한 (RPC Rate Limits)

Public RPC 엔드포인트(endpoints)는 매우 공격적으로 속도 제한(rate-limit)을 적용합니다. 흔히 IP당 초당 20~40개의 요청 수준입니다. 모든 동작마다 getBalance, getFee, simulateTransaction, sendTransaction을 수행하는 에이전트 함대(fleet)는 불과 몇 초 만에 이 제한을 초과해 버립니다.

단순한 대응책은 실패 시 단순히 재시도(retry)하는 것입니다. 진정한 대응책은 호출 낭비를 멈추는 것입니다:

• 상태를 폴링(poll)하지 말고 캐싱(cache)하세요. 잔액(balances)과 논스(nonces)를 로컬에서 추적하고, 본인이 직접 전송하거나 블록 이벤트가 발생했을 때만 무효화(invalidate)하세요. 대부분의 에이전트 루프는 이미 알고 있는 데이터를 다시 읽습니다.
• 체인이 허용하는 한 배치(batch) 처리하세요. JSON-RPC 배치 요청(batch requests)을 사용하면 10번의 읽기 작업을 1번의 HTTP 왕복(round trip)으로 압축할 수 있습니다.
• 엔드포인트를 순환(rotate)시키세요. 에이전트 함대를 여러 제공업체와 로컬 노드에 분산시키세요. 하나의 엔드포인트가 429(Too Many Requests) 오류를 내더라도 함대 전체가 멈추지 않도록 해야 합니다.

유용한 패턴은 모든 RPC 호출 주위에 작은 서킷 브레이커(circuit breaker)를 두는 것입니다:

class RpcPool:
    def __init__(self, endpoints):
        self.endpoints = [Endpoint(url) for url in endpoints]
...

빠르게 실패하고(fail fast), 장애 조치(fail over)를 수행하며, 죽은 엔드포인트를 절대 계속 두드리지 마세요.

세 번째 벽: 리오그(Reorgs)와 컨펌 혼란 (Confirmation Confusion)

에이전트는 컨펌(confirmations)을 바탕으로 행동합니다. 하지만 깊이(depth) 1에서 컨펌된 것처럼 보였던 블록이 리오그(reorg, 재구성)로 인해 사라질 수 있으며, 이와 함께 에이전트의 세계관 전체가 사라질 수 있습니다.

에이전트의 다음 동작이 이전 트랜잭션이 실제로 안착했는지 여부에 달려 있다면, 다음 사항들이 필요합니다:

• 최소 컨펌 깊이(minimum confirmation depth): 체인의 최종성(finality) 모델에 맞춰 조정해야 합니다 (Solana는 몇 초 내에 최종성이 확정되지만, 더 느린 체인은 더 많은 인내심이 필요합니다).
• 조정 작업(Reconciliation jobs): 리오그 이후에 "논스(nonce) N에서의 내 트랜잭션이 실제로 성공했는가?"를 재확인하고, 성공하지 않았다면 다시 제출(re-submit)하는 작업입니다.
• 멱등적 동작(Idempotent actions): 모든 에이전트 동작은 중복 제거 키(dedupe key) — 즉 (agent_id, action_type, target, params)의 해시값 — 를 포함해야 합니다. 그래야 리오그 이후 동일한 동작을 다시 제출하더라도 중복 실행되지 않습니다.

대부분의 "자율 에이전트(autonomous agent)" 데모가 조용히 실패하는 지점이 바로 여기입니다. 데모 환경에서는 리오그가 발생하지 않기 때문에 잘 작동하는 것처럼 보일 뿐입니다. 하지만 실제 체인 위에서 규모를 확장(scale)하면, 결국 리오그는 발생합니다.

네 번째 벽: 수수료와 가스 경매 (Fees and the Gas Auction)

에이전트 군단(fleet)의 규모가 작을 때는 수수료 시장이 요구하는 대로 지불하면 됩니다. 하지만 군단의 규모가 커지면, 당신이 곧 수수료 시장이 됩니다.

핵심은 수수료 전략을 전역적(global)으로 설정하는 것이 아니라, 트랜잭션별(per-transaction)로 설정하는 것입니다.

• 우선순위 클래스 (Priority classes). 정산에 중요한 작업(보상 청구, 포지션 종료 등)에는 공격적인 수수료를 책정합니다. 관리 작업(상태 업데이트, 로깅 등)은 저렴한 경로를 이용하게 합니다.
• 스팸을 보내지 말고 백오프(Backoff) 하세요. 멤풀(mempool)이 혼잡하다면, 상한선(cap)을 두고 수수료를 기하급수적으로 높인 뒤 기다리세요. 동일한 수수료로 동일한 트랜잭션을 스팸처럼 계속 보내는 것은 RPC 예산만 낭비할 뿐입니다.
• 혼잡 시간을 피해 스케줄링하세요. 사용 패턴을 예측할 수 있는 체인에서는 긴급하지 않은 트랜잭션을 활동량이 적은 시간대에 배치(batch)하여 처리하세요.

아키텍처 관점에서의 모습

대규모 확장(scale) 시에도 살아남는 패턴은 다음과 같습니다:

┌─────────────┐     ┌──────────────────┐     ┌──────────────┐
│  Agent Fleet │────▶│  Execution Core  │────▶│  Chain Layer │
│  (per-agent  │     │  nonce manager   │     │  (multi-RPC, │
...

에이전트는 단순하고 단일 목적(single-purpose)을 유지합니다. 실행 코어(execution core)가 논스(nonce), 수수료, 재시도(retry), 확정 추적(confirmation tracking)을 담당합니다. 체인 레이어(chain layer)는 RPC의 복잡함을 추상화합니다. 각 레이어는 독립적으로 확장 가능합니다.

다이어그램에 포함되지 않은 것들에 주목하세요. 크론 스크립트(cron scripts), 쉘 루프(shell loops), "그냥 노드에 직접 호출하기" 같은 것들 말입니다. 그것들은 시작하는 방법이지, 확장하는 방법이 아닙니다.

솔직한 결론

이러한 문제 중 새로운 것은 없습니다. 분산 시스템(distributed systems)은 수십 년 동안 논스(nonce)와 유사한 순서 지정, 재시도, 멱등성(idempotency) 문제를 해결해 왔습니다. 새로운 점은 블록체인이 당신이 통제할 수 없는 외부 상태를 추가했다는 것입니다: 리오그(reorgs), 수수료 시장, 최종성 지연(finality latency), 속도 제한(rate limits) 등 말이죠. 당신의 에이전트는 단순히 당신의 서비스와 대화하는 것이 아니라, 자신만의 의견(opinions)을 가진 살아있는 네트워크와 협상하는 것입니다.

그렇기 때문에 제가 성공하는 것을 본 팀들은 이를 첫날부터 스크립팅 (scripting) 문제가 아닌 인프라 (infrastructure) 문제로 취급합니다. 만약 단일 체인 (single chain) 상에서 플릿 (fleet)을 구축하고 있다면, 위에서 언급한 네 가지 장벽이 당신의 로드맵이 될 것입니다. 만약 여러 체인에 걸쳐 구축하고 있다면, 각 체인은 동일한 네 가지 장벽에 대해 저마다의 특성을 가집니다 — 서로 다른 최종성 (finality), 서로 다른 수수료 모델 (fee models), 그리고 서로 다른 RPC 특이사항 (RPC quirks) 등이 그것입니다.

만약 실행 코어 (execution core)를 처음부터 다시 구축하고 싶지 않다면, BBIO와 같은 플랫폼이 바로 이러한 교훈들을 사전에 반영하기 위해 존재합니다 — 이는 논스 시퀀싱 (nonce sequencing), 멀티 RPC 페일오버 (multi-RPC failover), 확정 추적 (confirmation tracking), 그리고 체인 간 에이전트별 키 관리 (per-agent key management)를 처리하는 블록체인 AI 에이전트를 위한 관리형 런타임 (managed runtime)으로, 이를 통해 당신의 팀은 제품을 실제로 차별화하는 에이전트 로직 (agent logic)에 집중할 수 있습니다.

어떤 방식이든: 동시성 (concurrency)이 필요해지기 전에 미리 설계하십시오. 장벽은 당신이 멈출 여유가 가장 없을 때 정확히 나타납니다.