본문으로 건너뛰기

전송량이 전부다: Synadia Cloud의 GiB당 NATS 전송량 요금을 변동 인프라 매출원가로 기록하기

게시됨 약 9분Mike ThriftMike Thrift
전송량이 전부다: Synadia Cloud의 GiB당 NATS 전송량 요금을 변동 인프라 매출원가로 기록하기
이 페이지에서

월 49달러 Starter 플랜에 가입하고 딱 그 금액만 예산에 잡았습니다. 그런데 두 번째 청구서는 두 배로 날아오고, 대시보드 어디에도 그 이유가 설명되어 있지 않습니다. 플랜 가격은 애초에 진짜 가격이 아니었습니다. 클라우드에서 나가는 바이트가 진짜 가격이었습니다. Synadia Cloud는 애플리케이션이 NATS 서비스에서 빼내는 모든 기가바이트를 계량하며, 초과분에서 정액 구독이 트래픽에 따라 늘어나는 변동 청구서로 바뀝니다.

시점이 중요합니다. NATS는 2026년 11월 10일 CNCF에서 졸업했으며, 4억 회 이상 다운로드되고 2,000개 이상의 기업이 사용하고 있습니다. 지금 수많은 팀이 셀프 호스팅 NATS에서 관리형 클라우드로 옮겨가며, 운영 부담을 한 번도 지켜본 적 없는 계량기와 맞바꾸고 있습니다. 이 글은 Synadia Cloud가 네트워크 데이터에 어떻게 요금을 매기는지, 실제 규모에서 얼마가 드는지, 프로덕션 메시징이 왜 간접비가 아니라 매출원가에 속하는지, 그리고 매출총이익률이 사실을 말하도록 어떻게 기록하는지 설명합니다.

Synadia Cloud는 네트워크 데이터에 어떻게 요금을 매기는가​

Synadia는 플랜을 팀에 적용하며, 모든 팀은 무료 Personal 플랜에서 시작합니다. 유료 사다리는 짧습니다. Starter는 월 49달러, Pro는 월 199달러, Enterprise는 맞춤 계약입니다. 각 등급은 연결, 스트림, 스토리지 한도와 함께 포함 네트워크 데이터 블록을 묶어 제공합니다. Personal은 10GiB, Starter는 100GiB, Pro는 1TiB, Enterprise는 2TiB를 포함합니다.

포함 블록이 전부입니다. 그 이후에 무슨 일이 일어나는지는 플랜에 달려 있기 때문입니다. 무료 Personal 플랜에서는 초과 청구가 전혀 없습니다. 팀이 10GiB를 초과하면 다음 청구 주기까지 또는 플랜을 업그레이드할 때까지 활성 및 신규 클라이언트 연결이 끊깁니다. 데모 당일의 트래픽 급증은 Personal에서 비용이 들지 않습니다. 가용성이 들 뿐입니다.

모든 유료 플랜에서 초과분은 계량되어 청구 주기 말에 트래픽 유형별로 부과됩니다. 거의 한 자릿수 차이로 구분되는 세 가지 요율입니다.

  • 클라이언트 및 리프 전송량: GiB당 9센트
  • 게이트웨이 전송량: GiB당 2센트
  • 라우트 인그레스 및 이그레스: GiB당 1센트

이 목록에서 빠진 것을 주목하세요. 클라우드로의 발행은 계량되지 않습니다. 계량기는 밖으로 흐르는 바이트에서 작동하며, 이는 팬아웃이 모든 Synadia 청구서의 배수라는 뜻입니다. 한 번 발행되어 열 개 소비자에게 전달되는 메시지는 하나가 아니라 열 번의 전송량 전달입니다.

클라이언트 및 리프 전송량: GiB당 9센트​

실제 청구서를 지배하는 요율이며, 시스템이 데이터를 소비하는 두 가지 방식을 모두 포괄합니다. 클라이언트 전송량은 클라우드에서 애플리케이션으로 전달되는 모든 바이트입니다. 구독자 전달, 요청-응답 응답, 스트림 읽기가 여기에 해당합니다. 리프 전송량은 같은 개념을 엣지로 확장한 것입니다. 리프 노드는 자체 네트워크에 있는 NATS 서버로, 클라우드 허브로 아웃바운드 연결하여 그 링크를 통해 서브젝트 관심사를 브리징합니다. 따라서 방화벽 뒤의 공장 현장이나 소매점이 인바운드 방화벽 규칙 없이도 발행하고 구독할 수 있습니다.

