---
title: "FAQ - Solana Shreds"
description: "ERPC Solana Shreds에 관한 자주 묻는 질문입니다. 리전, IP 등록, 연결되지 않을 때 확인할 사항, UDP Forwarding, 플랜과 결제를 다룹니다."
canonical: "https://erpc.global/ko/faq/shreds/general/"
locale: "ko"
---

# FAQ - Solana Shreds

## Q. Shreds / getBlock 출력이 갑자기 깨져 보이거나 -32015가 반환됩니다. 무엇이 바뀌었나요?

Solana Transaction v1(SIMD-0385)이 2026년 9월 15일, 에포크 1035에 Solana 메인넷에서 활성화되었습니다. v1 트랜잭션의 와이어 레이아웃은 버전 프리픽스 바이트 `0x81`로 시작하고, 서명은 메시지 뒤에 오며, 레거시 길이 프리픽스는 없습니다.

ShredStream 또는 UDP Forwarding의 엔트리를 직접 디코딩하는 경우, 4.2 미만 버전의 `bincode` 또는 `solana-entry` 디코더는 이 `0x81` 바이트를 서명 개수로 잘못 읽으며, 이는 EOF 오류, compact-length 오버플로 또는 "invalid message version" 오류로 나타납니다. 4.2 이전 크레이트로 raw 트랜잭션을 역직렬화하는 Geyser gRPC 사용자도 같은 문제를 겪습니다. `maxSupportedTransactionVersion: 0`으로 호출한 `getBlock`과 `getTransaction` RPC는 `-32015 Transaction version (1) is not supported by the requesting client`를 반환하며, `getTransactionsForAddress`는 `full` 모드에서 영향을 받는 각 행마다 같은 오류를 보고합니다. 이미 버전 1을 지정해 ERPC의 파싱된 JSON 응답을 읽고 있다면 영향을 받지 않습니다.

옵션 객체에서 `maxSupportedTransactionVersion`을 `1`로 설정하세요. `getBlock`과 `getTransaction`의 두 번째 매개변수, 그리고 `getTransactionsForAddress`의 옵션에도 동일하게 적용합니다:

```json
{
  "maxSupportedTransactionVersion": 1
}
```

Solana Stream SDK를 `2.0.0`으로 업그레이드하세요. crates.io의 Rust `solana-stream-sdk`, 또는 npm의 `@validators-dao/solana-stream-sdk`와 `@validators-dao/solana-shreds-client`입니다. `@validators-dao/solana-entry-decoder`는 별도로 `2.5.0`으로 업그레이드하세요. `1.4.0`과 entry-decoder `2.4.0`은 v1을 지원하지 않습니다. 자체 Rust 디코더는 `solana-entry` `4.2.x`로 옮기는 것이 좋습니다.

