TRC20 USDT 있는데 전송 안 될 때 TRX와 에너지 확인 순서

지갑에는 USDT가 분명히 있는데 보내기나 스왑을 누르면 실패하고, 거래 기록에는 OUT_OF_ENERGY가 남는 경우가 있습니다. 이때는 USDT 잔액만 다시 볼 것이 아니라 내가 사용하는 곳이 개인 지갑인지부터 구분한 뒤 TRX 잔액, Energy와 Bandwidth, 이전 실패 TXID를 순서대로 확인해야 같은 실패를 반복하지 않을 수 있습니다.

USDT 잔액이 있는데 왜 전송 버튼을 눌러도 움직이지 않을까

가장 먼저 구분할 것은 USDT를 어디에서 보내려는지입니다. 개인 지갑에서 TRC20 USDT를 다른 주소로 보내거나 지갑 안의 스왑 기능에서 TRON 스마트컨트랙트를 호출하는 상황이라면 사용자의 주소가 직접 온체인 거래를 실행합니다. 이때 USDT 잔액이 충분한 것만으로는 조건이 끝나지 않습니다.

TRC20 USDT는 TRON 위에서 동작하는 스마트컨트랙트 토큰이기 때문에 전송 과정에서 Bandwidth와 Energy라는 네트워크 자원이 필요합니다. TRON 공식 Bandwidth and Energy 문서는 트랜잭션 데이터 크기에 Bandwidth가 쓰이고 스마트컨트랙트의 TVM 명령 실행에는 Energy가 쓰인다고 설명합니다.

Energy에는 무료 기본 할당량이 없기 때문에 스테이킹이나 위임으로 확보한 Energy가 없으면 부족분을 TRX 소각으로 처리하게 됩니다. 공식 문서 확인일은 2026-09-30입니다.

이 구조 때문에 지갑에 USDT 100개가 보이더라도 TRX와 사용 가능한 Energy가 부족하면 보내기나 스왑이 막힐 수 있습니다. 초보자는 USDT가 달러 스테이블코인이므로 전송 수수료도 USDT에서 조금 차감되겠다고 생각하기 쉽지만, 일반적인 TRC20 전송의 네트워크 자원 결제 구조는 그렇게 단순하지 않습니다. 사용 가능한 Energy가 먼저 쓰이고 부족한 부분은 당시 체인 파라미터에 따라 TRX를 소모해 처리합니다.

따라서 USDT 잔액과 TRX 잔액은 화면에서 따로 확인해야 합니다. 특히 D’CENT 공식 도움말은 TRC20 토큰을 보낼 때 FAILED – OUT OF ENERGY가 나타나는 대표 원인으로 필요한 Energy를 충당할 TRX 가용 잔액 부족을 설명하고 있습니다. D’CENT는 안정적인 전송을 위해 100 TRX 이상의 가용 잔액을 유지하라고 권장하지만, 동시에 실제 필요한 TRX 수량은 Energy 단가에 따라 달라질 수 있다고 명시합니다.

이 100 TRX는 TRON 프로토콜이 정한 USDT 1회 전송 고정 수수료가 아니라 해당 지갑사의 운영상 권장치로 읽어야 합니다. 공식 도움말은 2026-09-30 확인했습니다.

여기서 거래소 출금과 개인 지갑 전송을 섞으면 판단이 틀어집니다. 예를 들어 Binance나 OKX 같은 중앙화 거래소에서 USDT를 외부 주소로 출금하는 경우 사용자가 자신의 개인 지갑에서 직접 스마트컨트랙트를 실행하는 방식과 다릅니다. 거래소가 자체 지갑에서 온체인 거래를 만들고 사용자는 거래소가 출금 화면에 표시한 네트워크 수수료와 최소 출금 조건을 따릅니다.

Binance 공식 도움말은 암호화폐 출금 수수료가 네트워크 상황에 따라 동적으로 조정되며 최소 출금액과 수수료는 네트워크별로 달라질 수 있으므로 현재 출금 화면에서 확인하라고 안내합니다. 그러므로 거래소 계정에 USDT가 있다고 해서 개인 지갑처럼 내 계정에 TRX를 별도로 넣어야 출금된다고 단정해서는 안 됩니다.

Bandwidth와 Energy는 무엇이 다르고 USDT 전송에는 왜 둘 다 필요한가

TRON에서 Bandwidth는 트랜잭션 자체의 데이터 크기를 처리하는 자원이고 Energy는 스마트컨트랙트 코드를 실행하는 자원입니다.