청구상의 결과는 엣지가 무료가 아니라는 점입니다. 클라우드가 리프 링크로 전달하는 모든 바이트는 최고 요율의 전송량입니다. orders.created 같은 좁은 서브젝트로 범위가 지정된 리프 구독은 정확히 그 서브젝트만 끌어옵니다. 모든 것을 끌어오는 느슨한 구독은 9센트짜리 링크로 전체 파이어호스를 끌어옵니다. 엣지에서의 관심사 범위 지정은 단순한 위생이 아니라 비용 통제입니다.

게이트웨이 전송량: GiB당 2센트​

게이트웨이는 클러스터를 슈퍼클러스터로 연결하며, 보통 리전 간에 연결합니다. 그래서 한 리전의 워크로드가 다른 리전의 서브젝트에 접근할 수 있습니다. 게이트웨이 전송량은 그 클러스터 간의 복제 및 교차 리전 트래픽이며, GiB당 2센트로 계량됩니다.

2센트는 무시해도 될 것 같지만, 그 밑에 클라우드 제공업체 자체의 전송 요금이 겹친다는 점을 기억해야 합니다. Synadia 자체의 운영 가이드는 높은 게이트웨이 트래픽 비율을 고칠 만한 문제로 지적하며, 가용 영역 간 전송만으로도 각 방향 Gigabyte당 약 1센트가 든다고 언급합니다. 리전 간 복제를 많이 하는 팀은 같은 바이트에 대해 제공업체의 전송 비용과 Synadia의 게이트웨이 계량기를 모두 지불합니다. 아키텍처가 진정으로 지리적 분산을 필요로 하지 않는 한 발행자, 스트림, 소비자를 한 리전에 유지하세요.

라우트 트래픽: GiB당 1센트​

라우트는 NATS 서버 간의 클러스터 내 링크로, 클러스터를 일관되게 유지하는 라우팅 및 복제 통신을 나릅니다. 양 방향 GiB당 1센트로, 설계상 이 페이지에서 가장 저렴한 계량기입니다. 탄력적인 다중 서버 토폴로지를 운영하는 데 불이익이 없도록 존재합니다. 라우트 트래픽이 청구서에서 의미 있는 항목으로 나타난다면 구조적으로 뭔가 잘못된 것입니다. 클라이언트 전송량 1달러에 맞서려면 아홉 배의 볼륨이 필요하기 때문입니다.

실제 규모에서 드는 비용​

기가바이트당 요율은 곱해봐야 의미가 있으므로, 현실적인 세 가지 형태를 소개합니다.

서비스 몇 개로 이루어진 사이드 프로젝트는 고민할 것 없이 Starter의 100GiB 안에 들어갑니다. 매일 1만 개의 작은 메시지가 각각 두 소비자에게 전달되면 한 달에 대략 20GiB가 이동합니다. 청구서는 49달러 정액, 초과분 없음, 포함 데이터에 대한 실효 요율은 GiB당 약 49센트입니다. 이 규모에서의 실수는 필요하지도 않은 여유분을 위해 Pro로 업그레이드하는 것입니다. 한 번도 건드리지 않는 기가바이트를 유지하려고 매달 150달러를 더 내는 셈입니다.

중간 규모의 SaaS 플랫폼이 주문 및 알림 이벤트를 워커와 두 개의 엣지 리프 노드로 스트리밍하면 한 달에 약 1.2TiB의 클라이언트 및 리프 전송량이 발생합니다. Starter에서는 9센트로 약 1,129GiB의 초과분, 즉 49달러 기본료에 약 102달러가 더해진 151달러 청구서가 됩니다. 여전히 Pro의 199달러보다 저렴하며, 손익분기점은 대부분의 팀이 짐작하는 것보다 멀리 있습니다. Starter에서 Pro로의 150달러 도약이 네트워크 데이터만으로 본전을 뽑으려면 월 초과분이 약 1.6TiB를 넘어야 합니다. 그 선 아래에서는 연결, 스트림, 스토리지 때문에 업그레이드하는 것이지, 데이터 블록 때문이 아닙니다. 업그레이드 버튼을 누르기 전에 그 나눗셈을 해보세요.

