서문
기업협업 중인 회사에서 진행중인 오픈소스 프로젝트에 참여하게 되었다. 그런데 CTO님이 REST 대신 gRPC를 써보면 경험도 되고 좋지 않겠냐고 하셨다. REST도 제대로 모르는데 gRPC?? 그게 뭐지? 하는 마음으로 하루 종일 gRPC가 뭔지, 파이썬&장고로 할 수 있는지 찾아보며 삽질을 했다.
결국 프론트와 같이 쓰려면 프론트 코드를 다 갈아 엎어야 한다는 사실을 알게 되어 gRPC를 사용하지는 못하게 되었지만, 하루를 갈아 넣은 삽질이 아까워서라도 기록을 남겨 본다.
※ 여기서 주의할 점은 앞으로 설명에서 서버-클라이언트 관계가 자주 등장할텐데, 이는 우리가 평소에 아는 프론트엔드-백엔드의 관계가 아니다. 둘 다 백엔드 서버일 수도 있다. 따라서 클라이언트는 요청을 하는 사람, 서버는 요청에 응답하는 사람으로 이해하는 것이 바람직하다.
1. REST vs RPC
개발을 공부할 때, 특히 백엔드 개발을 공부할 때 귀에 못이 박히도록 듣는 것이 RESTful API이다. REST가 무엇인지는 검색하면 산더미처럼 나올테니 자세한 설명은 생략하겠지만, REST(REpresentational State Transfer)란 웹에 존재하는 모든 자원(resorce, ex. 이미지, 동영상, 데이터)에 고유한 URI를 부여하여 자원에 대한 주소를 지정하는 방법론, 또는 규칙을 뜻한다.
RPC는 필자도 익숙하지 않은 개념인데, Remote Procedure Call의 약자로 원격지의 프로시저나 함수를 호출해서 사용하는 방식이다. 이 때 서버의 호출 규약을 미리 IDL(Interface Definition Language)를 통해 정해놓으므로, 개발자는 네트워크 통신과 관련된 코드를 신경 쓸 필요가 없다. 즉, 원격지의 함수를 내 로컬 서버의 함수를 실행하듯 실행시킬 수 있다는 뜻이다.
RPC는 위에서 설명한 것처럼, 원격의 함수를 손쉽게 실행시킬 수 있고 개발자가 네트워크 통신과 관련해서 크게 신경쓰지 않아도 되는데다가, 속도까지 빠르다는 장점이 존재하지만 코드를 익히기가 어렵다는 점과 status code 등이 없어서 디버깅이 쉽지 않다는 점 등으로 인해 현재는 REST API가 보편적으로 사용되고 있다.
하지만 갓-구글이 참여한 gRPC가 나오면서 사용하기도 쉬워지고 속도도 빠른 RPC 방식이 다시 유행하려는 조짐이 보인다.
2. RPC 기본개념
2-1. IDL
위에서도 잠깐 나왔지만 IDL을 통해 서버의 호출 규약을 정해놓고 통신을 함으로써 원격지의 함수를 로컬 함수처럼 실행할 수 있다. IDL에는 함수명, 인자, 반환값의 타입등이 정의되어 있고 이를 rcpgen 등의 컴파일러를 이용하여 스텁/스켈레톤 코드를 생성한다.
IDL에 규약이 적혀 있기 때문에 클라이언트와 서버의 언어가 다르더라도 함수를 실행시킬 수 있다.
2-2. Stub
스텁은 양쪽에서 모두 이해할 수 있는 형식으로 프로그램과 RPC런타임간에 간단한 정보를 교환하는 인터페이스 역할을 한다. 스텁은 클라이언트와 서버 양쪽에 생성되는데, 서버 쪽의 스텁을 스켈레톤이라고 한다.
RPC는 클라이언트가 서버에 요청해서 서버의 함수를 실행하는 것이므로, 클라이언트의 스텁은 매개변수를 서버에 전달해야 하는데 이 때 필요한 마셜링(Marshalling)과, 서버에서 전달받는 결괏값을 언마셜링(Unmarshalling)하는 역할을 담당하게 된다. 반대로 서버의 스텁도 클라이언트에게서 받은 매개변수를 언마셜링하고 함수의 실행 결과를 마셜링하게 된다.
3. gRPC
gRPC는 위에서 한참 설명한 RPC를, 구글 내부에서 Stubby라는 이름의 인프라로 만들어서 사용하고 있었는데 이 Stubby를 오픈소스로 공개한 것이다.
특징으로는
- HTTP/2를 사용해서 정보를 전송(REST는 보통 HTTP/1.X)
- Protocol Buffers를 IDL로 사용
- 양방향 스트리밍
등이 있다.
특히 이러한 장점을 서버/클라이언트의 언어가 다르더라도 사용할 수 있어서, 서버는 C++, 클라이언트1은 루비, 클라이언트2는 안드로이드-자바와 같이 전혀 다른 언어끼리도 소통이 가능하다.
4. 그래서 사용법은?
결국 쓸 기회가 없어서 실제로 적용해 볼 수는 없었다.
특히 장고에서 어떤 식으로 사용하는지는 gRPC를 사용하는 것이 인프라 쪽인 것 같아(추측) 정보가 거의 없고, 이 링크처럼 사용한 사람은 있지만 결국 클라이언트가 python이라 웹 개발에서 생각하는 FE/BE의 관계는 아닌 것 같다.
자료를 찾다 보니 의외로 일본 쪽에도 자료가 약간 있었는데, 특이한 글로는 프론트에서 Vue를 사용하고 백에서 python을 사용해 API 통신을 하는 글(일본어 주의)이 있었다.
그런데 gRPC를 사용해 볼 정도면 인프라와 관련된 지식이 어느정도 있는 사람일테니.. 공식문서와 stackoverflow를 통해 감을 잡을 수 있을 것이다. 글쓴이도 사용할 기회가 있다면 이 글을 수정할 예정이다.
