Kafka vs RabbitMQ vs SQS: 세 메시징 시스템을 같은 표 위에 올려놓기

이 글은 메시징/이벤트 시리즈 2편입니다.

• 1편: 메시징과 이벤트 깊게 보기: 큐, 로그, 전달 보장, 그리고 이벤트 기반 아키텍처
• 3편: Kafka 깊게 보기: 분산 로그, 파티션, 컨슈머 그룹, exactly-once
• 4편: RabbitMQ 깊게 보기: AMQP, exchange, ack, prefetch, DLX

1편에서 메시징의 개념 좌표축을 잡았습니다. 큐냐 로그냐, 전달 보장은 어디까지, 순서는 어느 단위로 — 이제 그 좌표축 위에 Kafka, RabbitMQ, SQS를 올려놓을 차례입니다.

세 도구를 "메시지 보내는 도구"로 뭉뚱그리면 선택이 어렵습니다. 하지만 각자의 출신을 알면 의외로 명확해집니다. Kafka는 분산 로그에서, RabbitMQ는 메시지 브로커에서, SQS는 관리형 큐에서 출발했습니다. 같은 일을 일부 겹쳐서 하지만, 잘하는 일이 다릅니다.

한눈에 보면

• Kafka: 분산 로그. 높은 처리량, 보존·replay, 다수 구독자, 이벤트 스트림에 강함. 대신 운영이 무겁습니다.
• RabbitMQ: 스마트 브로커. 유연한 라우팅, 작업 분배, 낮은 지연, per-message 제어에 강함. 초고처리량 스트림에는 부적합.
• SQS: 완전 관리형 큐. 운영 부담이 거의 없고 AWS와 잘 붙음. 대신 라우팅·replay·순서·처리량에 제약이 있습니다.
• 고르는 한 줄: 이벤트 스트림·재처리·대용량이면 Kafka, 유연한 라우팅·작업 큐면 RabbitMQ, AWS에서 운영 없이 단순 큐면 SQS.

세 가지 멘탈 모델

비교표로 들어가기 전에, 각 도구를 한 문장으로 그려야 합니다.

Kafka = 추가 전용 분산 로그

메시지를 파티션이라는 추가 전용 로그에 차곡차곡 쌓고, 소비자는 각자 offset을 들고 읽습니다. 소비해도 메시지는 안 사라지고 보존 기간 동안 남습니다. "이벤트의 흐름을 기록하는 거대한 로그 파일"을 떠올리면 됩니다.

flowchart LR
  P[Producer] --> Part[(Partition 0..N<br/>append-only log)]
  Part --> CG1[Consumer Group A]
  Part --> CG2[Consumer Group B]

RabbitMQ = 똑똑한 라우터가 달린 큐

프로듀서는 큐가 아니라 exchange에 보내고, exchange가 규칙(binding)에 따라 적절한 큐로 라우팅합니다. 소비자가 ack하면 메시지는 큐에서 사라집니다. "조건에 따라 메시지를 분배하는 우체국"에 가깝습니다.

flowchart LR
  P[Producer] --> X{Exchange}
  X -->|routing key| Q1[(Queue A)]
  X -->|routing key| Q2[(Queue B)]
  Q1 --> C1[Consumer]
  Q2 --> C2[Consumer]

SQS = 신경 안 써도 되는 관리형 큐

AWS가 운영을 다 가져갑니다. 큐를 만들고 메시지를 넣고 빼면 끝입니다. 브로커를 직접 띄우거나 클러스터를 관리할 필요가 없습니다. 대신 Kafka·RabbitMQ가 주는 세밀한 제어는 포기합니다. Standard(고처리량·순서 없음)와 FIFO(순서·중복 제거) 두 종류가 있습니다.

flowchart LR
  P[Producer] --> SQS[(SQS Queue<br/>managed)]
  SQS --> W1[Worker]
  SQS -. 경쟁 .-> W2[Worker]

같은 표 위에 올려놓기

이제 1편의 좌표축으로 셋을 한 번에 봅니다.

이 표에서 가장 중요한 줄은 **"소비 후 메시지"와 "재처리"**입니다. 1편에서 말한 큐 vs 로그의 차이가 여기서 그대로 드러납니다. Kafka만 메시지를 남기고 되감을 수 있고, RabbitMQ·SQS는 소비하면 끝입니다. 이 한 줄이 "이벤트 스트림이냐 작업 큐냐"를 거의 결정합니다.

처리량과 지연: 왜 Kafka가 빠른가

Kafka가 수십만~수백만 건/초를 감당하는 비결은 순차 디스크 쓰기와 배치입니다. 메시지를 로그 끝에 이어 붙이기만 하니 디스크가 랜덤 액세스를 거의 안 하고, 프로듀서·컨슈머가 메시지를 묶음으로 주고받아 네트워크·디스크 효율이 좋습니다. 또 소비자가 "읽을 것을 알아서 당겨가는(pull)" 구조라 브로커가 소비자 상태를 일일이 챙기지 않습니다(3편에서 자세히).

RabbitMQ는 메시지마다 라우팅·ack·상태 추적을 하므로 per-message 제어가 정교한 대신, 같은 하드웨어에서 Kafka만큼의 초고처리량은 내기 어렵습니다. 대신 지연은 더 낮을 수 있습니다. 메시지를 즉시 소비자에게 밀어주기(push) 때문입니다. "한 건이라도 최대한 빨리"가 중요한 작업 큐에서 RabbitMQ가 빛납니다.

