블록체인 트랜잭션은 어떻게 처리될까? 거래가 기록되는 과정

richissue 2026년 8월 17일 최종 수정 8월 31일 읽는 시간 약 14분

블록체인 트랜잭션은 어떻게 처리될까요? 거래 생성부터 네트워크 전파, 검증, 블록 포함과 최종 기록까지 블록체인 거래가 처리되는 과정을 쉽게 알아봅니다.

암호화폐를 다른 지갑으로 보내면 화면에서는 전송 버튼 한 번으로 끝나는 것처럼 보입니다.

하지만 블록체인 안에서는 거래를 만들고 서명한 뒤 네트워크에 전달하고, 노드가 규칙을 검증하고, 블록에 포함하는 과정이 이어집니다.

이때 만들어지는 것이 트랜잭션(Transaction)입니다.

트랜잭션을 단순히

“A 지갑에서 B 지갑으로 코인이 이동한 기록”

이라고만 이해하면 부족합니다.

Bitcoin에서는 이전에 받은 자산을 새로운 출력으로 만드는 방식이 사용되고, Ethereum에서는 ETH 전송뿐 아니라 스마트 계약을 실행하는 작업도 트랜잭션으로 시작할 수 있기 때문입니다.

블록체인 트랜잭션이란 무엇일까?

트랜잭션은 블록체인의 현재 상태를 바꾸기 위해 네트워크에 보내는 서명된 작업 요청이라고 이해하면 쉽습니다.

Bitcoin에서는 BTC를 다른 주소로 보내는 거래가 대표적입니다.

Ethereum에서는 ETH 전송뿐 아니라 토큰 이동, NFT 발행, DEX에서의 토큰 교환처럼 스마트 계약의 상태를 변경하는 작업도 트랜잭션으로 처리할 수 있습니다.

따라서

트랜잭션 = 코인 송금

이라고 한정하기보다

블록체인의 상태를 변경하기 위한 요청

이라고 보는 편이 정확합니다.

Bitcoin과 Ethereum은 거래 구조부터 다르다

둘 다 트랜잭션과 디지털 서명을 사용하지만 내부 구조는 다릅니다.

구분	Bitcoin	Ethereum
기본 구조	UTXO 방식	계정 기반
자산 이동	기존 출력을 소비하고 새로운 출력 생성	계정의 잔액·상태 변경
주요 정보	입력, 출력, 금액, 스크립트, 서명 등	nonce, to, value, data, gas 정보, 서명 등
프로그램 실행	제한적인 Script	EVM 스마트 계약 실행
대표 용도	BTC 이전	ETH 이전 + 스마트 계약 실행

이 차이를 알아두면 탐색기에서 Bitcoin과 Ethereum 거래 화면이 서로 다르게 보이는 이유도 이해하기 쉬워집니다.

Bitcoin은 코인을 그대로 옮기는 구조가 아니다

Bitcoin에서는 이전 거래에서 아직 사용하지 않은 UTXO(Unspent Transaction Output)를 입력으로 사용하고 새로운 출력을 만듭니다.

예를 들어 내가 1 BTC짜리 UTXO 하나를 가지고 있는데 상대에게 0.3 BTC를 보내고 싶다고 해보겠습니다.

단순화하면 거래는 다음처럼 구성될 수 있습니다.

기존 1 BTC UTXO를 입력으로 사용
상대방에게 0.3 BTC 출력 생성
남은 금액 가운데 일부를 내 주소로 돌려주는 잔돈 출력 생성
입력과 출력의 차이 일부는 수수료로 사용

그래서 Bitcoin 탐색기에서는 하나의 거래에 여러 입력과 여러 출력이 나타나는 경우가 많습니다.

즉 BTC라는 동전 하나가 주소 A에서 B로 그대로 이동하는 것이 아니라 기존에 사용할 수 있던 출력을 소비하고 새로운 출력을 만드는 구조입니다.

Ethereum 트랜잭션은 무엇이 다를까?

Ethereum은 계정 기반 구조를 사용합니다.

일반적인 트랜잭션에는 받을 주소와 보낼 ETH의 양뿐 아니라 nonce와 수수료 관련 정보, 서명 등이 포함됩니다.

스마트 계약을 실행한다면 data 필드에 계약에 전달할 정보도 들어갈 수 있습니다.

그래서 사용자에게는 비슷한 지갑 확인 화면으로 보이더라도

