1068. gRPC / 프로토콜 버퍼 직렬화 - Google Remote Procedure Call 초고속 마이크로서비스 통신 바이너리 패킹 HTTP/2 멀티플렉싱 API 아키텍처

핵심 인사이트: (477번 REST API 한계 돌파) 클라우드 시대, 수백 개의 쪼개진 마이크로서비스 서버들이 1초에 수만 번씩 "회원 정보 내놔!", "결제 승인해!" 대화를 한다. 옛날엔 이 대화를 JSON(텍스트) 껍데기에 싸서 REST API(HTTP)로 보냈다. JSON 텍스트 껍데기 까보는 데(파싱) CPU를 다 쓰고, "{"name":"kim"}" 괄호 하나하나가 용량을 너무 쳐먹어서 서버가 기절했다. 구글이 빡쳐서 판을 갈아엎었다. "야! 인간이 읽기 좋은 예쁜 JSON 텍스트 다 갖다 버려! 어차피 기계끼리 대화하는데 텍스트를 왜 써! 데이터를 0과 1의 극한의 덩어리(바이너리)로 미치도록 압축(프로토콜 버퍼)해서, 최신 고속도로인 HTTP/2 양방향 터널(gRPC)로 쏴버려!" 기계들의 대화 속도를 10배로 폭발시킨 흑마법, gRPC다.

Ⅰ. 기존 REST API (JSON + HTTP/1.1)의 재앙적 병목

  • JSON의 무거움: {"age": 30} 이 문장을 전송하려면 괄호, 쌍따옴표 텍스트까지 모조리 바이트로 차지합니다. 사람이 눈으로 읽기는 좋지만, 컴퓨터가 이 문자열을 쪼개서 숫자 30으로 해석(Parsing)하는 데 엄청난 CPU 연산 낭비가 터집니다.
  • HTTP/1.1의 족쇄: 464번에서 배운 홀딩(HOLB) 현상 때문에 한 번에 하나씩밖에 패킷을 못 던져 통신 딜레이가 끔찍했습니다.

Ⅱ. gRPC (Google Remote Procedure Call)의 탄생 🌟

  • 개념: 구글이 수만 대의 마이크로서비스 서버끼리 빛의 속도로 대화하게 하려고 자체 개발해 오픈소스로 푼 초고성능 범용 원격 프로시저 호출(RPC) 프레임워크입니다.
  • 원리 (RPC): 부산에 있는 서버 B의 코드를 실행하고 싶은데, 마치 내 서버 A 컴퓨터 안의 함수를 실행(CallPayment(100))하는 것처럼 아무 네트워크 지식 없이 한 줄의 코드만 치면 허공을 뚫고 들어가 남의 서버 함수를 실행시키고 값을 훔쳐 옵니다.

Ⅲ. gRPC가 REST API의 모가지를 비튼 2대 압살 무기 🌟 핵심 기출 🌟

1. 화물 다이어트: 프로토콜 버퍼 (Protocol Buffers, protobuf) 🌟

JSON을 무덤으로 보낸 1등 공신입니다. gRPC의 데이터 직렬화(Serialization, 포장지) 포맷입니다.

  • 개념: 데이터를 전송할 때 인간이 읽는 텍스트(String)를 싹 다 버리고, 오직 기계만 알아먹는 초압축 이진수(Binary) 덩어리로 꽉꽉 뭉쳐서 팩킹해 버립니다.
  • 동작:
    • .proto 파일에 설계도를 먼저 짭니다. "1번 칸은 문자열 이름, 2번 칸은 숫자 나이!"
    • 패킷을 쏠 때는 이름표 태그("name":)를 아예 생략하고, 그냥 [1번 칸 데이터][2번 칸 데이터] 이진수 덩어리만 틱 쏩니다.
    • 효과: JSON보다 용량이 3분의 1로 줄어들고, 텍스트를 해석할 필요가 없어 파싱 속도가 최소 5배~10배 미친 듯이 빨라집니다. 대규모 마이크로서비스 내부망 통신 트래픽을 극단적으로 쥐어짭니다.

2. 고속도로 교체: HTTP/2 기반 🌟

  • gRPC는 낡은 HTTP/1.1을 버리고 태생부터 HTTP/2(466번) 위에서만 돌아갑니다.
  • 양방향 스트리밍 (Bi-directional Streaming): 한 번 암호 터널(TCP)을 뚫어두면, 문을 안 닫고 클라이언트와 서버가 커다란 호스를 연결한 것처럼 실시간 비디오를 쏘듯 패킷을 양방향으로 와다다다 무한정 쏟아붓습니다(멀티플렉싱). 통신을 맺고 끊는 오버헤드가 제로가 됩니다.

Ⅳ. 언어 해방 (Polyglot)과 단점

  • 구글의 프로토콜 버퍼(설계도) 하나만 딱 짜서 컴파일러에 넣으면, 자바(Java), 파이썬(Python), Go, C++ 등 10개 언어의 통신 코드를 1초 만에 기계가 다 자동으로 생성(Code Generation)해 줍니다. 언어가 파편화된 클라우드 MSA 환경에서 신이 내린 축복입니다.
  • 치명적 단점 (브라우저 호환성): 브라우저(크롬, 사파리)는 이진수 덩어리(바이너리)를 직접 파싱하는 데 취약해서 프론트엔드(웹)와 백엔드가 통신할 땐 쓰기 힘듭니다(gRPC-Web 꼼수 필요). 그래서 **백엔드 서버들끼리의 내부망 통신(East-West)**에만 몰빵해서 100% 장악한 상태입니다.

📢 섹션 요약 비유: 기존 REST API(JSON) 방식은 외국인과 대화할 때, 택배 박스에 "이것의 이름은(name) 홍길동이고, 나이는(age) 30입니다"라고 영어 문장으로 예쁘고 친절하게 적어서 보내는 것입니다. 받는 사람이 박스 겉면만 보고도 무슨 내용인지 알 수 있지만, 글자가 길어 박스가 낭비되고 텍스트를 읽고 해석(파싱)하느라 시간이 한참 걸립니다. **gRPC(프로토콜 버퍼)**는 이 텍스트를 다 찢어버리고, 서로 미리 설계도(암호 책)를 나눠가진 뒤 '진공 압축 포장된 알약(바이너리 이진수)' 하나만 딸랑 쏘는 흑마법입니다. 해커나 인간이 이 패킷을 가로채서 까보면 그냥 10110010이라는 쓰레기 기계어 덩어리로 보여서 절대 읽지 못합니다. 하지만 암호 책(.proto)을 가진 상대방 서버는 이 이진수 알약을 0.001초 만에 쏙 풀어서 "홍길동, 30"이라는 데이터를 뽑아냅니다. 인간의 가독성을 완벽히 포기한 대가로, 용량을 1/3로 압축하고 파싱 속도를 10배 폭발시켜, 1초에 수만 번 대화하는 기계(MSA 컨테이너)들만의 초광속 텔레파시 우주 통신망을 완성했습니다.