━━━━ ◇ ━━━━
유니티(Unity)/툴 개발

[Unity gRPC 서버 개발(1/4)] REST API & PRC 개념 정리

📌 개요

 

 

[ Unity TCP Socket 서버 개발 ]

 

[Unity TCP Socket 서버 개발(2/2)] 서버와 클라이언트 분리

📌 개요 이전 포스터에서 C# TCP Socket 통신을 통해 채팅을 구현해봤습니다. 하지만 현업에서는 주로 서버와 클라이언트를 분리해서 사용합니다.Client: Unity 프로젝트 루트 폴더 (클라이언트)Server:

gus6615.tistory.com

 

최근에 C# 서버 엔진을 오라클 클라우드에서 실행하고, Unity 클라이언트가 C# 서버 기반으로 통신하는 프로젝트를 개발한 적이 있습니다. 이때, TCP Socket 방식을 사용하여 실시간으로 클라이언트와 서버가 통신을 수행하는 프로그램을 개발하였습니다.

 

이번에는 TCP Socket 방식이 아닌, gRPC을 통한 응답 및 요청을 구현해보려고 합니다. 게임에서는 gRPC를 이용하여 유저 정보 조회, 유저 데이터 조회, 랭킹, 인벤토리 관리, 친구 목록 등 게임 컨텐츠를 제작하기 때문에 게임 개발에 필수적인 기술 중 하나입니다.

 

그래서 이번 학습 목표는 다음과 같습니다.

 

 

 

 

※ 위 사진은 이번 학습을 위한 프로젝트 아키텍처를 간단히 그림으로 나타낸 것입니다.

 

먼저 오라클 클라우드 가상머신에 gPRC 응답을 처리하는 C# 서버를 구현합니다. C# 서버에서 MySQL 데이터 조회 및 업데이트 로직을 구현하고, gRPC 서버를 이용한 로그인 및 회원가입 기능을 개발해보도록 하겠습니다.

 

하지만 그전에 gRPC가 무엇인지, REST API와 다른 점이 뭔지 정리하고 넘어가도록 하겠습니다.

 

 

 

 

 


📌 REST 란 무엇인가?

 

REST 등장 배경

 

[ 2000년대 웹의 성장과 복잡성 증가 ]

 

1990년 ~ 2000년대 당시 웹은 단순한 문서 공유를 넘어 다양한 애플리케이션과 서비스를 제공하는 플랫폼으로 발전했으며, 웹 기반 시스템들이 점점 복잡해지며 규모가 커졌습니다.

 

 

[ SOAP 기술의 한계 ]

 

REST 등장하기 전, SOAP(Simple Object Access Protocol)이라는 웹 서비스 통신 표준 기술이 있었습니다. 다만, SOAP는 XML 기반의 메시지 포맷과 HTTP, SMTP 등 다양한 프로토콜 위에서 동작하는 웹 서비스 통신 규약이었습니다. SOAP는 표준화된 프로토콜이었으며, 트랜잭션 및 보안 등 복잡한 기능을 지원하는 기술이었습니다.

 

하지만 SOAP가 지원하는 강력한 기술은 한계가 명확했습니다. XML 기반의 방대한 명세와 복잡한 구조로 인해 메시지 크기가 커지고, 파싱(Parsing) 비용이 많이 들었습니다. 이로 인해 네트워크 오버헤드가 크고 성능이 저하되는 경우가 많았아요. 또한 HTTP를 단순 통신 수단으로만 사용하여 HTTP의 강점을 살리지 못했습니다. (모든 요청을 POST 메소드만 사용)

 

 

[ REST 모델 등장 ]

 

당시 웹 창시자 중 한 명인 로이 필딩은 HTTP의 설계를 제대로 활용하고 있지 못한다고 느꼈습니다. 그래서 그는 웹의 성공 요인인 HTTP의 강점을 활용하여 REST 라는 웹 통신 아키텍처를 만들었습니다. 표준화된 HTTP 메소드를 활용하여 SOAP의 복잡성과 성능 문제를 해결하면서도, 웹의 장점을 최대한 활용할 수 있게 되었습니다.

 

 

 

 

REST API : HTTP 프로토콜을 통해 URL로 통신하는 기술

 