일반적인 TRX 전송도 트랜잭션 데이터를 네트워크에 기록해야 하므로 Bandwidth를 사용하지만 TRC20 USDT의 transfer 호출은 여기에 스마트컨트랙트 실행이 추가되므로 Energy도 필요합니다. 2026-09-30 TRON 공식 Network Parameters에는 계정의 무료 Bandwidth 한도 getFreeNetLimit가 600으로 표시돼 있습니다.

공식 설명에서는 활성화된 계정이 하루 600 Bandwidth를 기본으로 받을 수 있다고 안내합니다. 반대로 Energy에는 이런 무료 기본 할당량이 없습니다. Energy를 스테이킹이나 다른 계정의 위임으로 보유하지 않았다면 스마트컨트랙트 호출 때 부족분을 TRX로 지불하는 구조가 됩니다.

현재 TRON 공식 체인 파라미터에서 Bandwidth가 부족할 때 적용되는 단가는 byte당 1,000 sun입니다. 1 TRX가 1,000,000 sun이므로 1 byte당 0.001 TRX에 해당합니다. 예를 들어 270 byte의 트랜잭션이 발생했고 사용할 Bandwidth가 전혀 남아 있지 않다는 가정을 세우면 270 × 1,000 sun = 270,000 sun, 즉 0.27 TRX라는 계산이 가능합니다. 이것은 계산 원리를 보여주는 가정 예시일 뿐 모든 TRC20 USDT 전송의 Bandwidth 비용이 0.27 TRX라는 의미는 아닙니다. 트랜잭션 크기와 사용 가능한 무료 또는 스테이킹 Bandwidth가 다르면 실제 부담도 달라집니다.

Energy의 현재 소각 단가는 TRON 공식 Network Parameters와 Paying for resources 문서에서 1 Energy당 100 sun으로 확인됩니다. 100 sun은 0.0001 TRX이므로 스테이킹이나 위임 Energy가 전혀 없고 특정 호출에서 사용자가 부담해야 할 부족 Energy가 50,000이라고 가정한다면 단순 Energy 부분은 50,000 × 100 sun = 5,000,000 sun, 즉 5 TRX로 계산됩니다.

부족 Energy가 100,000이라면 같은 가정에서 10 TRX입니다. 그러나 이 계산은 현재 getEnergyFee 값과 가정한 Energy 사용량을 곱한 산술 예시일 뿐 실제 USDT 전송 수수료를 미리 고정하는 공식이 아닙니다. TRON은 getEnergyFee와 Bandwidth 단가 같은 체인 파라미터를 거버넌스 제안으로 변경할 수 있기 때문에 게시글에는 반드시 확인 날짜를 함께 남기는 편이 좋습니다.

관련 공식 문서는 2026-09-30 확인했습니다.

스테이킹으로 얻는 Energy 역시 고정량이 아닙니다. TRON 공식 문서의 개념식은 내가 Energy 용도로 스테이킹한 TRX가 네트워크 전체 Energy 스테이킹에서 차지하는 비율에 네트워크 전체 Energy 한도를 곱하는 방식입니다. 즉 Energy obtained = 내 Energy용 스테이킹 TRX ÷ 네트워크 전체 Energy용 스테이킹 TRX × 네트워크 전체 Energy 한도입니다. 그래서 TRX 몇 개를 스테이킹하면 언제나 Energy가 몇 개 생긴다고 오래된 숫자를 고정해 쓰는 것도 정확하지 않습니다. 네트워크 전체 스테이킹 상태가 바뀌면 같은 TRX를 스테이킹해도 확보량이 달라질 수 있기 때문입니다.

fee_limit이 높게 보이는데도 OUT_OF_ENERGY가 나는 이유

fee_limit은 이름 때문에 실제 결제 수수료로 오해하기 쉽지만 TRON 공식 문서는 스마트컨트랙트 호출에서 사용자가 감당할 수 있는 Energy 예산의 상한이라고 설명합니다. 단위는 TRX가 아니라 sun이며 1 TRX는 1,000,000 sun입니다. 공식적인 기본 관계식은 maxCallerEnergyFromFeeLimit = fee_limit ÷ EnergyPrice입니다.

