126. RPC (Remote Procedure Call) - 분산 시스템 함수 호출

핵심 인사이트 (3줄 요약)

본질: RPC (Remote Procedure Call, 원격 프로시저 호출)는 네트워크로 연결된 원격 서버의 함수(프로시저)를 마치 로컬 함수인 것처럼 호출할 수 있게 해주는 분산 시스템용 통신 추상화 프레임워크다.

가치: IDL (Interface Definition Language)로 인터페이스를 명세하고 스터브(Stub) 코드를 자동 생성하여, 소켓(Socket) 기반의 하위 네트워크 프로그래밍 복잡성(마샬링, 연결 관리, 에러 처리)을 개발자에게 완전히 은닉한다.

융합: 1980년대 Sun Microsystems의 ONC RPC에서 시작하여 gRPC (gRPC Remote Procedure Calls), Apache Thrift 등 현대 마이크로서비스 아키텍처(MSA)의 핵심 내부 통신 표준으로 발전하였으며, 마샬링(Marshalling), XDR (External Data Representation), IDL 등 다양한 기술을 융합한 분산 컴퓨팅의 근간 기술이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: RPC는 분산 시스템에서 클라이언트 프로세스가 네트워크 상의 서버 프로세스가 제공하는 함수(서비스)를 로컬 함수 호출과 동일한 구문으로 호출할 수 있도록, 네트워크 통신의 모든 복잡성을 스터브(Stub)라는 프록시(Proxy) 계층으로 캡슐화하는 통신 프레임워크다.
필요성: 소켓(Socket) 기반의 네트워크 프로그래밍은 데이터 직렬화(Serialization), 엔디안(Endian) 변환, TCP 연결 관리, 타임아웃(Timeout) 처리, 재시도(Retry) 로직 등 비즈니스 로직과 무관한 하위 계층 코드를 반복적으로 작성해야 한다. 서비스가 수십 개로 분산되는 마이크로서비스 환경에서는 이러한 통신 보일러플레이트(Boilerplate) 코드가 프로젝트의 상당 부분을 차지하여 유지보수성을 심각하게 저하시킨다. RPC는 이 모든 네트워크 장벽을 '함수 호출'이라는 직관적인 패러다임 뒤로 감추어, 개발자가 분산 시스템의 비즈니스 로직 구현에만 집중할 수 있도록 한다.
💡 비유: RPC는 글로벌 콜센터의 통역 서비스와 같다. 내가 한국어로 질문(로컬 함수 호출)하면, 중간의 통역사(스터브)가 알아서 국제전화를 걸고 상대방 언어로 번역(마샬링)하여 답변을 받아온 뒤, 다시 내게 한국어로 돌려주므로 나는 상대방이 지구 반대편에 있다는 사실을 의식할 필요가 없다.
등장 배경: 1984년 Andrew Birrell과 Bruce Nelson이 Xerox PARC에서 RPC 개념을 학술적으로 정립하였고, 1980년대 후반 Sun Microsystems의 ONC RPC (Open Network Computing RPC)가 상용화의 표준이 되었다. 이후 DCE RPC, CORBA, Java RMI를 거쳐, 2015년 Google이 HTTP/2와 Protocol Buffers를 결합한 gRPC를 공개하면서 클라우드 네이티브 마이크로서비스 시대의 사실상(De-facto) 표준으로 부활하였다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │              RPC의 핵심 가치: 네트워크 은닉(Transparency)           │
  ├─────────────────────────────────────────────────────────────────────┤
  │                                                                     │
  │  [소켓 기반 통신 (개발자가 직접 구현)]                              │
  │                                                                     │
  │  sock = socket(AF_INET, SOCK_STREAM, 0);                            │
  │  connect(sock, "192.168.1.10", 8080);                               │
  │  // 개발자가 직접 직렬화                                            │
  │  msg = pack("order_id=%d,user_id=%d", 1001, 555);                   │
  │  send(sock, msg, strlen(msg), 0);                                   │
  │  resp = recv(sock, buf, 4096, 0);                                   │
  │  // 개발자가 직접 역직렬화                                          │
  │  result = parse_response(resp);                                     │
  │  close(sock);                                                       │
  │                                                                     │
  │  ─────────────────────────────────────────────────────────────      │
  │                                                                     │
  │  [RPC 기반 통신 (프레임워크가 자동 처리)]                           │
  │                                                                     │
  │  result = orderService.GetOrderStatus(order_id=1001, user_id=555);  │
  │                                                                     │
  │  내부적으로 스터브(Stub)이 자동 수행:                               │
  │  ┌──────────────────────────────────────────────────────────┐       │
  │  │ 1. 파라미터 마샬링 (pack to binary)                       │      │
  │  │ 2. 네트워크 전송 (TCP send)                                │     │
  │  │ 3. 응답 대기 (블로킹)                                     │      │
  │  │ 4. 응답 언마샬링 (unpack from binary)                     │      │
  │  │ 5. 결과 반환                                                │    │
  │  └──────────────────────────────────────────────────────────┘       │
  │                                                                     │
  │  개발자 코드: 1줄 vs 소켓 코드: 7줄 (복잡도 85% 감소)               │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 비교는 RPC가 왜 분산 시스템에서 필수적인지를 극명하게 보여준다. 소켓 기반 코드에서 개발자는 비즈니스 로직과 무관한 직렬화, 연결 설정, 송수신, 역직렬화 코드를 매 호출마다 반복 작성해야 한다. 반면 RPC에서는 로컬 함수 호출처럼 한 줄의 코드로 동일한 작업을 수행하며, 모든 네트워크 통신 로직은 IDL 컴파일러가 자동 생성한 스터브(Stub)가 대행한다. 이러한 추상화(Abstraction)는 단순히 코드 라인 수를 줄이는 것을 넘어, 네트워크 프로그래밍의 실수(엔디안 변환 누락, 버퍼 오버플로우 등)를 원천적으로 방지하여 시스템의 신뢰성을 획기적으로 높인다.

