
2026년 정말 중요한 단 9가지 SaaS 지표 (1,300개 이상 기업 벤치마킹)
Aleph × Benchmarkit의 342개 기업 패널에서 매출총유지율(GRR) 중앙값은 2025년 한 해 동안 88%에서 84%로 떨어졌습니다(Aleph × Benchmarkit, 2026 SaaS & AI Performance Benchmarks). 4포인트, 단 1년 만에. 하지만 대부분의 이사회 보고서에서 정말 중요한 SaaS 지표를 판단하는 기준은 여전히 자본이 사실상 공짜였던 2021년 10월, 데이비드 삭스(David Sacks)가 발표한 임계값입니다. 그 기준은 살짝 낡은 정도가 아닙니다. 더 이상 존재하지 않는 시장에 맞춰 보정된 것입니다. 이제부터 살펴볼 것은 아홉 가지 지표입니다. 모든 수치는 표본 크기까지 명시된 2026년판 보고서로 추적 가능하며, 저희가 그만 추적해야 한다고 생각하는 여섯 가지 지표도 함께 다룹니다.
핵심 요약
- 사용량 기반(usage-based) SaaS는 NRR 중앙값 108%를 기록해, 좌석 기반(seat-based) 모델의 98%보다 10포인트 앞섰습니다(Benchmarkit 2026, n=230).
- 매출총유지율(GRR) 중앙값은 전년 대비 88%에서 84%로 하락했습니다(Benchmarkit 2026).
- 부트스트랩(자체 자금조달) SaaS는 $3–20M ARR 구간에서 성장률 중앙값이 20%에서 15%로 둔화했습니다(SaaS Capital 2026, n>1,000).
- 2026년 정말 중요한 지표는 아홉 개이며, 흔히 추적되는 여섯 개는 그렇지 않습니다. 이 글은 그 여섯 가지를 구체적으로 짚습니다.
2026년 SaaS 벤치마크는 실제로 무엇을 말하는가?
2026년판 SaaS 지표 벤치마크는 모두 2025년 전체 실적을 기준으로 하며, 성장 측면에서는 시장이 더 어려워졌고 효율성 측면에서는 다소 나아졌다는 것을 보여줍니다. 순매출유지율(NRR) 중앙값은 102%, 매출총유지율(GRR) 중앙값은 84%로 둘 다 전년 대비 하락했으며, CAC 회수 기간 중앙값은 18개월에서 16개월로 개선됐습니다(Aleph × Benchmarkit, CY-2025; NRR n=230, CAC payback n=198, GRR 표본 크기 비공개).
이 모든 내용을 표 하나에 담았습니다. 사람들이 계속 검색하는 그 SaaS 지표 치트시트입니다. 스크린샷으로 저장하고, 인용하고, 반박해 보세요. 모든 수치는 2026년에 발표된 벤치마크의 CY-2025 실적이며, 달러(USD)는 발표된 그대로입니다. 출처가 공개하지 않은 구간은 n/a로 표시했으며, 추정치는 절대 넣지 않았습니다. 표기 방식에 대한 한 가지 참고 사항: SaaS Capital은 자사 수치를 "2026 medians"(2026년 중앙값)이라고 부르는 반면, Aleph와 Benchmarkit은 같은 보고 기간을 CY-2025로 표기합니다. 이 글에서는 일관성을 위해 CY-2025로 통일해 사용하지만, 기준이 되는 데이터 연도는 동일합니다.
| 지표 | 중앙값 (CY-2025) | 상위 25% (CY-2025) | 출처 (표본) |
|---|---|---|---|
| 순매출유지율(NRR) | 102% | 108%, 110–111%에서 하락 | Aleph × Benchmarkit (n=230) |
| 매출총유지율(GRR) | 84%, 이전 88% | 91%, 이전 95% | Aleph × Benchmarkit |
| 로고 유지율 / 고객 이탈률 | n/a | n/a | 2026년판 보고서 중 추적 가능한 수치 없음 |
| CAC 회수 기간 | 16개월, 이전 18개월 | 6개월 이하 | Aleph × Benchmarkit (n=198) |
| 번 배수(Burn multiple) | n/a | n/a | 미공개; 아래 CAC 비율 대체 지표 참고 |
| 직원 1인당 ARR | $193K, 29% 증가 | 약 $279K | Aleph × Benchmarkit (n=96) |
| 전년 대비 성장률, $3–20M ARR | 15%, 이전 20% | 90번째 백분위수 42.3% | SaaS Capital (n>1,000) |
| 소프트웨어 매출총이익률 | 80% | 86% 이상 | Aleph × Benchmarkit (n=228–232) |
| Rule of 40 | 25%, 이전 15%에서 상승 | 43% | Aleph × Benchmarkit |
중앙값은 "시장의 절반이 이 수치보다 낮다"는 뜻으로 읽어야지, 합격선으로 읽으면 안 됩니다. 이 아홉 개 지표는 세 그룹으로 나뉩니다:
- 유지율(Retention): NRR, GRR, 로고 유지율
- 효율성(Efficiency): CAC 회수 기간, 번 배수, 직원 1인당 ARR
- 성장 품질(Growth quality): 성장률, 매출총이익률, Rule of 40
업계 절반이 자본이 공짜였던 시절에 쓰인 기준으로 평가받고 있습니다.
이 벤치마크는 어떻게 만들어졌나 (방법론과 표본 크기)
저희가 직접 설문조사를 한 것은 아닙니다. 이 글의 정체는 이렇습니다. 실명이 공개된 2026년판 보고서들을 정규화해 모은 메타 벤치마크입니다. 모든 수치는 그중 한 보고서에 속하며 출처가 명시되어 있습니다. 저희 자체 작업을 다루는 유일한 섹션, 즉 이 수치들이 실제 구현에서 어떻게 어긋나는지를 다루는 부분에는 통계가 전혀 없습니다. 저희가 직접 측정한 수치가 없기 때문입니다.
| 보고서 | 발행처 | 발행일 | 표본 | 기여 지표 |
|---|---|---|---|---|
| 2026 SaaS & AI Performance Benchmarks | Aleph × Benchmarkit | 2026-06-01 | 총 342개사; NRR 230개사, CAC 회수 기간 198개사, 매출총이익률 228–232개사, 직원 1인당 ARR 96개사 | NRR, GRR, CAC 회수 기간, 매출총이익률, 직원 1인당 ARR, Rule of 40 |
| 2026 Benchmarking Metrics for Bootstrapped SaaS Companies | SaaS Capital | 2026 | 1,000개 이상의 비상장 B2B SaaS 기업 | 성장률, ARR 구간별 NRR·GRR, 90번째 백분위수 |
| 2026 Spending Benchmarks for Private B2B SaaS | SaaS Capital | 2026 | 동일 패널 | 영업·마케팅(S&M) 및 연구개발(R&D) 지출 비율 |
| SaaS Metrics Standard | SaaS Metrics Standards Board | 표준 문서, 2023년경 제정, 계속 업데이트 중 | n/a | 저희가 정규화 기준으로 삼은 ARR 및 유지율 정의 |
"1,300개 이상"의 계산 근거: Benchmarkit 패널의 342개사에 SaaS Capital 패널의 1,000개사 이상을 더하면 1,342개사를 넘습니다. SaaS Capital 패널은 위에 등장하는 두 보고서가 동일한 응답자 기반에서 나온 것이므로 한 번만 셌습니다.
정의는 SaaS Metrics Standards Board의 기준에 맞춰 정규화했습니다. NRR은 고정된 코호트를 기준으로 확장(expansion), 축소(contraction), 이탈(churn)을 측정하며 신규 고객은 완전히 제외합니다. 아래쪽의 SQL 코드가 정확히 이 원칙을 강제합니다.
의도적으로 뺀 수치도 있습니다. "직원 1인당 매출 $129,724"라는 수치와 "SaaS 기업 중 Rule of 40을 통과하는 곳은 11~30%뿐"이라는 주장입니다. 둘 다 1차 보고서가 아니라 어느 애그리게이터(aggregator)의 자체 분석에서 나온 것입니다. 이 검색 결과 상위 10개 페이지 중 자신의 수치가 어디서 나왔는지 설명하는 곳은 단 하나도 없습니다.
한 가지는 밝히고 넘어가겠습니다. 그러지 않으면 이 글 자체가 위선이 됩니다. 저희가 인용하는 두 출처는 직원 1인당 ARR에서 서로 다른 수치를 제시합니다. Benchmarkit의 요약 페이지는 $175K, 17% 증가를 헤드라인으로 내세우고, Aleph의 지표별 상세 페이지는 같은 패널을 기준으로 $193K, 29% 증가를 보고합니다. 저희는 $193K를 사용했는데, 이 페이지가 표본(n=96)을 공개하고 전체 분포까지 함께 발표하는 반면 요약 헤드라인은 둘 다 공개하지 않기 때문입니다. 다른 수치를 택해도 합리적인 선택일 수 있습니다. 다만 누구도 해서는 안 되는 일은, 어느 페이지에서 나온 수치인지 밝히지 않고 둘 중 하나를 인용하는 것입니다.
유지율: NRR, GRR, 그리고 로고 이탈
순매출유지율(NRR)
**순매출유지율(NRR)**은 순달러유지율(net dollar retention)이라고도 불리며, 고정된 고객 코호트가 12개월 뒤 얼마를 지불하는지를 측정합니다. 확장, 축소, 이탈을 모두 반영하지만 신규 고객은 제외합니다. CY-2025 중앙값은 **102%**이고, 25번째 백분위수는 92%로 2024년의 95%에서 하락했습니다(Aleph × Benchmarkit, n=230).
공식: NRR = (starting MRR + expansion − contraction − churn) ÷ starting MRR. $100K에서 시작한 코호트가 $12K만큼 확장하고, $4K만큼 축소하고, $6K만큼 이탈했다면 102%가 됩니다.
이제 이 글 전체를 관통하는 발견입니다. 패널을 가격 모델별로 나눠 보면 사용량 기반 기업의 NRR 중앙값은 108%로, 좌석 기반 기업의 98%보다 10포인트 앞섭니다(Aleph × Benchmarkit).
| 가격 모델 | NRR 중앙값 (CY-2025) | 100% 손익분기선 대비 |
|---|---|---|
| 사용량 기반 | 108% | 8포인트 위 |
| 전체 기업 | 102% | 2포인트 위 |
| 좌석 기반 | 98% | 2포인트 아래 |
Aleph × Benchmarkit, 2026 SaaS & AI Performance Benchmarks, NRR 응답 기업 n=230. 100% 선 아래로 내려가면 신규 고객 없이는 기존 고객 기반이 줄어듭니다.
이 98%라는 숫자를 한번 곱씹어 보세요. 중앙값에 해당하는 좌석 기반 SaaS 기업은 자기 기반만으로는 손익분기점에도 못 미칩니다. 내일 당장 신규 고객 확보를 멈추면 매출이 줄어든다는 뜻입니다. 다들 "고객이 우리를 얼마나 좋아하는가"를 나타내는 점수로 취급하는 이 지표에서, 무엇을 만들었는지보다 어떻게 요금을 매기는지가 더 중요합니다. NRR이 90%대 후반에서 정체돼 있다면, 고객이 성장할 때 함께 커지는 요소가 요금제 안에 있는지 자문해 보세요.
매출총유지율(GRR)
**매출총유지율(GRR)**은 NRR에서 확장분을 제외한 지표로, 축소와 이탈만 반영하며 각 고객의 시작 매출을 하한선으로 둡니다. 중앙값은 88%에서 84%로, 75번째 백분위수는 95%에서 91%로 하락했습니다(Aleph × Benchmarkit, CY-2025).
공식: GRR = (starting MRR − contraction − churn) ÷ starting MRR. 100%를 초과할 수 없습니다.
NRR은 확장 뒤에 이탈을 숨길 수 있지만 GRR은 그럴 수 없습니다. NRR 105%에 GRR 84%인 기업은 고객을 유지하고 있는 게 아니라, 남아 있는 고객에게 열심히 더 팔고 있는 것입니다.
로고 유지율과 고객 이탈률
로고 유지율은 금액이 아니라 고객 수를 세기 때문에, 이탈이 소형 계정이나 대형 계정 어느 한쪽에 몰릴 때마다 GRR과 다른 값을 보입니다. 저희는 2026년판 1차 보고서에서 로고 이탈률 중앙값을 추적할 수 없었기 때문에, 수치를 싣지 않았습니다.
그래도 한 가지는 말씀드리겠습니다. "연간 이탈률 5~7%면 건강한 편"이라는 말은 2019년 시절의 속설이며, 상위 10위 안에 드는 한 경쟁 사이트는 출처도 없이 지금도 이 말을 그대로 싣고 있습니다. ACV 구간을 명시하지 않으면 이 수치는 아무 의미가 없습니다.
당신의 SaaS는 정말 효율적인가? CAC 회수 기간, 번 배수, 직원 1인당 ARR
CAC 회수 기간
CAC 회수 기간은 고객 획득 비용을 매출총이익률로 조정한 매출로 회수하는 데 걸리는 개월 수입니다. CY-2025 중앙값은 16개월로 2024년의 18개월에서 개선됐습니다. 상위 25%는 6개월 이하에 회수하고, 하위 25%는 24개월 이상 걸립니다(Aleph × Benchmarkit, n=198).
공식: CAC payback = CAC ÷ (new MRR × gross margin).
Aleph의 주장처럼 CAC 회수 기간이 LTV:CAC를 대체해 주요 효율성 지표가 되어야 한다는 말은 단순한 산수 측면에서 옳습니다. 회수 기간은 당신이 실제로 아는 두 숫자를 쓰지만, LTV:CAC는 세 가지 추정치를 곱합니다. 같은 패널에서 매직 넘버 중앙값은 1.37, 즉 영업·마케팅(S&M) $1당 신규 ARR $1.37로 보고됩니다. 그 안을 더 쪼개 보면 차이가 더 뚜렷합니다. 신규 ARR $1을 만드는 데 신규 고객은 $1.63이 드는 반면 확장은 $0.80이면 됩니다(Aleph × Benchmarkit, NRR benchmarks). 확장이 절반 가격인 셈입니다.
번 배수(Burn multiple)
번 배수는 데이비드 삭스가 직접 고안한 개념으로, 순소진(net burn)을 순신규 ARR로 나눈 값입니다. 즉 반복 매출 1달러를 만드는 데 몇 달러를 소진하는지를 뜻합니다. 그의 2021년 기준으로는 1 미만이면 훌륭하고, 2 미만이어도 여전히 꽤 좋은 편입니다.
여기서 솔직하게 빈틈을 인정하겠습니다. 저희가 추적할 수 있는 2026년판 보고서 중 번 배수 분포를 발표한 곳은 하나도 없어서, 임의로 지어내지 않았습니다. 누군가 최근 번 배수 중앙값을 언급한다면, 어느 보고서인지, 어느 데이터 연도인지, 표본 크기(n)는 얼마인지 물어보세요. 자본 효율성은 이 카테고리에서 가장 많이 언급되면서도 가장 출처가 부실한 영역입니다.
직원 1인당 ARR
직원 1인당 ARR은 연간반복매출을 정규직 인원수로 나눈 값이며, 2025년에 가장 크게 움직인 지표입니다. 중앙값은 $193K로 $150K에서 29% 상승했고, 상위 25%는 약 $279K, 하위 25%는 $126K입니다(Aleph × Benchmarkit, n=96). 사용량 기반 기업이 $291K로 선두를 달립니다.
1년 만에 29% 상승한 것은 생산성이 기적적으로 좋아졌다는 뜻이 아니라, 상당 부분 채용 동결의 결과입니다. 이 비율을 움직이는 건 결국 툴링입니다. 소규모 팀이 몸집을 작게 유지하기 위해 쓰는 도구와 사람을 채용하는 대신 업무를 자동화하는 방법 모두 이 비율에 반영됩니다. 50% 이상 성장하는 기업은 직원 1인당 $235K를 기록한 반면, 31~50% 성장 구간은 $136K에 그쳤습니다.
성장 품질: 성장률, 매출총이익률, 그리고 Rule of 40
성장률
$3–20M ARR 구간의 부트스트랩 B2B SaaS 기업의 전년 대비 성장률 중앙값은 20%에서 15%로 떨어진 반면, NRR은 103%, GRR은 91%로 유지됐습니다(SaaS Capital, 2026 Benchmarking Metrics for Bootstrapped SaaS Companies, n>1,000). 90번째 백분위수 역시 51%에서 42.3%로 떨어졌습니다.
| 전년 대비 성장률, $3-20M ARR | 이전 연도 | CY-2025 | 변화 |
|---|---|---|---|
| 중앙값 | 20% | 15% | 5포인트 하락 |
| 90번째 백분위수 | 51% | 42.3% | 8.7포인트 하락 |
SaaS Capital, 2026 Benchmarking Metrics for Bootstrapped SaaS Companies, 비상장 B2B SaaS n>1,000. 같은 기간 유지율은 변동이 없었으며, 이는 둔화의 원인이 이탈이 아니라 고객 획득에 있음을 보여줍니다.
성장률은 떨어졌습니다. 유지율은 그러지 않았습니다. 즉 둔화는 고객 획득의 문제이고, 대부분의 이사회는 엉뚱한 곳을 가리키고 있는 셈입니다.
매출총이익률
소프트웨어 매출총이익률 중앙값은 **80%**이고, 상위 25%는 86% 이상, 하위 25%는 50%이며, 전체 매출을 합산한 혼합 이익률은 76%입니다(Aleph × Benchmarkit, n=228–232).
다들 AI 추론 비용이 SaaS 이익률을 갉아먹고 있으리라 예상합니다. 하지만 이 보고서는 이익률 압박을 발견하지 못했습니다. 소프트웨어 매출총이익률은 벤치마크 데이터 4개년 내내 79~81%를 유지했습니다. 보고서 자체의 조언은 지금부터 AI 비용을 계측하라는 것이며, 그 시작은 제품 안에서 LLM 추론이 토큰당 실제로 얼마나 드는지 파악하는 일입니다.
Rule of 40
Rule of 40은 성장률과 이익률을 합쳐 40을 넘어야 한다는 원칙입니다. CY-2025 중앙값은 15%에서 25%로 상승했고, 상위 25%는 **43%**에 도달했습니다(Aleph × Benchmarkit). 공식: growth % + FCF or EBITDA margin % ≥ 40.
여기서 가격 정책 이야기가 매듭지어집니다. 구독과 사용량을 결합한 하이브리드 모델이 43%라는 그 수치로 패널을 선도합니다. 다만 중앙값 상승이 무엇을 뜻하는지는 짚고 넘어가야 합니다. 기업들은 성장이 아니라 비용 절감으로 40에 가까워졌습니다. 시험을 통과하는 방법 중 가장 개운치 않은 방식입니다.
이 벤치마크는 ARR 구간별로 달라지는가?
네, 상당히 달라지며, 바로 이 지점에서 단일 숫자로 뭉뚱그린 가이드들이 가장 크게 무너집니다. NRR은 ARR $5M 미만 구간의 94%부터 $100M 이상 구간의 103%까지 폭넓게 분포하며, 직원 1인당 ARR은 최상위 구간이 아니라 중간 구간에서 정점을 찍습니다.
| 지표 (USD) | $5M 미만 ARR | $3–20M ARR (부트스트랩) | $20–50M ARR | $100M+ ARR |
|---|---|---|---|---|
| 순매출유지율 | 94% | 103% | 101% | 103% |
| 매출총유지율 | n/a | 91% | n/a | n/a |
| 전년 대비 성장률 | n/a | 15% | n/a | n/a |
| 직원 1인당 ARR | n/a | n/a | $282K | $206K |
| 소프트웨어 매출총이익률 | 72% | n/a | n/a | $50–100M 구간 86% |
행별 출처: NRR, 직원 1인당 ARR, 매출총이익률은 Aleph × Benchmarkit 2026(CY-2025) 기준이고, GRR과 성장률은 SaaS Capital 2026(n>1,000) 기준입니다. n/a는 해당 구간을 발표한 1차 출처가 없다는 뜻입니다. 자신의 열을 읽어 보세요. ARR $8M에 성장률 15%, NRR 103%라면 정확히 평균입니다.
왜 당신의 MRR 대시보드는 손익계산서(P&L)와 어긋나는가
위의 공식들은 쉬운 부분입니다. 실제 결제 데이터를 대상으로 정확하게 계산하는 일은 그렇지 않으며, 이 검색 결과에 등장하는 모든 가이드가 이 부분을 건너뜁니다.
정의 자체가 아직 확정되지 않았다는 것부터 공개된 근거로 보여드리겠습니다. 바로 이 문제를 표준화하기 위해 존재하는 기관인 SaaS Metrics Standards Board는 이 논쟁이 여전히 진행 중이라고 기록합니다. "NRR 계산에서 약정(commitment) 수준을 초과하는 사용량 기반 가격 매출(초과분)을 포함할지에 대해서는 논쟁이 있다." 다만 계산 방식에 대해서는 확실히 정리하고 있습니다. "코호트 방식이 NRR을 측정하는 가장 정확한 방법이며, 대부분의 상황에서 선호되는 접근법이다." Aleph는 가장 흔한 단일 오류를 직접 지목합니다. "가장 흔한 오류는 신규 고객 매출이 확장 항목으로 새어 들어가게 두는 것이다." Aleph의 표현을 빌리면 이는 NRR을 부풀리고 유지율 문제를 숨깁니다(Aleph × Benchmarkit).
따라서 자신의 NRR을 벤치마크 중앙값과 비교하려면 두 수치가 같은 방식으로 계산됐다는 전제가 필요한데, 표준화 기구조차 실제로는 그렇지 않을 가능성이 크다고 말합니다. 다음은 저희 Techsy가 이 지표를 계측할 때 방어 설계하는 다섯 가지 실패 유형입니다. 설문조사 결과가 아니라 실제 엔지니어링 실무 기준으로 정리했습니다.
- 신규 고객 매출이 확장 항목으로 새어 들어가는 경우. 쿼리가 고객 코호트를 고정하지 않고 날짜 범위만으로 필터링하면, 신규 고객이 들어올 때마다 유지율이 부풀려집니다.
- 축소와 이탈이 하나의 항목으로 뭉뚱그려지는 경우. GRR을 구하려면 이 둘을 분리해야 하며, 한 번 합쳐지면 재실행 없이는 다시 나눌 수 없습니다.
- ARR이 청구 시스템과 대시보드에서 서로 다른 시점에 스냅샷되는 경우. 예를 들어 주기 중간의 업그레이드가 한 시스템에서는 계약 전체 금액으로, 다른 시스템에서는 일할 계산으로 기록되면 절대 맞아떨어지지 않습니다.
- 월간 계약과 연간 계약이 서로 다른 방식으로 정규화되는 경우. 한 시스템은 연간 금액을 12로 나누고, 다른 시스템은 청구서 발행일 기준으로 인식합니다. 둘 다 나름의 근거는 있지만, 두 방식을 동시에 쓰는 것은 정당화될 수 없습니다.
- 코호트 창이 눈에 띄지 않게 이동하는 경우. 주로 연체(dunning) 상태를 활성(active)으로 집계하기 때문에 발생합니다. Stripe의
past_due는active가 아닌데, 단순한status != 'canceled'필터는 이를 활성 상태처럼 취급합니다.
이 다섯 가지 문제를 모두 해결하는 방법은 코호트 방식입니다. 특정 월을 정하고, 그달에 활성 상태였던 정확한 고객 목록을 고정한 뒤, 1년 뒤 그 동일한 고객들이 얼마를 지불하는지 물어보는 것입니다. 신규 고객은 필터가 아니라 구조 자체로 제외됩니다. 다음은 월간 MRR 스냅샷 테이블을 대상으로 한 PostgreSQL 16 버전입니다.
-- 확장, 축소, 이탈을 분리한 코호트 기준 NRR과 GRR.
-- 코호트는 기준월(anchor month)에 고정되므로 신규 고객이 들어올 수 없다.
WITH anchor AS (
SELECT customer_id, SUM(mrr_cents) AS start_mrr
FROM mrr_monthly
WHERE month = DATE '2025-06-01'
AND status = 'active' -- past_due와 unpaid는 active가 아니다
GROUP BY customer_id
),
later AS (
SELECT customer_id, SUM(mrr_cents) AS end_mrr
FROM mrr_monthly
WHERE month = DATE '2026-06-01'
AND status = 'active'
GROUP BY customer_id
),
movement AS (
SELECT
a.start_mrr,
COALESCE(l.end_mrr, 0) AS end_mrr,
GREATEST(COALESCE(l.end_mrr, 0) - a.start_mrr, 0) AS expansion,
CASE WHEN COALESCE(l.end_mrr, 0) = 0
THEN a.start_mrr ELSE 0 END AS churned,
CASE WHEN COALESCE(l.end_mrr, 0) BETWEEN 1 AND a.start_mrr
THEN a.start_mrr - l.end_mrr ELSE 0 END AS contraction
FROM anchor a
LEFT JOIN later l USING (customer_id) -- LEFT JOIN으로 이탈 계정도 유지
)
SELECT
SUM(start_mrr) AS start_mrr,
SUM(expansion) AS expansion,
SUM(contraction) AS contraction,
SUM(churned) AS churned,
ROUND(100.0 * SUM(end_mrr) / SUM(start_mrr), 1) AS nrr_pct,
ROUND(100.0 * (SUM(start_mrr) - SUM(contraction) - SUM(churned))
/ SUM(start_mrr), 1) AS grr_pct
FROM movement;단순한 MRR 합산으로는 얻을 수 없는 두 가지가 있습니다. LEFT JOIN은 0으로 떨어진 고객도 남겨 두므로, 이탈이 비율의 양쪽에서 조용히 사라지지 않고 제대로 집계됩니다. 그리고 각 이동 요소가 별도 컬럼으로 나오기 때문에, NRR과 GRR이 서로 어긋나는 두 개의 쿼리가 아니라 동일한 수치에서 도출됩니다.
그다음으로 해야 할 일은 지루하지만 꼭 필요한 산출물, 즉 지표별로 기록 시스템, 정확한 필터, 인식 시점 규칙, 통화 규칙을 명시한 한 페이지짜리 지표 정의 문서를 작성하는 것입니다. 어긋남은 대개 CRM 필드와 결제 필드가 둘 다 'MRR'이라 불리는데 어느 쪽이 우선인지 아무도 문서화하지 않았을 때 시작됩니다. 이는 저희가 SaaS 제품을 구축할 때 사용하는 AI 스택 위에서, 커스텀 HubSpot API 통합이 해결해야 하는 문제이기도 합니다.
어떤 SaaS 지표를 그만 추적해야 할까?
여섯 개 지표는 대시보드 공간만 차지할 뿐 아무것도 돌려주지 않습니다. 잘라내세요. 경쟁 가이드들은 우선순위도 없이 15개에서 38개까지 지표를 나열하는데, 38개는 대시보드가 아니라 서류 캐비닛입니다.
- 성장 지표로서의 NPS. CX 신호로는 괜찮습니다. 하지만 NRR은 NPS가 감성으로만 암시하는 것을 달러 단위로 측정하며, 위에서 인용한 2026년 벤치마크 보고서 중 NPS 수치를 발표한 곳은 하나도 없습니다.
- 단순 가입자 수(Raw signups). 의도만 셀 뿐 가치는 세지 못합니다. 출시 직후 스파이크와 봇 팜(bot-farm) 스파이크가 이 차트에서는 똑같아 보입니다.
- 누적 가입자 수(Total registered users). 계속 오르기만 하는 누적 수치는 지표가 아니라 트로피입니다. 자신이 줄어들고 있다는 사실을 알려주지 못합니다.
- 페이지뷰. 마케팅 인풋이지 비즈니스 아웃풋이 아닙니다. NRR 옆이 아니라 마케팅 보고서에 있어야 합니다.
- 유료 여부로 구분하지 않은 MAU/DAU. 무료 티어 활동과 유료 활동이 섞이면 대응할 수 없는 이유로 움직이는 숫자가 나옵니다. 나누거나 아예 빼세요.
- 단독 수치로서의 LTV. 여기가 가장 강하게 말씀드리고 싶은 부분입니다. LTV는 세 가지 추정치(ARPA, 매출총이익률, 이탈률)를 하나의 그럴듯해 보이는 수치로 압축하는데, 이탈률의 작은 오차만으로도 이 값이 크게 흔들립니다. 대신 CAC 회수 기간을 쓰세요. 실제로 관측 가능한 두 숫자니까요.
2021년 SaaS 지표 플레이북 이후 무엇이 바뀌었나?
데이비드 삭스와 이선 루비가 2021년 10월에 쓴 에세이는 바로 이 표현의 원조 문서이며, 그럴 만한 자격이 있습니다. 여섯 카테고리로 구성된 프레임워크는 이 분야에서 가장 명료한 정리 방식이고, 번 배수를 대중화한 것도 이 글입니다. 데이비드 스코크의 "SaaS Metrics 2.0"도 또 다른 정전(正典)급 참고 자료로 나란히 자리합니다.
문제는 프레임워크 자체가 아닙니다. 임계값이 2021년 자본시장에 맞춰 보정됐다는 점, 그리고 두 글 어디에도 2026년 독자에게 그 사실을 알려주는 대목이 없다는 점이 문제입니다. 이 기준에 자신을 견주는 창업자는 사실 중앙값에 있으면서도 실패하고 있다고 결론 내리게 됩니다.
- NRR: 2021년 시절 "건강하다"는 기준선은 110% 이상이었습니다. CY-2025 상위 25%는 108%로 계속 낮아지고 있으니, 110%는 이제 기준선이 아니라 상위 25%보다도 높은 값입니다.
- CAC 회수 기간: 예전 목표는 12개월이었습니다. CY-2025 중앙값은 16개월이고, 6개월을 넘기지 않는 곳은 상위 25%뿐입니다.
- 성장률: 제로금리(ZIRP) 시절 ARR $20M 미만 부트스트랩 기업의 기본값은 30% 이상이었습니다. CY-2025 중앙값은 15%입니다.
2021년 플레이북이 틀린 것은 아닙니다. 더 이상 존재하지 않는 자본시장에 맞춰 보정돼 있을 뿐입니다.
저자 소개
Mert Batur Gurbuz는 Techsy.io의 공동 창업자이며, 그의 팀은 B2B 고객을 위해 AI 에이전트, 자동화 시스템, 그리고 바로 이런 수치를 만들어내는 결제 인프라를 직접 구축합니다. 그는 금융 애널리스트가 아니라 대시보드를 직접 계측하는 팀을 이끄는 사람이며, 그래서 위의 정합성(reconciliation) 섹션이 저희가 1차 경험으로 말할 수 있는 부분입니다. 이력: 공동 창업자, Techsy.io, University of Birmingham. LinkedIn.
자주 묻는 질문
가장 중요한 SaaS 지표는 무엇인가요?
순매출유지율(NRR)입니다. 격차도 크지 않습니다. NRR은 이탈, 축소, 확장을 하나의 숫자로 함께 담아내는 유일한 지표이며, 신규 영업 없이도 사업이 복리로 성장할지를 예측합니다. CY-2025 중앙값은 102%입니다(Aleph × Benchmarkit, 2026년판, n=230). 확장이 이탈을 가리지 못하도록 GRR과 함께 보세요.
2026년 SaaS의 좋은 NRR 기준은 무엇인가요?
102%를 넘으면 중앙값을 넘어선 것이며, 상위 25% 구간은 오히려 상승이 아니라 계속 낮아지고 있습니다(Aleph × Benchmarkit, n=230, CY-2025). 가격 모델의 영향이 매우 큽니다. 사용량 기반 기업은 NRR 중앙값 108%를 기록한 반면 좌석 기반은 98%입니다. 전체 평균이 아니라 자신의 가격 모델을 기준으로 판단하세요.
SaaS에서 Rule of 40이란 무엇인가요?
성장률과 이익률을 합쳐 최소 40 이상이어야 한다는 원칙입니다. 성장률 30%에 잉여현금흐름(FCF) 마진 10%인 기업이면 정확히 이 기준을 통과합니다. CY-2025 중앙값은 15%에서 25%로 올랐고, 상위 25%는 43%에 이릅니다(Aleph × Benchmarkit). 이 상승분 대부분은 성장이 아니라 비용 절감에서 나왔습니다.
좋은 CAC 회수 기간 기준은 무엇인가요?
CY-2025 중앙값은 16개월로, 전년의 18개월보다 개선됐습니다. 상위 25% 기업은 6개월 이하에 획득 비용을 회수하고, 하위 25%는 24개월 이상 걸립니다(Aleph × Benchmarkit, n=198). 50% 이상 성장하는 기업은 평균 10개월입니다.
SaaS 지표는 몇 개나 추적해야 하나요?
아홉 개이며, 유지율·효율성·성장 품질로 나뉩니다. 더 많다고 좋은 게 아니라 오히려 나빠집니다. 38개짜리 지표 대시보드는 우선순위가 없어서 아무도 들여다보지 않고 어떤 숫자도 담당자가 없게 됩니다. 아홉 개를 골라 각각 담당자와 문서화된 정의를 부여하고, 정해진 주기로 검토하세요.
VC들은 실제로 어떤 SaaS 지표를 보나요?
성장률, 순매출유지율, CAC 회수 기간, 번 배수 순으로 대략 이 순서이며, Rule of 40은 밸류에이션을 걸러내는 기준으로 씁니다. 투자자들은 2021년보다 자본 효율성에 더 큰 비중을 두고 있으며, 그래서 대부분의 실사(due diligence) 대화에서 번 배수와 CAC 회수 기간이 LTV:CAC를 밀어내고 있습니다.
어떤 SaaS 지표가 허영 지표(vanity metric)인가요?
단순 가입자 수, 누적 가입자 수, 페이지뷰, 유·무료를 구분하지 않은 MAU/DAU, 성장 예측 지표로 쓰인 NPS, 그리고 단독으로 인용된 LTV입니다. 이들은 각각 계속 오르기만 하거나, 무료와 유료 활동을 섞어 버리거나, 여러 추정치를 하나의 그럴듯해 보이지만 실행 불가능한 숫자로 압축한다는 공통점이 있습니다.
NRR과 GRR의 차이는 무엇인가요?
NRR은 확장 매출을 포함하며 100%를 넘을 수 있지만, GRR은 확장을 제외하므로 절대 100%를 넘지 못합니다. NRR 105%에 GRR 84%인 사업은 고객을 잃고 있으면서 남은 고객에게 업셀링을 해서 이를 메우고 있는 것입니다. CY-2025 중앙값은 각각 102%와 84%입니다(Aleph × Benchmarkit).
왜 제 MRR 대시보드는 회계 시스템과 맞지 않나요?
보통 다섯 가지 기계적 원인 중 하나입니다. 신규 고객 매출이 확장 항목으로 새어 들어가거나, 축소와 이탈이 하나로 합쳐지거나, 청구 시스템과 대시보드가 ARR을 서로 다른 시점에 스냅샷하거나, 월간·연간 계약이 다르게 정규화되거나, 연체 상태를 활성으로 집계하는 경우입니다. 정의 문서를 하나로 통일하고 기록 시스템을 하나로 정하세요.
짧게 요약하면
세 가지입니다. NRR 중앙값은 102%, GRR 중앙값은 84%로 둘 다 하락했습니다. 즉 모두에게 조용히 유지율이 어려워지고 있다는 뜻입니다(Aleph × Benchmarkit, n=230, CY-2025). 사용량 기반 가격 정책은 NRR에서 좌석 기반보다 10포인트 앞서는데, 이는 계약 구조가 단순한 가격 결정이 아니라 유지율 결정이라는 뜻입니다. 그리고 부트스트랩 기업의 성장률은 20%에서 15%로 떨어졌지만 유지율은 변동이 없었으니, 둔화는 고객 획득 쪽에 있습니다(SaaS Capital, n>1,000).
그리고 확장 전에 챙겨야 할 목록의 나머지 절반도 있습니다. 규모를 키우기 전에 제대로 해둬야 할 것들입니다. 숫자와 손익계산서가 서로 어긋난다면, 그건 해법이 이미 알려진 배관(plumbing) 문제일 뿐입니다. 직접 디버깅하고 싶지 않다면 문의해 주세요.