예를 들어 현재 Energy 단가 100 sun을 그대로 가정하고 fee_limit이 100 TRX, 즉 100,000,000 sun으로 설정됐다면 fee_limit이 허용하는 이론적 Energy 상한은 100,000,000 ÷ 100 = 1,000,000 Energy입니다. 그렇다고 실제 거래에서 100 TRX가 자동으로 빠진다는 뜻도 아니고, 1,000,000 Energy를 반드시 쓸 수 있다는 뜻도 아닙니다.

중요한 제한은 실제 호출자가 제공할 수 있는 자원입니다. TRON FeeLimit 공식 문서는 호출자 Energy 한도를 callerEnergyLimit = min(callerStakedEnergy + (balance – callValue) ÷ sunPerEnergy, fee_limit ÷ sunPerEnergy) 형태로 설명합니다.

쉽게 말하면 첫 번째 값은 내가 가진 스테이킹 Energy와 실제 TRX 잔액으로 감당할 수 있는 범위이고, 두 번째 값은 fee_limit이 허용한 범위입니다. 네트워크는 둘 중 작은 값을 호출자가 부담할 수 있는 최대 Energy 범위로 봅니다. 따라서 fee_limit을 크게 잡았다고 해도 실제 TRX 잔액과 확보 Energy가 부족하면 실행 도중 한도에 닿을 수 있습니다.

반대로 TRX와 Energy가 충분해도 fee_limit이 너무 낮으면 fee_limit이 먼저 상한이 되어 OUT_OF_ENERGY가 발생할 수 있습니다. 공식 문서는 2026-09-30 확인했습니다.

2026-09-30 현재 TRON 메인넷의 getMaxFeeLimit 체인 파라미터는 15,000 TRX, 즉 15,000,000,000 sun입니다. 이 숫자는 한 거래에 설정할 수 있는 fee_limit 최대값입니다. 이것을 보고 USDT를 한 번 보내는 데 최대 15,000 TRX가 필요하다고 해석하면 틀립니다.

프로토콜이 허용하는 스마트컨트랙트 호출 예산 상한일 뿐이고 실제 비용은 실행에 소비된 Energy, 사용자가 미리 확보한 Energy, TRX 소각분, Bandwidth 등 실제 조건으로 결정됩니다. TRON 공식 문서도 getMaxFeeLimit와 getEnergyFee 같은 값은 체인 파라미터이므로 코드나 안내글에 영구 고정값으로 박아두지 말고 현재 값을 조회하라고 안내합니다.

또 하나 알아둘 점은 TRON의 Dynamic Energy Model입니다. 인기 스마트컨트랙트에는 기본 Energy 소비량 외에 동적 Energy 요소가 적용될 수 있기 때문에 과거 동일한 컨트랙트 호출에서 사용된 수치를 그대로 미래 거래에 적용하는 것은 안전하지 않습니다. 계약 상태, 호출 조건, 유지보수 주기에서 갱신되는 energy_factor 같은 요소가 달라질 수 있기 때문입니다.

그래서 전날 같은 USDT를 보낼 때 사용한 TRX가 얼마였다는 개인 경험만으로 오늘 필요한 금액을 정하지 않는 편이 좋습니다. 지갑이 예상 Energy나 예상 수수료를 보여준다면 전송 직전에 다시 확인하고, 예상치 역시 성공을 보장하는 고정값이 아니라는 점을 함께 이해해야 합니다.

OUT_OF_ENERGY가 이미 떴다면 USDT보다 먼저 실패 TXID를 확인해야 한다

거래가 실패했다고 표시되면 가장 먼저 같은 전송 버튼을 다시 누르기보다 기존 거래의 TXID를 확인하는 것이 좋습니다. TXID는 해당 온체인 거래를 식별하는 고유값이므로 TRONSCAN 같은 블록 탐색기에서 실행 결과와 자원 사용 내용을 확인하는 기준이 됩니다. 여기서 먼저 Result나 Contract Result가 실제로 OUT_OF_ENERGY인지 봅니다.

지갑 화면에서 단순히 실패라고만 표시되는 경우라도 원인은 Energy가 아니라 다른 컨트랙트 오류, 주소 상태, 계약 조건 등일 수 있기 때문입니다. 이번 글의 범위는 특히 OUT_OF_ENERGY로 확인되는 경우이며, 이미 송금이 성공한 뒤 상대 거래소 잔고에 입금되지 않는 문제와는 별개의 검색 의도입니다.

