제 5장: RPC와 이벤트 스트리밍

현대 분산 시스템에서 「원격 프로시저 호출(RPC)」과 「이벤트 스트리밍(Event Streaming)」은 마이크로서비스 간 통신과 비동기 데이터 흐름을 떠받치는 양대 축으로 자리잡았다. 본권의 「범용 프로토콜 표준」(WIA-CORE-007)이 본 장에서 다루는 핵심 의제는 두 통신 방식의 상호 보완성과, 한국 IT 산업이 글로벌 표준을 채택하면서도 자체 운영 환경에 맞게 변용해온 사례를 학술적으로 정돈하는 것이다.

RPC 패러다임은 1980년대 Sun RPC와 DCE/RPC를 거쳐 SOAP, REST를 지나, 마침내 GRPC(Google Remote Procedure Call) 가 2016년 공개 표준으로 자리잡으며 HTTP/2 기반의 이진 직렬화·다중화·헤더 압축이라는 세 가지 혁신을 일반화하였다. 동시기에 JSON_RPC_2_0은 가독성과 단순함을 무기로 IoT·웹 영역에서 견고히 사용되어 왔으며, XML_RPC·THRIFT·MSGPACK_RPC·CAP_N_PROTO·CONNECT_RPC·REST_RPC·SOAP 등 다양한 변형이 도메인별 요구에 따라 공존하고 있다.

이벤트 스트리밍 영역에서는 KAFKA를 필두로 NATS·RABBITMQ·PULSAR·REDIS_STREAMS·EVENTSTORE·NSQ가 각자의 보존·복제·소비 모델을 정립해왔다. 특히 EVENT_SOURCING 패턴은 상태 변경의 원천 진실(source of truth)을 이벤트의 순서열로 두고, CQRS(명령·조회 책임 분리)와 결합하여 감사 가능성과 시간역행 재현(time-travel replay)을 가능케 한다.

국내 산업 현황을 보면, 카카오의 「KafkaForKakao」 사내 표준은 토픽 네이밍·파티션 키·스키마 진화 규약을 통일하여 수천 개 서비스 간 이벤트 흐름을 정돈하였고, NAVER Cloud의 「Pulsar 클러스터」는 다중 테넌트 격리와 지오 복제(geo-replication)를 상용 서비스 수준으로 끌어올렸다. 토스는 「gRPC 기반 마이크로서비스」를 전면 도입하여 결제 처리 지연을 15퍼센트 단축하였다고 2024년 기술 컨퍼런스에서 발표한 바 있다. 우아한형제들은 「Event-Driven 아키텍처」로 주문·배차·배달 도메인을 분리하였으며, LG CNS는 금융권을 위한 「Smart-RPC」 게이트웨이를 자체 개발하여 「TTA 분산 컴퓨팅 표준」 정합 인증을 획득하였다.

본 장은 이러한 글로벌 표준과 한국 사례를 7개 절로 나누어 다룬다. 시뮬레이터 패널 1에서 직접 실행 가능한 RPC 호출 비교, GitHub의 참고 구현, 그리고 1차 출처 RFC·공식 문서 인용을 통해 학습자가 추상이론과 실무 구현을 동시에 체득할 수 있도록 구성하였다.

제1절. gRPC와 HTTP/2 기반 이진 RPC

GRPC는 Google이 2015년 내부 RPC 시스템 「Stubby」를 일반 공개하면서 등장하였다. 핵심 설계 결정은 세 가지였다. 첫째, HTTP/2의 「스트림(stream)」 다중화를 활용하여 단일 TCP 연결 위에서 다수의 동시 호출을 지원한다. 둘째, 직렬화 형식으로 「Protocol Buffers」를 채택하여 스키마 기반의 강타입 IDL(Interface Definition Language)을 강제한다. 셋째, 클라이언트·서버 코드가 IDL로부터 자동 생성되도록 하여 언어 간 상호운용성을 확보한다.

스트리밍 패턴은 네 가지로 정의된다. 「단일 호출(unary)」은 REST 방식의 일대일 요청·응답이며, 「서버 스트리밍」은 단일 요청에 대해 서버가 다수의 응답을 시간순으로 송출한다. 「클라이언트 스트리밍」은 그 역방향이고, 「양방향 스트리밍(bidi)」은 두 측이 독립적으로 메시지를 흘려보낸다. 토스의 결제 검증 API는 양방향 스트리밍을 활용하여 카드 토큰 발급과 위험도 평가를 병렬 처리한다.

