Request

Request란 무엇인가?

Request는 오픈 소스 암호화폐 결제 요청 및 정산(조정) 프로토콜로, 기업 또는 사용자가 서명된 인보이스 형태의 결제 요청을 생성하고, 그 요청 데이터를 탈중앙화 인프라에 저장하며, 자금의 커스터디를 결제 프로세서에게 넘기지 않고도 이후의 온체인 결제를 해당 요청과 매칭할 수 있게 해준다. 이 프로토콜이 해결하는 핵심 문제는, 많은 지갑과 결제 게이트웨이가 이미 수행하는 추상적인 “토큰 이동” 자체가 아니라, 결제를 둘러싼 검증 가능한 회계 객체를 만드는 것이다. 즉, 누가 결제를 요청했는지, 얼마를 청구했는지, 어떤 통화나 회계 단위가 사용되었는지, 어디에서 정산이 이루어졌는지, 그리고 결제가 자동으로 탐지·조정될 수 있는지 등을 명확히 하는 데 초점을 둔다.

따라서 프로토콜의 실질적인 경쟁우위는 L1 합의 레이어 자체가 아니라 워크플로 통합에 있다. Request는 서명된 결제 요청, IPFS 스토리지, 온체인 CID 앵커링, 결제 레퍼런스 이벤트, 웹훅, API 툴링, 멀티체인 결제 라우팅 등을 결합해 재무 백오피스의 기초 구성 요소(프리미티브)를 만든다. 이는 Request Network 문서와 프로토콜 개요에 설명되어 있다. docs.request.network

Request는 지배적인 레이어 1, 롤업, 대형 DeFi 머니마켓이 아니다. 암호화 인보이싱, 결제 탐지, 정산(조정)을 중심으로 한, 비교적 틈새적인 결제 및 개발자 도구용 애플리케이션 레이어이다.

2026년 5월 말 기준, 시장 데이터 제공업체들은 REQ를 시스템적으로 중요한 암호자산이 아닌 중소형 시가총액 토큰 범주에 분류했다. CoinMarketCap에서는 Request가 약 384위 전후에 위치했으며, CoinGecko와 DeFiLlama는 유통량 산정 방식과 시점 차이로 인해 서로 상당히 다른 시가총액 수치를 보고했다. 이 유형의 프로토콜에 대해 TVL 지표는 한계가 있다. DeFiLlama의 Request Network 페이지는 전통적인 대출/AMM TVL 수치 대신 재무 및 토큰 시장 데이터를 제공하는데, 이는 Request가 사용자 예치 자금 풀이라기보다 결제 인프라 역할을 한다는 점과 일치한다. 보다 관련성 높은 규모 지표는 결제 처리량과 실제 비즈니스 활동이며, 재단 웹사이트는 20억 달러 이상의 처리 금액과 광범위한 스테이블코인 지원을 주장한다. 커뮤니티가 운영하는 Request Activity Dashboard는 일별 결제 건수 및 결제 금액을 추적하지만, 소비자 지갑이나 거래소와 비교 가능한 명확한 DAU/MAU 사용자 코호트 지표는 제공하지 않는다. (coinmarketcap.com)

Request는 누가 언제 설립했는가?

Request는 2017년에 Christophe Lassuyt와 Etienne Tatur가 설립했으며, 두 사람 모두 이전 핀테크 프로젝트인 MONEYTIS와 연관이 있다. Y Combinator는 Request Network를 2017년 겨울 배치의 파리 기반 기업으로, Lassuyt를 Founder/CFO, Tatur를 Founder/CTO로 기록하고 있다. 론칭 당시의 맥락은 중요하다. REQ는 2017년 ICO 사이클 동안 등장했는데, 이 시기에 많은 프로젝트가 이더리움을 단순 토큰 전송을 넘어 회계, 상거래, 비즈니스 자동화 영역으로 확장하려고 시도했다. 과거 ICO 데이터베이스에 따르면 토큰 세일은 2017년 10월에 진행되었고, 초기 토큰 공급량은 약 10억 REQ 수준이었으나, 이후 소각 및 토큰 회계 변경으로 현재 공급량은 더 낮아졌다. 이러한 “세대”는 장점과 부담을 동시에 의미한다. Request는 여러 시장 사이클을 버텨 실제 동작하는 소프트웨어를 유지해 왔지만, 초기 내러티브가 단기 채택 속도보다 앞서 나갔던 2017년형 유틸리티 토큰 프로젝트들이 흔히 안고 있는 평판 부담도 함께 지고 있다. (ycombinator.com)

