RPC

RPC(Remote Procedure Call)는 다른 컴퓨터나 프로세스에 있는 기능을 마치 로컬 함수처럼 호출하는 개념입니다.

로컬 함수: cancelOrder(10)
원격 호출: 네트워크를 통해 주문 서비스의 cancelOrder(10) 실행

개발자는 함수 호출처럼 사용하지만, 실제 내부에서는 요청 직렬화, 네트워크 전송, 서버 실행, 응답 역직렬화가 일어납니다.

REST는 주로 자원을 중심으로 생각합니다.

POST /orders/10/cancellation

RPC는 수행할 동작을 중심으로 생각합니다.

OrderService.cancelOrder(orderId: 10)

둘 중 하나가 항상 더 올바른 것은 아닙니다. 회원·상품 CRUD는 자원 중심 표현이 자연스럽고, 결제 승인·보고서 생성·기기 재부팅 같은 명령은 RPC식 표현이 자연스러울 수 있습니다.

1. 클라이언트가 함수와 인자를 지정
2. Stub이 요청 데이터를 전송 가능한 형식으로 직렬화
3. 네트워크를 통해 서버로 전송
4. 서버가 해당 함수를 실행
5. 실행 결과를 직렬화해 반환
6. 클라이언트가 결과를 원래 타입으로 복원

Stub 또는 Client는 복잡한 네트워크 처리를 감추고 개발자가 일반 함수처럼 호출할 수 있게 돕습니다.

RPC는 넓은 통신 패턴입니다. 구현 기술로는 gRPC, JSON-RPC, XML-RPC 등이 있습니다.

• JSON-RPC: JSON 메시지로 메서드와 인자를 표현
• XML-RPC: XML로 호출 내용을 표현
• gRPC: Protocol Buffers와 HTTP/2를 주로 사용하는 RPC 프레임워크

JSON-RPC 예시는 다음과 같습니다.

{
  "jsonrpc": "2.0",
  "method": "subtract",
  "params": [42, 23],
  "id": 1
}

문법은 함수처럼 보여도 다음 실패 가능성이 추가됩니다.

• 네트워크가 끊김
• 서버가 응답하지 않음
• 응답이 늦어 Timeout 발생
• 요청은 처리됐지만 응답만 유실됨
• 재시도로 같은 작업이 중복 실행됨
• 클라이언트와 서버의 계약 버전이 다름

따라서 Timeout, 재시도, 멱등성, 오류 코드, 관측성, 버전 호환성을 반드시 고려해야 합니다. 호출 문법이 로컬 함수와 같아도 실패하는 방식은 다릅니다.

장점

• 명령 중심 업무를 직관적으로 표현합니다.
• 코드 생성과 타입 시스템을 결합하기 좋습니다.
• 서비스와 메서드 단위로 계약을 정의하기 쉽습니다.

한계

• 네트워크 실패가 함수 호출 문법 뒤에 숨을 수 있습니다.
• 구현 기술에 따라 브라우저 호환성과 디버깅 편의성이 떨어질 수 있습니다.
• 메서드가 많아지면 서비스 경계와 버전 관리가 복잡해집니다.

• 서비스 간 명령 호출이 중심인 시스템
• 기기 제어, 결제 승인처럼 행동의 의미가 강한 기능
• 타입이 명확한 내부 API가 필요한 경우
• 동일 조직 안에서 클라이언트와 서버 계약을 함께 관리할 수 있는 경우

RPC는 원격 서버의 기능을 함수처럼 호출하는 통신 개념이며, gRPC는 이를 구현하는 대표적인 프레임워크다.