이제 지리적 복제를 추가해 보겠습니다. 같은 플랫폼이 재해 복구를 위해 리전 간에 스트림을 미러링하여 500GiB의 게이트웨이 전송량을 추가하고, 총 클라이언트 전송량은 Pro 플랜에서 2TiB 바로 아래에 이릅니다. 클라이언트 초과분은 포함된 테라바이트를 넘는 960GiB로 9센트씩, 즉 86.40달러입니다. 게이트웨이 초과분은 500GiB에 2센트씩, 즉 10달러입니다. 청구서는 199더하기 96.40, 즉 295.40달러이며, 초과분의 3분의 2는 화이트보드에 그려질 때 아무도 값을 매기지 않은 복제 토폴로지에서 나옵니다. 이것이 뜻밖의 Synadia 청구서의 반복되는 형태입니다. 큰 숫자 하나가 아니라, 팬아웃과 복제가 작은 요율을 배수로 키우는 것입니다.

왜 프로덕션 메시징은 간접비가 아니라 변동 매출원가인가​

고객에게 제품을 전달하는 메시징은 직접적인 매출 원가입니다. 사용량에 따라 늘어나고, 아무것도 판매되지 않으면 사라지며, 투자자는 그것이 프로덕션용 컴퓨트, 데이터베이스, 스토리지, 대역폭과 나란히 매출총이익률 위에 나타나기를 기대합니다.

회계 기준은 여기에 여지를 남깁니다. 일반적으로 인정된 원칙은 매출원가를 정확히 정의하지 않으며, SaaS 매출총이익률 관행이 직접비 테스트로 그 공백을 메웁니다. 그 지출이 프로덕션에서 고객에게 서비스하기 위해 존재하는지 물어보세요. 주문 이벤트를 나르는 스트림, 고객 대면 워커로 팬아웃되는 전달, 고객에게 서비스하는 엣지 위치로 데이터를 공급하는 리프 링크는 모두 통과합니다. 지난주 트래픽을 재생하는 스테이징 계정, 부하 테스트 토픽, 개발자 샌드박스 구독은 통과하지 못합니다. 그것들은 연구개발이나 일반 간접비에 속합니다.

프로덕션 경계가 전부입니다. Synadia 청구서 한 장이 모든 계정과 모든 트래픽 유형을 한데 묶으므로, 대시보드의 계정별 사용량을 사용해 매달 분할하세요. 분할을 건너뛰는 팀은 보통 자기에게 유리한 방향으로 잘못을 저지릅니다. 인프라를 간접비에 묻고, 단위 경제성이 방어할 수 없는 매출총이익률을 보고하는 것입니다. 실사 검토는 한나절 만에 이를 재분류하며, 재작성된 마진이 더 높은 쪽인 경우는 결코 없습니다.

실제로 지불하는 순액을 기록하세요. 사용하지 않은 포함 데이터는 자산이 아니며 무료 Personal 등급은 매출이 아니므로, 총액으로 올리거나 이월할 것이 없습니다. 여유분에 대한 가시성이 필요하다면 지표에서 소비된 기가바이트 대 포함 기가바이트를 추적하고, 원장 기입은 현금 원가로 유지하세요.

마진이 사실을 말하도록 기록하는 방법​

메시징에 일반 클라우드나 소프트웨어 항목과 섞지 말고 고유의 매출원가 계정을 주세요. cloud messaging 같은 전용 계정을 두면 월 지출을 월 전송량 기가바이트로 나누어 진짜 GiB당 원가를 볼 수 있으며, 이것이 팬아웃 성장이 마진을 잠식하고 있는지 알려주는 숫자입니다.

Synadia 요금은 월말 이후에 정산되므로 발생주의로 기록하세요. 마감 시 전송량 지표로 프로덕션 부분을 추정하고, 청구서가 도착하면 실제 금액으로 조정하며, 비프로덕션 부분은 매출원가에서 제외하세요. 다음은 프로덕션이 추정 291.20달러를 기록하고 실제 청구서가 295.40달러였으며, 개발용으로 별도의 49달러 Starter 팀이 있었던 1월의 전체 주기입니다.

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:Synadia USD
 
2026-01-31 * "Synadia" "1월 프로덕션 추정치, Pro 기본료 더하기 클라이언트-리프 및 게이트웨이 초과분"
  Expenses:CostOfSales:Cloud-Messaging  291.20 USD
  Liabilities:Accrued:Synadia  -291.20 USD
 