📢 섹션 요약 비유: 원격 리모컨의 버튼 하나만 누르면 저 멀리 있는 TV의 채널이 바뀌듯이, 내부의 전파 송수신 과정(네트워크)을 알 필요 없이 버튼 누르기(함수 호출)라는 직관적 행위만으로 원격 작업을 수행하는 것이 RPC의 핵심 가치입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

RPC의 구성 요소

요소명	역할	내부 동작	관련 기술	비유
IDL (Interface Definition Language)	서비스 인터페이스(함수명, 인자, 반환 타입)를 언어 중립적으로 정의	IDL 컴파일러가 언어별 스터브 코드 자동 생성	Protocol Buffers, Thrift IDL	통역 매뉴얼
클라이언트 스터브 (Client Stub)	로컬 함수 호출을 네트워크 메시지로 변환	인자 마샬링 후 RPC 런타임에 전달	프록시(Proxy) 패턴	클라이언트 통역사
서버 스켈레톤 (Server Skeleton)	수신된 메시지를 서버의 로컬 호출로 복원	언마샬링 후 실제 함수 디스패치(Dispatch)	어댑터(Adapter) 패턴	서버 통역사
RPC 런타임 (Runtime)	전송 계층 관리 (연결, 재전송, 라우팅)	TCP/UDP 소켓을 래핑하여 메시지 송수신	gRPC, Thrift Runtime	우편 배달 시스템
마샬링 (Marshalling)	메모리 객체를 네트워크 전송 가능한 바이트 스트림으로 변환	엔디안 변환, 데이터 타입 정규화	XDR, Protobuf, JSON	수하물 규격 포장

