Pydantic AI vs smolagents — Web3 에이전트 결제는 무엇으로 만들까

삼코딩

@samcoding

Pydantic AI vs smolagents — Web3 에이전트 결제는 무엇으로 만들까

Pydantic AI vs smolagents — Web3 에이전트 결제는 무엇으로 만들까

인공지능 에이전트가 스스로 온체인 결제를 처리하고 스마트 계약과 상호작용하는 자율형 에이전트 상거래 시장이 빠르게 성장하고 있습니다. 파이썬 환경에서 코인베이스 에이전트킷(AgentKit)을 활용해 온체인 결제 에이전트를 개발할 때, 개발자는 피단틱 AI(Pydantic AI)와 허깅페이스의 스몰에이전트(smolagents)라는 두 가지 프레임워크를 두고 고민하게 됩니다. 안전한 의존성 주입을 통한 자산 보호와 코드 기반 실행을 통한 지연 시간 단축이라는 전혀 다른 아키텍처적 지향점을 가진 두 도구의 핵심 차이와 프로젝트 목적에 맞는 실전 선택 기준을 살펴봅니다.

Pydantic AI: 완벽한 타입 안전성과 보안 의존성 주입

온체인 비즈니스를 수행하는 AI 에이전트 개발에서 가장 중요한 두 가지는 개인키를 포함한 지갑의 보안과 트랜잭션 데이터의 정확성입니다. 피단틱 AI(Pydantic AI)는 패스트API 스타일의 견고한 타입 검증과 실행 컨텍스트(RunContext) 기반의 의존성 주입 모델을 통해 이 문제를 해결합니다.

가장 강력한 설계적 장점은 지갑 인스턴스나 프라이빗 키 같은 민감한 자원을 글로벌 상태에 노출하지 않고, 오직 개별 도구의 로컬 런타임 범위 내에만 안전하게 가두는 RunContext 메커니즘입니다. 코인베이스 에이전트킷의 CdpEvmWalletProvider를 에이전트 실행 시점에 의존성으로 주입하면, LLM이 직접 지갑 객체나 서명 키에 직접 접근하는 것을 원천 차단하면서도 안전하게 트랜잭션을 실행할 수 있습니다.

python
from pydantic_ai import Agent, RunContext
from coinbase_agentkit import CdpEvmWalletProvider

class AgentDeps:
    def __init__(self, wallet: CdpEvmWalletProvider):
        self.wallet = wallet

agent = Agent('openai:gpt-4o', deps_type=AgentDeps)

@agent.tool
def transfer_usdc(ctx: RunContext[AgentDeps], to_addr: str, amount: float) -> str:
    # CdpEvmWalletProvider가 글로벌 상태 오염 없이 로컬 범위에만 안전하게 주입됨
    tx_hash = ctx.deps.wallet.transfer(to_address=to_addr, amount=amount)
    return f"전송 완료: {tx_hash}"

만약 LLM이 유효하지 않은 헥사 주소를 제출하거나 가스비 한도를 잘못 계산하는 등 비정상적인 데이터를 반환할 경우, 피단틱의 데이터 검증 레이어가 즉시 오류를 감지합니다. 이 검증 실패는 LLM에 다시 올바른 형식을 요청하는 모델 재시도 루프를 자동으로 트리거하여, 에이전트가 깨진 트랜잭션을 블록체인에 제출하는 사고를 사전에 차단합니다.

smolagents: 단 한 번의 LLM 실행으로 트랜잭션 묶기

허깅페이스의 스몰에이전트(smolagents)는 LLM이 JSON 호출 스키마를 주고받는 대신, 직접 실행 가능한 파이썬 코드를 작성해 로컬에서 실행하는 코드-액션(Code-as-Action) 모델을 제안합니다.

기존 웹3 에이전트 설계에서 가장 곤혹스러운 점은 가스비 확인, 토큰 교환 경로 탐색, 최종 전송까지 이어지는 파이프라인의 지연 시간이었습니다. 각 도구를 호출할 때마다 LLM과 애플리케이션을 여러 차례 오가야 했기 때문입니다. 단계마다 최소 1.5초에서 3초의 LLM 추론 지연 시간이 쌓여 전체 실행 속도가 치명적으로 느려졌습니다. 스몰에이전트는 이 다단계 흐름을 단 한 번의 LLM 호출로 생성된 로컬 파이썬 스크립트 실행으로 압축합니다. 에이전트는 로컬 런타임에서 직접 변수를 할당하고, 조건문을 처리하며 라이브러리를 활용해 루프를 돌립니다.

