이런 분이 읽으면 좋습니다
요약: 네트워크 통신 프로토콜은 “최고”가 없다. REST, gRPC, MQTT, DDS, WebSocket, AMQP, NATS, Kafka Protocol은 각각 다른 제약 조건에서 최적이다. 이 글은 8개 프로토콜의 통신 모델, 성능 특성, 적합 분야를 2026년 기준으로 비교하고, 시스템의 요구사항에 따른 선택 기준을 정리한다. 결론부터 말하면, 대부분의 프로덕션 시스템은 2~3개 프로토콜을 조합해서 쓴다.
이 글은 시스템 아키텍처를 설계하면서 통신 레이어를 결정해야 하는 개발자와 아키텍트를 위해 썼다. “gRPC가 REST보다 빠르다”는 단편적 정보가 아니라, 각 프로토콜이 어떤 트레이드오프를 갖는지 구조적으로 이해하는 것이 목표다.
한눈에 보기: 8개 프로토콜 특성 비교
| 통신 모델 | 전송 계층 | 직렬화 | 주 활용 분야 | |
|---|---|---|---|---|
| REST/HTTP | 요청-응답 (1:1) | HTTP/1.1 또는 HTTP/2 | JSON, XML | 공개 API, 웹 서비스, CRUD |
| gRPC | 단방향/양방향 스트리밍 | HTTP/2 (필수) | Protocol Buffers | 마이크로서비스 간 통신, 저지연 API |
| MQTT | 발행-구독 (N:N) | TCP (또는 WebSocket) | 바이너리 페이로드 | IoT, 임베디드, 제한된 네트워크 |
| DDS | 발행-구독 (P2P) | UDP 멀티캐스트 / TCP | CDR (XCDR) | 군사, 자율주행, 로보틱스 (ROS 2) |
| WebSocket | 전이중 (1:1) | TCP (HTTP 업그레이드) | 텍스트/바이너리 자유 | 실시간 웹: 채팅, 게임, 대시보드 |
| AMQP | 큐/교환기 기반 라우팅 | TCP | 바이너리 프레임 | 엔터프라이즈 메시징, 안정적 전달 |
| NATS | 발행-구독 / 요청-응답 | TCP | 텍스트 (또는 바이너리) | 클라우드 네이티브 메시징, 엣지 |
| Kafka Protocol | 분산 로그 (소비자 그룹) | TCP | 바이너리 (자체 포맷) | 이벤트 스트리밍, 데이터 파이프라인 |
성능 비교: 지연, 처리량, 오버헤드
| 지연(latency) | 처리량(throughput) | 메시지 오버헤드 | 연결 방식 | |
|---|---|---|---|---|
| REST/HTTP | 중간 (10~100ms) | 중간 | 높음 (HTTP 헤더 + JSON) | 비연결 (커넥션 풀 가능) |
| gRPC | 낮음 (1~10ms) | 높음 | 낮음 (Protobuf 바이너리) | HTTP/2 다중화 |
| MQTT | 낮음 (1~50ms) | 중간 | 매우 낮음 (2바이트 헤더) | 영구 연결 |
| DDS | 매우 낮음 (<1ms) | 매우 높음 | 낮음 (CDR 바이너리) | P2P 직접 연결 |
| WebSocket | 낮음 (1~10ms) | 중간~높음 | 낮음 (2~14바이트 프레임) | 영구 연결 |
| AMQP | 중간 (5~50ms) | 중간~높음 | 중간 (프레임 헤더) | 브로커 경유 |
| NATS | 매우 낮음 (<1ms) | 높음 | 매우 낮음 (텍스트 프로토콜) | 영구 연결 |
| Kafka Protocol | 중간 (5~100ms) | 매우 높음 | 중간 (배치 최적화) | 브로커 경유 |
프로토콜별 상세 분석
REST/HTTP — 모든 것의 기본값
강점: 보편성(모든 언어, 모든 플랫폼 지원), HTTP 캐싱/CDN 활용, 도구 생태계(Postman, Swagger/OpenAPI), 학습 곡선 거의 없음
약점: JSON 직렬화/역직렬화 비용, HTTP/1.1 기준 요청-응답당 연결 오버헤드, 양방향 통신 불가, 강타입 계약 부재(OpenAPI로 보완 가능)
2026년 현황: 공개 API의 기본값으로 여전히 압도적이다. HTTP/2 채택이 확산되면서 성능 격차가 줄었고, OpenAPI 3.1 + 코드 생성 도구가 성숙해지면서 타입 안전성 문제도 완화됐다. 하지만 내부 마이크로서비스 통신에서는 gRPC에 밀리는 추세.
선택 기준: 외부 개발자가 소비하는 공개 API, 브라우저에서 직접 호출하는 API, 팀이 작고 단순함이 우선일 때.
gRPC — 마이크로서비스의 사실상 표준
강점: Protocol Buffers 기반 강타입 계약과 코드 생성, HTTP/2 다중화로 하나의 연결에서 여러 스트림 동시 처리, 양방향 스트리밍, 언어 중립적 IDL(Interface Definition Language)
약점: 브라우저에서 직접 호출 불가(gRPC-Web 프록시 필요), 사람이 읽을 수 없는 바이너리 포맷(디버깅 불편), 로드밸런서/프록시의 HTTP/2 지원 필요, .proto 파일 관리 부담
2026년 현황: 마이크로서비스 간 동기 통신에서 REST를 빠르게 대체하고 있다. Envoy, Istio 등 서비스 메시와의 통합이 성숙했고, gRPC-Web + Connect 프로토콜이 브라우저 지원 문제를 완화했다. Google, Netflix, Uber 등 대규모 시스템에서 사실상 표준.
선택 기준: 서비스 간 통신이 빈번하고 지연에 민감할 때, 다중 언어 환경에서 API 계약을 강제해야 할 때.
MQTT — IoT의 링구아 프랑카
강점: 극도로 가벼운 프로토콜(최소 헤더 2바이트), 3단계 QoS(0: 최대 1회, 1: 최소 1회, 2: 정확히 1회), 유언(Will) 메시지로 디바이스 오프라인 감지, 제한된 네트워크(3G, 위성)에서도 안정적
약점: 브로커 의존(EMQX, Mosquitto, HiveMQ), 토픽 기반 라우팅만 지원(복잡한 라우팅 불가), 메시지 크기 제한은 없지만 대용량 전송에 비적합, 보안은 TLS에 의존
2026년 현황: MQTT 5.0이 보편화되면서 공유 구독, 메시지 만료, 요청-응답 패턴이 추가됐다. AWS IoT Core, Azure IoT Hub가 네이티브 지원하면서 클라우드 IoT의 기본 프로토콜로 확고히 자리잡았다.
선택 기준: 수천~수백만 대의 디바이스가 소량 데이터를 간헐적으로 전송하는 IoT 시나리오. 배터리/대역폭 제한이 있는 환경.
DDS — 하드 리얼타임의 유일한 선택
강점: OMG 표준 기반 벤더 중립, 브로커 없는 P2P 아키텍처(단일 장애점 제거), 23개 QoS 정책(신뢰성, 데드라인, 활성도, 내구성 등 세밀한 제어), UDP 멀티캐스트로 마이크로초 단위 지연
약점: 높은 학습 곡선(QoS 정책 조합이 복잡), 상용 구현체(RTI Connext, eProsima Fast DDS) 라이선스 비용, 웹 생태계와의 통합 어려움, 디버깅 도구 부족
2026년 현황: ROS 2의 기본 미들웨어로 로보틱스 생태계에서 입지가 강화됐다. 자율주행(Autoware), 군사 시스템(DDS-Security 표준 완성), 산업용 IoT에서 핵심. 다만 웹/클라우드 네이티브 영역으로의 확산은 제한적.
선택 기준: 마이크로초 단위 지연이 요구되는 하드 리얼타임 시스템, 브로커 없는 P2P 통신이 필요한 경우, 군사/항공/자율주행 등 미션 크리티컬 시스템.
WebSocket — 실시간 웹의 기본 채널
강점: 단일 TCP 연결 위에서 전이중 통신, HTTP 업그레이드로 기존 인프라(프록시, 로드밸런서)와 호환, 브라우저 네이티브 지원, 프레임 오버헤드가 극히 작음(2~14바이트)
약점: 상태 유지(stateful) 연결이므로 수평 확장 어려움(스티키 세션 또는 Redis Pub/Sub 필요), 연결 끊김 시 재연결 로직 직접 구현 필요, 메시지 순서/전달 보장이 TCP 수준에 의존
2026년 현황: Socket.IO, Ably, Pusher 등 관리형 서비스가 확장 문제를 해결하면서 채택이 더 쉬워졌다. 하지만 서버 간 통신에는 거의 쓰이지 않으며, 브라우저-서버 실시간 통신에 특화.
선택 기준: 채팅, 실시간 대시보드, 온라인 게임, 주식 시세 등 브라우저에서 서버 푸시가 필요한 모든 경우.
AMQP — 엔터프라이즈 메시징의 중심
강점: 교환기(Exchange), 큐(Queue), 바인딩(Binding)으로 유연한 라우팅(직접, 팬아웃, 토픽, 헤더), 메시지 영속성과 확인(acknowledgment) 보장, 트랜잭션 지원, RabbitMQ 생태계
약점: 브로커 의존(브로커가 병목이 될 수 있음), 프로토콜 자체가 복잡(AMQP 0-9-1과 1.0이 호환되지 않음), Kafka 대비 처리량 한계, 설정과 튜닝에 전문 지식 필요
2026년 현황: RabbitMQ 4.x가 Khepri 합의 엔진을 도입하면서 클러스터 안정성이 크게 개선됐다. 하지만 이벤트 스트리밍 영역에서는 Kafka에, 경량 메시징에서는 NATS에 시장을 내주고 있다. 복잡한 라우팅 로직이 필요한 엔터프라이즈에서 여전히 강세.
선택 기준: 메시지 라우팅 로직이 복잡하고(조건부 분배, 우선순위 큐), 정확한 전달 보장이 필수인 엔터프라이즈 시스템.
NATS — 클라우드 네이티브의 신흥 강자
강점: 극도로 가벼운 바이너리(10MB 미만), 설정 거의 불필요(zero-config), 마이크로초 단위 지연, JetStream으로 영속성/정확히 한 번 전달 지원, 멀티 테넌시 네이티브
약점: JetStream 없는 Core NATS는 메시지 영속성 없음(fire-and-forget), Kafka 대비 생태계(커넥터, 스트림 처리)가 작음, 대규모 운영 사례가 Kafka보다 적음
2026년 현황: CNCF 인큐베이팅 프로젝트에서 졸업하며 클라우드 네이티브 메시징의 표준으로 부상 중. Synadia가 상용 지원을 강화했고, 엣지 컴퓨팅에서 NATS Leaf Node가 각광받고 있다. Kafka를 대체하기보다는 보완하는 위치.
선택 기준: 클라우드 네이티브 환경에서 서비스 간 경량 메시징, 엣지-클라우드 연결, 설정 복잡성을 최소화하고 싶을 때.
Kafka Protocol — 이벤트 스트리밍의 왕
강점: 분산 커밋 로그로 메시지 영구 보존(리플레이 가능), 소비자 그룹으로 수평 확장, 초당 수백만 메시지 처리, 정확히 한 번 전달(EOS) 지원, 커넥터 생태계(Kafka Connect)
약점: 운영 복잡성(ZooKeeper/KRaft, 파티션 관리, 리밸런싱), 지연이 상대적으로 높음(배치 최적화 때문), 리소스 소비가 큼(디스크, 메모리), 단순 메시징에는 과도한 선택
2026년 현황: KRaft 모드가 완전 안정화되면서 ZooKeeper 의존이 제거됐다. WarpStream, Redpanda 등 Kafka 호환 대안이 등장했지만 Kafka 프로토콜 자체가 사실상 표준. Confluent의 Flink 통합으로 스트림 처리 파이프라인이 성숙.
선택 기준: 이벤트 소싱, 데이터 파이프라인, 로그 집계, 메시지 리플레이가 필요한 대규모 시스템. “메시지를 보내고 끝”이 아니라 “메시지 히스토리를 보존하고 재처리”해야 할 때.
시나리오별 선택 가이드
| 최적 프로토콜 | 대안 | 피해야 할 선택 | |
|---|---|---|---|
| 공개 REST API | REST/HTTP | gRPC (+ gRPC-Web) | MQTT, DDS (브라우저 미지원) |
| 마이크로서비스 간 동기 통신 | gRPC | REST/HTTP (단순한 경우) | WebSocket (서버 간 부적합) |
| IoT 디바이스 데이터 수집 | MQTT | AMQP (리소스 여유 시) | gRPC (임베디드 지원 제한) |
| 자율주행/로보틱스 리얼타임 | DDS | 없음 (대안 부재) | REST, Kafka (지연 초과) |
| 실시간 웹 (채팅, 대시보드) | WebSocket | SSE (단방향이면) | REST 폴링 (비효율) |
| 엔터프라이즈 워크플로우 | AMQP (RabbitMQ) | NATS (단순한 경우) | Kafka (과도한 인프라) |
| 클라우드 네이티브 서비스 메시징 | NATS | Kafka (영속성 필요 시) | AMQP (클라우드 비친화) |
| 이벤트 스트리밍/데이터 파이프라인 | Kafka | Redpanda / NATS JetStream | MQTT, REST (설계 목적 불일치) |
피해야 할 흔한 실수 5가지
1. “gRPC가 빠르니까 모든 곳에 gRPC”: gRPC는 내부 서비스 간 통신에 탁월하지만, 공개 API에 쓰면 클라이언트 SDK 생성 부담이 생기고 브라우저 호환 문제가 발생한다. 공개 API는 REST, 내부는 gRPC가 표준 조합이다.
2. “Kafka를 메시지 큐로 사용”: Kafka는 메시지 큐가 아니라 분산 로그다. 단순한 작업 큐에 Kafka를 쓰면 운영 복잡성만 늘어난다. 작업 큐에는 RabbitMQ나 Redis가 적합하다.
3. “MQTT QoS 2를 기본으로 설정”: QoS 2(정확히 1회)는 4단계 핸드셰이크가 필요해서 지연이 크게 늘어난다. 센서 데이터 수집처럼 중복이 허용되는 경우 QoS 0이나 1이면 충분하다.
4. “WebSocket으로 서버 간 통신”: WebSocket은 브라우저-서버 통신을 위해 설계됐다. 서버 간에는 gRPC의 양방향 스트리밍이나 NATS가 훨씬 효율적이다.
5. “DDS를 일반 IoT에 도입”: DDS의 23개 QoS 정책은 강력하지만, 제대로 설정하지 않으면 오히려 성능이 나빠진다. 하드 리얼타임이 아닌 IoT에는 MQTT가 거의 항상 정답이다.
결론: 제약 조건이 답이다
통신 프로토콜 선택은 다음 순서로 좁혀진다:
- 통신 패턴은 무엇인가? — 요청-응답이면 REST/gRPC, 발행-구독이면 MQTT/NATS/Kafka, 전이중이면 WebSocket/gRPC 스트리밍
- 지연 요구사항은? — 마이크로초면 DDS, 밀리초면 gRPC/NATS, 수십 밀리초 이상 허용이면 REST/Kafka
- 메시지 보장 수준은? — 유실 허용이면 NATS Core/MQTT QoS 0, 최소 1회면 대부분 가능, 정확히 1회면 Kafka EOS/MQTT QoS 2
- 팀이 운영할 수 있는가? — 가장 결정적이면서 가장 자주 무시되는 제약
이 네 질문에 답하면 선택지는 1~2개로 좁혀진다. 여러 프로토콜을 조합해야 한다면, 각 레이어의 역할을 명확히 분리하라. “외부 API는 REST, 내부 동기 호출은 gRPC, 비동기 이벤트는 Kafka”처럼 레이어별로 하나씩 배정하는 것이 운영 가능한 아키텍처의 핵심이다.
다음에 읽을 글
- REST vs GraphQL vs tRPC: 2026 선택 가이드 — REST를 선택했다면, API 레이어의 다음 결정은 데이터 페칭 패턴이다
- 소프트웨어 아키텍처 진화사: 메인프레임에서 AI 에이전트까지 — 통신 프로토콜보다 큰 그림, 아키텍처 패러다임의 60년 변천사