OSP

Google Cloud Compute Engine / Function / Run 가격 정책(2026.07)

OSP — Thu, 2 Jul 2026 03:28:08 +0900

Google Cloud Compute Engine / Function/Run 가격 정책(2026.07)

Google Cloud 상품 개관

통신 기술을 이용한 서비스의 경우 현실적으로 서버를 둘 수밖에 없다. 인터넷 규범상 방문 판매는 사실상 막혀있고, 영업 주소지(서버)를 두어야 함이다.
2026.02.03 - [DEVELOPMENT] - 서버리스 P2P통신(Serverless Peer to Peer Communication)의 한계
클라우드 상품은 규모의 경제를 이용한 온프레미스 위탁 서비스로 요약되는데, 그 중 서버 계열 상품은ComputeEngine, Cloud Run, Cloud Function이 있으며 스펙별 시간당 요금제를 채택한다.

상품	요구사항		요약(주요 비유/용례)
Google Cloud Storage	용량 크고 사용빈도 낮음		외장 인터넷 하드(창고)
Google Cloud Firebase Firestore	용량 적지 않고 사용빈도도 됨	비관계형 DB	외장 인터넷 DB(검증/기록)
Supabase	용량 적지 않고 사용빈도도 됨	관계형 DB	외장 인터넷 DB(검증/기록)
Google Cloud Compute Engine	용량 적고 사용빈도 높은 편 *인터넷 통신의 보안 정책상 중요 클라이언트의 진입점인 서버가 됨		외장 인터넷 VM(레스토랑)
Google Cloud Run			외장 인터넷 VM(푸드트럭)
Firebase Cloud Functions			외장 인터넷 VM(파견요리사)

Compute Engine

요금제 및 특징 : 대여시간당 과금

워크로드에 따른 최적화 유형 > 스펙별 단위 요금제로 구성된다.

https://cloud.google.com/products/compute/pricing

머신 유형	워크로드	요금 범위
범용 머신	아묻따 가성비	시간당 0.05 - 20 USD
컴퓨팅 최적화 머신	고성능 컴퓨팅	시간당 0.07 - 10 USD
메모리 최적화 머신	메모리 집약	시간당 2 - 80 USD
가속기 최적화 머신	대규모 병렬 컴퓨팅	시간당 2 - 90 USD
스토리지 최적화 머신	코어 < 스토리지	시간당 2 - 30 USD
네트워크 최적화 머신	I/O 집약	시간당 0.15 - 20 USD

추상화된 하드웨어 자원(서버)을 대여하는 개념이라 요금제 산정이 단순하다.

특징

Cloud Run

요금제 및 특징 : 대여시간당 또는 사용량당 과금

설정한 컨테이너(인스턴스)의 CPU/메모리 용량과 사용 시간에 따라 과금된다.
https://cloud.google.com/run/pricing
인스턴스 기반 결제와 요청 기반 결제, 작업 기반 결제로 나뉜다
- 인스턴스 : 인스턴스라는 서버의 작은 구획을 기간제로 대여하는 요금제. 손님 유무에 무관하게 스펙*대여기간만큼 돈을 계속 지불한다.서버를 직접 관리해야 하고, 24시간 대기하므로 응답 속도가 빠르다.
- ★요청 : 손님의 요청이 있을 때만 인스턴스를 잠시 대여하고 이후 반납하는 요금제. 손님이 없을 때는 비용이 들지 않는다. 서버 관리를 구글이 담당하고, 응답은 Cloud Run이 컨테이너 빌드-실행하는 시간만큼 지연될 수 있다(Cold Start, 0.5 ~ 3초 범위). Cloud Run의디폴트 유형으로, 최소 인스턴스를 0으로 두어 요청이 없을 때는 요금이 부과되지 않게 함이 일반적이다.
- 작업 : 운영자의 요청이 있을 때만 인스턴스를 잠시 대여하고 이후 반납하는 요금제. 위와 같다.
구체적인 요금 도표는 아래와 같다.

요금 유형	CPU 요금(/vCPU)	메모리 요금(/GiB)	요청 요금	약정 할인
인스턴스	0.000018 USD / sec	0.000002 USD / sec	-	17 - 46%
요청	0.000024 USD / sec	0.0000025 USD / sec	0.4 USD / 1M 건	17%
작업	0.000018 USD / sec	0.000002 USD / sec	-	17 - 46%

유료 기능 검증/기록 용도로 요청 기반 요금제를 사용하는 예시를 살피자. 1vCPU, 1GiB만큼의 스펙을 두고 넉넉하게 하루에 1인당 3번, 매 번 10초씩 인스턴스를 사용한다고 가정하면 (0.000024 + 0.0000025)*(3*10*30) + (0.4 / 1000000)*(3*30) = 한 사람당 한 달에 0.023886$꼴이다.
DB케이스는 순수한 유료 사용자들이 모수가 되었지만, 서버 진입점은 무/유료 사용자 모두에게 개방되기 때문에 상대적으로 리스크가 있는 편이다. 그러나 24시간 한달 내내 이용해도 70$ 정도로, 절대적인 상한은 그리 심각하지 않다. 참고로 Compute Engine에서는 비슷한 스펙을 24시간 내내 돌리면 한 달에 30$ 정도로 예상된다.

서버를 하위 자원(CPU, 메모리)으로 잘게 쪼개 대여하는 개념이라 요금 산정이 조금 까다롭다.
- 앱 환경을 통쨰로 담은 컨테이너 단위로 컴퓨팅 엔진에 배포한다. 컨테이너 기술에 대한 이해가 약간 필요하지만 자유도가 높다.

Cloud Function

요금제 및 특징 : 대여시간당 또는 사용량당 과금

요금제의 전반적인 기틀은 Cloud Run과 같다.
https://firebase.google.com/pricing

요금 구분	요금
CPU 요금	Run과 같음 무료 범위는 약간 여유로움
메모리 요금
요청 요금
네트워크 아웃바운드 요금	0.12 USD / GB
클라우드 빌드 요금	0.003 USD / min

서버를 Clouid Run보다 더 잘게 쪼개 대여하는 개념이다.
- 함수 조각 단위로 컴퓨팅 엔진에 배포한다. 매우 단순하고, 자유도가 거의 없다. 아주 작은 독립 작업에 괜찮다.

비교 및 요약

클라우드 서비스	요금제 타입		비고
Cloud Compute Engine	대여 기간 만큼		규모의 경제
Cloud Run	대여 기간 만큼	실제로 사용한 만큼	앱 단위 프로토타입 배포
Cloud Function	실제로 사용한 만큼		기능 단위 프로토타입 배포

유료 검증/기록 용도로 사용하는 경우 무료 사용자에게도 개방적인 진입점이어서 비용 리스크 있으나, 절대적인 상한이 크지 않은 편.

AI API 가격 정책(2026.06) 및 적정 마진/용량

OSP — Mon, 29 Jun 2026 22:10:35 +0900

AI API 가격 정책(2026.06) 및 적정 마진/용량

STT/LLM
- 더보기
  - STT
    
    Speech To Text. 음성데이터을 텍스트로 치환하는 기능이다. 기술 원리적으로는 통계분류기구로, AI의 일종에 속한다.
  - LLM
    
    Large Language Model. 현재까지의 언어를(질문) 기반으로 다음 언어(답변) 예측/제공하는 통계 분류기구로, 현대의 AI는 대부분 이를 지칭한다.
  - LLM은 독자적으로도 사용할 수요가 많지만, STT는 LLM과 접목해야 표적 서비스 완성도에 큰 영향을 준다.

요금정책

STT : 분당 요금제

요금제 산정 방식이 명확하고 직관적이다.
Google Cloud STT
- https://cloud.google.com/speech-to-text/pricing
- 1분당 0.016$, 한달 총 사용량에 따라 0.004$/분 까지 떨어진다.
Open AI
- https://developers.openai.com/api/docs/pricing
- 모델에 따라 가격이 상이하며, 사용량에 따른 가격 절감은 없다. gpt-4o (0.006$/min), gpt-4o-mini (0.003$/min), Wisper (0.006$/min)

모델	특징	가격(USD/min)	시간(/USD)
Google Cloud STT	고품질	0.016 - 0.004	1시간 - 4시간
Open AI gpt-4o-transcribe	위스퍼+	0.006	3시간 -
Open AI gpt-40-mini-transcribe	가성비 품질	0.003	5시간 +
Open AI Whisper	표준 품질	0.006	3시간 -

LLM : 1M 토큰당 요금제

요금제 산정 기준이 토큰으로 추상화되어있다. LLM 내부적인 인식/출력 단위로 추정한다. 영어 기준으로는 단어당 1토큰(철자가 길면 2토큰), 한국어라면 글자당 1-2토큰으로 추산된다.

표준(Standard)/일괄(Batch)/유연(Flex)/우선(Priority)의 특징은 아래와 같으며, 이 다음부터는 표준을 기준으로 서술한다.

표준(Standard)	일괄(Batch)	유연(Flex)	우선(Priority)
실시간 처리형	일괄 처리형(~24시간)	표준+일괄(1~15분)	지연/실패 극소
기본 요금	50% 요금	50% 요금	200% 요금
일반적인 서비스	마이그레이션	백그라운드 비동기	결제 시스템 등

Open AI Chat GPT
- https://developers.openai.com/api/docs/pricing
- LLM 클래식 전통강자. AI 그 자체였는데, 언젠가부터 AI중 하나로 그 위상이 추락한 모습.
- 가성비 nano, 대중적 mini, 향상 (-), 초고급(pro)로 구분한다. 이 4 선택지는 행동과학적으로 난해하다. 뭐가 주력상품인지도 모르겠고, 일반적인 효용과 작명간의 미스매치도 눈에 띈다.
Google Gemini
- https://ai.google.dev/gemini-api/docs/pricing
- 언젠가부터 Ghat GPT와 어깨를 나란히 하는 신흥강자.
- 가성비 Flash-Lite, 밸런스 Flash, 고급 Pro로 구분한다. 형식상 구글의 넛지 의도는 분명한데, 여기는 균형 제품과 고급 제품의 실질적인 가격 차이가 가성비-균형 제품에 비해 크지 않다는 특징이 있다. 가격대에 따라 Open AI 제품군에 대응시키자면 각각 가성비, 향상, 초고급에 대응된다. 즉 대중적 mini 모델에 대응되는 제품이 없다.
요약
- 요금 기준으로는 가성비/고급/고급+로 나뉘고, 현실적인 밸런스 제품은 GPT-mini Only
표준 요금제 도표는 아래에서 살핀다.

모델	특징	가격(USD/1M Token)
모델	특징	입력 요금	출력 요금
Gemini 3.1 Flash-Lite	단순 추론, 가장 비용 효율적 모델	0.25, 0.50(오디오)	1.50
Gemini 3.5 Flash	구글 표준 상품, 범용적 밸런스 모델	1.5.	9.00
Gemini 2.5 Pro	고급 추론, STEM 분야 최첨단 모델	1.25 - 2.50	10.00 - 15.00
Gemini 2.5 Flash-Lite	3.1 Flash-Lite 이전 바용 효율 모델	0.10, 0.30(오디오)	0.40
Gemini 2.5 Flash	3 Flash 이전 밸런스 모델	0.30, 1.00(오디오)	2.50
Gemini 3 Flash Preveiw	3.5 Flash 이전 밸런스 모델	0.50, 1.00(오디오)	3.00
Gemini 3.1 Pro Preview	2.5 Pro 최신형	2.00 - 4.00	12.00 - 18.00
GPT-5.4 nano	초소형 모델.,극한의 단순 자동화 처리	0.20	1.25
GPT-5.4 mini	가성비 모델, 범용적인 파이프라인	0.75	4.50
GPT-5.4	표준 모델, 고성능 추론 위주	2.50	15.00
GPT-5.4 Pro	최상위 모델, STEM 분야 고정밀 모델	30.00	180.00
GPT-5.5	GPT-5.4 최신형	5.00	30.00
GPT-5.5 Pro	GPT-5.5 Pro	30.00	180.00

문맥 캐시값(Context Caching/Cached iunput)은 입력 요금의 10% 수준이다.
- 예를 들어서 현재 질문과 맥락이 이어지는 이전 질문/답변이 각각 1500토큰/1000토큰 2000토큰/1500토큰이었고 현재 질문이 2000토큰이라면, 2번쨰 질문 요금은 2000토큰*입력요금 + (1500+1000)토큰*(입력요금/10)이, 현재 질문 요금은 2000토큰*입력요금 + (1500+1000+2000+1500)토큰*(입력요금/10)이 된다.
- 일반적으로 시스템 프롬프트가 가장 큰 비중일 차지함을 고려하면, 매 질문에 "맥락 5회 누적마다 1질문 비용"이 추가로 부과되는 셈이다.

★구독료와 적정 용량 추산

0. 모델별 단위 토큰 사용량 및 가격, 1$당 호출 횟수

입력 : 서비스에 따라 시스템 프롬프트 포함 1500 토큰 가정, 가격표의 0.0015배
- Context 비용은 관련 대화 10개당 2입력 꼴이다.
출력 : 구조화된 출력 데이터 1000 토큰 가정, 가격표의 0.001배

모델	가격(USD/1 Turn)			Turn/USD
모델	입력 요금	출력 요금	합산 요금	호출 횟수
Gemini 3.1 Flash-Lite	0.000375, 0.00075(오디오)	0.0015	0.002	500
Gemini 3.5 Flash	0.00225	0.0090	0.01125	88
Gemini 2.5 Pro	0.001875 - 0.00375	0.010 - 0.015	0.0153	65
Gemini 2.5 Flash-Lite	0.00015, 0.00045(오디오)	0.0004	0.0007	1428
Gemini 2.5 Flash	0.00045, 0.0015(오디오)	0.00250	0.003475	287회
Gemini 3 Flash Preview	0.00075, 0.0015(오디오)	0.00300	0.004125	242회
Gemini 3.1 Pro Preview	0.003 - 0.006	0.012 - 0.018	0.0195	51회
GPT-5.4 nano	0.0003	0.00125	0.00155	645회
GPT-5.4 mini	0.001125	0.00450	0.005625	177회
GPT-5.4	0.00375	0.015	0.01875	53회
GPT-5.4 Pro	0.045	0.18	0.225	4회
GPT-5.5	0.0075	0.03	0.0375	26회
GPT-5.5 Pro	0.045	0.18	0.225	4회

1. 무료 사용자의 사용량 한도

2026.06.23 - [DEVELOPMENT/SUUROUNDINGS] - 수익성 핵심지표 : 리텐션(Retention)
리텐션 5% 확보를 위한 한계 감수비용은 구독료의 0.5%정도로, 구독료 1$당 0.005$가 된다. 상술한 요금 표를 구독료 1$당 무료 제공 한도로 바꾸면 다음과 같다.

3.1 Flash-Lite	3.5 Flash	2.5 Pro	2.5 Flash-Lite	2.5 Flash	3.1Pro
2.5회	0.4회	0.3회	7회	1.6회	0.2회
5.4 nano	5.4 mini	5.4	5.4 Pro	5.5	5.5 Pro
3.2회	0.8회	0.2회	0.2회	0.1회	0.02회

2. 유료 사용자의 사용량 한도

상술한 표에서 0.1$당 호출 횟수를 분리하면 다음과 같은데, 구독료*비용률로 나온 값의 대입하면 적정 사용량을 계산할 수 있다. 예를 들어 구독료 5$에 AI 비용률을 10%로 잡으면 0.5$이므로, 5.4mini는 18*5 = 90회 호출할 수 있다.
3.1 Flash-Lite 3.5 Flash 2.5 Flash-Lite 2.5 Flash

50회 9회 143회 33회

GPT-5.4 nano GPT-5.4 mini GPT-5.4 GPT-5.5

65회 18회 5회 3회

비용 절감 전략
더보기
- STT
  1. ★공백 제거(VAD, Voice Activity Detection)
    
    필수적이다. 침묵, 긴 호흡, 대기시간, "음..." 등의 불필요한 음성 데이터만 줄여도 10~40%정도의 시간 절약을 기대할 수 있고, 이는 그대로 비용절감이 된다.
    
    전반적으로 당연한, 합리적인 전처리로 인식된다.
  2. 재생 배속
    
    1.25 - 1.5배속 정도는 꽤 잘 인식하는 편이라고 한다. 20 ~ 30 %정도의 비용 절감을 기대할 수 있다. 일상적인 발언을 학습하기 때문에 일상적인 발화 속도여야 한다. STT가 랩을 잘 변환한다고 랩의 발화 속도인 일상적인 발화 속도의 2배~3배속으로 하는 비용 절감은 곤란하다. 음절 속도가 동일해도 발음 차이로 음절 경계가 달라지기 때문이다.
    
    이와 관련한 Google/OpenAI측 금지사항은 확인할 수 없다. 정확도는 보장할 수 없다.
- LLM
  1. 시스템 프롬프트 최소화
    
    사용자의 입력을 내가 제한하는 것은 부담스럽고, 시스템 프롬프트는 최적화 함이 필요하다. 줄인 만큼 요금에 그대로 반영된다. 다만 그럼에도 출력요금이 더 비싸긴 하다.
  2. 출력 길이 제한
    
    출력의 단위 요금이 꽤 비싸다. 시스템 프롬프트에 출력의 길이를 제한하는 것은, 생각처럼 크지 않은 UX 손해를 대가로 비용을 절감할 수 있다.
  3. 모델 단계화
    
    저렴한 모델을 기본값으로 쓰고, 저렴한 모델이 "어렵다" 판단한 경우에만 고급 모델을 호출하는 것이다. 입력 비용이 배가 되지만, 출력 비용의 이점이 전체적인 비용 절감을 가져올 수 있다. 어려운 질문이 대부분인 서비르마녀 입력 비용만 추가로 부담하는 셈이 된다.

요약
- 더보기
  - 1$당 STT 시간 : 3시간-
  - 모델에 따른 1$당 LLM 호출 횟수 축약
    
    초가성비 모델 일반 모델 고급 모델 초고급 모델(GPT Only)
    
    500회+ 100회 50회 4회

Firestore, CloudSQL, Supabase 가격 정책(2026.07) 및 적정 마진/용량

OSP — Sun, 28 Jun 2026 01:39:35 +0900

Firestore, CloudSQL, Supabase 가격 정책(2026.07) 및 적정 마진/용량

클라우드 상품 특징은 아래와 같다.

상품	요구사항		요약(주요 용례)
Google Cloud Storage	용량 크고 사용빈도 낮음		외장 인터넷 하드(창고)
Google Cloud Firebase Firestore	용량 적지 않고 사용빈도도 됨	비관계형 DB(문서)	외장 인터넷 DB
Google Cloud SQL		관계형 DB(스키마)
Supabase		관계형 DB(스키마)
Google Cloud Compute Engine	용량 적고 사용빈도 큰 편		외장 인터넷 CPU(현장인력)

