Cursor에 프라이빗 키 그만 붙여넣기: 코딩 에이전트에게 지갑 주는 법

빌드 중인 상황을 떠올려보자. Cursor 안의 에이전트가 컨트랙트 호출을 작성하고, 네트워크를 선택하고, 테스트 트랜잭션을 보낼 준비를 마쳤다. 계획과 서명된 트랜잭션 사이에 남은 것은 키 하나뿐이다. 그래서 프라이빗 키를 에이전트가 읽을 수 있는 .env 파일에 붙여넣고, 계속 작업을 이어간다.

바로 이 한 단계 때문에 많은 숙련된 개발자들이 실제 자금이 걸린 작업에서 AI를 멀리 둔다. 프라이빗 키는 전부 아니면 전무다. 에이전트가 키를 읽을 수 있게 되는 순간, 그 지갑에 있는 모든 것을, 어느 체인에서든, 영구적으로, 되돌릴 방법 없이 옮길 수 있다. 그리고 에이전트는 설계상 확률적이다. 대부분은 아주 잘 작동하지만, 가끔은 자신만만하게 틀린다.

더 나은 방법이 있다. 키를 넘기지 않고 지갑을 넘기는 것이다. 아래에서 Alchemy CLI의 agent wallets가 어떻게 작동하는지, 그리고 실제 한계가 어디에 있는지 설명한다.

문제는 에이전트가 아니라 키다

에이전트를 위험 요소로 취급하고 싶어지지만, 사실 에이전트는 진짜 문제가 아니다. 프라이빗 키는 애초에 공유하도록 설계된 적이 없다. "이 금액까지만 보낼 수 있다", "이 체인에서만", "다음 한 시간 동안만", "지금 당장 멈춰라" 같은 개념이 전혀 없다. 프라이빗 키는 전체 통제권을 부여하는 단일 비밀이며, 이를 사용하는 유일한 방법은 그것을 노출시키는 것뿐이다.

지금까지 개발자에게는 두 가지 선택지가 있었고, 둘 다 실제 비용을 수반했다. 키를 .env에 붙여넣고 에이전트가 자금을 완전히 통제하도록 받아들이는 방법이 있는데, 이는 잘못된 프롬프트 하나로 지갑이 비워질 수 있는 상태다. 아니면 지갑 SDK를 커스텀 백엔드에 연결해서 인증, 서명, 철회 로직을 직접 다시 구축하는 방법도 있는데, 이는 대부분의 팀이 감당하기엔 몇 주가 걸리는 작업이다. 첫 번째는 너무 위험하고, 두 번째는 너무 비싸다.

실제로 원하는 것은 스택의 다른 부분에서 접근 권한을 다루는 방식과 더 비슷하다. 루트 비밀번호를 그냥 넘겨주지 않는다. 범위가 제한된 자격증명을 발급하고, 무엇을 할 수 있는지 설정하고, 끝나면 철회한다. 지갑도 같은 방식으로 작동해야 한다.

Agent wallets는 어떻게 작동하는가

Alchemy CLI의 agent wallets를 사용하면 대시보드에서 지갑을 생성하고, 터미널에 범위가 제한되고 시간이 한정된 세션을 부여하고, 에이전트가 커맨드라인에서 실제 트랜잭션을 보내게 할 수 있다. 프라이빗 키는 CLI에 닿지 않고, Alchemy에도 닿지 않으며, .env 파일에 저장되지도 않는다. 이를 각각 다른 주체가 소유하는 세 개의 레이어로 보면 이해하기 쉽다.

커스터디 레이어: 키는 다른 누군가가 보관한다

지갑의 프라이빗 키는 우리의 임베디드 지갑 파트너인 Privy가 자체 인프라에서 보관한다. 여러분의 노트북에도, 레포에도, 우리 시스템에도 없다. 이것이 위험 계산을 바꾸는 핵심이다. 방금 전까지 .env에 붙여넣으려던 비밀이, 이제는 여러분도 에이전트도 직접 다룰 일이 없는 것이 된다.

세션 레이어: 에이전트는 비밀이 아니라 권한을 받는다

alchemy wallet connect를 실행하면 CLI는 여러분의 기기에서 새로운 P-256 키페어를 생성하고, 그 쌍의 프라이빗 절반은 기기를 벗어나지 않는다. 브라우저가 Alchemy 대시보드로 열리고, 거기서 지갑을 선택하고 세션을 승인한다. 승인을 하면 CLI의 퍼블릭 키가 해당 지갑의 서명자로 등록되며, 특정 기능으로 범위가 제한되고 여러분이 설정한 만료 시점으로 경계가 지어진다.

그 이후로 모든 서명 호출은 2단계 챌린지 방식으로 진행된다. 우리 백엔드가 Privy가 기대하는 정확한 페이로드를 구성하고, CLI가 그 정확한 바이트를 로컬에서 서명하며, 그런 다음에야 요청이 Privy에 도달한다. 세션이 만료되었거나, 철회되었거나, 바인딩 검사에 실패하면 다음 서명 시도는 우리 인프라를 벗어나기도 전에 거부된다. 에이전트는 자신이 가진 비밀을 통해서가 아니라, 여러분이 정의한 세션을 통해 동작하는 것이다.

