메시지 큐(Message Queue) 기초: 서비스 간에 일을 안전하게 넘기는 비동기 통신

서비스가 늘수록 “서로 바로 호출”이 항상 정답이 아닌 순간이 생긴다

결제, 주문, 알림처럼 기능이 나뉘기 시작하면 서비스끼리 일을 주고받아야 한다. 이때 매번 바로 호출하면 편해 보이지만, 한쪽이 느려지거나 잠깐 멈춘 순간 전체가 같이 흔들릴 수 있다.

반대로 “나중에 처리해도 되는 일”까지 즉시 처리하려고 하면 피크 시간에 병목이 커지고, 장애가 발생했을 때 복구가 더 어려워질 수 있다.

메시지 큐는 일을 “전달”하는 통로를 분리해, 요청 흐름을 안정적으로 만드는 방식이다.

• 메시지 큐가 하는 일: 저장하고 전달하고 재시도하는 역할
• 프로듀서·컨슈머 구조가 트래픽을 어떻게 완충하는지
• ACK, 재시도, DLQ가 안전장치가 되는 이유
• 언제 큐가 맞고, 언제 단순 호출이 더 나은지
• 현장에서 바로 확인하는 체크 포인트(적체, 지연, 실패)

메시지 큐는 “요청을 즉시 처리”가 아니라 “작업을 안전하게 넘김”에 초점이 있다

핵심 개념 1: 프로듀서·컨슈머와 큐는 작업 흐름을 분리한다

정의: 프로듀서(Producer)는 해야 할 일을 메시지로 만들어 큐에 넣고, 컨슈머(Consumer)는 큐에서 메시지를 꺼내 실제 처리를 수행하는 구조다.

핵심 특징: 일을 요청한 쪽과 일을 처리하는 쪽이 같은 속도로 움직이지 않아도 된다. 큐가 중간 버퍼가 되어 피크 트래픽을 흡수하고, 컨슈머는 처리 가능한 속도로 따라간다.

• 내부 동작 원리: 큐는 메시지를 순서대로 보관하고, 컨슈머는 폴링 또는 푸시로 메시지를 받아 처리한다. 이 구조로 요청 경로와 처리 경로가 분리된다.
• 범위: “즉시 응답이 필요 없는 업무”에 특히 잘 맞는다. 예를 들어 이메일 발송, 로그 적재, 통계 집계, 이미지 변환처럼 뒤에서 처리해도 되는 작업에 자주 쓰인다.
• 수명: 메시지는 보통 소비(처리 완료)되면 큐에서 제거된다. 다만 시스템에 따라 보관 기간(리텐션)이 정해져 있어, 기간을 넘기면 자동 삭제될 수 있다.
• 제약: 큐 자체도 자원이므로 메시지가 너무 빠르게 쌓이면 적체가 생긴다. 처리량을 늘리거나 메시지 크기·빈도를 줄이는 설계가 필요해진다.

주의점: 메시지 큐를 붙였다고 자동으로 빨라지지 않는다. 느린 작업을 큐 뒤로 숨기는 것만으로는 적체가 커지고, 결국 늦게 터지는 형태로 문제를 이동시킬 수 있다.

주의점: 큐를 통과하는 작업은 “즉시 반영”이 아닌 “최종 반영 지연”이 생길 수 있다. 사용자 화면이 그 지연을 어떻게 보여줄지 정책이 필요하다.

 

메시지 큐 기반 비동기 처리의 기본 구조

 

핵심 개념 2: ACK·재시도·DLQ는 “실패해도 잃지 않게” 만드는 장치다

정의: ACK(acknowledgement)는 컨슈머가 메시지를 정상 처리했음을 큐에 알리는 신호이며, 재시도는 실패한 메시지를 다시 처리하도록 만드는 정책이다. DLQ(Dead Letter Queue)는 반복 실패한 메시지를 따로 격리해 운영자가 확인할 수 있게 하는 별도 큐다.

핵심 특징: 네트워크 오류, 일시 장애, 외부 API 지연처럼 실패가 흔한 환경에서 메시지를 버리지 않고 안전하게 처리 흐름을 유지할 수 있다.