OUT_OF_ENERGY는 스마트컨트랙트 실행이 완료되기 전에 호출자가 사용할 수 있는 Energy 한도에 도달했다는 뜻으로 이해하면 쉽습니다. TRON Paying for resources 공식 문서는 fee_limit으로 허용된 예산을 초과하면 트랜잭션이 OUT_OF_ENERGY로 되돌려지고, 실행 과정에서 이미 소비된 Energy는 그 한도까지 청구될 수 있다고 설명합니다. 따라서 USDT 전송 자체가 완료되지 않았다고 해서 네트워크 비용까지 전혀 들지 않았다고 생각하면 안 됩니다. 실패 거래에서 USDT가 원래 지갑에 그대로 남아 있는지 확인하는 것과 TRX 또는 Energy가 얼마나 소모됐는지 확인하는 것은 서로 다른 점검 항목입니다.

이 구조가 실제 손실로 이어지는 대표적인 패턴은 원인을 확인하지 않고 재시도를 반복하는 것입니다. 예를 들어 지갑에 USDT는 충분하지만 가용 Energy가 부족하고 TRX도 실행 완료에 필요한 만큼 감당하지 못하는 상태라고 가정해보겠습니다. 첫 번째 호출이 실행되면서 일부 Energy 비용이 발생한 뒤 한도에 도달해 실패할 수 있습니다. 사용자가 실패 원인을 보지 않고 동일한 조건으로 두 번째, 세 번째 거래를 다시 만들면 그때마다 또 실행이 시작되고 다시 자원이 소모될 가능성이 있습니다. 전송하려던 USDT는 그대로인데 수수료 역할을 하는 TRX만 줄어드는 상황이 생길 수 있는 이유입니다.

따라서 실패 TXID에서는 최소한 거래 결과, 사용된 Energy, 표시되는 Energy Fee 또는 네트워크 비용, Fee Limit, 보낸 주소를 확인하고 현재 지갑의 TRX와 Energy 상태를 다시 봐야 합니다. 여기서 과거 거래가 사용한 Energy가 곧 다음 거래의 필요량이라고 단정해서는 안 됩니다. 스마트컨트랙트 상태와 네트워크 파라미터가 달라질 수 있기 때문입니다. 핵심은 TXID를 통해 이전 시도가 어디에서 실패했는지를 확인한 다음 조건을 바꾸지 않은 채 재시도하는 행동을 피하는 것입니다.

내 지갑의 Energy와 Bandwidth는 어디에서 무엇을 확인해야 할까

TRON은 계정의 자원 정보를 조회할 수 있도록 GetAccountResource API를 제공합니다.

공식 API 문서의 wallet/getaccountresource 응답에는 freeNetUsed, freeNetLimit, NetUsed, NetLimit, EnergyUsed, EnergyLimit 등이 포함됩니다. freeNetLimit은 계정이 사용할 수 있는 무료 Bandwidth 한도, freeNetUsed는 그중 사용한 양을 의미합니다.

NetLimit과 NetUsed는 스테이킹 등으로 확보한 Bandwidth 한도와 사용량을 보는 데 쓰이고, EnergyLimit과 EnergyUsed는 계정이 확보한 Energy와 사용량을 확인하는 기본 필드입니다. 개발자가 아니더라도 이 필드의 의미를 알면 지갑이나 탐색기가 보여주는 Resource 화면을 이해하기 쉬워집니다. 공식 API 문서는 2026-09-30 확인했습니다.

개념적으로 스테이킹으로 확보한 Energy의 남은 양은 EnergyLimit에서 EnergyUsed를 뺀 값을 참고할 수 있고, 스테이킹 Bandwidth도 NetLimit과 NetUsed의 차이를 참고할 수 있습니다. 무료 Bandwidth는 freeNetLimit과 freeNetUsed를 별도로 봐야 합니다. 다만 각 지갑 앱이 API 원본 필드를 그대로 보여주는 것은 아닙니다.

어떤 앱은 Available Energy처럼 사용자가 이해하기 쉬운 값으로 가공하고, 어떤 앱은 Resources 메뉴에서 Bandwidth와 Energy를 합쳐 보여줄 수 있습니다. 따라서 앱 화면에 표시된 이름이 공식 API 필드와 다르다고 해서 반드시 데이터가 잘못된 것은 아닙니다.