RPC 호출의 전체 실행 시퀀스

  ┌─────────────────────────────────────────────────────────────────────┐
  │                 RPC 호출의 전체 실행 시퀀스 (8단계)                 │
  ├─────────────────────────────────────────────────────────────────────┤
  │                                                                     │
  │  [Client Machine]                  [Server Machine]                 │
  │                                                                     │
  │  1. Client Code                   8. Server Function                │
  │     result = func(a, b)          ┌──▶ getStockPrice("AAPL")         │
  │       │                          │       │                          │
  │       ▼                          │       ▼                          │
  │  2. Client Stub                  │  7. Server Skeleton              │
  │     마샬링(a,b → binary)         │     언마샬링(binary → args)      │
  │       │                          │       │                          │
  │       ▼                          │       ▼                          │
  │  3. RPC Runtime (Client)         │  6. RPC Runtime (Server)         │
  │     전송 계층 (TCP/UDP)          │     수신 큐에서 꺼내기           │
  │       │                          │       │                          │
  │       │    ┌────────────────┐     │       │                         │
  │       └───▶│   Network     │─────┘       │                          │
  │            │  (TCP/IP 등)   │             │                         │
  │            └────────────────┘             │                         │
  │       4. Request Message                5. Response Message         │
  │          [func_id|arg_bytes] ◀────────── [result_bytes|status]      │
  │                                                                     │
  │  [역순 반환]                                                        │
  │  9. Client Stub 언마샬링(result_bytes → result)                     │
  │  10. Client Code가 result 사용                                      │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] RPC의 8단계 실행 시퀀스에서 가장 중요한 설계 원칙은 대칭성(Symmetry)이다. 클라이언트 측의 마샬링(단계 2)과 서버 측의 언마샬링(단계 7)은 정확히 역연산 관계에 있으며, 이 역연산의 정확성을 IDL이 보장한다. 단계 3~6에서 RPC 런타임이 실제 네트워크를 통해 메시지를 전송한다. 이때 메시지에는 함수 식별자(func_id), 마샬링된 인자(arg_bytes), 그리고 부가 정보(메시지 유형, 트랜잭션 ID 등)가 포함된다. 클라이언트는 단계 3에서 메시지를 전송한 후 결과를 기다리며 블로킹(Blocking)되며, 서버의 응답 메시지가 도달하면 블로킹이 해제되고 역순으로 결과가 복원된다. 이 과정에서 개발자는 네트워크 경계(Network Boundary)의 존재를 전혀 인식하지 못한다.

RPC 의미론(Semantics)의 세 가지 유형

의미론 유형	설명	장점	단점	구현 예시
정확히 한 번 (Exactly-Once)	호출이 정확히 한 번만 실행됨을 보장	가장 안전, 데이터 일관성 보장	구현 복잡, 중복 제거 메커니즘 필요	TCP 기반 gRPC + 멱등 키
최대 한 번 (At-Most-Once)	호출이 한 번 이상 수행되지 않음을 보장	중복 실행 없음, 구현 비교적 단순	서버 처리 후 응답 유실 시 결과 누락	UDP 기반 RPC
최소 한 번 (At-Least-Once)	호출이 적어도 한 번은 수행됨을 보장	결과 누락 방지	중복 실행 가능 (재시도 시)	멱등성이 보장된 연산 + 재시도

📢 섹션 요약 비유: '정확히 한 번'은 등기 우편으로 확실하게 한 번 배달하는 것이고, '최대 한 번'은 일반 우편으로 분실되면 다시 보내지 않는 것이며, '최소 한 번'은 분실되면 재발송하여 여러 번 도착할 수 있더라도 반드시 도착시키는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

RPC vs REST 다차원 비교

