여러 언어의 내부 서비스가 REST API로 통신합니다. gRPC로 바꾸면 계약 관리와 실행 비용에서 무엇이 달라지나요?

gRPC는 스키마 기반 코드 생성과 스트리밍, 데드라인 같은 기능을 일관되게 쓰기 좋습니다. 하지만 프로토콜을 바꾸는 것만으로 느린 DB나 과도한 호출 구조가 해결되지는 않습니다. 저는 실제 병목과 팀이 원하는 계약 관리 방식을 먼저 확인하겠습니다.

gRPC는 서비스 메서드와 메시지 형태를 스키마에 정의하고 클라이언트·서버 코드를 생성하는 RPC 프레임워크입니다. API 정의를 공유하고 여러 언어의 코드를 생성하는 이점이 있습니다. REST도 OpenAPI 기반 코드 생성을 사용할 수 있으므로 코드 생성이 gRPC만의 기능은 아닙니다. 그러나 생성 코드가 같아도 상태 값의 의미나 재시도 가능한 오류는 팀 간 계약으로 정해야 합니다.

여러 언어의 내부 서비스가 같은 메시지와 오류 계약을 사용한다면 스키마에서 클라이언트를 생성하는 것이 실수를 줄일 수 있습니다. 다만 필드 추가·삭제와 enum 처리 규칙을 지켜야 하고, 생성 코드 버전이 서비스들의 배포를 강하게 묶지 않게 해야 합니다. REST는 브라우저·운영 도구·외부 소비자와의 접근성이 좋을 수 있어 모든 경계를 같은 방식으로 통일할 필요는 없습니다.

저는 대표 요청의 직렬화 비용과 메시지 크기, 연결 재사용 상태를 비교하고, 데드라인과 취소가 실제 하위 처리까지 전파되는지 확인하겠습니다. 오류 코드가 잔액 부족 같은 규칙상 거절과 일시적인 통신 장애를 구분하는지도 중요합니다. 로드밸런서가 스트림과 연결을 어떻게 분산하는지, 운영자가 요청을 추적하기 쉬운지도 함께 봐야 합니다. 선택 기준은 최신 기술이라는 인상보다 계약 일관성·성능 이득·관측과 배포 비용의 합입니다.

스키마가 줄이는 오류와 남기는 오류

protobuf는 필드 번호와 메시지 구조를 공통으로 관리하고 생성 코드로 수동 JSON 해석 오류를 줄입니다. 그래도 필드 번호 재사용, enum의 알 수 없는 값, 필드 의미 변경, 생성 코드 혼합 배포는 별도 규칙이 필요합니다. gRPC 상태 코드가 같아도 잔액 부족 같은 규칙상 거절과 네트워크 재시도 가능 오류를 구분하지 않으면 중복 처리 문제가 생깁니다. REST는 브라우저·운영 도구·외부 소비자의 접근성이 좋아 모든 경계를 gRPC로 바꿀 이유가 없습니다.

스트림 비용을 측정합니다

대표 요청에서 JSON/protobuf 직렬화 CPU, 메시지 크기, 연결 재사용, p95/p99를 비교하되 DB나 호출 횟수가 병목이면 프로토콜 효과와 분리합니다. HTTP/2의 긴 연결은 스트림을 효율적으로 묶지만 연결 단위 로드밸런싱으로 특정 인스턴스가 바빠질 수 있습니다. 클라이언트 스트리밍은 소비자가 느릴 때 버퍼가 무한히 늘지 않게 백프레셔·취소·deadline을 연결합니다. 병행 기간에는 한 경로를 읽기 전용 비교 모드로 두고 오류·권한·외부 효과가 같은지 검증하겠습니다.

구체적인 경계 사례

REST는 JSON 직렬화 형식 자체가 아니라 자원과 HTTP 의미를 활용하는 설계 방식입니다. OpenAPI로 클라이언트를 생성할 수도 있고, gRPC도 브라우저에서는 gRPC-Web이나 프록시 같은 추가 경로가 필요할 수 있습니다. 비교는 수동 JSON 대 자동 생성이라는 이분법보다 소비자 환경·스키마 운영·스트리밍 요구를 기준으로 하겠습니다.

삭제한 protobuf 필드 번호와 이름은 예약해 다른 의미로 재사용하지 않습니다. 바이너리에서는 통과한 변경도 JSON 변환이나 알 수 없는 enum 처리에서 달라질 수 있어 실제 중간 게이트웨이까지 검사합니다. deadline이 지나 클라이언트가 오류를 받아도 서버 결제가 이미 끝났을 수 있으므로 결과 조회와 멱등 키가 필요합니다. 전송 프레임워크의 취소 신호가 외부 효과를 롤백하지는 않습니다.