크립토 토큰 승인(Allowance): 권한 확인과 취소 방법

웹사이트에 지갑을 연결하면 앱은 보통 공개 주소를 확인하고 거래 서명을 요청할 수 있습니다. 이것만으로 앱이 지갑의 모든 ERC-20 토큰을 옮길 권한을 얻는 것은 아닙니다. 토큰을 대신 쓰게 하는 승인은 토큰 컨트랙트에 따로 기록되며, 나중에 연결을 해제하는 작업과는 다른 상태입니다. MetaMask도 앱 연결 해제와 토큰 승인을 별개의 권한으로 설명합니다.

ERC-20 allowance는 토큰 컨트랙트 안에서 토큰 컨트랙트 + 체인 + 소유자 주소 + spender 주소 조합에 따라 관리됩니다. Ethereum에서 USDC spender에게 준 한도는 같은 지갑 주소라도 Polygon의 USDC나 다른 토큰 승인이 아닙니다. 따라서 “이 사이트에 한 번 승인했다”라고만 기억하면 어느 토큰과 네트워크의 권한인지 놓치기 쉽습니다.

이 글의 예시는 Ethereum과 호환 네트워크에서 쓰이는 ERC-20의 approve, allowance, transferFrom을 기준으로 합니다. 네이티브 ETH 송금, NFT의 setApprovalForAll, 다른 체인의 자산 권한, 지갑의 로그인 연결은 같은 기능이 아닙니다. 자산의 개인 키 백업과 복구는 별도 문제이므로 시드 문구 백업과 지갑 복구 안내도 함께 확인하세요.

ERC-20에서 사용자는 토큰 컨트랙트의 approve(spender, amount)를 호출해 특정 spender가 자기 토큰을 정해진 양까지 사용하도록 허용할 수 있습니다. ERC-20의 transferFrom은 그 spender가 소유자를 대신해 토큰을 보내는 데 쓰입니다. 따라서 approve 자체는 일반적으로 토큰 잔액을 다른 주소로 옮기지 않지만, 그 뒤의 컨트랙트 호출에서 허용 한도가 소비될 수 있습니다. 이는 ERC-20 표준에 정의된 allowance 흐름입니다.

예를 들어 지갑에 토큰 300개가 있고 특정 거래 라우터에 80개 allowance를 줬다면, 표준을 따르는 정상 ERC-20에서 그 spender가 해당 권한으로 사용할 수 있는 양은 남은 allowance와 잔액 중 작은 값으로 제한됩니다. 이 한도는 거래 한 건만을 가리키지 않을 수 있습니다. 컨트랙트가 여러 번 transferFrom을 부를 수 있고, 승인 당시 생각한 거래와 다른 호출 경로가 악용되면 의도하지 않은 이동이 일어날 수 있습니다. 토큰의 비표준 동작이나 추가 제한도 확인해야 합니다.

승인 요청은 보통 토큰 컨트랙트에 보내는 온체인 트랜잭션이며, 지갑에서 네트워크 수수료가 발생할 수 있습니다. 일부 서비스는 승인과 스왑을 별도 트랜잭션으로 나누고, 일부는 서명형 권한을 후속 트랜잭션과 함께 처리합니다. “승인”이라는 버튼 이름만 보지 말고 실제 서명 내용과 네트워크를 구분하세요.

지갑이 Unlimited 또는 매우 큰 숫자로 표시하는 승인은 보통 그 토큰의 최대 정수에 가까운 allowance를 설정합니다. 무한대 토큰이 생기는 것도, 승인 순간 잔액이 전송되는 것도 아닙니다. 다만 spender는 같은 토큰과 체인에서 남아 있는 한도를 사용해 이후 지갑에 들어오는 토큰까지 요청할 수 있습니다. 일부 구현은 최대값 allowance를 사용해도 차감하지 않고 남겨 둘 수 있으므로 화면의 “최대”가 실제로 어떻게 처리되는지 토큰 동작을 확인해야 합니다.

앱이 반복 승인을 줄이려고 넓은 한도를 요청할 수 있지만, 편리함과 위험은 함께 평가해야 합니다. spender 컨트랙트의 코드에 취약점이 생기거나 운영 권한이 악용되면, 이전에 허용한 권한이 뒤늦게 사용될 수 있습니다. Ethereum.org의 권한 취소 안내는 넓은 allowance가 남아 있을 때 사용자가 자산을 지갑으로 다시 옮긴 뒤에도 위험이 이어질 수 있다고 설명합니다.

반대로 필요한 양만큼만 승인한다고 모든 위험이 사라지는 것은 아닙니다. 잘못된 spender 주소나 가짜 토큰을 승인하면 작은 한도도 손실로 이어질 수 있고, 거래마다 승인을 다시 하면 수수료와 실수 기회가 늘 수 있습니다. 실제로 사용할 양, 사용 빈도, 프로토콜과 spender를 얼마나 신뢰하는지, 승인 상태를 다시 확인할 수 있는지를 함께 보세요.