Firestore : (https://cloud.google.com/firestore/pricing, https://cloud.google.com/firestore/enterprise/pricing)

요금제(종량제) : 저장용량당 저장료 + 작업횟수당 작업료 + 용량댱 네트워크 요금

요금제는 Standard / Enterprise로 나뉜다.고급쿼리지원 및 MongoDB 호환성에 차이가 있다.

종류	요금 (/month)
종류	기본 모델	1년약정 20%할인모델	3년약정 40% 학인모델
저장된 데이터	0.15 $ / Gib 0.24 $ / Gib
읽기	0.03 $ / 100000 doc 0.05 $ / 1000000 count	0.024 $ / 100000 doc 0.04 $ / 1000000 count	0.018 $ / 100000 doc 0.03 $ / 1000000 count
쓰기	0.09 $ / 100000 doc 0.26 $ / 1000000 count	0.072 $ / 100000 doc 0.208 $ / 1000000 count	0.054 $ / 100000 doc 0.156 $ / 1000000 count
삭제	0.01 $ / 100000 doc 0.26 $ / 1000000 count	0.008 $ / 100000 doc 0.208 $ / 1000000 count	0.006 $ / 100000 doc 0.156 $ / 1000000 count
네트워크	0.15 ~ 0.23 $/GiB	-

외장 DB는 유료 크레딧 사용량, 결제 로그 등을 검증/기록하는 용도로 많이 쓰이고, 이러한 경우 결제 또는 유료 기능을 사용시에 접근하기 때문에 저장 용량과 작업 횟수가 크지 않다. 넉넉잡아 한명당 1MB 문서, 하루에 한 번씩 읽고 쓴다고 하면 작업료 (0.00015 + 0.000036 + 0.00018 ~ 0.000366$ /월이 된다. 무료 할당량까지 고려하면 매우 저렴한 편,
- 구글 클라우드 스토리지 대비 산술적인 저장료는 10배,, 작업료는 10%정도 수준이다.

특징 : 서버리스DB, 확장성, 동시성 문제, 구글
더보기
- 서버리스 DB
  - 호출할 때만 컴퓨팅 리소스를 잠시 빌려서 사용한다. 따라서 서버를 24시간 대기시키는 유지 비용이 없다. 저장/읽기/쓰기/전송에 따라 실제로 사용하는 컴퓨팅 리소스에 맞추어 요금을 지불한다.
- 비관계형 DB : noSQL
  - 관계형 DB의 강력한 JOIN기능을 통해서 데이터를 엮을 수 없음. 태그/라벨 같은 N:M 유형의 관계형 데이터 구조를 다루는 서비스에 적합하지 않다. 불가능한 것은 아니지만 관계형 DB를 재발명하는 꼴이 되기 때문. 1:1의 정직, 단순, 심플한 데이터 구조에서 강력하다.
- 엄격한 스키마가 없음
  - 문서와 컬렉션이라는 JSON 유사 트리 구조로 데이터를 저장하며, 엄격한 스키마가 없기 때문에 문서마다 다른 필드를 가질 수 있어 필드 확장이 용이하다. 대신 데이터 구조의 일관성은 보장받지 못한다.
  - 복잡한 쿼리를 처리하려는 경우 데이터 구조화에 따라 noSQL 조회 기능의 구현 난이도 편차가 매우 크다. 세부 필드 조회 혹은 필드 값에 따른 조건부 조회를 구현하기 어렵다.
- 트랜잭선 구현상 주의 필요
  - 낙관적 동시성 제어 (Optimistic Concurrency Control) : 여러 사람이 동시에 같은 문서를 수정1할 때 먼저 끝낸 사람의 것을 반영하고 나중에 시도한 사람의 것은 실패시키고, 이후에 재시도된다. 그러나 단시간에 몰리면 에러를 뱉는다.
  - 반대로 말하면, 동시성 제어가 문제되지 않는 빈도로 사용되는 경우에는 큰 문제가 되지 않는다는 뜻이다.
- Google의 온프레미스 인프라 안정성 및 공급 업체 종속성
  - 물리적인 장소와 하드웨어 장비, 관리 인력 및 서비스 유지보수를 Google이 대신 해준다. 그러나 여러 차원에서 구글에 종속된다. Firestore에 정보가 쌓인 상태에서 구글의 가격정책이 급등하거나 구글 자체가 휘청이는 경우, 마이그레이션 리스크가 존재한다.
- 통합 환경
  - Firestore는 Firebase의 일 서비스로, 사용자 인증(Firebase Authentication), 백엔드 프레임워크(Cloud functions), 푸시알림(Cloud Messaging) 를 다루는 통합 환경에 속한다.

CloudSQL (https://cloud.google.com/sql/pricing)

요금제(대여료 + 종량제) : 머신 대여료 + 저장 용량당 저장료 + 작업용량량 네트워크 요금

요금제는 인스턴스 유형에 따라 오픈소스(MySql/PostgreSQL), 라이선스(SQL Server : MSSQL)로 나뉘며, 그 다음은 스펙 + 저장용량 + 작업용량 기반으로 과금된다. 구체적인 도표는 아래와 같다.

비용 구분	비용
머신 비용	범용	N4	N2	C4A
CPU USD/mon	30.149	30.149	39.201	39.42
메모리 USD / 1GiB*mon	5.11	5.11	6.643	6.57
인스턴스 비용 USD / month	micro		small
	7.665		25.55
스토리지 비용 USD / 1GiB*mon	SSD	HDD(오픈소스)	백업
	0.17	0.09	0.08
네트워크 비용 USD / 1GiB	인바운드		아웃바운드
	Free		0.12
라이선스 비용 USD / 코어시간	Express	웹	Standard	Enterprise
	0	0.01134	0.13	0.47
머신 비용은 통째로 빌리 경우, 인스턴스 비용은 쪼개 놓은 추상화 머신 패키지로 빌리는 경우 적용된다. 인스턴스는 토이 프로젝트나 프로토 타입의 비용 절감을 위한 과금 체계로, micro가 그 존재 의의라고 할 수 있다. 머신 과금에는 약정 할인이 있으며(인스턴스는 없다), HA 머신/스토리지는 2배 가격이다.

서버형 DB 특성상 계속 켜놓어야 하기 때문에 가장 싼 micro 요금제로 최소 월 8$ 정도이고, 사용량에 따라 요금이 추가로 부과된다. 온프레미스 대신 제3자의 클라우드를 빌려 쓰는 핵심은 규모의 경제 대신의 단기적인 비용 혜택인데, 그 이점을 제대로 살리지는 못한 요금제로 이해된다. 실제 청구서는 몇만원 수준이라 절대적인 가격이 비싸다고 말할 수는 없지만, 실험적/소형 프로젝트에 지불하기에는 시장 수요가 어떻게 될지도 모르는데 고정비용만 감당하기란 꺼려지기 마련이다.
- 가격 슬라이드를 그려보자면 규모의 경제 - 단기적인 비용 우위의 중간재 쯤인데, 안타깝게도 지위가 불안한 중간재에 속하는 것으로 보인다.
- 아래에서 살펴보겠지만, 최소한의 비용을 부담하는 대신 구글의 안정성과 관계형 DB의 장점을 모두 얻는 형국이어서 괜찮은 선택지는 맞다. micro로 하면 비용도 얼마 안 되고.

특징 : 서버DB, 구조성/확장 난이도, 구글/오픈소스
더보기
- 대기형 서버 DB
  - 기본적으로 서버를 통째로 빌리는 개념이기 때문에 아무도 접속하지 않아도 24시간 내내 비용이 계속 부과된다. 평소에 꺼놓고 호출할 때만 키는 요금 절감 방법은 CloudSQL의 On/Off에 몇 분의 로딩이 걸리기 때문에 현실적으로 불가능하다.
- 관계형 DB : SQL
  - N:M 유형의 데이터 구조를 조직하고 쿼리를 처리함에 있어 매우 강력하다. 얽히고 섥히기 좋은 데이터 구조에서 유리하다.
- 엄격한 스키마 존재
  - 스키마 불합치 발생이 크래시를 유발한다. 필드 확장은 용이하지 않으나, 전체적으로 동일한 포맷을 강제하는 강력한 규범 덕분에 데이터 구조의 일관성이 보장된다.
  - 복잡한 쿼리를 처리하려는 경우에도 엄격한 스키마와 JOIN 덕분에 매우 간단하다. 세부 필드 조회 혹은 필드 값에 따른 조건부 조회를 구현하기 간단하디.
- 강력한 트랜잭션
  - SQL의 트랜잭션 안정성 덕분에 데이터 정합성이 강하게 보장된다.
- Google의 온프레미스 인프라 안정성 및 공급 업체 종속성 및 오픈소스 개방성으로 완화
  - 물리적인 장소와 하드웨어 장비, 관리 인력 및 서비스 유지보수를 Google이 대신 해준다. 그러나 여러 차원에서 구글에 종속된다. Firestore에 정보가 쌓인 상태에서 구글의 가격정책이 급등하거나 구글 자체가 휘청이는 경우, 마이그레이션 리스크가 존재한다.
  - 오픈소스 관계형 DB 관리 시스템인 Postgres에 기반을 두어 특정 공급업체에 종속되지 않는다. 공급 업체의 가격 정책 변경이나 재무 위기 상황이라도, 경쟁 업체로 인한 마이그레이션 리스크 완화가 기대된다.
- 통합 환경
  - 과거에는 CloudSQL과 Firebase는 완전 별개의 서비스였으나 현재는 하나의 통합환경 Firebase에 강하게 통합되어 있다.

Supabase (https://supabase.com/pricing)

요금제(구독 + 초과 종량제) : 저장용량당 저장료 + 작업용량당 작업료

종류	요금
종류	Free	Pro		Team
구독료	-	기본 25$ / month 프로젝트당 + 10$ / month		기본 599$ / month 프로젝트당 + 10$ / month
프로젝트당 데이터	~ 500 MB	~ 8GB	이후 0.125 $ / GB	Pro와 동일
총 데이터	~ 1GB	~ 100 GB	이후 0.0213 $ / GB
MAU	~ 50000 명	~ 100000 명	이후 0.00325 $ / MA
네트워크 Egress	~ 5 GB	~ 250GB	이후 ~0.09 $ / GB

Firebase와 비슷한 사용량 기준으로 Pro요금제에서 한 명당 (0.000125 + 0.0000213 + 0.00025 + 0.00009) = 0.0004863$인 셈으로, 산술적으로는 Firebase보다 30%가량 비싸다고 할 수 있다.

특징 : 서버리스DB, 구조성/확장 난이도, 오픈소스
더보기
- 서버리스 DB
  - 호출할 때만 컴퓨팅 리소스를 잠시 빌려서 사용한다. 따라서 서버를 24시간 대기시키는 유지 비용이 없다. 저장/읽기/쓰기로 쓴 만큼만 요금을 지불한다.
- 관계형 DB : SQL
  - N:M 유형의 데이터 구조를 조직하고 쿼리를 처리함에 있어 매우 강력하다. 얽히고 섥히기 좋은 데이터 구조에서 유리하다.
- 엄격한 스키마 존재
  - 스키마 불합치 발생이 크래시를 유발한다. 필드 확장은 용이하지 않으나, 전체적으로 동일한 포맷을 강제하는 강력한 규범 덕분에 데이터 구조의 일관성이 보장된다.
  - 복잡한 쿼리를 처리하려는 경우에도 엄격한 스키마와 JOIN 덕분에 매우 간단하다. 세부 필드 조회 혹은 필드 값에 따른 조건부 조회를 구현하기 간단하디.
- 강력한 트랜잭션
  - SQL의 트랜잭션 안정성 덕분에 데이터 정합성이 강하게 보장된다.
- 공급업체 비종속성
  - 오픈소스 관계형 DB 관리 시스템인 Postgres에 기반을 두어 특정 공급업체에 종속되지 않는다. 공급 업체의 가격 정책 변경이나 재무 위기 상황이라도, 경쟁 업체로 인한 마이그레이션 리스크 완화가 기대된다.
- 통합 환경
  - 인증, 스토리지, 백엔드 프레임워크 등을 빠르게 개발할 수 있는 통합 환경이다.

비교
- 더보기
  - 비용 문제
    
    검증/기록 구현에 사용하려는 경우 검증/기록에 외부 DB를 사용하는 것은 로 컬 디바이스 내부 검증/기록만으로 부족한 경우인데, 보통 유료 기능에 대한 검증/기록에 이용된다. 유료 기능에 대한 보완책으로써 접근하면 모두 절대적인 비용 자체가 상당히 저렴한 편이라 비용 우열은 생략한다. 유료 사용자를 모수로 두고 0.002$ / 명이면, 무시해도 될 것으로 보인다.
    
    엔드포인트 단말 연결에 사용되는 경우 : 기기간 데이터 동기화, 메신저 등의 경우에 해당한다. 이 경우는 서비스 특성상 무료 사용자에게도 제공됨이 흔하다. 다만 대부분이 텍스트 자료를 임시 저장하는 형태로 일방의 수신으로 DB에서 삭제하므로 마찬가지로 비용이 저렴하다. 문제라면 모수가 전체 사용자라는 것인데, 네트워크 효과를 기대하는 바이럴 마케팅 비용으로 생각하면 부담스러운 가격은 아니다.
    
    최소 부담 비용 : 우선 DB 자체가 비싼 요금이라고 말하기는 어렵다. 사용량이 엄청 많아져야 수십만원, 주변에서 재벌 소리 들을 정도여야 수백-수천만원으로, 그 트래픽이 가져오는 수익성으로 커버를 하고도 남는 것이 일반적이다. 그러나 문제는 비용과 수익성이 큰 경우는 경제적으로 클라우드 대신 온프레미스가 선택지로 떠오르기 때문에, 클라우드의 주된 수요처는 소규모 프로젝트라는 것이다. 즉 돈 없는 개발자들의 실험적 수요를 받쳐주어야 하는 것인데, 서버형 DB는 이런 수요에 적절하게 설계되었다고 받아들여지지 않는다. 실질적으로 쓰이지도 않고 있고 앞으로도 쓰일지 아닐지 모르는 서비스를 위해 돈은 계속 지불하라니. 비록 몇만원이지만 선뜻 지갑이 열리지는 않는다.
  - 환경적 트레이드오프 : 구글에 올라 타느냐, 기술에 올라 타느냐 하는 문제로 치환된다. 역사적으로 문맥이 유지되는 것은 기술이지만, 보통 그것을 손에 쥐는 것이 기업이라 쉽지 않은 문제다. CloudSQL은 일방 의존성을 제거하여 구글의 안정성 + 오픈소스의 개방성 모두 기대할 수 있다. 다만 상술했듯 최소 요금이 존재한다. 마치 두 토끼를 모두 잡는 대신 돈을 지불하라 라는 의도된 설계처럼 들리지만, Goolge Cloud에 시초를 두었던 만큼 Cloud 제품군의 레거시 요금 정책에 영향을 많이 받았을 뿐인 것으로 추측한다. 그리고 이러한 레거시 요금 정책이 쫓아내는 수요를 캐치하고 나온 게 Supabase다.
  - 기술적 트레이드 오프
    
    정합성/동시성 제어 문제 : 이 역시 큰 화두가 되지 못한다. 1인이 단시간에 다수 결제 혹은 다수 유료기능 사용하는 상황은 너무 엣지 케이스다.
    
    4. 확장성/구조화 문제 : 이들을 분리하는 가장 주요한 지점이라 생각한다.
    
    Firebase : "A의 유료 결제 및 유료 기능 크레딧 사용 기록" 정도로 넓게 조회하고 구체적으로는 직접 열어서 확인하는 레거시 로깅 타입. 다각적인 데이터 분석이 어렵다.
    
    CloudSQL 또는 Supabase : "A의 x일 이후 유료 기능 사용 일자 및 크레딧", 또는 "A와 B의 잔여 크레딧이 같은 날짜" 수준의 구조적 조회가 필요한 경우 적절하다. 다각적인 데이터 분석에 수월하다.
  - 요약
    
    Firebase : 레거시DB로 족하다.
    
    Supabase : 관계형 DB를 최소 비용 없이 쓰고 싶다.
    
    CloudSQL : 관계형 DB를 글로벌 공룡 기업 걸로 쓰고 싶다.

요약

	Firebase	CloudSQL	Supabase
데이터 구조	직렬적 1:1	병렬적 N : M	병렬적 N : M
기술 트레이드오프 및 특징 NoSQL / SQL	쉬운 확장성	강한 정합성	강한 정합성
기술 트레이드오프 및 특징 NoSQL / SQL	정합성 문제	어려운 확장	어려운 확장
비용 트레이드오프 및 특징 서버형 / 서버리스	최소 비용 0	최소 비용 부담	최소 비용 0
비용 트레이드오프 및 특징 서버형 / 서버리스	유효 비용 증가	유효 비용 감소	유효 비용 증가
환경 트레이드오프 및 특징 구글 / 오픈소스	구글의 안정성(+)	구글의 안정성 (+)	오픈소스 개방성 (+)
환경 트레이드오프 및 특징 구글 / 오픈소스	구글 종속성(-)	오픈소스 개방성 (+)	상대적 불안정성 (-)
적정 용레	단순한 레거시 로깅 DB진입/쿼리 단순	구조적 데이터 DB진입/쿼리 구조적	구조적 데이터 DB진입/쿼리 구조적
적정 용레	비용회피 but 구글 의존 + 레거시 DB	비용 부담 but 병목 의존 제거 + 관계형 DB	비용 회피 but 기술 의존 + 관계형 DB

Google Cloud Storage가격 정책(2026.06) 및 적정 마진/용량

OSP — Fri, 26 Jun 2026 04:50:12 +0900

Google Cloud Storage 가격 정책(2026.06) 및 적정 마진/용량

클라우드 상품 특징은 아래와 같다.

상품	요구사항		요약(주요 용례)
Google Cloud Storage	용량 크고 사용빈도 낮음		외장 인터넷 하드(창고)
Google Cloud Firestore	용량 적지 않고 사용빈도도 됨	비관계형 DB(문서)	외장 인터넷 DB(검증/기록)
Supabase		관계형 DB(스키마)
Google Cloud Compute Engine	용량 적고 사용빈도 매우 큼		외장 인터넷 CPU(현장인력)

Coloud Storage : 외장 인터넷 저장매체 (https://cloud.google.com/storage/pricing)

1. 데이터 저장료(Data storage) : 저렴

데이터 저장 용량 종량제 : 어떤 리전의 어떤 스토리지 클래스에, 얼마나 많이 오래 보관하냐

가장 비싼 Standard 기준으로 100GiB 저장료가 한달에 3$정도로 매력적인 가격을 보인다(지역별 상이, Rapid 제외). 후술할 네트워크 사용료에서도 클라우드 인바운드는 무료로 책정하는데, 가격저항을 낮추어 많은 데이터를 유치하려는 구글의 의도가 뚜렷하다.

리전	스토리지 클래스	*요금 : $ / (gibibyte month)**
Single-Region (Seoul)	Standard	0.023
	Nearline	0.016
	Coldline	0.006
	Archive	0.0025
	Rapid Cache	0.120012
Dual-region* (Taiwan)	Standard	0.022
	Nearline	0.011
	Coldline	0.0044
	Archive	0.0014
Muiti-region** (asia)	Standard	0.026
	Nearline	0.015
	Coldline	0.00875
	Archive	0.003
Zonal (Singapore)	Rapid	0.11
gibiByte란 이진 연산으로 셈한 용령 단위로, 1gibiByte = 1GB+ 가 된다. 편의상 혼용한다. * 두 싱글 리전을 선택함으로써 진행하며, 이들의 요금이 각각 청구된다. 사전 정의된 듀얼 리전은 그 리전의 요금만 청구된다(싱글리전의 2배 요금) ** 리전을 선택/관리할 수 없고, 사전 정의된 멀티 리전의 요금만 청구된다.

리전	특징	과금 특징
요금 유형		저장료	처리비
싱글	단일 장애점, 값쌈 기준이 되는 기본 요건	-	-
듀얼	데이터 위치 통제와 단일 장애점 해소, 비쌈 비용을 감수하더라도 방어해야 하는 경우	근소하게 비싼 저장료 2중 부담	처리비 2중 부담 (복제)
멀티	Google 관리 하 단일 장애점 해소, 절충적임 단일 장애점만 간단하게 해결하고 싶은 경우	조금 더 비쌈	처리비 2중 부담 (복제)

백업 스토리지를 제공하는 경우를 생각해보자.
- 백업 스토리지긴 하지만 현실적으로 이는 지근거리의 백업이 대부분이다. 콜드라인/아카이브는 컨테이너/지하창고에 자물쇠 걸어 보관하는 수준의 백업이므로 적합하지 않다.서랍/캐비넷에 보관하는 수준의 백업으로는 스탠다드/니어라인이 적합하다. 스토리지 클래스별 권장 접근 주기는 월 1회 초과 / 월 1회 이하 / 분기 1회 이하 / 연 1회 이하이다.
- 리전에 대해서 살피면, 우선 민감 정보가 아닌 이상 듀얼은 배제하자. 싱글리전은 단일 장애점 문제를 감수하거나 직접 해결(백업리전 : 수동 듀얼리전)하는 것이고, 멀티리전은 이를 구글에게 맡기는 것이다. 수분- 가끔 수시간의 드문 리전 장애를 감수할 수 있으면 독고다이 싱글리전, 아니라면 백업리전 또는 멀티리전을 선택하면 될 것이다.
스토리지별 최소 보관 기간은 아래와 같으며, 조기 삭제시 잔여 기간 만큼 요금이 부과된다.
Standard Nearline Coldline Archive Rapid

None 30 Days 90 Days 365 Dyas None

구글 클라우드 프로젝트는 버킷이라는 단위로 자율적으로 소분할 수 있으며, 이 버킷에 부착하는 태그 하나당 월 0.005$가 부과된다. ~~티끌모아모아빔~~
- 구글 클라우드 스토리지 계층구조
  
  Storage Projcet Bucket* Folder File / Object

더보기
2. 데이터 처리비(Data processing) : 업도르/저장은 싼데 다운로드가 비쌈(싱글리전 기준)

운영비(Operation charges) : 어떤 리전/버킷의 어떤 스토리지에, 어떤 작업을 요청하냐

버킷 소속 리전	스토리지 클래스	작업 클래스	요금 : $ / 1000건
Single-region	Standard	클래스A 연산, 플렛 NS	0.005
		클래스A 연산, 계층 NS	0.0065
		클래스B 연산 플랫 NS	0.0004
		클래스B 연산, 계층 NS	0.0005
	Nearline	클래스A 연산, 플렛 NS	0.01
		클래스A 연산, 계층 NS	0.013
		클래스B 연산 플랫 NS	0.001
		클래스B 연산, 계층 NS	0.0013
	Coldline	클래스A 연산, 플렛 NS	0.02
		클래스A 연산, 계층 NS	0.026
		클래스B 연산 플랫 NS	0.01
		클래스B 연산, 계층 NS	0.013
	Archive	클래스A 연산, 플렛 NS	0.05
		클래스A 연산, 계층 NS	0.065
		클래스B 연산 플랫 NS	0.05
		클래스B 연산, 계층 NS	0.065
	Rapid Cache	-	Free
Dual-region Multi-region	Standard	클래스A 연산, 플렛 NS	0.01
		클래스A 연산, 계층 NS	0.013
		클래스B 연산 플랫 NS	0.0004
		클래스B 연산, 계층 NS	0.0005
	Nearline	클래스A 연산, 플렛 NS	0.02
		클래스A 연산, 계층 NS	0.026
		클래스B 연산 플랫 NS	0.001
		클래스B 연산, 계층 NS	0.0013
	Coldline	클래스A 연산, 플렛 NS	0.04
		클래스A 연산, 계층 NS	0.052
		클래스B 연산 플랫 NS	0.01
		클래스B 연산, 계층 NS	0.013
	Archive	클래스A 연산, 플렛 NS	0.10
		클래스A 연산, 계층 NS	0.13
		클래스B 연산 플랫 NS	0.05
		클래스B 연산, 계층 NS	0.065
Zonal	Rapid	클래스A 연산, 계층 NS	0.00113
		클래스B 연산, 계층 NS	0.0002
		클래스C 연산, 계층 NS	0.000625
		클래스D 연산, 계층 NS	0.00002
리전 / 스토리지 클래스로 계층적으로 분류했지만, 재고단위(SKU)는 평면적이다 https://cloud.google.com/skus?filter=autoclass&%3Bcurrency=USD

작업 클래스와 NameSpace, 메서드별 작업 클래스 구분은 다음과 같다

분류	내용	요약
Class A	업로드(PUT), 복사(COPY), 객체/폴더생성, 목록조회(LIST) 등	인바운드, 비쌈
Class B	다운로드(GET), 메타데이터 조회, 존재 여부 확인	아웃바운드, 쌈
플랫 NS	전통적인 평면적 저장 방식	비구조적, 저렴
계층 NS	폴대 개념을 추가한 계층적 저장 방식	구조적, 비쌈

클래스 A : 입력	클래스 B : 조회/다운로드	무료 : 삭제
★ storage.insert	★ storage.get	storage.bucket.delete
★ storage.patch	storage.getIamPolicy	storage.objects.delete
★ storage.update	storage.testIamPermissions	storage.folders.delete
storage.setIamPolicy	storage.AccessControls.list
storage.buckets.list
storage.objects.copy
storage.objects.list
storage.objects.copy
storage.objects.move
storage.objects.rewrite
storage.AccessControls.delete
PUT / POST	Get Object / HEAD	DELETE
1 태그 탈/부착	1 버켓의 태그 리스트 확인

검색비용(Retrival fees) : 어떤스토리지를 얼마나 읽기/복사/이동/재작성 하냐
- Nearline/Coldline/Archive 스토리지를 A클래스 작업(읽기/이동) 및 B클래스 작업(복사/재작성)이 호출된 경우 독립적으로 용량에 따라 과금된다. 네트워크요금은 별도이다.
- Standard Nearline Coldline Archive Rapid
  
  0$ 0.01$/gibiByte 0.02$/gibiByte 0.05$/gibiByte 0$

리전간 복제비용(Inter-region replication) : 어디 리전에서 어디 리전으로 얼마나 복제하냐

https://docs.cloud.google.com/storage/docs/availability-durability
리전간 복제는 버킷의 토글 옵션으로, 옵션이 켜져있는 듀얼리전/멀티리전 버킷에서 A 클래스 작업이 호출된 경우 독립적으로 용량에 따라 과금된다.

지역	요금 ($/gibiByte)
복제유형	기본	*터보(이중리전버킷 Only)**
북미	0.02	0.04
유럽	0.02	0.04
아시아	0.08	0.11
오세아니아	0.08	0.12
* 리전간 중복성 공백을 최소화해 데이터 손실 및 서비스 중단의 위험을 최소화하는 서비스.

자동 클래스 요금(Autoclass charges) : 버킷별 스토리지 클래스 자동 관리

https://docs.cloud.google.com/storage/docs/autoclass
사용 빈도에 따라 Standrad 부터 Archive까지 스토리지 클래스를 자동으로 관리하며, 이에 수반되는 작업에 대한 운영비도 청구된다.(Standard 요금 청구)

부과 주기	금액
매월	버킷의 Object(File) 1000개당 0.0025$/월
클래스 전환시	Cold > Standard / Near Archive > Standard / Near	싱글/플랫 기준 0.0005$/1000건
	나머지	Free

★네트워크 비용(Network) : 필수적인 비용인데 제일 비싸다. 최적화 필수

구글 클라우드 내부 데이터 전송료(Data transfer within Google Cloud) : Cloud간 전송

Cloud Storage > Cloud Service 인바운드가 US-EA 동일 로케이션에서 발생하면 무료이며,(UA-EAST-A에서 US-EAST-B로, US-EAST1에서 US-EAST1로, EU에서 EU로), 그 외에는 아래의 과금표를 따른다($/GiB)

도달>	US	EU	ASIA	IDN	OC	ME	LATAM	AF
US	0.02	0.05	0.08	0.10	0.10	0.11	0.14	0.11
EU	0.05	0.02	0.08	0.10	0.10	0.11	0.14	0.11
ASIA	0.08	0.08	0.08	0.10	0.10	0.11	0.14	0.11
IDN	0.10	0.10	0.10	None	0.08	0.11	0.14	0.14
OC	0.10	0.10	0.10	0.08	0.0.8	0.11	0.14	0.14
ME	0.11	0.11	0.11	0.11	0.11	0.08	0.14	0.11
LATAM	0.14	0.14	0.14	0.14	0.14	0.14	0.14	0.14
AF	0.11	0.11	0.11	0.14	0.14	0.11	0.14	None

특수 네트워크 사용료(Specialty network services) : 전용회선 사용료

일반 네트워크 사용료(General network usage) : 대략 0.12$/GiB

Google Cloud ↔ 사용자간 네트워크 전송료

항목	*가격($ / 1GB month * 계정)**
용량 구간	0GiB - 10 TiB	10 TiB - 150 TiB	150TiB +
클라우드로 인바운드	Free
아시아로 아웃바운드	0.12	0.11	0.08
중국으로 아웃바운드	0.23	0.22	0.20
호주로 인바운드	0.19	0.18	0.15
나머지로 아웃바운드	0.12	0.11	0.08

지능형 저장소 사용료(Storage Intelligence charges) : 스토리지 관리 AI
- 클래스 자동 관리가 자동 청소기이었다면, 이는 대시보드 분석기이다.
객체 컨텍스트(Object Contexts) : 오브젝트 레벨의 태그(key-value), 1000개당 0.003$ 티끌티끌
래피드 : 생략

용량과 작업 횟수에 따른 스토리지 클래스별 비용 양상

월간 요청횟수(x, 빨강축 : 회)과 저장용량(y, 초록축 : GiB)에 따른 비용 식과 그림은 다음과 같다. ratioA는 x중 A Class 작업의 비율이고 diffE는 평균전송비율, diffC는 평균복제비율이다.

싱글리전 케이스

		저장료	운영료	검색료	복제료	전송료
Standard	Class A	0.023$	0.005$	Free	None	Free
	ClassB		0.0004$			0.12
	가중평균	0.023y + (0.005ratioA + 0.0004(1-ratioA))(x/1000) + (1-ratioA)x0.12(diffEy)
Nearline	Class A	0.016	0.01	0.01	None	Free
	Class B		0.001			0.12
	가중평균	0.016y + (0.01ratioA + 0.001(1-ratioA))(x/1000) + (1-ratioA)x(0.12+0.01)(diffEy)
Coldline	Class A	0.006	0.02	0.02	None	Free
	Class B		0.01			0.12
	가중평균	0.006y + (0.02ratioA + 0.01(1-ratioA))(x/1000) + (1-ratioA)x(0.12+0.02)(diffE*y)
Archive	Class A	0.0025	0.05	0.05	None	Free
	Class B		0.05			0.12
	가중평균	0.0025y + (0.05ratioA + 0.05(1-ratioA))(x/1000) + (1-ratioA)x(0.12+0.05)(diffE*y)

아래에서는 스토리지 클래스별 비용 그래프로 호출 횟수(x, 빨강)과 스토리지 용량(y, 초록)에 따라 살핀다 : Standard(파랑), Nearline(빨강), Coldline(초록), Archive(노랑)
Figure1. diffE = 0.1인 경우 ratioA = 0.9(좌)와 1(우)의 비용 그래프. ratioA = 0.9에서는 낮은 x값에서(스토리지 비교군에 따라 B Class 작업1~8회 호출)에서 비용우열 역전이 발생한다. ratioA = 1에서는 네트워크 요금 때문에 솟아오른 비용이 털썩 주저앉아 평면처럼 되며, 저장료 우열대로 S<N<C<A의 원시적인 비욜 우열을 보인다.
Figure2.. ratioA = 0.9인 경우 diffE = 0.1(좌)와 0.2(우)의 비용 그래프. 비용. 낮은 x값에서 발생하는 비용 역전 범위가 줄어들고(Class B 작업 호출 횟수가 4회 미만) 전체적인 비용이 가파르게 상승한다.

듀얼/멀티리전 케이스 : 저장료는 싱글리전 2배, 복제비는 0.05로 단순화하였다

		저장료	운영료	검색료	복제료	전송료
Standard	Class A	0.046$	0.005$	Free	0.05	Free
	ClassB		0.0004$			0.12
	가중평균	0.046y + (0.005ratioA + 0.0004(1-ratioA))(x/1000) + 0.05ratioAxdiffCy + (1-ratioA)x(0.12diffEy)
Nearline	Class A	0.032	0.01	0.01	0.05	Free
	Class B		0.001			0.12
	가중평균	0.032y + (0.01ratioA + 0.001(1-ratioA))(x/1000) + 0.05ratioAxdiffCy + (1-ratioA)x(0.12+0.01)(diffEy)
Coldline	Class A	0.012	0.02	0.02	0.05	Free
	Class B		0.01			0.12
	가중평균	0.012y + (0.02ratioA + 0.01(1-ratioA))(x/1000) + 0.05ratioAxdiffCy + (1-ratioA)x(0.12+0.02)(diffE*y)
Archive	Class A	0.005	0.05	0.05	0.05	Free
	Class B		0.05			0.12
	가중평균	0.005y + (0.05ratioA + 0.05(1-ratioA))(x/1000) + 0.05ratioAxdiffCy + (1-ratioA)x(0.12+0.05)(diffE*y)

복제료는 선택적으로(토글) 지불하는 비용으로 단일 장애 문제에 대한 보험료이다.
아래에서 그래프로 살핀다. 비교를 위해 싱글리전 비용과 함께 나타내었다(각각 아래)
Figure3. diffE = diffC = 0.1인 경우 ratio = 0.9(좌)와 1(우)의 비용 그래프. 싱글리전과 달리 ratioA = 1인 경우에도 비용이 솟아있는데, A 클래스 작업에서 발생하는 복제비 때문이다.

축약하면 다음과 같다.

카테고리	비용 시나리오		핵심 비용 요소
업로드	저장료 * 운영료 + 복제료		복제료/저장료
다운로드	운영료 + 검색료 + 전송료		전송료
서비스 유형	싱글리전	업로드 위주	ratioA 의존
		다운로드 위주	전송료
	듀얼/멀티리전	업로드 위주	ratioA 및 복제 빈도 의존
		다운로드 위주	ratioA 및 복제 빈도 의존

싱글 리전, 업로드 위주 서비스에서 업로드 비용이 다운로드 비용의 10% 미만이 되기 위한 조건 : (저장료 * y) < 0.1 * (전송료 * diffE * y) * (1-ratioA) * x 을 살피면 다음과 같다.
- 일반적인 다운로드 케이스로 Standard, diffE = 1,. (1-ratioA)*x = 다운로드 수로 취급하면, 한 달에 다운로드 2회 이상부터 업로드 비용은 다운로드 비용의 10% 미만이 되며, 월 다운로드 4회 이상부터는 5% 미만이 되어 무시할 수 있게 된다.
- diff 등 저장/전송 비율을 크게 감축시킬 수 있다면 diffE = 0.1에서 각각 월 다운로드 20회, 40회 미만이 이에 해당한다.
- Figure4. diffE = 0.1(좌)와 1(우)의 다운로드 횟수에 따른 업로드비용/다운로드비용 그래프.

★구독료와 스토리지 적정 용량 추산

백업 서비스를 제공하는 경우를 생각해보자.(싱글리전)
1. 무료 사용자의 스토리지

리텐션 향상을 위한 한계 감수비용률은 아래와 같다.
2026.06.23 - [DEVELOPMENT/SUUROUNDINGS] - 수익성 핵심지표 : 리텐션(Retention)
Figure5. (리텐션, 비용률)에 따른 5% 전체리텬션 확대를 위한 한계 감수비용률 그래프.

한계 감수비용률을 10%로 추산하고 구독 전환률 0.025를 상수로 근사하면, 구독리텐션에 따른 매출공식에 따라 [0, 0.7]의 구독리텐션 범위에서 한계 감수비용은 구독료의 [0.0025, 0.008]배가 된다. 구독료 0.5%마다 추추가 리텐션 5%를 확보해야 한다는 의미이다. 구독료가 3000원이면 7.5-24원 구간으로, 대략 15원(0.01$)로 추산된다.

스토리지	비용 함수 (싱글리전)
Standard	S_{S}(x,y)=-costCeiling+0.023 y+(0.005 ratioA+0.0004 (1-ratioA))((x)/(1000))+(1-ratioA) x0.12 diffE y
Nearline	S_{N}(x,y)=-costCeiling+0.016 y+(0.01 ratioA+0.001 (1-ratioA))*((x)/(1000))+(1-ratioA) x (0.12+0.01) diffE y
Coldline	S_{C}(x,y)=-costCeiling+0.006 y+(0.02 ratioA+0.01 (1-ratioA))*((x)/(1000))+(1-ratioA) x (0.12+0.02) diffE y
Archive	S_{A}(x,y)=-costCeiling+0.0025 y+(0.05 ratioA+0.05 (1-ratioA))*((x)/(1000))+(1-ratioA) x (0.12+0.05) diffE y

이제 상술한 비용 그래프를 rationA = 0.9, diff = 0.1 사례를 z축으로 비용상한만큼 평행이동하면, z<=0인 부분(색이 없는 부분)이 무료 사용자에게 제공 가능한 범위라고 할 수 있다.
Figure6. 한계 감수비용 0.01$(좌), 0.02$(중), 0.04$(우)에 따른 비용곡면을 위에서 바라본 모습. 한계 감수비용이 증가함에 따라 무료 사용자에게 제공할 수 있는 범위(흰색)가 넓어진다
Figure7. 한계 감수비용 0.03$인 경우의 비용곡면. 500MB정도 제공하려면 한달에 30회 이하, 100MB면 한달에 150회 이하의 작업 호출 상한에서 이루어져야 한다.
더 세밀하게 Class A(업로드)와 Class B(다운로드)로 나누어 접근하면 다음과 같다.
1. Class A : raionA = 1, 한계감수비용 = 0.03, diff = 0.1
2. Figure8. rationA = 1인 경우의 비용 그래프. x축은 Class A 작업 호출 횟수가 된다. 1GB이하는 호출 횟수가 매우 널널하다. Class A와 Class B를 함께 묶어서 볼 것이 아니라, Class B의 횟수만 제한하는 것이 타당하다.
3. ★Class B : raionA = 0, 한계감수비용 = 0.03, diff = 0.1
4. Figure9. rationA = 0인 경우의 비용 그래프. x축은 Class B 작업 호출 횟수가 된다.

백업 서비스는 동기화 서비스와 달리 Class B(다운로드) 작업 수가 많지는 않을 것으로 예상된다. 주 1회 복원을 잡으면, 400MB까지 제공할 수 있음이다.
- 다만 해석상 유의점이 있다.
  1. 단일 장애점 문제를 감수하는 싱글 리전을 채택하였다. 이를 해소하기 위해 듀얼/멀티리전을 선택하는 경우 경우 50% 이하로 잡아야 할 것.
  2. 전송비율(diffE, diffC)이 상당히 중요하다. 이는 전송 최적화 수준으로 개발자 책임이 깊다. 사안에서는 0.1로 계산했는데, 스토리지 총 용량이 10GB라면 전송/복제 평균 용량을 1GB로까지 감축해냈다는 뜻이다. 복원에 매번 스토리지 전부를 끌어다 쓰면 diffE = 1이 된다.
동기화 서비스의 경우에도 클라우드 API 호출 양상은 달라지지 않기 때문에 본질적으로는 같다. 그러나 동기화는 Class B 호출 횟수가 상당히 늘어나기 때문에, 용량은 매우 작게 산정하여야 한다.
- 1분에 1회, 하루에 10시간동안 동기화하면 한 달에 18000회 호출되고, 용량 한도는 100kB가 된다. 동기화는 Firebase로 하자.

2. 유료 사용자의 스토리지

스토리지	비용 함수 (싱글리전)
Standard	S_{S2}(x,y)=S_{S}(x+OperationCount,y+Storage)((100)/(priceRatio))+ Fee((priceRatio)/(100))
Nearline	S_{N2}(x,y)=S_{N}(x+OperationCount,y+Storage)((100)/(priceRatio))+ Fee((priceRatio)/(100))
Coldline	S_{C2}(x,y)=S_{C}(x+OperationCount,y+Storage)((100)/(priceRatio))+ Fee((priceRatio)/(100))
Archive	S_{A2}(x,y)=S_{A}(x+OperationCount,y+Storage)((100)/(priceRatio))+ Fee((priceRatio)/(100))

1. 구독료를 잡아두고 적정 스토리지 용량을 계산하려면, 한계비용 = 구독료*(비용률/100) > 스토리지 요금을 만족하는 (작업 횟수, 스토리지 용량) 순서쌍을 확인하면 된다. Fee 2$/월, priceRatio 10%인 만큼 z축으로 평행이동한 그래프를 시각화하면 아래와 같다.
- Figure10. 한계비용 이하의 비용 곡면 하이앵글 구도. class B만 살피기 위해 ratioA = 0으로 계산하였다.
- 백업 서비스로 (2$, 10%)의 재무회계에서 주(1회,2회,3회) 복원을 잡으면 (3GB+, 1.5GB+, 1GB+), 저빈도 동기화로 월 1500회 잡으면 10MB, 고빈도 동기화로 월 18000회 잡으면 0.8MB한도가 된다. 상술한 해석상 유의점은 동일하다.
2. 스토리지 용량을 잡아두고 구독료를 계산하려면, y축으로 Storage만큼 평행이동한 비용곡면의 y=0 단면은 아래와 같다.
- Figure11. 한계 스토리지 용량 3GB(좌)와 1GB(GB)에서의 Class B 호출 횟수에 따른 적정 구독료 그래프 .
- Figure12. 한계 용량 5GB에서 Class B 호출 횟수에 따른 적정 구독료 그래프.
- 5GB 백업 서비스의 적정 구독료는 (주1회, 주2회, 주3회) 복원시 (3.5$, 6$, 8.5$)가 된다. 상술한 해석상 유의점은 동일하다.
3. 한달 Class B 호출 횟수를 잡아두고 구독료를 계산하면. x축으로 OperationCount만큼 평행이동한 비용 곡면의 x=0 단면은 다음과 같다.
1. Figure13. 한달 다운로드 5회(좌) 10회(우)인 용량 한도에 따른 적정 구독료 그래프.
2. 한달 (5회, 10회) 복원에 (2.5GB,1.5GB)가 용량 한도가 된다.

해석상 유의점은 상술한 바에 더해 Class B 요금 위주로 계산하였다는 것이다. 이것이 타당하기 위해서는 위해서는 Class A와 Class B의 비용 비중을 살펴야 하는데, 다운로드 비용이 업로드 비용에 비해 큰 범위일 것을 전제로 한다(Figure4 참조)
스토리지는 용량 종량제로 Place API처럼 매번 새로운 횟수가 제공되는 유형의 서비스가 아니기 때문에 변동계수 적용은 배제하였다.

비용절감전략
더보기
- 비활성 사용자에 대한 스토리지 클래스 변동
  - Standard > Nearline > Coldline > Archive 순서대로 저장료는 싸지만 접근 비용이 바싸게 책정되어 있다. 따라서 비활성 사용자에 대한 스토리지 클래스를 조절함으로써 저장료를 아낄 수 있을 것으로 기대된다.GCS에서 Autoclass를 제공한다.
  - 저장료 자체가 비싼 편이 아니라는 점과 구글측 수익성상 Autoclass의 최적화 수준에 대해서도 의문이 있는 점 등을 감안하면, 총 비용의 절감 효율을 크지 않을 것으로 예상된다. 다만 스토리지 전체 용량이 상당하다면 절대적인 액수는 무시하지 못할 것이다.
- 호출 횟수 제한
  - 비용의 핵심인 아웃바운드 비용의 상한을 호출 횟수로 제한하는 것이다. 다운로드 위주 서비스에서는 있을 수 없는 일이고 업로드 위주 서비스에서 네트워크 로딩 실패 에러 따위로 UX 저항을 완화함이 좋아 보인다.
  - UX를 고려하면 허용 리스크 범위를 감안하여 제한 수치를 넉넉히 산정함이 타당하다. 남용에 의한 왜곡을 예방할 수 있으나, 또라이 같은 악용자가 있지 않은 일반적인 케이스에서는 극적인 변화를 기대하긴 어렵다.
- ★전송/복제 효율 개선
  - 매 계산에서 사용된 diff가 이에 해당한다.원자성이 중요한 경우에는 있을 수 없는 일이지만, 단위별로 쪼개는 것이 가능한 경우에는 그 개선 효율이 상당하다.

요약
- 더보기
  - 싱글은 기본, 듀얼은 커스텀 정적 방패, 멀티는 구글 동적 방패
  - 유형 비용 시나리오 핵심 비용 요소
    
    업로드 저장료 + 운영료 + 복제료 복제료/저장료
    
    다운로드 운영료 + 검색료 + 전송료 전송료
    
    복제료와 전송료 최적화가 비용의 핵심 : 싱글리전만 복제료가 없다(단일 장애점)
  - Penny Service로는 어려운 편
    
    현대 디지털 경험상 용량 한도가 작아 긍정적인 결과를 장담하기 어려움

재무회계 : 매출과 비용률에 따른 순익(률)

OSP — Wed, 24 Jun 2026 15:56:59 +0900

매출과 비용률에 따른 순익(률)

매출(x, 천만원)과 비용률(y, %)에 따른 순익률(z)계산

1. 과세표준 : 편의상 스토어 수수료는 미리 차감하여 산정

모바일 앱 기준으로 고정 비용을 우선 산정하자.

플레이스토어/앱스토어 수수료(판매 금액의 15~30%)

https://support.google.com/googleplay/android-developer/answer/112622?
https://developer.apple.com/kr/app-store/small-business-program/
매출 100만달러(약 15억)까지는 15%, 그 이후 매출부터 30%의 누진 수수료가 있다

매출 (M$)	15% 부과금액(M$)	30% 부과금액(M$)	총 수수료$ (율%)
x (< 1)	0.15x	0	0.15x (15.0)
1.5	0.15	0.15	0.30M (20.0)
2	0.15	0.3	0.45M (22.5)
3	0.15	0.6	0.75M (25)
5	0.15	1.2	1.35M(27)
수수료	y = (0.225 + 0.075(\|x-1\|/(x-1)))x - (1 + (\|x-1\|/(x-1)))*0.075
수수료율	y = 0.225 + (\|x-1\|/(x-1))0.075 - (1 + (\|x-1\|/(x-1)))(0.075/x)

총 매출 당 수수료(M$, 좌측), 총 매출당 총 매출의 수수료 비중(%, 우측) : 30%에 수렴

부가가치세(판매 금액의 최대 9%)
- https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EB%B6%80%EA%B0%80%EA%B0%80%EC%B9%98%EC%84%B8%EB%B2%95/%EC%A0%9C30%EC%A1%B0
- 법령상 부가가치세는 10%이다. 구체적으로는 공급가액의 10%인데 이는 세수 확대를 위한 세법의 발전 과정 및 공급가액/공급대가의 구분 때문이고, 계산 편의상 소비자 결제금액(공급대가)를 기준으로 접근한다(정확히는 공급대가의 9%가 아니라 공급대가의 1/11 = 9.0909%이다)
  1. 판매 시점의 부가가치세(9%) : 순수 물건/서비스 가격을 공급가액이라 하는데, 부가가치세는 이 공급가액을 과세표준으로 10%를 징수한다. 둘을 더한 가격을 공급대가라 한다. 최종 판매금액을 만원으로 잡고 싶으면, 9091원의 공급가액(부가세 909.1원, 만원의 1/11)에 맞추어 사업을 꾸려야 한다.
  2. 납부 시점의 부가가치세(유동적) : 판매 시점부터 사업자 손에 있다가 사업자들이 나누어서 대리 납부하는 구조이다. 구체적으로는 매출세액(소비자로부터 받아놓은 부가가치세의 합)과 매입세액(사업을 위해 납부하였고, 증빙가능한 부가가치세의 합) 차액의 10%만큼만 최종적으로 제출하며, 매입세액이 더 많으면 돌려받기도 한다. 사업자가 순수하게 창출한 가치(부가가치)의 10%만 세금을 부과하는 것이다..
- 요약하면 판매대금의 최대 9%만큼을 납부하는 것으로, 매입세액에 따라 줄어들 수 있다.
종합소득세(과세표준의 6~45%)/법인세(과세표준의 10~25%)
- 과세표준(100M₩)에 따른 법인세(좌, 100M₩)와 유효세율(우, %) : 10, 20, 22, 25 계단식 수렴이 눈에 띈다.
지방소득세(과세표준의 0.6~4.5%/1~2.5%) : 종합소득세/법인세의 10%

기타비용
- 계산 편의를 위해 이렇다할 백분율 비중이 없는 모든 비용을 다 포함한다. 월세, 임금, 장비 감가상각, Saas / API 등 서비스 비용이 이에 해당하며, 과세표준 산정시의 필요경비/손금에 해당한다

매출(x)과 기타비용률(y)에 따른 과세표준은 다음과 같다.

내용	수식
부가가치세	0.091x
스토어 수수료	0.225+(\|x-150\|/(x-150))0.075 - (1-(\|x-150\|/(x-150)))(11.25/x)
기타 비용	(y/100)*x
과세 표준	(1 - 0.09 - (0.225+(\|x-150\|/(x-150))0.075 - (1-(\|x-150\|/(x-150)))(11.25/x) - (y/100))*x

Figure1. 매출액과 비용률에 따른 과세표준(z, 보라)

2. 순익 일반 = 과세표준 - 소득세

소득세 : 각각 종소세와 법인세를 적용받는다
- https://www.law.go.kr/LSW/lsLinkCommonInfo.do?lsJoLnkSeq=1019372661&chrClsCd=010202&ancYnChk=
- https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EB%B2%95%EC%9D%B8%EC%84%B8%EB%B2%95/%EC%A0%9C55%EC%A1%B0
- 지방소득세는 소득세의 10%로 소득세에 가산해서 계산
순익 = 과세표준 - 소득세

내용	x=매출(천만원), y=비용률(%)에 따른 계산식
과세표준(천만원) 누진공제액으로 계산	P(x,y)=조건(x≤150, (1-0.091-0.15-((y)/(100))) x, (1-0.091-0.30-((y)/(100))) x+22.5)
개인순익(천만원)	개인(x,y)=조건(x≥0 ∧ x≤50000 ∧ y≥0 ∧ y≤90, 조건(P(x,y)≤1.4, P(x,y)0.934, 조건(P(x,y)≤5, P(x,y)0.835+0.1386, 조건(P(x,y)≤8.8, P(x,y)0.736+0.5885, 조건(P(x,y)≤15, P(x,y)0.615+1.6555, 조건(P(x,y)≤30, P(x,y)0.582+2.1505, 조건(P(x,y)≤50, P(x,y)0.560+2.8105, 조건(P(x,y)≤100, P(x,y)0.538+3.9105, P(x,y)0.505+7.2105))))))))
법인순익(천원)	법인(x,y)=조건(x≥0 ∧ x≤50000 ∧ y≥0 ∧ y≤90, 조건(P(x,y)≤20, P(x,y)0.89, 조건(P(x,y)≤2000, P(x,y)0.78+2.2, 조건(P(x,y)≤30000, P(x,y)0.758+46.2, P(x,y)0.736+706.2))))
개인순익률(%)	개인이익률(x,y)=((개인(x,y))/(x))*100
법인순익률(%) =	법인이익률(x,y)=((법인(x,y))/(x))*100

Figure2. 매출 50억(좌), 5000억(우)까지 개인(초록)과 법인(빨강)의 순익(천만원) 그래프 정면. 수수료와 누진세의 영향이 겹치는 15억-20억 부근에서 크게 꺾이는 모습이다.
Fifigure3. 매출 5000억까지 개인(초록)과 법인(녹색)의 순익(천만원) 그래프 후면
Figure4. 매출 50억 까지의 개인(초록)과 법인(빨강)의 순익(천만원) 그래프 후면. 스토어 수수료 변동이 발생하는 15억 부근에서 요철이 발생함을 확인할 수 있다. 개인 그래프에서도 마찬가지의 요철이 확인된다.
Figure5. 매출 5000억 까지의 개인(황토)와 법인(파랑)의 순익률(%) 그래프 후면(좌), 정면(우). 법인의 경우 10% > 20% 세율 변동의 영향을 크게 받는 2억-50억 구간에서 빠르게 감소하고 이후 50%-(VAT 9% + 수수료 30% + 법인세 25% + 비용률)로 수렴하며, 개인의 경우 세율 변동은 완만하지만 세율 분리 구간 자체가 앞단에 몰려 있어 비슷한 구간에서 빠르게 감소하여 30%-(VAT 9% + 수수료 30% + 종소세 45% = 비용률)로 수렴하는 모습이다
Figure6. 매출 50억 까지의 개인(황토)와 법인(파랑)의 순익률(%)그래프 후면. 극 초반의 개인 강세와 2억(법인세율 10% -> 20%)과 15억(수수료변동) 근처의 요철이 눈에 띈다.
Figure7. 매출 50억 까지 개인(황토)와 법인(파랑)의 순익률(%) 그래프 정면. 개인의 경우에도 수수료 요철을 확인할 수 있으며, 종소세 변동에 의한 요철도 범위를 좁혀서 보면 보이기는 하는데 크게 특징적이지는 않다

3. 순익 분석 용례 : 비용률을 결정하면 매출에 따른 순익률을 확인할 수 있다
더보기

요약
- 더보기
  - 개인은 30%- 수렴
  - 법인은 50%- 수렴

수익성 핵심지표 : 리텐션(Retention)

OSP — Tue, 23 Jun 2026 12:21:42 +0900

수익성 핵심 지표로서 리텐션(Retention)

★리텐션 : 재방문률/유지율/잔존율
- 더보기
  - 신규 유입된 고객이 특정 기간동안 재방문한 비율을 의미한다 : 충성고객 비율
    
    지수함수적으로 우하향 이후 멱함수적으로 평탄화되는 것을 전형적인 클래식 리텐션 커브로 삼는다. 정보 누적 등 사용에 따라 가치가 커지는 앱은 우하향 - 평탄화 - 우상향 과정을 거치는 케이스도 보고된 바 있다(Evernote)
    
    Figure1. 클래식 리텐션의 전형적인 양상 : 범위/롤링 리텐션도 큰 양상에서는 대동소이하다. 실제 수치는 깔끔한 곡선이 아니라 들쑥날쑥한 직선들의 집합이고, 그것을 피팅하면 대충 이래 된다.
    
    클래식 리텐션(Classic Retention) : 그 날에 재방문했는지
    
    첫 방문(Day0) 이후 특정 날짜(Day7, Day10, Day30)에 재방문한 유저의 비율(누적X)
    
    Day7 : 첫 방문 이후 딱 7일차에 재방문한 유저 비율
    
    ★범위 리텐션(Range/Bracket Retention) : 그 기간(일, 주, 월)에 재방문했는지
    
    첫 방문 이후 임의의 기간(Week, Month 등)동안 재방문한 유저의 비율(누적X)
    
    Week1 : 첫 방문 이후 최초 1주일 안에 한 번이라도 재방문한 유저의 비율
    
    클래식 리텐션의 재방문 포획 규격을 하루에서 일주일/한달 처럼 범위로 확장한 지표로, 매일 접속할 필요는 없지만 장기적으로는 계속 쓰는 어플리케이션에서 가장 실효적이다. 예를 들어 은행/쇼핑/중고차플랫폼/세금 앱을 클래식 리텐션으로 측정하면 수치는 곤두박질치고 지표의 시각적 의미와 현실적 소비자 감정의 괴리가 벌어진다.이에 클래식 리텐션을 넓은 시간 단위에서도 측정하려는 지표로, 쉽게 이해하면 클래식 리텐션을 일 유형으로 포섭한 확장판이다. Figure1에서 x축 단위가 (주)가 되거나, 일 단위를 유지하면 계단식으로 그리진다.
    
    롤링 리텐션(Rolling Retention) : 그날 이후 한 번이라도 재방문했는지
    
    첫 방문 이후 N일되는 날부터 단 한번이라도 재방문한 비율
    
    Day7 : 첫 방문 이후 7, 8, ...일쨰에 단 한번이라도 재방문한 유저 비율
    
    사용자가 서비스에서 완전히 이탈했는지 여부를 파악하기 위한 지표이다. 언어적 설명만 들으면 이용 주기가 큰 서비스에서 범위 리텐션보다 쓸만한 것처럼 느껴지지만 그렇지 않다. 오늘 기준으로 10일차 리텐션이 20%였어도 내일 재접속이 늘어나면 10일차 리텐션이 21%로 소급되는 특징 때문에 의미를 크게 두기 어렵다. 지금 본 지표는 내일 바뀌고 모레 바뀌고 한달 뒤 또 바뀔 것이기 때문. 재방문 포획 규격을 무한대로 늘린 극단적인 범위 리텐션이라고 볼 수 있다. 단순히 극단적일 뿐만이 아니고, 후술할 내용처럼 그 지표 특성 자체가 클래식/범위 리텐션과 비선형적이다. Figure1에서 y값이 다소 위에 머문다.
    
    클래식/범위 리텐션은 이미 결정되어 바뀔 수 없는 과거 지표라면, 롤링 리텐션은 수치들을 계속 반영하는 실시간 지표에 가깝다. 오늘이 13일차인 경우, 13일차 리텐션 수치는 아직 불확정이다. 이는 어차피 바뀔 것이기 때문에, 13일차에 Day13 또는 Week2 리텐션 데이터를 활용하겠다고 에너지를 소모하는 것에 대해서는 고민이 필요하다. 롤링 리텐션이 하는 게 정확히 그것이다.
    
    약간 전광판 같은 느낌이 있으며, 이 자체만으로는 해석하기 어렵다. 코스피 9000은 코스피 역사를 아는 사람에게는 의미가 크지만, 오늘 처음 본 사람에게는 ?몬데? 인 것과 같다. 따라서 이를 활용하려면 일자별 롤링 리텐션을 애니메이션처럼 제시하여 품질 개선이나 마케팅의 효용 분석을 시각화함에 사용함이 바람직하다 본다.
  - 리텐션은 원시적으로 신규 고객의 재방문률(이하 전체 리텐션)이지만, 조금만 비틀면 구독자의 구독 유지율이 된다(이하 구독 리텐션)
    
    전체 리텐션은 무료 사용자와 유료 사용자가 모두 혼합된 재방문률로 수익성과 관련되긴 하지만 다소 희석되는 반면, 구독 리텐션은 구독자의 구독유지율로 수익성의 가장 직접적인 단서로 기능한다.
    
    전체 리텐션은 "앱의 매력", 구독 리텐션은 "앱의 매력을 수익으로 회수한 정도"로 요약된다.
  - 이탈률(Churm Rate) : 실패고객 비율
    
    측정 시점으로부터 특정 기간동안 앱을 이탈한 사용자로, 리텐션과 상보관계인 지표이다.
    
    기간 내 이탈자수가 기간 시작 시점 사용자 수에서 차지하는 비율을 계산한다. (기간 시작시점 사용자수 기준 이탈 사용자 수)/(기간 시작시점 사용자 수) 로 계산한다.
    
    예를 들어 1월에 1000명이 사용하던 서비스에 이후 2월에 한번이라도 재방문한 사용자가 700명이라면 2월 리텐션은 70%, 이탈률은 30%가 된다. 이처럼 닫힌 사용자 집단에 대해, 리텐션의 기준과 이탈율의 시작점, 그리고 측정 기간이 같으면 리텐션 + 이탈률 = 1이 된다.
    
    예시 케이스에서 "1월 기준"이라는 말을 생략했는데, 만약에 기준이 12월이었고, 12월 사용자가 1400명이었다면 2월의 리텐션이 50%가 되지만 2월의 이탈율은 여전히 30%로, 합이 1이 아니게 된다.
    
    웹 분야에서 사용되던 이탈률(Bounce Rate)이 있었는데, 웹 개발자들이 모바일 개발자로 넘어가면서 용례가 혼합된 것으로 보인다. 특정 세션에 진입 후 별다른 액션 없이 해당 세션에서 바로 탈출하는 비율로, 고객이 탐색조차 거부한다는 치명적인 의미의 지표로 사용되었다. 앞서 살펴보았듯 모바일에서와 의미가 사뭇 다른데, 사실 한국어만 음절이 같지 영어는 음절부터 다르다.

구독모델 재무 회계에서 리텐션

매출 표준 공식 = 전환률 * 구독료 * ∑R^(n)

1. 리텐션에 따른 단위 매출

기간 평균 구독 리텐션 R(T) = ∫dR(t)dt/T, ARPUs =기간당 가입자당 평균 매출(Average Revenuew Per User : 구독료)에 대해 풀어보면 다음과 같다. 수학적으로 무한 시간대에서 R = 0이지만 현실적인 기업 운영 스케일에서 평탄화 구간의 수치로 근사함이 타당하다.
다운로드당 LTV = 설치유료전환률 * 구독료 / (1 - 평균 구독 리텐션)
- 유료고객 LTV = ARPUs = ARPUs*R + ARPUs+R^2 + ... = ∑ARPUs*R^(n) = ARPUs(1-R)
- 설치고객 LTV = 설치사용자당 유료 전환비율(설치유료전환률) * 유료고객 LTV
- 따라서 다운로드당 LTV = 설치유료전환률 * 구독료 / (1 - 평균 구독 리텐션)으로 정리된다
- Figure2. 평균 리텐션에 따른 다운로드당 LTV 그래프이다(전환률 0.02, 구독료 5$) 리텐션 1에서 LTV는 발산한다.. 리텐션에 대한 집착이 사실은 무한 매출에 대한 동경이아닐까 생각한다.
다운로드당 연매출 = 설치유료전환률 * 구독료 * (1 - 평균리텐션^12) / (1 - 평균리텐션)
- 유료고객 연매출 = (ARPUs * ARPUs*R + ... + ARPUs*R^11) = ARPUs(1 - R^12)/(1 - R)
- 설치고객 연매출 = 설치유료전환률 * 유료고객 연매출
- 따라서 다운로드당 연매출 = 설치유료전환률 * 구독료 * (1 - R^12)/(1 - R)으로 정리된다.
- Figure3. 평균 리텐션에 따른 다운로드당 연매출 그래프이다(전환률과 구독료는 위와 같다)
다운로드당 월매출 = 전환률 * 구독료
- 수식 해례는 생략한다
카테고리별 전환률과 구독 리텐션의 러프한 추산치는 다음과 같다.

카테고리	성공 수준	설치유료전환률(%)	월간 구독 리텐션(%)
수치 눈대중	하위	1	35
	중위	2	50
	우수	4	65
	최우수	8	70+
생산성	하위	1	40-
	중위	2.5	50
	우수	5	65
	최우수	8	70+
건강/피트니스*	하위	1	30-
	중위	3	50
	우수	6	60
	최우수	12	75+
미디어/엔터**	하위	1	40-
	중위	2	55
	우수	4	65
	최우수	7	70+
캐쥬얼 게임은 구독보다 일회성 결제에 익숙한 카테고리로, 부적합 배제하였다. * 결제율이 낮은 대신 가격 저항이 약한 카테고리로 알려져 있다. ** 흥미 진입 후 소재 고갈시 구독 해지로 전환률은 초기 리텐션이 준수하나 유지가 짧다.

2. 리텐션에 따른 순익

매출과 비용률에 따른 순익은 다음과 같고
- 2026.06.24 - [DEVELOPMENT/SUUROUNDINGS] - 재정건전성 : 매출과 비용률에 따른 순익(률)
- Figure4. 매출 5000억까지의 개인(황토)와 법인(파랑)의 순익률(%). 법인은 50%, 개인은 30%로 수렴하는 모습
- 매출은 전환률(C), 구독료(F), 구독리텐션(R), 총 다운로드수(N)로 결정되므로 순익은 C, P, R, N, y 다섯 변수의 함수라고 할 수 있으므로, 매출을 R과 N의 함수로 나타낼 수 있다. N과는 계단식 선형 관계를 보이고(누진 구간), R=1에서 발산하는 요철있는 거수 가오리가 된다. 매출별 순익과 해석상 크게 겹치므로 생략한다.

★ 리텐션 향상을 위한 한계 감수비용률
더보기
0. 한계 감수비용률이란
- 리텐션을 delta만큼 향상시키기 위해 감수할 수 있는 추가 비용률로 정의한다.
  - 예를 들어 특정 (Ra, y)지점에서의 delta 0.01에 대한 한계 감수 비용률이 5%라면, 1%의 전체 리텐션 향상을 위해 전체 매출액의 5%까지는 추가 비용을 지불할 이익이 있다는 뜻이 된다.
- 미소 리텐션(delta) 및 미소 비용률(dy)에 대한 순익 차이로 검증한다.
1. 전체 리텐션 향승을 위한 한계 감수비용률
- 전체 리텐션을 delta만큼 향상시키기 위해 감수할 수 있는 비용률 dy에 대해서 고민해보면,
  1. 리텐션에 따른 매출은 상술한 바와 같다.
  2. 다만 이는 구독 리텐션 수식이고, 구독 리텐션과 전체 리텐션의 관계를 시그모이드로 근사한다 : 초반에 빨리 증가하다가 이후에 완화되는 점진적 수렴 모델을 차용한다.
  3. 전환률 역시 전체 리텐션으로부터 자유롭지 못하며, 이 역시 시그모이드로 근사한다 : 사용자가 가치 효용을 체감하는 임계 리텐션에서 전환률이 크게 증가하는 모델을 차용한다
- import numpy as np import math import plotly.graph_objects as go # 전체리텐션에 따른 매출 : N(만명), F(천만원) def revenue(Ra, N, C, F): Rs = subscription_retention(Ra) anuual = (1 - Rs**12) / (1 -Rs) return N*10000 * C * F/10000000 * anuual # 전체리텐션에 따른 구독전환률 : 시그모이드 근사 def conversion(Ra, base_C): M = 5.0 # 전체 리텐션이 100%일 때의 배수 (상한선) k = 5.0 # 곡선의 가파름 (10 정도면 급격함, 5~8이 보수적) x0 = 0.5 # 변곡점 : 가치효용 체감으로 전환률이 가파르게 상승하는 시점. 결제 저항이 낮으면 감소 # 0에서 시작해 1에서 M배가 되도록 정규화된 시그모이드 sigmoid = 1 / (1 + np.exp(-k * (Ra - x0))) f_0 = 1 / (1 + np.exp(-k * (0 - x0))) f_1 = 1 / (1 + np.exp(-k * (1 - x0))) # [0, 1] 구간을 [base_C, base_C * M]으로 스케일링 return base_C * (1 + (M - 1) * (sigmoid - f_0) / (f_1 - f_0)) # 구독리텐션을 전체 리텐션으로 치환 : 시그모이드 근사 [0,1] > (0.3 ~ 0.95) def subscription_retention(Ra): return 1.4/(1 + np.exp(-3.3*Ra)) - 0.4 # 부가가치세와 스토어수수료를 고려한 과세표준 def P(r, y, N, C, F): R = revenue(r, N, C, F) if R <= 150: return (1 - 0.091 - 0.15 - y/100) * R return (1 - 0.091 - 0.30 - y/100) * R + 22.5 # 개인 순익 def personal(r, cost_rate, N, C, F): p = P(r, cost_rate, N, C, F) if p <= 1.4: return p * 0.934 elif p <= 5: return p * 0.835 + 0.1386 elif p <= 8.8: return p * 0.736 + 0.5885 elif p <= 15: return p * 0.615 + 1.6555 elif p <= 30: return p * 0.582 + 2.1505 elif p <= 50: return p * 0.560 + 2.8105 elif p <= 100: return p * 0.538 + 3.9105 else: return p * 0.505 + 7.2105 # 법인 순익 def corporation(r, cost_rate, N, C, F): p = P(r, cost_rate, N, C, F) if p <= 20: return p * 0.89 elif p <= 2000: return p * 0.78 + 2.2 elif p <= 30000: return p * 0.758 + 46.2 else: return p * 0.736 + 706.2 # 개인과 법인의 순익률 def personal_margin(r, y, N, C, F): R = revenue(r, N, C, F) return 100 * personal(r, y, N, C, F) / R def corporate_margin(r, y, N, C, F): R = revenue(r, N, C, F) return 100 * corporation(r, y, N, C, F) / R # 주어진 전체리텐션/비용률에서 delta(리테션 변화)에 따른 순익 증감 # 즉 delta만큼의 리텐션 향상을 위한 한계 감수비용률이 된다 def breakeven_cost_increase(Ra, y, N, base_C, F, delta): current_C = conversion(Ra, base_C) future_C = conversion(Ra + delta, base_C) base = P(Ra, y, N, current_C, F) for dy in np.linspace(0, 50, 1000): new_profit = P(Ra + delta, y+dy, N, future_C, F) if(new_profit) <= base: return dy return np.nan F = 3000 N = 100 base_C = 0.025 delta = 0.01 r_vals = np.linspace(0, 0.99, 300) # 전체리텐션 Ra. 함수들 전부 Ra 기반으로 구성되어 있음 cost_vals = np.linspace(0, 99, 300) # 비용률 y X, Y = np.meshgrid(r_vals, cost_vals) Z = np.full((len(cost_vals), len(r_vals)), np.nan) # Z 객체도 사이즈 맞춰서 생성 # Z 객체에 값 주입 for i in range(X.shape[0]): for j in range(X.shape[1]): # val = personal_margin(X[i, j], Y[i, j], N, C, F) # val = personal(X[i, j]+delta,Y[i, j],N,C,F) - personal(X[i, j],Y[i, j],N,C,F) # 0 초과인 경우에만 값을 대입하고, 나머지는 그냥 nan(기본값)으로 둡니다. # if val > 0: Z[i, j] = breakeven_cost_increase(X[i,j],Y[i,j], N, base_C, F, delta) # else: Z[i, j]는 이미 nan이므로 아무것도 하지 않습니다. # 그리기 fig = go.Figure( data=[ go.Surface( x=X, y=Y, z=Z, contours = { "x": {"show": True}, "y": {"show": True}, "z": {"show": True} } ) ] ) fig.update_layout( scene=dict( xaxis_title="전체리텐션", yaxis_title="비용률 %", zaxis_title="한계 감수비용률 %" ) ) fig.show()
- Figure5. F=3000,base_C=0.025, detla=0.01에 대해서 총 다운로드수 N = 100(좌), 1000(우)에 대한 한계 감수비용률 : 스토어 수수료 구간이 변하는 리텐션 영역에서의 급락이 확인된다. 급락 지점의 차이를 유발하나, 한계 감수 비용률의 범위에 미치는 영향을 상대적으로 미미하다.(0-3%) 구독료 및 전환률에 변화를 주어도 비슷하게 동작한다.
- Figure6. F=3000, base_C=0.025, N=10에 대해서 delta = 0.01(좌), 0.05(우)에 대한 한계 감수비용률. 리텐션 상승수치에 발 맞추어 한계 감수비용률도 증가하는 모습이 확인된다. 전체 매출에 미치는 영향은 앞선 N, C, F에 비해 1/100 배 영향이라서 급락 지점의 이동은 위처럼 빠르지 않다.
- Figure7. Figure6의 delta=0.05 케이스를 위에서 바라본 모습이다. 8-12% 정도의 한계 감수 비용률을 추산할 수 있다.5%의 추가 리텐션을 확보할 수 있다면, 기존 10%의 비용률에 대해 최대 20%까지 비용률 확대를 감수할 이익이 있다는 것이다.
- 상기 Figure 7의 한계 감수 비용률을 10%로 취급해보자.
  - 이는 리텐션 5% 증가가 비용률 10% 증가와 동등한 이익 효과를 낸다는 것이다.
  - 그러나 구독료의 10%는 지속 가능성에 의문이 남는다. 2.5%의 전환률, [0, 0.9]의 리텐션에서 산술적으로 0.25 - 2.5% 이지만, 리텐션 증가하면 한계 감수비용률이 감소하므로 상방이 쪼그라들어 0.25 - 0.75% 정도로 이해할 수 있다
  - 한계 감수율이 delta에 선형적인 양상임을 고려하면 리텐션 증가량에 따라 산술 배수 범위로 접근하는 것도 납득 가능한 추산으로 판단한다.
- 또는 산술적으로 전체 사용자에게 구독료의 N%만큼 비용을 감수하면 다운로드당 비용은 구독료*(N/100), 다운로드당 수입은 1명당 구독료*C가 되며, 수수/세금 등을 고려하면 한계 감수 비용률은 (C/2)가 됨을 파악할 수 있다. 이는 리텐션과 관계 없는 절대 상한이라 볼 수 있다.
- 요약
  - delta : 한계 비용감수율과 선형적인 양상
  - N, C, F : 쌍봉 골짜기 이동
  - 추가리텐션 5%당 구독료의 0.5%
수익성 핵심요소별 리텐션과의 관계
더보기
1. 전환률 C = f(Ra)
  - 다운로드 사용자가 유료 사용자로 전환되는 비율을 일컫는다.
  - 전체 리텐션과 연역적인 귀결 관계가 확인되지는 않으나, 귀납적으로 전체 리텐션과 양의 상관관게에 놓여 있다고 이해됨이 일반적이다. 계속 사용하고 있다는 것은 앱의 가치 효용을 체감하고 있을 확률이 크다는 것이고, 당장은 아니더라도 계속 사용하다 보면 체감에 이를 확률이 높아지는 것이다.
    
    일반적으로 선형적, 지수, 로그보다는 시그모이드/로지스틱스 등 S-Curve 형태로 근사된다.
    
    앞서 서술한 가치 효용 체감 시점에 전환률이 급격히 상승하는 모델이다.
  - 때때로 전체 리텐선의 상승에도 전환률 상승이 정체되거나 역효과가 발생하기도 한다.
    
    리텐션 상승을 주도한 원인이 체리피커의 유입을 유도하는 광고라거나, 유료 사용자의 차별적 이점을 제거한 업데이트인 경우 등이 있다. 단순히 말하면 실패한 어그로다.
    
    또는 무료 기능만으로 충분히 강하거나 유료 기능의 가치가 미비한 경우가 있다. 소비자의 심리적 저항을 불러일으키지 않는 차별적 기능 병목으로 과금 구조를 잘 설계하는 것이 중요하다.
  - 요약하자면 더 깊이 사용하고 싶어야 한다.
2. 구독 리텐션과 전체 리텐션
  - 독 리텐션은 구독 사용자의 구독 유지 비율, 전체 리텐션은 전체 사용자의 사용 유지 비율이다.
    
    구독 리텐션은 상술한 매출 산정의 직접적인 근거가 되며, 고객의 풀이 한정적이다.
    
    전체 리텐션은 매출 산정의 직접 요인은 아니다. 고객의 풀이 넓으며, 매출의 잠재력이 된다.
  - 상호간 수학적인 귀결관계는 없다. 그러나 경험적으로 반복되는 특징이 몇 가지 있다.
    
    전체 리텐션은 0에서 시작하지만, 낮은 전체 리텐션 구간에서도 구독 리텐션은 더 위에서 시작하는 경우가 많다. 아예 구독을 안 했으면 안 했지, 그래도 구독을 시작하면 한 달만에 바로 끊는 경우가 드물다는 것이다.
    
    이후 역전되는 구간이 발생하는데, 가격 저항에 부딪히는 것으로 이해된다.
  - 요약
    
    구독 리텐션 : 실현 수익력, 충성 고객 관리
    
    전체 리텐션 : 수익 잠재력. 고객 확대 관리
    
    중간역전관계
    
    계속 사용하고 싶어야 한다.
3. 구독료
  - 텐션과 뚜렷한 상관관계는 기대하기 어렵다. 따지자면 심리적 가격 저항이 리텐션 하락에 영향을 미칠 수 있으며, 구독전환률과 매출/마진 구조에 영향을 미친다. 수요가 가격에 반비례하는 거시 특성을감안하면 구독 전환률과 구독료를 곱하면 변화가 크지않은 준 상수처럼 취급할 수도 있다.
    
    2026.06.19 - [DEVELOPMENT/SUUROUNDINGS] - Google Place API(New) 가격 정책(2026.06) 및 적정 마진
  - 요약하면 마땅한 가격이어야 한다.

광고모델 재무회계에서 리텐션

매출 표준 공식 : ARPUa * Ad

Ad(T) (= ∫dRa(t)dt)는 사용자당 적분기간(T)내에서 활성일수 평균, ARPUa는 사용자 1인당 하루 광고 매출 평균이댜(=하루 광고노출횟수 평균(I)/1000*eCPM)

광고 시장에서 광고주는 노출당(CPM), 혹은 클릭당(CPC), 또는 다운로드당(CPI) 광고료를 지불하게 된다. 이를 퍼블리셔 입장에서 노출 1000회당 평균 수익으로 단일화한 수치가 eCPM이다. 광고 형식과., 국가에 따라 범위가 eCPIM은 범위가 넓게 포진한다. 우측은 중간값이다. 소비력이 약한 국가는 보수적으로 채택함이 옳다.

국가	배너		네이티브		전면		보상형
미국 계열	0.2 - 1	0.6	1 - 4	2.5	4 - 12	8	10-30	20
유럽/일본	0.15 - 0.8	0.48	0.8 - 3	1.9	3 - 10	6.5	8 - 25	16.5
한국	0.1 - 0.5	0.3	0.5 - 2	1.25	2 - 8	5	5 - 20	12.5
남미	0.05 - 0.3	0.18	0.2 - 1	0.6	1 - 4	2.5	2 - 10	6
인도	0.02 - 0.2	0.11	0.1~0.5	0.3	0.5~2	1.25	1 - 6	3.5

다운로드당 월/연매출 및 LTV은 다음과 같다
- ARPUa * A(30)
- ARPUa * A(365)
- ARPUa * A(∞)
eCPIM = 1에서 Ad(빨강)과 I(초록)에 따른 월매출/LTV을 살핀다.
- Figure8. 평균활성일수와 하루 평균 노출횟수에 따른 매출 그래프. eCPM에 선형적으로 비례하기 때문에 형식/국가별 eCPM값을 곱하면 전체적으로 응용할 수 있다.
- 미국 사용자들에게 제공하는 앱에 네이티브 광고를 달고 1년간 10일 활성에 하루 3회 노출을 가정하면 연매출 0.05 * 2.5 = 0.125$(188원), 평생 15일 활성으로 LTV/ 0.1875$(281원)가 된다.

★ 광고 + 구독 모델에서 1 다운로드 확보를 위한 집행 비용
- LTV
- 더보기
  - 다방면에서 흔한 수익모델이다.
    
    수학적으로는 구독 LTV와 광고 LTV의 구독 전환률(C) 내분값으로 해석할 수 있다. 그러나 편의상 광고 모델 LTV * N 으로 단순화해보자.
  - 보수적으로 1<N<3정도 잡으면
    
    미국/네이티브에서 수수료와 세금을 고려하면 1 다운로드당 100-700원 정도, 인도라면 10-70원 정도 비용이 손익 분기점이 될 것으로 예상한다. 현재 CPI가 미국 0.9$, 인도 0.2$정도인데 이것도 싼 레인지에 속하는 편이라, 대체로 손해가 예상된다.
리텐션 개선을 위한 주요 도구
- 온보딩 : 도입부에서 앱의 가치를 직관적으로 수긍하도록 하여 초기 이탈 방지
- 더보기
  - 통계적으로 30초 - 3분 이내에 앱의 가치를 납득하지 못한 사용자는 이탈 후 앱을 삭제한다. 카테고리에 따라 수치는 상이할 수 있겠으나, 중요한 것은 고객의 첫인상을 사로잡아야 한다는 것이다.
    
    앱의 가치는 미감, 성능, 비전 등이 있을 수 있다.
  - 온보딩은 이런 첫인상에 중요한 역할을 한다. 뭘 하는 앱인지 알고 행동이 명확하다면 온보딩은 굳이 필요 없다 말할 수 있다. 그러나 앱의 차별화에 대해 고민하면 대부분의 경우 부분적으로라도 온보딩을 채택하는 것이 유리하다 할 수 있겠다. 앱의 차별점이 순수한 미감이나 비전이라면, 온보딩은 굳이 채택할 실익이 없을 수 있다.
  - 요약하면 시작부터 한 눈에 이해하게 만들어야 한다.
- 습과화 도구 : 도입부-초반부에서 앱을 지속적으로 사용하는 습관을 형성하여 장기적인 관계 형성
- 더보기
  - 첫인상을 넘어서면 두번째 큰 관문이 있는데, 많은 사용자는 그 이후 두어번 들락날락 거리고 더이상 방문하지 않는다는 것이다. 여기서부터는 현실적인 리텐션의 설계의 문제이다.
    
    출석체크나 퀘스트,미션 등 앱을 재방문하거나, 앱의 기능을 사용함에 따라 보상을 제공하는 것이 좋다. 이러한 습관화 도구의 독점적인 보상을 제공하는 형태도 있을 수 있지만, 수익성 측면에서는 유료 기능의 일부를 제공하는 것이 더 유리함이 일반적이다. 리텐션 상승은 크게 차이나지 않는 반면 독점 보상이 유료 기능의 가치를 희석하는 하방 압력만 발생하기 때문이다.
  - 요약하면 계속 사용하는 넛지환경을 제공해야 한다.
- 맞춤/행동 기반 알림 : 중반부 이후부터 사용자들에게 직접적인 리마인드
- 더보기
  - 성공적이면 리텐션을 직접적으로 끌어올릴 수 있다. 그러나 기본적으로 저항이 있는 옵션이라 실패시 확실한 이탈(앱 삭제)의 트리가기 되거나, 싸구려 앱이라는 인상을 남길 수도 있다. UX상 이는 시스템 알림으로 제공되는 광고와 마찬가지이기 때문이다.
    
    업데이트나 이벤트, 혹은 시기에 따라 예상되는 수요의 맞춤 공급 등 고객의 입맛을 정교하게 고려한 알람이 필요하다. 소비자 입장에서 별다른 득도 없는데 남용되는 순간 곧바로 아웃으로 이어진다. ~~배민에서 쿠폰도 안 주면서 푸시알람만 띄우면 빡이 쳐 안 쳐 배민은 그나마 이미 수요가 쌓여서 망정이지 어디 듣보잡 앱이 이랬어봐 콱 씨~~
  - 요약하면 계속 사용하도록 안내해야 한다.
요약
- 더보기
  - 판 키우기
    
    키워서 먹기 위한 한계 비용은 추가 리텐션 5%당 구독료의 0.5%
  - 수익성 개선
    
    리텐션 : 계속 사용하기 쓸만한 앱을 만들어 한 눈에 이해하고 계속 사용하도록 하며
    
    전환률 : 납득 가능한 차별적 기능을 마땅한 가격에 제공해야 한다

Google Place API(New) 가격 정책(2026.06) 및 적정 마진/호출횟수

OSP — Fri, 19 Jun 2026 14:23:01 +0900

Google Place API(New) 가격 정책(2026.06) 및 적정 마진/호출횟수

Place API 과금 기준은 등급(Essentials / Pro / EnterPrise)이라는 큰 분류와 SKU라는 작은 분류로 구성된다.

요청 데이터 필드에 따라 SKU 결정 > SKU별 요금 테이블에 의거해서 요금이 과금된다
요청 데이터 필드별 SKU

Place API(New)는 불러오는 데이터를 선택하도록 하는데(필드 마스크), 요청된 데이터 필드중에서 가장 비싼 데이터 필드의 SKU를 기준으로 요금제 등급이 결정된다. 예를 들어 Essentials Field만 요청하면 Essentials SKU만 트리거되고, Essentials 요금제로 책정된다. 반면 데이터 필드가 하나라도 Pro면 Pro SKU가 트리거되고, Pro 요금제로 책정된다.
- https://developers.google.com/maps/documentation/places/web-service/place-details?
- https://developers.google.com/maps/billing-and-pricing/sku-details?

Place Details Essentials SKU IDs Only SKU
Field	내용
attributions	장소 데이터의 출처
id	고유 식별자
moved_place moved_place_id	(주소이전/폐업 등) 옛날 주소로 검색한 경우 신규 주소로 안내하는 용도
name	장소의 시스템용 명칭 (place/ChIj-58Kq39...)
photos	사진

Place Details Essentials SKU
Filed	내용
addressComponents	시/구/동/우편번호 등 주소의 구조적 데이터
addressDescriptor(인도)	묘사형 주소(A은행 옆, xx역 도보 5분 등)
adrFormatAddress	웹 표준 포맷에 맞춘 주소 데이터
formattedAddress shortFormattedAddress	전체 주소
postalAddress	우편 주소
location plusCode	위도/경도 정보 및 그 약식
types	해당 장소가 속한 카테고리 목록
viewport	장소를 지도에 표시할 때 카메라 영역

Place Details Pro SKU
Filed	내용
accessibilityOptions	거동 불편자를 위한 편의성 구성 여부
businessStatus	영업 상태(영업 중/폐업 등)
subDestinations	해당 장소(대형 시설)에 속한 장소 목록
containingPlaces	해당 장소가 속한 대형 시설 (신세계 내부 스타벅스인 경우, 해당 신세계 백화점)
displayName	장소의 사람용 명칭(스타벅스 시청점 등)
googleMapsLinks	다양한 Google Maps 기능으로 이동할 수 있는 링크 모음 (길 찾기, 리뷰 작성, 사진 찾기 등)
googleMapsUri	해당 장소의 Google Maps 상세 페이지로 연결되는 URI
iconBackgroundColor iconMaskBaseUri	지도상에서 표시되는 아이콘 디자인 관련 속성
openingDate	영업일 정보
primaryType primaryTypeDisplayName	장소의 업종 분류(restraunt/ cafe 등)
pureServiceAreaBusiness	순수 서비스 비즈니스 여부(배달전문, 출장세차 등)
timeZone utcOffsetMinutes	해당 장소의 표준 시간대 및 UTC와의 차이(min)

Place Details Enterprise SKU
Filed	내용
currentOpeningHours currentSecondaryOpeningHours regularOpeningHours regularSecondaryOpeningHours	현재 혹은 정기적인 영업 시간
internationalPhoneNumber nationalPhoneNumber	국제/국내용 전화번호
priceLevel priceRange	가격대 정보
rating userRatingCount	평점 및 개수
transitStation(대중교통 거점)	버스 정류장, 지하철역 등 교통 거점의 데이터
websiteUri	웹사이트 URI

Place Details Enterprise + Atmosphere SKU
Filed	내용
servesBeer servesBreakfast servesBrunch servesCocktails servesCoffee servesDessert servesDinner servesLunch servesVegetarianFood servesWine menuForChildren delivery takeout reservable liveMusic fuelOptions*(주유소)	상품/서비스 제공 여부 * 제공하는 연료 종류
dineIn outdoorSeating restroom	장소 제공 여부
goodForChildren goodForGroups goodForWatchingSports allowsDogs	아이/모임/관람에 좋은지 여부 반려견 동반 가능 여부
paymentOptions	결제 수단
reviews reviewSummary	사용자 리뷰 및 요약
editorialSummary generativeSummary neighborhoodSummary	요약(편집자/AI/로컬/리뷰)
parkingOptions curbsidePickup evChargeOptions evChargeAmenitySummary	자동차 관련 필드 (주차장, 드라이브쓰루, 전기차 충전 여부 및 요약)
routingSummaries	(Text/Nearby Search SKU에서만 해당) 출발지에서 해당 장소까지의 경로 데이터(수단/시간/거리 등)

SKU별 요금제 테이블

SKU호출건수에 따라 가격이 책정된다. 예를 들어 Place API Essentials Autocomplete Requests SKU가100회호출되면 0.283$의 요금이 부과되며, 사용량이 많아질 수록 단위 비용은 감소한다.
- https://developers.google.com/maps/billing-and-pricing/pricing?

Place API (New) Essentials
SKU Name	$/1000회 (최대~최소)
Autocomplete Requests	2.83	0.21
Autocomplete Session Usage	Free	Free
Place API Place Details Essentials IDs Only	Free	Free
Place API Place Details Essentials	5	0.38
Place Dtails Text Search Essentials IDs Only	Free	Free
Place UI Kit Query	1	0.08
Place Ui Kit - Autocomplete Per Session	10	0.80
Time Zone	5	0.38

Place API (New) Pro
SKU Name	$/1000회 (최대~최소)
Address Validation Pro	17	1.28
Place API Nearby Search Pro	32	2.40
Place API Place Details Pro	17	1.28
Place API Text Search Pro	32	2.40
Place Aggregate API	10	0.75

Place API (New) Enterprise
SKU Name	$/1000회 (최대~최소)
Address Validation Enterprise	25	2.28
Place API Nearby Search Enterprise	35	2.63
Place API Nearby Search Enterprise + Atmosphere	40	3.40
Place API Place Details Enterprise	20	1.51
Place API Place Details Enterprise + Atmosphere	25	2.28
Place API Place Details Photos	7	0.53
Place API Text Search Enterprise	35	2.63
Place API Text Search Enterprise + Atmosphere	40	3.40

지도 검색에서 자동 완성은 인프라급 UX로 포기하기 어렵지만, 그 과금 구조 특성상 주의를 요한다.

자동완성 세션 과금 구조 및 시나리오

일반적으로 검색은 버튼, 엔터 등 명확한 종료행위를 수반한다. 1회 검색 : 쿼리의 1:1 관계가 성립하지만, 자동완성의 경우에는 1회 검색 : 검색 종료까지의 쿼리가 1:N 관계가 성립한다.
디바운스 딜레이, 타자 속도, 자동완성 완성도 등에 따라 달라지겠지만 "스타벅스 시청점"을 검색하는 경우를 예를 들어 보자. "스" > "스타" > "스타버" > "스타벅스" > "스타벅스 싳" > "스타벅스 시청저", "스타벅스 시청점". 예시 케이스에서 총 7회 자동완성을 수반하며, 여기에 마지막에 스타벅스 시청점을 클릭해서 Masked Field Data를 요청하는 것까지 총 8회의 SKU를 트리거하게 된다.
- Google Maps는 이렇듯 다소 공격적인 과금구조를 설계한 뒤 세션 사용을 제시한다.
- https://developers.google.com/maps/documentation/places/web-service/session-pricing?

세션 생명 주기

세션 생명 주기
세션 시작	첫 번째 Autocomplete 요청
세션 유지	후속 Autocomplete 요청
세션 종료	Place Details 또는 Address Validation 요청 또는 불완전한 세션 종료

요금 시나리오

뒤로가기 / 앱 종료 등 불완전 종료되는 세션의 요금 시나리오
Autocomplete	Autocompete Requests SKU 트리거 : 0.00283$
청구서	자동완성 요청 횟수 * 0.00283$

Place Details Essentials 요청으로 종료되는 세션의 요금 시나리오
처음 12개의 Autocomplete	Autocompete Requests SKU 트리거 : 0.00283$
후속 Autocompete	Autocompete Session Uasge SKU 트리거 : 무료
Place Details Essentials	Place Details Essentials SKU 트리거 : 0.005$
청구서	{ min(12, 자동완성 요청 횟수 * 0.00283$ } + 0.005$

Place Details Pro / Address Validation Pro 요청으로 종료되는 세션의 요금 시나리오
Autocomplete	Autocomplete Session Usage SKU 트리거 : 무료
Place Details Pro 또는 Address Validation Pro	Place Details Pro SKU 트리거 : 0.017$ 또는 Address Validatoin Pro SKU 트리거 : 0.017$
청구서	0.0017$

Place Details Enterprise / Address Validation Enterprise 요청으로 종료되는 세션의 요금 시나리오
Autocomplete	Autocomplete Session Usage SKU 트리거 : 무료
Place Details Enterprise 또는 Address Validation Enterprise	Place Details Enterprise SKU 트리거 : 0.020$ 또는 Address Validation Enterprise SKU 트리거 : 0.025$
청구서	0.020$ 또는 0.025$

Place Details Enterprise + Atmopshere 요청으로 종료되는 세션의 요금 시나리오
Autocomplete	Autocomplete Session Usage SKU 트리거 : 무료
Place Details Enterprise + Atmosphere	Place Details Enterprise + Atmosphere SKU 트리거 : 0.02$
청구서	0.025$

자동완성 과금 구조의 특징 : 필드 마스크에 따른 계단식 과금 쳬게와 세션형 요금제의 결합

앞서 살펴보았듯, Essentials/Pro 등 데이터 필드 마스크에 따라 계단식 요금제 정책을 두고 있으며, Essentials 필드만 요청하는 경우 SKU 단위로는 가장 저렴한 가격이 부과된다. 그러나 세션을 종합하면 오히려 비싸지기도 한다.
20회의 자동완성 이후 Place Details로 세션이 종료되는 경우를 예시로 하면, Essentials 등급은 12회의 자동완성 + 1회의 세부정보 비용으로 총 0.03896$이 부과되며, Non-Essentials 등급은 각각 0.017$, 0.20$, 0.25$이 부과된다. 정상 종료 케이스에서 자동완성 요청 수에 따른 세션별 가격 그래프는 다음과 같다
Figure 1. 자동완성 5회 이상부터는 Essentials가 가장 저렴한 요금제가 아니다.
뒤로가기, 앱 종료 등 불완전 종료 케이스에서는 자동완성 요청은 요청별 가격으로 되돌아가며, 각각 0.00283$이 부과된다. Place Details가 호출되지 않고 필드 마스크의 요금제 등급에 무관하다.
- Figure 2. 불완전 종료 케이스에서 모든 요금제는 대등하다
자동완성 요청 횟수(x), 정상:비정상 종료 비율(y:1-y), 세션별 비용(z)를 시각화하면 다음와 같다
Essentials z=y (0.005+0.00283*((x+12-abs(x-12))/(2)))+(1-y)*0.00283*x

Pro z=y*0.017+(1-y)*0.00283*x

Enterprise z=y*0.020+(1-y)*0.00283*x

Enterprise + Atmosphere z=y*0.025+(1-y)*0.00283*x
- Figure7. Essentials - Enterprise + Atmosphere : 자동완성 5-8회 이상은 Essentials 비용 열위
Figure 3-7을 종합한 러프한 비용 우열을 매트릭스로 나타내면 다음과 같다.

	자동완성 요청 적음	자동완성 요청 많음
정상 종료 적음	Essentials 비용 근소 우위	Non-Essentials 비용 근소 우위
정상 종료 많음	Essentials 비용 우위 (최대 80%절감, 0.005 : 0.025)	Non-Essentials 비용 우위 (최대 56.5%절감, 0.03896 : 0.017)

자동 완성 과금 구조를 고려한 비용 최적화 방안

1. 통계적인 관점에서 Essentials와 Non-Essentials간 상대적인 비용 우열

정상 종료의 비중은 어플리케이션의 성질에 따라 크게 좌우된다. Google Maps 같은 단순 지도앱의 경우 호기심/탐색형 검색이 많아 자동완성 결과까지만 확인할 뿐 세부 정보 요청으로 진입하지 않고 불완전 종료로 마무리되는 경우가 과반으로 알려져 있으며, 배달앱, 택시앱 등 장소 검색 목적이 뚜렷한 경우에는 70~90% 수준의 빈도로 정상 종료되는 것으로 알려져 있다.
- 단순 지도앱이 아님에도 비정상 종료 세션이 많다면 어플리케이션에 장소 검색이 필요한지, 필요하다면 어째서 중도 이탈하는 것인지 의문을 가져야 한다. 또한 단순 지도 앱은 인프라적으로 기능하여 사업성 측면에서 범국가적 규모의 B2B 사업에 가깝기 때문에, 다수 불완전 종료 매트릭스는 대부분의 개발자들에게 애초에 해당 사항이 없다.
따라서 다수 정상 종료 매트릭스의 비용 우열을 살펴보면 다음과 같다.

자동 완성	등급	필수 - 비필수 비용 우열 및 절감률 (빨강: Essentials, 파랑 : Non-Essentials, 회색 : 10% 미만)
-	-	y = 0.6	y = 0.7	y = 0.8	y = 0.9	y = 1.0
0회 0.005	Pro	71	71	71	71	71
	Enterprise	75	75	75	75	75
	Enter + Atmo	80	80	80	80	80
1회 0.00783	Pro	49	50	52	53	53
	Enterprise	56	57	59	60	61
	Enter + Atmo	64	66	67	68	69
2회 0.01066	Pro	31	33	34	36	37
	Enterprise	59	42	44	45	47
	Enter + Atmo	50	52	54	56	57
3회 0.01349	Pro	15	17	18	20	21
	Enterprise	25	28	29	31	32
	Enter + Atmo	38	40	42	44	46
4회 0.01632	Pro	3	3	3	4	4
	Enterprise	13	15	16	17	18
	Enter + Atmo	27	29	31	33	35
5회 0.01915	Pro	8	9	9	10	11
	Enterprise	3	3	4	4	4
	Enter + Atmo	17	19	20	22	23
6회 0.02198	Pro	15	17	19	21	23
	Enterprise	6	7	8	8	9
	Enter + Atmo	8	9	10	11	12
7회 0.02481	Pro	21	23	26	29	31
	Enterprise	13	14	16	18	19
	Enter + Atmo	0	1	1	1	1
8회 0.02764	Pro	25	28	32	35	38
	Enterprise	18	20	23	25	28
	Enter + Atmo	6	7	8	9	10
9회 0.03047	Pro	28	33	37	40	44
	Enterprise	22	25	28	31	34
	Enter + Atmo	12	13	15	16	18
10회 0.0333	Pro	31	36	40	45	49
	Enterprise	25	29	33	36	40
	Enter + Atmo	16	18	21	23	25
11회 0.03613	Pro	34	39	44	48	53
	Enterprise	28	33	37	41	44
	Enter + Atmo	20	22	25	28	31
12회 0.03896	Pro	36	41	46	51	56
	Enterprise	31	35	40	44	49
	Enter + Atmo	23	26	29	33	36
...

0회부터 5~7회의 분기점까지 Essentials의 이익이 빠르게 감소하며, 그 이후부터는 Non-Eseesntials의 이익이 완만하게 증가하는 모습을 보인다.

2. 절대적인 비용 상한

앞서 상대적인 비용 우위를 살펴보았는데, 그 논리의 주요한 전제는 통계적인 관점에서 y가 1에 가깝다는 것이었다. 그러나 통계적인 관점을 벗어나면, 사용자가 Place API를 호출하는 각각의 현실 케이스에서 y는 0(불완전 종료)또는 1(정상 종료)만을 갖는다.
정상 종료 케이스는 앞서 살핀 상대적 비용우열에 포함되는 영역이지만, 불완전 종료 케이스는 그렇지 않다. 요금제 차등이 없어 상대적 우열을 가리는 것이 원리적으로 불가능할 뿐만 아니라, 가장 중요하게도 요금 상한이 존재하지 않는 케이스이기 때문에 동일하게 포섭하는 것은 옳지 않다. 따라서 프로그래밍 레벨에서는 Place API를 호출하는 경우 이 불완전 종료 케이스에 대한 처리가 필요하다.

종료	자동 완성 요청에 따른 가격 ($/1000회)
-	6	7	8	9	...	13	14	...	100	...
불완전	016.98	019.81	022.64	025.47		036.79	039.62		283.0
Essen	021.98	024.81	027.64	030.47		038.96	038.96		038.96
Pro	017.00	017.00	017.00	017.00		017.00	017.00		017.00
Enter	020.00	020.00	020.00	020.00		020.00	020.00		020.00
En+At	025.00	025.00	025.00	025.00		025.00	025.00		025.00

Essentials의 경우 13회까지 불완전 종료가 비용 우위이고, Pro, Enterprise, Enterprise + Atmosphere는 각각 6회, 7회, 8회까지 불완전 종료가 비용 우위를 점한다.

3. 시나리오별 비용 최적화

Non-Essentials 데이터가 필요한 경우
- 정상 종료 케이스에서는 비용 최적화가 필요 없다. 변동 가격이 아니기 때문이다. 갈림길이 없어 비용 절감 전략이 뚜렷하다.
- 불완전 종료 케이스에서는 이를 우선 탐지하여 Place Details SKU 호출하고, 세션 정상 종료로 처리하여 비용 상한을 잠그는 것이 최소한의 방어로 보인다. 더 적극적으로는 불완전 종료가 비용 우위를 갖는 자동 완성 호출 횟수 13(Essential), 6(Pro), 7(Enterprise), 8(Ent+Amt)까지는 파이프라인에서 불완전 종료를 그대로 패싱하고, 그 이후부터는 Place Details SKU를 호출하여 세선 정상 종료로 취급되도록 한다.(불완전 종료 대응 로직)
Essentials 데이터만 필요한 경우
- 정상 종료 케이스에서부터 비용 최적화를 고려해야 한다. 비용과 UX의 트레이드 오프 관계가 설계되어 있기 때문에, 선택을 해야 하는 시점이 온다. 예를 들어 5회의 자동완성시 19.15$로 Place Details Pro SKU의 17.00$을 상회한다. 즉 세션당 자동완성이 평균 5회 이상이라면 차라리 Pro가 더 저렴하다. 여기서 기로에 놓인다. 디바우스 및 세션제한으로 자동완성 횟수를 제한하며 Essentials를 유지하던가(비용 채택), 아예 Pro를 채택하는 것이다(UX 채택)
  - 다수의 장소는 프랜차이즈명+지명, 지명 + 카테고리의 조합인데, GoogleMaps 기본 제공 UI 기준으로 스타벅스 시청역점을 10회 검색해본 결과 Google Colud 측정항목에서 Place API가 290회 호출된 것으로 확인된다. 타자가 느린 편도 아닌데 화면 바뀌는 게 심상치 않다 했더니 비용 절감을 위해서 기본 UI는 지양해야 할 것으로 보인다.
  - 디바운스 : 한국어 기준 10음절를 입력한다 치면, 평균 200음절/min 타이핑 속도로 3초가 예상된다. 이 경우 자동완성을 4회 이내로 제한하려면 디바운스를 750ms 이상으로 설정해야 한다. 참고로 검색 UX에서 적정 디바운스는 200~300ms정도로 보는 것이 일반적이다.영어 기준으로 3단어를 35단어/min의 타이핑 속도로 입력하면 5초가 넘고, 이 경우 Essentials의 비용 우위를 위한 최소 디바운스는 약 1300ms가 된다.
  - 세션 제한 : 일정 시간이나 일정 자동완성 횟수를 초과하면 검색 세션 자체를 제거하는 방법인데, 이건 상당히 치명적인 UX라 논하지 않겠다. "손님, 네 거 다 썼으니까 당장 나가"라고 말하며 쫓아내는 셈인데, 이정도 배짱 장사는 쉽지 않다.
- 불완전 종료 케이스에서는 상술한 불완전 종료 대응 로직을 따른다.

장소검색 비용을 고려한 적정 마진

순익계산 : 순익 = f(매출, 기타비용률) = f(g(리텐션), 기타비용률)

매출액별 순익은 다음과 같다.
- 2026.06.24 - [DEVELOPMENT/SUUROUNDINGS] - 재무회계 : 매출과 비용률에 따른 순익(률)
- Figure8. 매출 5000억 까지의 개인(황토)와 법인(파랑)의 순익률(%). 법인은 50%-, 개인은 30%-로 수렴하는 모습

상술한 매출별 순익 매트릭스를 포섭한 구독료에 따른 순익을 계산하면 아래와 같다.

환율 1500원/$, 다운로드 당 유료 전환률을 0.4%라 가정했을 때, 1만 다운로드당 40명의 구독전환 기댓값을 기반으로 구독료별 순익을 계산하면 다음과 같다.

구독료 ($/월)	단위 매출 (원/설치)	설치 수 (만회)	총 연매출 (천만원)	개인/법인의 순익률(%)
기타 비용률(%)				10	20	30	40	50
1	72	28	2	62/59	60/50	43/41	35/32	25/23
		69	5	58/59	50/50	41/41	33/32	24/23
		278	20	49/59	43/50	37/41	30/32	22/ 23
		694	50	43/56	37/48	31/40	25/32	19/23
		3472	250	33/48	28/40	23/32	17/24	12/16
2	144	14	2	62/59	60/50	43/41	35/32	25/23
		35	5	58/59	50/50	41/41	33/32	24/23
		139	20	49/59	43/50	37/41	30/32	22/23
		347	50	43/56	37/48	31/40	25/32	19/23
		1736	250	33/48	28/40	23/32	17/24	12/16
3	216	9	2	62/59	60/50	43/41	35/32	25/23
		23	5	58/59	50/50	41/41	33/32	24/23
		93	20	49/59	43/50	37/41	30/32	22/23
		232	50	43/56	37/48	31/40	25/32	19/23
		1157	250	33/48	28/40	23/32	17/24	12/16
4	288	7	2	62/59	60/50	43/41	35/32	25/23
		17	5	58/59	50/50	41/41	33/32	24/23
		69	20	49/59	43/50	37/41	30/32	22/23
		174	50	43/56	37/48	31/40	25/32	19/23
		868	250	33/48	28/40	23/32	17/24	12/16
5	360	6	2	62/59	60/50	43/41	35/32	25/23
		14	5	58/59	50/50	41/41	33/32	24/23
		56	20	49/59	43/50	37/41	30/32	22/23
		139	50	43/56	37/48	31/40	25/32	19/23
		694	250	33/48	28/40	23/32	17/24	12/16
6	432	5	2	62/59	60/50	43/41	35/32	25/23
		12	5	58/59	50/50	41/41	33/32	24/23
		46	20	49/59	43/50	37/41	30/32	22/23
		115	50	43/56	37/48	31/40	25/32	19/23
		579	250	33/48	28/40	23/32	17/24	12/16
7	504	4	2	62/59	60/50	43/41	35/32	25/23
		10	5	58/59	50/50	41/41	33/32	24/23
		40	20	49/59	43/50	37/41	30/32	22/23
		99	50	43/56	37/48	31/40	25/32	19/23
		496	250	33/48	28/40	23/32	17/24	12/16
8	576	3	2	62/59	60/50	43/41	35/32	25/23
		9	5	58/59	50/50	41/41	33/32	24/23
		35	20	49/59	43/50	37/41	30/32	22/23
		87	50	43/56	37/48	31/40	25/32	19/23
		434	250	33/48	28/40	23/32	17/24	12/16
9	648	3	2	62/59	60/50	43/41	35/32	25/23
		8	5	58/59	50/50	41/41	33/32	24/23
		31	20	49/59	43/50	37/41	30/32	22/23
		77	50	43/56	37/48	31/40	25/32	19/23
		386	250	33/48	28/40	23/32	17/24	12/16
10	720	3	2	62/59	60/50	43/41	35/32	25/23
		7	5	58/59	50/50	41/41	33/32	24/23
		28	20	49/59	43/50	37/41	30/32	22/23
		69	50	43/56	37/48	31/40	25/32	19/23
		347	250	33/48	28/40	23/32	17/24	12/16

예를 들어 구독료 3$에 연매출 5억이라면, 비용률 30%일 때 순익률은 31/40%이다.(파란색)
구독자당 평균 구독기간을 1년이라 가정하면 단위 매출이 곧 단위 LTV가, 총 연매출이 LTV가 된다. 구독료를 2$로 책정했을 때 347만회의 다운로드를 확보한 경우 총 매출 기댓값은 5억이 되며, 비용률에 따라 순익을 계산할 수 있다. 비용률이 20%라면 생애 순익은 18,500, 24,000만원이, 1다운로드당 생애 순익은 53/69원이 된다(녹색)
반대로 1다운로드당 생애 순익을 300원 이상으로 맞추고 싶다면 매트릭스상 구독료에 따라 비용률은 10~30%이하로 책정하여야 할 것이다(빨간색)

★구독료와 적정 호출 횟수 : 무료 사용자와 유료 사용자의 호출 횟수 한도

1. 무료 사용자의 호출 횟수

무료 사용자에게도 비용을 감수하는 것은 수익 잠재력(리텐션)을 통한 수익성 개선에 있으며, 리텐션 향상을 위한 한계 감수비용륭은 아래에서 확인할 수 있다.
2026.06.23 - [DEVELOPMENT/SUUROUNDINGS] - 수익성 핵심지표 : 리텐션(Retention)
Figure9. 5%의 리텐션 확보를 위한 한계 감수비용률 그래프. 대략 10%로 추산할 수 있다.
10% 추산값과, 구독 전환률 0.025를 상수로 근사하면 구독리텐션에 따른 매출공식에 따라 [0, 0.7]의 구독리텐션 범위에서 한계 감수비용은 구독료의 [0.0025, 0.008]배가 된다. 구독료가 3000원이면 7.5-24원인 셈. 이를 15원으로 평균을 내면, 무료사용자에게 한 달에 제공하는 Place API Pro 1회마다 대략 5%의 전체 리텐션 확대를 가져와야 수지타산이 맞게 된다.
확대 리텐션에 변동계수를 산술적으로 대입하면 2.32~4.3%으로, 주 1회 , 한달4회를 무료로 제공해서 추가 리텐션 15% 정도를 확보할 수 있다면 합리적으로 납득 가능한 비용 부담이라는 것이다. 보수적으로는 20~30% 범위로 가늠된다.

2. 유료 사용자의 호출 횟수

모식형 단편 두 개를 짚고 시작한다 :

한달 구독료가 10$이고 40%의 비용 상한(전부 API : 4$)을 설계했다고 생각해보자. Pro 기준 한달에 최대 235회의 장소 검색 세션을 제공할 수 있으며, 이는 하루 8번의 장소 검색을 전제로 비용을 부과하는 것이다
상술한 순익 매트릭스에서 비용률이 40%인 행을 짚으면 매출에 따른 순익률을 예상할 수 있다. 연매출 2억까지는 30%를 약간 상회하다가 그 이후부터 개인사업자 먼저 빠르게 감소하는 모습을 볼 수 있는데, 순익 매트릭스 보는 법을 알았으니 이제 단편을 구체적으로 살핀다.
1. 단편 1: API 호출 상한 횟수 변동 *
  - 1, 택시나 배달 앱도 아니고 검색 횟수가 불필요하게 많다고 판단했다면, API 비용 상한을 2$로 줄이고 구독료도 5$로 낮출 수 있다. 이 경우 상술한 순익 매트릭스에서 비용은 동일하고 매출액이 증가하는 것을 기대할 수 있다. 순이익은 늘고, 순익률은 줄게될 것이다. 대체로 없는 일이다(로켓과 깃털의 깃털).
  - 2. 혹은 API 상한 비용만 2$로 감축하되 구독료는 동결하여 비용율을 20%로 낮출 수도 있다. 이 경우 상술한 순익 매트릭스에서 비용률만 낮아질 것을 기대할 수 있다. 소비자 입장에서 외관상 차이는 없어 매출에는 영향을 미치지 않을 것이고, 순익과 순익률만 증가할 것이다.
  - 3. 반대로 검색 횟수가 부족하다고 판단했다면, API 비용 상한을 5$로 늘리고 구독료도 12.5$로 올릴 수 있다. 이 경우 소비자가 납득하지 못한다면 매출과 순익 모두 줄어들 것이고, 가격 저항을 이겨냈다면 매출과 순익 모두 늘어나고 순익률은 감소할 것이다. 대체로 흔한 일이다.(로켓과 깃털의 로켓)
  - 4. 혹은 API비용 상한을 5$로 늘리고 구독료를 동결할 수 있다. 이 경우 상술한 순익 매트릭스에서 비용 비율만 높아질 것을 예상할 수 있다. 소비자 입장에서는 외관상 차이는 없어 매출에는 영향을 미치지 않을 것이고, 순익과 순익률만 감소할 것이다.
2. 단편 2: API 호출 상한 횟수 유지
  - 5.반면 그만큼의 횟수가 마땅히 필요하다면 비용 상한을 유지하고 구독료만 올리거나 낮출 수 있다. 구독료만 낮추는 경우 상술한 순익 매트릭스에서 매출액 증가와 비용률 상승이 예상된다. 순익률은 줄어들고(매출과 비용률 모두 순익률을 낮춘다) 순익의 추이는 장담할 수 없게 된다. 올리는 경우는 반대로 되지만, 가격 저항 때문에 공공연한 로켓발사대(상향 비용 전가)가 없는 이상 맨 땅에 가격 인상은 보기 어려운 것 같다.

	구독료 변동, 비용률 유지	구독료 동결, 비용률 변동
API 상한 감축	1. 매출액 ↑, 순익 ↑, 순익률 ↓ *하향 비용 전가	2. 매출액 -, 순익 ↑, 순익률 ↑ *Shrinkflation 또는 비용 최적화
API 상한 확대	3. 매출액 ↓↑ , 순익 ↓ , 순익률 ↑↓ *상향 비용 전가	4. 매출액 -, 순익 ↓ , 순익률 ↓ *품질 개선
API 상한 동결	5. 매출액 ↑↓ , 순익 ?, 순익률 ↓↑ *가격 인상/인하	-

이제 장편을 시작하자.

장편 1 : 구독료를 먼저 정하고 API 호출 횟수 계산 : 가격 전략을 우선시하여 먼저 구독료를 잡아 놓고 설계하는 경우를 생각해보자. 감당할 수 있는 기타 비용 비율과 UX의 균형을 찾아 호출 수를 설계할 수 있다.

장편 1을 정리한 표이다 : 구독료에 따른 API호출 상한을 API 매출 비율별로 나열한 뒤, 상한에 따른 적정 월 평균 호출 횟수를 변동 계수에 따라 나열하였다.
편의상 Pro를 기준으로 반올림하여 계산한다. API 비용의 매출 비율은 전체 매출에서 API 비용으로 감당할 수 있는 비율을 의미한다. 맨 우측 값은 정규분포에서 95%의 사용자가 주어진 월 API 상한에서 유효하기 위한 평균값이다

구독료($)	API비용의 매출비율(%)	월 API 상한(회)	적정 월 평균 호출 횟수
변동계수 CV (환산계수 : 0.859, 0.670, 0.549, 0.464)			0.1	0.3	0.5	0.7
2	10	12	10	8	7	6
	20	23	20	15	13	11
	30	35	31	24	19	16
	40	47	40	32	26	22
	50	59	51	40	32	27
3	10	18	16	12	10	8
	20	35	31	24	19	16
	30	53	46	36	29	25
	40	71	61	48	39	33
	50	88	76	59	48	41
4	10	23	20	15	13	11
	20	47	40	32	26	22
	30	71	61	48	39	33
	40	94	81	63	52	44
	50	118	101	79	65	55
5	10	29	25	19	16	14
	20	59	51	40	32	27
	30	88	76	59	48	41
	40	118	101	79	65	55
	50	147	124	99	81	68

월구독료로 3$로, API 비용 비율을 20%로 책정하는 케이스에서 API 호출 상한은 월 35회가, 5$/10%로 책정하면 월 29회가 된다. 된다(파란색)
- API호출의 변동 계수가 평범한 서비스라면 각각 월 평균 API 호출 횟수가 24회, 19회여야 UX와도 균형을 맞는다고 할 수 있을 것이다.
반대로, 월 13~15회의 평균 호출 횟수가 적절하다고 판단된 케이스에서 (구독료, API 비용 비율)의 순서쌍은 (2,20), (4,10), (4,13), (5,10)이 된다. (빨간색)
- API호출의 변동 계수가 평범한 서비스라면 (2, 20), (4, 10)이 괜찮은 순서쌍이 될 것이다.

장편 2 : 적정 호출 횟수 도출 후 구독료 추론 : UX 전략을 우선시하여 사용 경험에 따른 적절한 API 호출 횟수를 먼저 계산하고, 이에 맞추어 통계적으로 감당할 수 있는 범위로 비용을 가두는 방식이다.

장편 2을 정리한 표이다 : 적정 월 평균 호출 횟수에 따른 적정 구독료를 API 매출 비율과 변동 계수별로 나열하였다.
편의상 Pro를 기준으로 반올림하여 계산한다. API 비용의 매출 비율은 전체 매출에서 API 비용으로 감당할 수 있는 비율을 의미한다. 맨 좌측 값은 정규분포에서 95%의 사용자가 주어진 월 API 상한에서 유효하기 위한 평균값이다.

적정 호출 평균 (회/월)	API 비용률 (%)	월 API 상한(좌, 회) 적정 구독료(우, $)
변동 계수		0.1		0.3		0.5		0.7
5	10	6	1.02	8	1.36	9	1.53	11	1.87
	20		0.51		0.68		0.765		0.935
	30		0.34		0.45		0.51		0.623
	40		0.255		0.34		0.383		0.468
	50		0.204		0.27		0.306		0.374
10	10	12	2.04	15	2.55	18	3.06	22	3.74
	20		1.02		1.275		1.53		1.87
	30		0.68		0.85		1.02		1.246
	40		0.51		0.648		0.766		0.936
	50		0.408		0.51		0.612		0.748
15	10	17	2.89	23	3.91	27	4.59	32	5.44
	20		1.445		1.955*		2.295*		2.75*
	30		0.963		1.303		1.53		1.8
	40		0.723		0.978		1.149		1.36
	50		0.578		0.782		0.918		1.08
20	10	23	3.91	30	5.1	36	6.12	43	7.31
	20		1.955		2.55		3.06		3.655
	30		1.303		1.7		2.04		2.467
	40		0.978		1.296		1.532		1.828
	50		0.782		1.02		1.224		1.465
25	10	29	4.93	37	6.29	46	7.82	54	9.12
	20		2.465		3.145		3.91		4.59
	30		1.643		2.097		2.606		3.06
	40		1.233		1.573		1.956		2.298
	50		0.986		1.258		1.564		1.836
30	10	35	5.95	45	7.65	55	9.35	65	11.05
	20		2.975		3.825		4.675		5.525
	30		1.983		2.55		3.117		3.677
	40		1.4875		1.193		2.338		2.758
	50		1.19		1.532		1.87		2.206

적정 월평균 호출 횟수 15회에 API 비용 비율을 20%로 산정하면 적정 구독료는 변동 계수에 따라 1.445~2.72$이 된다 (빨간색)
- API호출의 변동 계수가 평범한 서비스라면 1.995$이 적정 구독료라 할 수 있다.
반대로, 구독료를 2~2.99$로 책정하려는 케이스에서 (월 평균 적정 API 호출 횟수, API 비용 비율)의 순서쌍은 (10, 10), (15, 10), (20, 20), (20, 30), (25, 20), (25, 30), (25, 40), (30, 20), (30, 40)이 된다. (파란색) 다소간의 차이는 포섭하였다.
- API호출의 변동 계수가 평범한 서비스라면 (10, 10), (20, 20), (25, 20), (25, 30), (30, 30)이 괜찮은 순서쌍이 될 것이다.

변동 계수는 평균 대비 변동률로 상대적 표준편차로 요약되는데, 개발자 제어 영역이 아니라 사용자 행동 특성이므로 독립변수로서 다루지 않았다. 일반적으로 0.1은 집약적인 분포, 0.3은 가장 흔한 분포, 0.5부터는 불안정해서 평균과 같은 대표값의 의미가 희석되는 분포이다. ~~정규분포애서 CV=1이면 지랄 하네 그게 랜덤이지 정규분포냐~~
변동 계수는 어플리케이션과 API 각각의 속성, 어플리케이션과 API의 관계에 따라 상이할 수 있다

요약

자동완성 요금을 고려한 비용 최적화
- 정상 종료 : 자동완성 5회까지 Essentials 비용 우위, 이후 Non-Essentials 비용 우위
- 불완전 종료 :자동완성 6~8회 또는 13회부터 정상 종료가 비용 우위(불완전 종료 대응 로직)

Place API 월 제공 횟수 판단 기준(Pro 기준)

무료 : 월 1회당 추가 리텐션 3.5%는 확보해야. 현실적으로 최초메만 제공함이 타당하다.

유료 : API 비용률 [0, 1]에 대해

내용	식	값
API 비용률		0.1	0.2	0.3
구독료 1$당 최대 제공 횟수	58.8 * API 비용률	6	12	18
구독료 1$당 적정 제공 횟수	최대 제공 횟수 * 0.6	4	7	11
적정 제공 1회당 구독료($)	0.0283 / API 비용률	0.283	0.142	0.094
적정 제공 5회당 구독료($)	적정 1회당 구독료 * 5	1.145	0.707	0.472

싱글턴 패턴(Singleton Pattern)의 현 주소

OSP — Wed, 4 Feb 2026 22:06:08 +0900

싱글턴 패턴(Singleton Pattern)의 현 주소

서론
- 더보기
  - 싱글톤 패턴은 개념적으로 단순해 유명한 패턴이기도 하면서, 동시에 개발자 커뮤니티에서는 안티패턴에 가깝게 취급되며 악명이 자자한 패턴이기도 하다. 이 글은 이런 부정적 평가의 이유를 분석하려는 의도에서 시작한다.
  - 우선 싱글턴 패턴 자체의 기원적 정의에 대해 알아본다. 이후 현대적 개발환경에서 싱글턴이 어떻게 재해석되고 있는지 살펴보며, 이 과정을 통해 "싱글톤이 왜 불편한가?"라는 질문에 답해본다.
싱글턴
- 기원적 정의 : 유일성 + 전역성
- 더보기
  1. 싱글톤의 정의는 다음과 같다.(Design Patterns, GoF, 1994)
    
    Ensure a class has one instance, and provide a global point of access to it.
  2. 기원적으로 싱글턴은 단일인스턴스보장과 전역진입점제공이라는 두 요소로 정의된다.
    
    첫번째 요소는 비교적 직관적이며, 그 구현도 비교적 쾌적하다. 생성자를 외부에 노출하지 않아(private), 클래스 내부에서 인스턴스를 하나만 생성하도록 강제함으로써 객체의 개수를 통제한다. 이는 패턴의 의도를 코드레벨 이전의 언어 차원에서 고정시킨다.
    
    두번째 요소가 더 중요하면서도 논쟁적이다. 싱글턴은 단일 인스턴스를 의미 있는 사용을 위해 어디서든 접근 가능한 하나의 진입점을 제공한다. static getInstance() 같은 형태로 구현되며, 이는 사실상 전역 접근 수단이다.
  3. 이 패턴은 설정 객체, 로깅 시스템, 하드웨어 자원관리자처럼 여러 개가 존재할 필요가 없는 대상을 표현하는데 사용되었다. 개념적으로 유일해야 하는 존재, 통제되는 전역 상태를 겨냥한 패턴이다.
    
    사용례가 암시하듯 싱글턴패턴이 겨냥하는 대상은 개념적으로 유일하기만 해서는 안 되고, 일관성도 갖추어야 한다. private 생성자로 단일인스턴스를 보장하고, 흩어져있지 않고 단일한 진입점으로 대상에 데이터 일관성을 해결하려는 의도로 보인다.
    
    문제는 이 전역성이 내포한 구조적 위험에 있다. GoF시기에는 개발효율보다 자원효율을 중시하던 시대였기 때문에, 유일한 자원의 관리라는 장점이 더 크게 평가된 것으로 보인다..
- 현대적 접근 : 전역성 기피
- 더보기
  1. 현대 싱글턴 설명에서는 전역접근이라는 표현이 자주 실종된다. GoF 이후에 싱글턴패턴을 새로이 정의했다는 것은 찾아볼 수 없었다. 개발자들 행동패턴상 주도적으로 새로 정의하는 것은 쉽지 않고, 소극적인 해결책으로 불편한 요소를 의도적으로 희석하는 것으로 보인다. 이 배경에는 몇가지 흐름이 있다.
    
    개발 효율을 높게 평가하는 현대 프로그래밍에서는 테스트 가능성과 의존성 명시가 중요하다. 그러나 전역성은 테스트 순서에 따라 결과가 달라지게 만들어 단위테스트(Unit Test)의 독립성을 거의 즉사시킨다. 또한 전역이라 인자로 받지 않아도 바로 호출할 수 있으니 의존성이 코드 밖에 숨어버린다.
    
    둘째로 DI(Dependency Injection)컨테이너가 일반적으로 보급되었다. 개발자는 더이상 getInstance()를 호출하지 않고 프레임워크가 객체를 주입해준다. 이 과정에서 전역접근이라는 독소조항은 프레임워크 내부로 숨겨지고, 단일 인스턴스라는 목적만 취할 수 있게 되었다.
    
    또 현대에서는 JVM의 JMM(Java Memory Model)은 데이터 일관성을 위한 규칙을 언어 차원에서 지원한다. 따라서 데이터 일관성을 위해서 단일 인스턴스에 더해 "A" Global Access/전역성까지 채택할 이유는 약해진 반면 구조적 위험은 여전히 짊어지고 있는 셈이 된 것.
  2. 다양한 배경들로 현대에서 싱글턴을 냄새나는 존재로 취급하는 장면은 약간 밈처럼 느껴지기도 한다.(실제로 code smell, stink라 표현한다) 다만 싱글턴의 악명은 싱글턴 자체라기 보다는, 전역성이라는 일 요소에서 기인한 것으로 보인다. 전역성은 코드를 엄청나게 큰 머리카락 공으로 만들어 버린다.
정리
더보기
- 범인은 싱글턴이 아니라 전역성
- 근데 이제 안 그래도 이미지 별로였는데 더 개선된 것까지 나와서 이걸 계속 써야 하나 싶은 약간 그런

WebRTC(Web Real Time Communication)

OSP — Tue, 3 Feb 2026 17:37:54 +0900

WebRTC(Web Real Time Communication)

webRTC
- 개관
- 더보기
  - WebRTC는 브라우저간 플러그인 없이 저지연 실시간 P2P통신을 가능하게 하는 표준 기술/API이다. 화상통화, 음성통화, 파일전송, 실시간 데이터교환 등 다양하게 활용되고 있다. 현재는 Web/모바일/데스크톱에서도 지원되는 크로스플랫폼 기술이다.
  - 이를 활용한 서비스로는 대표젹으로 디스코드가 있다.
- 특징
- 더보기
  - 서버를 최소화할 수 있다. 설계상 서버리스P2P통신을 지향하는 것으로 보이나, ISP 관리환경 내에서 안정적인 서비스를 위해 서버는 두되 그 개입을 최소화하려는 것으로 보인다.
    
    이런 맥락에서 WebRTC는 사용자들에게 서버를 전가하지 않기 때문에, 분산네트워킹을 뜻하는 전통적인 의미의 P2P통신과는 아예 거리가 멀다. 반면 일상적으로 연상되는 P2P 이미지는 직접연결로, WebRTC가 분명 이에 더 가깝다. 사견으로 전통적 P2P는 거의 사기에 가까운 네이밍이라 본다. 이질적인 정의를 머릿속에 한땀한땀 입력한 사람을 제외하면, 분산 네트워킹을 떠올리며 P2P를 찾는 사람은 상상하기 어렵다. 이런 용어와 인상의 혼잡은 사람을 그 맥락과 오래 함께한 사람을 제외한 많은 이들을 혼란에 빠뜨린다.~~말똑바로안해?~~
  - 그리고 저지연(Low-Latency)이 상당히 두드러지는 특성이다. 최적의 환경에서는 실시간에 가까운 지연 시간을 보여준다. 또한 대체로 많은 부분이 표준화되어 제공되기 때문에, 개발자 입장에서 신경쓸 부분은 많지 않다. 사용자 개발자 모두 쾌적하다. 시그널링과 랜더링은 신경써야 한다.
  - 다만 모바일-모바일간 UDP Hole Pucnhing 성공률이 보장되지 않아 결국 TURN으로 가고, 이는 WebRTC를 사용하는 목적과 벗어나는 결과를 초래한다.
- 연결수립과정
  - 시그널링(Signalling) - NAT Traversal - 연결수립 - 데이터 전송
  - 더보기
    시그널링은 두 피어가 실제로 데이터를 주고받기 전에 서로 어떤 방식으로 통신할 수 있는지를 합의하기 위한 사전 협상단계라고 볼 수 있다. 이 단계에서는 미디어 종류, 지원 코덱, 암호화 방식, 네트워크 후보 정보처럼 연결에 필요한 메타데이터가 교환된다. WebRTC표준은 시그널링 방식 자체를 정의하지 않기 때문에 개발자는 WebSocket, HTTP, MQTT등 임의의 서버 기반 채널을 선택해 구현해야 한다.
  - 더보기
    NAT Traversal은 사설 네트워크나 이동 통신망 뒤에 있는 두 피어가 직접 연결될 수 있도록 경로를 탐색하는 과정이다. 대부분의 클라이언트는 NAT나 방화벽 내부에 위치해 있어 외부에서 직접 접근이 불가능하며, WebRTC는 이를 전제로 설계되어 있다. STUN(Session Traversal Utilities for NAT)서버를 통해 각 피어는 외부에서 자신이 식별되는 IP/포트를 확인하고 ICE(Interactive Connectivity Establishment)프레임워크를 통해 가능한 네트워크 경로를 수집/비교한다. ICE 프레임워크가 확보하는 후보는 다음과 같다.
    
    직접 연결 탐색 : STUN에서 드러난 IP/포트로 UDP Hole Punching으로 직접 연결. STUN 서버가 연결을 최초에 중계하게 되면 각 호스트의 NAT입장에서는 사설 단말이 앞서 요청을 보냈고, 이에 대한 응답을 받는 셈이 된다. 따라서 이후의 INBOUND패킷들을 허용하게 되고, 여기서부터는 서버가 없어도 통신이 가능해진다. 단 NAT 정책이 엄격한 경우 그렇지 않을 수 있다.
    
    기타 경로 우선순위 탐색
    
    TURN(Traversal Using Relays around NAT) fallback : 안 되면 서버가 중계
  - 더보기
    연결 수립(Connection Establishment) 은 NAT Traversal 과정에서 수집된 여러 후보 경로 중 실제로 사용할 하나의 통신 경로를 선택하고, 이를 안전한 연결로 확정하는 과정이다. ICE는 각 후보 경로에 대해 연결 가능성을 테스트한 뒤, 가장 안정적이고 우선순위가 높은 경로를 선택한다. 이후 선택된 경로를 기반으로 DTLS(Datagram Transport Layer Security) 핸드셰이크가 수행되며, 이 단계에서 암호화/보안 설정이 이루어진다. WebRTC에서는 암호화가 선택 사항이 아니라 필수이기 때문에, 이 단계가 완료되기 전에는 어떤 데이터도 전송될 수 없다. 연결 수립이 완료되면 두 피어는 논리적으로 하나의 지속적인 세션을 공유하게 되며, 이후 데이터 전송은 이 세션을 통해 이루어진다.
    
    WebRTC는 연결 상태를 자체적으로 계속 확인한다. 연결 상태 변동에 따라 직접연결에서 중계연결로 강등되기도, 중계연결에서 직접연결로 승격되기도 한다. 이 경우에도 TURN은 보충적으로 기능한다.
    
    여기서 P2P연결의 재미있는 점은 서버가 죽어도 그것을 이유로 통신이 끊기지는 않는다는 점이다. 서버가 죽어도 이와 무관하게 P2P연결은 유지된다. 다만 네트워크 핸드오버(Network Handover) 등 서버 외적인 이유로 통신이 끊길 수 있고, 그 때 연결 재수립이 불가능해질 뿐이다. 반면 TURN fallback 환경에서는 서버가 죽으면 당연히 통신이 끊긴다.
  - 더보기
    데이터 전송 단계(Data Transfer)는 실제 음성, 영상, 또는 애플리케이션 데이터가 피어 간에 교환되는 단계다. 음성과 영상 데이터는 SRTP(Secure Real time Transport Protocol)를 통해 전송되며, 지연을 최소화하기 위해 일부 패킷 손실을 허용하는 방식으로 처리된다. 애플리케이션 데이터는 DataChannel을 통해 전달되며, 이는 SCTP를 기반으로 하여 신뢰성과 순서를 선택적으로 조절할 수 있다. 이로 인해 WebRTC는 실시간 게임 상태 동기화처럼 빠른 응답이 중요한 경우와, 메시지 전달처럼 신뢰성이 중요한 경우를 모두 지원할 수 있다. 데이터 전송은 연결 수립 단계에서 확정된 단일 경로를 따라 이루어지며, 해당 경로가 TURN 서버를 포함하는 경우에는 모든 데이터가 서버를 경유하게 된다. 따라서 이 단계에서의 성능과 비용 특성은 앞선 NAT Traversal 결과에 직접적으로 의존한다.
정리
- 더보기
  - WebRTC는 STUN 서버의 도움을 받아 NAT를 통과한 뒤, 가능한 경우 단말 간 직접 연결을 맺어 저지연 통신을 수행하는 P2P(직접연결) 통신 기술이다.
  - 안 되는 경우 보충적으로 TURN서버로 중계(Relay)한다.

서버리스 P2P통신(Serverless Peer to Peer Communication)의 한계

OSP — Tue, 3 Feb 2026 16:02:45 +0900

서버리스 P2P통신(Serverless Peer to Peer Communication)의 한계

서론
- 더보기
  - 이 글은 서버 없이 P2P통신을 기반으로 어플리케이션을 만들어 보려는 의도에서 시작한다. 테스트버전으로 실험해보기도 좋고, 안정성 흠결이 크지 않다고 판단한 경우 간결한 어플리케이션 론칭을 열어둘 수도 있다는 마음에서 시작했다.
  - 서버리스 P2P 통신이란 무엇인지, 서버-클라이언트 모델을 살펴보며 서버리스 P2P통신이 제한되는 방향으로 발전되었음을 살펴본다. 이후 NAT(Network Address Translation)에 따라 서버리스 P2P통신이 제한되는 방식을 알아본다.
서버리스 P2P 통신과 서버-클라이언트 모델(Server-Client Model)
- 더보기
  - P2P통신은 A와 B의 사이에 중앙형 서버를 매개로 두지 않고 이루어지는 통신을 의미한다. P2P 통신의 핵심은 토폴로지상 중앙형 서버가 없어 각각의 통신 단말이 서로 대등하다는 것이다.
    
    P2P라는 상호 직접적, 중간매개없음이라는 인상을 주기 쉽다. 그러나 IT에서 P2P의 정의는 분산네트워킹이고, 직접적이라거나 매개 없음을 의미하지 않고 단지 중앙집중형 매개가 없음을 의미할 뿐이다. 그리고 뒤에서 살펴보겠지만 P2P통신의 경우에도 서버로 기능할 무언가는 있어야 한다. 이런 혼동에서 자유롭고자 이 글에서는 서버의 부재 환경을 확실히 하기 위해 서버리스P2P란 표현을 사용했다.
  - 서버-클라이언트 모델은 현대 어플리케이션의 범용 구조이다. 서버(Server)는 편의기능(Service)를 제공하는 단말을 의미한다. 클라이언트는 서버에 서비스를 요청(Request)하는 주체, 서버는 요청에 응답(Response)하여 서비스를 제공하는 주체이다. 이 모델의 핵심적인 특징은 둘을 서로 대등하지 않게 본다는 것이다. 서버는 외부 요청에 열려있어야 하고, 클라이언트는 선수적으로 열어둘 필요는 없다.
  - 온라인 메신저, 게임 등 엔드포인트 단말간 데이터를 주고 받아야 하는 대부분의 앱은 A - 서버 - B와 같은 형태로 서버를 매개로 한다. 이는 서버가 우체국/택배회사 같은 기능을 담당하는 것이다. 경제원리적으로 비용와 생산성 모두 잡을 수 있으니까 이것이 가장 보편적인 건 이해 되는데, 직접 전달을 제한까지 하는 이유는 무엇일까?
    
    앞서 클라이언트는 외부 요청에 열려 있을 필요가 없다 했는데, 한 발 더 나아가 외부 요청에 닫혀 있을 필요가 화두로 떠오른다. 보안문제 때문이다. 요청한 단말에 서비스를 제공하기만 하면 되는 건데 단말에 굳이 접근할 이유가 없다는 것이다.
    
    문제는 요청과 응답의 본질이 모두 동일함에 있다. 요청과 응답으로 개념적으로 분리해내긴 했지만 그 본질은 데이터 제공으로 동일하다. 응답이라는 이름만 붙이고 사실상 요청을 하는 형태로 우회되기 쉽다. 시스템이 선의에 의존해서는 안 되는 것이고, 구조적인 해결책이 필요했다.
NAT(Network Address Translation)로 구현된 서버-클라이언트모델
- 더보기
  1. NAT란 공인IP(Public/Global IP)와 사설IP(Private IP)를 매핑하는 기술이다. 공인IP는 세계에서 유일한 IP주소, 사설IP는 공인IP 내부에서만 유일하면 되는 IP주소이다.
  2. 기원적으로 이는 IPv4의 주소 부족 사태를 해결하기 위한 기술적 수단이었다. 그러나 상태기반 트래픽 제어로 기능함을 깨닫게 되면서 현대적으로 사실상 보안 메커니즘으로 기능하게 되었다.
    
    첫번째 이유로 사설IP는 DHCP(Dynamic Host Configuration Protocol)에 따른 동적 IP를 할당을 디폴트로 채택하고 있기 때문에 외부에서는 안정적인 주소 확보가 어렵다는 점이고,
    
    무엇보다도 현대 NAT 기술이 데이터흐름을 일방향적으로 제한할 수 있도록 설계되었다는 점에 있다. 비기업 회선에 대한 INBOUND패킷은 매핑되는 OUTBOUND패킷이 존재할 때만 허용한다. 가정용IP는 INBOUNT패킷을 제한하고, 기업용IP는 제한하지 않는다. 이렇게 서로 대등하지 않은 관계를 구현해내는 것이다. 참고로 모바일 데이터도 마찬가지이다(CGNAT, Carrier Grade NAT). 서버와 클라이언트는 물리적인 컴퓨터 시스템에 따른 구분이 아니라, 접근정책에 따른 구분이라 보는 것이 더 정확하다. 다모아에서 서버컴퓨터를 구매해도 가정용 회선 연결하면 서버로 못 쓴다. 반면 가정용 데스크톱도 기업용 회선 연결하면 서버로 쓸 수 있다.
  3. 여기에서 서버리스 P2P통신의 한계가 발생한다. A단말과 B단말이 통신하는 과정은 데이터 전달의 반복이고, 현대 서버-클라이언트 모델로 해석하자면 요청과 응답의 반복이다. 서버리스 P2P통신은 비기업용 단말간 통신을 염두에 둔 표현이다. 따라서 둘 다 상대방에게 요청은 할 수 있는데, 상대방의 요청을 받을 수는 없는 입장이라 요청을 보내고 마냥 기다리게 된다.
분산형 네트워크(Distributed Network)의 환상
- 더보기
  1. 어느순간부터 분산형이라는 표현을 전면에 내세우는 기술들이 많이 생겼다. 공격적인 케이스에서는 서버가 없다는 표현을 쓰기도 한다. 분산형이라는 이름, 서버가 없다는 표현, P2P라는 표현 등이 버무려지면서 P2P=서버리스라는 인상을 주기도 한다. 그러나 앞서 NAT에서 보았듯 P2P 통신 제한은 ISP정책상의 한계이며, 비기업 회선 이용자간 통신에는 서버가 필요하다. 보안정책을 채택하지 않는 통신사를 새로 설립하지 않는 이상 말이다.
  2. 살펴보건대, 분산형 네트워크에서 서버가 없다는 표현은 운영자 측의 단일운영주체/단일장애점으로서 중앙서버가 없다는 의미로 이해된다. 대신 서버 역할을 사용자중 누구나 맡을 수 있게 열어둔다. 서버가 없다는 것은, 자리가 비었으니 사용자 누구라도 기업 회선을 받아 서버 역할에 참여할 수 있다는 사용자 개입을 의식한 표현으로 보인다. 그리고 그 비용을 비트코인/이더리움 등으로 보상해주겠다는 게 블록체인 생태계이다. 포스트-SKT 사업자모집 광고와 흡사하다.
  3. 결과적으로 블록체인을 필두로 하는 분산형 생태계는 투자금으로 운영되며, 레거시 보안정책에서 자유로운 신규 ISP처럼 기능한다. 이게 앞으로 어떤 방향으로 전개될지는 모르겠다. 넥스트ISP 인가 싶기도 하고, 보안정책과 기지국을 생각하면 바퀴 재발명의 길인가 싶기도 하다.
대안
- 더보기
  - 서버리스P2P는 ISP정책상 제한됨을 알아보았으니, 그 대안을 살펴보자.
    
    WebRTC(Web Real Time Communication) : 브라우저간 플러그인 없이 저지연 실시간 P2P통신을 가능하게 하는 표준 기술/API로, 현재는 Web/모바일/데스크톱에서도 지원되는 크로스플랫폼 기술이다.
    
    서버를 두되, 그 개입을 최소화하는 방식. 다만 모바일에서는 UDP Hole Punching으로 인한 통신이 보장되지는 않기 때문에 결국에는 레거시한 데이터 릴레이 방식으로 귀결될 수 있다. 서버를 어디까지나 보험으로 두겠다는 의도라 볼 수 있다.
    
    libp2p/bittorrent : 분산네트워킹기술
    
    내 서버를 사용자들의 서버로 대신하는 방식. 생태계가 충분히 커야 유의미하며, 서버를 부담하는 이들에 대한 보상을 생각해야 한다.
    
    동일Wifi, Wifi-Direct, Bluetooth, NFC
    
    디바이스 자체의 통신 기능을 이용하는 방식. ISP 정책을 벗어나 비기업 단말에 대한 선수적 데이터 제공이 가능하다.(아이폰은 제한) 아무래도 가장 큰 병목은 거리 의존성이다.
정리
- 더보기
  1. 서버-클라이언트 모델은 ISP의 운영정책(NAT/CNAT로 INBOUND 제한 허용)으로 구현된다.
  2. 따라서 비기업 단말은 요청을 받을 수 없기 때문에, ISP생태계에서 서버리스P2P 통신은 구조적으로 제한된다.
  3. 즉 서버리스P2P 통신의 한계는 네트워크 기술의 한계라기 보다는 ISP 관리영역 안에서의 한계다.
  4. 분산형 네트워크는 서버리스P2P통신기술이 아니라 신규 ISP사업에 가깝다.
  5. 서버를 두되 최소화 하거나, 사용자에게 서버를 전가하거나, ISP정책 외 통신 기능을 이용하는 대안이 있다.

모델에 따른 1$당 LLM 호출 횟수 축약
초가성비 모델	일반 모델	고급 모델	초고급 모델(GPT Only)
500회+	100회	50회	4회

구글 클라우드 스토리지 계층구조
Storage	Projcet	Bucket*	Folder	File / Object

유형	비용 시나리오	핵심 비용 요소
업로드	저장료 + 운영료 + 복제료	복제료/저장료
다운로드	운영료 + 검색료 + 전송료	전송료

Essentials	z=y (0.005+0.00283((x+12-abs(x-12))/(2)))+(1-y)0.00283*x
Pro	z=y0.017+(1-y)0.00283*x
Enterprise	z=y0.020+(1-y)0.00283*x
Enterprise + Atmosphere	z=y0.025+(1-y)0.00283*x