URL은 어떤 자원(Resource)에 대한 것만 명시하며, 메소드는 HTTP 메소드로 표현합니다.

 

이때, 클라이언트 상태를 서버에 저장하지 않습니다. (Stateless)

 

때문에 각 요청이 독립적이라 서버에 부담을 줄일 수 있습니다.

 

 

 

REST API는 HTTP URL을 통해 자원을 명시하며, HTTP 메소드를 통해 자원에 대한 처리를 정의합니다.

 

HTTP 메소드는 아래와 같습니다.

  • POST : 추가
  • GET : 조회
  • PUT : 수정 (전체를 수정)
  • PATCH : 상태 변경 (일부분만 수정)
  • DELETE : 삭제

 

표준화된 HTTP를 활용하기 때문에 빠르게 배울 수 있어 웹 애플리케이션을 개발할 때 많이 사용됩니다. 다만, 웹 서비스가 아닌 마이크로서비스 또는 고성능을 요구하는 서비스에서는 사용하기 힘들 수 있습니다. 그래서 고성능을 요구하는 게임 업계에서는 원격 프로시저 호출(RPC) 기술이 다시 각광받고 있습니다.

 

 

 

 

 


📌 gRPC란?

 

 

RPC(Remote Procedure Call) : 원격에 있는 프로시저(함수/메서드)를 호출하는 기술

 

RPC는 마치 로컬에 있는 함수를 호출하는 것처럼, 네트워크 너머 다른 컴퓨터나 프로세스에 있는 함수를 호출하고 그 결과를 받을 수 있게 해줍니다. 이를 통해 서버와 클라이언트 구조를 구현할 수 있습니다.

 

하지만 네트워크 문제가 발생하면 사용할 수 없는 기술이며, 서버와 클라이언트 간의 통신에서 메세지를 해석하기 위한 명확한 규약이 필요합니다. 이는 버전 관리의 어려움을 유발하게 됩니다.

 

gRPC는 이러한 한계점들을 개선하기 위해 Protobuf, HTTP/2 등 다양한 기술을 통해 효율적인 통신을 제공하는 RPC 프레임워크로 각광받고 있습니다.

 

 

gRPC : Google에서 개발한 오픈 소스 RPC 프레임워크

 

기존 RPC의 개념을 현대적인 마이크로서비스 아키텍처에 맞게 개선하고 최적화한 RPC입니다. 분산 시스템, 특히 마이크로서비스 간의 고성능 통신에 매우 적합하도록 설계되었습니다.

 

기존 REST와 RPC와 차별화되는 주요 기술은 다음과 같습니다.

 

 

1. Protocol Buffers (Protobuf)

 

 

gRPC는 메시지 직렬화 및 규약 명세를 정의하기 위해 Protobuf를 사용합니다. (.proto 파일로 저장)

 

위 .proto 파일을 살펴보면 Key 값마다 번호가 붙어있는 것을 확인할 수 있습니다. 이를 통해 메시지에 모든 Key를 저장하지 않아 메시지의 크기를 대폭 줄일 수 있습니다.

 

또한, 바이너리(이진) 형식으로 데이터를 직렬화하여 전송되기 때문에 용량이 줄고 성능을 높여줍니다. gRPC는 HTTP/2 프로토콜을 기반으로 병렬적으로 응답-요청을 처리합니다. TLS를 통해 데이터를 암호화하여 전송하기 때문에 보안에도 뛰어납니다.

 

 

※ .proto 파일에 Key와 필드 번호를 명시하기 때문에 중복되는 Key를 포함하여 보내지 않아 네트워크 오버헤드를 줄입니다.

 

이처럼 gRPC는 서버와 클라이언트가 호율적으로 통신하기 위한 프레임워크로 각광받고 있습니다. 이 기술은 게임 업계에서 클라이언트와 서버가 협업하면서 많이 사용되는 기술입니다. 그래서 저는 이번 기회에 gRPC 기술을 공부하며 Unity에 적용하여 공부해볼 예정이며, MySQL을 통해 유저 DB를 구축하여 로그인/회원가입 기능을 제작해보도록 하겠습니다.

 

긴 포스터를 읽어주셔서 감사합니다.

 

 

 

 

 

COMMENT