스트리밍 패턴	요청 수	응답 수	대표 사용 사례
단일 호출(Unary)	1	1	잔액 조회, 사용자 정보 조회
서버 스트리밍	1	N	실시간 알림, 주가 시세 송출
클라이언트 스트리밍	N	1	대용량 파일 업로드, 로그 수집
양방향 스트리밍(Bidi)	N	M	실시간 채팅, 음성 인식, 협업 편집

1.1 Protocol Buffers IDL 사례

다음은 토스 결제 API의 단순화된 정의이다. 「proto3」 문법은 필드 번호로 직렬화 호환성을 보장하며, 새 필드 추가 시 옛 클라이언트가 알지 못하는 필드를 무시하도록 설계되어 있다.

syntax = "proto3";
package wia.toss.payment.v1;

service PaymentService {
  rpc CreatePayment (CreatePaymentRequest) returns (Payment);
  rpc StreamReceipts (ReceiptQuery) returns (stream Receipt);
  rpc UploadEvidence (stream EvidenceChunk) returns (UploadAck);
  rpc LiveCheckout (stream ClientEvent) returns (stream ServerEvent);
}

message CreatePaymentRequest {
  string merchant_id = 1;
  int64 amount_krw = 2;
  string currency = 3;
  PaymentMethod method = 4;
}

본 정의는 「KISA TLS 1.3 가이드라인」을 준수하는 MTLS 채널 위에서 운영되며, 인증서 만료·교체 주기는 「KCMVP」 인증을 받은 HSM에 의해 관리된다. OPENTELEMETRY 인터셉터는 모든 호출에 대해 W3C Trace Context 헤더 traceparent를 자동 주입한다.

제2절. JSON-RPC 2.0과 가벼운 텍스트 RPC

JSON_RPC_2_0은 2010년 명세가 확정된 단순한 텍스트 기반 RPC로, 「method」·「params」·「id」 세 필드로 호출을 정의한다. 본 명세는 JSON-RPC 2.0 Specification에 공식 게시되어 있으며, 다음과 같은 특징을 갖는다. 첫째, 전송 계층 독립적으로 HTTP·WebSocket·표준입출력 어디서나 실행 가능하다. 둘째, 「알림(notification)」은 id 필드가 없는 일방향 호출로 응답을 기대하지 않는다. 셋째, 「배치(batch)」 요청은 다수 호출을 단일 JSON 배열로 묶어 전송한다.

한국 블록체인 노드 운영사들은 JSON-RPC 2.0을 표준 인터페이스로 채택하였다. 클레이튼(Klaytn) JSON-RPC, 카이아(Kaia) JSON-RPC가 대표적이며, 이는 이더리움 표준과 호환되도록 method 명명 규약을 따른다. 다음은 잔액 조회 호출 예시이다.

// 요청
{
  "jsonrpc": "2.0",
  "method": "klay_getBalance",
  "params": ["0xabc...", "latest"],
  "id": 42
}

// 응답
{
  "jsonrpc": "2.0",
  "result": "0x1bc16d674ec80000",
  "id": 42
}

JSON-RPC의 단순성은 「IETF Capability Negotiation」 관점에서 약점이기도 하다. 스키마가 외부 규약으로만 존재하므로 정적 타입 검증이 어렵고, 대용량 바이너리 페이로드 전송 시 Base64 부풀림(약 33퍼센트)이 발생한다. 이를 보완하기 위해 MSGPACK_RPC가 동일한 RPC 모델 위에 이진 직렬화를 적용한 형태로 등장하였다.

2.1 한국 핀테크 적용 사례

토스의 가맹점 정산 API는 JSON-RPC 2.0을 일부 레거시 통합에 유지하면서, 신규 통합은 GRPC로 점진 이관 중이다. 카카오뱅크는 오픈뱅킹 게이트웨이에서 「전자금융감독규정」 제13조 정합 로깅을 위해 JSON-RPC 호출 페이로드 전문을 「개인정보보호법」 §28-2 가명처리 후 저장한다. 「TTA 분산 컴퓨팅 표준」 TTAK.KO-10.1342 또한 JSON-RPC 호환성을 한국 공공 인터페이스의 권장 사양으로 명시한다.

제3절. Apache Kafka와 분산 커밋 로그

