사용자 한 명이 늘 때 드는 비용부터 계산하는 법

작은 앱을 만들면 전체 서버비나 월 매출부터 봐야 할 것 같지만, 초기에는 “한 명이 더 쓰면 얼마가 더 들까”를 묻는 편이 실용적입니다. 사용자가 늘어도 비용이 거의 안 늘 수 있고, 반대로 AI 생성이나 영상 변환처럼 실행할 때마다 비용이 붙는 기능도 있습니다.

작은 음식점에서 한 그릇을 더 팔 때 재료와 용기가 얼마나 더 필요한지 보는 상황을 생각해 보세요. 가게 보증금과 냉장고 값은 한 그릇이 더 팔렸다고 바로 늘지 않지만, 재료와 포장비는 대체로 늘어납니다. 앱도 같은 방식으로 나누면 무료 사용자를 어디까지 받을지, 유료 기능은 무엇을 감당해야 하는지 보이기 시작합니다.

계산할 단위를 하나로 정한다

단위 경제성의 단위는 비용과 가치를 반복해 비교할 기준입니다. 사용자 한 명, 주문 한 건, 완성된 보고서 한 개, 변환된 영상 한 편이 될 수 있습니다. 단위가 다르면 수익과 비용을 한줄에 비교할 수 없으므로 먼저 사용자가 얻는 결과에 가까운 단위 하나를 고릅니다.

예를 들어 이미지 한 장을 만들고 저장하는 도구라면 “가입자 한 명”보다 “완료 이미지 한 장”이 비용을 더 잘 설명할 수 있습니다. 가입만 하고 사용하지 않는 사람과 매일 열 장을 만드는 사람은 비용 구조가 다르기 때문입니다.

고정비와 변동비를 나눈다

고정비는 짧은 기간에 사용량이 좀 바뀐다고 바로 늘지 않는 비용입니다. 도메인 연간 비용, 이미 결제한 디자인 도구, 최소 서버 기본요금이 여기에 가까울 수 있습니다. 변동비는 사용량이 늘 때 함께 늘어나는 비용으로, API 호출, 결제 수수료, 대용량 저장과 전송비가 해당할 수 있습니다.

다만 서비스 요금제에 따라 경계가 달라집니다. 기본 포함량까지는 요금이 같다가 일정 사용량을 넘으면 추가 비용이 붙을 수 있습니다. 그래서 가격표를 외워 분류하기보다 실제 청구서의 비용 항목과 사용량 기록을 같이 보는 편이 안전합니다. Google Cloud는 제공 비용뿐 아니라 운영과 관리 비용까지 포함한 전체 비용을 보도록 안내합니다.

단위당 수익과 비용을 같은 표에 둔다

수익과 비용의 기간과 단위를 맞추어야 합니다. 한 달 매출과 하루 API 비용을 바로 빼거나, 사용자 한 명의 결제와 전체 회원의 저장 비용을 비교하면 결과를 해석하기 어렵습니다. AWS 문서가 워크로드의 비용과 사업 출력을 함께 측정하라고 안내하는 이유도 돈이 쓰인 결과를 같은 기준에서 보기 위해서입니다.

아래는 실제 요금이 아니라 계산 방법만 익히기 위한 가상 예시입니다.

단위: 완료 보고서 1개
단위당 결제 수익: 1,000원
결제 처리 비용: 40원
외부 API 비용: 120원
저장과 전송 비용: 20원
단위당 남는 금액: 1,000 - 40 - 120 - 20 = 820원

이 820원은 회사의 최종 이익이 아닙니다. 아직 인건비, 세금, 고정비, 환불, 미결제, 고객 지원 비용 등이 남아 있습니다. 작은 서비스에서는 이 숫자를 “한 건을 더 제공할 때 발생하는 통제 가능한 차이”로 읽는 것이 적절합니다.

예상치와 실제 측정값을 나눈다