프로젝트의 내러티브는 시간이 지나며 더 좁고 구체적으로 변해 왔다.

초기 프레이밍은 인보이스, 감사 추적, 무역법 준수, 글로벌 결제 요청을 위한 광범위한 탈중앙 결제 네트워크였다. 현재 제품 초점은 보다 운영 중심·실용 중심이며, 이념적 색채는 줄어들었다. API 기반 암호화폐 결제, 온체인 인보이싱, 결제 탐지, 크로스체인 라우팅, 일괄 결제, 정기 결제, 정산(조정)을 중심으로 하고 있다.

이러한 진화는 재단의 2025년 업데이트에 잘 드러난다. Request는 새로운 범용 블록체인이 되려 하기보다는, API V2, 부분 결제, 고도화된 웹훅, 암호화폐-법정화폐 워크플로우, 일괄 결제, 크로스체인 결제 기능 등을 출시했다. 제도적 관점에서 보면, “블록체인 위의 PayPal” 비전에서 재무팀, 결제 서비스 제공업체, 멀티체인 구조화 결제 기록이 필요한 크립토 네이티브 기업을 위한 미들웨어로 방향 전환을 한 셈이다. request.network

Request Network는 어떻게 작동하는가?

Request는 자체적인 작업증명(Proof-of-Work), 지분증명(Proof-of-Stake), DAG, 검증인 집합, 시퀀서, 롤업 합의 메커니즘을 보유하지 않는다. 대부분의 요청 내용은 IPFS에 저장하고, IPFS 콘텐츠 식별자를 온체인에 앵커링하며, 지원되는 정산 체인의 스마트 컨트랙트를 통해 결제를 처리하는 온체인·오프체인 하이브리드 프로토콜이다.

문서에 따르면, 요청은 Gnosis Chain에 CID를 저장하는 방식으로 생성되며, 결제는 20개 이상 지원되는 EVM 호환 체인 또는 NEAR에서 수행될 수 있다. 이후 파생 결제 레퍼런스(Reference)에 연결된 온체인 결제 이벤트를 인덱싱해 요청의 잔액을 계산한다. 기술적으로 Request는 응용 계층 프로토콜 및 개발자용 API로서, 자체적인 보안 예산을 제공하기보다는 Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon 등 외부 네트워크로부터 라이브니스와 파이널리티를 상속받는다. docs.request.network

프로토콜의 독특한 메커니즘은 결제 레퍼런스이다. 권장되는 레퍼런스 기반 모델에서는, 요청 데이터에서 파생된 고유 식별자가 블록체인 결제를 근본적인 인보이스 또는 결제 요청에 연결한다. 프록시 컨트랙트는 자금을 수취인에게 전달하고, 결제 금액과 레퍼런스를 포함하는 이벤트를 발생시키며, 서브그래프는 이후 정산(조정)을 위해 이 이벤트들을 인덱싱한다.

시스템은 네이티브 확장성 프리미티브로 샤딩이나 ZK 롤업을 사용하지 않으며, 검증 모델도 암호학적 롤업 증명 검증이라기보다는, 이벤트 인덱싱 기반 정산 + 서명된 요청 메타데이터에 가깝다. Request Node는 IPFS, 스마트 컨트랙트, The Graph를 가로지르는 게이트웨이 역할을 한다. 재단이 개발자 편의를 위해 노드를 운영하고 있지만, 프로덕션 빌더에게는 자체 노드 운영을 권장한다. 이는, 기초 요청 데이터와 컨트랙트가 오픈 소스라 하더라도 재단이 운영하는 게이트웨이와 API에 대한 의존이 중앙화 벡터가 될 수 있기 때문이다.

