gRPC와 RESTful API, 언제 어떤 걸 사용 할까?

1. 서론

프론트엔드와 백엔드가 분리되는 구조가 자연스러워지면서 시스템 간 통신 방식에 대해 고민할 일이 자주 생기게 되었습니다. 저는 주로 RESTful API를 사용해왔는데, 최근에 gRPC라는 방식도 있다는 것을 알게 되었고, 어떤 특징을 가지고 있는지, 그리고 어떤 상황에서 사용하면 좋을지를 비교해보며 정리해보았습니다.

https://blog.postman.com/grpc-vs-rest/

---

2. RESTful API, gRPC란?

API(Application Programming Interface)는 서로 다른 소프트웨어 시스템이 데이터를 주고받고 기능을 사용할 수 있도록 정의된 인터페이스입니다. 특히 웹 서비스나 마이크로서비스 구조에서는 서버와 클라이언트가 통신할 수 있도록 API를 활용하게 되는데, 이때 주로 사용되는 두 가지 방식이 RESTful API와 gRPC입니다.

두 방식은 모두 서버의 기능을 클라이언트가 사용할 수 있게 한다는 목적은 같지만, 작동 방식과 철학이 다릅니다. RESTful API는 "URL을 통해 자원에 접근"하는 구조라면, gRPC는 "원격 함수 호출"의 개념에 가깝습니다.

2.1. RESTful API란?

REST(Representational State Transfer) 는 HTTP 프로토콜을 기반으로 자원을 URI로 표현하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 자원에 접근하는 구조입니다. 데이터를 주고받을 때는 주로 JSON 포맷을 사용하며, 구조가 직관적이고 브라우저와의 호환성이 뛰어납니다. 그래서 많은 웹 서비스에서 표준처럼 사용되고 있습니다.

• GET /users → 사용자 목록 조회
• POST /users → 사용자 생성
• PUT /users/1 → ID 1번 사용자 정보 수정
• DELETE /users/1 → ID 1번 사용자 삭제

 

2.2. gRPC란?

gRPC는 Google에서 개발한 고성능 RPC(Remote Procedure Call) 프레임워크입니다. 클라이언트는 마치 로컬 함수를 호출하듯 서버의 기능을 호출할 수 있고, 이때 데이터는 Protocol Buffers라는 바이너리 포맷으로 직렬화되어 전송됩니다. 이는 JSON보다 훨씬 빠르고 가볍습니다.

또한 gRPC는 HTTP/2를 기반으로 작동해, 멀티플렉싱이나 양방향 스트리밍 같은 고급 기능도 기본 지원합니다. gRPC는 네 가지 통신 방식을 지원하는데, 단순한 요청-응답 외에도 다음과 같은 스트리밍 방식이 있습니다:

• 서버 스트리밍: 클라이언트가 요청을 한 번 보내고, 서버가 여러 개의 응답을 스트리밍으로 전송합니다.
• 클라이언트 스트리밍: 클라이언트가 여러 개의 요청을 스트리밍으로 보내고, 서버는 한 번 응답합니다.
• 양방향 스트리밍: 클라이언트와 서버가 동시에 여러 메시지를 주고받을 수 있습니다.

서버와 클라이언트는 .proto 파일로 API 명세를 공유하고, 이 파일을 기반으로 자동으로 코드를 생성합니다. 클라이언트 측에는 RPC 메서드 스텁이 생성되고, 서버 측에는 서비스 구현을 위한 베이스 클래스가 생성됩니다. 이를 통해 서로의 요청과 응답 구조를 정확하게 일치시킬 수 있어, 별도의 문서를 참고하지 않더라도 안정적인 통신이 가능합니다.

 

gRPC는 기본적으로 브라우저 환경을 직접 지원하지 않기 때문에 웹 프론트엔드에서 사용하려면 gRPC-Web이라는 별도 계층이 필요합니다. gRPC-Web은 브라우저와 gRPC 서버 간의 통신을 가능하게 해주는 클라이언트-프록시 조합으로, 브라우저에서 gRPC 기능을 사용할 수 있도록 도와줍니다.

 

      

      

      

    
    

      <code />
    
// user.proto
service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}

 