평가 기준	RPC (gRPC)	REST (HTTP/JSON)	판단 기준
설계 철학	동사(Action) 중심	명사(Resource) 중심	행위 vs 자원 중심
페이로드	이진 포맷(Protobuf)	텍스트 포맷(JSON)	대역폭 효율
타입 안정성	IDL 기반 강한 타입	JSON 스키마(선택적)	인터페이스 계약 엄격성
스트리밍	양방향 스트리밍 기본 지원	HTTP/2 SSE만 단방향	실시간 데이터 처리
오버헤드	HTTP/2 멀티플렉싱	HTTP/1.1 헤더 중복	내부 통신 효율
사용처	마이크로서비스 간(S2S) 통신	외부 Public API, 프론트엔드	내부 vs 외부

📢 섹션 요약 비유: REST가 누구나 읽을 수 있는 표준 편지(사람 친화적)라면, RPC는 훈련된 요원들끼리 암호화된 모스 부호(기계 친화적)로 통신하는 방식으로, 외부 고객에게는 REST를, 내부 서비스 간에는 RPC를 사용하는 하이브리드 전략이 실무의 표준입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 -- RPC 타임아웃과 서킷 브레이커: MSA 환경에서 주문 서비스가 결제 서비스를 gRPC로 호출했으나, 네트워크 스위치 장애로 응답이 유실된 상황. 주문 서비스가 타임아웃(Timeout) 설정 없이 무한 대기하면 전체 시스템이 마비되는 캐스케이딩(Cascading) 장애가 발생한다. 아키텍트는 반드시 RPC 호출에 명시적 타임아웃을 설정하고, 실패 누적 시 서킷 브레이커(Circuit Breaker)를 트리거하여 장애 전파를 차단해야 한다.
시나리오 -- 멱등성(Idempotency) 보장과 재시도 폭풍(Retry Storm): 타임아웃으로 RPC 호출이 실패했을 때, 사실 서버에서는 이미 요청을 처리했으나 응답만 유실된 상태일 수 있다. 무조건 재시도하면 결제 중복 승인 같은 치명적 오류가 발생한다. 백엔드 엔지니어는 모든 상태 변경 RPC에 멱등 키(Idempotency Key)를 IDL에 포함시켜, 중복 호출 시 서버가 이전 결과를 반환하도록 설계해야 한다.

도입 체크리스트

기술적: IDL 파일의 하위 호환성(Backward Compatibility)을 위해 필드 번호와 타입 변경 정책을 수립하였는가? RPC 호출에 적절한 타임아웃(Timeout)과 재시도(Retry) 정책을 설정하였는가?
운영 보안적: RPC 통신 채널에 TLS 암호화를 적용하였으며, mTLS (Mutual TLS)로 서비스 간 상호 인증을 구현하였는가? RPC 트래픽의 지연(Latency)과 에러율(Error Rate)을 APM으로 모니터링하고 있는가?

안티패턴

RPC 남용에 의한 채티 I/O (Chatty I/O): 로컬 객체를 다루듯 루프 안에서 수천 번의 RPC 호출을 수행하는 안티패턴. 1회 호출에 10ms가 걸리면 1,000회 호출 시 10초의 지연이 발생한다. 반드시 배치(Batch) 처리가 가능한 굵직한(Coarse-grained) 인터페이스를 IDL에 정의해야 한다.
📢 섹션 요약 비약 비유: 로컬 함수는 내가 직접 주방에서 요리하는 것이지만, RPC는 원격 요리사에게 주문하는 것이라 전화가 끊기면 요리를 안 한 건지, 다 해놓고 배달만 못 한 건지 알 수 없으므로 반드시 주문 번호(멱등 키)와 대기 시간(타임아웃)을 설정해야 합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	도입 전 (Raw Socket)	도입 후 (gRPC 등 RPC)	개선 효과
정량	수동 직렬화, HTTP/1.1 중복 헤더	Protobuf + HTTP/2 멀티플렉싱	내부 통신 레이턴시 70% 이상 단축
정량	언어별 통신 보일러플레이트 수작성	IDL 기반 스터브 자동 생성	통신 모듈 개발 시간 1/5 단축
정성	이기종 언어 간 타입 변환 에러	컴파일 타임 강력한 타입 체크	인터페이스 호환성 100% 보장