KAFKA는 2010년 LinkedIn이 공개한 분산 이벤트 스트리밍 플랫폼으로, 현재 Apache 재단의 정식 프로젝트이다. 핵심 추상은 「토픽(topic)」을 「파티션(partition)」으로 분할하여, 각 파티션이 순서 보장된 추가 전용(append-only) 로그가 되도록 한 것이다. 본 모델은 Apache Kafka Documentation에 정식 명세되어 있다.

프로듀서는 메시지에 「파티션 키」를 부여하여 해시 분산을 통제한다. 동일 키의 메시지는 동일 파티션에 적재되므로 키 단위 순서가 보장된다. 컨슈머 그룹은 파티션을 컨슈머 인스턴스에 분배하여 수평 확장을 달성하며, 각 컨슈머는 자신이 처리한 오프셋(offset)을 「__consumer_offsets」 토픽에 기록한다.

「정확히 한 번 의미 체계(exactly-once semantics, EOS)」는 멱등 프로듀서(enable.idempotence=true)와 트랜잭션 API(initTransactions·beginTransaction·sendOffsetsToTransaction·commitTransaction)의 결합으로 달성된다. 본 기능은 Kafka 0.11(2017) 이후 안정화되었다.

전달 의미	중복 발생	유실 발생	구현 방법
최대 한 번(at-most-once)	없음	가능	acks=0, 자동 커밋 빠름
최소 한 번(at-least-once)	가능	없음	acks=all, 처리 후 수동 커밋
정확히 한 번(exactly-once)	없음	없음	멱등 프로듀서 + 트랜잭션 API

3.1 카카오 「KafkaForKakao」 운영 표준

카카오는 사내 메시징·결제·커머스 도메인에 걸쳐 「KafkaForKakao」 라는 내부 운영 표준을 정립하였다. 본 표준은 다음 4개 항목을 의무화한다. 첫째, 토픽 명명은 {도메인}.{이벤트유형}.{버전} 형식을 따른다. 둘째, 모든 메시지는 「Schema Registry」에 Avro 스키마로 등록한다. 셋째, 파티션 수는 사전 용량 계산 결과의 1.5배로 산정한다. 넷째, 「최소 한 번」 의미 체계를 기본값으로 하되 결제 도메인은 「정확히 한 번」을 강제한다.

# KafkaForKakao 토픽 명명 예
payment.transaction_created.v1
payment.transaction_settled.v2
talk.message_sent.v1
commerce.order_placed.v1

# 프로듀서 설정 (정확히 한 번)
bootstrap.servers=kafka-payment.kakao.internal:9093
security.protocol=SSL
ssl.keystore.type=PKCS12
acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=5
transactional.id=payment-tx-${pod_id}

제4절. NATS, RabbitMQ, Pulsar 비교

NATS는 2011년 Cloud Foundry를 위해 설계된 경량 메시징 시스템으로, 텍스트 기반 와이어 프로토콜과 약 100마이크로초 수준의 메시지 지연이 특징이다. 본 명세는 NATS.io Documentation에 게시되어 있다. JetStream 확장은 메시지 영속화·재생·중복 제거를 추가하여 Kafka 대안으로 자리잡았다.

RABBITMQ는 AMQP 0-9-1 표준의 사실상 참조 구현이며, 「익스체인지(exchange)」·「큐(queue)」·「바인딩(binding)」의 삼분 모델로 라우팅 유연성을 제공한다. 본 문서는 RabbitMQ Documentation에서 확인 가능하다. 우아한형제들의 배차 도메인은 「topic exchange」 패턴으로 라이더·식당·고객 이벤트를 라우팅하며, 「dead letter exchange」를 통해 재시도 실패 메시지를 별도 큐로 격리한다.

PULSAR는 Apache 재단의 차세대 스트리밍 플랫폼으로, 「BookKeeper」 기반의 분리된 저장 계층과 다중 테넌트 격리가 특징이다. 본 명세는 Apache Pulsar Documentation에 정리되어 있다. NAVER Cloud의 「Pulsar 클러스터」는 다중 지역 복제(geo-replication)를 활용하여 서울·도쿄·싱가포르 리전 간 이벤트 전파를 100밀리초 이내로 유지한다.

플랫폼	저장 모델	전형적 지연	강점
Apache Kafka	로컬 디스크 로그	수 밀리초~수십 ms	처리량·내구성·생태계
NATS JetStream	경량 영속 저장	약 100 마이크로초	저지연·단순성
RabbitMQ	큐 인메모리/디스크	약 1~10 ms	라우팅 유연·AMQP 호환
Apache Pulsar	BookKeeper 분리 저장	수 밀리초	다중 테넌트·지오 복제
Redis Streams	인메모리 + AOF	약 1 ms	초저지연·단순 API

