두 구조의 핵심 차이를 실제 사용 경험으로 설명하기
약 86초
HTTP REST와 gRPC 차이를 코드 레벨 경험과 함께 풀어낸다
REST API는 자원 중심으로 URL을 설계하고 HTTP 메서드로 의도를 표현합니다. 클라이언트와 서버가 텍스트 기반 JSON을 주고받기 때문에 사람이 읽기 쉽고 디버깅이 편하다는 장점이 있습니다. 반면 RPC 방식은 원격 서버의 함수를 직접 호출하는 것처럼 설계합니다. gRPC 기준으로는 Protobuf로 직렬화하기 때문에 페이로드가 작고, 바이너리 전송이라 속도가 빠릅니다.
개인 프로젝트에서 두 방식을 모두 사용해 보았는데, REST는 외부 클라이언트에게 노출할 API에 사용하고 gRPC는 내부 마이크로서비스 간 통신에 사용했습니다. gRPC로 교체했을 때 같은 데이터 기준 응답 크기가 약 40% 줄었고, 처음에 proto 파일 설계를 잘못하여 필드 타입을 두 번 바꿨던 실패가 있었습니다. 버전 관리가 REST보다 엄격하다는 것을 그때 배웠습니다.
결국 누가 호출하느냐, 성능 요구가 얼마나 빡빡하냐에 따라 선택이 갈린다고 생각합니다. 외부 파트너나 브라우저 클라이언트라면 REST, 내부 서비스 간 고성능 통신이라면 gRPC 쪽이 자연스럽습니다. 두 구조의 경계를 이해하면 설계 의사결정이 훨씬 빨라진다고 느꼈습니다.
이 결의 특징
REST·gRPC 두 방식을 직접 프로젝트에서 사용했습니다. JSON 디버깅 편의성과 Protobuf 바이너리 전송, 40% 크기 감소 수치가 구체적입니다. proto 파일 필드 타입을 두 번 수정한 실패 경험이 버전 관리 복잡성을 증명합니다.
이 결이 통하는 자리
외부 클라이언트·내부 마이크로서비스 구분을 기술 선택 기준으로 설명할 때, 설계 의사결정이 빨라진다는 자각이 살아 있을 때 설득력을 갖습니다.