ETH를 다른 주소로 보내는 거래

와

DEX에서 토큰을 교환하는 거래

의 내부 내용은 상당히 다를 수 있습니다.

후자의 경우 트랜잭션이 스마트 계약의 함수를 호출하고, 계약 코드가 실행되면서 Ethereum의 상태가 변경됩니다.

개인키는 네트워크로 보내지 않는다

트랜잭션을 만들 때 지갑은 개인키로 디지털 서명을 생성합니다.

여기서 중요한 점은 개인키 자체가 블록체인이나 상대방에게 전달되는 것이 아니라는 것입니다.

네트워크에 전달되는 것은 트랜잭션 데이터와 서명 결과입니다.

노드는 이 서명을 검증해 해당 자산을 사용할 권한이 있는 키로 승인된 거래인지 확인할 수 있습니다.

따라서 정상적인 암호화폐 전송에서 개인키를 상대방이나 블록 탐색기, 네트워크 노드에 입력할 이유는 없습니다.

서명된 거래는 어떻게 네트워크에 퍼질까?

지갑에서 만들어진 거래는 연결된 노드를 통해 블록체인 네트워크에 전달됩니다.

거래를 받은 노드는 자신이 사용하는 규칙과 정책에 따라 거래를 확인하고, 전달할 수 있는 거래라면 다른 피어에게 다시 전파할 수 있습니다.

Bitcoin에서는 아직 블록에 포함되지 않은 유효한 거래가 노드의 멤풀(Mempool)에 보관될 수 있습니다.

여기서도 하나의 중앙 멤풀이 존재하는 것은 아닙니다.

각 노드가 자신이 알고 있고 보관하기로 한 미확정 거래를 관리하므로 노드마다 멤풀의 내용이 조금씩 다를 수 있습니다.

그리고

네트워크에 거래가 퍼졌다 = 블록체인에 기록됐다

는 뜻도 아닙니다.

블록에 포함되기 전까지는 아직 미확정 상태입니다.

노드는 무엇을 검증할까?

노드는 사용자가 보낸 거래를 그대로 저장하지 않습니다.

먼저 해당 네트워크의 규칙에 맞는지 확인합니다.

Bitcoin이라면 예를 들어

거래 형식이 유효한지
사용하는 UTXO가 실제 존재하는지
이미 사용한 출력을 다시 쓰려고 하지 않는지
필요한 서명과 사용 조건을 만족하는지

등을 확인합니다.

Ethereum에서는

서명이 유효한지
nonce가 올바른지
필요한 잔액과 비용을 감당할 수 있는지
EVM 규칙에 따라 실행 가능한지

등이 중요합니다.

즉 블록체인은 데이터를 무조건 기록하는 저장소가 아니라 네트워크 규칙을 만족한 상태 변경만 받아들이는 시스템입니다.

유효한 거래도 바로 블록에 들어가는 것은 아니다

거래가 유효하더라도 블록 공간과 네트워크 상황에 따라 대기할 수 있습니다.

Bitcoin에서는 채굴자가 미확정 거래 가운데 일부를 선택해 후보 블록에 넣습니다.

Ethereum에서는 블록 제안자가 거래를 포함하고, 다른 참여자들이 합의 규칙에 따라 블록과 상태 변경을 검증합니다.

여기서 중요한 것은 채굴자나 검증자가 개인 판단으로 거래 규칙을 정하는 것이 아니라는 점입니다.

유효하지 않은 거래가 포함된 블록이라면 다른 노드도 자신이 실행하는 프로토콜 규칙을 기준으로 이를 검증합니다.

스마트 계약이 혼자 트랜잭션을 시작할까?

Ethereum에서는 이 부분이 자주 오해됩니다.

일반적인 최상위 트랜잭션은 EOA(Externally Owned Account), 즉 개인키로 관리되는 계정이 서명해 시작합니다.

예를 들어 DEX에서 Swap 버튼을 누르면 사용자의 지갑이 스마트 계약을 호출하는 트랜잭션에 서명합니다.

그 트랜잭션이 실행되는 동안 스마트 계약이 다른 계약을 다시 호출할 수 있습니다.

따라서 흐름은 보통

사용자 트랜잭션 → 스마트 계약 실행 → 필요하면 다른 계약 호출

형태입니다.

