온체인 트레이딩에서 지연시간의 비용

지연 비용은 제품이 관찰한 체인 상태와 실제 액션이 실행되는 시점의 상태 사이의 간극으로 나타난다. 이 간극은 제품이 읽고, 결정하고, 제출하고, 확인을 기다리는 데 쓰는 매 밀리초마다 커진다.

장기 관점의 포트폴리오 뷰에서는 이 간극이 단순한 불편함일 수 있다. 하지만 마켓 메이커, 스왑 라우터, 청산 엔진, 또는 오래된 주문을 취소하려는 트레이더에게는 전략 우위의 상당 부분을 갉아먹을 수 있다. 저지연 RPC는 이런 제품들이 더 최신 상태에 기반해 행동할 수 있게 해준다는 점에서 성공적인 트레이딩 경험의 핵심이다.

쿼트는 거래가 실행되기 전에 낡을 수 있다

스왑 쿼트는 애플리케이션이 요청하는 시점의 풀 준비금, 오더북 유동성, 가스 상황, 시장 상태를 담는다. 사용자가 트랜잭션을 확인하는 동안에도 이 입력값들은 계속 변한다.

기본 경로는 단순하다:

1. 앱이 체인 및 시장 상태를 읽는다.
2. 쿼트 또는 거래 결정을 계산한다.
3. 사용자가 트랜잭션을 제출한다.
4. 네트워크가 이를 전파, 시퀀싱, 실행한다.
5. 앱이 영수증을 받고 화면을 갱신한다.

각 단계의 지연은 최종 액션을 그만큼 덜 최신 상태로 만든다. 느린 읽기는 더 오래된 시장 데이터를 사용하게 하고, 느린 제출은 시장이 움직일 시간을 더 벌어주며, 느린 확인은 사용자가 낡은 상태를 보게 만든다.

0x는 여러 유동성 소스에 걸쳐 거래 가격을 책정한다. 요청이 진행되는 동안에도 가격이 움직일 수 있기 때문에, 이 팀은 응답성 있고 정확한 데이터를 쿼트 품질과 직결시키며, 1초 이내에 쿼트를 생성한다.

Jupiter는 타이밍 간극을 잘 보여준다: direct-landing 경로는 50400밀리초, 즉 Solana 블록 01개를 목표로 하는 반면, 표준 RPC 제출은 400밀리초1.2초, 즉 블록 13개가 걸린다. 쿼트와 실행 사이의 블록 수가 적을수록 상태가 변할 기회도 줄어든다.

지연이 누적되는 네 단계

모든 거래는 이 단계들을 거친다. 어느 단계에서든 지연이 발생하면 최종 결과는 그만큼 덜 최신이거나 덜 확실해진다.

이 단계들은 서로 영향을 미친다. 오래된 시장 읽기는 쓰기 경로가 아무리 빨라도 그대로 오래된 상태다. 변동성이 큰 구간에서는 평균보다 가장 느린 요청이 더 중요하다. 실패 역시 나름의 리스크를 만든다: 재시도, 낡은 화면, 놓친 액션.

지연에 민감한 제품은 성공률과 함께 p95, p99 응답 시간을 평가해야 한다. 우리의 공개 벤치마크 방법론은 워밍업된, 메서드 단위의 EVM 읽기를 측정하고 성공 응답의 지연을 실패와 별도로 보고한다. 기반이 되는 Node API는 제품이 체인과 상호작용할 때 사용하는 읽기와 쓰기를 포괄한다. 이는 특정 프로바이더 경로를 측정하는 것이며, 트레이딩 팀은 자신의 읽기, 쓰기, 리전, 트래픽 패턴을 직접 테스트할 필요가 있다.

온체인 트레이딩에서 지연은 어떻게 경제적 비용이 되는가?

지연은 실행 결과를 바꿀 때 경제적 비용이 되며, 그 방식은 워크로드에 따라 다르다. 다음은 온체인 트레이딩 시스템에서 반복적으로 나타나는 패턴들이다.

