보안 & 아이덴티티

당신의 Web3 에이전트는 안전합니까? MCP로 블록체인 트랜잭션의 보안 허점을 막는 법

2025년 12월 5일

Adrien Delaroche

Web3 Principal Architect

Try Gemini 3

Our most intelligent model is now available on Vertex AI and Gemini Enterprise

해당 블로그의 원문은 2025년 12월 6일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud는 AI와 Web3라는 두 가지 혁신적인 기술의 독특한 교차점에 있습니다. 블록체인과 상호작용할 수 있는 AI 에이전트의 등장은 자동화된 금융 전략, 빠른 결제, 그리고 복잡한 DeFi(탈중앙화 금융) 작업을 실행하거나 여러 체인에 걸쳐 자산을 연결(bridging)하는 등 더욱 복잡한 시나리오의 세계를 열어줍니다.

하지만 이 새로운 패러다임의 실질적인 실행 가능성은 누가 에이전트를 호스팅하고, 누가 작업에 필요한 개인 키를 소유하는가에 달려 있습니다.

핵심 문제는 간단합니다. 대부분의 암호화폐 사용자는 에이전트 키를 관리하기 위해 직접 보안 서버를 운영하지 않을 것이므로, 서비스 제공업체는 두 가지 주요 아키텍처 중 하나를 선택할 가능성이 높습니다. 첫째는 사용자가 개인 키를 제어하는 제3자 에이전트에게 자금을 위임하는 커스터디얼 모델(Custodial Model)이고, 둘째는 에이전트가 생성한 트랜잭션을 사용자가 자신의 개인 키로 직접 서명하는 논커스터디얼 모델(Non-custodial Model)입니다.

오늘날 대부분의 예시는 에이전트가 직접 개인 키를 보유하는 형태를 보여주며, 대부분의 암호화폐 모델 컨텍스트 프로토콜(MCP) 서버는 개인 키로 구성해야만 사용할 수 있습니다. 하지만 이것이 유일한 선택지는 아닐 수 있습니다.

에이전트 제어 모델 (Agent-Controlled Model)

이 모델은 사용자가 제3자가 호스팅하는 에이전트와 상호작용하는 환경을 위해 설계되었으며, 이는 기술 대중화를 위한 현실적인 가정입니다. 이 시나리오에서 사용자는 에이전트에게 자신의 개인 키를 제공하지 않습니다. 대신, 에이전트는 자체 키를 가지며, 사용자는 에이gent가 자신을 대신하여 자산을 사용할 수 있도록 허용량(allowance)을 부여합니다.

동작 방식

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_Agent-controlled_model_sequence_diagra.max-1800x1800.jpg

에이전트 제어 모델 시퀀스 다이어그램

에이전트가 지갑을 가집니다: 에이전트는 하나 또는 여러 개의 개인 키를 소유합니다. 이 지갑들의 개인 키는 사용자가 아닌, 에이전트의 호스트가 안전하게 관리합니다.
사용자가 자금을 위임합니다: 사용자는 개인 지갑(예: MetaMask, 하드웨어 지갑)에서 에이전트의 공개 주소로 특정 금액을 전송합니다.
에이전트가 자율성을 얻습니다: 이제 에이전트는 자신이 제어하는 지갑의 자금에 대해 완전한 자율적 통제권을 갖게 됩니다. 에이전트는 자신의 키를 사용하여 미리 지급된 잔액이 소진될 때까지 토큰을 교환(swap)하거나, NFT를 구매하거나, 다른 에이전트에게 데이터 비용을 지불하는 등의 트랜잭션에 서명하고 실행할 수 있습니다.

내재된 리스크

이 모델은 자동화를 제공하지만, 리스크의 주체를 사용자에게서 에이전트와 그 호스트로 이전시키는 중대한 위험을 내포합니다.