코인베이스 에이전트킷 도구를 주입받은 에이전트가 작성하고 실행하는 코드 흐름은 다음과 같습니다.

python
# smolagents가 작성하고 로컬에서 즉시 실행하는 파이썬 코드 예시
gas_price = get_gas_price()
if gas_price < 30:
    swap_res = swap_usdc_to_eth(amount=100)
    tx = transfer_eth(to_address="0xRecipient...", amount=0.05)
    print(f"Transaction Success: {tx}")

이처럼 복잡한 분기 처리와 트랜잭션 실행이 모델의 재개입 없이 단일 로컬 루프 내에서 완결되므로, 오프체인 지연 시간을 크게 줄이면서 온체인 트랜잭션 효율성을 대폭 극대화할 수 있습니다.

지연 시간과 가스비 대결: 실전 프로덕션 벤치마크

온체인 환경에서 AI 에이전트의 응답 지연 시간과 트랜잭션 가스비는 서비스 사용성과 직결됩니다. 이 부분에서 피단틱 AI와 스몰에이전트의 아키텍처 차이가 가장 극명하게 드러납니다.

기존 피단틱 AI 같은 스키마 기반 JSON 도구 호출 방식은 가스비 조회, 스왑 경로 탐색, 토큰 전송 같은 다단계 작업을 수행할 때 매 단계마다 LLM 추론을 거쳐야 합니다. 사용 모델에 따라 단계마다 약 1.5초에서 3초의 네트워크 지연 시간이 순차적으로 누적되므로, 간단한 결제 흐름을 완료하는 데도 10초 이상이 소요되곤 합니다.

반면 코드-액션 모델을 사용하는 스몰에이전트는 LLM이 한 번의 추론으로 전체 실행 흐름을 담은 파이썬 코드를 작성합니다. 로컬 실행 루프 덕분에 전체 LLM 호출 단계를 30%에서 70%까지 대폭 단축할 수 있습니다. 비록 코드를 안전하게 실행하기 위해 E2B나 모달(Modal) 같은 격리된 마이크로 가상머신(microVM) 샌드박스를 띄우는 데 약 100ms에서 300ms의 오버헤드가 발생하지만, 수 초 단위의 LLM 호출 횟수 자체를 줄여주므로 최종 지연 시간은 오히려 획기적으로 줄어듭니다.

가스비 최적화 측면에서도 스몰에이전트가 유리합니다. 생성된 파이썬 코드 내부에서 web3.py 같은 라이브러리를 사용해 여러 계약 호출을 단일 EVM 멀티콜로 직접 묶어 처리할 수 있기 때문입니다. 이는 단계별로 트랜잭션을 따로 전송하는 순차 호출 방식에 비해 온체인 가스 오버헤드를 최대 40%까지 절감해 줍니다.

다만, 유연한 코드 실행이 주는 강력함의 이면에는 치명적인 보안 리스크가 숨어 있습니다. 생성된 코드에 버그가 있거나 악의적인 프롬프트 주입 공격을 받을 경우, 에이전트 지갑의 자산이 한순간에 유출될 위험이 있습니다. 이 때문에 스몰에이전트를 프로덕션에 적용할 때는 철저한 격리 환경인 가상 샌드박스가 강제됩니다. 이에 반해 피단틱 AI는 정해진 정적 스키마 구조 내에서만 도구를 호출하므로, 별도의 무거운 가상 샌드박스 없이도 일관된 안정성과 강한 자산 보안을 누릴 수 있습니다.

내 Web3 에이전트 프로젝트에는 무엇을 쓸까

프로젝트의 보안 수준과 트랜잭션 실행 속도 중 무엇이 더 중요한지에 따라 선택은 명확해집니다. 규제 준수와 엄격한 자산 관리가 필요해 철저한 검증과 오작동 방지가 중요한 엔터프라이즈 환경이라면 피단틱 AI가 제공하는 타입 검증과 의존성 주입 모델이 가장 안전한 선택입니다. 반면 실시간 가스비 변동에 대응하며 여러 탈중앙화 금융 프로토콜에서 여러 트랜잭션을 한 번에 묶어 처리해야 하는 자율형 결제 에이전트라면 스몰에이전트의 코드 실행 모델이 큰 이점을 제공합니다. 해결하려는 비즈니스 시나리오의 위협 모델과 비용 효율성을 꼼꼼히 비교해 보고 최적의 에이전트 아키텍처를 구성해 보시기 바랍니다.

참고 링크

(수정됨)