토큰 승인은 지정한 상대가 컨트랙트 규칙에 따라 계정의 토큰을 쓰도록 허용하는 것이에요. ERC-20은 토큰 인터페이스 표준이며 대표적인 승인이 Approve예요. 연결이나 연결 해제는 승인·철회와 달라요. EIP-20은 한도 조회와 사용을, EIP-2612는 조건을 충족한 서명으로 한도를 설정하는 방식을 정의해요. 유한 한도로 효력·사용·철회를 살펴보며 자료 확인일은 2026년 10월 27일이에요.
지갑 확인창에서 어려운 것은 버튼보다 무엇에 동의하는지 이해하는 일이에요. 사이트는 로그인이라는데 화면은 거래 승인을 요구하고, 연결을 끊어도 누군가의 토큰 사용 한도는 체인에 남아 있을 수 있어요. 연결 여부만 보면 실제 지출 권한을 놓치기 쉬워요.
연결·거래·서명을 구분한 뒤 한 유한 한도 계획을 끝까지 따라가요. 각 단계 이후 실제로 바뀐 상태와, 그 결과만으로 안전하다고 할 수 없는 부분을 확인할 거예요.
지갑 연결·거래·서명은 다른 권한을 줘요
연결·Approve·메시지 서명을 모두 ‘승인 완료’라고 묶을 수는 없어요. 일반적인 연결로 사이트가 선택한 공개 주소를 얻고 후속 요청을 할 수 있지만, 요청 가능과 마음대로 자산을 옮길 권한은 달라요. 키 보관의 기본은 지갑과 자산 통제권에서 확인해요.
사이트 연결이 토큰 지출 승인은 아니에요
일반 ERC-20 토큰은 컨트랙트에 사용 한도를 기록해요. 보유자가 spender에게 한도를 주면 상대는 규칙에 따라 transferFrom을 호출해 보유자 토큰을 수신자에게 옮길 수 있어요. Spender는 사용을 승인받은 주소로, 컨트랙트나 일반 계정일 수 있어요. ‘라우터’라는 이름만으로 신뢰를 판단하지 않아요.
MetaMask 공식 ‘Disconnect wallet from a dapp’도 연결 해제가 토큰 승인을 철회하지 않는다고 설명해요. 연결은 화면의 연결 상태, 철회는 온체인 한도를 바꿔요. 하드웨어도 악성 지출 요구를 자동 거절하지 않아요. 하드웨어의 개인키 격리는 일부 키 탈취 위험을 줄이지만 사용자는 여전히 서명을 이해해야 해요.
Approve와 Permit은 효력이 생기는 시점이 달라요
Approve는 보통 토큰 컨트랙트로 보내는 거래예요. 버튼을 눌러도 온체인 실행 성공을 기다려야 새 한도가 됐다고 말할 수 있어요. 서명 거절·미전송·처리 대기·실패는 완료로 기록하지 않아요.
EIP-2612의 Permit은 보유자가 특정 데이터에 먼저 서명하고 본인이나 다른 사람이 나중에 제출하는 방식이에요. Gas는 온체인 실행의 과금 작업량이에요. 서명 순간에는 온체인 가스비가 없어도 이후 제출자가 한도를 설정할 수 있어요. 수수료가 안 나갔다고 자산 위험이 없다는 뜻은 아니에요. 다른 프로토콜에는 자체 서명·지출 구조가 있어 동일 철회 방식을 일괄 적용할 수 없어요.
승인 한도를 읽기 전에 네 가지 정보를 고정해요
네트워크·보유자·토큰 컨트랙트·승인받은 상대를 먼저 맞춰요. 하나가 빠지면 다른 체인·계정·토큰을 조회하고 0을 보고 잘못 안심할 수 있어요.
네트워크·보유자·토큰·승인 상대를 확인해요
보유자는 누구 계정에서 토큰이 나가는지, 컨트랙트는 어떤 토큰인지, 승인 상대는 누가 한도에 따라 쓸 수 있는지를 뜻해요. 수신자와 승인 상대는 다를 수 있으므로 최종 수신 주소를 그대로 spender로 보지 않아요.
EIP-20의 allowance(owner, spender)는 지정한 토큰 컨트랙트에서 보유자와 spender를 인수로 조회해요. 이름이 같은 토큰도 같은 컨트랙트가 아니며 주소 외형이 같아도 네트워크 확인은 필요해요. 공식 경로에서 전체 정보를 얻고 서명할 내용과 대조해야 어떤 상태를 바꿀지 알 수 있어요.
승인 한도는 잔액이 아니고 무제한도 무료가 아니에요
잔액은 현재 보유량, 승인 한도는 지정 상대가 컨트랙트 규칙에 따라 쓸 수 있는 범위예요. 20을 승인해도 잔액이 20 늘거나 즉시 20이 나가는 것은 아니에요. 한도가 잔액보다 크면 이후 들어오는 토큰까지 위험에 포함될 수 있어요.
무제한이나 큰 수는 사용 범위를 바꾸는 것이지 수수료를 없애지 않아요. 최대 한도·차감·변경 방식은 구현마다 달라요. 이후에는 사용 성공마다 줄어드는 유한 한도만 가정하며 모든 ERC-20을 대표하지 않아요. 12만 필요하다면 왜 더 큰 권한을 요구하는지 이해해야 해요. 다음번 편의 때문에 범위 확인을 생략하지 않아요.
유한 한도 연습: 20·8·0은 언제 성립하나요
한도와 잔액을 분리해야 각 단계에서 끝난 일을 알 수 있어요. A가 T 100단위를 보유하고 S가 그중 12를 쓰도록 한 뒤 남은 권한을 철회하는 가정이에요. A·S·T·수신자 R은 표식일 뿐 실제 배포·서명·송금은 없어요. 토큰 가격이나 이익 가정도 없어요.
1단계: 현재 한도를 읽고 작업 필요성을 확인해요
네트워크·A·T 컨트랙트·S를 고정해 현재 한도 0과 조회 시점을 기록해요. 그다음 S가 대신 쓰는 기능이 정말 필요한지, S가 신뢰할 수 있는 화면의 주소와 같은지 확인해요. 한 조합의 현재 온체인 한도 0만으로 다른 승인이나 유효한 서명이 없다고 증명하지는 못해요.
이번에는 20만 승인하고 12 사용 후 나머지를 처리하기로 해요. 20은 설명용 선택이지 모두에게 같은 한도를 권하는 것이 아니에요. 서명창의 S나 T가 바뀌면 준비를 취소하고 네 항목을 다시 확인해요. ‘아까 확인했다’는 이유로 다른 요구를 통과시키지 않아요.
2단계: 20만 승인하고 온체인 확인을 기다려요
A가 T에 대한 S의 한도를 20으로 설정하는 Approve를 준비한다고 가정해요. 거래 상대·호출·수수료를 대조해요. 20은 토큰 표시 단위예요. 컨트랙트는 더 작은 정수 단위를 사용할 수 있으니 토큰의 소수 자릿수에 맞춰 신뢰할 화면에서 변환해야 해요. 원시 정수를 화면 수량으로 보면 안 돼요.
서명했어도 미확정이면 대기로 적고 한도를 미리 20으로 쓰지 않아요. 성공 후 같은 조합을 조회해 20을 확인해야 효력 발생으로 기록해요. 이 단계는 T를 옮기지 않아 잔액은 100이에요. A가 수수료를 내면 네이티브 자산은 별도로 줄 수 있지만 T를 사용한 것과 섞지 않아요.
3단계: 12 사용 뒤 잔액 88·남은 한도 8을 확인해요
S가 규칙에 따라 A의 T 12를 R에게 성공적으로 옮기고 다른 변동은 없다고 가정해요. A 잔액은 100−12＝88, 유한 한도는 20−12＝8이에요. 각각 남은 보유량과 상대가 더 쓸 수 있는 양에 답하므로 숫자가 다른 것이 맞아요.
작업 화면의 체크 표시만 보지 않아요. 원 거래 성공, 실제 토큰·수신자, 현재 잔액·한도를 확인해요. 다른 사용이나 송금이 있었다면 88·8을 그대로 적용할 수 없어요. 실패했다면 실제 온체인 상태로 기록하고 기대대로 12를 빼지 않아요.
일반 ERC-20 한도는 부여한 권한에 따라 동작하며 수신자나 용도가 매번 고정됐다는 뜻은 아니에요. 컨트랙트가 별도로 제한하지 않는 한 첫 수신자가 R이었다고 나머지 8도 항상 같은 곳에만 쓰인다고 가정하면 안 돼요.
4단계: 철회 성공 후 0을 확인해요
같은 T·S 조합을 0으로 바꾼다고 가정해요. 철회가 처리 중이라면 버튼을 눌렀다고 기존 8이 무효가 되지 않아요. 상대의 사용과 철회 중 무엇이 먼저 실행되는지가 결과를 바꿔요. ‘철회 전송됨’을 ‘자산 안전’이라고 적지 않아요.
철회 성공과 재조회 0 이후에야 해당 온체인 한도가 0이라고 기록해요. 다른 T 변동이 없다면 A 잔액은 88이며, 8의 권한을 없앴다고 8이 돌아오지 않아요. 이미 나간 12를 회수하지도, 다른 권한의 안전을 보증하지도 않아요.
EIP-20은 0이 아닌 기존 승인 한도를 바꾸는 거래 순서 위험과 화면에서 0으로 바꾼 후 새 값을 주는 방식도 안내해요. 실제 토큰에는 별도의 증감 방식이나 제한이 있을 수 있어요. 먼저 0으로 만드는 것이 모든 선제 사용을 막는 보증은 아니에요. 공격이 의심되면 노출 상황을 재평가하고 한도 숫자만 반복 변경하지 않아요.
한도 하나를 철회해도 남는 위험이 있어요
특정 권한을 철회해도 다른 서명·토큰·키 노출이 자동으로 사라지지 않아요. 끝난 것은 고정 네트워크에서 A의 T에 대한 S의 한도 0뿐이에요. 다른 상대·체인·자산은 따로 확인해요.
미제출 Permit은 현재 한도와 따로 판단해요
독립적인 분기로, A가 아직 제출하지 않은 EIP-2612 Permit에 서명한 적이 있다고 해 봐요. nonce와 기한 등이 맞으면 나중에 제출해 지정 한도를 설정할 수 있어요. nonce는 같은 허가의 재사용을 막는 순번, deadline은 제출 마감 조건이에요. 날짜가 아직 안 지났다고 안심할 수 있다는 뜻은 아니에요.
현재 Approve 한도 0이 모든 미제출 서명의 무효를 뜻하지는 않아요. 실제 프로토콜·허가 내용·취소 방법을 봐야 하며 일반 approve(0)은 모든 종류의 서명을 자동 취소하지 않아요. 20→8→0의 원 연습에는 Permit이 없어요. 한도 0의 결론 범위를 설명하는 별도 예이지 두 번째 사용이 실제 생겼다는 주장이 아니에요.
개인키 유출은 승인 철회로 통제권을 바꿀 수 없어요
시드 문구나 개인키를 넘겼다면 S의 한도만의 문제가 아니에요. 비밀을 가진 사람은 새 거래나 승인을 만들 수 있고 앱 비밀번호 변경으로 상대의 복사본을 회수하지 못해요. 개인키와 시드 문구의 차이로 어떤 계정이 같은 근원인지 확인해요.
‘철회 완료’ 화면만으로 사건을 끝내지 않아요. 반대로 의심 승인이 있다는 사실만으로 개인키 유출을 단정하지도 않아요. 알려진 노출과 미확인 부분을 구분해 실제 단서를 따라요. 의심 송금과 통제권 확인에서 그 분기를 이어가요.
매번 서명 전에 승인 관리를 습관으로 만들어요
동의하기 전에 상대·범위·효력 발생 방식을 설명할 수 있어야 해요. 사후 점검은 남은 한도를 찾지만 다음의 모르는 서명을 보증하지 않아요. 화면을 읽을 수 없거나 정보가 다르거나 사이트가 확인 생략을 재촉하면 멈춰요.
신뢰할 입구에서 조회하고 낯선 검증 요청은 거절해요
직접 확인한 지갑·공식 문서·검증된 한도 관리 도구에서 시작하고 낯선 메시지의 ‘안전 검사’를 누르지 않아요. 공개 한도 조회에 고객센터로 시드 문구나 개인키를 보낼 필요는 없어요. 관리 도구도 서명·거래를 요구하면 다시 읽어야 하며 안전을 내세운다고 예외가 되지는 않아요.
MetaMask 공식 ‘Spending caps’는 한도 조회·철회를 설명하지만 목록은 도구가 지원하는 범위 안에 있어요. 표시가 없다고 다른 체인, 대체 불가능 토큰(NFT)의 작업 권한, 프로토콜별 서명이 없다고 할 수는 없어요. 이번 ERC-20 연습도 그 처리 규칙을 대신하지 않아요.
네트워크 비용과 중단 조건을 같이 확인해요
Approve와 철회는 보통 온체인 수수료가 들고, 서명형 허가는 제출 비용을 다른 사람이 낼 수도 있어요. 누가 수수료를 내는지와 누구에게 토큰 사용을 허용하는지는 다른 문제예요. 실패한 트랜잭션의 수수료에서 준비액과 실제 비용을 나눠요.
일상 관리라면 비용·예산부터 확인해요. 스위퍼 봇이 의심된다면 철회를 끝내려고 기존 계정에 네이티브 자산을 바로 보충하지 않아요. 봇은 입금을 감시해 자동으로 빠르게 자산을 빼내는 프로그램이에요. 한도와 중단 조건을 함께 적어, 권한 하나를 처리하다 새 자산까지 노출하지 않도록 해요.
이 글은 구조 설명과 가정이며 실제 승인·철회는 하지 않았어요. 개인별 자산 처분 조언이 아니고 토큰·프로토콜 구현은 다를 수 있어요. 침해가 의심되면 실제 기록과 검증된 공식 지원으로 판단해요.