성능 리스크: 에이전트의 성능이 저조할 수 있습니다. 예를 들어, 트레이딩 에이전트가 잘못된 전략을 실행하여 사용자가 위임한 자금을 잃을 수 있습니다.
악의적 행위 리스크: 잘못 설계되었거나 의도적으로 악의적인 에이전트가 자금을 오용할 수 있습니다. 예를 들어, 에이전트가 승인되지 않은 주소로 잔액을 전송할 수 있습니다. 이러한 시나리오를 방지하기 위해, 호스팅 플랫폼은 에이전트의 행동을 제약하는 강력한 안전장치, 감사, 규칙을 갖추어야 합니다. 또 다른 옵션은 자금의 사용 방식을 보장하는 스마트 컨트랙트 안에 에이전트 자금을 안전하게 보관하는 것입니다.
보안 리스크: 제3자 호스트는 이제 사용자가 위임한 자금의 수탁자(custodian)가 됩니다. 만약 호스트 플랫폼이 해킹당해 에이전트의 개인 키가 유출된다면, 사용자가 선지급한 잔액이 주요 공격 대상이 될 것입니다.

자체 호스팅(Self-hosted) 변형 모델

기술적으로 숙련된 소수의 사용자는 개인 서버에서 이 모델을 직접 실행하기를 원할 것입니다. AI 에이전트 개발이 아직 초기 단계에 있기 때문에, 이 소규모 개발자 및 얼리 어답터 그룹이 현재의 주요 사용자층을 형성하고 있습니다.

결과적으로, 이 자체 호스팅 모델은 오늘날 가장 흔하게 접할 수 있는 방식이며, 대부분의 암호화폐 MCP 서버가 이를 지원하도록 구축되고 있습니다. 이 경우, 키가 사용자가 직접 제어하는 환경을 절대 벗어나지 않기 때문에 에이전트에게 개인 키를 제공하는 것이 기술적으로 안전합니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_-_Self-hosted_agent_model_sequence_diagr.max-1300x1300.jpg

자체 호스팅 에이전트 모델 시퀀스 다이어그램

하지만 이 방식 역시 매우 높은 수준의 리스크를 동반합니다. 사용자의 기기가 손상되면 개인 키가 해킹될 수 있으며, 비정상적이거나 승인되지 않은 에이전트의 행동은 상당한 손실로 이어질 수 있습니다.

예를 들어, 사용자가 "500 USD를 UNI로 교환하고 싶어"라고 말했을 때, 에이전트가 UNI를 매도하거나, UNI를 매수하면서 슬리피지(slippage) 비율을 잘못 설정하거나, 혹은 엉뚱한 UNI 토큰을 구매할 수도 있습니다. 이 접근 방식은 테스트 용도로만 사용하는 것을 권장합니다.

트랜잭션 생성자 모델 (Transaction-Crafter Model)

이 모델은 대부분의 사용자 상호작용에 더 적합한, 논커스터디얼(Non-custodial) 방식이며 근본적으로 더 안전한 대안입니다. 여기에서 에이전트는 사용자의 자금을 절대 보유하지 않습니다. 이 모델의 목적은 에이전트 제어 모델과 정확히 동일한 작업을 수행하지만, 트랜잭션에 직접 서명하고 전송하는 대신, 사용자가 직접 서명하고 블록체인 네트워크에 전송할 수 있도록 트랜잭션을 사용자에게 반환합니다.

동작 방식

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_-_Transaction_crafter_model_sequence_dia.max-1300x1300.jpg

트랜잭션 생성자 모델 시퀀스 다이어그램

사용자가 에이전트에게 지시합니다: 사용자는 "내 ETH를 USDC로 바꿔줘"와 같이 에이전트에게 작업을 요청합니다.
에이전트가 트랜잭션을 생성합니다: 에이전트는 사용자의 요청을 분석하고, 스왑(swap) 트랜잭션과 같은 원시(raw) 트랜잭션을 구성합니다.
사용자가 트랜잭션에 서명합니다: 에이전트는 이 데이터를 사용자에게 다시 전달합니다. 사용자의 지갑에는 실행하려는 작업이 정확히 무엇인지 보여주는 팝업창이 표시됩니다. 오직 사용자만이 개인 키로 이를 승인하고 서명할 수 있습니다.

Google Cloud 도구로 에이전트 구축하기