비공개 요청(Private Request)은 비대칭키 암호화와 AES 암호화를 추가로 사용한다. 요청 내용은 AES 키로 암호화되고, 해당 AES 키는 각 이해관계자의 공개키로 암호화된 뒤 IPFS에 저장된다. docs.request.network

req 토크노믹스는 어떤 구조인가?

REQ는 약 10억 개 규모로 처음 발행된 ERC-20 토큰이며, 공급 구조는 인플레이션형 발행 자산이라기보다는 비교적 고정된 공급과 완만한 소각 메커니즘을 가진 형태로 이해하는 것이 적절하다. 2026년 5월 말 기준, Etherscan은 ERC-20 토큰 컨트랙트를 0x8f8221afbb33998d8584a2b05749ba73c37a938a로 표기하며, 최대 총 공급량을 약 9억 9,941만 6천 REQ로 나타낸다. CoinMarketCap은 유통량을 약 7억 9,670만 REQ로, CoinGecko는 다른 유통량 수치를 제시하고 있는데, 이는 “유통” 공급량이 리저브, 브리지, 비활성 잔고를 어떻게 분류하느냐에 따라 달라지기 때문이다.

커뮤니티 대시보드는 약 58만 3천 REQ가 소각된 것으로 보고하는데, 이는 초기 공급량 대비 매우 작은 비율이다. 따라서 소각에 따른 디플레이션 효과는 존재하지만, 그 자체만으로 투자 논리의 핵심이 될 정도로 크지는 않다. (etherscan.io)

REQ의 가치 포착 메커니즘은 간접적이며, 신중하게 해석해야 한다.

문서는 요청이 저장될 때 REQ를 잠그고(락), 브리지하고, 소각할 수 있는 토큰 및 소각 메커니즘 컨트랙트를 명시하고 있다. 한편 API 문서는 API를 통해 처리된 결제에 대해 5bp(0.05%) 수준의 프로토콜 수수료를 설명하며, 주요 USD·EUR 기반 스테이블코인에 대해서는 대략 25달러 또는 25유로 수준에서 상한이 걸려 있다고 서술한다.

이는 전통적인 PoS 스테이킹 수익과는 다르며, Request가 ETH 검증인처럼 REQ 스테이킹으로 보안이 유지되는 구조도 아니다. 일부 서드파티 설명 자료는 REQ의 유틸리티를 스팸 방지, 거버넌스, 스테이킹, 수수료 할인, 독립성 등으로 묘사하지만, 최신 공식 기술 문서는 대규모 유동 스테이킹 시장, 검증인 보상 일정, REQ 보유자를 위한 반복적 발행(에미션) 프로그램 등을 전면에 내세우지 않는다.

가장 방어적인(보수적인) 토크노믹스 해석은, REQ가 상한이 있는 공급과 사용량 연동 소각 요소를 가진 레거시 유틸리티/거버넌스형 토큰이라는 점이다. 단기적으로는 프로토콜 사용성이 수동적인 토큰 보유자에게 자동으로 귀속되기보다는, 제품 레이어와 재단이 운영하는 API 서비스에 보다 직접적으로 축적될 가능성이 크다. docs.request.network

누가 Request를 사용하고 있는가?

거래소에서의 REQ 투기 거래와 실제 Request Network 사용도 간의 차이는 상당하다. 토큰 거래량은 시장 유동성과 투자자 로테이션을 반영하지만, 프로토콜 사용도는 생성된 요청 수, 탐지된 결제, 결제 처리량, API 채택, 재무 워크플로에의 통합 정도로 측정하는 것이 더 적합하다.

Request가 2025년 5월에 발표한 생태계 업데이트에서는 보고 지표의 초점을, 단순 트랜잭션 수에서 “결제 건수(number of payments)”로 명시적으로 전환했다. 인보이스 생성, 승인, 거절 등의 행위는 실제 정산 활동과 무관하게 트랜잭션 숫자만 부풀릴 수 있기 때문이다.