• 내부 동작 원리: 컨슈머가 메시지를 처리한 뒤 ACK를 보내면 큐는 해당 메시지를 완료로 표시한다. ACK가 없으면 메시지는 재전달되거나 가시성 제한(visibility timeout) 이후 다시 처리 후보가 된다.
• 범위: 결제 승인처럼 “중복 실행이 위험한 작업”도 큐를 통해 처리할 수 있지만, 중복 방지(멱등성)가 같이 설계되어야 한다.
• 수명: 실패 메시지는 재시도 횟수·보관 기간 규칙에 따라 오래 남을 수 있다. DLQ에 쌓인 메시지는 운영자가 분석 후 재처리하거나 폐기하는 절차가 필요하다.
• 정리 필요성: DLQ를 방치하면 “실패가 누적된 상태”가 장기화된다. 재처리 기준, 알림, 정리 주기를 함께 가져가야 한다.

주의점: 재시도를 무작정 늘리면 장애를 더 키울 수 있다. 같은 원인으로 실패하는 메시지가 폭증하면, 컨슈머와 외부 시스템을 함께 과부하시킬 수 있다.

주의점: “한 번만 처리”는 현실에서 쉽지 않다. 메시지가 중복 전달되는 상황을 전제로 두고, 결과가 두 번 반영되지 않도록 설계하는 편이 안전하다.

 

메시지 처리 실패 시 재시도와 DLQ로 이어지는 흐름

 

언제 메시지 큐를 쓰고, 언제 단순 호출이 더 나은지 기준을 세워야 한다

메시지 큐는 만능이 아니다. 빠른 응답이 필요한 동기 흐름은 그대로 두고, 뒤로 밀어도 되는 작업을 분리하는 식으로 쓰는 경우가 많다.

현장에서 헷갈리는 지점은 “지연 허용”과 “실패 처리 책임”이다. 큐를 붙이면 지연이 생기고, 그 지연을 운영과 화면에서 감당해야 한다.

비교 항목	동기 호출(직접 요청)	메시지 큐 기반 비동기
응답 방식	상대 서비스가 처리 완료해야 응답한다	요청을 큐에 넣고 빠르게 반환할 수 있다
장애 전파	한쪽 지연/장애가 연쇄로 번지기 쉽다	큐가 완충 역할을 하며 연쇄를 줄인다
지연 특성	즉시 결과가 필요할 때 유리하다	처리 지연이 생길 수 있어 정책이 필요하다
실패 처리	요청 실패가 사용자에게 즉시 드러난다	재시도·DLQ로 실패를 흡수할 수 있다
운영 복잡도	구성이 단순하나 장애 시 연쇄 위험이 있다	큐 지표(적체/지연/실패) 관리가 필요하다

표 제목: 동기 호출 vs 메시지 큐 비동기 통신 핵심 비교

어떤 상황이면 메시지 큐가 맞는가: YES/NO 체크리스트

• 질문: 사용자가 “지금 당장 결과”를 받아야 하는가. YES: 동기 호출이 기본이며, 비동기는 보조로 분리한다. NO: 메시지 큐 후보가 된다.
• 질문: 피크 타임에 트래픽이 몰리며 처리량이 들쑥날쑥한가. YES: 큐로 완충하고 컨슈머 수를 조절하는 구성이 유리하다. NO: 단순 호출로도 충분할 수 있다.
• 질문: 실패 시 재시도와 재처리가 필요한가. YES: 큐의 재시도·DLQ가 운영에 도움이 된다. NO: 단순 호출에서 오류 처리를 끝내도 된다.
• 질문: 작업이 중복 실행되어도 안전하게 설계할 수 있는가. YES: 큐 기반 처리 안정성이 올라간다. NO: 큐 도입 전에 중복 방지 기준을 먼저 세워야 한다.
• 질문: 처리 지연을 사용자가 이해할 수 있게 안내할 수 있는가. YES: 비동기 처리가 자연스럽게 녹는다. NO: “반영 지연”이 민원으로 돌아올 수 있다.

실전 예시: 알림 발송이 주문 처리까지 느리게 만드는 문제를 분리하는 방식

문제: 사용자가 주문을 완료할 때마다 문자/이메일 알림을 보내는데, 알림 서비스가 느려지는 순간 주문 완료 화면까지 지연되거나 실패한다.

왜 발생: 주문 서비스가 알림 발송을 동기 호출로 묶어 두면, 알림 서비스의 지연이 주문 트랜잭션 흐름에 그대로 영향을 준다. 외부 메시징 업체 API가 느려지거나 제한에 걸리면 주문 처리도 함께 흔들린다.

어떤 선택이 적합: 주문 완료는 즉시 확정되게 두고, 알림 발송은 메시지 큐로 넘겨 비동기로 처리하는 구성이 맞다. 주문 서비스는 “알림 요청 메시지”를 큐에 넣고 빠르게 응답하며, 알림 컨슈머가 뒤에서 발송을 수행한다.

