REST가 만연한 세상에서 RPC를 외치다 | RPC란?, REST vs RPC

RPC란? 

RPC는 Remote Procedure Call의 약자로 원격 프로시저 호출이라는 뜻이다. 

말 그대로 원격 서버의 프로시저를 호출하기 위한 방법이다. 

 

예를 들어 내가 유튜브에서 영상을 본다면 아마 대략적으로 다음과 같은 과정을 거칠 것이다. 

이때 유튜브 앱과 유튜브 서버가 통신하기 위해 사용할 수 있는 기술이 RPC이다. 

실제로 유튜브가 RPC로 구현되어있는지는 모른다. 그냥 큰 흐름만 봐주길 바란다.

 

REST와의 비교

위의 예제에서 유튜브 앱을 클라이언트, 유튜브 서버를 서버라고 부른다. 

클라이언트와 서버가 통신하기 위한 방법에는 REST라는 방법도 존재한다. 

 

REST는 Representational State Transfer의 약자로 상태가 없는 통신이라는 뜻이다. 

REST 기반 통신에서는 내가 얻고자하는 자원의 위치를 나타내는 URL과 HTTP 메서드를 통해 원격서버와 통신할 수 있다. 

 

반면 RPC는 stub이라는 것을 통해 통신하는데, stub에는 원격 서버와 통신하는 함수들이 구현되어 있기 때문에,

우리는 stub의 함수를 호출하여 원격 서버와 통신할 수 있다. 

 

이렇게 보면 RPC가 굉장히 비효율적으로 보일 수 있다. (실제로 더 오래된 기술이긴 하다)

서버와 직접적으로 통신하는 것이 아니라 stub을 통해 통신하기 때문이다.

 

하지만 클라이언트와 서버에 각각 Stub을 구현함으로써 통신하는 데이터에 대한 명확한 정의할 수 있다.

또한 REST는 HTTP기반이지만 RPC는 여러 프로토콜을 선택할 수 있기 때문에 REST보다 효율적이고 빠를 수 있다. 

그래서 고성능이나 복잡한 상호 작용을 요구하거나 서버와 클라이언트 사이의 명확한 통신을 원하는 경우 

RPC는 좋은 선택지가 될 수 있다. 

---

 

나는 사실 여태까지 API를 구현할 때 REST 기반의 API만 구현해보았다.

왜냐하면 시중에 나오는 대부분의 책들이 RESTful API 구현만 다루기 때문이다. 

그러다 인프런 강의에서 처음으로 RPC라는 개념을 접하게 되었고, 

도대체 RPC가 뭐야! 라는 생각으로 이 포스팅을 작성하게 되었다. 

 

다음 포스팅에서는 NextJS 프로젝트에 tRPC를 적용해보고, 

간단한 API 통신을 구현해보는 과정을 정리해보려 한다.