스왑: 낡은 쿼트는 슬리피지 또는 리버트가 된다

가격 임팩트와 슬리피지는 흔히 뭉뚱그려 이야기되지만, 서로 다른 비용을 가리킨다. 우리의 DeFi 인프라 가이드는 이 비용들이 실제 운영 중인 쿼트 플로우에서 어떻게 나타나는지 보여준다. 가격 임팩트는 특정 거래 규모가 풀 가격에 일으키는 예측 가능한 변화다. 슬리피지는 쿼트된 출력값과 실행 시점에 받는 출력값 사이의 추가적인 간극이다. 이는 지연, 동시 트랜잭션, 블록 포함 순서에 따라 달라진다.

이 구분은 제품 설계에서 중요하다. 가격 임팩트는 쿼트 시점에 이미 보인다. 슬리피지는 트랜잭션이 대기 중인 동안 커진다. 최소 출력값 가드는 지나친 가격 변동을 리버트로 전환시켜 사용자를 보호한다. 수수료가 낮은 트랜잭션은 가격 환경이 변하는 동안 더 오래 대기할 수 있다; 최소 출력값, 최대 입력값, 또는 데드라인은 사용자가 받아들일 최악의 실행 조건을 설정한다.

사용자에게 드러나는 결과는 더 나쁜 가격, 놓친 거래, 또는 변화하는 시장에 대한 노출을 줄이는 더 좁은 실행 경로다. 더 빠른 읽기와 제출은 그 노출 윈도우의 일부를 줄여준다.

마켓 메이킹과 주문 관리: 늦은 취소는 독성 흐름이 될 수 있다

마켓 메이커는 가격이 움직일 때마다 쿼트를 계속 갱신한다. 시스템이 가격 변동을 늦게 인지하거나 취소를 늦게 보내면, 대기 중인 주문이 이미 손실이 난 이후에 체결될 수 있다. 즉시 주문을 내는 트레이더는 반대의 위험에 직면한다: 주문이 시장에 도달할 즈음에는 사용 가능한 유동성이 이미 사라졌을 수 있다.

청산과 차익거래: 시간 자체가 기회의 일부다

청산 엔진과 차익거래 시스템은 상태 변화를 관찰하고 기회가 닫히기 전에 행동하기 위해 경쟁한다. 여기서 관련된 경쟁은 새로운 오라클 가격, 변경된 헬스 팩터, 풀 불균형, 또는 크로스 벤뉴 가격 변동일 수 있다. 이를 놓치면 수익 손실로 이어질 수 있다. 반복된 실패 시도 역시 수수료를 소모하고 블록스페이스를 낭비할 수 있다.

체인 설계는 이 경쟁의 양상을 바꾼다. 도착 순서로 시퀀싱하는 시스템에서는 더 낮은 지연 경로가 순서에 직접적인 영향을 미칠 수 있다. 우선순위 수수료를 사용하는 시스템에서는 수수료와 타이밍 모두가 중요하다. 비공개 주문 흐름이나 번들을 사용하는 시스템에서는 가시성과 원자적 실행이 추가적인 트레이드오프를 만든다. 인프라는 이러한 시장 규칙 안에서 작동한다. 그 역할은 전략이 그 규칙에 진입하기 전에 불필요한 지연을 추가하지 않는 것이다.

지갑과 트레이딩 인터페이스: 지연은 신뢰 문제가 된다

지연은 체결 가격 이상의 영향을 미친다. 지갑이나 트레이딩 앱은 사용자가 쓸모 있는 화면을 보기 전에 여러 호출을 거쳐야 할 수 있다: 잔액, 허용량, 경로 쿼트, 가스 추정, 영수증, 트랜잭션 기록. 이런 호출들이 느리게 반환되거나 간헐적으로 실패하면 사용자는 변하는 가격, 지연된 상태, 또는 멈춘 것처럼 보이는 인터페이스를 보게 된다.