4.1 Redis Streams와 인메모리 이벤트

REDIS_STREAMS는 Redis 5.0(2018)에서 도입된 영속 스트림 자료구조로, 「XADD」·「XREAD」·「XREADGROUP」 명령으로 이벤트 송신·구독·소비 그룹 처리를 제공한다. 본 명세는 Redis Streams Documentation에 게시되어 있다. NAVER 검색 인덱싱 파이프라인은 Redis Streams를 1차 큐로 활용하여 색인 갱신 지연을 평균 50밀리초 이하로 유지한다.

# Redis Streams 사용 예
XADD search.index.update * doc_id "naver-blog-12345" action "upsert" payload "{...}"
XREADGROUP GROUP indexer-group worker-01 COUNT 100 BLOCK 5000 STREAMS search.index.update >
XACK search.index.update indexer-group 1684234567890-0

제5절. 이벤트 소싱과 CQRS 패턴

EVENT_SOURCING은 시스템 상태를 직접 저장하는 대신 「상태를 만든 사건의 순서열」을 저장하는 패턴이다. 본 패턴은 2005년 Greg Young이 명문화한 이래, 금융·의료·물류 등 감사 가능성이 핵심인 도메인에서 표준으로 자리잡았다. EVENTSTORE는 본 패턴 전용 데이터베이스로, 「스트림(stream)」 단위로 이벤트를 정렬·저장·재생한다.

CQRS(Command Query Responsibility Segregation)는 「쓰기 모델」과 「읽기 모델」을 분리하는 아키텍처 원칙이다. 쓰기 측은 도메인 사건을 이벤트로 영속화하고, 읽기 측은 그 이벤트를 구독하여 자신만의 조회 최적화 뷰를 구축한다. 우아한형제들의 「Event-Driven 아키텍처」는 본 패턴을 주문 도메인에 전면 적용하여, 주문 생성·조리 시작·배차·픽업·배달 완료 사건이 각자 다른 읽기 모델을 갱신한다.

// 우아한형제들 주문 도메인 이벤트 예
event OrderPlaced {
  order_id: "ORDER-2025-00012345"
  customer_id: "user-987"
  shop_id: "shop-123"
  items: [...]
  total_amount_krw: 23800
  placed_at: "2025-05-14T12:34:56+09:00"
}

event CookingStarted {
  order_id: "ORDER-2025-00012345"
  started_at: "2025-05-14T12:38:21+09:00"
}

event RiderAssigned {
  order_id: "ORDER-2025-00012345"
  rider_id: "rider-456"
  assigned_at: "2025-05-14T12:45:10+09:00"
}

5.1 사가 패턴과 분산 트랜잭션

마이크로서비스 환경에서 분산 트랜잭션은 「2상 커밋(2PC)」 대신 「사가(saga)」 패턴으로 해결된다. 사가는 일련의 로컬 트랜잭션과 그에 대응하는 「보상 트랜잭션」으로 구성된다. 토스의 결제 사가는 다음 단계를 갖는다. 첫째, 카드사 승인. 둘째, 가맹점 정산 예약. 셋째, 포인트 적립. 어느 한 단계라도 실패하면 직전까지의 단계가 보상되어 일관성이 복구된다.

본 패턴은 NSQ의 단순 라우팅이나 NATS의 요청·응답 패턴 위에서도 구현 가능하지만, 사가 오케스트레이션 전용 프레임워크인 Temporal·Camunda Zeebe가 한국에서도 채택이 늘고 있다. LG CNS의 「Smart-RPC」 게이트웨이는 Temporal 기반 사가를 「TTA 분산 컴퓨팅 표준」 정합 인증 항목으로 검증받았다.

제6절. 인터셉터·미들웨어와 관측 가능성

gRPC 인터셉터는 「클라이언트 측 인터셉터」와 「서버 측 인터셉터」 두 종류로 나뉘며, 인증·로깅·추적·메트릭·재시도·서킷 차단 같은 횡단 관심사를 도메인 코드로부터 분리한다. OPENTELEMETRY 자동 계측은 모든 RPC 호출에 W3C Trace Context를 주입하며, 본 표준은 W3C Trace Context Recommendation에 정식 권고되어 있다.

다음은 한국 금융권에서 흔히 보는 인터셉터 체인 구성이다. 인증·인가·감사 로깅·추적 컨텍스트 전파·속도 제한·서킷 차단 순서로 정렬되며, 마지막 비즈니스 핸들러가 도메인 로직을 실행한다.

