🔥 SQS란 무엇인가: 큐의 추상

처음 SQS 콘솔을 열었을 때 가장 먼저 누른 버튼은 SendMessage와 ReceiveMessage였다. 서울 리전 엔드포인트가 sqs.ap-northeast-2.amazonaws.com인 큐를 하나 만들고 짧은 문자열을 넣었는데, SendMessage 응답은 바로 돌아왔다. 대신 내가 맡긴 일의 결과는 그 응답 안에 없었다. 꺼내는 쪽 일은 ReceiveMessage를 누른 뒤에야 따로 보였다.

콘솔 화면은 단순했지만 머릿속에서는 일이 두 갈래로 나뉘었다. 메시지를 넣는 쪽은 일단 자기 일을 끝내고 지나간다. 메시지를 꺼내는 쪽은 자기 속도로 나중에 처리한다. AWS는 2006년 7월 11일 SQS를 일반 공개했다. AWS가 초기에 내놓은 서비스 중 하나다(AWS 출시 공지).

큐의 추상

큐는 생산자가 보낸 메시지를 소비자가 꺼낼 때까지 잠시 보관하는 자료 구조이다. AWS는 SQS를 분산 소프트웨어 시스템과 컴포넌트를 통합하고 분리하는 호스팅 큐로 설명한다(AWS Developer Guide).

이 추상이 필요한 이유는 동기 호출과 대비하면 바로 보인다. 동기 호출은 보내는 쪽과 받는 쪽을 한 요청 안에 묶는다. 받는 쪽이 느리거나 멈추면 보내는 쪽도 같은 지연을 감당한다. 큐는 이 결합을 끊는다. 보내는 쪽은 메시지를 남기고 다음 일을 한다. 소비자는 나중에 꺼내서 처리한다. 이것이 비동기 처리이다.

숫자는 큐를 운영 판단으로 바꾼다. 메시지는 기본값으로 4일 동안 보관하고 최대 14일까지 늘릴 수 있다(큐 설정 문서). 2KB 주문 메시지 5만 건을 하루 동안 처리하지 못하면 큐에는 약 100MB가 남는다. 2026년 5월 3일 기준 AWS Developer Guide 의 quotas-messages 페이지는 큐의 최대 메시지 크기를 1,024 KiB 로 둔다. 같은 시점 AWS features 페이지는 여전히 256 KB 로 표기하므로 출처마다 값이 달라 보일 수 있다(Developer Guide). 큐는 바로 사라지는 신호가 아니라, 시간차를 두고 메시지를 보관하는 장치다.

생산자와 소비자 분리

생산자와 소비자를 분리하면 가용성과 처리 속도를 따로 다룰 수 있다. 웹 서버가 주문 접수 메시지를 넣는 순간까지 성공하면, 정산이나 알림 같은 뒤쪽 작업은 같은 초에 끝낼 필요가 없다. 소비자 수를 늘려 처리량을 높일 수도 있고, 뒤쪽 작업이 잠시 멈춰도 앞쪽 요청을 바로 막지 않을 수도 있다.

이 분리의 본질은 중간 보관이다. 초당 100건이 들어오는데 소비자가 초당 60건만 처리해도 시스템 전체가 즉시 실패로 바뀌지는 않는다. 큐 안에 남은 메시지를 기준으로 병목을 계산할 수 있기 때문이다. AWS 문서도 SQS를 여러 생산자와 여러 소비자가 동시에 쓰는 분산 메시징 구조로 설명한다(AWS Developer Guide).

처음 visibility timeout을 봤을 때는 한참 갸우뚱했다. 메시지를 받았다고 바로 사라지는 것이 아니기 때문이다. SQS는 보관 중 메시지와 수신했지만 아직 삭제하지 않은 in-flight 메시지를 구분하고, 기본 visibility timeout은 30초이다(visibility timeout 문서). 소비자가 30초 안에 삭제하지 못하면 다른 소비자가 다시 받을 수 있다. 비동기는 편의가 아니라 재처리 규칙까지 포함한 계약이다.

관리형이 감추는 비용

SQS는 관리형 서비스이지만 운영 책임을 없애지 않는다. 서버를 직접 띄우지 않아도 된다는 뜻이지, 메시지 처리 규칙을 AWS가 대신 정해 준다는 뜻은 아니다.

사용자는 IAM 권한을 만들어야 한다. 어느 역할이 SendMessage, ReceiveMessage, DeleteMessage를 호출할지 직접 정해야 한다. 네트워킹도 끝나지 않는다. VPC 안에서 사설로 붙일지, 인터넷을 거칠지, 어느 리전에 둘지 판단해야 한다. 운영 상태도 계속 확인해야 한다. 큐 길이, ApproximateAgeOfOldestMessage, 실패 횟수, 재시도 지연은 CloudWatch 지표와 경보로 확인해야 한다. 관리형이 감추는 비용은 서버 비용이 아니라 판단 비용이다.

요금도 단순하지 않다. 2026년 5월 3일 기준 시작 가격은 Standard 요청 100만 건당 0.40달러, FIFO 요청 100만 건당 0.50달러이고, 매월 100만 요청은 무료다(AWS Pricing). 한 달 Standard 요청이 300만 건이면 무료 100만 건을 뺀 200만 건에 대해 0.80달러를 낸다. 하지만 실제 청구서는 요청 수만으로 끝나지 않는다. 메시지를 여러 번 받고, visibility timeout을 바꾸고, KMS를 붙이고, 관측 지표를 늘리면 비용 구조도 함께 커진다. DLQ를 붙일지, 재처리를 몇 번 허용할지도 사용자가 정한다.

언제 SQS를 쓰지 말아야 하는가

1초 미만 응답이 필요한 작업에는 SQS가 잘 맞지 않는다. 결제 승인처럼 호출 직후 결과를 바로 받아야 하는 작업에 큐를 끼우면, 큐에 넣는 순간과 처리 완료 시점을 따로 다루느라 설계가 한 단계 더 복잡하게 만든다. 이런 경우에는 동기 API나 다른 통신 방식을 먼저 검토한다.

순서 보장이 핵심인 작업에는 SQS부터 붙이지 않는다. FIFO가 순서를 돕기는 하지만, 처리량 제한과 재시도 규칙을 함께 계산해야 하기 때문이다. 순서 보장 자체가 업무 규칙의 중심이면 큐를 붙이기 전에 왜 반드시 순서가 필요한지부터 다시 정리해야 한다.

지금은 SQS를 저장소보다 시간차를 다루는 도구로 본다. 메시지를 어디에 둘지보다, 누가 지금 답하지 않아도 되는지를 먼저 묻게 된다.