gRPC 알아보기

 

gRPC란 무엇인가

 

서버 개발을 하다 보면 결국 같은 문제에 부딪힌다.

 

“서버끼리 어떻게 대화할까?”

 

앱 → 서버

서버 → 다른 서버

서버 → 분석 시스템

 

이 모든 통신에는 방식이 필요하다. 우리가 가장 익숙한 방식은 REST API다.

 

하지만 규모가 커지면 REST가 조금 버거워지는 순간이 온다.

이때 자주 등장하는 기술이 gRPC다.

 

---

 

먼저 REST부터 생각해보자

 

대부분의 서비스는 이런 식으로 동작한다.

 

앱이 서버에 요청을 보낸다.

POST /login
{
  "email": "user@email.com",
  "password": "1234"
}

서버는 JSON을 읽고 처리한 뒤 응답을 보낸다.

{
  "success": true,
  "user_id": 1234
}

이 방식의 특징은 다음과 같다.

 

• HTTP 사용
• JSON 데이터
• URL 기반 API

 

이게 바로 REST API다.

 

많은 서비스가 이 방식으로 잘 돌아간다.

 

그런데 서비스가 커지면 문제가 하나 생긴다.

 

서버끼리 통신이 많아진다.

 

예를 들어 이런 구조다.

API 서버
  ├ 유저 서비스
  ├ 결제 서비스
  ├ 포인트 서비스
  └ 어뷰징 탐지 서비스

이 모든 서버가 서로 REST API로 통신하면 다음 문제가 생긴다.

 

• JSON이 커서 느림
• HTTP 요청 비용 증가
• API 관리 복잡

 

그래서 등장한 것이 gRPC다.

 

---

 

gRPC를 한 문장으로 설명하면

 

gRPC는

 

“다른 서버의 함수를 직접 호출하는 것처럼 통신하는 기술”이다.

 

REST는 이런 느낌이다.

URL 요청 → 서버 처리

gRPC는 이런 느낌이다.

함수 호출 → 서버 실행

예를 들어 서버에 이런 기능이 있다고 생각해보자.

 

Fraud 검사

 

REST 방식이라면 이렇게 호출한다.

POST /fraud/check
{
  "user_id": 123,
  "ip": "1.2.3.4"
}

gRPC에서는 이렇게 된다.

FraudService.Check(user_id, ip)

마치 다른 서버의 함수를 호출하는 느낌이다.

 

그래서 이름도 RPC (Remote Procedure Call)다.

 

Remote = 원격

Procedure Call = 함수 호출

 

즉

 

원격 서버의 함수를 호출하는 방식

 

---

 

gRPC가 빠른 이유

 

여기에는 기술적인 이유가 있다.

 

 

1. JSON 대신 Protobuf 사용

 

REST는 보통 JSON을 사용한다.

{
  "user_id": 123,
  "ip": "1.2.3.4"
}

gRPC는 Protocol Buffers (protobuf) 라는 형식을 사용한다.

 

이건 바이너리 데이터다.

 

장점은

 

• 데이터 크기가 작다
• 파싱 속도가 빠르다

 

즉 네트워크 비용이 줄어든다.

 

---

 

2. HTTP/2 사용

 

REST는 보통 HTTP/1.1을 사용한다.

 

gRPC는 HTTP/2를 사용한다.

 

HTTP/2는 다음 기능이 있다.

 

• 하나의 연결에서 여러 요청 처리
• 헤더 압축
• 스트리밍

 

그래서 대량 요청 처리에 유리하다.

 

---

 

gRPC는 어떻게 사용하는가

 

gRPC는 먼저 서비스 정의 파일을 만든다.

 

이 파일을 proto 파일이라고 한다.

 

예시:

service FraudService {
  rpc CheckFraud (FraudRequest) returns (FraudResponse);
}

message FraudRequest {
  string user_id = 1;
  string ip = 2;
}

message FraudResponse {
  int32 risk_score = 1;
}

이걸 보면 구조가 보인다.

FraudService
   └ CheckFraud()

즉

 

CheckFraud라는 함수를 원격 서버에서 실행한다.

 

그리고 놀라운 부분이 하나 있다.

 

이 proto 파일을 기반으로

 

• 서버 코드
• 클라이언트 코드

 

를 자동 생성한다.

 

그래서 개발자는 이렇게 사용한다.

fraudClient.CheckFraud(request)

이렇게 하면 내부적으로 gRPC 요청이 날아간다.

 

---

 

gRPC는 언제 사용하는가

 

gRPC는 주로 서버끼리 통신할 때 사용한다.

 

대표적인 예는 마이크로서비스 구조다.

API Server
   ├ User Service
   ├ Payment Service
   ├ Point Service
   └ Fraud Service

이 서비스들이 서로 통신해야 한다.

 

이때 gRPC를 사용하면

 

• 빠르고
• 타입 안전하고
• 관리가 쉽다

 

그래서

 

대형 서비스들이 많이 사용한다.

 

예를 들어

 

• Google
• Netflix
• Square
• Cloudflare

 

같은 회사들이 내부 통신에 사용한다.

 

---

 

어뷰징 방지 시스템에서 gRPC

 

어뷰징 탐지는 속도가 중요하다.

 

예를 들어 이런 상황이다.

 

유저가 포인트를 적립한다.

유저 행동
   ↓
API 서버
   ↓
어뷰징 검사
   ↓
허용 / 차단

이 과정이 느리면 서비스가 느려진다.

 

그래서 보통 어뷰징 로직을 별도 서비스로 분리한다.

API Server
   ↓
Fraud Detection Service

이때 gRPC를 사용하면

 

• 응답 속도 빠름
• 많은 요청 처리 가능
• 서비스 구조 분리

 

장점이 생긴다.

 

특히 이런 작업에 잘 맞는다.

 

• Risk score 계산
• IP 평판 검사
• 디바이스 검사
• 이메일 위험도 검사

 

---

 

정리

 

gRPC를 한 문장으로 다시 정리하면 이렇다.

 

“서버끼리 빠르게 함수 호출 방식으로 통신하는 기술”

 

REST와 비교하면

항목	REST	gRPC
데이터	JSON	Protobuf
속도	보통	빠름
통신 방식	URL	함수 호출
주 사용처	외부 API	내부 서비스

그래서 대부분의 시스템은 이렇게 구성된다.

외부 API → REST
내부 서비스 → gRPC

즉

 

외부에는 REST, 내부에는 gRPC

 

이 구조가 가장 흔하다.

 

흥미로운 사실 하나.

 

Google 내부에서는 오래전부터 RPC 기반 시스템을 사용해왔다.

gRPC는 그 연구의 공개 버전이다.

 

대규모 시스템에서는 결국 같은 결론에 도달한다.

 

“네트워크가 느리다.”

 

그래서 사람들은 계속해서

더 빠른 통신 방법을 발명한다.

 

gRPC도 그 진화의 한 단계다.