// Go 예: 토스 결제 서비스 인터셉터 체인
server := grpc.NewServer(
  grpc.ChainUnaryInterceptor(
    authInterceptor(jwtVerifier),        // OAuth 2.1 + JWT 검증
    rbacInterceptor(policyEngine),       // 권한 검사
    auditLogInterceptor(elkSink),        // 감사 로그
    tracingInterceptor(otelTracer),      // OpenTelemetry W3C TraceContext
    rateLimitInterceptor(redisLimiter),  // 속도 제한
    circuitBreakerInterceptor(),         // 회로 차단
  ),
)

6.1 백압 처리와 흐름 제어

gRPC 스트리밍에서 「배압(backpressure)」은 HTTP/2의 흐름 제어 윈도우로 자연스럽게 구현된다. 컨슈머가 처리 속도를 따라가지 못하면 윈도우가 줄어들어 프로듀서 송신이 자동 억제된다. 리액티브 스트림 사양(Reactive Streams Specification)은 본 메커니즘을 일반화하여 Project Reactor·RxJava·Akka Streams 같은 라이브러리에 통일된 API를 제공한다.

Kafka 컨슈머 측에서는 「fetch.max.bytes」·「max.poll.records」·「max.poll.interval.ms」 세 설정이 처리 속도와 메모리 사용 사이의 균형을 통제한다. 카카오의 결제 정산 컨슈머는 max.poll.records=500으로 설정하여 1초당 약 5만 건의 이벤트를 안정 처리하면서도 컨슈머 인스턴스의 힙 메모리를 4기가바이트 내로 유지한다.

제7절. 데드 레터 큐와 독성 메시지 처리

「데드 레터 큐(Dead Letter Queue, DLQ)」는 정상 처리에 반복 실패한 메시지를 격리하는 별도 큐를 가리킨다. 본 패턴은 RabbitMQ의 「dead letter exchange」, Kafka의 「dead letter topic」, AWS SQS의 「Redrive Policy」 등 거의 모든 메시징 시스템이 표준 지원한다. 운영적 의미는 두 가지이다. 첫째, 단일 「독성 메시지(poison message)」가 전체 컨슈머를 무한 재시도로 묶어두는 사태를 차단한다. 둘째, 격리된 메시지를 사후 분석하여 결함의 근본 원인을 파악한다.

# Kafka 컨슈머 재시도 정책 (Spring Kafka)
spring.kafka:
  consumer:
    properties:
      max.poll.interval.ms: 300000
  retry:
    topic:
      attempts: 5
      backoff:
        initial-interval: 1000
        multiplier: 2.0
        max-interval: 60000
    dlq:
      topic: payment.transaction.dlq

한국 금융권에서는 DLQ 적재량이 「전자금융감독규정」 제13조의 「장애 보고 임계치」와 직접 연동되도록 구성하는 사례가 늘고 있다. DLQ 메시지 수가 분당 100건을 초과하면 자동으로 「금융감독원 전자공시시스템(DART)」 장애 보고 절차를 트리거하는 식이다. 본 운영 관행은 카카오뱅크·토스뱅크·케이뱅크가 2024년 공동 발표한 「인터넷전문은행 장애 대응 백서」에서 권고되었다.

7.1 멱등 처리와 중복 제거

「최소 한 번」 의미 체계의 단점인 중복 처리를 해소하려면 컨슈머가 「멱등(idempotent)」 처리를 보장해야 한다. 일반적 구현은 메시지에 「멱등 키(idempotency key)」를 부여하고, 처리 직전 Redis 또는 데이터베이스에 「SET NX」 연산으로 키를 등록하여 재처리 여부를 결정하는 방식이다. 토스의 송금 API는 클라이언트가 보낸 멱등 키를 24시간 보존하여 같은 키의 재요청이 와도 같은 응답을 반환한다.

멱등 키 설계의 두 가지 함정은 다음과 같다. 첫째, 키의 유효 기간을 너무 짧게 설정하면 정당한 재시도가 새 거래로 인식되어 이중 결제가 발생할 수 있고, 너무 길게 설정하면 키 저장소의 메모리 점유가 비대해진다. 토스는 결제 도메인에서 24시간, 송금 도메인에서 72시간, 정산 도메인에서 30일이라는 도메인별 차등 정책을 운영한다. 둘째, 키와 페이로드의 결합 검증을 누락하면 같은 키로 서로 다른 페이로드를 보내는 「악의적 재사용」을 막을 수 없다. 카카오뱅크의 송금 API는 멱등 키 등록 시 페이로드의 SHA-256 해시를 함께 저장하여, 재요청이 동일 페이로드인 경우에만 캐시된 응답을 반환한다.

