---
title: "블록체인 인덱서란?"
description: "인덱서의 역할과 온체인 데이터를 쿼리하는 데 어떻게 도움이 되는지 알아보세요."
---

# 블록체인 인덱서란?

<ImageBlock
  src="https://media.alchemy.com/1764645001-what-is-a-blockchain-indexer.png"
  alt="블록 데이터를 확대해 보여주는 돋보기 그래픽"
  width={5760}
  height={2700}
  priority
/>

블록체인에는 근본적인 문제가 있습니다. 바로 데이터가 검색 가능하지 않다는 것입니다. 다시 말해, 온체인 데이터는 기본적으로 쿼리할 수 없습니다.

전통적인 데이터베이스에서는 데이터가 인덱스와 관계를 가진 테이블 형태로 구성되어 있어, 개발자가 모든 레코드를 스캔하지 않고도 요청을 즉시 쿼리할 수 있습니다. 반면 블록체인은 데이터를 블록의 선형 체인 형태로 저장하며, 이는 불변성과 보안을 위해 최적화된 것이지 빠른 검색을 위한 것이 아닙니다.

이러한 설계 때문에 SQL도 없고, 내장된 인덱스도 없으며, 데이터를 쉽게 쿼리할 수 있는 편리한 `"SELECT FROM transactions WHERE..."`함수도 없습니다. 블록체인이 대신 제공하는 것은 `eth\_getBlockByNumber` 같은 저수준 RPC 메서드로, 원시 블록을 반환할 뿐이라 필요한 것을 찾으려면 블록을 하나씩 가져와서 스캔해야 합니다.

