블록체인 데이터 인덱싱: DeFi 앱에 RPC 호출 이상의 것이 필요한 이유

블록체인 데이터 인덱싱: DeFi 앱에 RPC 호출 이상의 것이 필요한 이유

블록체인 개발자에게 앱이 “체인을 어떻게 읽을 것인가”를 물어보면 거의 항상 같은 대답을 듣습니다. 바로 RPC 호출입니다. RPC는 가장 확실한 출발점이며, 현재 지갑 잔액이나 특정 거래 확인 여부와 같은 간단한 질문에는 실제로 충분합니다. 하지만 DeFi 앱이 이 풀의 모든 거래 내역, 특정 토큰을 채굴한 모든 지갑, 지난 한 달간 유동성 심도 변화와 같은 좀 더 복잡한 질문에 답해야 하는 순간, RPC 호출만으로는 더 이상 적합한 아키텍처가 아니게 됩니다. 대부분의 개발팀은 실제 운영 환경에서 부하가 걸린 상태로 이러한 사실을 값비싼 경험을 통해 깨닫게 됩니다.

이는 대규모 분석 대시보드에만 국한된 문제가 아닙니다. 풀의 최근 거래 내역, 사용자의 파밍 보상 추이, 또는 간단한 “거래량 기준 상위 풀” 순위표 등을 보여주는 소규모 DeFi 프런트엔드조차도 순수 RPC 접근 방식으로는 효율적으로 답변할 수 없는 종류의 질문을 던지고 있습니다. “내 앱이 블록체인에 연결된다”와 “내 앱이 사용자가 기대하는 데이터를 실제로 보여줄 수 있다” 사이의 간극은 거의 전적으로 이러한 차이에서 비롯되며, 실제 트래픽 발생 시 엔드포인트 타임아웃이 발생하는 시점을 우연히 발견하기보다는 이 차이를 정확하게 이해하는 것이 중요합니다.

🗨️ “RPC는 연결성을 제공하고, 인덱서는 데이터를 활용 가능하게 만들며, 오라클은 애플리케이션을 현실 세계 및 다른 블록체인과 연결하고, 레이어 2는 실행 비용을 낮추며, 스토리지는 자산과 기록을 보관합니다.” 
— Web3 인프라 스택 개요, 2026

RPC 노드는 실제로 어떤 질문에 답하기 위해 만들어졌을까요?

RPC 엔드포인트는 단일 노드의 현재 또는 거의 현재 상태에 접근할 수 있는 관문이며, 특정 시점의 단일 개체에 대한 질문에 특히 적합합니다.

• 이 주소의 현재 잔액은 얼마인가요?
• 이 거래가 확인되었습니까?
• 현재 상태를 기준으로 이 계약 메서드를 호출하면 어떤 결과가 반환됩니까?

구조적으로 취약한 부분은 시간 경과에 따른 집계 또는 여러 엔티티에 걸친 집계입니다. “지난 30일 동안 이 풀에서 발생한 모든 스왑”은 단일 상태 읽기가 아니라, 노드가 요청에 따라 요약하도록 설계되지 않은 이력에 대한 쿼리입니다. RPC 노드에 이러한 질문에 대한 답변을 요청하려면 요청당 엄청난 범위의 블록을 다시 처리하거나, 애플리케이션이 해당 질문에 효율적으로 답변할 수 없다는 사실을 받아들여야 합니다.

이러한 제한은 특정 제공업체의 구현상의 버그가 아니라, 노드가 실제로 수행하도록 설계된 방식의 직접적인 결과입니다. 노드는 현재 상태를 유지하고 새로운 블록의 유효성을 검증하는 역할을 합니다. 노드는 범용적인 이력 데이터베이스로 설계된 것이 아니며, 그러한 역할을 요구하는 것은 노드 설계의 본질과 상충됩니다. 업계 인프라 가이드에서는 이러한 점을 점점 더 명확하게 설명하고 있습니다. 목적에 맞게 구축된 인덱스에서는 미미한 수준인 요청량도 일반 RPC 방식을 통해 처리될 경우 “공유 계층 엔드포인트를 과부하”시킬 수 있으며, 심지어 전용 유료 RPC 계층조차도 쿼리 패턴이 “하나의 항목 조회”에서 “여러 항목에 걸친 이력 재구성”으로 넘어가면 실질적인 한계에 도달합니다.

