![[BlockChain] 도대체 왜 REST 대신 RPC를 쓸까? (개념부터 노드 통신까지)](/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fattachment%253A5e6a2455-d6bd-48ce-9574-86c7d69a3a19%253A19.png%3Ftable%3Dblock%26id%3D2bb9c76c-6cb4-8086-ada8-e0b3982a5e17%26spaceId%3Db4216657-966f-4c29-ae8c-42f6c4adb66d&w=3840&q=75)
개요
우리가 처음 블록체인을 공부하다보면 머릿속에 잘 그려지지 않는게 있더라구요. 바로 도대체 어디다가 요청을 보내고 응답을 받아야 되는 건지에서 부터 풀리지 않아서, 전체 블록체인의 그림이 그려지지 않더라구요. 그래서 이 블로그에서는 도대체 RPC가 뭔지 그게 어떻게 Rest API랑 다른 것인지 한 번 알아보고, 나아가 JSON-RPC와 노드 프로바이더가 왜 필요한지에 대해서 심층적으로 알아보도록 할게요.
RPC는 무엇인가?
사실 개발을 하는 개발자 입장에서는 RPC와 REST API를 정보를 요청하면 정보를 받는 커뮤니케이션 도구로서 비슷한 역할을 하고 있어요. 그래서 종종 헷갈리죠, ‘아니 둘 다 비슷한 거 같은데 왜 REST를 굳이 안쓰고 RPC를 쓰는걸까?’ (처음에 제가 했던 생각이에요.ㅎ)
일단 쉽게 생각해보면 RPC(Remote Procedure Call)의 이름 그대로 ‘원격 (Remote)’에 있는 함수(Procedure)를 호출(Call)’하는 것이에요.
내 컴퓨터에서 사용하지만, 실제 실행은 멀리 있는 다른 컴퓨터 (서버 혹은 노드)에서 마치 내 옆에 있는 함수처럼 실행되게 만드는 기술이에요. 그래서 웹 개발에서 흔히 쓰이는 REST가 자원을
URL 로 가리키는 것에 집중한다면, RPC는 동작(Action) 그 자체에 집중한다고 생각하면 돼요.RPC와 REST API의 차이점
하지만 URL과 Action만으로는 차이점을 제대로 설명할 순 없죠. 결정적으로 개발자들이 느끼는 차이점을 3가지로 한번 정리해볼게요.
1. 창구의 갯수가 다르다: “여러개의 문” vs “하나의 문”
눈에 띄는 차이는 '엔드포인트(Endpoint)'입니다. REST API로 서비스를 만든다면
/users, /products, /orders 처럼 수많은 URL이 존재합니다. 지도를 보듯 각 주소를 다 알아야 하죠.반면, RPC(특히 이더리움 JSON-RPC)는 단 하나의 URL만 사용해요. 노드 프로바이더가 준 주소 딱 하나만 알면, 그곳으로 잔액 조회도 보내고, 송금 요청도 보내고, 블록 정보도 요청하죠. 주소 고민 없이 "요청 내용"에만 집중하면 되는 구조에요.
2. 말하는 방식이 다르다: “HTTP 메서드” vs “함수 이름”
REST에서는 HTTP프로토콜을 따르기 때문에 각 행위에 대한 약속된 동사(
GET, POST, PUT, DELETE)를 사용해야돼요. 반면 RPC는 대부분
POST 만 사용하고 본문안에 실제 하고 싶은 행동을 적어줘야 돼요. 왜 이렇게 해야하는지는 다음 항목에서 다루어 볼 것이지만, 핵심만 간단하게 말씀드리자면 블록체인의 특성 때문이라고만 언급하고 넘어갈게요. 3. 결과 확인 방식이 다르다 : ‘상태 코드’ vs ‘에러 코드’
REST는 성공하면 200, 없으면 400, 서버 에러면 500 등 HTTP 상태 코드로 결과를 판단할 수 있는 거 다들 아실거에요.
하지만 RPC는 “통신 자체는 성공했네? 그럼 일단 200으로 반환!” 하는 경우가 많아서 반드시 응답 본문 안의
error 필드를 확인해야 해요. 이 부분이 처음에 많이들 헷갈리는 부분이더라구요. 블록체인 개발자는 항상 RPC 요청에서 응답 본문을 확인하는 습관을 들여야 해요!왜 RPC는 POST요청만 사용하는 가??
앞선 항목에서 RPC가 POST 요청만 사용하고, 상세한 요청 내용은 본문에 적어 요청한다고 말씀드렸었죠. 그럼 왜 이렇게 했어야만 속이 시원했을까요?! 이는 블록체인의 특성상 REST라는 옷이 맞지 않기 때문이에요.
일단 RPC가 제공해야 하는 일은 CRUD보다 훨씬 많기 때문이에요. 그럼 CRUD가 어디서 왔냐? 또 왜 애초에 이렇게 했어야 하느냐?는 기본적으로 중앙 서버는 데이터베이스를 사용하기 때문이었죠. 그렇기 때문에 데이터베이스에 특화된 HTTP요청을 프로토콜로 사용했던 거에요.
REST API는 기본적으로 데이터 베이스의 CRUD에 최적화 되어있기 때문에 HTTP의 4개의 동사로도 충분했어요. 하지만 블록체인, 특히 스마트 컨트렉트는 달라요. 주로
투표하기, 토큰 교환, 예치, 이자 수령, 민팅 등등 수만 가지 동작을 해야해요. 이 다양한 동작들을 4개의 동사에 끼워맞추는 것이 매우 어려워 진 것이죠. 그래서 어떤 동작을 할지를 HTTP헤더가 아닌 본문(Body)에 자유롭게 적을 수 있도록 한 것 이에요. HTTP말고도 다른 길도 필요하다.
RPC를 사용하는 결정적 이유 중 하나는, HTTP말고도 다른 길이 필요하기 때문이에요. 주로
Websocket 으로 블록 생성을 실시간으로 감지 할 때 사용하거나, IPC (Inter-Process Communication) 같이 컴퓨터 내부에서 빠르게 통신하기 위한 길이 필요해요. 그리고 이 WebSocket과 IPC에는 GET이나 POST같은 개념이 없어요. 쉽게 비유하자면, 웹소켓이나 IPC는 이미 연결된 전화라고 생각해볼게요. 두 개체가 연결이 되어있는데 갑자기 전화를 건 사람이 “지금 부터는 요청(GET)입니다.” “지금부터는 전송(POST) 입니다” 라고 하지 않잖아요? 그냥 서로 필요한 말만 주고받으면 되는거니깐요. 그래서 이 처럼 연결이 유지가 되는 환경에서는 헤더에 요청 메서드를 붙일수가 없어요. 그래서
어떤 환경이든 상관없이 본문안에 함수를 직접 적어 보내는 방식이 필요했던 것이죠. 그래서 소통할 수 있는 공통 언어가 필요해진 것이에요. JSON-RPC: 컴퓨터들 끼리의 대화 규칙
앞서 말씀드린 대로, 블록체인 노드와 대화할 때는 전송 수단에 구애받지 않는 ‘공통 언어’가 필요해 졌고, 이더리움 생태계에서는 그 표준으로
JSON-RPC 2.0을 채택했어요.쉽게 말해, “데이터를 주고 받을 때 이렇게 생긴 JSON 포맷을 쓰자!”라는 약속을 한거죠. 그래서 우리가 요청을 보낼 때, 이 약속에 따라서 반드시 포함해야하는 4가지 핵심 정보가 있어요.
jsonrpc: “나 지금 2.0 버전 규칙 쓰고 있어!” (버전 명시)
method: “이 함수 실행해줘!” (하고 싶은 행동 명시)
params: “이 재료를 사용해줘” (지갑주소, 블록 번호 등)
id: “이건 1번 주문서야!” (내 요청을 구분하는 번호)
백문이 불여일견이니, 실제 우리가 노드로 보내는 요청 메시지는 아래와 같이 생겼어요.
JSON
{
"jsonrpc": "2.0", // 1. 버전
"method": "eth_getBalance", // 2. 함수 이름 (잔액 조회)
"params": [ // 3. 파라미터 (지갑 주소, 시점)
"0x407d73d8a49eeb85d32cf465507dd71d507100c1",
"latest"
],
"id": 1 // 4. 요청 ID
}어떤 가요? 생각보다 단순하죠? 개발자 라이브러리(ethers.js 등)를 쓸 때 내부적으로는 항상 이런 모양의 JSON데이터가 노드로 날아가고 있었던 거에요. 우리는 그동안 라이브러리 덕분에 이 과정을 몰랐을 거에요.
이젠 우린 보내는 편지(JSON)가 어떻게 생겼는 지 알게되었어요. 그럼 이 편지를 누구한테 실제로 보내야 하는 걸까요? 여기서
노드 프로바이더가 등장하게 돼요!노드 프로바이더는 왜 쓰는가?
원칙적으로 블록체인 네트워크에 접속해서 데이터를 읽거나 쓰려면, 내 컴퓨터도 블록체인 네트워크의 일원(노드)이 되어야 해요. 즉 이더리움 클라이언트(Geth 등)를 직접 설치하고 실행해야된 다는 말이죠. 하지만 현실적으로 개인이 직접 노드를 운영하는 건 상당히 번거로운 일이에요. 왜일까요?
- 이더리움 전체 장부 데이터를 받으려면 2TB이상의 SSD가 필요해요.
- 처음 동기화하는 데만 며칠, 혹은 몇 주가 걸릴 수도 있어요.
- 24시간 내내 컴퓨터를 켜놔야 하고, 네트워크 업그레이드 때마다 소프트웨어를 업데이트 해줘야 해요.
우린 당장 Dapp을 만들고 테스트 해야하는데, 노드 설치하다가 지쳐 떨어질 수도 있는 거죠ㅠ. 그래서 등장한 것이
노드 프로바이더에요! 대표적으로 Infura, Alchemy, QuickNode 같은 서비스들이에요.쉽게 비유하자면, 전기를 쓰기 위해서 발전소를 짓는게 아니라 콘센트만 꽂아서 전기를 사옹하는 것과 같아요. 그래서
Node Provider들은 우리가 사용할 수 있게 RPC-URL에 JSON-RPC로 요청하기만 되는 거에요. 그럼 우린 마치 내 컴퓨터에 노드가 있는 것 처럼 자유롭게 블록체인과 대화할 수 있게 되는거에요.읽기와 쓰기의 결정적 차이
이제 어디(
RPC-URL)로 어떤 내용(JSON-RPC)으로 요청을 할 수 있는지 알게 되었는데요. 이제 요청을 보낼려고 하면 REST API에 익숙한 저희들을 당황하게 만드는 마지막 관문이 있어요.바로
읽기와 쓰기의 프로세스가 완전히 다르다는 것이에요. REST에서는 GET이든 POST든 서버가 처리하고 응답을 주는 과정이 비슷했지만, 블록체인 RPC에서는 “전 세계의 장부를 다 고칠 것이냐, 아니면 그냥 보기만 할것이냐”를 결정짓는 차이 때문이에요.읽기 작업을 우리가 노드에 요청을 한다고 생각해볼게요. 요청을 받은 노드는 이미 블록체인 데이터를 동기화해서 가지고 있기 때문에, 다른 네트워크에 물어볼 필요없이 자기 하드 디스크에 있는 데이터만 보고 알려주면 끝이에요. 그래서
가스비가 발생하지 않고 빠른 응답을 받을 수 있어요. 반면 쓰기 작업은 블록체인의 상태를 영구적으로 바꿔야 하는 작업이 필요해요. 그래서 노드 나 혼자만 바꾸면 안되고, 전 세계에 있는 모든 노드가 ‘이거 맞아!’하고
합의하는 과정이 필요해요. 그래서 채굴자에게 수수료(가스비)도 줘야하고 블록에 담길 때까지 기다려야하기 때문에 응답이 느려요. 비유를 하자면, 도서관 책을 읽는 것은 비용이 들지 않는데, 책의 내용을 수정할려면 다시 출판하는 작업이 필요하다고 생각하면 좋을 것 같아요.
마무리
지금까지 블록체인 개발의 기초이자 핵심인 RPC에 대해서 알아보았어요. 이러한 원리를 공부를 한다는 것은 나중에 복잡한 에러를 만났을 때 대처하는 능력에서 큰 차이를 만든다고 생각해요. 만약 RPC관련 문제 였다면 ‘내가 보낸 JSON 파라메터에 문제가 있엇나?’ 또는 ‘가스비가 부족해서 트랜잭션이 멈췄나?’하고 바로 문제의 본질에 접근할 수 있을 테니까요.
요즘 같이 AI가 많은 걸 해주는 세상에서 가면 갈수록 개발자의 디버깅능력이 중요해지는 만큼, 이런 원리 공부가 더더욱 필요하지 않나 생각하게 되네요! 다음에도 더 좋은 내용으로 찾아뵐게요! 읽어주셔서 감사해요!