가격표로 만든 예상치는 시작점일 뿐입니다. 사용자마다 요청 길이와 저장 기간이 다르고, 재시도와 실패도 비용을 만들 수 있습니다. 일정 기간 테스트 사용량을 기록한 뒤 완료 건수로 나누어 실제 단위당 비용을 만듭니다. 실패한 요청을 분모에서 지워 성공한 건만 싸게 보이게 하면 안 됩니다.

• 예상 비용과 실제 청구 비용을 다른 칸에 적습니다.
• 시도 횟수, 완료 횟수, 실패 횟수를 따로 세어 봅니다.
• 다시 처리한 요청과 환불된 결제를 표시합니다.
• 한 사용자가 많은 단위를 쓰는지 분포를 보조 지표로 봅니다.
• 월별 가격표와 할인 크레딧이 바뀌었는지 확인합니다.
• 숫자를 확인한 날짜와 기간을 함께 기록합니다.

여기서 제거해야 할 것은 이상치가 아니라 원인을 모르는 숫자입니다. 특정 날 비용이 커졌다면 사용자 증가, 재시도 반복, 저장 기간, 비정상 요청 중 무엇과 연결됐는지 찾아야 합니다.

무료 범위와 가격은 단위 비용 뒤에 정한다

무료 제공은 무조건 손해라는 뜻이 아닙니다. 사용자가 핵심 가치를 확인할 수 있고, 운영자가 그 범위의 변동비를 감당할 수 있다면 유용한 시작점이 됩니다. 다만 건당 비용이 큰 기능을 무제한으로 열어 두고 사용자 수만 보면 성장할수록 위험해질 수 있습니다.

매일 무료 작업 횟수, 최대 입력 크기, 저장 기간 같은 경계를 하나씩 시험합니다. 가격은 단위당 비용만으로 정하지 말고 제품이 주는 가치, 지원과 개발 비용, 세금과 환불 조건까지 함께 검토합니다. 단위 경제성은 가격을 자동으로 정해 주는 공식이 아니라 안전한 선택 범위를 줄여 주는 장부에 가깝습니다.

비밀키와 결제 설정은 계산표 밖에 둔다

비용을 모은다고 API 비밀키, 결제 수단, 전체 영수증, 사용자 식별자를 공유 문서에 붙이면 안 됩니다. 작업 건수와 비용을 연결할 때도 개인을 바로 알아볼 수 없는 내부 번호를 쓰고, 원본 청구 자료는 권한이 제한된 저장소에 둥니다.

가격표나 청구 설정을 바꾸는 명령은 의미와 영향 범위를 모르면 실행하지 마세요. 삭제, 해지, 예산 상한 변경은 서비스를 멈추거나 자료를 잃게 할 수 있으므로 대상 계정, 현재 설정, 적용 시각, 되돌릴 방법을 먼저 확인합니다. 비용 추정치만 보고 유료 계획을 취소하거나 사용자의 기능을 닫지 않습니다.

오늘 바로 해볼 작은 실습

실제 결제나 설정 변경 없이 종이나 빈 표에서 10분 안에 해볼 수 있습니다.

1. 내 서비스의 결과를 사용자, 주문, 완료 작업 중 하나로 정합니다.
2. 그 단위가 하나 늘 때 더 쓰이는 호출, 저장, 전송, 결제 항목을 적습니다.
3. 도메인과 기본 도구 요금처럼 바로 늘지 않는 항목을 다른 칸으로 옮깁니다.
4. 모르는 금액은 상상해 채우지 말고 “미확인”으로 둡니다.
5. 최근 청구서와 사용량 화면에서 비밀값이 아닌 합계만 확인합니다.
6. 예상치와 실제치 차이를 다음 한 주 동안 기록할 칸을 만듭니다.
7. 가격이나 무료 범위를 바꾸기 전에 더 확인할 숫자 하나를 정합니다.

실습의 목표는 정확한 이익을 단번에 맞추는 것이 아닙니다. 한 단위가 늘 때 어떤 비용이 움직이는지, 어떤 숫자가 아직 없는지를 보이게 만드는 것입니다. 다음 주에 같은 단위로 다시 계산해야 비용이 줄었는지, 사용자 가치를 해치지 않고 지속할 수 있는지 비교할 수 있습니다.