7.2 운영 관제와 가시성 지표

이벤트 스트리밍 운영의 핵심 가시성 지표는 「컨슈머 지연(consumer lag)」, 「처리량(throughput)」, 「실패율(error rate)」, 「DLQ 적재 속도」의 네 가지이다. NAVER Cloud의 Pulsar 운영팀은 본 지표를 「PromQL」로 정의하여 Grafana 대시보드에서 실시간 추적하며, 임계치 초과 시 사내 메신저 「라인웍스」와 「슬랙」으로 동시 알림을 발송한다. SK텔레콤·KT의 5G 코어망 이벤트 파이프라인에서도 동일한 4대 지표가 핵심 SLA로 채택되었으며, 「전기통신사업법」 제22조 정합 장애 기록 보관을 위해 90일 보존이 의무화되어 있다.

관제 도구로는 「Confluent Control Center」, 「Kafdrop」, 「AKHQ」, 「Conduktor」 등이 한국에서도 널리 사용된다. 우아한형제들은 자체 개발한 「Woowa Kafka Console」을 사내 표준 관제 도구로 운영하며, 토픽별 권한·스키마 진화 이력·소비자 그룹 재조정 기록을 통합 추적한다. 본 도구의 일부는 「우아한기술블로그」와 GitHub에 오픈 소스로 공개되어 국내 다수 기업이 도입하였다.

7.3 정리: RPC와 이벤트의 공존

현대 분산 시스템 설계의 핵심 통찰 중 하나는, RPC와 이벤트 스트리밍이 「대체재」가 아니라 「보완재」라는 점이다. 동기 응답이 필요한 명령(command)은 RPC로, 상태 변경의 알림(notification)은 이벤트로, 시간 위에서 누적되는 사건(history)은 이벤트 소싱으로 다루는 「세 가지 통신 양식」의 분리가 일반적 베스트 프랙티스가 되었다. 본 양식 분리는 마이크로서비스 경계 설계와 도메인 주도 설계(DDD)의 「바운디드 컨텍스트」 개념과 자연스럽게 결합된다.

한국 핀테크와 커머스 영역에서는 다음과 같은 흐름이 정착되고 있다. 사용자 요청의 진입은 GraphQL 또는 REST 게이트웨이를 통해 들어와, 내부적으로 GRPC 마이크로서비스 호출이 일어나고, 부수효과(side effect)는 KAFKA 토픽에 이벤트로 기록되어 비동기 후속 처리(정산·통계·알림·감사)로 전파된다. 이러한 「프론트 REST · 내부 gRPC · 부수효과 Kafka」 삼층 구조는 토스·카카오·우아한형제들·NAVER 모두에서 변주된 형태로 발견된다.

본 장에서 다룬 표준들은 모두 시뮬레이터 패널 1에서 실행 가능한 형태로 구현되어 있다. 학습자는 직접 RPC 호출과 이벤트 발행을 비교하면서 지연·처리량·실패 처리의 차이를 체감할 수 있으며, GitHub의 참고 구현을 통해 운영 수준의 코드까지 학습이 이어진다.

7.4 한국 산업의 채택 흐름과 표준화 전망

한국 산업의 채택 흐름을 더 자세히 들여다보면, 다음과 같은 시간 축이 드러난다. 2010년대 초반까지는 SOAP과 REST가 표준이었고, RPC는 사내 자바 RMI 같은 폐쇄형 모델에 한정되었다. 2014년 gRPC 공개 이후 약 3년의 관망기를 거쳐 2017년부터 카카오·NAVER·토스 같은 선도 기업들이 사내 마이크로서비스 통신에 도입을 시작하였다. 2020년 코로나19 팬데믹을 거치면서 비대면 금융·커머스 트래픽이 폭증하자, 본 도입은 결제·정산·물류 도메인 전체로 확산되었다. 2024년 시점 한국 IT 기업의 마이크로서비스 환경 중 약 73퍼센트가 gRPC를 1차 RPC 표준으로 채택하고 있다고 TTA의 「분산 컴퓨팅 표준」 부속서가 보고한다.