실제 적용에서 이러한 원칙이 어긋나는 지점: TON의 자체 아키텍처가 가장 명확한 사례

TON은 이 문제에 대한 매우 유용한 사례 연구입니다. 왜냐하면 TON의 설계 자체가 RPC 전용이라는 한계를 미묘한 비효율성이 아닌 매우 두드러진 문제로 드러내기 때문입니다.

🗨️ “STON.fi와 같은 탈중앙화 거래소(DEX), 대출 프로토콜, Jetton 발행 등을 포함하는 TON DeFi 생태계는 거래 제출을 위한 실시간 메서드 접근(v2)과 토큰 잔액 조회, 유동성 풀 읽기, 과거 거래 데이터 조회를 위한 인덱서 접근(v3) 모두를 필요로 합니다. v2만 제공하는 공급자는 팀들이 자체 인덱서를 운영하거나 불완전한 데이터 커버리지를 감수하도록 강요합니다.” 
— Chainstack, TON RPC 공급자 가이드, 2026

이는 STON.fi와 같은 탈중앙화 거래소(DEX)가 RPC 접근만으로는 제대로 작동할 수 없다는 점을 명확히 인정한 것입니다. TON의 비동기식 샤딩 아키텍처는 계약 간 메시지가 단일 체인 동기 호출처럼 같은 블록에서 해결되지 않기 때문에, “RPC를 반복적으로 폴링하는” 단순한 방식은 기존 체인보다 훨씬 더 비효율적입니다. 제톤 마스터 열거, 메시지별 트랜잭션 추적, 풀의 거래 내역 재구성 등 이 생태계 특유의 고강도 읽기 패턴은 “공유 계층 엔드포인트를 빠르게 과부하 상태로 만든다”고 명시적으로 지적되었습니다. 이는 가상의 확장성 문제가 아니라, STON.fi와 같은 유형의 애플리케이션에서 실제로 발생하고 있는 현실적인 운영 문제입니다.

인덱서가 실제로 하는 일은 무엇일까요?

인덱서는 더 빠른 RPC 노드가 아닙니다. 체인 뒤에 있는 근본적으로 다른 형태의 데이터입니다.

• 이 시스템은 체인을 지속적으로 감시하고 관련 이벤트를 발생 즉시 쿼리 가능한 데이터베이스에 기록하며, 요청을 기다리지 않습니다.
• 이는 RPC 노드가 효율적으로 답변할 수 없는 종류의 과거 데이터, 여러 주체에 걸친 정보(예: 풀별 총 거래량, 지갑이 보유했던 모든 포지션, 특정 기간 동안의 시계열 데이터)를 미리 집계합니다.
• 이는 일반적으로 GraphQL이나 SQL과 같은 쿼리 인터페이스를 통해 데이터를 노출하는데, 이 인터페이스는 일반적인 JSON-RPC 방식이 처리하도록 설계되지 않았던 집계 패턴을 위해 만들어졌습니다.

이러한 구분은 아키텍처적으로 중요합니다. RPC 노드는 “현재 이 특정 사안에 대해 무엇이 사실인지”를 알려주는 반면, 인덱서는 “시간 경과에 따라 모든 것에 걸쳐 무엇이 사실이었는지”를 알려줍니다. 그리고 DeFi 프런트엔드는 동일한 인터페이스의 서로 다른 부분을 위해 이 두 가지 모두를 필요로 합니다.

⚡ STON.fi의 아키텍처 자체가 이미 이러한 분열을 반영하고 있는 곳

이는 단순히 추상적인 인프라 논의에 그치는 것이 아니라, STON.fi가 자체 개발자용 API를 구성하는 방식에 직접적으로 반영되어 있습니다. STON.fi의 REST API는 풀 데이터, 제톤 정보, 프로토콜 통계, 수수료 데이터를 구체적으로 제공하여, 통합 개발자들이 “이 풀의 과거 데이터는 어떻게 생겼을까?”라는 질문에 대한 답을 찾기 위해 자체적인 인덱싱 파이프라인을 실행할 필요가 없도록 설계되었습니다. 데이터 집계 작업은 이미 한 번 중앙에서 완료되어 있으므로, 프로토콜을 기반으로 구축하는 모든 팀에 부담을 주지 않습니다.