예를 들어, 특정 지갑의 모든 트랜잭션을 찾고 싶다면 블록 0부터 시작해서 수백만 개의 블록을 순회하고, 각 블록의 모든 트랜잭션을 확인하면서 노드가 도중에 요청을 제한하지 않기를 바라야 합니다. [Ethereum 메인넷](https://www.alchemy.com/rpc/ethereum)에는 [2천만 개 이상의 블록](https://etherscan.io/)이 있어, 이 작업에 몇 시간에서 며칠까지 걸릴 수 있으며, 그 데이터를 유용하게 쓰려면 직접 정리하고 저장까지 해야 합니다.

이때 필요한 것이 바로 인덱서입니다. 인덱서는 블록체인의 원시 순차 데이터와 애플리케이션에 필요한 빠른 쿼리 사이를 이어주는 다리 역할을 합니다. 온체인 데이터를 위한 검색 엔진이라고 생각하면 됩니다. 인덱서는 블록체인을 지속적으로 모니터링하고, 관련 정보를 추출하고, 쿼리 가능한 데이터베이스로 정리한 뒤, API를 통해 몇 시간이 아닌 밀리초 단위로 응답하는 형태로 제공합니다.

인덱서가 없다면 반응성 있는 앱을 만드는 것은 거의 불가능합니다. 포트폴리오를 불러오는 데 30초가 걸리는 DeFi 대시보드나, 트랜잭션 유형별로 필터링을 할 수 없는 네오뱅크를 상상해 보세요. 인덱서는 블록체인 데이터를 미리 처리함으로써 모든 블록을 직접 스캔할 필요가 없게 해줍니다.

이 가이드에서는 블록체인 인덱서가 무엇인지, 어떻게 작동하는지 설명하고, 실제로 인덱서가 사용되는 사례를 소개하겠습니다.

코드 예제와 참고할 만한 자료 링크를 함께 제공하여 더 깊이 파고들 수 있도록 구성했습니다. 첫 앱을 만들고 있는 주니어 개발자든, 지식을 다시 정리하고 싶은 개발자든 이 가이드를 통해 블록체인 인프라에서 가장 중요한 요소 중 하나를 이해할 수 있을 것입니다.

## 블록체인 인덱서란 무엇인가?

블록체인 인덱서는 블록체인을 지속적으로 감시하고, 트랜잭션 데이터와 스마트 컨트랙트 이벤트를 추출하며, 이를 구조화된 형식으로 변환한 뒤, 빠른 쿼리에 최적화된 데이터베이스에 저장하는 특수한 서비스입니다.

이 과정을 세 단계로 나눠서 생각해 볼 수 있습니다:

1. **추출 (Extract)**: 인덱서는 블록체인 노드를 실시간으로 모니터링하며, 새로운 블록, 트랜잭션, 이벤트가 체인에 추가되는 즉시 이를 캡처합니다.
1. **변환 (Transform)**: 원시 블록체인 데이터를 디코딩하여 트랜잭션 입력값을 파싱하고, 스마트 컨트랙트 이벤트를 디코딩하고, 토큰 전송을 추적하고, 상태 변화를 의미 있는 레코드로 정리합니다.
1. **적재 (Load)**: 마지막으로, 처리된 데이터를 쿼리 가능한 데이터베이스\(PostgreSQL, MongoDB, 또는 특화된 그래프 데이터베이스 등\)에 저장하여, 애플리케이션이 사용할 수 있는 API를 통해 해당 데이터를 노출할 수 있게 합니다.

이 과정이 실제로 어떻게 작동하는지 더 깊이 알아보고 싶다면, [Ethereum Foundation의 인덱서 소개 자료](https://www.youtube.com/watch?v=WgBab6kamtg)를 참고하세요.

## 인덱서를 구성하는 요소는 무엇인가?

인덱서는 구현 방식이 다양하지만, 대부분 데이터를 처리하고 제공하기 위해 함께 작동하는 몇 가지 핵심 구성 요소를 공통적으로 갖추고 있습니다. 각 요소가 어떻게 맞물리는지 살펴보겠습니다.

### 1. 데이터 소스 \(블록체인 연결\)

이는 인덱서가 블록체인 자체와 연결되는 지점으로, 보통 노드\(Ethereum의 [Geth](https://geth.ethereum.org/)나 [Solana RPC](https://www.alchemy.com/dapps/list-of/rpc-node-providers-on-solana) 노드 등\)이거나 인프라 제공업체의 API\(Alchemy와 같은\)입니다.

인덱서는 이 소스로부터 원시 데이터를 지속적으로 가져옵니다: 새로 추가되는 블록, 그 블록 안의 트랜잭션, 스마트 컨트랙트가 발생시키는 이벤트 로그, 때로는 상태 변화까지 포함됩니다. 일부 인덱서는 실시간으로 데이터를 처리\(새 블록을 즉시 수신\)하고, 다른 인덱서는 과거 데이터를 처리하거나 다운타임 이후 따라잡기 위해 배치 방식으로 작동합니다.

### 2. 인덱싱 엔진 \(처리 계층\)

이 부분이 전체 작업의 두뇌 역할을 합니다. 인덱싱 엔진은 원시 블록체인 데이터를 의미 있고 검색 가능한 형태로 변환합니다.

엔진의 핵심 역할은 트랜잭션과 이벤트를 디코딩하는 것입니다. 원시 블록체인 데이터는 인코딩되어 있어, 트랜잭션 입력값은 16진수 문자열이고 이벤트 로그는 암호화 해시 형태입니다. 인덱싱 엔진은 컨트랙트의 [ABI](https://docs.soliditylang.org/en/latest/abi-spec.html)\(Application Binary Interface\)를 사용하여 각 트랜잭션이 실제로 무엇을 했는지 해석합니다. 토큰 스왑이었는지, NFT 민팅이었는지, 거버넌스 투표였는지 말이죠. 파라미터를 디코딩하고, 의미 있는 값을 추출하여 사람이 읽을 수 있는 레코드로 변환합니다.

개별 트랜잭션을 디코딩하는 것 외에도, 엔진은 시간에 따른 상태 변화를 추적해야 합니다. 블록체인은 현재 상태를 쉽게 접근할 수 있는 형태로 저장하지 않으며, 대신 상태 전이의 히스토리를 저장합니다. 따라서 인덱서는 이벤트의 체인을 따라가며 현재 상태를 재구성합니다: 전송이 일어날 때마다 토큰 잔액이 어떻게 변하는지 추적하고, 토큰이 지갑 간에 이동할 때 NFT 소유권을 모니터링하며, 상호작용이 있을 때마다 스마트 컨트랙트의 저장 변수가 어떻게 변하는지 관찰합니다. 이러한 상태 추적은 "이 지갑이 현재 소유하고 있는 NFT는 무엇인가?"와 같은 쿼리에 필수적입니다. 이 답은 온체인 어디에도 저장되어 있지 않으며, 전체 전송 히스토리로부터 계산해야만 알 수 있습니다.

엔진은 또한 특화된 인덱스를 구축하는데, 이는 빠른 조회를 가능하게 하는 효율적인 데이터 구조입니다. 책의 색인처럼 생각하면 됩니다: "Ethereum"이라는 단어를 찾기 위해 모든 페이지를 읽는 대신, 색인을 확인해서 관련 페이지로 바로 이동하는 것과 같습니다. 인덱싱 엔진은 주소\(지갑 `0x123`의 모든 활동 찾기\), 토큰 ID\(NFT #5000의 소유자와 히스토리 찾기\), 트랜잭션 유형\(모든 [Uniswap](https://www.alchemy.com/dapps/uniswap) 스왑 찾기\), 타임스탬프\(지난 24시간 동안의 모든 활동 찾기\) 등에 대한 조회 테이블을 생성합니다. 이러한 인덱스가 있기에 수백만 개 블록을 순차적으로 스캔하던 작업이 1초 미만의 쿼리로 바뀌는 것입니다.

이 엔진의 또 다른 중요한 역할은 체인 재구성(reorg)을 처리하는 것입니다. 가끔 블록체인 합의 과정에서 최근 블록의 짧은 구간이 다른 블록들로 교체되는 경우가 있는데, 이를 흔히 "[블록체인 reorg](https://www.alchemy.com/overviews/what-is-a-reorg)"라고 부릅니다. 이런 일이 발생하면 인덱서는 reorg를 감지하고, 고아가 된 블록에서 인덱싱한 데이터를 롤백한 후, 새로운 정규 블록을 다시 인덱싱해야 합니다. reorg를 제대로 처리하지 않으면 인덱싱된 데이터에 정규 체인에서 실제로 일어나지 않은 트랜잭션이 포함될 수 있습니다.

마지막으로, 이 인덱싱 엔진은 동기화와 백필(backfill)을 관리합니다. 인덱서가 처음 시작될 때는 전체 블록체인 히스토리를 처리해야 하며, 이는 몇 년치, 수백만 개의 블록이 될 수 있습니다. 이 "백필" 과정은 효율적이어야 하며, 보통 블록 처리를 병렬화하고 재시작에 대비해 진행 상황을 체크포인트로 저장합니다. 일단 따라잡고 나면, 인덱서는 새로 추가되는 블록과 지속적으로 동기화하며, 보통 체인 최신 지점보다 몇 초 정도만 뒤처집니다. 인덱서가 오프라인이 되거나 뒤처지면, 블록을 놓치지 않고 따라잡아야 합니다.

바로 이 지점에서 무거운 연산 작업이 일어납니다: 수백만 개의 트랜잭션을 파싱하고, 컨트랙트 주소와 토픽을 기준으로 관련 이벤트를 필터링하고, 복잡하게 중첩된 데이터 구조를 디코딩하고, reorg 상황에서도 일관된 상태를 유지하며, 빠른 저장과 조회를 위해 모든 것을 구조화하는 작업입니다.

### 3. 데이터베이스 \(저장 계층\)

엔진이 데이터를 처리하고 구조화한 후에는, 쿼리 가능한 곳에 저장되어야 하며, 보통 외부 데이터베이스가 그 역할을 합니다. 데이터베이스 선택은 인덱서의 사용 사례와 쿼리 패턴에 따라 달라집니다:

- **관계형 데이터베이스 \(PostgreSQL, MySQL\)**: 관계형 데이터베이스는 대부분의 블록체인 인덱서에서 가장 흔하게 선택되는 방식입니다. 트랜잭션마다 변하는 지갑 잔액을 추적하거나, 블록과 주소를 연결하는 외래 키로 트랜잭션 히스토리를 유지하거나, 여러 테이블에 걸쳐 JOIN 연산으로 토큰 전송을 쿼리하는 등 복잡한 관계를 가진 구조화된 데이터에 이상적입니다. SQL의 강력한 쿼리 언어를 사용하면 "지난 한 주 동안 이 컨트랙트로부터 10 ETH 이상 받은 모든 주소를 보여줘"와 같은 질문을 쉽게 할 수 있습니다. 엄격한 스키마는 금융 정보를 추적할 때 중요한 데이터 일관성을 보장합니다.
- **NoSQL 데이터베이스 \(MongoDB, Cassandra\)**: NoSQL 데이터베이스는 스키마가 시간이 지남에 따라 변할 수 있는 준구조화 데이터에 유연성을 제공합니다. 다양한 이벤트 구조를 가진 여러 스마트 컨트랙트를 인덱싱하거나, 테이블에 깔끔하게 맞지 않는 원시 트랜잭션 메타데이터를 저장할 때 유용합니다. 이러한 데이터베이스는 수평 확장에 강점을 가지며, 여러 서버에 데이터를 분산시켜 대량의 쓰기 작업\(초당 수천 개의 블록을 처리할 때 중요\)을 처리합니다. 복잡한 쿼리 기능보다 순수한 인덱싱 속도가 더 중요할 때 자주 사용됩니다.
- **그래프 데이터베이스 \(Neo4j\)**: 그래프 데이터베이스는 관계가 많은 쿼리를 위해 설계되었습니다. 여러 지갑을 거치는 토큰 흐름을 추적\(자금 추적\)하거나, DeFi 프로토콜 간 상호작용을 분석\(유동성 풀을 통해 어떤 프로토콜이 연결되어 있는지\)하거나, 소셜 그래프\(어떤 지갑들이 서로 상호작용하는지\)를 구축하는 사용 사례에 적합합니다. 관계형 데이터베이스의 JOIN 대신 그래프 데이터베이스는 네이티브 그래프 탐색을 사용하여, "이 주소로부터 3홉 이내에 있는 모든 지갑 찾기" 같은 쿼리를 관계형 데이터베이스보다 훨씬 빠르게 처리합니다.
- **데이터 웨어하우스 \(BigQuery, Snowflake\)**: 데이터 웨어하우스는 대규모 데이터셋 전반의 분석과 집계를 위해 설계되었습니다. 실시간 쿼리용이 아니라, "이번 달 모든 DEX의 총 거래량은?" 또는 "지난 1년간 체인별 일일 활성 주소를 보여줘" 같은 질문에 답하기 위한 것입니다. 컬럼 기반 저장과 분산 처리를 통해 수십억 개의 레코드를 효율적으로 처리할 수 있지만, 운영용 데이터베이스보다 지연 시간이 더 깁니다.

많은 프로덕션 인덱서는 여러 데이터베이스 유형을 함께 사용합니다: 애플리케이션 UI를 구동하는 빠른 실시간 쿼리를 위해 PostgreSQL에 트랜잭션 데이터를 저장하는 동시에, 같은 데이터를 BigQuery로도 전달하여 분석 대시보드와 과거 트렌드 분석에 활용합니다. 이러한 하이브리드 방식은 각 데이터베이스가 가장 잘하는 역할을 하도록 해줍니다.

### 4. API 계층 \(쿼리 인터페이스\)

API 계층은 애플리케이션이 인덱싱된 데이터에 접근할 수 있게 해주는 부분입니다. API는 데이터가 내부적으로 어떻게 저장되고 정리되어 있는지 알 필요 없이 앱이 처리된 블록체인 데이터를 쿼리할 수 있도록 엔드포인트를 노출하며, 데이터베이스 스키마, 인덱싱 로직, 데이터 변환의 복잡성을 추상화합니다.

일반적인 접근 방식은 다음과 같습니다:

- **GraphQL API**: GraphQL API는 가장 유연한 옵션으로, 클라이언트가 단 한 번의 쿼리로 필요한 데이터를 정확히 요청할 수 있게 해줍니다. 여러 REST 호출을 하는 대신, 애플리케이션은 하나의 요청으로 중첩된 관련 데이터를 요청할 수 있습니다. 예를 들어 "이 주소에 대해 값이 &gt; $1,000인 모든 ERC-20 전송을 가져오고, 각 전송마다 토큰의 이름, 심볼, 소수점 자릿수, 현재 가격을 포함해줘" 같은 요청이 가능합니다. GraphQL은 클라이언트가 반환할 필드를 지정할 수 있게 해주어, 과도한 페칭\(필요 없는 데이터를 가져오는 것\)이나 부족한 페칭\(여러 번 왕복이 필요한 것\)을 피할 수 있습니다. 이는 여러 엔티티에 걸친 복잡한 쿼리에 특히 강력합니다. 예를 들어 [The Graph 프로토콜](https://thegraph.com/)은 전적으로 GraphQL 위에 구축되어 있습니다.
- **REST API**: REST API는 더 단순하고 예측 가능하며, 일반적인 쿼리를 위한 미리 정의된 엔드포인트를 제공합니다. 각 엔드포인트는 트랜잭션 히스토리를 가져오는 `/api/address/\{address\}/transactions`이나 현재 모든 토큰 보유자를 가져오는 `/api/token/\{contract\}/holders`처럼 특정 목적을 가집니다. REST는 캐싱이 더 쉽고\(각 URL이 특정 리소스를 나타내므로\), 문서화하기 더 간단하며, 대부분의 개발자에게 익숙합니다. 단점은 유연성이 떨어진다는 점으로, 엔드포인트가 제공하지 않는 데이터가 필요하면 여러 요청을 하거나 새로운 엔드포인트가 만들어질 때까지 기다려야 합니다. REST는 쿼리 패턴이 잘 알려져 있고 일관될 때 이상적입니다.
- **WebSocket 스트림**: WebSocket 스트림은 새 블록이 인덱싱될 때 실시간 업데이트를 받기에 적합합니다. 몇 초마다 API에 "새로운 게 있나요?"라고 폴링하는 대신, 앱은 WebSocket 연결을 열어두고 관련 데이터가 도착하는 즉시(예: 특정 주소가 트랜잭션을 받았을 때) 푸시 알림을 받습니다. 이는 실시간 거래 대시보드나 실시간 알림 시스템처럼 즉각적인 업데이트가 필요한 애플리케이션에 중요합니다. WebSocket은 연결을 계속 열어두기 때문에 가끔씩 하는 REST 호출보다 리소스를 더 많이 사용하지만, 시간에 민감한 데이터의 지연을 없애줍니다.

API 계층에는 단순히 데이터를 제공하는 것 이상의 중요한 인프라 기능이 포함되는 경우가 많습니다: 캐싱\(자주 요청되는 쿼리 결과를 메모리에 저장하여 데이터베이스를 반복적으로 조회하지 않도록 하고, 인기 있는 쿼리의 응답 시간을 크게 개선함\), 속도 제한\(한 사용자가 너무 많은 요청으로 시스템에 과부하를 주지 못하도록 방지하여 모두에게 공정한 접근을 보장함\), 인증\(사용량을 추적하고, 접근 제어를 강제하며, 필요시 프리미엄 등급에 대해 요금을 부과할 수 있도록 하는 API 키나 토큰\)입니다. 이러한 기능들은 특히 수천 개의 앱을 동시에 서비스할 때 API가 빠르고 안정적이며 경제적으로 지속 가능하도록 보장합니다.

## **인덱서 구성 요소들이 함께 작동하는 방식**

실제로 작동하는 흐름의 예를 살펴보겠습니다. 인덱서의 데이터 소스가 Ethereum 노드에서 블록 #18,500,000을 가져옵니다. 그런 다음 인덱싱 엔진은 그 블록 안의 200개 트랜잭션을 디코딩하고, 500개의 이벤트\(Uniswap 스왑과 NFT 전송 포함\)를 추출하며, 어떤 지갑이 영향을 받았는지 식별합니다.

그 후, 데이터베이스는 주소, 토큰 컨트랙트, 타임스탬프에 대한 인덱스를 포함하여 이 레코드들을 저장합니다. 이 지점부터 여러분의 앱은 인덱서의 API에 "이번 주 주소 `0x123`가 구매한 모든 NFT를 보여줘"라고 쿼리합니다. API는 블록체인이 아닌 인덱싱된 데이터베이스를 조회하여 50ms 만에 결과를 반환합니다.

이러한 아키텍처 덕분에 인덱서는 몇 시간이 걸리던 블록체인 스캔을 밀리초 단위의 쿼리로 바꿀 수 있는 것입니다.

## 실제로 인덱싱은 어떻게 작동하는가?

구성 요소들을 이해했으니, 이제 인덱싱이 실제로 어떻게 작동하는지 살펴보고 인덱서가 원시 블록체인 데이터를 즉시 쿼리 가능한 정보로 어떻게 바꾸는지 보여드리겠습니다.

### 실제 예시: DeFi 대출 프로토콜 인덱싱하기

[Aave](https://aave.com/)나 [Compound](https://compound.finance/) 같은 플랫폼이 작동하는 방식과 유사한, 단순화된 대출 프로토콜 스마트 컨트랙트를 구체적인 예시로 살펴보겠습니다. 이 컨트랙트는 사용자가 담보를 예치하고 자산을 빌릴 수 있게 해줍니다:

<CodeSnippet language="solidity" code={`// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

\`contract LendingProtocol {

\`struct Position {
address user;
address collateralToken;
uint256 collateralAmount;
address borrowedToken;
uint256 borrowedAmount;
uint256 interestRate;
uint256 timestamp;
}

mapping(uint256 => Position) public positions;
uint256 public nextPositionId;

event PositionOpened(
uint256 indexed positionId,
address indexed user,
address collateralToken,
uint256 collateralAmount,
address borrowedToken,
uint256 borrowedAmount,
uint256 interestRate
);

event PositionClosed(
uint256 indexed positionId,
address indexed user,
uint256 amountRepaid
);

event PositionLiquidated(
uint256 indexed positionId,
address indexed liquidator,
uint256 collateralSeized
);

function openPosition(
address collateralToken,
uint256 collateralAmount,
address borrowedToken,
uint256 borrowedAmount,
uint256 interestRate
) external {
uint256 positionId = nextPositionId++;

    positions[positionId] = Position({
        user: msg.sender,
        collateralToken: collateralToken,
        collateralAmount: collateralAmount,
        borrowedToken: borrowedToken,
        borrowedAmount: borrowedAmount,
        interestRate: interestRate,
        timestamp: block.timestamp
    });

    emit PositionOpened(
        positionId,
        msg.sender,
        collateralToken,
        collateralAmount,
        borrowedToken,
        borrowedAmount,
        interestRate
    );

}

function closePosition(uint256 positionId, uint256 amountRepaid) external {
require(positions[positionId].user == msg.sender, "Not position owner");

    emit PositionClosed(positionId, msg.sender, amountRepaid);

    delete positions[positionId];

}

}`} />

인덱서가 없다면 이 프로토콜에 대한 질문에 답하는 것은 힘든 일이 될 것입니다:

- "모든 포지션에 걸친 총 예치 자산 가치는?" 이를 알려면 모든 블록을 스캔하고, 모든 `PositionOpened` 이벤트를 찾아 각각을 디코딩하고, 총 담보액을 계산해야 합니다.
- "사용자 0x123의 모든 포지션을 보여줘" 이 역시 전체 스캔이 필요하며, 사용자 주소로 필터링해야 합니다.
- "ETH 담보 대출의 평균 이자율은?" 여기서도 담보 토큰으로 필터링하는 전체 스캔이 필요하며, 이자율을 집계해야 합니다.
- "이번 주에 청산된 포지션은 몇 개인가?" 이를 알려면 일주일치 블록을 스캔하며 `PositionLiquidated` 이벤트를 찾아야 합니다.

이러한 각 쿼리는 몇 분에서 몇 시간까지 걸릴 수 있으며, 수 기가바이트의 블록체인 데이터를 처리해야 합니다.

인덱서를 사용하면 다음과 같이 진행됩니다:

1. **이벤트 감지**: 인덱서는 LendingProtocol 컨트랙트 주소를 모니터링합니다. 블록 #18,500,000에 `PositionOpened` 이벤트를 발생시키는 트랜잭션이 포함되면, 인덱서는 즉시 이를 캡처합니다.
1. **데이터 추출**: 컨트랙트의 ABI를 사용하여 인덱서는 이벤트 파라미터를 디코딩합니다: `positionId=42`, `user=0xabc...`, `collateralToken=0xWETH`, `collateralAmount=5000000000000000000`\(5 ETH, wei 단위\), `borrowedToken=0xUSDC`, `borrowedAmount=8000000000`\(8,000 USDC\), `interestRate=500`\(5%\).
1. **보강**: 인덱서는 추가 컨텍스트를 가져와서 이 데이터를 보강할 수 있습니다. 예를 들어 ETH와 USDC의 현재 USD 가격을 조회하여 포지션의 달러 가치를 계산하거나, 시간 기반 쿼리를 위해 블록 타임스탬프를 저장할 수 있습니다.
1. **저장**: 여러 인덱스와 함께 이를 데이터베이스에 기록합니다:

<CodeSnippet language="sql" code={`INSERT INTO lending_positions (
    position_id, user_address, collateral_token, collateral_amount,
    borrowed_token, borrowed_amount, interest_rate, 
    block_number, timestamp, status
) VALUES (42, '0xabc...', '0xWETH', 5000000000000000000, '0xUSDC', 8000000000, 500, 18500000, 1699564800, 'open');

-- Create indexes for fast lookups
CREATE INDEX idx_user ON lending_positions(user_address);
CREATE INDEX idx_collateral_token ON lending_positions(collateral_token);
CREATE INDEX idx_status ON lending_positions(status);`} />

5.** API 제공**: 이제 이런 복잡한 쿼리들이 단순하고 빠른 데이터베이스 조회가 됩니다:

- "총 예치 자산 가치?" → `SELECT SUM\(collateral\_amount \* token\_price\) FROM lending\_positions WHERE status='open'`\(10ms 만에 반환\)
- "사용자 0x123의 포지션?" → `SELECT \* FROM lending\_positions WHERE user\_address='0x123'`\(즉시\)
- "ETH 대출의 평균 이자율?" → `SELECT AVG\(interest\_rate\) FROM lending\_positions WHERE collateral\_token='0xWETH'`\(밀리초 단위\)

인덱서는 새로운 블록마다 이 과정을 계속 반복하여, 프로토콜의 전체 상태와 히스토리에 대한 실시간 쿼리 가능한 뷰를 유지합니다. `PositionClosed` 이벤트가 발생하면 상태 필드를 업데이트합니다. 가격이 변하면 청산 모니터링을 위해 포지션의 건전성 비율을 다시 계산할 수 있습니다.

순차적인 블록체인 스캔에서 인덱싱된 데이터베이스 쿼리로의 이러한 전환이야말로 현대적인 크립토 핀테크 대시보드, 분석 플랫폼, 리스크 모니터링 도구를 가능하게 하는 것입니다. 인덱서가 없다면 우리가 블록체인 애플리케이션에서 기대하는 사용자 경험은 아예 존재할 수 없을 것입니다.

## 인덱서는 어떤 문제를 해결하는가?

대출 프로토콜 예시를 통해 인덱싱이 어떻게 작동하는지 살펴봤으니, 이제 인덱서가 개발자를 위해 해결하는 근본적인 문제들을 정리해보겠습니다:

- **데이터 접근성과 쿼리 성능**: 블록체인에는 내장된 검색 기능이 없으며, 데이터를 쿼리하려면 수백만 개의 블록을 순차적으로 스캔해야 합니다. 인덱서는 블록체인 데이터를 추출하여 전략적인 인덱스를 갖춘 쿼리 가능한 데이터베이스로 정리함으로써, 몇 시간 걸리던 스캔을 밀리초 단위의 쿼리로 바꿔줍니다.
- **데이터 분석**: 대규모 활동\(거래량, 사용자 패턴, 프로토콜 건전성\)을 파악하려면 방대한 데이터셋을 집계해야 합니다. 인덱서는 과거 상태를 유지하고 일반적인 지표를 미리 계산해둡니다. 일일 DEX 거래량은 이미 합산되어 있고, 프로토콜 변경 이후 비활성 지갑은 인덱싱된 타임스탬프를 통해 즉시 쿼리할 수 있어, 커스텀 데이터 파이프라인이 필요 없어집니다.
- **실시간 앱 개발**: 현대적인 앱은 사용자에게 정확하고 성능 좋은 경험을 제공하기 위해 온체인 이벤트에 즉각적으로 반응해야 합니다. 블록체인 노드를 계속 폴링하는 것은 느리고 비효율적입니다. 인덱서는 이벤트가 발생하는 즉시 애플리케이션에 알려주는 푸시 기반 아키텍처\(WebSocket\)를 사용하여, 블록체인 앱이 web2만큼 반응성 있게 느껴지도록 만들어줍니다.

## 일반적인 인덱싱 사용 사례

인덱서가 존재하는 이유를 이해하면 실제로 무엇을 만들 수 있는지 명확해집니다. 인덱싱된 블록체인 데이터를 활용하는 실제 애플리케이션들을 소개합니다:

- **DeFi 대시보드 및 포트폴리오 관리**: [Zapper](https://zapper.xyz/), [Debank](https://debank.com/), [Zerion](https://zerion.io/) 같은 앱들은 [Aave](https://aave.com/)의 대출 포지션, [Uniswap](https://uniswap.org/)의 유동성 풀, [Lido](https://lido.fi/)의 스테이킹 자산 등 수십 개의 프로토콜에 걸친 사용자 포지션을 실시간 USD 가치와 함께 하나의 포트폴리오 뷰로 집계합니다. 인덱서가 없다면 페이지를 로드할 때마다 수백 개의 스마트 컨트랙트를 개별적으로 쿼리해야 할 것입니다.
- **고급 검색을 갖춘 마켓플레이스**: [OpenSea](https://opensea.io) 같은 플랫폼에서 사용자는 특정 특성으로 컬렉션을 필터링하고, 희귀도 순위로 정렬하고, 전체 소유권 히스토리를 확인하고, 시간에 따른 바닥 가격 변화를 추적할 수 있습니다. 인덱서 덕분에 검색할 때마다 전체 블록체인을 스캔하지 않고도 수백만 개의 ERC-721에 걸친 이러한 복잡한 쿼리가 가능합니다.
- **온체인 분석 플랫폼**: [Dune](https://dune.com/home), [Nansen](https://www.nansen.ai/), [Flipside Crypto](https://flipsidecrypto.xyz/home/) 같은 도구들은 프로토콜 지표를 보여주는 커스텀 대시보드를 제공하며, DEX 거래량, 대출 프로토콜 이용률, 체인 간 브릿지 흐름, 고래 지갑의 움직임을 추적합니다. 애널리스트들은 원시 블록체인 로그를 처리하는 대신 인덱싱된 데이터에 대해 SQL 쿼리를 작성합니다.
- **트레이딩 봇 및 MEV 전략**: 자동화된 트레이딩 시스템은 차익거래 기회를 찾기 위해 멤풀 트랜잭션을 모니터링하고, 최적의 라우팅을 위해 여러 DEX에 걸친 유동성 풀 준비금을 추적하며, 트리거 이벤트가 발생한 블록 내에서 전략을 실행합니다. 이는 인덱서만이 대규모로 제공할 수 있는 1초 미만의 데이터 접근을 필요로 합니다.
- **지갑**: [MetaMask](https://metamask.io/), [Rainbow](https://rainbow.me), [Phantom](https://phantom.com/) 같은 현대적인 지갑들은 전체 트랜잭션 히스토리, 토큰 잔액\(가지고 있는지도 몰랐던 토큰 포함\), 대기 중인 트랜잭션, 예상 가스비를 보여줍니다. 이러한 기능들은 모두 인덱싱된 데이터에 의존하며, 블록체인 노드를 직접 쿼리한다면 지갑 인터페이스가 사용할 수 없을 정도로 느려질 것입니다.
- **블록체인 탐색기**: [Etherscan](https://etherscan.io/), [Solscan](https://solscan.io/) 및 유사한 탐색기들은 사용자가 어떤 주소, 트랜잭션 해시, 블록 번호, 토큰 컨트랙트든 검색하면 즉시 전체 세부 정보, 관련 트랜잭션, 과거 활동을 볼 수 있게 해줍니다. 이들은 본질적으로 포괄적인 블록체인 인덱서 위에 얹힌 UI 레이어입니다.
- **DAO 거버넌스 플랫폼**: [Snapshot](https://snapshot.org/)과 [Tally](https://www.tally.xyz/) 같은 도구들은 제안의 생명주기, 특정 블록 시점의 토큰 보유량을 기반으로 한 투표권 계산, 위임 관계, 투표 히스토리를 추적합니다. 이러한 플랫폼들은 과거 제안에 누가 투표할 자격이 있었는지 계산하기 위해 인덱싱된 과거 상태가 필요합니다.
- **리스크 관리 및 모니터링**: 프로토콜들은 인덱서를 사용하여 청산 위험이 있는 대규모 포지션을 모니터링하고, 보안 알림을 위해 비정상적인 지갑 활동 패턴을 추적하고, 트랜잭션 패턴을 분석하여 잠재적인 스마트 컨트랙트 익스플로잇을 식별하고, 특정 온체인 조건이 충족될 때 알림을 생성합니다.
- **크로스체인 브릿지**: 체인 간 자산 이동을 지원하거나 여러 네트워크에 걸쳐 최적의 스왑 경로를 찾는 애플리케이션들은 수수료를 계산하고, 환율을 비교하고, 전송 상태를 추적하기 위해 각 블록체인으로부터 실시간 인덱싱된 데이터가 필요합니다.

## 2025년 인기 있는 인덱서

인덱싱 생태계는 탈중앙화 프로토콜부터 완전 관리형 서비스까지 다양한 솔루션을 제공합니다. 주요 옵션들을 정리하면 다음과 같습니다:

### The Graph

[The Graph](https://thegraph.com/)는 가장 널리 채택된 탈중앙화 인덱싱 프로토콜입니다. 개발자는 어떤 스마트 컨트랙트를 모니터링할지, 그리고 데이터를 쿼리 가능한 형식으로 어떻게 변환할지를 지정하는 커스텀 인덱싱 구성인 "서브그래프"를 정의합니다. 독립적인 노드 운영자들이 인덱싱 인프라를 운영하고 쿼리를 서비스한 대가로 GRT 토큰을 받습니다. The Graph는 검열 저항성을 우선시하고 중앙화된 서비스 제공업체보다 탈중앙화 인프라에 의존하고 싶은 프로젝트에 가장 적합합니다.

### Goldsky

[Goldsky](https://goldsky.com/)는 90개 이상의 블록체인을 지원하는 인프라 플랫폼으로, 커스텀 데이터 파이프라인에 중점을 둡니다. 복잡한 데이터 변환, 외부 데이터베이스로의 블록체인 데이터 스트리밍, 분석 워크로드를 위한 데이터 웨어하우스 공급에 강점이 있습니다. Goldsky는 Graph 호환 서브그래프 호스팅과 실시간 데이터 스트리밍을 위한 자체 Mirror 파이프라인 시스템을 모두 제공합니다. 표준 GraphQL 쿼리가 제공하는 것 이상의 커스텀 비즈니스 로직을 갖춘 멀티체인 인덱싱이 필요한 팀에 적합합니다.

### Chainstack

[Chainstack](https://chainstack.com/)은 관리형 서비스로서 Subgraphs를 제공하는 엔터프라이즈급 블록체인 인프라 제공업체입니다. 보장된 업타임 SLA, 저지연 쿼리를 위한 글로벌 CDN 배포, 전용 지원 채널을 갖춘 안정적인 인덱싱을 제공합니다. 이 플랫폼은 Ethereum과 EVM 호환 체인을 지원하며, Chainstack의 더 넓은 노드 인프라 서비스와 통합됩니다. Chainstack은 엔터프라이즈 지원, 규정 준수 기능, 예측 가능한 확장성이 필요한 조직에 특히 강점을 가집니다.

## 프로젝트에 맞는 인덱서를 선택하는 방법

적합한 인덱서를 선택하는 것은 여러분의 구체적인 요구사항에 달려 있습니다. 고려해야 할 주요 요소들은 다음과 같습니다:

**1. 체인 호환성** 인덱서마다 지원하는 블록체인 생태계가 다르므로, 선택한 인덱서가 구축하려는 체인을 지원하는지 확인하세요. 일부는 Solana처럼 특정 네트워크에 특화되어 있고, 다른 일부는 EVM 호환 체인에 집중하거나 광범위한 멀티체인 커버리지를 제공합니다.

**2. 쿼리 요구사항** 인덱서마다 필요에 따라 다른 쿼리 인터페이스를 제공합니다: 유연한 중첩 쿼리를 위한 GraphQL, 단순하고 미리 정의된 엔드포인트를 위한 REST, 분석 워크로드를 위한 SQL, 실시간 스트리밍을 위한 WebSocket. 애플리케이션이 데이터에 어떻게 접근할지 고려하고 해당 패턴을 지원하는 인덱서를 선택하세요.

**3. 성능 요구사항** 지연 시간과 처리량 요구사항을 신중히 고려하세요. 일부 인덱서는 실시간 애플리케이션을 위한 속도를 우선시하고, 다른 인덱서는 포괄적인 과거 데이터 접근이나 대용량 분석 쿼리에 집중합니다.

**4. 인프라 철학** 운영 부담은 줄지만 벤더 의존성이 생기는 완전 관리형 서비스를 원하는지, 아니면 검열 저항성은 제공하지만 더 많은 설정과 유지보수가 필요한 탈중앙화 프로토콜을 원하는지 결정하세요.

**5. 비용 구조** 대부분의 인덱서는 개발용 무료 등급, 성장 중인 프로젝트를 위한 사용량 기반 요금제, 프로덕션 워크로드를 위한 엔터프라이즈 플랜 등 단계별 가격 정책을 제공합니다. 장기 비용을 예측할 때 예상 쿼리 볼륨과 데이터 반출 수수료를 고려하세요.

**6. 개발자 경험** 문서의 품질, 선호하는 프로그래밍 언어에 대한 SDK 지원, 커뮤니티 자료의 가용성을 평가하세요. 강력한 개발자 지원과 명확한 예제는 통합 시간을 크게 줄여줄 수 있습니다.

**7. 데이터 특화도** NFT 마켓플레이스나 Solana 애플리케이션 같은 특정 사용 사례의 경우, 특화된 인덱서가 범용 솔루션보다 더 풍부한 즉시 사용 가능한 데이터를 제공하는 경우가 많습니다. 여러분의 도메인에 맞게 미리 보강된 데이터가 상당한 개발 노력을 절약해줄지 고려해보세요.

## 결론

대규모로 온체인 데이터를 다루는 것은 어려운 문제입니다. 블록체인은 현대 애플리케이션이 필요로 하는 종류의 쿼리를 위해 만들어지지 않았습니다. 수백만 개의 트랜잭션에 걸쳐 검색, 필터링, 집계를 하려면 적절한 인프라 없이는 앱이 멈춰버릴 것입니다.

인덱서는 이러한 문제를 해결하기 위해 무거운 작업을 대신 처리합니다: 블록체인 데이터를 지속적으로 처리하고, 쿼리 가능한 형식으로 정리하며, 빠른 API를 통해 제공합니다. 이를 통해 여러분은 데이터 파이프라인과 블록체인 노드와 씨름하는 대신 훌륭한 애플리케이션을 만드는 데 집중할 수 있습니다.

시작할 준비가 되셨나요? Alchemy는 블록체인 개발을 간단하게 만들어주는 포괄적인 도구 모음과 보강된 API를 제공합니다. [Alchemy 문서](https://www.alchemy.com/docs/)를 확인하고 개발을 시작해보세요.

## 자주 묻는 질문

### 블록체인 인덱서란 무엇인가요?

블록체인 인덱서는 블록체인을 지속적으로 모니터링하고, 트랜잭션 데이터와 스마트 컨트랙트 이벤트를 추출하며, 이를 구조화된 형식으로 변환한 뒤, 빠른 쿼리에 최적화된 데이터베이스에 저장하는 특수한 서비스입니다.

### 블록체인 인덱서는 어떻게 작동하나요?

인덱서는 세 단계 프로세스를 따릅니다: 추출\(블록체인 노드를 실시간으로 모니터링\), 변환\(원시 블록체인 데이터를 디코딩하고 상태 변화를 정리\), 적재\(처리된 데이터를 애플리케이션이 사용할 수 있는 API와 함께 쿼리 가능한 데이터베이스에 저장\).

### 블록체인 인덱서의 주요 구성 요소는 무엇인가요?

핵심 구성 요소로는 데이터 소스\(블록체인 연결\), 인덱싱 엔진\(트랜잭션과 이벤트를 디코딩하는 처리 계층\), 데이터베이스\(PostgreSQL이나 MongoDB 같은 저장 계층\), API 계층\(GraphQL, REST, 또는 WebSocket을 사용하는 쿼리 인터페이스\)이 있습니다.

### 왜 블록체인 데이터를 직접 쿼리할 수 없나요?

블록체인은 데이터를 보안에 최적화된 선형 블록 체인 형태로 저장하며, 빠른 검색을 위한 것이 아닙니다. 내장된 SQL이나 인덱싱이 없어서, 특정 데이터를 찾으려면 수백만 개의 블록을 하나씩 스캔해야 하며, 이는 몇 시간에서 며칠까지 걸릴 수 있습니다.

### 블록체인 인덱서는 개발자를 위해 어떤 문제를 해결하나요?

인덱서는 몇 시간 걸리던 블록체인 스캔을 밀리초 단위의 쿼리로 바꿔주고, 대규모 데이터셋에 걸친 실시간 분석과 집계를 가능하게 하며, 블록체인 앱이 전통적인 웹 애플리케이션만큼 반응성 있게 느껴지도록 하는 푸시 기반 아키텍처를 제공합니다.

### 블록체인 인덱서의 일반적인 사용 사례는 무엇인가요?

인기 있는 애플리케이션으로는 DeFi 대시보드와 포트폴리오 추적기, 온체인 분석 플랫폼, 트레이딩 봇, 현대적인 지갑, 블록체인 탐색기, 크로스체인 브릿지 등이 있습니다.

### 프로젝트에 맞는 인덱서는 어떻게 선택하나요?

체인 호환성, 쿼리 요구사항\(GraphQL vs REST vs SQL\), 성능 요구사항, 인프라 철학\(관리형 vs 탈중앙화\), 비용 구조, 개발자 경험의 품질, 그리고 사용 사례에 특화된 데이터가 필요한지 여부를 고려하세요.

### 인덱서와 풀 노드를 운영하는 것의 차이는 무엇인가요?

풀 노드는 전체 블록체인을 저장하고 직접 쿼리하려면 많은 리소스가 필요한 반면, 인덱서는 데이터를 미리 처리하고 최적화하여 API를 통해 1초 미만의 조회를 가능하게 하며, 느린 수동 블록체인 스캔의 필요성을 없애줍니다.