이는 변동성이 큰 시기에 특히 치명적이다. 조용한 시장에서는 단순히 불편한 정도였던 느린 잔액 갱신이, 사용자가 리스크를 관리하려는 순간에는 헤지, 취소 결정, 또는 입금 확인을 지연시킬 수 있다.

왜 테일 지연이 평균보다 더 중요한가

지연 분포에는 테일이 있다. 엔드포인트가 부하 상황에서 느려지면, 제품은 트래픽이 급증하거나, 변동성이 커지거나, 체인이 혼잡할 때 그 느린 경로를 경험하게 된다.

그래서 프로바이더 검토는 다음 네 가지 질문에 답해야 한다:

• 어떤 메서드가 크리티컬 패스에 있는가? 최신 블록 읽기, eth_call, eth_getLogs, 영수증 조회, 트랜잭션 브로드캐스트를 각각 별도로 평가하라; 각각 동작 방식이 다르다.
• 사용자와 서비스는 어느 리전에서 연결하는가? 지리적 위치는 네트워크 경로를 바꾼다.
• p95와 p99 성공 호출은 얼마나 느린가? 이 값들은 평균이 가려버리는 요청들을 드러낸다.
• 요청은 얼마나 자주 실패하거나 타임아웃되는가? 타임아웃은 재시도, 낡은 UI, 놓친 액션을 유발할 수 있는 신뢰성 이벤트다.

벤치마크는 이런 조건들을 명시적으로 드러내고, 구매자가 실제로 운영하는 제품 경로를 측정해야 한다. 우리의 벤치마크 방법론은 빌더들의 인프라 결정을 돕기 위해 메서드 단위 비교마다 요청 출처, 메서드, 페이로드, 타임아웃, 성공 규칙, 연결 상태를 고정한다.

저지연 RPC가 해결할 수 있는 것과 해결할 수 없는 것

더 빠른 RPC 레이어는 현재 상태를 더 빨리 반환하고, 서명된 트랜잭션을 더 빨리 제출하며, 트레이딩 인터페이스를 반응성 있게 유지할 수 있다. 하지만 체결 품질은 여전히 시장 움직임, 유동성, 수수료, 경로 선택, 트랜잭션 보호, 체인의 시퀀싱 정책에 달려 있다. 프로바이더의 읽기 벤치마크는 읽기 성능을 측정할 뿐이며, 엔드투엔드 스왑 성능, 트랜잭션 포함, WebSocket 동작, 전략 PnL은 별도의 테스트가 필요하다.

이런 범위 설정은 인프라에 대한 주장을 정직하게 유지하고, 팀이 자신의 워크로드에 맞는 측정 방식을 선택하도록 돕는다. 목표는 제품의 경제성이 시간에 가장 민감한 경로에서 피할 수 있는 지연을 제거하는 것이다.

우리는 이 목표를 중심으로 저지연 RPC 작업을 구축했다. Alchemy Edge Proxy는 인그레스 단계에서 고정된 요청 경로 오버헤드를 제거하며, 마이그레이션 측정에서 APAC p99를 150밀리초에서 20밀리초로 줄였다. Cortex 라우팅은 근접성만을 전체 답으로 취급하는 대신 요청마다 정상 상태인 노드를 선택한다. Cortex는 또한 부하 상황에서도 요청 경로를 반응성 있게 유지하는 용량 및 플릿 운영을 뒷받침한다. 우리의 저지연 인프라 작업은 엣지, 라우팅, 용량, 노드 운영, 측정에 걸쳐 있다. 각 레이어는 신뢰할 수 있는 저지연 서비스를 제공하기 위해 세밀하게 튜닝되어 있다.

자신의 실행 경로를 평가하는 방법

지연이 가장 큰 사용자 또는 경제적 비용을 만드는 흐름부터 시작하라.

