Solana에서 확장성을 설계한 방법

Solana는 다른 어떤 블록체인과도 다릅니다. Solana의 아키텍처는 처음부터 하드웨어의 한계까지 처리량을 끌어올리도록 설계되었습니다 — 병렬 실행, 내장된 시간 기록, 멤풀 없는 트랜잭션 전달이 모두 함께 작동하여 초당 수천 건의 트랜잭션을 1초 미만의 파이널리티로 처리합니다. 그리고 Firedancer가 메인넷에 배포되고 Alpenglow가 다가오면서, 이 한계는 극적으로 높아지려 하고 있습니다.

이 속도를 따라가는 인프라를 구축하려면 단순히 빠른 노드 이상이 필요합니다. 스택의 모든 레이어를 내일의 부하가 오늘의 부하를 압도할 것이라는 전제 하에 설계해야 합니다.

이것이 저희가 Solana 플랫폼을 처음부터 다시 구축하면서 확장성에 접근한 방식이며, 다음에 올 것을 위해 포지셔닝한 방식입니다.

Solana의 확장성 모델은 근본적으로 다릅니다

대부분의 블록체인 인프라는 Ethereum의 실행 모델 — 순차적 트랜잭션 처리, 전역 상태 트라이, 비교적 적은 데이터 출력 — 을 기준으로 설계됩니다. Solana는 이러한 전제를 모두 깨뜨립니다.

Solana의 병렬 런타임인 Sealevel은 모든 트랜잭션이 읽기 및 쓰기 집합을 사전에 선언하도록 요구하여, 서로 겹치지 않는 트랜잭션이 여러 CPU 코어에서 동시에 실행될 수 있게 합니다. Proof of History는 암호학적 시계를 원장에 직접 내장하여, 다른 체인들의 합의 속도를 늦추는 조율 오버헤드를 제거합니다. 그리고 Gulf Stream은 트랜잭션을 멤풀에 대기시키는 대신 다음 블록 생산자에게 직접 전달하여 확인 지연 시간을 더욱 단축합니다.

그 결과 네트워크는 매우 높은 속도로 방대한 양의 데이터를 생성합니다 — 피크 속도에서 연간 4페타바이트 이상입니다. 이 데이터를 서비스하는 인프라는 RPC 스키마만 다른 Ethereum처럼 다뤄서는 안 됩니다. Solana 고유의 데이터 패턴, 접근 특성, 규모를 중심으로 설계되어야 합니다.

이러한 이해가 저희가 내린 모든 결정을 형성했습니다.

Solana의 데이터 특성에 맞춘 아키텍처 설계

Solana의 데이터 프로필은 특정한 인프라 과제들을 만들어냅니다. 블록은 크고 밀도가 높습니다. 과거 조회는 엄청난 범위에 걸쳐 있습니다. 개발자는 무작위 포인트 조회(서명으로 단일 트랜잭션 가져오기)와 대규모 순차 스캔(주소의 전체 서명 히스토리 탐색) 모두를 필요로 합니다. 그리고 이 모든 것이 전 세계적으로 낮은 지연 시간에서 이루어져야 합니다.

저희는 아카이브 아키텍처의 세부적인 기술 내용 — HBase 마이그레이션, 삼중 검증 수집, 자가 복구 파이프라인, 그리고 getTransaction에서 리전당 100,000+ RPS를 달성한 구체적인 최적화 방법들 — 을 별도의 엔지니어링 게시글에서 다뤘습니다. 이 글은 그러한 결정들 뒤에 있는 설계 원칙에 관한 것입니다.

핵심 원칙은 다음과 같습니다: 독립적으로 확장되어야 하는 관심사들을 분리한다. 전통적인 Solana 인프라는 데이터 수집, 저장, 서빙을 단일 모놀리식 검증자 노드에 묶어 넣습니다. 이러한 결합은 읽기를 쉽게 확장할 수 없고, 서비스를 재시작하려면 몇 시간의 다운타임이 필요하며, 전체 스택을 건드리지 않고는 저장소 레이아웃을 최적화할 수 없다는 것을 의미합니다.

저희는 시스템을 독립적인 서비스들로 분해했습니다 — 몇 초 만에 시작되는 경량 RPC 서버, 각 인스턴스가 처리하는 데이터 유형을 세밀하게 제어할 수 있는 전용 수집기, 그리고 Solana의 접근 패턴에 맞게 특별히 설계된 저장소 레이어입니다. 각 레이어는 자체 조건에 따라 확장됩니다. 트래픽이 급증하면, 같은 데이터 레이어에 대해 몇 초 만에 추가 RPC 인스턴스를 가동합니다. 새로운 리전이 필요할 때, 저장소 레이어는 서빙 계층과 독립적으로 복제됩니다.

확장성의 전제 조건으로서의 신뢰성

인프라에는 하나의 패턴이 있습니다: 팀들은 속도를 최적화하다가 확장 한계에 부딪히고, 그 한계가 사실은 신뢰성 문제였다는 것을 깨닫습니다. 연결 끊김, 불완전한 데이터, 부하 상태에서의 조용한 실패는 모두 위장된 확장성 실패입니다.