미래 전망

서비스 매시 (Service Mesh)와의 통합: Istio, Envoy 등 서비스 매시가 RPC 트래픽을 사이드카(Sidecar) 프록시로 가로채어 트래픽 관리, 로드 밸런싱, 보안 정책을 인프라 수준에서 제어한다.
양방향 스트리밍 RPC: gRPC의 서버 스트리밍(Server Streaming), 클라이언트 스트리밍(Client Streaming), 양방향 스트리밍(Bidirectional Streaming) 모델이 실시간 데이터 처리(예: 주식 호가, 채팅, IoT 센서 데이터)의 표준 통신 패턴으로 자리 잡고 있다.

참고 표준

RFC 1831: ONC RPC (Open Network Computing RPC) 프로토콜 명세.
gRPC (CNCF): Protocol Buffers + HTTP/2 기반의 현대 RPC 프레임워크. Cloud Native Computing Foundation이 관리하는 마이크로서비스 통신 표준.

RPC는 네트워크의 존재를 개발자에게 완전히 은닉하는 분산 시스템의 핵심 추상화 기술이다. 스터브(Stub), IDL, 마샬링(Marshalling)이라는 세 가지 기둥을 통해 소켓 프로그래밍의 복잡성을 "함수 호출 한 줄"로 압축하며, gRPC를 통한 현대적 부활로 클라우드 네이티브 마이크로서비스 아키텍처의 근간 기술로 확고히 자리 잡았다.

📢 섹션 요약 비유: 수동 기어 조작으로 엔진 회전수를 맞춰야 했던 과거의 운전(소켓 프로그래밍)이 자동 변속기(RPC)의 도입으로 엑셀과 브레이크만 밟으면 되는 시대로 변모하여, 개발자가 오직 목적지(비즈니스 로직)에만 집중할 수 있게 된 것과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
마샬링/언마샬링 (Marshalling/Unmarshalling)	RPC의 핵심 데이터 변환 기술. 메모리 객체를 네트워크 전송 가능한 바이트 스트림으로 변환(Marshalling)하고, 수신 측에서 원래의 구조체로 복원(Unmarshalling)한다.
XDR (External Data Representation)	Sun Microsystems가 ONC RPC를 위해 설계한 기계 독립적 데이터 인코딩 표준. 이기종 시스템 간의 데이터 형식 차이(엔디안, 정수 크기)를 추상화한다.
IDL (Interface Definition Language)	서비스 간 통신 규약을 언어 중립적으로 정의하는 명세 언어. 컴파일러가 IDL로부터 각 언어용 스터브(Stub) 코드를 자동 생성한다.
서킷 브레이커 (Circuit Breaker)	RPC 호출 실패가 누적될 때 추가 요청을 차단하여 단일 서비스 장애가 전체 시스템으로 전파되는 캐스케이딩(Cascading) 장애를 막는 클라우드 네이티브 방어 패턴이다.
gRPC	Google이 개발한 현대 RPC 프레임워크. Protocol Buffers(IDL + 직렬화), HTTP/2(전송), 양방향 스트리밍을 결합하여 마이크로서비스 내부 통신의 사실상 표준이다.

👶 어린이를 위한 3줄 비유 설명

RPC는 다른 나라에 있는 요리사에게 내가 원하는 요리를 만들어 달라고 부탁하는 "만능 통역 스마트폰"이에요.
내가 한국어로 "피자 만들어줘"라고 버튼을 누르면, 스마트폰 안의 똑똑한 비서(Stub)가 알아서 상대방 언어로 번역해서 이메일로 보내주고, 응답이 오면 다시 내 식탁에 올려줘요.
요리사가 멀리 있어도 내 눈앞에서 요리하는 것처럼 느껴지지만, 사실은 중간에 통역(마샬링)과 배달(네트워크)이라는 복잡한 과정이 숨어 있답니다!