트랜잭션은 체인이 처리하는 기록 단위이고, 결제·교환·투표 같은 이용 행위와 일대일로 대응하지 않습니다. 한 트랜잭션으로 여러 수신자에게 지급하거나 여러 계약을 호출할 수 있으며 합의 투표와 실패 실행이 집계에 포함되기도 합니다. 비교하려는 목적에 맞게 기록·동작·성공 결과를 나누어 세어야 합니다.
블록에 들어간 한 건과 이용자가 끝낸 한 일을 구분합니다
사용자는 교환 버튼을 한 번 눌렀다고 느끼지만, 실제로는 사전 승인과 교환을 별도로 실행했을 수 있습니다. 반대로 서비스는 여러 고객의 지급 요청을 모아 하나의 기록으로 보낼 수 있습니다. 화면의 클릭 수, 전송된 요청 수, 블록의 트랜잭션 수가 항상 같을 이유는 없습니다.
네트워크 처리량을 측정하는 질문에는 트랜잭션 수가 유용하지만 서비스 이용 규모를 추정하는 질문에는 추가 분류가 필요합니다. 거래 해시가 존재한다는 사실과 원하는 자산 이동이 완료됐다는 사실도 구분합니다. 이 구분 없이 ‘하루 이용 건수’를 적으면 서로 다른 활동이 같은 숫자로 합쳐집니다.
기록을 몇 번 남겼는지와 그 안에서 무엇을 몇 번 완료했는지는 다른 질문입니다.
JOBCOIN 지표 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 블록에 들어간 한 건과 이용자가 끝낸 한 일을 구분합니다
사용자는 교환 버튼을 한 번 눌렀다고 느끼지만, 실제로는 사전 승인과 교환을 별도로 실행했을 수 있습니다.
- 비트코인의 다중 출력이 지급 건수를 바꿉니다
비트코인 개발자 문서는 트랜잭션이 입력과 출력으로 구성된다는 점을 설명합니다.
- 계약 호출과 이벤트를 더하면 중복이 생길 수 있습니다
이더리움의 최상위 트랜잭션은 계약 코드를 실행할 수 있고 그 실행 중 다른 계약과 상호작용할 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
비트코인의 다중 출력이 지급 건수를 바꿉니다
비트코인 개발자 문서는 트랜잭션이 입력과 출력으로 구성된다는 점을 설명합니다. 출력은 이후에 사용될 수 있는 자산 단위를 만들며 하나의 트랜잭션에 여러 출력이 들어갈 수 있습니다. 이 구조를 이용하면 여러 지급을 묶어 처리할 수 있습니다.
가상의 서비스가 고객 20명에게 각각 출금해야 한다고 가정합니다. 고객별로 한 건씩 보낼 때에는 20개의 트랜잭션이 필요하지만 여러 출력을 가진 한 건에 모으면 기록은 한 개가 될 수 있습니다. 고객 지급은 20건으로 같아도 트랜잭션 통계는 크게 달라집니다.
출력 수를 그대로 고객 수로 읽는 것도 해법은 아닙니다. 서비스가 자신에게 돌려보내는 잔돈 출력이 섞일 수 있고 한 고객에게 여러 출력이 생길 수도 있습니다. 비트코인 잔돈 주소를 구분하는 분석이 필요한 이유이며, 공개 장부만으로 모든 출력의 사업상 목적을 확정할 수는 없습니다.
계약 호출과 이벤트를 더하면 중복이 생길 수 있습니다
이더리움의 최상위 트랜잭션은 계약 코드를 실행할 수 있고 그 실행 중 다른 계약과 상호작용할 수 있습니다. 탐색기가 내부 트랜잭션이라고 표시하는 실행 흔적이나 토큰 전송 이벤트는 별도의 서명된 최상위 트랜잭션과 같은 항목이 아닙니다.
가상 교환 요청 한 건이 라우터, 두 개의 풀, 수수료 처리 계약을 거친다고 해 봅니다. 최상위 거래 한 건, 여러 내부 호출, 여러 전송 이벤트가 함께 관측될 수 있습니다. 이 세 수치를 합산해 이용 다섯 건이라고 부르면 같은 과정을 여러 번 셀 위험이 있습니다.
교환을 세려면 어떤 완료 이벤트 또는 자산 변화가 교환 한 건을 뜻하는지 정의합니다. 여러 경로로 나뉜 주문이나 복합 호출을 어떻게 묶을지도 정합니다. 활성 주소의 주체 조정과 마찬가지로, 집계 규칙을 바꾸면 같은 장부에서도 결과가 달라질 수 있습니다.
| 관측 단위 | 가상 사례 | 유용한 질문 | 주의점 |
|---|---|---|---|
| 최상위 트랜잭션 | 묶음 출금 1건 | 블록이 처리한 기록 수 | 지급 20건을 한 건으로 표시 가능 |
| 출력·전송 이벤트 | 지급 및 잔돈 또는 계약 간 전송 | 자산 이동 경로 | 고객이나 독립 이용 수와 같지 않음 |
| 내부 호출 | 라우터에서 풀로 이어지는 실행 | 계약 실행 과정 | 최상위 거래와 합산하면 중복 가능 |
| 완료된 서비스 동작 | 조건을 충족한 교환 결과 | 실제 기능 사용 | 앱별 판정 규칙이 필요 |
합의 투표를 포함한 TPS와 제외한 TPS는 다른 값입니다
솔라나의 공식 getRecentPerformanceSamples 응답에는 전체 트랜잭션 수와 비투표 트랜잭션 수, 표본 기간이 별도 필드로 제시됩니다. 비투표 값은 null일 수도 있으므로 자료가 없다는 상태를 0건으로 바꾸어서는 안 됩니다. 전체와 비투표 수의 구분은 네트워크 합의 활동과 다른 실행을 나누어 읽는 출발점입니다.
계산 예시로 60초 동안 전체 6,000건, 비투표 1,200건이 관측됐다고 가정하면 전체 기준은 초당 100건, 비투표 기준은 초당 20건입니다. 이는 실제 솔라나 성능 측정값이 아닌 가상 산식입니다. 어느 수치를 사용했는지 밝히지 않고 다른 체인의 수치와 비교하면 정의 차이를 성능 차이로 오해하게 됩니다.
비투표 거래라고 해서 모두 사람이 실행한 성공적인 결제라는 뜻은 아닙니다. 자동화·실패 실행·여러 계약 동작이 포함되는지는 별도 확인해야 합니다. 최대 순간 처리량과 하루 평균 처리량도 측정 시간이 다르므로 같은 비교표에 넣을 때 구분 열이 필요합니다.
실패와 재시도는 실제 완료보다 기록을 늘릴 수 있습니다
사용자가 원하는 교환을 끝내기 위해 여러 번 요청하면 완료된 동작은 하나여도 블록에 포함된 실패 시도와 성공 시도가 따로 남을 수 있습니다. 반면 전파되지 않았거나 블록에 들어가지 못한 요청은 블록 트랜잭션 수에 나타나지 않을 수 있습니다. 지갑의 오류 횟수와 체인 기록의 실패 횟수가 다른 이유입니다.
집계 표에는 포함된 전체 거래와 성공 상태의 거래를 따로 두고 실패 원인이나 재시도 처리 방식을 설명합니다. 특히 활동 급증이 있으면 신규 이용 증가인지 반복 실패인지 확인해야 합니다. 처리량 숫자가 커졌어도 사용자가 결과를 얻기까지 더 오래 걸렸을 수 있기 때문입니다.
가스 사용량과 수수료를 함께 읽으면 기록 수 외에 자원을 얼마나 소비했는지도 볼 수 있습니다. 그러나 자원 소비가 많다는 사실 역시 성공적인 경제 활동의 증거는 아닙니다. 결과, 비용, 처리 시간을 서로 다른 축으로 놓아야 불필요한 실행 증가를 성장으로 포장하지 않게 됩니다.
- 전체 거래·성공 거래·실패 거래의 포함 범위를 적습니다.
- 투표와 시스템 활동의 별도 필드가 있는지 확인합니다.
- 출력·이벤트·내부 호출을 거래 수와 합산하지 않습니다.
- 배칭 및 복합 실행의 묶음 규칙을 기록합니다.
- 측정 기간과 평균·최대치의 차이를 표시합니다.
비교 목적에 맞는 결론만 남깁니다
체인 자체의 처리 부하를 비교한다면 같은 기간의 자원 사용과 처리 지연을 함께 보아야 합니다. 결제 서비스의 이용을 비교한다면 성공한 지급과 수취 결과를 세는 쪽이 질문에 가깝습니다. 개발 활동을 알고 싶다면 계약 배포나 실제 호출을 별도로 조사해야 합니다.
따라서 트랜잭션 수 하나로 네트워크의 인기, 고객 수, 매출, 기술 우위를 동시에 설명하지 않습니다. 보고서에 숫자 옆의 단위를 길게 적는 수고가 잘못된 결론을 줄입니다. ‘어떤 체인의 어떤 거래를 얼마 동안 어떤 조건으로 센 값인가’라는 설명이 있어야 다른 독자도 같은 자료를 검토할 수 있습니다.
자주 묻는 질문
트랜잭션 수가 줄면 이용이 감소한 건가요?
배칭이 늘어 같은 지급을 더 적은 기록으로 처리했을 수 있습니다. 성공한 서비스 동작, 출력 구조, 활동 주소 등 다른 자료를 함께 확인해야 합니다.
토큰 전송 이벤트를 전부 더하면 이용 건수가 되나요?
한 이용 과정에서 여러 전송이 발생하거나 계약 사이에서 자산이 이동할 수 있습니다. 이벤트는 이동 기록이며 독립적인 이용이나 고객을 뜻하지 않습니다.
비투표 TPS는 곧 실제 결제 TPS인가요?
투표를 제외했다는 뜻일 뿐입니다. 결제 외의 계약 실행, 자동화, 성공 여부를 추가로 분류해야 결제 완료량에 가까운 값을 만들 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