저희는 처음부터 이를 염두에 두고 설계했습니다. 저희의 멀티 리전 아키텍처는 3~5단계의 자율적인 장애 조치를 포함합니다 — 노드, 랙, 또는 전체 리전에 문제가 생기면 트래픽이 자동으로 재라우팅됩니다.

데이터 무결성 측면에서, 모든 레코드는 두 번 기록되고, 프로그래밍적으로 검증되며, 완전성에 대해 지속적으로 스캔됩니다. 불일치가 발견되면 자가 복구 파이프라인이 자동으로 재수집하고 격차를 복구합니다 — 블록당 최대 30~50개의 관련 주소를 교차 검증합니다. 전체 복구 프로세스는 자동화되어 있으며 지속적으로 실행됩니다. 이것은 알림이 있는 정적인 모니터링 대시보드가 아닙니다.

Solana에서의 데이터 무결성은 대부분이 인정하는 것보다 더 어려운 문제입니다. 데이터의 순전한 양과 속도로 인해 작은 격차조차 빠르게 누적됩니다 — 이는 개발 팀들 사이에서 흔한 골칫거리이며, 많은 팀들이 인프라 제공업체로부터 누락되거나 일관되지 않은 데이터를 받았다고 보고했습니다. 이는 개발자의 앱이 트랜잭션이 인덱싱되지 않았거나 서명 히스토리가 불완전하여 망가지기 전까지는 보이지 않는 문제 중 하나입니다. 저희는 정확성을 최선의 노력이 아니라 타협할 수 없는 것으로 취급합니다.

그 결과 선거일 밤 Polymarket과 World의 메인넷 출시를 8년 이상 지원해 온 것과 동일한 운영 엄격함을 바탕으로 99.99%의 가동 시간을 달성했습니다. 이 수준의 신뢰성은 단순한 기능이 아니라 나머지 확장성 스토리를 가능하게 하는 기반입니다.

Solana의 다음 처리량 시대를 위한 설계

Solana의 현재 처리량은 초당 수천 건의 트랜잭션으로 측정됩니다. 프로토콜의 로드맵은 그보다 몇 자릿수 더 큰 규모를 가리키고 있으며, 이러한 궤적에 맞게 설계되지 않은 인프라는 병목 지점이 될 것입니다.

Jump Crypto의 독립적인 검증자 클라이언트로 C로 작성된 Firedancer는 2025년 말 메인넷에 배포되었습니다. 실험실 조건에서 초당 100만 건 이상의 트랜잭션을 처리하는 것으로 나타났습니다. 모듈식 타일 기반 아키텍처, 커널 우회 네트워킹, 병렬 서명 검증은 검증자 소프트웨어가 하드웨어를 사용하는 방식에 대한 근본적인 재고를 나타냅니다. 2025년 말 기준, Solana 스테이크의 약 21%가 Firedancer를 실행하고 있으며, 채택은 가속화되고 있습니다.

Firedancer와 함께, Alpenglow 프로토콜 업그레이드는 Solana의 합의 메커니즘을 재작성하고 블록 파이널리티를 약 150밀리초로 줄이는 것을 목표로 합니다. 그리고 SIMD-0370과 같은 제안들은 블록 수준의 컴퓨팅 한도를 완전히 제거하여, 인위적인 소프트웨어 제한이 아니라 하드웨어가 실제로 처리할 수 있는 것에 따라 블록이 확장되도록 할 것입니다.

또한, Light Protocol이 개발한 ZK Compression은 영지식 증명을 사용하여 여러 계정 상태를 단일 온체인 계정으로 압축할 수 있게 해줍니다. 이는 Solana의 증가하는 상태 저장 문제를 해결하고 완전히 새로운 애플리케이션 설계 패턴을 열어줍니다.

저희 인프라는 이러한 업그레이드들을 염두에 두고 설계되었습니다. 분해된 아키텍처는 처리량 요구가 증가함에 따라 각 레이어를 독립적으로 확장할 수 있음을 의미합니다. 멀티 리전 배포는 더 많은 양의 글로벌 트래픽을 처리하는 데 필요한 지리적 분산을 제공합니다. 이는 다른 Solana RPC 제공업체 대비 2배의 처리량 우위를 저희에게 제공하며, 이는 시작점이지 한계가 아닙니다.

확장 가능한 인프라가 빌더들에게 열어주는 것

확장성은 개발자가 무엇을 구축할 수 있는지를 직접적으로 결정합니다. 지난 8년 동안, 저희는 첫 API 호출부터 이후의 모든 전환점까지 빌더들을 지원해왔습니다. Circle, Robinhood, OpenSea와 같은 팀들은 초기 프로토타입에서 수억 명의 사용자에게 서비스하는 제품으로 Alchemy에서 성장했습니다.