서명 직전에 네 가지를 살펴보세요. 첫째, 지갑이 선택한 네트워크가 사이트가 안내한 네트워크와 일치하는지 확인합니다. 둘째, 심볼 이름만 믿지 말고 토큰 컨트랙트 주소와 토큰을 확인합니다. 셋째, 권한을 받는 spender 주소가 그 서비스의 공식 문서나 확인 가능한 컨트랙트 주소와 일치하는지 봅니다. 넷째, 허용 한도가 거래에 필요한 양인지, 크게 오래 남는 권한인지 구분합니다.

브라우저 주소창의 도메인, 광고 검색 결과, 고객지원 DM이나 QR 코드에서 바로 지갑을 연결하지 마세요. 피싱 사이트는 실제 앱과 비슷한 화면을 보여 줄 수 있습니다. 저장해 둔 공식 주소나 프로젝트의 공식 문서에서 시작하고, 컨트랙트 이름이 익숙하다는 이유만으로 주소를 신뢰하지 마세요. 블록 탐색기의 검증 표시도 컨트랙트 코드의 안전성을 보증하지 않습니다.

하드웨어 서명 장치는 개인 키를 일반 브라우저에서 분리하는 데 도움을 줄 수 있지만, 사용자가 승인하는 spender나 금액이 안전한지는 따로 판단해야 합니다. 장치가 트랜잭션 내용을 읽기 쉬운 형식으로 보여 주지 못하면 임의로 서명하지 말고, 지갑 공급자의 공식 설명에서 해당 요청의 의미를 확인하세요. 화면에 보이는 정보가 제한적이면 검토 능력도 제한적입니다.

일부 ERC-20은 ERC-2612 permit을 지원합니다. 일반 approve 트랜잭션 대신 소유자가 typed-data 메시지에 서명하면, 누구든 그 서명을 제출해 token allowance를 설정할 수 있습니다. permit 메시지에는 소유자, spender, 한도, nonce와 deadline이 포함되며, 표준은 체인과 컨트랙트 도메인을 사용해 서명 재사용을 제한합니다.

여기서 deadline은 서명을 permit 호출로 제출할 수 있는 마지막 시점입니다. ERC-2612에 따라 이미 제출되어 설정된 allowance가 그 시각에 자동으로 만료된다는 뜻은 아닙니다. 승인된 한도는 이후 소비되거나 다시 설정되거나 취소될 때까지 남을 수 있습니다. 일부 토큰은 다른 permit 방식이나 추가 만료 규칙을 가질 수 있으므로, 모든 서명 화면에 보이는 “permit”을 ERC-2612와 동일하게 취급하지 마세요.

서명은 가스 비용을 다른 계정이 대신 부담하게 하는 흐름에 쓰일 수 있지만, 서명 자체가 무해한 로그인 확인이라는 뜻은 아닙니다. 지갑이 토큰, spender, 한도, 만료 시점을 명확히 보여 주지 않거나 웹사이트 설명과 맞지 않으면 서명을 거절하고 공식 문서를 확인하세요. 이미 만든 서명은 아직 제출되지 않았더라도 지정된 deadline 전에 누군가 제출할 수 있습니다.

앱에서 로그아웃하거나 지갑의 사이트 연결을 끊으면 브라우저 세션 또는 지갑 연결 권한이 바뀝니다. 하지만 이미 토큰 컨트랙트에 기록된 ERC-20 allowance는 별도로 남아 있을 수 있습니다. 반대로 allowance를 취소해도 연결된 사이트가 알고 있는 공개 주소나 과거 온체인 기록이 사라지는 것은 아닙니다. MetaMask의 연결 해제 안내도 두 동작을 구별합니다.

온체인 allowance 취소는 해당 토큰과 spender에 허용한 값을 0으로 바꾸는 트랜잭션을 제출하는 방식이 일반적입니다. 그 트랜잭션에도 네트워크 수수료가 들며, 확인될 때까지 기존 권한이 아직 적용 중일 수 있습니다. 취소 뒤에는 승인 검사 화면이나 토큰 컨트랙트 상태를 새로 조회해 같은 지갑·체인·토큰·spender의 값이 실제로 0이 되었는지 확인하세요. MetaMask 도움말과 Ethereum.org는 체인별 approval checker를 확인하는 방법을 설명하지만, 어떤 도구를 쓰든 공식 도메인과 네트워크를 직접 확인해야 합니다.

각 체인에서 상태가 따로 기록되므로 Ethereum의 한도를 0으로 바꿔도 다른 네트워크의 동일 토큰 권한까지 자동으로 바뀌지 않습니다. 여러 지갑 계정, 토큰 컨트랙트, spender를 확인하고, 트랜잭션이 최종 반영된 뒤 결과를 다시 조회하세요. 승인 취소 도구에 시드 문구나 개인 키를 입력할 이유는 없습니다.

