메시징 비용을 백만 요청당 40센트로 예산에 잡았는데, AWS 청구서는 메시지 수가 시사하는 것보다 세 배 높게 도착했습니다. 원인은 가격 인상이 아닙니다. 바로 64 KB 청킹 규칙입니다. AWS는 논리적 메시지에 과금하지 않고, 해당 메시지를 건드리는 모든 API 호출에서 페이로드의 64 KB 청크마다 과금합니다. 200 KB 주문 이벤트는 전송할 때 4번의 과금 요청이 되고, 워커가 수신할 때 4번 더, 워커가 삭제할 때 4번 더 발생합니다. SNS 팬아웃이 다시 배수로 늘리기 전에, 이미 메시지 하나에 12번의 청구가 발생하는 것입니다.
이 글에서는 SQS와 SNS가 실제로 요청을 어떻게 집계하는지, 현실적인 볼륨에서 그 비용이 얼마인지, 프로덕션 메시징이 왜 간접비가 아니라 매출원가에 속하는지, 그리고 매출총이익이 진실을 말하도록 어떻게 기록하는지 설명합니다.
SQS가 메시지 하나를 여러 과금 요청으로 바꾸는 방법
SQS 가격은 무척 단순해 보입니다. 표준 큐는 백만 요청당 약 40센트, FIFO 큐는 백만 요청당 약 50센트이며, 매월 첫 백만 건의 표준 요청은 무료입니다. 복잡함은 요청의 정의 속에 숨어 있습니다.
각 64 KB 청크가 하나의 요청
페이로드의 시작된 64 KB 청크마다 각각 하나의 요청으로 집계됩니다. 30 KB 메시지는 1회 요청입니다. 64 KB 메시지도 1회 요청입니다. 65 KB 메시지는 2회입니다. 200 KB 메시지는 4회, 256 KB 메시지는 4회, 1 MB 페이로드는 16회입니다.
마지막 숫자는 예전보다 더 중요해졌습니다. 2025년 8월에 AWS는 표준 및 FIFO 큐 모두에서 SQS 최대 메시지 크기를 256 KB에서 1 MB로 늘렸습니다. 이 여유 공간은 가끔 발생하는 큰 이벤트에는 편리하지만, 64 KB를 넘겨 두는 모든 것은 건드릴 때마다 청크 배수를 지불합니다. 평균 페이로드를 50 KB에서 200 KB로 옮긴 팀은 메시지를 단 하나도 더 보내지 않고도 SQS 요청 수가 네 배로 늘어납니다.
모든 API 작업이 개별적으로 집계
큐에 대한 각 API 작업은 하나의 요청이며, 청크 배수는 각 작업에 적용됩니다. 전송, 수신, 삭제, 메시지 가시성 변경은 각각 독립적으로 과금됩니다.
표준 큐에서 200 KB 메시지 하나의 전체 생명주기를 살펴보겠습니다. 전송은 4번의 과금 요청입니다. 워커의 수신은 4번 더입니다. 성공적으로 처리한 후의 삭제는 4번 더입니다. 논리적 메시지 하나에 12번의 과금 요청, 정가 기준 천 건당 약 0.5센트입니다. 30 KB 메시지의 동일한 생명주기는 총 3번의 요청입니다. 대부분의 SQS 청구서에서 지배적인 변수는 메시지 수가 아니라 페이로드 크기입니다.
처음 운영하는 사람을 놀라게 하는 과금 항목이 두 가지 더 있습니다. 빈 수신도 과금됩니다. 메시지를 반환하지 않는 모든 폴링도 여전히 요청으로 집계되므로, 유휴 큐에 대한 공격적인 숏 폴링 루프는 아무것도 얻지 못한 채 돈을 태웁니다. 그리고 FIFO 큐는 모든 볼륨 구간에서 표준 대비 약 25퍼센트의 할증이 붙는데, 청크 배수가 이미 불리하게 작용하고 있는 상황에서는 이 비용이 빠르게 누적됩니다. 순서 보장과 정확히 한 번 처리가 진정으로 필요한 곳에 FIFO를 사용하고, 나머지 모든 곳에는 표준을 사용하세요.
SNS가 다시 한 번 배수로 늘리는 방법
SNS는 두 번째 과금 차원을 추가합니다. 게시된 메시지는 도착 시 한 번, 그리고 모든 전달마다 다시 한 번 과금되기 때문입니다.
게시와 전달은 별도의 과금 항목
토픽에 게시하는 비용은 백만 요청당 약 50센트이며, 같은 방식으로 청킹됩니다. 256 KB 게시는 4회로 집계됩니다. 그리고 각 구독자에게의 각 전달도 64 KB 청크당 과금되며, 요율은 전달 프로토콜에 따라 다릅니다.
모든 전달의 비용이 같지는 않습니다. SQS 큐, Lambda 함수, Firehose 스트림으로의 전달에는 전달 요금이 없으므로 SNS-to-SQS 팬아웃은 전달 측면에서 거의 무료입니다. HTTP 및 HTTPS 전달, 이메일, 모바일 푸시는 과금되며, SMS는 메시지 세그먼트당 별도로 가격이 책정됩니다. 따라서 256 KB 이벤트를 3개의 SQS 큐와 1개의 HTTP 웹훅으로 팬아웃하면 게시 요청 4번, 3개의 SQS 전달에 0번, HTTP 전달 4번이 발생합니다. 해당 이벤트를 64 KB 미만으로 줄이면 동일한 팬아웃에 게시 1번과 HTTP 전달 1번의 비용만 듭니다.
SNS는 2026년 9월에 SQS를 따라 더 큰 페이로드를 지원하여, 토픽 수준의 최대 크기 설정으로 1 MB 메시지를 허용했습니다. 256 KB를 초과하도록 구성된 토픽은 SQS, Lambda, Firehose로만 전달할 수 있으며, 구독은 최대 100개입니다. 이 제약은 의도된 패턴에 대한 힌트입니다. 큰 이벤트는 모든 프로토콜로 뿌리는 것이 아니라 큐 기반 파이프라인에 속한다는 것입니다.
팬아웃이 여전히 우월한 이유
전달 요금 항목은 팀들이 SNS를 건너뛰고 각 소비자에게 직접 중복 SQS 메시지를 보내고 싶게 만듭니다. 그러지 마세요. 중복 전송은 주기의 가장 비싼 부분, 즉 소비자별 전송 + 수신 + 삭제를 배수로 늘리는 반면, SNS-to-SQS 팬아웃은 구독자당 게시 1번과 SQS 전달 요금 0번만 지불합니다. 여러 소비자가 동일한 이벤트를 필요로 할 때, 팬아웃은 더 깔끔한 아키텍처이자 더 저렴한 청구서입니다.
실제 볼륨에서의 비용
정가 요율은 백만 단위 숫자이므로 곱해 봐야 의미가 있습니다. 그래서 세 가지 현실적인 형태를 제시합니다.
한 개의 표준 큐를 통해 매월 2백만 건의 작은 메시지를 보내는 사이드 프로젝트는 거의 아무것도 지불하지 않습니다. 64 KB 미만의 각 메시지는 전송 1번, 수신 1번, 삭제 1번, 즉 6백만 요청입니다. 첫 백만 건은 무료이므로 나머지 5백만 건에 백만 건당 40센트를 적용하면 약 2달러입니다.
매월 5백만 건의 10 KB 알림을 3개의 SQS 구독자와 1개의 HTTP 웹훅이 있는 표준 토픽에 게시하는 중형 SaaS 플랫폼은 SNS 부분에 한 자릿수 금액을 지불합니다. 게시 비용은 약 2달러 50센트입니다. 3개의 SQS 전달은 무료입니다. HTTP 전달은 십만 건당 6센트로 약 3달러입니다. 하위 SQS API 작업이 총액을 대략 두 배로 늘려, 전체 알림 파이프라인은 매월 15달러 미만입니다. 이것이 메시징이 정말로 무시할 수준인 형태입니다.
이제 각 이벤트에 전체 주문 문서가 포함되어 있기 때문에 200 KB 페이로드로 동일한 SaaS 워크로드를 다시 실행해 보겠습니다. 모든 과금 항목이 네 배가 됩니다. 게시는 10달러, HTTP 전달은 12달러로 뛰고, 하위 SQS 수신과 삭제도 네 배가 됩니다. 파이프라인은 매월 약 60달러에 이르며, 절대 금액으로는 여전히 작지만, 간결한 이벤트를 사용한 동일한 워크로드 비용의 네 배이며, 볼륨이 커질수록 이 격차는 더 벌어집니다. 월 5억 건의 청크 요청에서는 간결한 이벤트와 비대한 이벤트의 차이가 네 자릿수의 연간 비용 항목이 됩니다.
볼륨 구간은 존재하지만 중소기업에는 거의 중요하지 않습니다. 표준 요청은 월 1,000억 건, 2,000억 건을 넘어서면 요율이 내려갑니다. 현실적인 지렛대는 구간이 아니라 평균 청크 계수입니다.
프로덕션 메시징이 간접비가 아닌 변동 COGS인 이유
유료 고객에게 제품을 제공하는 메시징은 직접적인 매출원가입니다. 사용량에 따라 확장되고, 아무것도 판매되지 않으면 사라지며, 투자자들은 프로덕션용 컴퓨팅, 데이터베이스, 스토리지, 대역폭과 함께 매출총이익선 위에서 이를 보기를 기대합니다.
회계 기준은 여기에 여지를 남깁니다. 일반적으로 인정된 원칙은 매출원가를 정확히 정의하지 않으며, SaaS 매출총이익 관행은 직접비 테스트로 그 공백을 채웁니다. 지출이 프로덕션에서 고객에게 서비스를 제공하기 위해 존재하는지 물어보세요. 주문 이벤트를 처리하는 프로덕션 큐, 고객 대면 워커로 팬아웃하는 알림 토픽, 고객 엔드포인트로의 웹훅 전달은 모두 통과합니다. 스테이징 큐, 부하 테스트 토픽, 개발자 샌드박스 구독, 그리고 지난 분기 부하 테스트를 소진하는 데드 레터 큐는 통과하지 않습니다. 이들은 연구개발비나 일반 간접비에 속합니다.
프로덕션 경계가 전부입니다. 하나의 AWS 청구서가 모든 큐와 토픽을 한데 묶으므로, 프로덕션 리소스에 태그를 붙이고 매월 청구서를 분할하세요. 분할을 건너뛰는 팀은 보통 자기에게 유리한 방향으로 잘못을 저질러, 인프라를 간접비에 묻고 단위 경제성이 방어할 수 없는 매출총이익을 보고합니다. 실사 검토는 오후 한나절 만에 이를 재분류하며, 재작성된 마진은 결코 더 높은 쪽이 아닙니다.
실제로 지불하는 순액을 기록하세요. 무료 티어는 청구 할인이지 수익이 아니므로 총액으로 되돌릴 것이 없습니다. 무료 티어가 워크로드의 얼마나 흡수하는지 가시성을 원한다면, 지표에서 과금 요청을 별도로 추적하고 원장 항목은 현금 원가로 유지하세요.
마진이 진실을 말하도록 기록하는 방법
메시징에 일반적인 클라우드나 소프트웨어 항목에 섞지 말고 고유한 매출원가 계정을 부여하세요. cloud messaging 같은 전용 계정은 해당 월 지출을 해당 월의 과금 요청으로 나누어 청크 요청당 실제 비용을 보여주며, 이것이 페이로드 증가가 마진을 잠식하고 있는지 알려주는 숫자입니다.
AWS 청구는 월말 이후에 정산되므로 미지급으로 계상하세요. 마감 시 요청 지표로부터 메시징 부분을 추정하고, 청구서가 도착하면 실제 금액으로 조정하며, 샌드박스 부분은 매출원가에서 제외하세요. 프로덕션 메시징이 18달러 40센트이고 샌드박스가 2달러 10센트를 추가한 달의 전체 주기는 다음과 같습니다.
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Expenses:CostOfSales:Cloud-Messaging USD
2026-01-01 open Expenses:Research:Cloud-Sandbox USD
2026-01-01 open Liabilities:Accrued:AWS USD
2026-01-31 * "AWS" "1월 SQS 프로덕션 820만 청크 요청 + SNS 게시 및 HTTP 전달"
Expenses:CostOfSales:Cloud-Messaging 18.40 USD
Liabilities:Accrued:AWS -18.40 USD
2026-02-03 * "AWS" "1월 AWS 청구 정산, 프로덕션 메시징 + 샌드박스 2.10"
Liabilities:Accrued:AWS 18.40 USD
Expenses:Research:Cloud-Sandbox 2.10 USD
Assets:Cash:Operating -20.50 USD최소한 매월 서비스 및 사용 유형별로 그룹화한 비용 탐색기와 미지급 금액을 대조하세요. SQS와 SNS는 별도 항목으로 나타나야 하므로, 한쪽의 급증이 다른 쪽의 평탄한 추세 속에 숨지 않습니다. 원장을 평문으로 유지한다면, 문서의 비용 추적 패턴이 서비스별 메시징 분할로 자연스럽게 확장됩니다.
피해야 할 분류 함정 하나: FIFO 할증과 확장 보존 스토리지는 여전히 메시징 비용이지만, 실제 재처리 기간을 넘어선 확장 보존은 전달 비용이 아니라 스토리지 선택입니다. 보존 기간을 줄이거나 스토리지 부분을 제자리로 옮기세요. 14일 보존 정책이 조용히 매출원가를 부풀리도록 두지 마세요.
청구서를 보통 30~50퍼센트 줄이는 다섯 가지 통제
롱 폴링과 배치 처리부터 시작하세요. 이 둘을 함께 적용하면 SQS 지출을 거의 절반으로 줄이는 경우가 흔하며, 구현에 오후 한나절이 걸립니다.
1. 모든 곳에서 롱 폴링 활성화
모든 큐에서 수신 대기 시간을 20초로 설정하세요. 그러면 워커가 빈 폴링을 반복하는 대신 연결을 열어 둔 상태로 유지되어, 유휴 큐 청구서를 지배하는 빈 수신 항목이 급감하고 소비자의 CPU 급증이 완화됩니다.
2. 허용되는 모든 API 호출을 배치 처리
전송, 수신, 삭제는 모두 최대 10건의 메시지 배치를 지원합니다. 호출당 하나의 메시지를 처리하는 워커는 한 번에 열 건을 소진하는 워커보다 열 배의 요청 수를 지불합니다. 배치 삭제가 가장 흔히 놓치는 부분입니다. 전송은 세심하게 배치 처리하는 팀이 삭제는 하나씩 하는 경우가 많습니다.
3. 페이로드를 다이어트시키기
각 이벤트를 하나의 64 KB 청크 미만으로 유지하세요. 전체 문서는 객체 스토리지에 저장하고, 소비자가 필요로 하는 식별자가 담긴 참조를 보내세요. 이것이 클레임 체크 패턴입니다. 참조가 비현실적인 경우에는 압축하고, 포함된 블롭, 중복된 고객 레코드, 장황한 디버그 컨텍스트를 핫 경로에서 제거하세요. 제거한 청크마다 전송, 수신, 삭제, 게시, 전달에 걸쳐 배수로 효과가 나타납니다.
4. 토픽에서 필터링
필터 정책을 연결하여 각 구독자가 처리하는 이벤트만 수신하도록 하세요. 필터링 없는 팬아웃은 소비자가 도착하자마자 버리는 메시지에 대해 전달 및 하위 처리 비용을 지불합니다. 구독당 한 줄 수정으로 해결되는 순수한 낭비입니다.
5. 순서 보장이 실제로 필요한 곳에만 FIFO 사용
어떤 큐가 진정으로 순서 보장과 중복 제거를 필요로 하는지 감사하세요. FIFO 할증은 큐의 모든 청크 요청에 적용되므로, 아무도 순서를 정하지 않는 이벤트를 처리하는 FIFO 큐는 상시 25퍼센트 할증입니다. 감사하는 동안, 독성 메시지가 재시도되어 요청 수를 크게 늘리도록 두지 말고 짧은 보존 기간과 실패용 데드 레터 큐를 설정하세요.
청구서를 예측하는 두 가지 지표를 모니터링하세요. 대략적인 전송 메시지 수와 빈 수신 횟수입니다. 빈 수신이 전체 수신의 작은 비중을 초과하면 경고하고, 분기별로 큐당 평균 페이로드 크기를 검토하세요. 페이로드 증가는 매월 놓치기 쉽고 연간으로는 중요할 만큼 점진적입니다.
메시징 비용에 대한 월말 체크리스트
숫자가 신뢰할 수 있도록 매월 같은 방식으로 루프를 닫으세요.
- 애플리케이션 로그의 논리적 메시지 수가 아니라 청구 내역에서 SQS와 SNS의 청크 요청 수를 가져오세요.
- 각 서비스의 지출을 청크 요청으로 나누어 실제 단위 비용을 구하고, 40센트와 50센트의 정가 벤치마크와 비교하세요.
- 과금 요청을 논리적 메시지로 나누어 큐당 평균 청크 계수를 계산하세요. 1.2를 넘는 것은 페이로드 검토가 필요합니다.
- 리소스 태그를 사용하여 프로덕션과 스테이징, 샌드박스 지출을 분할하고, 프로덕션만 매출원가에 반영되었는지 확인하세요.
- 지난달 미지급 금액을 정산된 청구서에 맞춰 조정하고, 차이를 추정치에 이월하세요.
- 전체 수신 중 빈 수신의 비중을 확인하고, 인프라 변경 후에도 롱 폴링이 여전히 활성화되어 있는지 확인하세요.
- 해당 월에 생성된 모든 새 큐와 토픽이 프로덕션 태그와 필터 정책을 상속했는지 확인하세요.
오늘 청구 콘솔에서 이번 달의 SQS와 SNS 항목을 가져와 평균 청크 계수를 계산해 보세요. 1.2를 넘는다면, 가장 저렴한 마진 개선책은 더 큰 요금제가 아니라 더 작은 페이로드입니다.