잘못 쓰면 어떤 문제: 재시도를 공격적으로 걸면 같은 알림이 여러 번 발송될 수 있다. 반대로 재시도를 너무 줄이면 일시 장애에서 알림이 누락될 수 있다. DLQ가 없으면 실패 원인 분석이 어려워지고, 운영자는 “왜 안 갔는지”를 찾기 위해 로그를 뒤져야 한다.

확인/해결: 큐에 메시지가 얼마나 쌓이는지, 컨슈머가 어느 속도로 처리하는지, 실패가 어디로 모이는지부터 수치로 확인해야 한다. 그 다음 재시도 정책과 컨슈머 확장으로 병목을 줄이는 순서가 일반적이다.

확인하는 방법: 큐 적체·지연·실패를 한 번에 점검하는 순서

1. 메시지 큐 관리 화면(또는 클라우드 콘솔)에서 해당 큐를 선택한다.
2. 현재 메시지 개수(Queue Depth)와 증가 추세를 확인한다. 짧은 시간에 계속 증가하면 컨슈머 처리량이 부족한 상태다.
3. 처리 지연(Consumer Lag 또는 Oldest Message Age)을 확인한다. 가장 오래된 메시지의 대기 시간이 길면 사용자 체감 문제로 이어질 수 있다.
4. 실패 횟수와 재시도 횟수 지표를 확인한다. 실패가 늘면 외부 API 제한, 인증 오류, 포맷 오류 같은 원인을 의심한다.
5. DLQ가 있다면 DLQ 메시지 수를 확인한다. DLQ가 증가하면 “반복 실패”가 누적되고 있다는 뜻이다.
6. 컨슈머 로그에서 실패 원인을 분류한다(예: 외부 API 타임아웃, 4xx/5xx 응답, 잘못된 수신자 데이터).
7. 조치 방향을 정한다: 처리량 부족이면 컨슈머 인스턴스/워커 수를 늘리고, 외부 API 제한이면 속도 제한과 지수 백오프 재시도를 적용하며, 데이터 오류면 메시지 검증과 DLQ 재처리 절차를 만든다.

운영에서 자주 놓치는 포인트 2가지

첫째, 큐를 붙이면 “반영 지연”이 생길 수 있으므로 사용자 화면과 고객 응대 문구가 준비되어야 한다. 예를 들어 “알림은 최대 몇 분 내 발송될 수 있다” 같은 기준이 없으면 작은 지연도 오류로 인식된다.

둘째, DLQ는 만들어 두는 것만으로 끝나지 않는다. DLQ에 쌓인 메시지를 누가 언제 어떤 기준으로 재처리할지, 실패 원인을 어떻게 분류할지까지 정해져야 누락과 중복을 줄일 수 있다.

결론

메시지 큐는 작업을 안전하게 넘기고 트래픽을 완충해 서비스 간 연쇄 장애를 줄이는 방식이다.

ACK·재시도·DLQ를 함께 설계하면 실패를 흡수하면서도 원인 분석과 복구가 쉬워진다.

즉시 결과가 필요한 흐름과 지연 가능한 작업을 분리하면, 성능과 안정성을 동시에 확보하기가 수월해진다.

• 다음에 읽으면 좋은 연계 주제: 재시도 정책(백오프)과 속도 제한으로 장애를 키우지 않는 방법
• 다음에 읽으면 좋은 연계 주제: 멱등성 설계로 중복 처리와 중복 발송을 막는 방법

FAQ

메시지 큐를 쓰면 데이터가 유실되지 않는가

큐가 내구성 있게 저장하도록 설정하면 유실 가능성을 줄일 수 있다. 다만 설정과 운영에 따라 달라지므로, 보관 기간과 장애 시 복구 절차를 함께 점검해야 한다.

비동기로 넘기면 사용자는 결과를 어떻게 확인하는가

즉시 확정이 필요한 것은 동기 흐름으로 처리하고, 비동기 작업은 “처리 중/완료” 상태를 별도로 보여주는 방식이 흔하다. 처리 지연이 가능한 범위를 화면에서 명확히 안내하는 편이 혼선을 줄인다.

DLQ에 메시지가 쌓이면 어떻게 처리하는가

실패 원인을 분류한 뒤 재처리 또는 폐기 기준을 정해 운영한다. 반복 실패를 방치하면 누락이 누적되므로, DLQ 알림과 정기 점검을 루틴으로 두는 방식이 많이 쓰인다.