ERC-20 allowance를 0으로 바꾸면 그 상태가 반영된 뒤에는 해당 allowance를 근거로 새 transferFrom을 실행할 수 없습니다. 이미 완료된 토큰 전송을 되돌리거나, 수취 주소의 자산을 회수하거나, 스마트 계약의 다른 권한까지 없애 주는 작업은 아닙니다. 의심스러운 권한으로 토큰이 이미 옮겨졌다면 승인 취소만으로 회복된다고 기대해서는 안 됩니다.

취소 후에도 같은 지갑의 개인 키가 노출되면 공격자는 다른 방식으로 거래를 서명할 수 있습니다. 같은 토큰에 대한 다른 spender 승인, 다른 토큰의 승인, NFT 운영자 승인, permit 서명, 컨트랙트별 권한도 별도로 남을 수 있습니다. 취소 결과는 권한 목록을 확인한 정확한 지갑 주소와 체인 범위 안에서 해석하세요.

승인을 끊으면 다음 스왑·예치·상환 때 다시 허용해야 할 수 있습니다. 취소 버튼을 누르기 전에 그 spender가 미결 거래나 계속 사용하는 포지션과 연결되어 있는지 살펴보고, 필요한 경우 프로토콜의 공식 도움말을 확인하세요. 이는 권한을 유지하라는 뜻이 아니라, 취소로 인해 어떤 후속 동작이 달라지는지 알고 상태를 관리하라는 뜻입니다.

ERC-20 표준은 기존의 0이 아닌 allowance를 다른 0이 아닌 값으로 바꿀 때, 사용자 인터페이스가 먼저 0으로 설정하도록 권고합니다. spender가 기존 한도를 쓰는 트랜잭션과 새 한도를 설정하는 트랜잭션 사이에 끼어들면, 사용자가 생각한 것보다 많은 양이 승인되는 경합이 생길 수 있기 때문입니다. 예컨대 100에서 25로 바꾸려 할 때 spender가 먼저 기존 100을 쓰고 새 25가 설정되면 두 한도를 차례로 사용할 가능성이 생깁니다.

먼저 0으로 설정하고 확인된 다음 새 한도를 설정하면 두 값이 겹쳐 유효해지는 상황을 줄일 수 있지만, 0 트랜잭션이 확인되기 전에 기존 allowance가 사용되는 일까지 되돌리지는 않습니다. 두 단계는 각자 수수료를 낼 수 있고, 토큰별 동작이 다를 수 있습니다. 지갑이나 토큰이 제공하는 안전한 한도 변경 방법과 공식 안내를 확인하고, 트랜잭션 확인 전에 다음 단계로 넘어가지 마세요.

이미 allowance가 얼마인지 확신할 수 없다면 새 숫자를 덧씌우기 전에 현재 네트워크의 토큰 컨트랙트 상태를 조회합니다. 지갑 인터페이스에서 한도가 비어 있거나 토큰이 예상과 다르게 동작한다면, 다른 체인이나 다른 주소의 결과를 현재 권한으로 오해하고 있지 않은지도 확인하세요. 승인 값을 확인할 때는 지갑 주소와 토큰 컨트랙트 주소가 모두 맞아야 합니다.

1. 프로젝트의 공식 도메인과 선택한 체인을 다시 확인합니다.
2. 토큰 컨트랙트와 spender 주소를 확인하고, 사용하려는 양에 비해 권한이 과도한지 봅니다.
3. 지갑 서명 화면에서 트랜잭션 또는 typed-data의 실제 권한을 확인합니다. 읽을 수 없는 요청은 서명하지 않습니다.
4. 사용을 마쳤거나 더 이상 신뢰하지 않는 spender는 해당 네트워크에서 allowance를 조회하고, 필요하면 0으로 바꾼 뒤 결과를 다시 확인합니다.
5. 새 지갑을 고를 때는 체인 지원 목록뿐 아니라 승인 내용을 읽기 쉽게 보여 주는지, 키 백업과 복구가 이해 가능한지, 업데이트와 복구 정책을 확인할 수 있는지 비교합니다.

하드웨어 지갑은 키 관리와 서명 검토에 관한 선택지이지, 악성 계약을 자동으로 판별하거나 사용자가 넓은 한도를 승인하는 일을 막아 주는 보증은 아닙니다. 승인 화면이 안전을 대신 판단해 줄 것이라고 기대하지 말고, 확인 가능한 spender·토큰·네트워크·한도에 근거해 결정하세요. 승인 권한은 계정 연결과 별도로 남을 수 있다는 점을 기억하면, 지갑 보안 제품을 비교할 때도 실제 보호 범위와 한계를 구분할 수 있습니다.