(이 글은 2024-01-06 미니 개발 세미나 발표 내용을 기반으로 하였습니다)
미니 개발 세미나 노션 바로가기
실제 유튜브 발표 영상 바로가기
RPC란 무엇일까요?
위키피디아에서는 RPC를 위와 같이 설명합니다. 무슨 이야기인지 잘 모르시겠죠?
그래서 제가 쉽게 정리를 해봤습니다.
RPC는 Remote Procedure Call의 약자예요. 한국어로 직역하면 원격 프로시저 호출인데요,
여기에서 프로시저라는 용어는 프로그래밍 언어에서의 함수와 비슷하다고 봐주시면 될 것 같습니다.
즉, RPC란 다른 컴퓨터에 있는 함수를, 내 컴퓨터에 있는 함수인 것마냥 호출해서 사용하는 것을 말합니다.
그리고 RPC는 하드웨어, 운영체제, 그리고 네트워킹 프로토콜과는 무관하게 사용할 수 있습니다.
그런데 우리가 익숙한, ‘일반적인’ 웹의 구조에서, 클라이언트가 요청을 보내고 서버가 응답하는 과정에서 함수는 반드시 실행된단 말이죠.
그럼 클라이언트-서버 아키텍처를 사용하는 것은 다 RPC냐는 의문이 들 수도 있습니다.
그런데 실제로는 그렇지 않고, 함수가 네트워크 상으로 완전히 노출되어 있고, 그 함수에 파라미터를 넣어서 내 로컬 컴퓨터에서 돌리는 것처럼 그대로 사용한다는 개념이 있어야 RPC라고 할 수 있을 것 같습니다.
이해를 더 돕기 위해, RPC를 사용하는 어플리케이션 단의 코드를 가져와서 더 설명해보겠습니다.
위 코드를 보시면 익숙하죠. 자바스크립트로 서버에 fetch를 날려 데이터를 받아오고 있습니다.
그렇다면 RPC를 사용한 이 코드를 보시죠.
이 코드는 RPC의 구현 프레임워크인 gRPC로 짜여져 있습니다.
구글이 만들었다고 해서 google RPC, gRPC에요. 2015년에 출시된 것으로 알고 있습니다.
이 코드에서 중요한 부분은, client.getExampleData() 부분입니다. 서버로부터 정보를 받아오기 위해, 공개된 함수인 getExampleData()를 마치 로컬의 함수인 것처럼 호출하고 있습니다.
그리고 아까 ExampleService, ExampleRequest같은 것들을 import하고 있었는데, 그런 것들은 이런 식으로 package definition file을 만들어서 정의해줘야 합니다.
RPC가 어떻게 동작하는지 더 자세히 원리를 알아볼까요.
왼쪽이 함수 실행 요청을 보내는 클라이언트, 오른쪽이 함수를 실제로 실행하는 서버입니다.
그림 왼쪽 위를 봐주세요. 클라이언트가 함수를 호출하는데, 이때 함수 이름, 입력 파라미터, 그리고 각 파라미터의 타입을 넘겨줍니다.
그러면 stub이라는 친구가 이것을 받아서 RPC 런타임에서 사용 가능한 형식으로 바꿔줍니다. 이것을 marshalling이라고 하고, 그 반대의 과정을 unmarshalling이라고 합니다.
이렇게 marshalling된 데이터는 RPC Runtime System에게 넘겨지고, 이는 클라이언트가 실행을 요청한 함수가 실제로 있는 서버에게 전달됩니다.
이때, 함수가 어디 서버에 있는지 알기 위해서, 함수와, 그 함수가 실제로 있는 서버의 네트워크 위치를 매핑한 테이블을 각각의 모든 컴퓨터들이 갖고 있게 하는 방법을 사용할 수도 있고, DNS와 비슷하게 함수와 그 실제 위치를 매핑해주는 서버를 둘 수도 있습니다.
이렇게 전달된 함수 실행 요청은, 서버 측에서 unmarshalling되어 그 요청대로 실제로 함수가 실행되게 됩니다.
그 return된 출력 파라미터는 아까와 비슷한 과정으로, marshalling된 뒤 클라이언트에게 보내져 unmarshalling 과정을 거친 후 클라이언트가 함수 실행 결과를 받아볼 수 있게 됩니다.
이런 RPC의 개념을 API 설계에 응용한 것을 RPC API라고 합니다.
RPC API는 흔히 REST API와 비교되는데요, 서버에게 보내지는 요청을 행위 중심으로 추상화할 것인지, 리소스 중심으로 추상화할 것인지의 차이입니다.
REST의 경우에는 저저번 주에 발표했던 적이 있죠. REST의 제약조건 중에 ‘자원은 하나의 식별자를 통해 식별된다’, ‘자원은 표현의 교환을 통해 다뤄진다’와 같은 제약조건이 있었는데, 자원, 즉 리소스를 중심적으로 제약조건을 서술하고 있는 것을 볼 수 있었습니다.
더 구체적인 예시를 확인해볼까요.
501번 유저에게 “Hello!”라는 메세지를 보낼 때, RPC API와 REST API를 사용하는 두 경우를 비교해봅시다.
먼저 RPC API의 경우, SendUserMessage와 같이, 마치 함수처럼 서버에게 요청을 보내고 있습니다.
아래에는 그 함수에 필요한 입력 파라미터들, userId와 message를 추가로 보내주고 있죠.
그와 반면에, REST API의 경우, 메세지를 하나의 자원으로 보고 있습니다. 501번 유저의 messages를 자원으로 보고, 그곳에 자원을 추가해줄 것을 요청하고 있죠.
정리하면, RPC API에서는 행위 중심으로 사고하여, 유저에게 메세지를 보내달라고 요청하고 있는 것이고,
REST API에서는 리소스 중심으로 사고하여, 유저의 메세지 컬렉션에 메세지 리소스를 만들어달라고 요청하고 있는 것입니다.
그렇다면 RPC API와 REST API를 사용하는 예시 사례들을 살펴볼까요?
예시 사례들에서 RPC API와 REST API 중에 어떤 것이 더 적절할지 제 생각을 말하지는 않겠습니다.
여러분들이 이 사례들을 보고, RPC API와 REST API중에서 무엇이 적절한지 스스로 생각해보시면 좋을 것 같아요.
첫 번째 예시로, 당근마켓에서 판매되는 물건들에 대한 API를 만든다고 해봅시다.
새 물건 추가, 물건 정보 세부검색, 물건 가격 업데이트, 물건 삭제와 같은 API들이 필요합니다.
새 물건을 추가할 때, REST API와 RPC API를 각각 사용한다고 하면 위와 같습니다.
RPC에서는 addItem이라는 함수에 파라미터를 넣어 요청하고 있는 것을 볼 수 있죠.
물건 세부정보 검색에서는 이렇게 API가 설계될 수 있습니다.
REST API에서는 productID를 URI의 일부로 넣었지만, RPC API에서는 파라미터로 보아 분리했죠.
RPC API에서는 HTTP 위에서 사용할 때, POST 메서드만을 사용하거나, GET POST 두 가지 메서드를 사용하는 경우가 많다고 합니다.
다음으로, 물건 가격 업데이트입니다.
아까와 비슷하죠.
다음 예시로, 슬랙 채널에서 이예찬이라는 유저를 강제추방시킨다고 해봅시다.
REST API로 이렇게 짜면 되지 않을까요?
이러면 안되겠죠.
이러면 어디로부터 추방하겠다는 건지, 유저의 계정을 완전 삭제시키고 싶다는 건지, 유저를 차단/제한하고 싶다는 것인지, 그 의도가 불분명합니다.
그럼 서버가 정확한 맥락을 이해하도록 하기 이해, 위와 같이 추가 정보들을 제공해줘야 할 것입니다.
그와 반면에 RPC API를 사용한다면 이렇게 표현할 수 있을 것입니다.
그 다음 예시로, 홈 IoT 시스템을 만든다고 해봅시다.
전등, 오븐, 에어컨 등등 여러가지 가전제품들이 있고, 그 각각마다 기능들이 있습니다.
왼쪽이 REST API를 사용한 부분이고, 오른쪽이 RPC API를 사용한 부분입니다.
정리하면 다음과 같습니다.
REST, RPC API를 언제 사용해야 할까요?
API가 주로 행동으로 이뤄진 경우에는 RPC API가 적절할 것이고,
API가 주로 데이터를 다루는 CRUD 작업일 경우에는 REST API가 적절할 것입니다.
요즘 REST API가 약간 정설처럼, 언제나 정답인 것처럼 사용되는 모습을 볼 수 있는데, 여러분들이 상황에 따라, 만들고 싶은 것이 무엇인지에 따라, RPC API와 REST API 중에 더 적합한 것을 선택해 사용했으면 좋겠습니다.
발표 마치겠습니다. 감사합니다.
References
RPC와 REST의 차이점은 무엇인가요?
About gRPC
Can gRPC replace REST and WebSockets for Web Application Communication?
FAQ - gRPC
What is Remote Procedure Call? - W3C
What’s the Difference Between RPC and REST?
Understanding RPC Vs REST For HTTP APIs
Web service differences between REST and RPC
Remote procedure call - Wikipedia