이 모델을 시연하기 위해, 저는 여러 Google Cloud 도구를 사용하여 샘플 에이전트를 구축했습니다. 에이전트의 추론은 Gemini 2.0 Flash 모델을 기반으로 하며, Google Agent Development Kit (ADK)를 사용하여 전체 흐름을 조율(orchestration)했습니다. 테스트를 위한 자금은 개발자에게 핵심적인 리소스인 공개 Google Cloud Ethereum Faucet에서 얻었습니다.

ADK를 사용하여 에이전트를 개발하는 것은 매우 간단하며, 다음과 같은 유용한 기능들을 제공합니다.

간단한 테스트 및 개발 환경을 위한 웹 UI
에이전트를 프로덕션 환경에 쉽게 배포할 수 있는 Agent Engine 및 Google Cloud Run과의 강력한 통합
커스텀 프론트엔드와 쉽게 연결하기 위해 에이전트를 API 서버로 실행하는 간단한 방법
MCP 서버, 에이전트 간(A2A) 프로토콜, Google 검색과 같은 도구에 쉽게 연결할 수 있는 툴박스

Google Cloud 스택을 사용하여 에이전트를 구축하는 방법에 대해 더 자세히 알고 싶다면, 이 아티클을 읽어보세요.

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_cejGPDZ.max-1800x1800.jpg

이 앱은 크게 두 부분으로 구성됩니다. 바로 트랜잭션을 생성하는 에이전트와, 에이전트로부터 생성된 트랜잭션을 받아 MetaMask로 전달하여 서명과 전송을 처리하는 프론트엔드입니다.

Google ADK를 사용하면 에이전트 개발 자체는 매우 간단하지만, craft_eth_transaction 함수는 지원하는 작업의 종류에 따라 상당히 복잡해질 수 있습니다. 여기에는 다음과 같은 작업들이 포함됩니다.

로드 중...

from google.adk.agents import Agent
from web3 import Web3

ETH_RPC_URL = "RPC URL"

# (This is the tool function defined in the next section)
def craft_eth_transaction(to_address: str, amount: float, from_address: str, chain_id: int):
   # Step 1: Fetch the sender's next transaction count (nonce)
   # Step 2: Determine transaction type (ETH transfer or smart contract call)
   # Step 3: Construct the 'data' field using ABI
   # Step 4: Assemble and return the final, unsigned transaction

# The Agent is defined with a simple, non-custodial instruction
root_agent = Agent(
   name="transaction_crafter_agent",
   model="gemini-2.0-flash",
   description="An agent that crafts Ethereum transactions for a front-end to send via MetaMask.",
   instruction=(
       "You are an agent that crafts ETH transactions. "
       "Your only job is to collect the information from the user to craft Ethereum transactions.. "
       "The sender's address will be provided to you as context, along with the chain ID."
       "Use the `craft_eth_transaction` tool to generate the transaction object. "
       "The tool will return a JSON object that is ready to be sent to MetaMask. "
       "Leave gas and gasPrice fields empty; MetaMask will set them."
       "**IMPORTANT:** After using the tool, you must present the final transaction JSON in the response, formatted exactly like this:\n"
       "   ```json\n"
       "   {\n"
       "     \"to\": \"0x...\",\n"
       "     \"from\": \"0x...\",\n"
       "     \"value\": \"0x...\",\n"
       "     \"nonce\": \"0x...\",\n"
       "     \"chainId\": \"0xaa36a7\"\n"
       "   }\n"
       "   ```\n"
   ),
   tools=[craft_eth_transaction],
)

클라이언트 측(client-side)의 로직은 깔끔하며 Web3 상호작용에만 집중합니다. 프론트엔드는 대규모 언어 모델(LLM)이나 에이전트 오케스트레이션(agent orchestration)에 대해 전혀 알 필요가 없습니다. 그저 Google Cloud Run에서 호스팅되는 에이전트의 API 엔드포인트를 호출하고, 표준 JSON 트랜잭션 객체를 반환받아 MetaMask로 전달하기만 하면 됩니다.

에이전트를 API 서버로 쉽게 실행할 수 있는 ADK의 기능 덕분에 이처럼 명확한 관심사 분리(separation of concerns)가 가능합니다. 프론트엔드의 두 가지 주요 기능은 에이전트의 응답에서 트랜잭션을 추출하고, 이를 MetaMask로 보내는 것입니다. 다음은 해당 함수들의 예시입니다.