두 번째 함수는 단순히 코드가 더 짧다는 것 이상의 의미를 지닙니다. 이는 이 글에서 제시하는 핵심 아키텍처를 구현한 것으로, 동일한 작업을 수행하면서도 엔지니어링 시간과 공유 인프라에서의 런타임 부하 측면에서 근본적으로 다른 비용을 발생시키는 두 가지 함수를 의미합니다.

더 넓은 인프라 환경에서 이와 동일한 문제를 해결합니다

STON.fi 자체 API는 이 문제에 대한 하나의 해결책이며, 특히 해당 프로토콜 데이터에 특화되어 있습니다. 더 넓은 생태계에서는 일반적인 경우에 대해 몇 가지 공통된 패턴으로 수렴되었습니다.

서브그래프 방식 인덱싱. DeFi 및 NFT 프로토콜 전반에서 널리 채택되는 패턴입니다. 온체인 이벤트 중 중요한 이벤트를 정의하면 호스팅된 인덱싱 레이어가 해당 이벤트를 지속적으로 수집하여 표준 쿼리 인터페이스를 통해 제공합니다. 개발자는 추적할 이벤트를 정의할 뿐, 체인에서 해당 이벤트를 찾는 방법을 정의할 필요는 없습니다.

자체 인프라로의 스트리밍 파이프라인. 일부 플랫폼은 요청 시점에 타사에서 호스팅하는 인덱스를 쿼리하는 대신, 관련 온체인 이벤트를 거의 실시간으로 팀 자체 데이터베이스로 직접 스트리밍합니다. 이는 설정 복잡성을 다소 감수하는 대신 결과 데이터에 대한 완전한 소유권을 확보하는 방식입니다.

과거 데이터 백필을 위해 특별히 설계된 고처리량 검색 계층입니다. 실시간 인덱싱과는 달리, 이 범주는 이벤트 중심의 대용량 과거 데이터 쿼리에 특화되어 있습니다. 이러한 워크로드는 기존 방식에서는 표준 RPC 호출을 통해 방대한 블록 범위를 수동으로 재생해야 했지만, 이 검색 계층은 바로 이러한 액세스 패턴에 맞춰 설계되어 있어 효율적으로 처리할 수 있습니다.

이러한 문제들이 존재하는 이유는 모든 블록체인과 모든 주요 DeFi 애플리케이션에서 동일한 근본적인 격차가 지속적으로 나타나기 때문입니다. 즉, 노드에 직접 접근하는 것만으로는 현재 상태 및 과거 데이터에 대한 질문에는 잘 답변할 수 있지만, 집계 데이터에 대한 질문에는 제대로 답변할 수 없습니다. 그리고 이러한 격차는 RPC 용량을 늘리는 것만으로는 해소되지 않고, 진정으로 다른 종류의 인프라 계층을 추가해야만 해결됩니다. 단순히 더 크거나 빠른 RPC 플랜에 비용을 지불하여 이 문제를 해결하려는 팀은 한계가 이동할 뿐, 완전히 사라지지는 않는다는 사실을 깨닫게 됩니다. 문제는 항상 쿼리 패턴의 불일치였지, 공급자의 처리량 자체가 아니었습니다.

실제로 중요한 차원에서 비교하기

💧 특정 시점의 데이터 읽기 vs. 과거 데이터 집계. RPC 호출은 “현재 상태는 무엇인가?”에 대한 답을 제공합니다. 인덱스는 “특정 기간 동안의 상태를 요약하여” 답을 제공하며, 실제 DeFi 프런트엔드는 이 두 가지를 동시에, 종종 같은 화면에서 필요로 합니다.

🧭 단일 엔티티 쿼리와 여러 엔티티에 걸친 쿼리. 지갑 잔액 조회는 RPC 방식입니다. 유동성 풀에 있는 모든 유동성 공급자의 규모별 순위 매기기는 인덱스 방식입니다. 두 번째 패턴을 첫 번째 방식에 억지로 적용하려는 단순한 아키텍처는 실제 부하 상황에서 실패합니다.