컨트롤 레이어: 킬 스위치는 여러분이 쥐고 있다

지갑을 생성하거나 철회할 수 있는 곳은 대시보드뿐이며, 철회는 클릭 한 번으로 즉시 적용된다. 터미널에서 alchemy wallet disconnect를 실행할 수도 있다. 세션이 의도하지 않은 일을 하기 시작하면, 세션을 종료하면 서명이 멈춘다. 세션이 알아서 잘 작동하기를 그저 바라고만 있을 필요가 없다. 언제든 종료할 수 있기 때문이다.

에이전트가 실제로 할 수 있는 일

세션이 활성화되면, 에이전트는 온전한 트랜잭션 범위를 다룰 수 있다. EVM 체인에서는 네이티브 토큰과 ERC-20을 보내고, 컨트랙트를 호출하고, ERC-20 승인을 관리하고, 스왑하고, 메인넷 간 브리지를 할 수 있다. Solana에서는 SOL과 SPL 토큰을 보낼 수 있다. 트랜잭션은 우리의 Wallet API를 통해 실행되므로, Gas Manager를 통한 가스 스폰서십, 배칭, 자동 재시도, ERC-20 가스 결제도 함께 제공된다.

CLI는 에이전트를 위한 도구 표면으로 설계되었기 때문에, 에이전트는 이런 명령어들을 스스로 파악한다. --json 플래그는 구조화된 출력을 반환하고, --no-interactive은 명령어가 프롬프트에서 막히지 않게 해주며, alchemy agent-prompt은 모든 명령어, 플래그, 에러 코드를 설명하는 JSON 문서를 출력한다. 이것을 시스템 프롬프트에 넣으면 에이전트는 전체 범위를 한 번에 학습한다. 통합해야 할 SDK도 없고, 문서에서 추론해야 할 것도 없다.

누구를 위한 것이며 어떤 흐름에 맞는가

이것은 Cursor나 Claude Code에서 지내며 온체인 작업을 하는 개발자를 위한 것이다: DeFi 프로토콜을 통합하거나, 결제 흐름을 연결하거나, 컨트랙트를 테스트하면서, 서명이 필요한 지점에서 멈추는 대신 에이전트가 실제로 트랜잭션을 실행하기를 원하는 사람. 에이전트가 코드를 작성하게 하고 나서 온체인 부분은 직접 마무리해온 적이 있다면, 이 도구가 그 간극을 메운다. 두 가지 흐름이 이 도구가 제 역할을 하는 지점을 보여준다.

첫 번째는 빌드-앤-테스트 루프다. 프로토콜과 통합 작업을 하고 있고, 에이전트가 코드를 작성했다. 실제로 작동하는지 알려면 누군가 실제 트랜잭션을 보내야 한다: 컨트랙트에 자금을 넣고, 호출하고, 결과 상태를 확인하고, 조정하고, 다시 실행한다. 이를 직접 하면 모든 트랜잭션을 직접 승인하고 붙여넣어야 하는데, 이는 애초에 에이전트를 데려온 이유인 그 번거로움 그 자체다. 세션을 사용하면 지갑을 만들고, 소액을 입금하고, 짧은 만료 시간으로 범위가 제한된 세션을 승인한 뒤, 에이전트가 전체 루프를 실행하게 둔다. 에이전트는 보내고, 결과를 읽고, 반복하며, 여러분은 지켜본다. 세션이 만료되면 접근 권한도 자동으로 끝난다.

두 번째는 여러 단계로 이루어진 온체인 작업을 수행하는 에이전트다. 어떤 작업은 단일 호출이 아니라 일련의 시퀀스다: 메인넷에서 토큰을 스왑하고, 그 수익을 L2로 브리지한 다음, 포지션에 예치한다. 결과물을 설명하고 에이전트가 세션을 통해 각 단계를 수행하게 할 수 있다. 각 단계를 직접 실행할 필요가 없다. 세션은 에이전트가 사용할 수 있는 기능과 기간을 제한하는 것이지, 얼마나 많이 옮길 수 있는지를 제한하는 것이 아니다. 따라서 작업에 필요한 만큼만 지갑에 자금을 넣고, 짧은 만료 시간을 설정하고, 끝나면 철회한다.

한계에 대한 솔직한 설명

돈을 다루는 도구는 만든 사람들이 그 한계를 분명히 밝힐 때 더 신뢰하기 쉬워진다. 프로덕션에서 이를 신뢰하기 전에 알아둘 만한 몇 가지 한계가 있다.