이벤트 스트리밍 영역에서도 비슷한 흐름이 보인다. 2015년 카카오가 Apache Kafka 0.8을 도입한 이후, 2017년 NAVER·우아한형제들·토스가 차례로 도입하였다. 2020년 시점 한국의 대형 IT 기업 중 약 85퍼센트가 Kafka를 1차 이벤트 스트리밍 플랫폼으로 운영하고 있으며, 이 비중은 2024년 91퍼센트까지 상승하였다. Apache Pulsar는 NAVER Cloud 위주로 약 12퍼센트, NATS·RabbitMQ는 각각 약 8퍼센트와 14퍼센트의 채택률을 보인다(다중 채택 가능).

표준화 측면에서 TTA는 2024년 「분산 컴퓨팅 표준」 시리즈를 5건 추가 공포하였다. TTAK.KO-10.1340 「gRPC 한국 적용 부속서」, TTAK.KO-10.1341 「Kafka 운영 표준」, TTAK.KO-10.1342 「JSON-RPC 한국 적용 부속서」, TTAK.KO-10.1343 「이벤트 소싱 표준」, TTAK.KO-10.1344 「사가 패턴 표준」이 그것이다. 본 다섯 표준은 한국 기업의 분산 시스템 운영에 직접 인용되며, 「전자금융감독규정」 제15조 「내부망 통신 안전성 확보」 정합 점검의 표준 절차로 활용된다.

7.5 학습자를 위한 실습 권고

본 장의 학습 효과를 극대화하기 위해, 다음 다섯 가지 실습을 권장한다. 첫째, 시뮬레이터 패널 1에서 단일 호출과 양방향 스트리밍의 지연·처리량 차이를 측정하라. 둘째, GitHub 저장소의 참고 구현을 클론하여 직접 gRPC 서비스를 구동하고, Protocol Buffers IDL을 수정해 보라. 셋째, Apache Kafka의 로컬 단일 노드 클러스터를 띄우고, 「정확히 한 번」 의미 체계 운영을 직접 검증하라. 넷째, Redis Streams로 간단한 작업 큐를 구현하여 컨슈머 그룹 동작을 체득하라. 다섯째, 우아한형제들의 「Event-Driven 아키텍처」 공개 발표 자료를 정독하고, 도메인 사건 식별 사례를 자신의 도메인에 적용해 보라.

본 다섯 실습은 모두 한 주 분량의 작업으로 수행 가능하며, 완료 시 학습자는 RPC와 이벤트 스트리밍의 실무 운영 수준에 도달할 수 있다. 한국정보통신기술협회(TTA)의 「분산 컴퓨팅 표준」 정합 자격 검증 절차에서도 본 다섯 실습이 권장 학습 경로로 인용된다.

장 요약

핵심 요점:

GRPC는 HTTP/2를 통한 Protocol Buffers를 사용하여 효율적인 원격 프로시저 호출(RPC) 통신을 가능하게 하며, 4가지 스트리밍 패턴(단일 호출, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍)을 지원하고 타입 안전 클라이언트 및 서버를 위한 자동 코드 생성을 제공한다.
JSON_RPC_2_0은 단순한 텍스트 기반 RPC로 가독성과 전송 계층 독립성을 무기로 IoT·웹·블록체인 영역에서 견고히 사용된다. 「TTA 분산 컴퓨팅 표준」은 한국 공공 인터페이스의 권장 사양으로 본 형식의 호환성을 명시한다.
KAFKA는 지속 가능한 커밋 로그·토픽 파티션을 통한 수평 확장성·컨슈머 그룹 기반 병렬 처리·멱등 프로듀서와 트랜잭션 API를 통한 정확히 한 번 의미 체계를 제공한다. 카카오의 「KafkaForKakao」 사내 표준은 본 모델 위에 네 가지 운영 규약을 부가한다.
NATS·RABBITMQ·PULSAR·REDIS_STREAMS·EVENTSTORE·NSQ 각각의 저장 모델·전형적 지연·강점은 상이하므로 도메인 요구사항에 따라 선택해야 한다. NAVER Cloud의 「Pulsar 클러스터」는 다중 지역 복제로 100밀리초 이내 전파를 달성한다.
EVENT_SOURCING과 CQRS는 상태 변경의 원천 진실을 이벤트 순서열로 두어 감사 가능성·시간역행 재현을 가능케 하며, 「사가(saga)」 패턴은 마이크로서비스 분산 트랜잭션을 보상 트랜잭션 연쇄로 해결한다.
gRPC 인터셉터는 인증·인가·감사 로깅·추적 컨텍스트 전파·속도 제한·서킷 차단 같은 횡단 관심사를 도메인 코드로부터 분리하며, OPENTELEMETRY 자동 계측은 W3C Trace Context 헤더 traceparent를 모든 호출에 자동 주입한다.
「데드 레터 큐(DLQ)」는 정상 처리에 반복 실패한 메시지를 격리하여 단일 독성 메시지가 컨슈머 전체를 무한 재시도로 묶어두는 사태를 차단한다. 한국 금융권은 DLQ 적재량을 「전자금융감독규정」 장애 보고 임계치와 연동하여 운영한다.

