“대기 중(Pending)”, “전송됨(sent)”, “컨펌됨(confirmed)”, “체결됨(filled)”이라는 단어들이 동일한 화면에 자주 함께 표시되기 때문에 하나의 사다리 위에 놓인 연속적인 단계로 착각하기 쉽습니다. 그러나 이들은 대개 서로 완전히 다른 두 대상을 설명합니다. 주문은 거래소 플랫폼에서 고유한 라이프사이클을 갖습니다. 주문은 수락되거나 거부되며, 호가창에 미체결로 머물거나, 분할 체결되거나, 취소될 수 있습니다. 블록체인 트랜잭션은 전혀 다른 자체 라이프사이클을 갖습니다. 사용자가 서명하고, 네트워크에 제출되며, 처리되고, 컨펌되며, 최종 완결(finalized)되거나, 오류로 실행 실패하거나 네트워크에 전혀 포함되지 못합니다. 이 둘을 혼동하는 기록은 실제 일어나지 않은 거래를 기록하거나 실제로 일어난 거래를 누락할 수 있습니다.
두 개의 상태 머신, 두 종류의 객관적 증거
**주문 상태(order state)**는 트레이딩 질문에 답합니다. 거래소가 나의 지침을 다른 상대방 주문과 매칭했는가, 얼마의 수량과 어떤 가격에 체결되었는가? **트랜잭션 상태(transaction state)**는 분산 원장 질문에 답합니다. 블록체인 네트워크가 나의 서명된 트랜잭션을 블록에 포함시켰는가, 오류 없이 실행되었는가, 그리고 그 기록은 현재 얼마나 확정적으로 완결되었는가?
때로는 한쪽이 다른 쪽에 의존합니다. 온체인 탈중앙화 스왑은 해당 블록체인 트랜잭션이 성공적으로 실행되어야만 비로소 체결될 수 있습니다. 반면 어떤 경우에는 서로 거의 무관합니다. 예치 입금 트랜잭션은 거래소로 담보를 이동시킬 뿐이며 그 이후에 거래소 내부에서 제출되는 주문들은 완전히 독립된 고유 식별자와 상태를 갖습니다. 어느 쪽이든 한쪽 상태 머신의 상태가 다른 쪽 상태 머신의 결정적 증거가 될 수는 없습니다. 블록체인에서 완결된 입금 트랜잭션이 거래소 주문의 체결을 증명하지 않으며, 거래소에서 체결 완료로 표시된 주문이 외부 지갑으로의 출금 완결을 증명하지는 않습니다.
거래소에서의 주문 라이프사이클
거래소마다 상태 명칭을 다르게 사용하므로 특정 거래소 문서를 반드시 확인해야 합니다. Hyperliquid의 거래 엔드포인트 문서는 훌륭한 예시입니다. 주문을 제출하면 상태 목록 내에 주문별 개별 결과가 반환됩니다. 공식 예제는 주문 ID(oid)를 포함하는 대기(resting) 결과, 총 체결 수량과 평균 체결 가격 및 oid를 포함하는 체결(filled) 결과, 그리고 오류 메시지를 포함하는 에러 결과를 보여줍니다. 한 예제 에러 응답은 최상위 레벨 상태가 “ok”로 표시되기도 하므로 API 요청 자체가 정상 수락되었다는 사실과 주문이 성공적으로 체결되었다는 것은 완전히 별개입니다. 반드시 개별 주문 항목을 읽어야 합니다.
동일한 문서는 주문에 선택적 클라이언트 주문 ID(cloid)를 부여할 수 있도록 허용하며, 이는 제출 전에 사용자가 직접 선택하는 128비트 16진수 문자열입니다. Hyperliquid의 주문 상태 쿼리는 oid 또는 cloid를 모두 지원하며 상태 및 상태 타임스탬프와 함께 주문을 반환합니다. 표시되는 상태 값에는 open, filled, canceled, triggered, rejected가 포함되며 구체적인 사유도 함께 제공됩니다. 증거금 부족으로 인한 취소, 자전거래 방지(STP)에 의한 취소, 강제 청산으로 인한 취소, 잘못된 틱 가격 또는 시장가 주문의 유동성 부족으로 인한 거부 등이 그것입니다. 시스템에서 찾을 수 없는 주문은 알 수 없는 주문(unknown-order) 응답을 반환합니다.
부분 체결은 각별한 주의가 필요합니다. 상태 라벨이 전체 주문을 설명하는 동안 실제 체결 수량은 전혀 다른 진실을 말할 수 있습니다. 요청 수량 중 일부만 체결되고 나머지는 여전히 호가창에 머물거나 나중에 취소되었을 수 있습니다. 단 하나의 상태 단어에서 임의로 추론하지 말고 거래소의 실제 체결 내역으로부터 실행 수량, 체결 가격 및 수수료를 대조하십시오. 주문 유형 가이드는 지정가, 시장가 또는 트리거 주문이 왜 서로 다른 결과로 이어지는지 설명합니다.
블록체인 상에서의 트랜잭션 라이프사이클
Solana를 예로 들면 지갑이 트랜잭션을 구성하고 사용자가 이에 서명한 후 네트워크로 브로드캐스트 전송합니다. 수수료는 SOL로 지불됩니다. 트랜잭션이 블록에 포함되면 RPC 노드는 점진적으로 강화되는 확정(commitment) 레벨을 보고할 수 있습니다. 즉 processed, confirmed, finalized 순이며 finalized가 가장 강력한 최종 완결 상태입니다. 트랜잭션은 여전히 수수료가 청구되는 실행 에러로 끝날 수도 있고 네트워크에 전혀 포함되지 못한 채 만료될 수도 있습니다. Solana 트랜잭션 작동 원리는 서명, 수수료 및 컨펌 단계를 다루며, 대기, 컨펌 및 완결 상태 가이드는 Bitcoin, Ethereum, Solana가 서로 다른 개념에 어떻게 유사한 단어를 사용하는지 비교합니다.
이곳에서의 고유 식별자는 Solana의 트랜잭션 서명(signature)이거나 다른 체인의 트랜잭션 해시(TXID)입니다. 이는 원장 기록을 식별하는 식별자일 뿐 그 자체로 대금 지급이나 거래 완료를 증명하지는 않습니다. 트랜잭션 해시가 식별하는 내용에 관한 해설이 그 차이점을 다룹니다. 이를 조회하려면 올바른 클러스터에서 Solana 서명을 확인하고 상태와 오류 메시지를 확인하십시오.
“전송됨”이나 “대기 중”이 체결을 의미하지 않는 이유
지갑 화면에 “전송됨(sent)”이라고 표시되는 것은 대개 서명된 트랜잭션이 지갑을 떠났음을 의미할 뿐입니다. 네트워크가 이를 블록에 포함시켰는지, 오류 없이 실행되었는지, 무엇을 매수했는지는 아직 전혀 알 수 없습니다. “대기 중(pending)”을 표시하는 스왑 인터페이스 역시 마찬가지입니다. 트랜잭션이 온체인에서 성공적으로 실행되기 전까지 거래는 일어난 것이 아니며 실제 수령하는 수량은 실행된 트랜잭션이 슬리피지 한도 내에서 실제로 전달한 결과물입니다. 스왑이 멈춘 것처럼 보인다면 재시도하기 전에 대기 중이거나 실패한 Jupiter 스왑 가이드를 확인하여 섣부른 재시도로 인한 이중 매매를 방지하십시오.
반대 방향의 혼란도 빈번하게 발생합니다. 거래소에서 제출된 지침은 요청 레벨에서는 정상 접수되었지만 주문 레벨에서는 즉시 거부되거나 수 시간 동안 미체결 상태로 머물 수 있습니다. “제출됨(Submitted)”은 사용자의 행동을 설명할 뿐 시장의 체결 반응을 의미하지 않습니다.
가상의 대조 검증 사례
거래소에 스테이블코인 담보를 입금한 후 매수 지정가 주문을 제출하는 가상의 트레이더를 살펴보겠습니다. 아래의 모든 식별자와 시각은 학습용 가상 데이터입니다.
| 시간 (UTC) | 사건 | 상태 머신 | 관측된 상태 | 입증하는 내용 |
|---|---|---|---|---|
| 09:00:05 | 입금 트랜잭션 서명 | 블록체인 | 서명값 반환 | 트랜잭션이 생성되어 네트워크로 전송됨 |
| 09:00:20 | 입금 상태 확인 | 블록체인 | Finalized, 에러 없음 | 이체 내역이 네트워크 블록에 최종 기록됨 |
| 09:02:10 | 거래소 계좌 잔고 | 거래소 | 담보 반영 완료 | 거래소가 자체 내부 승인 절차를 완료함 |
| 09:05:00 | 매수 지정가, cloid 0xA1… | 거래소 | Resting (대기), oid 4411 | 주문이 활성화되었으나 아직 미체결 |
| 09:40:00 | 동일 주문 상태 | 거래소 | 1.0 중 0.6 체결 | 부분 체결 발생, 아직 미완료 포지션 |
| 10:00:00 | 주문 잔량 취소 | 거래소 | 취소됨 (Canceled) | 기록된 체결가에서 최종 확정 수량은 0.6 |
오직 거래소의 실제 체결 내역만이 무엇이 매수되었는지를 보여줍니다. 오직 블록체인 원장 기록만이 입금 트랜잭션이 정상 도착했음을 보여줍니다. 그 사이에 위치한 거래소 계좌 반영 단계는 네트워크가 이체를 완결한 후 거래소가 자체 규정에 따라 처리하는 독립된 절차입니다.
트레이딩 저널에 반드시 기록해야 할 항목
각 주문에 대해 다음을 기록하십시오. 거래소, 거래 상품, 매수/매도 방향, 최초 주문 수량, 지정가 또는 트리거 가격, 설정한 경우의 cloid, 거래소 발급 oid, 주문 제출 시각, 타임스탬프가 포함된 모든 상태 변경 이력, 그리고 각 체결의 수량·가격 및 수수료. 각 트랜잭션에 대해 다음을 기록하십시오. 블록체인 네트워크 및 클러스터, 트랜잭션 서명 또는 해시, 관측된 확정 레벨과 확인 시각, 에러 내용, 지불된 수수료 및 그에 따른 지갑 잔고 변동. 익스플로러에서 트랜잭션 읽기 문서는 어떤 필드가 객관적 증거를 담고 있으며 무엇을 증명할 수 없는지 보여줍니다.
주문 제출 전에 클라이언트 주문 ID를 사전에 생성해 두는 것은 응답 패킷이 유실되더라도 자신의 저널 메모를 거래소 기록과 안정적으로 연결할 수 있기 때문에 매우 유용합니다. 트레이딩 저널 템플릿은 두 영역의 열을 나란히 배치하여 관리할 수 있습니다. 시뮬레이션 기록 역시 독립된 열로 엄격히 관리되어야 합니다. SuperQuant에 포함된 예시들은 합성 시간별 데이터와 모델링된 가상 체결을 사용하며, 실전 주문을 제출하지 않고 라이브 체결을 검증하지 않습니다. 모의 거래와 실전 거래 비교 문서는 모델링된 체결과 거래소 실제 체결이 서로 완전히 다른 증거인 이유를 설명합니다.
지속적인 학습
Solana 활용 아카데미 트랙은 서명부터 탐색기 검증까지 트랜잭션 영역을 단계별로 체계화합니다. 트레이딩 영역의 경우 지정가와 시장가 주문의 차이점과 병행하여 학습하고 모든 저널 항목에 두 식별자를 함께 보관하십시오. 본 문서는 교육 연구 목적의 콘텐츠이며 투자 조언이 아닙니다.