1. 경로 계산, 서명, 제출, 포함, 상태 갱신을 포함해 상태 읽기부터 사용자에게 보이는 결과까지의 경로를 매핑하라.
2. 제품이 실제로 사용하는 메서드와 페이로드를, 서비스와 사용자가 실제로 운영되는 리전에서 테스트하라. 제품이 의존하는 RPC API와 지원 체인부터 시작하라. 평상시와 변동성 또는 트래픽이 높은 시기에 동일한 테스트를 실행하라.
3. p50, p95, p99, 성공률, 타임아웃율, 쿼트-결과 시간을 기록하라. 읽기, 제출, 포함 지연은 별도로 유지하라.
4. 이 측정값들을 결과와 연결하라: 쿼트-체결 드리프트, 리버트, 놓친 체결, 취소 성공률, 지원 문의, 사용자 이탈.

이렇게 하면 자신의 전략, 자산, 사용자에 맞는 비용 모델을 만들 수 있고, 더 빠른 경로가 실행 결과를 어디서 바꾸는지 알 수 있다.

자주 묻는 질문

RPC 지연은 트레이딩 성능에 어떤 영향을 미치는가?

지연은 트레이딩 앱이 관찰한 상태와 트랜잭션이 실행되는 상태 사이의 간극을 벌린다. 느린 읽기는 쿼트가 서명되기 전에 낡게 만들고, 느린 제출은 시장이 움직일 시간을 더 주며, 느린 확인은 사용자가 낡은 화면을 보고 행동하게 만든다. 결과는 더 나쁜 체결, 놓친 거래, 또는 리버트다.

RPC 지연이 낮으면 더 나은 체결이 보장되는가?

낮은 RPC 지연은 제출 전후의 피할 수 있는 지연을 줄여준다. 체결 품질은 시장 움직임, 유동성, 수수료, 비공개 주문 흐름, 경로 선택, 체인 시퀀싱, 트랜잭션 보호에도 달려 있다.

왜 p95가 트레이딩 앱에서 평균 RPC 지연보다 유용한가?

평균은 부하나 변동성 시기에 몰리는 느린 요청들을 가려버릴 수 있다. p95는 측정된 조건에서 성공한 응답의 95%가 적어도 이만큼은 빨랐다는 것을 보여준다. 실패와 타임아웃은 별도의 신뢰성 측정이 필요하므로, 성공률과 함께 읽어야 한다.

트레이딩 앱을 위해 RPC 프로바이더를 어떻게 벤치마크하는가?

제품이 실제로 사용하는 메서드와 페이로드를, 사용자와 서비스가 실제로 운영되는 리전에서 테스트하라. 우리의 벤치마크 방법론을 재현 가능한 출발점으로 활용하라. p50, p95, p99, 성공률, 타임아웃율을 기록하고, 읽기, 제출, 포함 지연을 별도로 유지하라. 변동성이 크고 트래픽이 많은 구간뿐 아니라 조용한 시장 조건에서도 테스트를 반복하라.

가격 임팩트와 슬리피지는 같은 것인가?

아니다. 가격 임팩트는 거래 규모가 현재 풀에 미치는 예측 가능한 효과다. 슬리피지는 쿼트된 출력값과 사용자가 실제로 받는 값 사이의 실행 시점 차이다. Raydium의 문서는 각각에 대해 명확한 기술적 정의를 제공한다.

트레이딩 팀은 읽기, 쓰기, 전체 워크플로를 각각 별도로 벤치마크해야 하는가?

그렇다. 메서드 단위 읽기 테스트는 특정 요청에 대한 프로바이더 동작을 비교할 수 있다. 쿼트 신선도, 의사결정, 제출, 포함, 확인을 함께 이해하려면 전체 트레이딩 흐름 테스트가 필요하다. 이 두 결론은 분리해서 유지해야 한다.