서비스 간 메시징을 도입하려는데 실시간 알림, 과거 이벤트 재생, 작업 재시도의 요구가 다릅니다. 어떤 보장과 운영 조건을 기준으로 NATS·Kafka·SQS를 선택하나요?

제품 이름보다 메시지의 수명과 소비 모델을 먼저 나눕니다. Core NATS(연결된 구독자에게 즉시 전달하는 NATS 방식)는 subject(메시지 분류 이름) 통신에 가깝고, Kafka는 partition log(파티션별 순서 로그)를 보관해 여러 consumer group이 각자 위치에서 재생하는 데 강합니다. SQS는 관리형 작업 큐로서 소비자에게 작업을 전달하고 visibility timeout(처리 중 재전달을 잠시 막는 시간)과 재시도를 운영 서비스에 맡기는 선택입니다. NATS의 JetStream(메시지를 저장·재생하는 NATS 기능)을 쓰면 저장·재생·ACK(처리 완료 확인) 모델이 달라지므로 “NATS 대 Kafka”처럼 제품 단위로만 비교하지 않습니다.

여러 팀이 계정 이벤트를 보관 기간 안에서 독립 재생해야 하면 로그·partition·retention·consumer offset이 중요합니다. 즉시 내부 요청이면 request-reply 지연·연결·응답 상관관계를 보고, 운영 인력이 적고 단순 작업 분배가 목적이면 관리형 큐의 운영 비용을 봅니다. 순서 범위, 최대 메시지 크기, 재전달·중복, 장애 복구, cross-region 비용도 요구사항 표에 적겠습니다.

어떤 broker(메시지를 전달·저장하는 중간 시스템)도 외부 DB 효과의 멱등성이나 중복 반영을 자동으로 없애지 않습니다. 예를 들어 작업 전달이 한 번 더 되면 주문 상태를 두 번 바꾸지 않도록 소비자와 DB가 별도 처리 기록을 가져야 합니다. 대표 workload에서 생산 확인, 소비 지연, 재처리, 보관 만료와 비용을 시험하고, 한 제품으로 통일했을 때의 운영 단순화와 애플리케이션에 옮겨가는 복잡성을 함께 비교해 선택하겠습니다.

메시지의 수명과 소비 모델을 고릅니다

연결된 소비자에게 즉시 알리고 놓친 내용을 복원하지 않아도 되면 Core NATS가 단순할 수 있습니다. 소비자가 잠시 내려가도 재전달해야 하면 JetStream의 저장·ACK·재전달 설정을 평가합니다. 과거 이벤트를 여러 consumer group이 각자 재생하고 partition 순서를 유지해야 하면 Kafka가 맞고, 하나의 작업을 관리형 큐로 넘기며 visibility timeout·DLQ 운영을 맡기고 싶으면 SQS가 후보입니다. 순서가 전역인지 키 단위인지, 처리 시간이 timeout을 넘는지까지 요구사항으로 고정합니다.

브로커 밖의 효과를 보호합니다

ACK·offset·메시지 삭제는 외부 DB 변경이 완료됐다는 사실과 같은 것이 아닙니다. 소비자가 처리 ID와 업무 키를 저장하고 조건부 갱신으로 포인트·주문 상태의 중복 반영을 막아야 합니다. Kafka 재생은 오래된 이벤트를 다시 적용할 수 있고, SQS는 visibility 만료로 같은 작업이 동시에 실행될 수 있습니다. 대표 장애에서 소비자 재시작·ACK 유실·보관 만료·재전달 비용을 시험하고, 전환 시 이중 소비와 시작 위치를 명시하겠습니다.

구체적인 경계 사례

예를 들어 주문 처리 워커 20개가 작업을 나눠 맡는 것과 분석·알림·검색 서비스가 같은 주문 이벤트를 모두 읽는 것은 다릅니다. 하나의 큐나 소비 그룹을 공유하면 전자는 가능하지만 후자의 독립 전달이 되지 않을 수 있습니다. 독립 구독이나 그룹을 만들고 각 서비스의 보관·재생 위치를 따로 관리해야 합니다.

비용은 생산 메시지 수만이 아니라 소비자 수에 따른 읽기, 재전달, 장기 보관, 지역 간 데이터 이동, 운영 인력을 포함합니다. SQS Standard와 FIFO도 순서·중복 제거 범위·처리량 조건이 다르므로 같은 제품명 아래 별도 후보로 봅니다. FIFO의 중복 제거가 소비자의 외부 DB 커밋과 메시지 삭제를 하나의 원자 작업으로 만들어 주는 것은 아니며, 브로커 전환 때도 기존 처리 ID를 유지해 재처리를 안전하게 하겠습니다.