로드 중...

/**
* Step 1: Process the agent's response to extract the crafted transaction data.
* The agent's only output is a standard, unsigned transaction object.
*/
function extractTransactionFromAgentResponse(agentEvents) {
   const functionResponse = agentEvents.find(
       e => e.content?.parts?.[0]?.functionResponse?.name === 'craft_eth_transaction'
   )?.content.parts[0].functionResponse;

if (functionResponse?.response?.success) {
       // The raw transaction object, ready for the user's wallet
       return functionResponse.response.transaction;
   }
   return null;
}

/**
* Step 2: Pass the crafted transaction to the user's wallet for execution.
* This function triggers a MetaMask pop-up, putting the user in full control.
*/
async function executeMetaMaskTransaction(txData) {
   if (!txData || typeof window.ethereum === 'undefined') {
       console.error("Invalid transaction data or MetaMask not found.");
       return;
   }

try {
       // The 'eth_sendTransaction' call asks the wallet to sign and send.
       // The private key is never exposed to our web application.
       const txHash = await window.ethereum.request({
           method: 'eth_sendTransaction',
           params: [txData], // txData is the JSON object from the agent
       });

console.log(`Transaction sent successfully! Hash: ${txHash}`);
       return txHash;

} catch (error) {
       // This error typically means the user rejected the transaction in MetaMask.
       console.error("Transaction failed or was rejected by user:", error);
   }
}

에이전트가 사용자의 의도를 확인하는 방법

에이전트와의 대화를 통해 의사 결정을 내리는 것이 에이전트 작업의 과정이라면, MetaMask 팝업창은 그 대화의 최종 결론입니다.

이를 금융 자문가가 투자 전략을 설명한 뒤 최종 서류에 서명을 요청하는 디지털 버전이라고 생각해보세요. 그 서명은 바로 사용자가 해당 행위를 이해하고 동의한다는 것을 의도적이고 명확하게 확인하는 필수 절차입니다. 이는 사용자의 명시적인 승인을 통해 에이전트의 제안을 현실로 만들며, 결정적인 심리적 안정감을 제공합니다. 특히 기반 LLM, 대화의 문맥, 접근 가능한 데이터에 따라 에이전트의 해석이 크게 달라질 수 있다는 점을 고려할 때, 승인 전 지갑 트랜잭션을 두 번 확인하는 것은 언제나 좋은 습관입니다.

MCP 서버는 두 가지 현실을 모두 지원해야 합니다

에이전트가 다른 에이전트에게 서비스 비용을 자율적으로 지불하는 미래 비전을 실현하기 위해서는 에이전트 제어 모델이 필수적입니다. 이러한 경제 생태계의 에이전트들은 운영을 위해 자신만의 자본이 필요할 것입니다.

하지만 트랜잭션 생성자 모델은 그 미래로 나아가는 안전한 다리 역할을 합니다. 이 모델은 에이전트에게 안전하게 자금을 지원하거나, 혹은 더 간단한 작업을 위해 일회성 트랜잭션을 실행하는 데 사용될 수 있습니다. 이러한 유연성이 바로 핵심입니다.

개발자의 관점에서 이 기능을 추가하는 것은 그리 어려운 일이 아닙니다. 만약 MCP 서버가 이미 보유한 키로 트랜잭션을 준비하고 서명할 수 있다면, 최종 서명 단계 없이 동일한 로직을 수행하고 서명되지 않은 트랜잭션을 반환할 수도 있어야 합니다. 이 작은 변화는 사용자를 위해 훨씬 더 안전하고 유연한 패러다임을 열어주며, 나아가 다중 에이전트 시스템에서 전용 "서명 에이전트(signer agent)"와 같은 더 복잡한 설계를 가능하게 할 수도 있습니다.

따라서 폭넓은 채택을 위해 설계된 견고한 MCP 서버라면, 개발자에게 다음과 같은 애플리케이션을 구축할 수 있는 유연성을 제공해야 합니다.