gRPC와 REST API의 차이점을 설명해주세요.

gRPC와 REST API는 서비스 간 통신을 구현하는 대표 방식입니다. REST는 HTTP 리소스와 JSON 중심의 범용 API 스타일이고, gRPC는 Protocol Buffers와 HTTP/2를 기반으로 한 고성능 RPC 프레임워크입니다.

핵심 개념

• REST는 URL, HTTP method, status code를 활용해 리소스를 표현합니다.
• gRPC는 .proto 계약에서 서비스와 메시지 타입을 정의하고 코드를 생성합니다.
• gRPC는 unary뿐 아니라 server/client/bidirectional streaming을 자연스럽게 지원합니다.

동작 방식 또는 판단 기준

이 주제를 이해할 때는 다음 순서로 보면 실무 적용이 쉬워집니다.

1. 무엇을 해결하려는가: 성능, 표현력, 안정성, 접근성 중 어떤 문제를 줄이려는지 확인합니다.
2. 전제 조건은 무엇인가: 정렬 여부, 브라우저 지원, 네트워크 특성, 동시성 조건처럼 성립해야 하는 조건을 점검합니다.
3. 비용은 어디서 발생하는가: 시간 복잡도, 메모리, 캐시, 재시도, 렌더링 비용처럼 병목 지점을 나눠 봅니다.
4. 실패 시 어떤 문제가 생기는가: 잘못 적용했을 때의 버그나 운영 리스크를 함께 고려합니다.

실제 예시

syntax = "proto3";

service UserService {
  rpc GetUser(GetUserRequest) returns (User);
}

message GetUserRequest { string id = 1; }
message User { string id = 1; string name = 2; }

GET /users/123 HTTP/1.1
Accept: application/json

HTTP/1.1 200 OK
{ "id": "123", "name": "Kim" }

실무에서 주의할 점

• gRPC는 브라우저 직접 호출이 제한적이어서 gRPC-Web이나 gateway가 필요할 수 있습니다.
• REST는 사람이 읽기 쉽고 도구 생태계가 넓지만, 스키마 강제와 타입 안전성은 별도 OpenAPI 관리가 필요합니다.
• gRPC는 binary 포맷이라 디버깅이 낯설 수 있고, API 공개용으로는 진입 장벽이 있습니다.

실무 적용 가이드

• 외부 공개 API와 간단한 CRUD는 REST가 무난합니다.
• 내부 마이크로서비스 간 고성능/타입 안전/스트리밍이 중요하면 gRPC를 고려합니다.
• 계약 변경은 backward compatibility와 버전 정책을 반드시 관리합니다.

함께 연결해서 보면 좋은 키워드

gRPC, REST, Protobuf, HTTP/2, API Design

정리

gRPC와 REST API는 서비스 간 통신을 구현하는 대표 방식입니다. 다만 개념 자체보다 중요한 것은 적용 조건과 한계를 함께 이해하는 것입니다. 작은 예제에서는 단순해 보여도 실제 서비스에서는 성능, 보안, 유지보수성, 접근성 요구사항이 함께 얽히므로, 문제의 성격을 먼저 파악한 뒤 적절한 도구로 선택하는 것이 좋습니다.