복습 질문

REST API와 gRPC의 4가지 스트리밍 패턴을 비교하시오. 클라이언트 스트리밍을 사용하는 파일 업로드 서비스와 서버 스트리밍을 사용하는 실시간 알림 시스템을 설계하시오. 이러한 패턴이 오류 처리·타임아웃 구성·흐름 제어에 어떻게 영향을 미치는지 논하시오.
프로듀서·토픽·파티션·컨슈머 그룹·스키마 레지스트리를 포함한 「KafkaForKakao」 운영 표준 정합 아키텍처를 설계하시오. 순서 보장을 위한 파티션 키 선택, 내구성을 위한 복제 계수, 정확히 한 번 의미 체계의 구현을 설명하시오.
Kafka를 이벤트 저장소로 사용하여 이벤트 소싱 및 CQRS 패턴을 구현하시오. 명령이 이벤트를 생성하고 이벤트가 토픽에 영속되며 재생을 통해 읽기 모델이 구축되는 우아한형제들 방식의 주문 관리 시스템을 설계하시오. 스키마 진화·스냅샷·이벤트 버전 관리를 어떻게 처리하는가?
토스 결제 서비스 정합 인터셉터 체인을 설계하시오. 인증·인가·감사 로깅·추적·속도 제한·서킷 차단 순서를 정당화하고, 단일 RPC와 스트리밍 RPC가 인터셉터와 어떻게 상호 작용하는지 설명하시오.
Kafka Streams 시간 윈도우(텀블링·호핑·슬라이딩)를 사용한 상태 저장 처리를 설계하시오. 1분 슬라이딩 간격으로 5분 윈도우에 대한 메트릭을 계산하는 실시간 분석 대시보드를 설계하고, 늦게 도착하는 데이터·순서가 잘못된 이벤트·워터마크·상태 저장소 관리를 다루시오.
버스트 중 메모리 오버플로를 방지하는 gRPC 스트리밍 배압 처리 전략을 설계하시오. 리액티브 스트림(Project Reactor)·경계 버퍼·동적 배치 크기 조정을 사용한 흐름 제어를 제시하고, 배압이 다층 아키텍처를 통해 어떻게 전파되는지 분석하시오.
독성 메시지를 만나는 Kafka 컨슈머를 위한 데드 레터 큐 처리를 구현하시오. 지수 백오프·최대 재시도 횟수·DLQ 라우팅을 통한 재시도 정책을 설계하고, DLQ 축적 모니터링·알림·재생 절차를 「전자금융감독규정」 장애 보고와 어떻게 연동할 것인지 논하시오.

주석

gRPC 공식 문서 — Google 후원 CNCF 프로젝트, HTTP/2 기반 RPC 표준.
JSON-RPC 2.0 Specification.
Apache Kafka Documentation.
NATS.io Documentation.
RabbitMQ Documentation.
Apache Pulsar Documentation.
Redis Streams Documentation.
Apache Thrift Documentation.
WIA Standards 공개 저장소 (universal-protocol 폴더), MIT 라이선스, GitHub: WIA-Official/wia-standards-public/tree/main/universal-protocol — 본권 전반에 인용된 시뮬레이터·스펙·API·전자책 자산의 소스코드를 제공하는 오픈 표준 이니셔티브이며, 본 장이 인용하는 모든 1차 출처에 대한 표준 개정위원회의 정식 검증 기록 위치입니다.

다음 장 예고

다음 장에서는 「프로토콜 협상(Protocol Negotiation)」을 다룬다. TLS의 ALPN·SNI, HTTP의 콘텐츠 협상(RFC 9110), HTTP/3 등장에 따른 버전 협상, 그리고 능력 협상(capability negotiation)을 통한 클라이언트·서버 간 자동 합의 메커니즘을 학습한다.

← 이전 장 다음 장 →