---
title: "지갑 nonce 공백을 복구하는 방법"
description: "EVM 계정에서 처음 누락된 nonce를 찾아 교체 또는 취소 여부를 결정하고, 지갑이나 여러 기기에서 거래가 대기열에 막히는 일을 방지합니다."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 지갑 nonce 공백을 복구하는 방법
> 교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.
## 직접 답변
EVM 호환 체인에서는 하나의 외부 소유 계정(EOA)이 보낸 거래가 nonce 순서대로 실행됩니다. 다음 실행 가능 nonce가 없거나 멈추면, 더 높은 nonce의 거래는 수수료가 높아도 대기열에 남을 수 있습니다. 복구할 때는 **가장 낮은 미해결 nonce부터 처리**해야 합니다. 체인과 발신자를 확인하고 확정 및 대기 nonce 데이터를 비교한 다음, 의도한 거래를 교체하거나 동일한 nonce를 쓰는 취소 거래와 경쟁시킵니다.
취소는 프로토콜 차원의 되돌리기가 아닙니다. 보통 해당 계정이 자신에게 보내는 0 ETH 전송으로, 같은 nonce에서 원래 거래와 경쟁합니다. 유효한 거래 중 블록에 먼저 포함된 거래가 이기며, 이미 확정된 거래는 이 방법으로 취소할 수 없습니다.
이 절차는 일반적인 EVM EOA 거래에 적용됩니다. 스마트 계정이나 계정 추상화 작업은 컨트랙트가 정의한 nonce 체계를 사용할 수 있고, UTXO 네트워크는 다른 거래 모델을 사용합니다.
## nonce 공백이 대기열을 막는 이유
EOA의 nonce는 순차적으로 증가하는 카운터입니다. 하나의 nonce에서는 거래 하나만 실행될 수 있고, 계정은 nonce 25보다 nonce 26을 먼저 실행할 수 없습니다. 따라서 노드는 즉시 실행 가능한 거래와 향후 실행을 기다리는 높은 nonce의 거래를 구분합니다.
대기열은 하나의 전역적이고 권위 있는 mempool이 아닙니다. 각 RPC 노드가 보고 보관하는 대기 거래의 일부는 서로 다릅니다. 거래가 지갑에는 표시되지만 탐색기에는 없거나, 한 RPC에서는 보이고 다른 RPC에서는 보이지 않을 수 있습니다. 이는 거래가 방송되지 않았거나, 노드의 풀에서 삭제되었거나, 조회 중인 서비스까지 전파되지 않았다는 뜻일 수 있습니다.
`latest`를 사용한 `eth_getTransactionCount`는 최신 블록 상태의 거래 수를 반환하며, EOA에서는 확정 거래 다음의 nonce로 해석할 수 있습니다. 같은 호출에서 `pending`을 사용하면 한 노드의 대기 상태를 조회합니다. 두 값의 차이는 그 노드가 대기 거래를 알고 있음을 시사하지만, 모든 공개 노드가 이를 안다는 증거는 아닙니다.
## 서명하기 전에 진단하기
1. 모든 기기와 애플리케이션에서 영향을 받은 주소의 전송을 중단합니다. 네트워크, chain ID, 발신자 주소, 거래 해시, nonce, 수신자, 금액, calldata, gas limit, 수수료 필드를 기록합니다.
2. 지갑, 탐색기, RPC가 모두 동일한 체인과 발신자를 가리키는지 확인합니다. nonce는 한 체인의 계정에 속하며 지갑 설치본에 속하지 않습니다.
3. `latest`와 `pending` 모두로 `eth_getTransactionCount`를 조회하고, 가능하면 독립된 RPC 제공자 두 곳을 사용합니다. 불일치는 온체인 상태가 모순된다는 증거가 아니라 mempool 관점이 다르다는 증거로 봅니다.
4. 발신자의 거래를 nonce별로 확인합니다. 가능하다면 노드의 거래 풀 API로 실행 가능한 `pending` 항목과 미래의 `queued` 항목을 구분할 수 있습니다. 공개 RPC 제공자는 이 비표준 API를 비활성화하는 경우가 많습니다.
5. `latest` 값부터 시작해 확정 거래가 없는 첫 nonce를 찾습니다. 그 nonce의 알려진 거래가 아직 보이는지, 삭제되었는지, 로컬에서만 만들어졌는지 판단합니다.
지갑의 상태 표시만 보고 행동하지 마십시오. 올바른 체인의 확정 nonce, 거래 영수증, 블록 포함 여부가 결정적인 증거입니다.
## 첫 미해결 nonce 교체 또는 취소하기
**원래 작업을 유지하려면:** 지갑의 속도 높이기 기능을 사용하거나, 발신자, nonce, 수신자, 금액, calldata는 같고 경쟁력 있는 수수료를 적용한 거래를 다시 방송합니다. 서명하기 전에 모든 필드를 확인하십시오. payload를 바꾸면 다른 작업이 됩니다.
**원래 작업을 포기하려면:** 아직 미확정일 때 같은 nonce와 경쟁력 있는 수수료를 사용해 해당 주소에서 자신에게 0 ETH를 보냅니다. 이는 자기 전송이 이기도록 시도할 뿐입니다. 원래 거래가 먼저 확정될 수 있으므로, 교체 거래에 영수증이 생기고 원래 거래가 미확정으로 남아 있음을 확인하기 전에는 취소 성공으로 간주하지 마십시오.
교체 거래의 수락 여부는 노드 정책이며 보편적인 인상률은 없습니다. EIP-1559 거래에서는 `maxPriorityFeePerGas`와 `maxFeePerGas`를 모두 올려야 할 수 있고, `maxFeePerGas`는 현재 base fee에서 사용할 수 있어야 합니다. 지갑 추정치와 클라이언트 규칙은 다릅니다. `replacement transaction underpriced` 오류는 수신 노드가 현재 정책에 따라 교체를 수락하지 않았다는 뜻입니다.
가장 낮은 nonce가 확정되면 영수증, `latest`, 잔액 및 모든 상위 nonce 거래를 다시 확인합니다. 대기 거래는 즉시 실행 가능해질 수 있지만, 관련 노드 모두에서 삭제된 거래는 의도적인 재방송이 필요할 수 있습니다. 이전 사본이 포함되지 않았는지 먼저 확인하지 않고 무작정 다시 보내지 마십시오.
## 예시
한 주소의 거래가 nonce 24까지 확정되어 `latest`는 25입니다. 한 RPC는 `pending`을 25로 보고하지만, 지갑은 nonce 26과 nonce 27을 대기 중으로 표시합니다. 어느 제공자도 nonce 25에서 방송된 거래를 찾지 못합니다.
소유자는 먼저 올바른 체인, 발신자, 기록된 payload를 확인합니다. nonce 25에 원래 의도한 거래가 있었다면 현재 수수료로 그 작업을 nonce 25에서 재구성해 방송합니다. 의도한 작업이 없었다면 nonce 25에서 0 ETH 자기 전송을 제출할 수 있습니다. nonce 27의 수수료만 올려서는 공백을 메울 수 없습니다.
nonce 25가 포함되면 소유자는 nonce 26 또는 nonce 27을 건드리기 전에 영수증을 확인합니다. 두 거래 중 어느 것이든 삭제되었거나 공백이 닫힌 뒤 빠르게 실행될 수 있으므로 각각 검토합니다.
## 위험 및 중단 조건
- 교체 거래는 원래 거래와 경주할 수 있습니다. 온체인 증거가 나올 때까지 원래 수신자, 금액, 컨트랙트 호출이 여전히 실행될 수 있다고 가정합니다.
- 신뢰할 수 있는 화면에서 전체 발신자 주소, chain ID, nonce, calldata를 확인합니다. 악성 코드나 신뢰할 수 없는 “복구” 사이트가 전송이나 승인을 바꿔 넣을 수 있습니다.
- 교체 수수료에 충분한 네이티브 통화를 남겨 둡니다. 컨트랙트 호출이 나중에 revert되더라도 블록에 포함된 거래에는 gas가 부과됩니다.
- nonce 공백 복구를 위해 시드 구문이나 개인 키를 공개하지 마십시오. 정상적인 RPC, 탐색기 또는 지원 담당자는 이를 요구하지 않습니다.
- 주소가 침해된 경우 반복적인 공개 교체가 공격자와의 수수료 경쟁이 될 수 있습니다. 침해된 기기 사용을 중단하고, 즉흥적으로 수수료를 올리는 대신 사고 대응 계획을 따릅니다.
- RPC 제공자의 결과가 다르거나, 원래 수신자를 모르거나, payload를 재구성할 수 없거나, 큰 컨트랙트 작업이 걸려 있다면 서명 전에 멈추고 전문가의 도움을 받습니다.
여러 기기나 자동 서명자를 반복 사용한다면 계정과 체인마다 nonce 할당자를 하나만 두고, 서명을 직렬화하며, 예약 nonce와 해시를 영구 기록하고, 확정 상태와 방송 노드의 대기 풀 모두에 대조해 재발을 방지합니다. 지갑의 로컬 활동 기록만 초기화해도 온체인 상태나 다른 노드의 mempool은 바뀌지 않습니다.
## 흔한 오해
- **“nonce 27의 수수료를 올리면 nonce 25를 건너뛸 수 있다.”** 이전 nonce가 실행 가능해진 뒤 우선순위는 높일 수 있지만 공백을 복구하지는 못합니다.
- **“찾을 수 없으면 취소된 것이다.”** 한 노드가 거래를 삭제해도 다른 노드, 빌더 또는 거래 상대방이 보유할 수 있습니다. 서명된 거래는 다시 방송될 수 있습니다.
- **“0 ETH 자기 전송은 원래 거래를 되돌린다.”** 같은 nonce에서 경쟁할 뿐이며 원래 거래가 확정된 뒤에는 효과가 없습니다.
- **“`pending`은 네트워크의 최종 답이다.”** 조회한 노드의 대기 상태일 뿐이며 제공자마다 다를 수 있습니다.
## 관련 주제
- [Nonce](/ko/crypto/nonce-crypto/)
- [거래 교체](/ko/crypto/mempool-replacement/)
- [교체 거래 수수료 부족](/ko/crypto/replacement-transaction-underpriced/)
- [우선순위 수수료](/ko/crypto/priority-fee/)
- [RPC 노드](/ko/crypto/rpc-node/)
- [암호화폐 지갑](/ko/crypto/wallet/)
## 출처
- [거래](https://ethereum.org/en/developers/docs/transactions/) - Ethereum.org (확인일: 2026-08-22)
- [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) - Ethereum.org (확인일: 2026-08-22)
- [txpool 네임스페이스](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool) - go-ethereum (확인일: 2026-08-22)
- [대기 중인 거래의 속도를 높이거나 취소하는 방법](https://support.metamask.io/manage-crypto/transactions/how-to-speed-up-or-cancel-a-pending-transaction) - MetaMask 도움말 센터 (확인일: 2026-08-22)
Source: https://wiki.fcontext.com/ko/crypto/wallet-nonce-gap-recovery/index.mdx