⏱️ 요청 시 계산 방식 vs. 사전 집계 결과 방식. 페이지 로드 시마다 트랜잭션을 재생산하여 30일간의 거래량을 계산하는 방식은 요청 시 작업이기 때문에 트래픽 증가에 따라 확장성이 떨어집니다. 반면, 사전 계산된 수치를 반환하는 인덱싱된 API는 사용자가 얼마나 많이 문의하는지가 아니라, 기본 데이터가 실제로 얼마나 자주 변경되는지에 따라 확장성이 향상됩니다.

⚔️ 자체 인덱싱 스택 운영 vs. 프로토콜 자체 인덱싱 API 활용. 인덱싱 파이프라인을 자체 호스팅하면 완벽한 제어 권한을 확보할 수 있지만, 지속적인 운영 비용이 발생합니다. 프로토콜 자체 인덱싱 엔드포인트(예: STON.fi의 REST API)를 사용하면 프로토콜 프런트엔드에서 이미 처리해야 했던 쿼리에 대한 운영 부담을 완전히 없앨 수 있습니다.

인덱싱 레이어를 추가해야 하는 진정한 이유는 무엇일까요?

1. 시간적 범위 또는 여러 개체를 동시에 다루는 모든 질문. 과거 거래량, 지갑 수준의 포지션 내역, 풀 순위 조회는 일반 RPC 접근 방식으로는 더 이상 충분하지 않다는 가장 명확한 신호입니다.
2. 반복적이고 비용이 많이 드는 체인 스캔을 유발하는 요청 패턴을 처리합니다. 단일 페이지를 제공하는 데 매번 로드할 때마다 의미 있는 범위의 트랜잭션 기록을 다시 재생해야 하는 경우, 해당 계산은 요청 경로가 아닌 사전 집계된 인덱스에 있어야 합니다.
3. 공유 인프라를 압도하는 것으로 명시적으로 문서화된 읽기 패턴이 있습니다. 체인의 툴링 생태계에서 특정 쿼리 패턴이 표준 RPC 방식 대신 전용 인덱서 접근을 필요로 한다고 지적할 때, 이는 아키텍처 결정을 위한 직접적이고 신뢰할 수 있는 신호이며 추측이 아닙니다.

⚠️ 정확하게 이해하는 것이 중요한 것은 무엇일까요?

• 인덱서는 더 빠른 RPC 노드가 아닙니다. 인덱서 는 특정 시점의 상태가 아닌 집계 및 이력 관리를 위해 설계된 구조적으로 다른 데이터 계층입니다.
• 프로토콜 자체의 인덱싱된 API를 사용하는 것은 지름길이 아니라, 오히려 올바른 아키텍처인 경우가 많습니다. STON.fi는 이미 자체 API를 통해 풀 및 수수료 데이터를 제공하고 있으므로, 해당 집계 기능을 별도로 재구축하는 것은 프로토콜이 이미 잘 수행한 작업을 중복하는 것입니다.
• TON의 비동기 샤딩 설계는 다른 체인에 비해 이러한 차이점을 더욱 명확하게 드러내지만, 그 중요성은 결코 떨어지지 않습니다. TON 인프라 제공업체가 문서화한 v2/v3 RPC 분리는 이 체인의 아키텍처가 단순한 동기식 체인보다 단순한 폴링 패턴의 오류를 더 빠르고 명확하게 드러내기 때문에 존재하는 것입니다.

🏁 결론

RPC 호출은 DeFi 앱이 가장 흥미롭지 않게 묻는 질문, 즉 “지금 이 특정 사안에 대해 무엇이 사실인가요?”라는 질문에 대한 답을 잘 제시합니다. 하지만 앱이 과거 데이터나 여러 엔티티를 동시에 처리해야 하는 순간, 실제 거래 인터페이스가 사용자에게 보여주는 대부분의 상황처럼 RPC 접근만으로는 확장성이 떨어집니다. 특히 TON의 경우, STON.fi와 같은 DEX가 표준 RPC 방식과 함께 인덱서 수준의 접근이 필요하다고 명시적으로 언급되어 있는 현실을 보면, 이러한 격차는 이론적인 문제가 아니라 실제로 존재하는 문제입니다. 프로토콜 자체의 인덱싱 API가 존재하는 경우, 해당 API를 기반으로 구축하는 것이, 그 집계 기능을 독립적으로 재구현하는 것보다 일반적으로 더 나은 해결책이며, 타협안이 아닙니다.