2026-02-03 * "Synadia" "1월 청구서 295.40 정산 더하기 49.00 개발 팀"
  Liabilities:Accrued:Synadia  291.20 USD
  Expenses:CostOfSales:Cloud-Messaging  4.20 USD
  Expenses:Research:Cloud-Sandbox  49.00 USD
  Assets:Cash:Operating  -344.40 USD

최소한 매달 발생 금액을 대시보드의 계정별 네트워크 사용량과 조정하고, 클라이언트, 게이트웨이, 라우트 트래픽을 별도 항목으로 두어 한쪽의 급증이 다른 쪽의 평탄한 추세 속에 숨지 않도록 하세요. 장부를 플레인 텍스트로 유지한다면, 문서의 비용 추적 패턴이 트래픽 유형별 메시징 분할로 자연스럽게 확장됩니다.

피해야 할 분류 함정 하나: 추가 리프 노드, 연결 패키지, 스토리지 같은 애드온은 프로덕션에 서비스한다면 여전히 메시징 비용이지만, 자체 셀프 호스팅 NATS 시스템을 연결하는 Remote System 애드온은 하이브리드 아키텍처 선택입니다. 그 링크가 현재 고객에게 서비스하기 위해서가 아니라 레거시 온프레미스 시스템을 유지하기 위해 존재한다면, 그 시스템의 비용이 사는 곳에 속하며 매출원가에는 속하지 않습니다.

전송량이 마진을 잠식하지 못하게 하는 다섯 가지 통제​

팬아웃 규율과 페이로드 크기에서 시작하세요. 둘은 함께 배수와 피승수를 다루며, 둘 다 한나절이면 되는 수정입니다.

1. 모든 전달을 구매로 취급하라​

각 구독자 전달은 별도로 계량되는 전송량이므로, 누가 무엇을 받는지 감사하세요. 빡빡한 서브젝트 범위를 붙여 모든 소비자가 처리하는 이벤트만 받도록 하고, 퇴역한 워커의 죽은 구독을 제거하세요. 필터링 없는 팬아웃은 소비자가 도착하자마자 버리는 메시지에 대해서도 전달 비용을 지불합니다. 구독당 한 줄 수정으로 해결되는 순수한 낭비입니다.

2. 페이로드를 다이어트시켜라​

이벤트를 간결하게 유지하세요. 전체 문서는 오브젝트 스토리지에 저장하고 소비자가 필요한 식별자가 담긴 참조를 보내세요. 클레임 체크 패턴입니다. 포함된 블롭, 중복된 고객 레코드, 장황한 디버그 컨텍스트를 핫 패스에서 제거하세요. 제거하는 모든 기가바이트는 그것을 실은 모든 메시지의 모든 전달에서 9센트를 절약합니다. 그래서 페이로드 크기가 보통 플랜 쇼핑보다 나은 절감 수단입니다.

3. 리프 노드 관심사를 빡빡하게 범위 지정하라​

리프 링크는 반대편에 관심사가 있는 서브젝트만 전달하므로, 엣지 구독이 9센트 파이프의 밸브입니다. 분기마다 모든 리프 구독을 검토하고 각각이 여전히 살아 있는 엣지 워크로드에 서비스하는지 확인하세요. 한 매장의 잊힌 캐치올 구독 하나가 전체 서브젝트 공간을 청구서에서 가장 비싼 링크로 조용히 끌어내릴 수 있습니다.

4. 스트림을 소비자 근처에 두라​

아키텍처가 허용하는 한 발행자, 스트림, 소비자를 한 리전에 같은 곳에 두세요. 교차 리전 복제는 같은 바이트에 게이트웨이 초과분과 제공업체의 기저 전송 요금을 함께 지불합니다. 그래서 모든 게이트웨이 기가바이트는 필요하다고 입증될 때까지 유죄로 취급하세요. 재해 복구가 진정으로 두 번째 리전을 필요로 한다면 전체 계정이 아니라 복구 목표를 충족하는 가장 작은 서브젝트 집합만 복제하세요.

5. 플랜을 적정화하고 소진율을 감시하라​