커뮤니티 대시보드는 지원 체인 전반의 결제 처리량과 결제 건수도 보고하지만, 이는 일별 변동성이 큰 지표이므로 안정적인 활성 사용자 수로 단정지어 해석해서는 안 된다. 섹터 관점에서 Request는 DeFi 유동성, 게임, NFT 투기보다는, 암호화폐 결제, 스테이블코인 정산, 인보이싱, 급여 지급, 회계, 재무 운용 교차점에 위치한다. request.network

가장 설득력 있는 채택 근거는 익명의 지갑 수가 아니라, 재무·크립토 운영 관련 식별 가능한 제품 및 서비스와의 통합 사례이다. Request의 2025년 생태계 업데이트에서는 Animal Social Club, intrXn, 0 Finance, Allora, Request Finance 등을 ‘액티브 빌더(active builders)’로 명시했으며, 이전 업데이트에서는 Huma Finance, BSOS, Joba Network 및 기타 생태계 참여자들도 언급되었다.

2025년 10월, Kryptos는 Kryptos Enterprise 내 인보이싱 기능을 지원하기 위해 Request Network API를 통합했다고 발표했으며, Request는 인보이스 생성, 온체인 결제, 이벤트 웹훅, 정산 기능을 제공하고 있다. 해당 발표에서는 Kryptos가 자체적으로 집계한 수치로, 등록 사용자 20만 명 이상, 초기 단계에서 온보딩된 Web3 비즈니스 50곳 이상, 그리고 수천 건의 지갑, CEX, DeFi, 체인 통합 등을 제시했다. 이러한 수치는 직접적인 REQ 보유자 채택이라기보다는 파트너 플랫폼의 규모를 보여주는 지표로 읽어야 하지만, 출처가 불분명한 파트너십 루머보다는 훨씬 실질적인 데이터다. request.network

Request에 대한 리스크와 도전 과제는 무엇인가?

Request의 규제 리스크는 거래소, 대출 프로토콜, 프라이버시 믹서 등에 비해 미묘하지만, 그렇다고 리스크가 0인 것은 아니다. 공개 검색과 검색 결과를 통해 확인 가능한 SEC 소장 텍스트 상에서는 2023년 Coinbase 및 Binance에 대한 주요 SEC 소송에서 REQ가 명시적인 토큰으로 언급되지 않았고, 2026년 5월 말 기준으로 Request Network를 직접 대상으로 한 SEC의 적극적인 소송이 널리 보도된 바도 없다.

그러나 이것이 규제 측면에서의 ‘안전지대’를 의미하는 것은 아니다. REQ는 2017년 ICO 시기에 판매되었고, 현재도 2차 시장에서 거래되고 있으며, 미국 규제 당국은 전통적으로 프로토콜 개발 자금 조달을 위해 배포된 토큰들에 대해 높은 수준의 심사를 진행해 왔다.

또한 프로토콜의 결제 비즈니스는 특히 Request가 크립토-법정화폐(crypto-to-fiat) 결제, 지갑 스크리닝, 기업 인보이싱 등을 지원하는 만큼, AML(자금세탁방지), 제재 대상 스크리닝, KYC, 스테이블코인 규제, 송금업 라이선스, 세무 보고와 같은 이슈들과도 맞닿아 있다. 중앙화 리스크 또한 이론적 수준에 그치지 않고 실무적으로 존재한다. 재단이 운영하는 API, 대시보드, 보안 결제 페이지, Request 노드, 결제 감지 인프라 등은, 비록 스마트 컨트랙트·SDK·데이터 모델은 오픈소스로 남아 있더라도, 운영상 의존성을 만들어낼 수 있다. sec.gov

경쟁은 치열한데, 이는 Request가 해결하려는 사용자 문제를 여러 방향에서 공략할 수 있기 때문이다. 전통적인 결제 프로세서는 스테이블코인 결제 기능을 추가하고 있으며, 중앙화된 크립토 결제 프로세서는 규정 준수, 차지백 정책, 법정화폐 오프램프, 머천트 대시보드를 제공할 수 있다. 지갑과 거래소는 결제 링크를 직접 추가할 수 있고, 엔터프라이즈용 크립토 회계 솔루션은 자체 스택 안에 인보이스 정산 기능을 구축할 수 있다. Web3 내부에서도 Safe, Coinbase Commerce 유사 제품, 멀티시그 트레저리 도구, 급여 플랫폼, 스테이블코인 체크아웃 제공자, 온체인 회계 대시보드, 크로스체인 라우팅 API 등은 각각 Request의 워크플로 일부를 흡수할 수 있다.