• 밀리초 단위의 아카이브 조회는 지갑이 완전한 트랜잭션 히스토리를 즉시 렌더링할 수 있음을 의미합니다.
• 최신 우선 조회는 사용자의 최신 활동을 표시하기 위해 몇 년치의 오래된 데이터를 스캔할 필요를 없애줍니다.
• getTokenLargestAccounts이 20개가 아닌 1,000개의 결과를 반환하는 것은 분석 플랫폼에 토큰 분포에 대한 의미 있게 더 풍부한 시각을 제공합니다.
• 네이티브 가스리스 트랜잭션은 전환율을 저해하는 온보딩 마찰을 제거합니다.
• 100% 스테이크된 쓰기는 트랜잭션이 실제 블록 생산자에게 도달하도록 보장하여 확인 신뢰성을 향상시킵니다.

이러한 기능들은 저희가 확장성을 제1원칙으로 취급하기 때문에 존재합니다.

앞으로의 길

Solana는 빠르게 진화하고 있습니다. 네트워크의 용량은 증가할 것이며, 그 위에 구축된 애플리케이션들은 규모에서 더 많은 것을 요구하게 될 것입니다.

저희의 약속은 이 흐름보다 앞서 나가는 것입니다 — 더 낮은 지연 시간, 더 높은 처리량, 더 깊은 데이터 접근, 그리고 아직 불가능한 사용 사례를 가능하게 하는 새로운 기능들에 투자하는 것입니다. 인프라는 결코 빌더가 제품에서 타협해야 하는 이유가 되어서는 안 됩니다.

저희가 설명한 모든 것은 오늘 이용 가능합니다.

• alchemy.com/solana에서 시작하세요
• 맞춤형 벤치마킹, 특별 가격 책정, 또는 기타 문의는 저희에게 연락하세요.

자주 묻는 질문

Solana의 확장성이 다른 블록체인과 다른 점은 무엇인가요?

Solana는 Sealevel 런타임을 통한 병렬 트랜잭션 실행, 내장된 시간 기록을 위한 Proof of History, 그리고 멤풀을 우회하는 Gulf Stream을 사용하여, 1초 미만의 파이널리티로 초당 수천 건의 트랜잭션을 가능하게 하며 피크 속도에서 연간 4페타바이트 이상의 데이터를 생성합니다.

Alchemy의 분해된 아키텍처는 Solana의 확장성을 어떻게 개선하나요?

Alchemy는 데이터 수집, 저장, 서빙을 독립적인 서비스로 분리하여 각각 자체 조건에 따라 확장되도록 하며, 이를 통해 RPC 서버가 몇 초 만에 가동되고, 트래픽이 다운타임 없이 확장되며, 새로운 리전이 전체 스택을 건드리지 않고 배포될 수 있습니다.

Firedancer란 무엇이며 Solana의 처리량에 어떤 영향을 미치나요?

Firedancer는 Jump Crypto의 독립적인 검증자 클라이언트로 C로 작성되었으며 2025년 말 메인넷에 배포되었습니다. 모듈식 아키텍처, 커널 우회 네트워킹, 병렬 서명 검증을 통해 실험실 조건에서 초당 100만 건 이상의 트랜잭션을 처리하는 것으로 나타났습니다.

Alchemy는 Solana 규모에서 데이터 무결성을 어떻게 보장하나요?

모든 레코드는 두 번 기록되고, 프로그래밍적으로 검증되며, 완전성에 대해 지속적으로 스캔됩니다. 자가 복구 파이프라인은 블록당 최대 30~50개의 관련 주소를 교차 검증하여 모든 격차를 자동으로 재수집하고 복구합니다.

ZK Compression이란 무엇이며 왜 Solana에 중요한가요?

Light Protocol이 개발한 ZK Compression은 영지식 증명을 사용하여 여러 계정 상태를 단일 온체인 계정으로 압축할 수 있게 해주며, Solana의 증가하는 상태 저장 문제를 해결하고 새로운 애플리케이션 설계 패턴을 가능하게 합니다.

Alchemy는 Solana에서 어떻게 더 빠른 아카이브 조회를 달성하나요?

저희는 Solana의 접근 패턴에 최적화된 HBase 기반 저장소 레이어, 최신 우선 조회, 멀티 리전 아키텍처를 사용하여 getTransaction와 같은 메서드에서 리전당 100,000 RPS 이상으로 밀리초 단위의 아카이브 조회를 제공합니다.

Alchemy의 Solana 인프라가 규모에서 신뢰할 수 있는 이유는 무엇인가요?

3~5단계의 자율적인 장애 조치를 갖춘 멀티 리전 아키텍처, 자동화된 자가 복구 파이프라인, 지속적인 데이터 검증이 99.99%의 가동 시간을 제공하며, 노드, 랙, 또는 전체 리전에 문제가 생기면 트래픽이 자동으로 재라우팅되도록 보장합니다.

Alchemy의 확장 가능한 인프라가 제공하는 개발자 기능은 무엇인가요?

밀리초 단위의 아카이브 조회, 최신 우선 조회, 20개가 아닌 1,000개의 결과를 반환하는 getTokenLargestAccounts, 네이티브 가스리스 트랜잭션, 그리고 확인 신뢰성을 향상시키는 100% 스테이크된 쓰기입니다.