소비된 기가바이트 대 포함 기가바이트를 월간이 아니라 주간으로 추적하세요. 초과분은 주기가 끝날 때까지 조용히 누적되기 때문입니다. 데이터 이유로 Starter를 Pro로 업그레이드하기 전 1.6TiB 손익분기점을 기억하고, 반대 방향의 Personal 절벽도 기억하세요. 무료 등급에서 프로토타이핑하는 팀은 신경 쓰는 트래픽 급증이 오기 전에 업그레이드해야 합니다. Personal은 초과분에 청구서가 아니라 끊긴 연결로 응답하기 때문입니다.

메시징 비용을 위한 월말 체크리스트​

숫자를 신뢰할 수 있도록 매달 같은 방식으로 루프를 닫으세요.

  1. 애플리케이션 로그의 논리적 메시지 개수가 아니라 대시보드의 트래픽 유형별 전송량 기가바이트를 가져오세요.
  2. 각 유형의 지출을 해당 기가바이트로 나누고 9, 2, 1센트 벤치마크와 비교하세요.
  3. 전달 수를 발행 수로 나누어 서브젝트별 전달 팬아웃을 계산하세요. 설계 비율을 넘는 것은 구독 검토가 필요합니다.
  4. 계정별로 프로덕션과 스테이징 및 샌드박스 사용량을 분할하고, 프로덕션만 매출원가에 반영되었는지 확인하세요.
  5. 지난달 발생 금액을 정산된 청구서에 맞춰 조정하고 차이를 추정치에 이월하세요.
  6. 총 전송량에서 게이트웨이 트래픽 비중을 확인하고, 모든 교차 리전 흐름이 여전히 아키텍처적 이유가 있는지 점검하세요.
  7. 해당 월에 생성된 모든 신규 계정, 스트림, 리프 노드가 프로덕션 태깅과 빡빡한 서브젝트 범위를 물려받았는지 확인하세요.

오늘 대시보드에서 이번 달 Synadia 네트워크 항목을 가져와 총 전송량 기가바이트를 포함 블록과 비교하세요. 초과분이 고객 사용량보다 빠르게 늘고 있다면, 팬아웃이나 복제가 요율을 배수로 키우는 것이며, 가장 저렴한 마진 개선은 더 큰 플랜이 아니라 더 작은 페이로드와 더 빡빡한 구독입니다.

출처: https://beancount.io/ko/blog/2026/11/11/synadia-cloud-nats-egress-pricing-variable-cogs-guide

게시됨: 2026년 11월 11일

약 9분

64 KB 청킹 규칙: AWS SQS/SNS 요청당 과금 가격을 변동 COGS로 기록하기

SQS와 SNS는 모든 API 호출에서 64 KB 청크마다 과금하므로, 200 KB 메시지는 12번의 요청 비용이 발생합니다. 프로덕션…

cost-of-goods-sold
cloud-services
약 10분

메시지당이 아닌 초당 과금: CloudAMQP의 인스턴스 시간 인보이스를 인프라 COGS로 조정하기

CloudAMQP는 인스턴스 시간을 초 단위로 청구하며 한 달 후에 청구합니다: 프로덕션 브로커는 COGS로 처리하고, 마감 시 발생액을…

cost-of-goods-sold
cloud-services
약 10분

좌석이 아닌 피처 뷰: ML 플랫폼을 위한 Tecton의 소비 크레딧 청구를 ASC 606 매출원가로 처리하기

Tecton은 소비 크레딧과 자체 계정의 클라우드 지출을 청구합니다: 프로덕션 서빙은 매출원가로, 실험은 연구개발비로 처리하고 미청구분은…

cost-of-goods-sold
machine-learning
약 9분

클라우드 비용 배분: 소규모 SaaS 팀을 위한 실용적인 쇼백 가이드

소규모 SaaS 팀을 위한 30일 쇼백 플레이북 — 보고 기준 정의, 간결한 태깅 사전 적용, 방어 가능한 공식으로 공유 비용 배분, AI…

saas
cloud-services
약 9분

웹훅 청구서는 간접비가 아니라 매출원가(COGS)입니다: Svix 및 Hookdeck 기반 이벤트 중심 SaaS의 장부 관리

Svix 및 Hookdeck 청구서는 간접비가 아닌 매출 비용입니다: 플랫폼 수수료와 측정 사용량을 분리하고, 인보이스 발행 전에 발생시켜,…

saas
cost-of-goods-sold