gRPC는 함수 중심, REST는 자원 중심이라고 이해하시면 전체 구조가 명확해집니다.

2.3. RESTful API와 gPRC 통신 흐름

1. 엔드포인트 설계

• URI를 통해 자원을 표현합니다.
  예: /users, /products/123
• 자원에 대한 행위는 HTTP 메서드로 구분합니다.
  예: GET, POST, PUT, DELETE

2. 요청 생성

• 클라이언트는 HTTP 요청을 만들어 서버로 전송합니다.
• 보통 JSON 형식으로 데이터를 담습니다.

3. 서버 처리

• 서버는 URI와 HTTP 메서드를 기준으로 해당 자원을 처리합니다.
• 요청을 분석하고, DB나 비즈니스 로직을 실행하여 결과를 반환합니다.

4. 응답 전송

• 서버는 HTTP 응답 코드와 함께 JSON 데이터를 반환합니다.
• 클라이언트는 이를 파싱해 화면에 출력하거나 로직에 활용합니다.

2.4. gRPC 통신 흐름 요약

1. .proto 파일 정의
   • 클라이언트와 서버가 공통으로 참조할 .proto 파일을 작성합니다.
   • 서비스 이름, 메서드, 메시지 타입을 정의합니다.
2. Stub 생성
   • .proto 파일을 바탕으로 클라이언트/서버용 코드가 자동 생성됩니다.
   • 클라이언트는 이 Stub을 통해 서버 메서드를 호출합니다.
3. gRPC 통신 (HTTP/2 + Protocol Buffers)
   • 내부적으로는 HTTP/2 기반의 바이너리 통신이 이뤄집니다.
   • 데이터는 JSON이 아닌 Protocol Buffers 형식으로 전송되어 더 작고 빠릅니다.
4. 서버 처리
   • 서버는 Stub을 통해 요청을 받아 비즈니스 로직을 실행하고 응답을 반환합니다.

---

3. 공통점과 차이점

3.1. 공통점

• 클라이언트-서버 구조 기반으로 동작합니다.
• 비동기 통신을 지원합니다.
• 다양한 언어와 플랫폼에서 사용이 가능합니다.
• 보안(SSL/TLS)을 적용할 수 있습니다.
• 명세 기반의 API 문서화가 가능합니다.

3.2. 차이점

항목	RESTful API	gRPC
데이터 포맷	주로 JSON	Protocol Buffers (바이너리)
프로토콜	HTTP/1.1	HTTP/2
성능	상대적으로 느림	빠름 (직렬화/역직렬화 효율)
스트리밍	제한적	양방향 스트리밍 지원
브라우저 지원	우수	제한적 (gRPC-Web 필요)
학습 난이도	낮음	상대적으로 높음 (proto 파일, IDL 등)

---

4. RESTful API와 gRPC 선택

4.1. RESTful API를 선택하면 좋은 상황

• 브라우저 환경에서 사용해야 할 경우
• 단순한 CRUD 중심의 서비스일 경우
• 다양한 디바이스나 외부 서비스와의 연동이 필요한 경우

예: 블로그, 뉴스 사이트, 쇼핑몰 등의 웹 기반 서비스에서 사용하기 적합합니다.

4.2. gRPC를 선택하면 좋은 상황

• 마이크로서비스 간 통신이 많은 시스템
• 실시간 데이터 전달이 중요한 서비스 (예: 채팅, 영상 스트리밍 등)
• 고성능이 요구되는 내부 시스템 또는 서비스 간 통신
• 명확한 인터페이스 정의 및 자동 코드 생성이 필요한 경우

예: 실시간 게임 서버, 금융 데이터 처리, 마이크로서비스 연동 등에서 효과적으로 활용할 수 있습니다.

---

5. 마무리

RESTful API와 gRPC는 각각의 목적과 장점이 분명한 통신 방식입니다. REST는 범용성과 호환성, 사용 편의성이 강점이고, gRPC는 성능, 효율성, 그리고 요청과 응답 구조가 명확하게 정의되어야 하는 상황에서 유리합니다.

어떤 방식을 선택할지는 프로젝트의 특성과 환경에 따라 달라지며, 상황에 맞게 적절히 선택하거나 병행해서 사용하는 것이 중요하다고 생각합니다.