SQS는 HTTP API 기반이라 건당 지연은 더 크고, 폴링·배치·롱폴링으로 효율을 맞춥니다. 하지만 "운영을 신경 안 써도 자동으로 확장된다"는 점이 그 단점을 상쇄합니다.

정리하면, 대량 스트림 처리량은 Kafka, 건당 저지연은 RabbitMQ, 운영 없는 확장은 SQS입니다.

운영 부담: 가장 현실적인 축

기술 비교에서 자주 빠지지만 실무에서 제일 중요한 축입니다.

• Kafka: 브로커 클러스터, 파티션 설계, 디스크 용량, 복제·ISR, (구버전은 ZooKeeper, 최신은 KRaft) 같은 걸 직접 운영하거나, Confluent Cloud·MSK 같은 관리형을 써야 합니다. 강력하지만 무겁습니다.
• RabbitMQ: 단일 노드는 가볍게 시작되지만, HA를 위해 클러스터·quorum queue를 구성하면 운영 난이도가 올라갑니다. Kafka보다는 가볍습니다.
• SQS: 운영이 사실상 없습니다. 이게 SQS의 가장 큰 장점입니다. 작은 팀이 AWS 위에서 빠르게 비동기 처리를 붙일 때 압도적으로 편합니다.

팀 규모와 운영 여력이 도구 선택을 크게 좌우합니다. "Kafka가 제일 강력하니까 Kafka"는 운영 인력이 없으면 독이 됩니다.

그래서 언제 무엇을 고르나

Kafka를 고를 때

• 이벤트를 여러 소비자가 각자 다른 용도로 소비한다(결제·정산·추천·분석).
• 과거 데이터를 다시 읽거나(replay) 새 소비자가 처음부터 읽어야 한다.
• 처리량이 매우 크고, 이벤트를 데이터 파이프라인/스트림 처리의 원천으로 쓴다.
• 이벤트 소싱·로그 수집·실시간 분석 같은 그림이 있다.

RabbitMQ를 고를 때

• 작업 큐가 필요하다 — 워커들이 일을 나눠 처리한다.
• 라우팅이 복잡하다 — 조건·주제·우선순위에 따라 다른 큐로 보내야 한다.
• 건당 저지연이 중요하고, per-message ack·재시도·우선순위 제어가 필요하다.
• RPC, 지연 메시지, 데드레터 같은 메시징 패턴을 세밀하게 다루고 싶다.

SQS를 고를 때

• 이미 AWS 위에 있고, 메시징 운영에 사람을 쓰고 싶지 않다.
• 비동기 작업 처리(이미지 변환, 알림, 백그라운드 잡)에 단순 큐면 충분하다.
• Lambda·ECS 같은 AWS 컴퓨트와 자연스럽게 엮고 싶다.
• 브로드캐스트가 필요하면 SNS + SQS 조합으로 fan-out 한다.

실제로 던플 시세 수집 파이프라인은 마지막 경우입니다. 작은 팀이 AWS(ECS·SQS) 위에서 운영 부담 없이 비동기 수집 작업을 돌려야 했기에 SQS가 자연스러운 선택이었습니다. 반대로 "수집된 시세를 여러 소비자가 각자 분석·집계·재처리"하는 그림이 커진다면 그때 Kafka를 검토하게 됩니다.

흔한 오해 정리

• "Kafka가 최신이고 제일 좋다" — 처리량·보존이 강할 뿐, 작업 큐·복잡한 라우팅은 RabbitMQ가 더 편하고, 운영 없는 단순 큐는 SQS가 더 낫습니다. 용도가 다릅니다.
• "RabbitMQ는 느리다" — 초고처리량 스트림이 아닐 뿐, 건당 지연은 오히려 낮습니다.
• "SQS는 장난감이다" — 관리형이라 제어가 적을 뿐, 운영 비용까지 포함하면 작은 팀엔 가장 합리적일 때가 많습니다.
• "하나만 써야 한다" — 큰 시스템은 셋을 섞습니다. 이벤트 스트림은 Kafka, 작업 큐는 RabbitMQ/SQS처럼 용도별로 나눠 씁니다.

정리하면

• 세 도구의 출신을 기억하면 됩니다 — Kafka는 로그, RabbitMQ는 브로커, SQS는 관리형 큐.
• 가장 큰 분기점은 1편의 큐 vs 로그: 보존·replay·다수 구독이면 Kafka, 삭제형 작업 큐면 RabbitMQ/SQS.
• 처리량은 Kafka, 건당 저지연·라우팅은 RabbitMQ, 운영 없는 확장은 SQS.
• 운영 부담은 무시할 수 없는 선택 축이고, 팀 여력이 도구를 가릅니다.
• 큰 시스템은 셋 중 하나를 고르기보다 용도별로 섞어 씁니다.

다음 두 편에서는 이 중 설계 철학이 가장 대비되는 둘, Kafka와 RabbitMQ를 각각 깊게 들여다봅니다. 먼저 Kafka의 로그·파티션·컨슈머 그룹·exactly-once부터 봅니다.

다음 글에서 이어서 보기

• 3편: Kafka 깊게 보기: 분산 로그, 파티션, 컨슈머 그룹, exactly-once

같이 보면 좋은 글

• 메시징과 이벤트 깊게 보기: 큐, 로그, 전달 보장, 그리고 이벤트 기반 아키텍처
• 던플 개발기 (1): 시세 수집 파이프라인 — tier, 증분 저장, 멱등 워커