가스 및 수수료 스폰서십 정책은 트랜잭션 수수료를 제어한다. 지갑 지출 한도가 아니므로, Gas Manager 정책을 에이전트가 옮길 수 있는 금액의 상한선으로 취급해서는 안 된다. 스왑과 브리지는 현재 EVM 메인넷에서만 지원된다. 세션 서명자는 raw EVM 트랜잭션을 직접 서명하지 않는다. 동작은 wallet_prepareCalls나 wallet_sendCalls 같은 Alchemy Wallet API 호출을 통해 실행된다. 그리고 세션은 대시보드에서 설정한 범위 그대로다. 즉 여러분이 설정한 만료 시간과 기능이 실제 경계이며, 이는 단순한 권고가 아니다.

이 중 어느 것도 우회책이 아니다. 이것이 시스템이 작동하도록 설계된 방식이다. 지갑이 커스터디를 유지하고, 세션이 권한을 전달하며, 여러분은 이를 종료할 수 있는 능력을 계속 쥐고 있다.

시작하기

CLI의 agent wallets는 이제 정식으로 제공되며, 대기자 명단도 별도 등급도 없다. Node 22 이상과 Alchemy 계정이 필요하다. 세 개의 명령어면 에이전트가 제어할 수 있는 지갑에 도달할 수 있다:

connect 단계는 대시보드를 여는데, 여기서 세션을 승인하고 범위와 만료 시간을 설정한다. 상태를 변경하는 워크플로우를 실행하기 전에, 먼저 에이전트가 세션을 검증하게 하자:

작업이 끝나면 세션을 종료한다:

온체인에서 가장 까다로운 제품을 만드는 팀들은 이미 Alchemy 위에서 운영되며, 100개 이상의 체인에서 연간 1조 달러가 넘는 금액을 처리한다. Agent wallets의 요점은, 같은 인프라가 이제 코딩 에이전트에게 넘겨주는 지갑도 뒷받침한다는 것이다. 키를 넘기지 않으면서도 말이다. Cursor에 프라이빗 키를 붙여넣는 대신, 에이전트에게 범위가 제한된 세션을 주고 언제든 철회할 수 있는 능력을 유지할 수 있다.

agent wallets 문서를 읽어보거나, Alchemy for agents를 살펴보거나, CLI를 설치해서 직접 시도해보자.

FAQ

프라이빗 키를 공유하지 않고 AI 코딩 에이전트에게 지갑을 넘겨주려면 어떻게 해야 하나요?

Alchemy 대시보드에서 지갑을 생성한 다음, 터미널에서 alchemy wallet connect --mode session을 실행하세요. CLI는 로컬 키페어를 생성하고, 대시보드에서 범위가 제한되고 시간이 한정된 세션을 승인합니다. 에이전트는 그 세션을 통해 트랜잭션을 보내며, 프라이빗 키는 지갑 제공자에게 남아 있고 절대 노출되지 않습니다.

프라이빗 키는 실제로 어디에 저장되나요?

지갑의 프라이빗 키는 Alchemy의 임베디드 지갑 파트너인 Privy가 자체 인프라에서 보관합니다. 여러분의 기기, 레포, .env 파일에 기록되는 일이 없으며, CLI나 Alchemy 자체 시스템에도 닿지 않습니다. 에이전트는 키 자체가 아니라 승인된 세션을 통해 동작합니다.

에이전트의 지갑 접근 권한을 철회할 수 있나요?

네. Alchemy 대시보드에서 클릭 한 번으로 세션을 철회하거나, 터미널에서 alchemy wallet disconnect을 실행하면 됩니다. 철회는 즉시 적용되며, 해당 세션의 다음 서명 시도는 거부됩니다. 세션은 승인할 때 설정한 시간에 자동으로 만료되기도 합니다.

agent wallet로 에이전트는 무엇을 할 수 있나요?

EVM 체인에서 에이전트는 네이티브 토큰과 ERC-20을 보내고, 컨트랙트를 호출하고, 승인을 관리하고, 스왑하고, 메인넷 간 브리지를 할 수 있습니다. Solana에서는 SOL과 SPL 토큰을 보낼 수 있습니다. 트랜잭션은 Alchemy의 Wallet API를 통해 실행되므로 가스 스폰서십, 배칭, 재시도, ERC-20 가스 결제를 이용할 수 있습니다.

스폰서십 정책이 에이전트가 쓸 수 있는 금액을 제한하나요?

아니요. 가스 및 수수료 스폰서십 정책은 트랜잭션 수수료를 제어하는 것이지 지갑 잔액을 제어하는 것이 아닙니다. 지출 한도가 아닙니다. 에이전트가 할 수 있는 일의 실제 경계는 대시보드에서 세션에 설정한 기능과 만료 시간이므로, 세션의 범위를 신중하게 설정하세요.

시작하려면 무엇이 필요한가요?

Node 22 이상과 Alchemy 계정이 필요합니다. CLI의 agent wallets는 대기자 명단도 별도 등급도 없이 정식으로 제공됩니다. npm i -g @alchemy/cli@latest로 설치하고, alchemy auth를 실행한 다음, alchemy wallet connect --mode session으로 대시보드에서 세션을 승인하세요.