SQS 표준 대기열과 FIFO 대기열, 메시지 순서와 중복을 어떻게 다룰까
주문이 들어오면 결제를 확인하고, 재고를 줄이고, 알림 메일을 보내는 식으로 여러 작업이 이어지는 서비스를 생각해 보겠습니다. 이 작업을 한 번에 처리하면 메일 서버가 잠깐 느려지기만 해도 주문 화면 전체가 멈춥니다. 그래서 작업을 메시지로 남겨 두고, 처리하는 쪽이 자기 속도에 맞춰 꺼내 가도록 나누는 방식이 널리 쓰입니다.
Amazon Simple Queue Service(SQS)는 이렇게 메시지를 잠시 맡아 두는 대기열 서비스입니다. 보내는 쪽과 받는 쪽이 서로 직접 연결되지 않기 때문에, 한쪽이 잠시 멈추거나 갑자기 요청이 몰려도 메시지는 대기열에 남아 있다가 차례로 처리됩니다.
이 글에서는 SQS의 두 가지 대기열인 표준 대기열과 FIFO 대기열이 순서와 중복을 다루는 방식의 차이, 처리량 한도, 메시지를 안전하게 처리하는 가시성 제한 시간과 배달 못 한 편지 대기열, 그리고 요금 계산 방법을 정리합니다.
고르는 기준은 간단합니다. 순서가 바뀌거나 같은 메시지가 두 번 와도 처리 결과가 같도록 만들 수 있다면 처리량 제한이 거의 없는 표준 대기열을, 순서와 한 번만 처리하는 것이 반드시 필요하다면 FIFO 대기열을 고릅니다. 매달 100만 요청까지는 무료이고, 그 이후 표준은 100만 요청당 0.40달러, FIFO는 0.50달러입니다.
표준 대기열과 FIFO 대기열의 차이
표준 대기열은 처리량을 최우선으로 합니다. 메시지는 최소 한 번 전달되는데, 드물게 같은 메시지가 두 번 이상 전달될 수 있고, 순서도 보낸 순서를 최대한 따르지만 보장하지는 않습니다. 대신 초당 API 호출 수에 사실상 제한이 없습니다.
FIFO 대기열은 순서와 정확성을 우선합니다. 같은 메시지 그룹 ID를 가진 메시지는 보낸 순서대로 전달되고, 5분의 중복 제거 간격 안에 같은 메시지를 다시 보내도 대기열에 한 번만 들어갑니다. 대기열 이름은 반드시 .fifo로 끝나야 합니다.
| 구분 | 표준 대기열 | FIFO 대기열 |
|---|---|---|
| 전달 방식 | 최소 한 번(중복 가능) | 정확히 한 번 처리(5분 중복 제거) |
| 순서 | 최대한 유지, 보장 안 함 | 메시지 그룹 안에서 보장 |
| 처리량 | 사실상 무제한 | 파티션당 API별 초당 300건, 배치 시 3,000개 메시지 |
| 고처리량 모드 | 해당 없음 | 리전에 따라 초당 최대 70,000건 |
| 이름 | 제한 없음 | .fifo로 끝나야 함 |
| 요청 요금 | 100만 건당 0.40달러 | 100만 건당 0.50달러 |
메시지 그룹과 중복 제거 이해하기
FIFO 대기열의 순서는 대기열 전체가 아니라 메시지 그룹 ID 단위로 보장됩니다. 예를 들어 주문 번호를 메시지 그룹 ID로 쓰면, 같은 주문의 결제·출고·배송 메시지는 순서대로 처리되고, 서로 다른 주문은 동시에 처리될 수 있습니다. 그룹 ID를 하나만 쓰면 모든 메시지가 한 줄로 서기 때문에 처리 속도가 크게 떨어집니다.
중복 제거는 두 가지 방법 중 하나로 설정합니다. 메시지마다 중복 제거 ID를 직접 넣거나, 콘텐츠 기반 중복 제거를 켜서 메시지 본문의 SHA-256 해시를 ID로 쓰게 하는 방식입니다. 네트워크 오류로 보내기 요청을 다시 시도해도 5분 안이라면 같은 메시지가 두 번 들어가지 않습니다.
표준 대기열을 쓴다면 받는 쪽에서 중복을 견디도록 설계해야 합니다. 주문 번호로 이미 처리했는지 확인한 뒤 건너뛰는 식으로, 같은 메시지를 두 번 처리해도 결과가 같게 만드는 것을 멱등성이라고 합니다. 이렇게 설계하면 처리량이 큰 표준 대기열을 안심하고 쓸 수 있습니다.
가시성 제한 시간과 배달 못 한 편지 대기열
SQS에서 메시지를 받아 가도 메시지가 바로 지워지지는 않습니다. 받은 순간부터 가시성 제한 시간 동안 다른 소비자에게 보이지 않게 숨겨지고, 처리를 마친 소비자가 삭제 요청을 보내야 비로소 사라집니다. 처리 중에 소비자가 멈추면 제한 시간이 지난 뒤 메시지가 다시 보이게 되어 다른 소비자가 처리할 수 있습니다.
| 설정 | 기본값 | 범위 |
|---|---|---|
| 가시성 제한 시간 | 30초 | 0초~12시간 |
| 메시지 보존 기간 | 4일 | 1분~14일 |
| 전송 지연 | 0초 | 최대 15분 |
| 메시지 크기 | - | 최대 1MiB |
| 배치 | - | 요청 한 번에 최대 10개 메시지 |
가시성 제한 시간은 메시지 하나를 처리하는 데 걸리는 시간보다 넉넉하게 잡아야 합니다. 너무 짧으면 처리가 끝나기 전에 메시지가 다시 보여 같은 작업이 두 번 실행됩니다. 반대로 어떤 메시지가 계속 처리에 실패한다면, 정해진 횟수 이상 받아 간 메시지를 배달 못 한 편지 대기열(DLQ)로 옮기도록 설정해 정상 메시지의 처리를 막지 않게 합니다.
SQS 요금 계산
| 항목 | 요금(2026년 9월 기준) |
|---|---|
| 무료 사용량 | 매달 100만 요청 |
| 표준 대기열(월 1,000억 건까지) | 100만 요청당 0.40달러 |
| FIFO 대기열(월 1,000억 건까지) | 100만 요청당 0.50달러 |
| 요청 계산 단위 | 페이로드 64KB마다 요청 1건 |
| 같은 리전 안 데이터 전송 | 무료 |
요청은 보내기, 받기, 삭제가 각각 따로 계산됩니다. 예를 들어 한 달에 메시지 100만 개를 보내고, 받고, 삭제하면 요청은 300만 건입니다. 표준 대기열이라면 무료 100만 건을 빼고 200만 × 0.40달러 ÷ 100만 = 0.80달러, FIFO라면 1.00달러입니다. 메시지 하나가 200KB라면 64KB 단위로 나눠 요청 4건으로 계산되므로, 큰 메시지는 S3에 두고 대기열에는 위치만 보내는 방식이 비용과 크기 제한 모두에 유리합니다.
메시지가 없을 때 계속 받기 요청을 보내면 빈 응답도 요청으로 계산됩니다. 받기 요청에 대기 시간을 설정하는 긴 폴링을 쓰면 메시지가 올 때까지 기다렸다가 응답하므로 빈 요청 수와 비용을 줄일 수 있습니다.
SQS와 SNS, 무엇이 다를까
메시지 서비스를 찾다 보면 SQS와 함께 Amazon SNS도 자주 보입니다. 둘 다 메시지를 전달하지만 방식이 다릅니다. SQS는 메시지를 대기열에 쌓아 두고 받는 쪽이 꺼내 가는 방식이고, SNS는 주제에 게시된 메시지를 구독자 모두에게 즉시 밀어 보내는 방식입니다.
| 구분 | SQS | SNS |
|---|---|---|
| 전달 방식 | 받는 쪽이 가져감(풀) | 구독자에게 밀어 보냄(푸시) |
| 받는 쪽 | 메시지 하나를 소비자 하나가 처리 | 같은 메시지를 여러 구독자가 받음 |
| 보관 | 최대 14일 대기열에 보관 | 보관하지 않고 바로 전달 |
| 대표 용도 | 작업 분산, 처리 속도 조절 | 알림, 여러 시스템에 동시 전파 |
두 서비스는 함께 쓰는 경우가 많습니다. 주문 완료 메시지를 SNS 주제에 게시하고, 결제·재고·알림 시스템마다 SQS 대기열을 하나씩 구독시키면 하나의 메시지가 세 대기열로 복사되고 각 시스템은 자기 속도대로 처리합니다. 이런 구성을 팬아웃이라고 부릅니다.
정리
SQS 표준 대기열은 처리량에 사실상 제한이 없는 대신 메시지가 중복되거나 순서가 바뀔 수 있고, FIFO 대기열은 메시지 그룹 안의 순서와 5분 중복 제거를 보장하는 대신 처리량에 한도가 있습니다. 메시지는 삭제 요청이 있어야 사라지므로 가시성 제한 시간을 처리 시간보다 길게 잡고, 실패가 반복되는 메시지는 DLQ로 옮깁니다. 매달 100만 요청은 무료이며 이후 표준은 100만 요청당 0.40달러, FIFO는 0.50달러입니다.
헷갈리기 쉬운 질문
이미 만든 표준 대기열을 FIFO로 바꿀 수 있나요?
대기열 유형은 만든 뒤에 바꿀 수 없습니다. FIFO가 필요하다면 이름이 .fifo로 끝나는 새 대기열을 만들고, 보내는 쪽과 받는 쪽을 새 대기열로 옮겨야 합니다.
같은 메시지가 두 번 처리되는 것 같아요.
표준 대기열에서는 드물게 생길 수 있는 일이고, 가시성 제한 시간이 처리 시간보다 짧을 때도 자주 생깁니다. 처리 시간을 측정해 제한 시간을 늘리고, 처리 로직에 이미 처리한 메시지인지 확인하는 단계를 넣으세요.
Lambda와 함께 쓰면 무엇이 편한가요?
SQS를 Lambda의 이벤트 소스로 연결하면 Lambda가 대기열을 대신 확인해 메시지를 배치로 가져가고, 처리에 성공하면 메시지를 삭제합니다. 받는 쪽 서버를 따로 운영하지 않아도 됩니다.
긴 폴링은 얼마나 기다리게 설정하나요?
받기 요청의 대기 시간은 1초에서 20초 사이로 정할 수 있고, 0으로 두면 바로 응답하는 짧은 폴링이 됩니다. 메시지가 드문드문 들어오는 대기열이라면 20초로 두는 것이 빈 요청을 줄이는 데 가장 효과적입니다.
메시지가 밀리고 있는지 어떻게 알 수 있나요?
CloudWatch의 SQS 지표에서 대기 중인 메시지 수와 가장 오래된 메시지의 나이를 보면 됩니다. 가장 오래된 메시지의 나이가 계속 늘어난다면 소비자가 처리 속도를 따라가지 못하는 것이므로, 소비자 수를 늘리거나 처리 로직을 점검해야 합니다.
메시지를 최대한 오래 보관하려면?
메시지 보존 기간은 최대 14일입니다. 그보다 오래 남겨야 하는 기록이라면 처리 과정에서 S3나 데이터베이스에 따로 저장해 두어야 합니다.
대기열은 서비스의 각 부분이 서로의 속도에 묶이지 않게 해 주는 완충 장치입니다. 다만 어떤 대기열을 고르느냐에 따라 받는 쪽이 감당해야 할 일이 달라지므로, 순서와 중복에 대한 요구를 먼저 정리하는 것이 출발점입니다.
새로 대기열을 설계한다면 처리 로직을 멱등하게 만들 수 있는지부터 따져 보세요. 가능하다면 표준 대기열과 DLQ 조합으로 시작하고, 주문 상태 변경처럼 순서가 꼭 필요한 흐름에만 FIFO 대기열을 쓰는 것이 비용과 처리량 모두에 유리합니다.
함께 읽으면 좋은 글: 서버리스 AWS Lambda 개념 / RTO·RPO와 멀티 AZ 구성
참고 자료: SQS 메시지 할당량, FIFO 대기열의 정확히 한 번 처리, 가시성 제한 시간, Amazon SQS 요금
※ 본 글은 2026년 9월 기준 Amazon SQS 개발자 안내서와 요금 페이지를 참고해 작성했으며, 요금과 할당량은 리전과 시기에 따라 달라질 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.