- [마이그레이션 가이드](https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/transaction-v1.md)
- [SDK 2.0.0 릴리스 노트](https://github.com/ValidatorsDAO/solana-stream/releases/tag/v2.0.0)
- [Solana Stream SDK 저장소](https://github.com/ValidatorsDAO/solana-stream)
- [SIMD-0385: Transaction v1 제안](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)
- [Solana 업그레이드: Larger Transaction Sizes](https://solana.com/upgrades/larger-transaction-sizes)
- [Solana RPC 문서: getBlock](https://solana.com/docs/rpc/http/getblock)
- [Solana RPC 문서: getTransaction](https://solana.com/docs/rpc/http/gettransaction)
- [ERPC 문서: ShredStream 빠른 시작](https://erpc.global/ko/doc/shredstream/quickstart/)
- [ERPC 문서: Geyser gRPC 빠른 시작](https://erpc.global/ko/doc/geyser-grpc/quickstart/)
- [ERPC 문서: RPC](https://erpc.global/ko/doc/rpc/general/)

## Q. 노드는 어느 리전에 있나요?

현재 다음 리전에서 노드를 운영하고 있습니다.

- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- Dublin (DUB)
- New York (NY)
- Chicago (CHI)
- Salt Lake City (SLC)
- Tokyo (TY)
- Singapore (SGP)
- Sydney (SYD)

ERPC는 직선 거리에 의존하는 대신 실제 라우팅 경로를 기반으로 실제 네트워크 지연 시간을 측정하여 지연 시간이 가장 낮은 리전을 자동으로 선택합니다. 이 방식은 개별 사용자의 지연 시간을 개선할 뿐만 아니라 전체 네트워크 효율성을 높이고, 잠재적인 공격에 대한 ERPC의 글로벌 복원력을 강화합니다.

사용 환경에서 최적 리전이 자동으로 선택되지 않는 경우 ERPC Web Dashboard를 통해 문의해 주세요.

ERPC Web Dashboard: https://dashboard.erpc.global/ko

## Q. 지연 시간이 9999ms로 표시되고 최적이 아닌 리전이 선택됩니다. 어떻게 해야 하나요?

Shreds 리전 선택을 위해 ERPC는 아래에 나열된 프록시 호스트에서 등록된 IP로 ICMP 지연 시간 프로브를 전송합니다. 나열된 모든 소스 IP에서 들어오는 ICMP 에코 요청을 허용하십시오. 방화벽(ufw, 클라우드 방화벽, 보안 그룹 등)에서 이를 차단하면 측정값이 `9999ms`가 되고 최적이 아닌 리전이 선택될 수 있습니다. 한 리전에 여러 IP가 있는 경우 각각 별도의 프로브 호스트이며, 모두 허용해야 합니다.

[ERPC_PING_SOURCES:shreds]: #
| 리전 | ICMP 소스 IP |
| --- | --- |
| 🇳🇱 Amsterdam | `82.21.43.35` |
| 🇺🇸 New York | `151.243.244.162` |
| 🇩🇪 Frankfurt | `151.241.178.73` |
| 🇯🇵 Tokyo | `143.20.238.88` |
| 🇸🇬 Singapore | `151.245.186.3` |
| 🇬🇧 London | `151.241.65.10` |

[ERPC_FAR_POINT_GUIDANCE_START:shreds]: #
### Far Point가 선택되었습니다

Shared Shreds의 Far Point는 용량이 제한된 대체 경로입니다. 각 엔드포인트가 동시에 프록시할 수 있는 스트림은 모든 고객을 합해 최대 32개이며, 고객당 32개가 아닙니다. 구독자가 선택된 Shreds 엔드포인트 가까이에서 실행될 때 스트리밍 효율이 가장 높습니다. 장거리 스트림은 공유 연결, 흐름 제어 윈도우, egress 용량을 더 오래 사용합니다. 공유 환경의 응답성을 유지할 수 있도록 표시된 모든 리전의 ICMP 프로브 소스 IP 주소를 허용한 후 리전 선택을 다시 실행해 주세요. 지속적으로 사용하려면 선택된 엔드포인트 근처의 ERPC VPS를 고려해 주세요. UDP Forwarding은 Standard와 Premium으로 제공됩니다. 어느 쪽이든 UDP Forwarding의 리전은 ERPC Web Dashboard에서 선택하고, 원시 Shreds는 지정한 공용 IPv4 주소와 포트로 UDP를 통해 받습니다.

[이 엔드포인트 근처에서 ERPC VPS 사용하기](https://erpc.global/ko/vps/) · [UDP Forwarding 옵션 비교하기](https://erpc.global/ko/shreds/)
[Solana Shreds 빠른 시작 가이드 읽기](https://erpc.global/ko/doc/shredstream/quickstart/)

[ERPC_FAR_POINT_GUIDANCE_END:shreds]: #

## Q. IP를 허용 목록에 등록했는데도 연결되지 않습니다. 무엇을 확인해야 하나요?

대시보드에서 선택한 HTTPS 엔드포인트를 사용하세요. HTTPS는 443 포트를 사용하며, 80 포트의 HTTP는 암호화되지 않은 저지연 옵션으로 유지됩니다.

두 전송 방식은 동일한 등록 IP 허용 목록을 사용합니다. 대시보드에서 선택한 엔드포인트를 사용하고 HTTPS는 443, HTTP는 80을 지정하세요.

- HTTPS 엔드포인트: 대시보드에서 선택한 엔드포인트의 443 포트를 사용하세요.
- HTTP 엔드포인트: 대시보드에서 선택한 엔드포인트의 80 포트를 사용하세요.
- 대시보드에 표시된 URL을 `https://` 또는 `http://` 형식으로 사용하세요.

인증은 등록된 IP 주소를 기준으로 합니다. 특정 제품 페이지에서 명시하지 않는 한 `x-token`, `token` 또는 `Authorization` 헤더를 추가하지 마세요.

## Q. 지금까지 WebSocket이나 Geyser gRPC(YellowStone)만 사용해 봤습니다. 샘플이 있나요?

네. SLV를 사용하면 Shreds 연결 테스트와 애플리케이션 개발을 빠르게 시작할 수 있습니다.

자세한 내용은 다음 가이드를 참고하세요.

- [Shreds 빠른 시작 가이드](https://erpc.global/ko/doc/shredstream/quickstart/)

## Q. IP 주소를 두 개 등록할 수 있나요?

구독당 하나의 엔드포인트를 사용할 수 있습니다. IP 주소를 두 개 사용하려면 별도의 구독 두 개를 신청해야 합니다.

## Q. 어떤 리전을 추천하나요?

영구적으로 가장 좋은 단일 리전은 없습니다. Solana는 글로벌하며 리더 역할은 리더 스케줄에 따라 검증자 간에 넘어갑니다. 검증자가 많고 스테이크가 높은 리전일수록 리더 슬롯이 더 자주 발생하여 트랜잭션이 더 빨리 안착하는 데 도움이 될 수 있습니다. 다만 경쟁 트래픽도 그곳에 집중되므로, 전략에 따라서는 덜 붐비는 리전이 더 나은 결과를 줄 때도 있습니다.

실용적인 출발점으로, 안정적인 리더 슬롯 공급이 가장 중요하다면 Frankfurt나 미국 동부 해안처럼 검증자가 밀집한 리전을 선택하고, 최단 경로 실행이 우선이라면 특정 대상 검증자 가까이에 배치하세요. [Validators Solutions](https://validators.solutions/)로 공개된 Solana 네트워크 분포를 파악한 뒤, [ERPC Leader Slot API](https://erpc.global/ko/doc/rpc/leader-slot-api/)와 실제 측정값을 사용해 단일 리전, 이중 리전, 글로벌 배포 중 무엇이 적합한지 판단하세요.

[![Solana 메인넷 분포 보고서](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/)

## Q. ~400ms 이내의 지연 시간이 필요합니다.

약 400ms 이내의 지연 시간을 달성하려면 다음 핵심 사항을 고려하세요.

- **Ping 값에 대한 현실적인 이해**: ping 값은 이상적인 조건을 나타낼 뿐 스트리밍 통신의 실제 지연 시간을 반영하지 않으며, 스트리밍 통신의 지연 시간은 일반적으로 ping의 약 5배에 이릅니다. 예를 들어 대륙 간 100ms의 ping은 실제로는 약 500ms의 지연 시간으로 이어집니다. 따라서 ~400ms 지연 시간을 달성하려면 동일 리전 내에 인프라를 구축해야 합니다.
  - 일반적인 Ping 값 참고:
    - 동일 네트워크: ~0.1ms
    - 사설 네트워크 상호 연결(PNI): ~0.2ms
    - 동일 데이터 센터: ~0.3ms
    - 동일 도시: ~1ms
    - 인접 국가: ~5–10ms
    - 대륙 간: ~100–300ms

- **평균 지연 시간의 함정 피하기**: Solana 검증자는 전 세계에 분산되어 있고 리더 스케줄은 매 에포크마다 무작위로 바뀝니다. 평균 지연 시간에 의존해 ~400ms를 달성하는 것은 비현실적입니다. 대신 특정 리전의 검증자 스케줄을 정밀하게 추적하여 가장 낮은 지연 시간의 슬롯을 식별해야 합니다. 최소 지연 시간을 일관되게 달성하려면 관련된 모든 리전에 인프라가 필요합니다. 동일 리전 내에서는 데이터 취득이 수십 밀리초 내에, 전송은 단 몇 밀리초 내에 이루어질 수 있습니다.

- **리더 스케줄 추적**: **ERPC Leader Slot API**(`getLeaderSlots`)를 사용해 해당 리전의 리더 검증자 스케줄을 모니터링하세요.
  이 API는 다가오는 리더 스케줄, 현재 에포크의 스테이크 가중치, 검증자의 추정 지오로케이션, 참고 ping 값을 반환하므로, 지연 시간이 가장 낮아 노려야 할 슬롯을 해당 슬롯이 오기 전에 미리 파악할 수 있습니다.
  공개된 지도 형식의 데이터와 네이티브 RPC API는 폭넓은 네트워크 가시성에는 유용하지만 실행 타이밍에는 충분히 정밀하지 않습니다. Leader Slot API는 라우팅 및 거래 결정에 필요한 세밀함으로 그 격차를 메웁니다.
  - [ERPC Leader Slot API 문서](https://erpc.global/ko/doc/rpc/leader-slot-api/)
  - [ERPC Web Dashboard](https://dashboard.erpc.global/ko)

[![Validators Solutions - Solana 네트워크 데이터](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/)

Solana 네트워크 데이터: [Validators Solutions](https://validators.solutions/)

## Q. 제로 블록(zero-slot) 거래는 어떻게 달성할 수 있나요?

제로 블록(zero-slot) 거래를 성공적으로 달성하려면 다음과 같이 더 정교한 전략이 필요합니다.

- **기회 구역 식별**: Solana 검증자는 전 세계에 분산되어 있어 모든 슬롯에서 최적의 지연 시간을 달성하는 것은 물리적으로 불가능합니다. 따라서 인프라가 위치한 리전의 검증자 리더 스케줄을 모니터링하여 가장 유리한 기회 구역을 식별하세요. 여러 리전에 인프라를 배포하는 것도 유리할 수 있습니다. 예를 들어 Frankfurt는 검증자 밀도가 높아 리더 선택이 더 자주 일어나고 거래 기회가 더 많은 핵심 리전입니다.

  공개된 지도 형식의 데이터 소스나 네이티브 RPC API보다 훨씬 높은 정밀도로 다가오는 리더 스케줄, 현재 에포크의 스테이크 가중치, 검증자의 추정 지오로케이션 데이터, 참고 ping 값을 조회하려면 **ERPC Leader Slot API**(`getLeaderSlots`)를 사용하세요. 이를 통해 슬롯이 오기 전에 기회 구역을 파악하고 거의 제로에 가까운 지연 시간으로 거래를 실행할 수 있습니다.
  - [ERPC Leader Slot API 문서](https://erpc.global/ko/doc/rpc/leader-slot-api/)
  - [ERPC Web Dashboard](https://dashboard.erpc.global/ko)

- **전용 노드 구축**: 경쟁이 어렵다면 전용 노드 배포를 고려하세요. 공유 노드는 다른 사용자의 트래픽으로 인해 지연이 발생하므로 권장되지 않습니다. 또한 애플리케이션과 동일한 네트워크 내에 전용 노드를 배치하면 네트워크 지연 시간을 크게 줄이고 성능을 최적화할 수 있습니다.

## Q. 특정 엔드포인트를 사용할 수 있나요?

저지연 환경을 유지하기 위해 시스템이 자동으로 가장 가까운 사용 가능한 노드를 선택합니다. 특정 엔드포인트를 사용하려면 해당 엔드포인트에 가장 가까운 서버를 임대하는 것을 권장합니다.

## Q. 전용 엔드포인트는 왜 더 빠른가요?

공유 엔드포인트는 동일한 리소스를 공유하는 여러 고객이 사용합니다. 트래픽이 늘어나면 지연이 발생하는 경향이 있습니다. 서버 리소스에는 물리적 한계가 있어 처리할 수 있는 작업량이 유한합니다. 너무 많은 요청이 동시에 도착하면 순차적으로 처리해야 하므로 응답 시간이 느려집니다.

공유 엔드포인트에서도 성능을 최적화하기 위해 다양한 조치를 취하고 있지만, 전용 엔드포인트에서는 고객이 해당 리소스의 유일한 사용자입니다. 따라서 다른 사용자의 영향을 전혀 받지 않아 일관되게 안정적이고 빠른 응답이 보장됩니다.

또한 전용 엔드포인트는 TLS 없이 HTTP 등으로 통신하는 옵션을 제공합니다. TLS 핸드셰이크(약 20ms)를 생략하면 HTTPS에 비해 통신이 더욱 빨라집니다.

## Q. 구독한 뒤에 판매 가격이 인상되나요?

구독이 활성 상태인 동안에는 가입 시 고정한 판매 가격이 그대로 유지됩니다. Solana의 실시간 워크로드를 견뎌내는 환경은 전 세계적으로 희소하며, 하드웨어와 네트워크 수요 증가에 맞춰 가격을 단계적으로 인상할 계획입니다. 고사양 구성과 수요가 높은 리전일수록 가장 빠르게 소진되므로, 현재 가격을 고정해 두는 것이 장기적으로 가장 비용 효율적인 선택입니다.

## Q. 암호화폐로 결제하고 싶습니다

암호화폐 결제는 등록된 청구지 국가가 EU 회원국 중 하나인 경우 ERPC Web Dashboard에서 이용할 수 있습니다. 계정에 등록된 결제 카드가 모두 EU 외 지역에서 발급된 경우 암호화폐 결제를 이용할 수 없습니다. SOL, USDC 또는 EURC를 사용하여 ERPC Credits를 구매할 수 있습니다.

구매한 ERPC Credits로 ERPC 플랜을 시작하거나 계속 이용할 수 있습니다. 대시보드를 열고 암호화폐 결제를 선택한 뒤 지갑에서 송금하면, 대시보드가 트랜잭션을 확인하고 계정에 Credits를 반영합니다.

지원 국가: 그리스, 네덜란드, 덴마크, 독일, 라트비아, 루마니아, 룩셈부르크, 리투아니아, 몰타, 벨기에, 불가리아, 스웨덴, 스페인, 슬로바키아, 슬로베니아, 아일랜드, 에스토니아, 오스트리아, 이탈리아, 체코, 크로아티아, 키프로스, 포르투갈, 폴란드, 프랑스, 핀란드, 헝가리.

목록에 없는 국가에서는 신용카드 결제를 이용해 주세요.

[ERPC Web Dashboard](https://dashboard.erpc.global/ko)

## Q. 왜 ShredStream은 모든 트랜잭션을 포함하지 않나요?

설계상 Shreds는 Solana 블록체인의 모든 트랜잭션을 포함하지 않습니다. 모든 트랜잭션을 모니터링하려면 수많은 프록시를 전 세계에 배포하고 모든 validator로부터 Shreds를 수신해야 하는데, 이는 현실적이지 않습니다.

일반적으로 사용자는 사용 가능한 데이터의 일부만으로 운영하며, 이 방식은 대부분의 실제 애플리케이션에 충분합니다. 사용 사례에서 손실 없는 완전한 데이터 커버리지가 요구된다면 Shreds는 적합하지 않을 수 있습니다.

보다 포괄적인 모니터링이 필요한 시나리오에서는 Geyser gRPC가 Shreds보다 높은 신뢰성을 제공합니다. 다만 Solana 블록체인에서 100% 데이터 커버리지를 달성하려면 여전히 수많은 edge 서버를 배포해야 하며, 이는 실제로는 비현실적일 수 있습니다.

Geyser gRPC는 99%를 초과하는 신뢰성을 제공하며, 이는 Shreds보다 눈에 띄게 높습니다. 이는 저희를 포함한 많은 사용자가 확인한 사실입니다. 반면 Shreds는 일반적으로 90% 이상의 신뢰성을 제공합니다.

Shreds가 모든 트랜잭션을 포착하지는 않지만, 핵심 장점은 대부분의 트랜잭션을 Geyser gRPC보다 더 빠르게 가져올 수 있다는 점입니다.

더 깊이 이해하려면 Solana의 Turbine 및 Gulf Stream 프로토콜을 살펴보는 것을 권장합니다.

- [Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol](https://medium.com/solana-labs/gulf-stream-solanas-mempool-less-transaction-forwarding-protocol-d342e72186ad)
- [Turbine — Solana’s Block Propagation Protocol Solves the Scalability Trilemma](https://medium.com/solana-labs/turbine-solanas-block-propagation-protocol-solves-the-scalability-trilemma-2ddba46a51db)

## Q. 가능한 한 최고의 환경을 원합니다.

UDP Forwarding은 Standard와 Premium으로 제공됩니다. 두 서비스 모두 Shreds는 사용자가 선택한 리전에서 수신 측에 도달합니다. Standard에서는 ERPC가 Shreds를 해당 리전의 노드에서 전달하므로, Shreds가 하나의 소스 IP에서 도착합니다. Premium에서는 메시 네트워크가 Shred마다 이 네트워크에 가장 먼저 도착한 사본을 내보냅니다. 어느 쪽이든 ERPC Web Dashboard에서 리전을 선택하고, 원시 Shreds를 받을 공용 IPv4 주소와 포트를 설정하세요.

자세한 내용은 ERPC Web Dashboard를 통해 문의해 주세요.

[ERPC Web Dashboard](https://dashboard.erpc.global/ko)

🔗 [ERPC Web Dashboard](https://dashboard.erpc.global/ko)

## Q. 지연 시간은 어느 정도인가요?

지연 시간은 측정 방법과 구체적인 사용 환경에 따라 달라집니다. 정확한 수치에 집중하기보다는, 지연 시간이 실제 운영 요구사항을 충족하는지 확인하는 것이 중요합니다.

지연 시간 측정을 위한 사용하기 쉬운 TypeScript 및 Rust 도구를 제공합니다.

- [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream)
- [SLV (한국어)](https://slv.dev/ko)

## Q. 이 RPC(gRPC, Shreds)는 다른 서비스보다 빠른가요?

저희는 모든 가격대에서 속도를 우선해 설계하며, 다른 어떤 제공업체와 나란히 측정해 보시는 것을 환영합니다. 결과는 리전, 공유 엔드포인트인지 전용 엔드포인트인지, 사용하는 프로토콜(WebSockets, gRPC, Shreds), 그리고 클라이언트의 프로그래밍 언어에 따라 달라질 수 있습니다.

저희 서비스가 더 느리다고 느끼신다면, 비교한 구체적인 조건과 경쟁사를 ERPC Web Dashboard를 통해 알려주세요. 원인을 파악하고 속도를 더욱 개선하겠습니다.

[ERPC Web Dashboard](https://dashboard.erpc.global/ko)

## Q. 가장 빠른 성능을 제공하는 플랜은 무엇인가요?

일반적으로 최상위 등급 플랜이 우수한 CPU, 더 큰 메모리 용량, 견고한 하드웨어 구성 덕분에 가장 빠른 성능을 제공합니다.

더 강력한 서버가 필요하면 맞춤형 솔루션도 제공하지만, 표준 플랜은 최적의 가격 대비 성능을 제공하도록 설계되었습니다.

저희는 모든 가격대에서 세계 최고 수준의 성능을 제공한다고 자신합니다. 동일한 가격대에서 더 빠른 제공업체를 찾으신다면 알려주세요. 조사하여 개선하겠습니다.

## Q. 지연 시간이 높습니다. 왜 그런가요?

지연 시간은 엔드포인트와의 거리가 멀어질수록 크게 증가합니다. 제공된 엔드포인트와 더 가까운 곳에 위치한 서버에서 접속하는 것을 권장합니다. 가장 빠른 환경은 저희 [Bare-Metal 서버](https://erpc.global/ko/baremetal/)와 [VPS 서비스](https://erpc.global/ko/vps/)를 통해 이용하실 수 있습니다.

## Q. WebSockets, gRPC, Shreds 중 무엇이 가장 빠른가요?

고객 피드백에 따르면 성능 순서는 다음과 같습니다.

**Shreds > gRPC > WebSockets**

경험이 다르다면 저희에게 알려주세요.

## Q. 지연 시간이 예상과 다릅니다.

성능은 사용하는 프로그래밍 언어에 따라 크게 달라집니다. 일반적으로 성능 순서는 다음과 같습니다.

**Rust > Go > TypeScript (JavaScript) > Python**

자세한 비교는 다음을 참고하세요.

[프로그래밍 언어 속도 비교](https://niklas-heer.github.io/speed-comparison/)

가장 높은 성능을 위해서는 Rust를 강력히 권장합니다.
