운영에서는 계약, 시간 예산, status 매핑을 같이 본다

gRPC 호출은 빠르지만 장애가 감춰지면 더 어렵습니다. 배포 전후에는 같은 trace 안에서 세 기준을 함께 확인합니다.

계약proto 호환성

필드 번호, optional/default, service 이름 변경을 추적합니다.

시간deadline과 retry

느린 내부 호출이 HTTP 요청 전체를 붙잡지 않게 제한합니다.

상태status code 매핑

NOT_FOUND, UNAVAILABLE 같은 상태를 API 의미로 바꿉니다.

문제	신호	대응
계약 불일치	method not found	proto, decorator, getService 이름 비교
느린 호출	deadline exceeded	timeout, retry, fallback 기준 설정
서버 장애	UNAVAILABLE	상태 매핑과 circuit breaker 검토

핵심: gRPC 품질은 “호출이 된다”보다 “계약이 깨져도 추적되고, 느려져도 시간 예산 안에서 실패한다”에 가깝습니다.