6.1 비용 모델
Neon 청구서는 compute, database storage, instant restore storage, 포함량 초과 branch, snapshot storage, network 항목으로 구성됩니다. Branch는 플랜에 포함된 개수 안에서는 그 자체로 추가 비용을 만들지 않습니다. 포함량을 넘기면 branch 하나하나가 시간 비례로 과금됩니다. Branch가 compute를 갖는 순간 CU-hour가 발생하고, branch에 쓰기가 생기는 순간 delta 저장량이 GB-month로 계량됩니다. 이 구조를 이해하면 "branch를 많이 만들면 비싸지는가"라는 질문에 조건을 붙여 답할 수 있습니다.
과금 축
| 축 | 단위 | 측정 대상 | 단가 (Launch, Scale) |
|---|---|---|---|
| Compute | CU-hour | compute 크기 × 실행 시간 | $0.106, $0.222 |
| Database storage | GB-month | root branch는 logical data size, restore window 안의 child branch는 delta와 logical size 중 작은 값 | $0.35 |
| Instant restore storage | GB-month | history window 안의 변경 이력 | $0.20 |
| 포함량 초과 branch | branch-month | 플랜 포함 개수를 넘긴 branch. 시간 비례로 계량 | $1.50 |
| Snapshot storage | GB-month | 선택 기능. manual, scheduled snapshot 모두 계량 | $0.09 |
| Network | GB | 공개 전송 포함량 초과분. Free 5 GB, Launch와 Scale은 project당 500 GB 포함 | $0.10 |
Compute는 compute size × hours running으로 계산합니다. 가격 문서는 1 CU를 "~4 GB RAM + CPU + SSD"로 설명합니다. vCPU 수는 이 문장에 숫자로 나오지 않으므로 정확한 값은 compute 크기 문서에서 확인합니다.
Storage는 시간 단위로 계량한 뒤 GB-month로 환산합니다. 1 GB를 한 달 보관하면 1 GB-month입니다. Root branch는 실제 데이터 크기(logical size)를 기준으로 청구됩니다. Child branch는 "생성 이후 변경량과 logical size 중 작은 값"을 기준으로 청구되는데, 이 계산은 그 branch가 restore window 안에 있을 때만 성립합니다. 가격 문서에 따르면 window 밖으로 나간 child branch는 부모와 storage를 더 이상 공유하지 않아 쓰기가 없어도 root branch 수준으로 과금됩니다. 오래 살려 둘 branch의 비용을 추정할 때 이 조건이 가장 자주 빠집니다.
Private 전송은 Scale 플랜에서 $0.01/GB이며 양방향으로 계량됩니다. Snapshot storage는 root branch에서 생성한 snapshot에만 발생하는 선택 항목입니다.
플랜별 가격과 한도
| 항목 | Free | Launch | Scale |
|---|---|---|---|
| 월 요금 | $0 | 사용량 기반 | 사용량 기반 |
| Compute 단가 | 포함 | $0.106/CU-hour | $0.222/CU-hour |
| Storage 단가 | 0.5 GB/project 포함 | $0.35/GB-month | $0.35/GB-month |
| Project 수 | 100 | 100 | 1,000 |
| 포함 branch 수/project | 10 | 10 | 25 |
| Compute 범위 | 0.25~2 CU | 0.25~16 CU autoscaling | 0.25~56 CU (autoscaling 최대 16) |
| History window | 최대 6시간 또는 변경량 1 GB | 최대 7일 | 최대 30일 |
| Scale to zero | 5분 고정 | 5분, 해제 가능 | 1분~항상 켜짐 |
AI agent 플랫폼을 위한 Agent 플랜은 신청(apply) 방식의 별도 프로그램으로 제공됩니다. 한도와 단가를 개별 협의하는 구조이므로 위 표와 나란히 비교하기 어렵습니다. Instant restore storage는 database storage와 단가가 다릅니다. 가격 문서 기준으로 $0.20/GB-month이며, $0.35/GB-month인 database storage와 섞어 계산하면 history 비용이 과대 추정됩니다.
Branch가 비용을 만드는 순간
Branch 생성은 pageserver에 timeline 메타데이터를 하나 추가하는 작업입니다. 데이터를 복사하지 않으므로 storage도 증가하지 않습니다. 비용은 두 지점에서 발생하기 시작합니다.
- Branch에 compute endpoint를 붙이고 쿼리를 실행하면 CU-hour가 발생합니다. CLI에서
neon branches create는 기본으로 read-write compute를 함께 만듭니다. Compute 없이 branch만 두려면--no-compute를 지정합니다. - Branch에서 INSERT, UPDATE, DELETE가 발생하면 delta가 누적됩니다. 100 GB 데이터베이스의 branch에서 인덱스 하나를 다시 만들면 해당 인덱스 크기만큼 delta가 생깁니다.
# compute 없는 branch: storage 0, compute 0
neon branches create --name review-2026-09 --no-compute
# compute를 붙이는 순간부터 CU-hour 계량
neon branches add-compute review-2026-09 --cu 0.25-1
Scale to zero는 이 구조에서 compute 비용을 통제하는 장치입니다. 5분 동안 연결이 없으면 compute가 멈춥니다. CU-hour 계량도 함께 멈춥니다. PR마다 branch를 만들어도 테스트가 끝난 뒤 유휴 상태라면 compute 비용은 실행 시간만큼만 발생합니다. 반대로 heartbeat나 모니터링 쿼리가 5분보다 짧은 간격으로 들어오면 compute가 중지되지 않습니다. 이 경우 24시간 과금됩니다. 이 문제는 6.2의 콜드스타트와 함께 판단해야 합니다.
History window 확대의 대가
Instant restore와 과거 시점 branching은 pageserver가 변경 이력을 보관하기 때문에 가능합니다. History window를 1일에서 7일로 늘리면 7일치 WAL 유래 delta layer가 GC 대상에서 제외됩니다. 이에 따라 storage가 늘어납니다. 증가 폭은 데이터 크기가 아니라 쓰기량에 비례합니다. 하루 20 GB를 갱신하는 workload는 7일 window에서 최대 140 GB 안팎의 이력을 유지합니다. 실제 값은 compaction과 image layer 생성에 따라 달라집니다. 따라서 콘솔의 Instant restore storage 지표로 확인합니다.
Free 플랜의 restore window는 6시간이지만 변경량 1 GB에 먼저 도달하면 그 시점에서 끝납니다. 실습 project에서 갱신 부하를 반복해서 발생시키면 6시간을 채우기 전에 이 한도에 닿습니다.
예산 추정 예시
가정을 명시한 산술입니다. Launch 플랜에서 개발팀 5명이 공유 staging branch 하나와 개인 branch 5개를 운영한다고 가정합니다.
| 항목 | 가정 | 계산 | 월 비용 |
|---|---|---|---|
| Staging compute | 2 CU, 하루 8시간, 20일 | 2 × 8 × 20 = 320 CU-hour | $33.92 |
| 개인 branch compute | 0.25 CU 최소, 하루 2시간 실제 사용, 20일, 5개 | 0.25 × 2 × 20 × 5 = 50 CU-hour | $5.30 |
| Root storage | 40 GB logical | 40 GB-month | $14.00 |
| Child branch delta | branch당 평균 2 GB, 6개 | 12 GB-month | $4.20 |
| Instant restore | 7일 window, 하루 3 GB 쓰기 | 약 21 GB-month × $0.20 | $4.20 |
| 합계 | 약 $61.62 |
Autoscaling을 켜면 staging compute는 부하가 없는 시간에 0.25 CU까지 내려갑니다. 따라서 첫 줄의 비용이 줄어듭니다. 반대로 개인 branch가 야간에도 연결을 유지하면 둘째 줄이 0.25 × 24 × 30 × 5 = 900 CU-hour로 증가해 $95.40이 됩니다. 이 표에서 변동 폭이 가장 큰 변수는 compute 실행 시간입니다. branch 개수 자체는 아닙니다.
Aurora clone과의 과금 방식 비교
Aurora clone도 copy-on-write로 생성되지만 storage 소유권을 다루는 방식이 다릅니다.
| 구분 | Neon child branch | Aurora clone |
|---|---|---|
| 생성 직후 storage | 0 | 0 (원본과 페이지 공유) |
| 쓰기 후 storage | delta, 상한은 logical size | clone이 변경한 페이지만 clone 소유 |
| 원본 삭제 시 | branch가 독립 데이터 유지 (문서상 세부 과금은 확인 필요) | 공유 페이지 소유권이 clone들로 재분배되어 clone 청구 증가 |
| CoW 개수 제한 | 플랜별 branch 수 (10 또는 25) | CoW clone 15개, 이후 full copy |
Aurora는 원본 클러스터를 삭제하면 공유 페이지의 청구가 남은 clone으로 이전됩니다. 따라서 "clone은 싸다"는 전제는 원본의 수명에 따라 달라집니다. Neon은 branch가 timeline 트리의 노드이므로 부모를 삭제하는 작업 자체에 제약이 있고, 과금은 restore window 안에서 delta 기준으로 유지됩니다.
두 방식 모두 쓰기가 없으면 storage 증분이 0에 가깝다는 점은 같습니다. 그러나 storage 증분과 compute 실행 비용은 분리해서 봐야 합니다. Aurora clone은 별도 DB cluster로 생성되므로 DB instance 또는 Serverless v2 ACU의 실행 비용이 처음부터 붙습니다. Neon child branch는 compute를 붙이지 않으면 실행 비용이 없고, 붙여도 scale to zero로 유휴 시간을 줄입니다. "clone 전체가 거의 무료"라는 표현이 성립하는 범위는 storage 증분에 한정됩니다.
비용을 줄이는 운영 습관
Branch에 만료 시각을 지정하면 방치된 branch의 compute와 delta가 자동으로 정리됩니다.
neon branches create --name ci-1234 --expires-at 2026-09-08T09:00:00Z
neon branches set-expiration review-2026-09 --expires-at 2026-09-14T00:00:00Z
History window는 복구 요구사항에 맞춰 정합니다. 개발용 project는 1일 이하로 둡니다. 개인 branch는 필요할 때 compute를 붙입니다. neon branches reset --parent로 부모 상태에 맞추면 delta가 초기화됩니다. Reset 후 storage 지표가 내려가는지 확인하는 습관은 청구 예측의 정확도를 높입니다.
콘솔 지표로 검증하기
추정치는 콘솔의 Projects 페이지와 project dashboard에 표시되는 compute, storage, history, network 지표로 검증합니다. 사용량 기반 플랜에서는 Consumption metrics API로 같은 값을 가져옵니다. 월초에 추정표를 만들고 매주 실제 지표와의 차이를 기록합니다. 그러면 어떤 가정이 빗나갔는지 빠르게 드러납니다. 자주 빗나가는 가정은 compute 실행 시간과 history 저장량입니다. root storage는 예측이 잘 맞습니다.
연습 문제
- 팀의 현재 개발 DB 서버 월 비용을 CU-hour와 GB-month로 환산해 위 표와 비교합니다.
- Branch 하나에
pgbench -i -s 100을 실행한 뒤 콘솔의 storage 지표가 얼마나 늘어나는지 기록하고, logical size 상한에 닿는 시점을 관찰합니다. - Scale to zero를 비활성화한 branch와 기본값 branch의 하루 CU-hour 차이를 계산합니다.
심화 체크
- 우리 workload의 일일 쓰기량으로 7일 history window가 만드는 storage를 추정했는가?
- CI 파이프라인이 만드는 branch에 만료 시각이 모두 붙어 있는가?
- 모니터링 에이전트의 접속 주기가 scale to zero를 막고 있지 않은가?