비트코인 컨펌 수와 이중지불 위험을 구분하는 방법
비트코인을 전송한 뒤 지갑이나 거래소에서 미확인, 0 컨펌, 1 컨펌 같은 표시를 보면 거래가 실패한 것인지, 얼마나 기다려야 하는지 혼란스러울 수 있습니다. 핵심은 거래가 네트워크에 전파된 상태, 유효한 블록에 포함된 상태, 그 블록 위에 새 블록이 쌓인 상태를 서로 다른 단계로 이해하는 것입니다.
이 글은 Bitcoin 개발자 문서의 결제 검증, 블록체인, 거래 구조 설명을 바탕으로 컨펌 수와 이중지불 위험을 실무적으로 해석하는 방법을 정리합니다. 특정 코인이나 거래소 이용을 권하는 글이 아니며 가격 전망이나 매수·매도 판단을 제공하지 않습니다. 가상자산은 가격 변동과 원금 손실 위험이 있으므로 송금 전 주소·네트워크·수수료·수취 서비스 정책을 직접 확인해야 합니다.
핵심 요약: 컨펌은 거래가 묻힌 깊이를 나타낸다
컨펌은 단순한 시간 표시가 아닙니다. 거래가 포함된 블록이 현재 유효한 체인 안에서 얼마나 깊게 자리 잡았는지를 나타내는 지표입니다. 일반적인 화면에서 0 컨펌은 거래가 전파되었지만 아직 블록에 포함되지 않았다는 뜻이고, 1 컨펌은 거래가 최신 블록에 포함되었다는 뜻입니다. 그 뒤 블록이 하나 더 연결되면 2 컨펌으로 표시됩니다.
컨펌 수가 늘수록 과거 기록을 바꾸려면 더 많은 블록의 작업을 다시 수행해야 하므로 이중지불에 대한 방어가 강해집니다. 다만 컨펌이 많다는 사실이 잘못 입력한 주소를 되돌려 주거나 개인키 탈취와 거래소 출금 제한까지 해결해 주는 것은 아닙니다.
| 화면 상태 | 기술적 의미 | 사용자가 확인할 것 |
|---|---|---|
| 전송 준비·서명 전 | 거래가 아직 네트워크에 제출되지 않음 | 주소, 네트워크, 금액, 수수료 |
| 전파됨·0 컨펌 | 노드가 거래를 보았지만 블록에는 미포함 | TXID, 수수료 수준, 충돌 여부 |
| 1 컨펌 | 거래가 최신 유효 블록에 포함됨 | 수취 서비스의 필요 컨펌 수 |
| 여러 컨펌 | 포함 블록 위에 후속 블록이 누적됨 | 고액·상품 인도 등 상황별 승인 기준 |
거래 전파와 결제 확정은 왜 다른가
지갑이 거래를 만들고 서명한 뒤 피어에게 보내면 거래 정보는 비트코인 P2P 네트워크로 퍼집니다. 이때 TXID가 생성되고 블록 탐색기에서 검색될 수 있어도 아직 블록에 포함되지 않았다면 0 컨펌입니다. TXID가 조회된다는 사실만으로 결제가 확정된 것은 아닙니다.
Bitcoin 개발자 문서의 결제 검증 설명에 따르면 거래를 방송했다고 해서 수취가 보장되는 것은 아닙니다. 같은 미사용 거래 출력, 즉 UTXO를 입력으로 사용하는 충돌 거래가 존재할 수 있으며 최종적으로 유효 체인에는 그중 하나만 포함될 수 있기 때문입니다. 따라서 상품을 즉시 넘기거나 되돌릴 수 없는 서비스를 제공한다면 0 컨펌 승인에 별도의 위험 분석이 필요합니다.
전파가 늦다는 이유만으로 곧바로 이중지불 공격이라고 판단해서도 안 됩니다. 낮은 수수료, 네트워크 혼잡, 지갑의 재전파 상태, 수취 서비스의 노드 동기화 지연 등도 화면 반영을 늦출 수 있습니다. 먼저 송금 지갑의 상태와 TXID, 입력·출력, 블록 포함 여부를 순서대로 확인하는 것이 안전합니다.
이중지불은 같은 UTXO를 두 번 쓰려는 충돌이다
비트코인 거래는 계좌 잔액에서 숫자를 차감하는 방식이 아니라 이전 거래가 만든 미사용 출력인 UTXO를 입력으로 소비합니다. 하나의 UTXO는 유효한 블록체인에서 한 번만 소비될 수 있습니다. 같은 UTXO를 서로 다른 두 거래가 입력으로 사용한다면 두 거래는 충돌하며 둘 다 최종 유효 기록이 될 수 없습니다.
예를 들어 A가 가진 하나의 UTXO를 사용해 상점 B에게 보내는 거래와 다시 A가 관리하는 주소로 보내는 거래를 각각 만든 상황을 생각할 수 있습니다. B가 0 컨펌 알림만 보고 물건을 넘겼는데 다른 거래가 먼저 블록에 포함되면 B의 거래는 최종 결제가 되지 않을 수 있습니다. 이것이 수취인이 컨펌을 기다리는 기본 이유입니다.
모든 지연 거래가 악의적인 충돌 거래는 아닙니다. 지갑이 수수료 조정 기능으로 거래를 대체하는 경우처럼 사용자가 의도적으로 더 높은 수수료의 후속 거래를 만드는 정상적 흐름도 있습니다. 따라서 단일 탐색기의 경고 문구만 보지 말고 지갑 안내, 입력 충돌 표시, 최종 블록 포함 결과를 함께 봐야 합니다.
컨펌 수는 어떻게 계산하는가
거래가 포함된 블록을 기준으로 그 블록 자체를 첫 번째 확인으로 세고 이후 유효 체인에 블록이 추가될 때마다 컨펌 수가 하나씩 증가합니다. 개념적으로 현재 체인 끝의 높이가 900,005이고 거래가 높이 900,003 블록에 포함되었다면 계산은 900,005 - 900,003 + 1 = 3이므로 3 컨펌입니다.
이 계산은 탐색기 화면의 단순 경과 시간이 아니라 현재 유효 체인의 블록 높이와 포함 블록 높이의 차이를 사용합니다. 비트코인 블록은 평균적인 생성 간격을 갖지만 실제 간격은 들쭉날쭉합니다. 그러므로 10분이 지났는데도 1 컨펌이 되지 않았거나 짧은 시간에 여러 블록이 생성되는 현상은 가능합니다.
| 예시 항목 | 값 | 해석 |
|---|---|---|
| 거래 포함 블록 높이 | 900,003 | 거래가 처음 기록된 블록 |
| 현재 유효 체인 끝 높이 | 900,005 | 현재 노드가 인정하는 최신 블록 |
| 계산식 | 900,005 – 900,003 + 1 | 포함 블록 자체를 1로 포함 |
| 결과 | 3 컨펌 | 포함 블록 위에 후속 블록 2개가 연결됨 |
0·1·2·6 컨펌을 기계적으로 적용하면 안 되는 이유
공식 결제 처리 문서는 0 컨펌은 일반적으로 위험 분석 없이 신뢰하지 말아야 하고, 1 컨펌부터 이중지불 위험이 크게 낮아지며, 더 많은 블록이 쌓일수록 보호가 강해진다고 설명합니다. 흔히 언급되는 6 컨펌은 고액 또는 사기 위험이 있는 결제를 다루는 소프트웨어가 사용할 수 있는 보수적 기준의 예시이지 모든 거래에 적용되는 절대 숫자는 아닙니다.
필요 컨펌 수는 수취인의 위험과 운영 정책에 따라 달라집니다. 소액의 되돌릴 수 있는 디지털 서비스와 고액 실물 상품 인도는 손실 규모가 다릅니다. 거래소 입금은 거래소가 자산별로 정한 컨펌 수를 충족해야 내부 잔액에 반영되는 경우가 많으므로 블록체인에서 확인되었더라도 거래소 화면에는 대기 상태로 남을 수 있습니다.
사용자는 임의로 “한 시간이면 안전하다”라고 판단하기보다 수취 지갑이나 거래소가 명시한 필요 컨펌 수를 확인해야 합니다. 서비스 정책은 보안 상황, 네트워크 상태, 입출금 점검에 따라 달라질 수 있습니다.
실전 확인 순서: TXID부터 서비스 정책까지
첫째, 송금 지갑에서 거래 상태와 TXID를 복사합니다. TXID가 없거나 전송 대기 상태라면 아직 서명·방송 단계가 끝나지 않았을 수 있습니다. 둘째, 신뢰할 수 있는 서로 다른 조회 수단에서 해당 TXID의 입력, 출력 주소, 금액, 블록 포함 여부를 확인합니다. 주소 전체를 대조하되 개인정보 노출에도 주의합니다.
셋째, 0 컨펌이라면 수수료율과 미확인 상태, 충돌 또는 대체 가능성 표시를 확인합니다. 수수료를 올리려고 같은 금액을 다시 무작정 전송하면 별도 거래가 생겨 혼란이 커질 수 있으므로 사용 중인 지갑의 공식 수수료 조정 절차를 따라야 합니다. 넷째, 컨펌이 생겼다면 현재 수와 수취 서비스가 요구하는 수를 비교합니다.
다섯째, 요구 수를 충족했는데도 입금이 반영되지 않으면 TXID, 송금 네트워크, 입금 주소, 메모나 태그 필요 여부, 발생 시각을 정리해 서비스 고객지원에 문의합니다. 비밀번호, 시드 문구, 개인키는 어떤 지원 담당자에게도 제공하면 안 됩니다.
실제 시나리오로 보는 판단 기준
시나리오 1: 개인 지갑끼리 소액 테스트 송금
처음 사용하는 주소라면 먼저 소액으로 보내 주소와 네트워크가 맞는지 확인합니다. 수취 지갑에 0 컨펌으로 보인다면 TXID와 출력 주소를 대조하고 1 컨펌 이상이 생기는지 기다립니다. 테스트가 정상 완료된 후 본 송금을 별도로 진행하면 주소 오입력과 서비스 호환 문제를 줄일 수 있습니다.
시나리오 2: 거래소 입금이 블록체인에는 보이지만 잔액에 없음
탐색기에서 2 컨펌이 확인되더라도 거래소가 3 컨펌 이상을 요구한다면 내부 잔액 반영 전 대기 상태일 수 있습니다. 필요 컨펌을 충족한 이후에도 오래 반영되지 않을 때만 점검 공지와 고객지원 절차를 확인합니다. 네트워크 선택이 잘못되었다면 컨펌 수가 늘어도 자동 복구된다는 보장은 없습니다.
시나리오 3: 고액 상품을 비트코인으로 결제받음
판매자는 상품 가치, 환불 가능성, 구매자 신원 확인 수준, 이중지불 위험을 반영해 사전에 승인 컨펌 수를 정해야 합니다. 0 컨펌 알림만으로 되돌릴 수 없는 상품을 인도하지 말고 내부 화면 한 곳이 아니라 자체 노드 또는 신뢰 가능한 검증 수단을 활용하는 편이 안전합니다.
블록 재구성과 컨펌 표시가 되돌아갈 수 있는 경우
거래가 포함된 최신 블록이 항상 영구적으로 체인에 남는 것은 아닙니다. 거의 동시에 발견된 블록 가운데 하나가 이후 더 많은 누적 작업을 가진 체인의 일부가 되면 다른 블록은 유효 체인에서 빠질 수 있습니다. 이때 해당 블록의 거래가 새 체인에 아직 포함되지 않았다면 컨펌 수가 줄거나 다시 미확인으로 표시될 수 있습니다.
이 현상 때문에 1 컨펌은 0 컨펌보다 훨씬 강한 신호이지만 모든 상황에서 절대적인 최종성을 뜻하지는 않습니다. 후속 블록이 쌓일수록 해당 기록을 바꾸는 비용과 난도가 커집니다. 고액 결제에서 더 많은 컨펌을 기다리는 이유도 여기에 있습니다.
컨펌이 해결하지 못하는 위험
컨펌은 블록체인 기록 변경과 이중지불 위험을 낮추는 지표이지 모든 송금 위험을 없애는 인증서가 아닙니다. 피싱 사이트에 시드 문구를 입력했거나 악성코드가 주소를 바꿨다면 많은 컨펌은 잘못된 송금을 더 깊게 확정할 뿐입니다. 주소와 네트워크를 잘못 선택한 경우에도 마찬가지입니다.
거래소나 수탁 서비스의 지급불능, 출금 중단, 계정 탈취는 온체인 컨펌과 별개의 위험입니다. 가격 변동으로 인한 원금 손실 가능성도 컨펌 수와 무관합니다. 따라서 송금 보안, 보관 보안, 서비스 신용 위험, 시장 위험을 각각 나누어 관리해야 합니다.
| 위험 종류 | 컨펌 증가로 완화되는가 | 별도 대응 |
|---|---|---|
| 동일 UTXO의 이중지불 | 대체로 완화됨 | 상황별 필요 컨펌 기준 설정 |
| 최신 블록 재구성 | 후속 블록 누적으로 완화됨 | 고액 거래는 더 보수적으로 대기 |
| 주소·네트워크 오입력 | 완화되지 않음 | 소액 테스트, 주소 전체 대조 |
| 개인키·시드 탈취 | 완화되지 않음 | 오프라인 보관, 피싱 방지, 권한 점검 |
| 거래소 운영·지급 위험 | 완화되지 않음 | 서비스 공지·정책·출금 가능 여부 확인 |
| 가격 하락과 원금 손실 | 완화되지 않음 | 감당 가능한 범위, 투자 판단 분리 |
자주 묻는 질문
10분이 지나면 반드시 1 컨펌이 되나요?
아닙니다. 평균 블록 간격은 개별 거래의 확정 시간을 보장하는 타이머가 아닙니다. 블록 생성 간격은 변동하고 거래 수수료와 블록 공간 경쟁에 따라 포함 시점도 달라질 수 있습니다.
TXID가 보이면 상대방이 돈을 받은 것인가요?
TXID가 조회되면 거래가 생성·전파되었다는 단서는 되지만, 0 컨펌이라면 아직 유효 블록에 포함되지 않은 상태일 수 있습니다. 수취 서비스가 요구하는 컨펌 수까지 확인해야 합니다.
6 컨펌이면 모든 위험이 사라지나요?
아닙니다. 이중지불과 블록 기록 변경 위험은 크게 낮아지지만 주소 오입력, 피싱, 개인키 유출, 수탁기관 문제, 가격 변동과 원금 손실 위험은 그대로 남습니다.
컨펌이 오래 걸리면 같은 금액을 다시 보내도 되나요?
무작정 재송금하면 별도 결제가 될 수 있습니다. 사용 중인 지갑이 제공하는 공식 수수료 조정 또는 취소 가능 여부를 먼저 확인하고 수취인과 TXID를 공유해 중복 처리되지 않도록 해야 합니다.
최종 체크리스트와 결론
- TXID가 조회되는 것과 블록에 포함되는 것을 구분했습니다.
- 거래의 입력과 출력 주소, 금액, 선택한 네트워크를 확인했습니다.
- 현재 컨펌 수와 수취 서비스의 필요 컨펌 수를 비교했습니다.
- 0 컨펌 거래는 손실 규모와 되돌릴 수 있는지 별도로 평가했습니다.
- 시드 문구와 개인키를 누구에게도 제공하지 않았습니다.
- 컨펌이 주소 오입력, 서비스 신용, 가격 하락과 원금 손실까지 해결하지 않는다는 점을 확인했습니다.
결론적으로 컨펌 수는 “몇 분을 기다렸는가”보다 “거래가 유효 체인 안에 포함되고 그 위에 얼마나 많은 블록이 쌓였는가”를 보여 주는 지표입니다. 0 컨펌은 전파와 확정을 구분해야 하는 단계이고 이후 컨펌이 누적될수록 이중지불 방어가 강해집니다. 실제 승인 기준은 금액, 상품 인도 가능성, 수취 서비스 정책을 함께 반영해 정해야 합니다.
공식 참고 자료:
- Bitcoin Developer Guide, Payment Processing: https://developer.bitcoin.org/devguide/payment_processing.html
- Bitcoin Developer Guide, Block Chain: https://developer.bitcoin.org/devguide/block_chain.html
- Bitcoin Developer Guide, Transactions: https://developer.bitcoin.org/devguide/transactions.html
- Bitcoin Developer Guide, Operating Modes: https://developer.bitcoin.org/devguide/operating_modes.html