HTTP/2 위에서 동작하는 gRPC의 와이어 형식과 호출 조건

gRPC는 원격 프로시저 호출을 위한 프레임워크이며, 일반적인 네이티브 gRPC는 HTTP/2 스트림을 사용합니다. 요청은 POST와 서비스·메서드 경로를 사용하고, content-type은 application/grpc 계열입니다. 메시지는 1바이트 압축 표시와 4바이트 big-endian 길이 필드를 앞에 붙인 프레이밍을 따릅니다. 이 메시지 경계와 HTTP/2 DATA 프레임 경계는 일치한다고 가정할 수 없습니다. 서버 응답은 HTTP 상태만으로 RPC 성공 여부를 나타내지 않습니다. 최종 grpc-status는 보통 트레일러에 담기며, 즉시 실패에는 trailers-only 응답도 허용됩니다. 따라서 중간 프록시가 트레일러를 보존하는지 확인해야 합니다.

전문가 관점: 채널은 단일 연결이나 무제한 처리량을 뜻하지 않음

gRPC 엔지니어 Jean de Klerk(당시 Google)는 구현 블로그에서 채널을 논리적 대상으로 설명하고, 실제 RPC가 여러 HTTP/2 연결로 분산될 수 있는 이름 해석·로드밸런서 구성을 다룹니다. 이 분석은 연결 관리가 성능과 복구에 영향을 준다는 실무 관점이며, 모든 라이브러리의 기본 연결 풀이 같다는 뜻은 아닙니다. HTTP/2 연결 하나의 동시 스트림 수에는 피어가 설정한 제한이 있을 수 있고, 이미 시작된 스트림은 일반적으로 도중에 다른 백엔드로 옮겨지지 않습니다. 긴 스트림은 재연결·재시도와 별도 복구 설계가 필요합니다.

스키마와 전송의 역할을 구분

Protocol Buffers는 흔히 쓰이는 IDL·메시지 인코딩이지만 gRPC의 유일한 페이로드 형식은 아닙니다. 압축은 grpc-encoding으로 협상하며, 압축 플래그가 1인 메시지에 선언된 코딩을 적용합니다. 이 형식 자체가 특정 크기 절감률이나 JSON 대비 처리 속도를 보장하지 않습니다. 실제 크기와 CPU 비용은 스키마, 데이터, 언어 런타임, 압축, 네트워크에서 측정해야 합니다. 서비스 정의에서 생성한 코드는 인터페이스 불일치를 줄이는 데 도움을 주지만, 분산 배포 중 구버전·신버전 호환성은 별도로 설계해야 합니다.

타임아웃·재시도·브라우저 제약

grpc-timeout을 생략하면 프로토콜 문서는 서버가 무한 타임아웃으로 간주해야 한다고 설명하므로, 서비스는 예산에 맞는 deadline을 명시하는 것이 중요합니다. RPC는 별도로 멱등이라고 정의하지 않는 한 자동 중복 제거를 전제하지 않습니다. 처리 결과가 불명확한 실패 뒤 재시도하면 서버 작업이 중복될 수 있으므로 멱등 키와 재시도 가능 오류를 정해야 합니다. 브라우저의 gRPC-Web은 일반 gRPC와 같은 기능 범위가 아니며, 브라우저-서버 스트리밍 조합과 프록시 지원을 확인해야 합니다. 배포 전 트레일러, 흐름 제어, 연결 제한, 취소, 장애 후 재시도를 실제 경로에서 시험하세요.

참고 자료