개요
protobuf와 gRPC라는 개념을 오랫동안 알고는 있지만, 실제로 사용 해본 것은 protobuf만 사용해 보았었다. protobuf는 많은 거부감이 있어 처음에는 이해하기가 많이 어려웠지만 프로젝트를 만들어서 테스트 해보니 protobuf란 개념 자체는 json이나, xml과 같이 하나의 직렬화 방식중 하나이란걸 알게 되니 쉬운 개념이 되었다. 하지만 protobuf란 개념은 확실히 이해를 했지만 gRPC라는 내용은 HTTP/2 라는 내용이 나오고, gRPC를 사용하기 위해서 protoc에 추가 익스텐션을 설치해야 하는 번거로움과 새로운 개념을 공부 해야 하는 내용 때문에 포기 했었다. 하지만 이번에 Go 언어를 공부 하면서 gRPC를 공부했었다. 공부하면서 내용을 정리해 보았다.
gRPC와 관한 이야기
gRPC는 protobuf 인/디코딩 방식을 통하여 다른 외부 프로그램의 함수를 원격으로 호출 시키는 방식임. [관련 내용]
실제로 사용해본 경험
[gRPC의 idl 레포지토리]에서 protobuf를 사용해본 경험으로는 기존 Restful 형식에 비해서 형태가 자유로움이 정말 좋았다. 기존 Restful의 경우 Method를 통해서 동작을 정의하고, Body에 내용을 적는 방식이다. 하지만 gRPC의 경우는 서버의 함수를 호출 하면서, 매개변수나, 반환값은 protobuf 형식으로 반환하는 방식이다. 그래서 Python 같은 언어가 아니라면 서버에 데이터를 잘못 보낼 가능성이 작다는 부분이 가장 매력적으로 느껴졌다. API가 빌드가 되고 오류가 컴파일 타임 때 잡히는것이 정말 좋은것 같다.
그 외에 gRPC는 여러가지 확장 도구가 있었는데, grpc를 json으로 변환해주는 gRPC-Gateway와 같은 다양한 확장 도구 때문에 많은 장점이 있다고 생각한다.
Github Action를 이용한 자동화
gRPC를 활용한 뱅크샐러드가 자료를 검색 했을 때 많은 자료가 나왔었다. 그래서 그 덕분에 내부적으로 어떻게 활용해야하는지, 레포지토리 구성은 어떻게 해야하는지 많은 도움이 되었다.
Github Action을 통하여 Main에 Push 트리거가 발생하게 되면 Go 언어와 Swift언어로 빌드하여 각각의 Branch에 푸시하는 자동화 시스템을 넣었다.
느낀점
장단점은 확실 하나, 내부 통신을 할 때나 개발 팀이 엄청 많고, 문서관리가 많이 힘든 경우가 아니라면 gRPC가 아닌, Rest만 이용해도 충분하다고 생각한다. 극단적으로 최적화 해야하는게 아니라면 굳이 라는 느낌이 강하다.