스마트 계약이 인터넷을 감시하다가 스스로 개인키를 이용해 새로운 최상위 트랜잭션을 만드는 구조라고 생각하면 안 됩니다.

블록에 포함됐는데 실패한 거래도 있다

Ethereum에서는 블록에 기록된 거래와 성공한 거래를 구분해야 합니다.

스마트 계약을 호출한 트랜잭션이 블록에 포함됐더라도 실행 과정에서 조건을 충족하지 못하거나 오류가 발생하면 상태 변경이 실패할 수 있습니다.

블록 탐색기에서는 이런 거래도 Failed 상태로 확인할 수 있습니다.

즉

Failed = 블록체인에 기록되지 않았다

가 아니라

거래는 기록됐지만 요청했던 상태 변경이 성공하지 않았다

는 의미입니다.

그리고 실행 과정에서 이미 사용된 계산 자원에 대한 가스비가 발생할 수도 있습니다.

트랜잭션 해시는 무엇을 보여줄까?

트랜잭션이 만들어지면 이를 식별하는 트랜잭션 해시(Transaction Hash)가 생성됩니다.

Bitcoin에서는 흔히 TXID라고 부릅니다.

TXID나 트랜잭션 해시를 블록 탐색기에 검색하면

거래가 조회되는지
블록에 포함됐는지
어느 블록에 들어갔는지
입력과 출력 또는 송금 정보가 무엇인지
수수료가 얼마인지
현재 처리 상태가 어떤지

등을 확인할 수 있습니다.

다만 TXID는 중앙기관이 발급한 거래 승인번호가 아닙니다.

특정 블록체인 트랜잭션을 식별하는 값입니다.

또 TXID가 생성됐다고 받는 거래소의 계정 잔액까지 즉시 반영됐다는 뜻도 아닙니다.

온체인 거래 처리와 거래소 내부 입금 처리는 서로 다른 단계일 수 있습니다.

모든 블록체인이 같은 방식으로 거래를 확정할까?

아닙니다.

Bitcoin에서는 거래가 블록에 포함된 뒤 새로운 블록이 쌓이면서 컨펌 횟수가 늘어납니다.

Ethereum PoS에서는 합의 과정을 통해 블록이 정당화되고 최종화되는 구조를 사용합니다.

따라서 Bitcoin의

“몇 컨펌인가?”

라는 기준을 모든 블록체인에 그대로 적용하면 안 됩니다.

트랜잭션 생성과 검증의 기본 개념은 비슷할 수 있지만 합의와 최종성 방식은 네트워크마다 다릅니다.

처리 과정을 한 번에 정리하면

단계	실제로 일어나는 일
거래 생성	지갑이 트랜잭션 데이터 구성
서명	개인키로 거래 승인 서명 생성
전파	연결된 노드를 통해 네트워크로 전달
검증	노드가 서명과 자산 사용 조건 등을 확인
대기	블록에 포함되기 전 미확정 상태
블록 포함	채굴자 또는 블록 제안자가 거래 포함
블록 검증	다른 참여자도 블록과 거래를 규칙에 따라 검증
확정	네트워크 합의 구조에 따라 확정성 증가

복잡해 보여도 핵심은 간단합니다.

거래를 만든다 → 서명한다 → 네트워크가 검증한다 → 블록에 기록한다 → 합의를 통해 확정성이 높아진다

는 흐름입니다.

자주 헷갈리는 부분

흔한 생각	실제로는
전송 버튼을 누르면 바로 블록체인에 기록된다	거래 생성·전파·검증·블록 포함 과정이 필요
개인키가 네트워크로 전달된다	개인키는 서명 생성에만 사용됨
Bitcoin은 코인 하나가 주소 사이를 이동한다	기존 UTXO를 소비하고 새로운 출력을 생성
멤풀은 전체 네트워크에 하나다	각 노드가 자신의 미확정 거래를 관리
채굴자가 마음대로 거래를 승인한다	프로토콜 규칙을 만족해야 함
스마트 계약이 스스로 최상위 거래를 만든다	일반적으로 EOA의 트랜잭션이 실행을 시작
실패한 Ethereum 거래는 기록되지 않는다	블록에 포함된 실패 거래도 존재
TXID가 있으면 거래소 입금도 끝났다	온체인 처리와 거래소 내부 반영은 별개
모든 체인이 Bitcoin식 컨펌을 사용한다	합의와 최종성 방식은 체인마다 다름