경제적 위협은, 결제 라우팅과 정산이 ‘범용 API 기능’으로 전락할 경우, Request의 5bp(5 베이시스 포인트) 수수료와 REQ 소각 연동 구조가 가격 경쟁 속에서 희석될 수 있다는 점이다. Request의 방어력은, 개발자들이 Request의 인보이스 객체, 결제 참조 표준, 정산 도구를 대체 가능한 편의 레이어가 아닌, 장기적으로 유지되는 통합 레이어로 취급하느냐에 달려 있다. docs.request.network

Request의 향후 전망은 어떠한가?

Request의 단기 로드맵은 합의 레이어의 재발명보다는 제품의 깊이에 초점을 맞추고 있는 것으로 보인다. 2025년 및 2026년 초의 검증된 문서에 따르면, API V2 마이그레이션, 크로스체인 스테이블코인 결제, 일괄 결제(batch payments), 부분 결제(partial payments), 크립토-법정화폐 워크플로, 반복 결제(recurring payments), 수수료 커스터마이징, 지갑 및 네트워크 전환 기능 개선, 더 넓은 결제 추적, API를 통한 25개 이상 체인 지원 등이 계획되어 있다. 크로스체인 결제는 특히 중요하며, 이는 실제 운영상 고통점을 해결하기 때문이다. 예를 들어, 지급인은 Optimism 상의 USDT를 보유하고 있는데 인보이스는 Base 상의 USDC를 요구할 수 있고, 재무팀은 브리지, 스왑, 가스 토큰, 정산을 수동으로 관리하고 싶어 하지 않는다.

Request의 문서에 따르면 크로스체인 결제는 USDC (USDC), USDT (USDT), DAI (DAI)를 대상으로 하며, Ethereum (ETH), Arbitrum One (ARB), Base, OP Mainnet (OP)에서 지원된다. 라우트는 거래 수수료와 처리 속도를 기준으로 순위가 매겨지며, 공개된 크로스체인 제품 페이지에 따르면 Request는 통합 결제 감지와 웹훅 로직을 유지하면서 LI.FI 라우팅을 사용한다. request.network

구조적 난제는 ‘채택 밀도(adoption density)’다. Request는 광의의 의미에서 이더리움, Visa, Stripe, 모든 스테이블코인 프로세서를 이길 필요는 없다. 대신 충분한 수의 비즈니스 애플리케이션, 회계 제품, PSP, 크립토 네이티브 재무팀이 Request의 ‘요청 및 정산 레이어’를 표준으로 삼도록 만드는 것이 중요하다. 베어 케이스는 스테이블코인 결제가 지갑, 은행, 거래소 API에 직접 내장되면서, Request가 토큰 가치 포착력이 제한된 소규모 개발자 도구에 머무를 수 있다는 시나리오다.

불리시(긍정적) 시나리오는 가격 서사만큼 과장되지는 않는다. 스테이블코인 결제가 계속 확장되고, 재무팀이 감사 가능하며 비(非)커스터디얼이고 멀티체인에 걸친 결제 기록을 요구하게 된다면, 서명된 요청, 결제 참조, 웹훅, 배치 플로우, 반복 결제, 크로스체인 라우팅을 결합한 Request의 인프라는 여전히 유효할 수 있다.

따라서 프로젝트의 미래는 투기적인 REQ 수요보다는, Request가 오랜 운영 역사를 얼마나 견고한 통합, 투명한 사용 지표, 그리고 실제 결제와의 경제적 연동 관계가 기관 투자자와 토큰 보유자에게 충분히 명확한 토큰 모델로 전환해 낼 수 있느냐에 더 크게 좌우된다.