실전에서는 복잡한 API 호출보다 확인 순서가 중요합니다. 첫째, 지갑에서 USDT가 TRON 네트워크의 TRC20 토큰인지 확인합니다. 둘째, 같은 TRON 주소에 TRX 잔액이 있는지 확인합니다. 셋째, 지갑의 Resource 또는 Energy 메뉴가 있다면 가용 Energy와 Bandwidth를 확인합니다. 넷째, 과거 실패 거래가 있다면 TXID에서 OUT_OF_ENERGY인지 확인합니다. 다섯째, 전송 화면으로 돌아왔을 때 지갑이 예상 수수료나 필요한 자원을 새로 계산해 보여주는지 확인합니다. 사용자가 직접 fee_limit을 입력할 수 있는 고급 지갑이라면 fee_limit이 지나치게 낮게 설정되지 않았는지도 함께 봐야 합니다.

초보자가 특히 피해야 할 방법은 인터넷 검색에서 찾은 오래된 글의 TRX 숫자를 그대로 입금하는 것입니다. D’CENT의 100 TRX 권장처럼 출처와 의미가 분명한 수치도 프로토콜의 고정 필요량이 아니라 지갑사가 실패 가능성을 낮추기 위해 제시한 가용잔액 권장치입니다. 반대로 커뮤니티 댓글에서 누군가 5 TRX, 10 TRX, 20 TRX면 된다고 말한 수치는 그 사람의 특정 시점과 특정 조건에서의 경험일 수 있습니다. 현재 Energy 단가, 계정의 자원 보유 상태, fee_limit, 호출 조건이 모두 같다는 보장이 없으므로 그대로 따라가는 방식은 정확한 확인법이 아닙니다.

재시도 전에 개인 지갑과 거래소 출금을 나눠 확인하는 순서

개인 지갑에서 TRC20 USDT를 보내는 경우에는 다음 순서로 확인하면 문제를 좁히기 쉽습니다. 먼저 USDT가 실제 TRON 네트워크 토큰인지 확인하고, 같은 주소의 TRX 잔액을 별도로 봅니다. 다음으로 지갑이나 TRONSCAN에서 Energy와 Bandwidth를 확인합니다. 이미 실패한 거래가 있다면 새 거래를 만들기 전에 TXID를 열어 OUT_OF_ENERGY인지, 실제로 얼마의 Energy가 소비됐는지, fee_limit이 어떻게 설정됐는지를 확인합니다. 그다음 지갑이 새 전송 시점에 보여주는 예상 네트워크 비용이나 자원 요구량을 다시 봅니다. 이 순서를 거치면 단순히 USDT가 있으니 다시 누르면 된다는 식의 재시도를 피할 수 있습니다.

거래소 출금은 개인 지갑의 직접 전송과 구분해야 합니다. 거래소가 안내하는 최소 출금액과 네트워크별 수수료를 출금 화면에서 확인하고, 받는 쪽이 지원하는 네트워크와 일치하는지도 다시 보세요. 거래소 화면의 수수료를 내 개인 지갑의 Energy 계산식과 같은 값으로 취급하면 판단이 어긋날 수 있습니다.

저장해 다시 볼 체크리스트는 간단합니다. 개인 지갑인가 거래소인가, TRC20 네트워크가 맞는가, USDT와 별도로 TRX 잔액이 있는가, 사용할 수 있는 Energy가 있는가, Bandwidth는 남아 있는가, 이전 실패 TXID의 Result가 OUT_OF_ENERGY인가, fee_limit이 너무 낮지는 않은가, 실패 거래에서 이미 네트워크 비용이 빠졌는가, 새 거래 전 지갑이 다시 계산한 예상값을 확인했는가를 순서대로 봅니다. 어느 하나를 확인하지 않은 상태에서 인터넷의 특정 TRX 수량만 믿고 반복 전송하는 것은 피하는 편이 좋습니다.

마지막으로 이 문제를 이미 송금한 뒤 거래소에 입금되지 않는 문제와 섞지 않아야 합니다. OUT_OF_ENERGY는 개인 지갑에서 스마트컨트랙트 실행 자체가 완료되지 못한 단계의 문제입니다. 반대로 TXID가 성공 상태이고 자산이 목적지 주소로 온체인 전송됐는데 거래소 잔고에 반영되지 않는다면 지원 네트워크, 최소 입금액, 컨트랙트 지원 여부, 메모나 태그, 거래소 입금 처리 상태 등을 확인해야 하는 별도 문제입니다. 검색 의도도 다르고 해결 절차도 다르기 때문에 이번 글은 전송 전 또는 전송 실행 중 막히는 상황에만 집중하는 편이 독자에게 더 정확한 답이 됩니다.

자주 묻는 질문