초기 SaaS 운영비 산정 가이드: MVP 개발비 이후 매달 나가는 비용을 어떻게 예측할까
정답부터 말하면, 초기 SaaS 운영비는 서버비 한 줄로 잡으면 안 됩니다. MVP 개발비와 별도로 월 반복 비용을 기본 인프라, 사용량 변동비, 외부 API, 운영 인력, 유지보수, 예외 대응으로 나누고, 최소·기준·성장 시나리오를 만들어야 합니다. 정부지원사업 예산계획에서는 더 중요합니다. 협약 기간 안에서 집행 가능한 비용과 출시 후 회사가 직접 부담해야 할 런웨이를 분리하지 않으면, 개발 완료 후 서비스는 열렸는데 운영비가 빠진 계획서가 됩니다.
초기 창업팀이 자주 놓치는 지점은 개발 견적이 ‘무엇을 만들 것인가’에 집중한다는 점입니다. 반면 SaaS 운영비는 ‘만든 것을 몇 명에게, 어느 수준으로, 얼마나 안정적으로 제공할 것인가’의 비용입니다. 기능 수가 적어도 파일 업로드가 많거나, 고객사별 데이터 분리가 필요하거나, AI API 호출이 잦거나, 유료 고객에게 장애 대응을 약속하면 월 비용 구조가 달라집니다.
1. MVP 개발비와 SaaS 운영비는 다른 예산입니다
MVP 개발비는 대체로 기획, UI, 프론트엔드, 백엔드, 관리자 화면, 배포 초기 설정처럼 한 번 만드는 비용입니다. 운영비는 매달 반복됩니다. 서버, 데이터베이스, 백업, 로그, 모니터링, 보안 패치, 고객문의, 장애 대응, 외부 API 사용료가 여기에 들어갑니다. 그래서 개발비가 합리적이어도 운영비가 비현실적이면 출시 후 3개월 안에 의사결정이 꼬일 수 있습니다.
| 구분 | 개발비에 가까운 항목 | 운영비로 따로 봐야 하는 항목 |
|---|---|---|
| 목적 | 제품을 처음 구현하고 검수하기 | 서비스를 계속 제공하고 장애를 줄이기 |
| 발생 방식 | 프로젝트 단위, 마일스톤 단위 | 월 반복, 사용량 증가에 따라 변동 |
| 대표 항목 | 기능 개발, 화면 구현, API 개발, 관리자 기능 | 클라우드, DB, 백업, 모니터링, 보안 업데이트, 고객지원 |
| 위험 | 범위 증가, 일정 지연, 검수 기준 불명확 | 트래픽 증가, 외부 API 과금, 로그 폭증, 장애 대응 부재 |
개발 범위 자체를 아직 정리 중이라면 먼저 MVP 개발 기간·비용 추정 가이드처럼 기능 단위의 크기를 나눈 뒤, 각 기능이 어떤 운영비를 만든다는 관점으로 이어가야 합니다. 예를 들어 채팅 기능은 화면 개발비뿐 아니라 메시지 저장량, 알림 발송, 실시간 연결, 악성 사용자 대응 비용을 만듭니다.
2. 초기 SaaS 운영비의 8가지 비용 항목
아래 표는 실제 산정표를 만들 때 기본으로 넣어야 할 항목입니다. 금액은 클라우드 사업자, 리전, 사용량, 계약 조건, 아키텍처에 따라 달라지므로 특정 단가를 외워서 적용하기보다 ‘무엇이 비용을 움직이는지’를 먼저 정리해야 합니다.
| 비용 항목 | 무엇에 따라 변동되나 | 초기 팀이 놓치기 쉬운 점 | 산정 방법 |
|---|---|---|---|
| 애플리케이션 서버 | 요청 수, 동시접속, 실행 시간, 배포 환경 수 | 운영 환경만 보고 스테이징·테스트 환경을 빼는 경우 | 월 가동 시간, 최소 인스턴스, 피크 대응 방식을 정한다 |
| 데이터베이스 | 저장 용량, 읽기·쓰기 빈도, 백업, 복제 구성 | 초기에는 작아 보여도 로그성 데이터가 빠르게 늘어남 | 테이블별 월 증가량과 보관 기간을 추정한다 |
| 스토리지·CDN·트래픽 | 파일 업로드, 다운로드, 이미지·영상 제공량 | 업로드보다 다운로드와 외부 전송 비용을 과소평가 | 파일 1개 평균 크기, 사용자당 월 다운로드 횟수를 둔다 |
| 백업·복구 | 백업 주기, 보관 기간, 복구 목표 시간 | 백업은 있는데 복구 테스트가 없는 상태 | 일일·주간 백업, 보관 일수, 복구 리허설 비용을 넣는다 |
| 모니터링·로그 | 로그량, 메트릭 수, 트레이스 샘플링, 알림 채널 | 에러가 났을 때 원인을 찾을 데이터가 부족하거나 반대로 로그 비용이 폭증 | 필수 로그, 보관 기간, 알림 기준을 정한다 |
| 보안·인증 | 인증 방식, 권한 체계, 비밀관리, 감사 로그 | 관리자 계정, API 키, 개인정보 접근 로그를 뒤늦게 보강 | 인증·권한·비밀관리·취약점 패치 주기를 비용에 반영한다 |
| 외부 API·AI·결제·문자 | 호출 수, 토큰 수, 메시지 수, 결제 건수 | 사용자 입력 한 번이 여러 API 호출로 이어지는 구조 | 사용자 행동 1회당 호출량을 계산하고 상한을 둔다 |
| 고객지원·유지보수 | 문의 건수, 버그 빈도, 장애 대응 수준, 기능 개선량 | 대표나 개발자가 임시로 처리하다가 제품 개선 시간이 사라짐 | 월 정기 점검, 긴급 대응, 소규모 수정 범위를 분리한다 |
3. 먼저 운영 가정서를 만드세요
초기 SaaS 운영비 산정의 출발점은 견적서가 아니라 운영 가정서입니다. 견적서에 ‘서버 구축’이라고 적혀 있어도 월간 활성 사용자, 피크 시간대, 업로드 파일 크기, 데이터 보관 기간, 고객사 수, API 호출량이 없으면 비용은 감으로 계산됩니다.
운영 가정서에 들어갈 최소 입력값
- 사용자 가정: 가입자 수, 월간 활성 사용자, 동시접속, 관리자 사용자 수
- 고객사 가정: B2C 단일 사용자 중심인지, B2B 고객사별 테넌트 구조인지
- 트래픽 가정: 사용자 1명당 월 페이지뷰, API 요청 수, 피크 시간대 배율
- 데이터 가정: 고객 1명당 생성 데이터, 파일 평균 크기, 월 증가량, 보관 기간
- 외부 API 가정: 문자, 이메일, 결제, 지도, 인증, AI 모델 호출 횟수
- 운영 등급: 내부 테스트, 무료 베타, 유료 고객, B2B 계약 고객 중 어디에 해당하는지
- 지원 가정: 문의 채널, 응답 시간, 장애 공지 방식, 야간·주말 대응 여부
여기서 중요한 것은 숫자가 틀릴 수 있다는 사실을 인정하는 것입니다. 처음부터 정확한 예측은 어렵습니다. 대신 ‘왜 이 숫자를 넣었는지’를 남겨두면, 출시 후 실제 청구서와 비교해 다음 달 예산을 조정할 수 있습니다.
4. 월 운영비 계산식은 단순하게 시작해도 됩니다
초기에는 복잡한 재무 모델보다 아래 구조가 더 쓸모 있습니다.
월 운영비 = 기본 인프라 + 데이터·트래픽 변동비 + 관측성·보안 비용 + 외부 API 비용 + 고객지원·운영 인력 + 유지보수 + 예비 항목
이때 ‘기본 인프라’는 사용자가 없어도 나가는 비용입니다. 서버 최소 가동, DB 인스턴스, 도메인, 인증서, 모니터링 기본 비용 등이 해당됩니다. ‘변동비’는 사용자가 늘 때 증가합니다. 파일 다운로드, API 호출, AI 토큰, 문자 발송, 로그 저장량이 대표적입니다. ‘사람 비용’은 견적서에서 빠지는 경우가 많지만 실제로는 가장 먼저 병목이 됩니다. 문의 답변, 장애 확인, 버그 재현, 배포 점검은 모두 누군가의 시간입니다.
운영비 산정용 엑셀 컬럼 예시
| 컬럼 | 작성 예시 | 검토 포인트 |
|---|---|---|
| 비용 항목 | DB 백업, 문자 발송, AI 요약 API | 기능이 아니라 과금 단위로 적는다 |
| 단가 기준 | 월 고정, 호출당, GB당, 사용자당 | 공식 단가표 또는 견적 기준을 남긴다 |
| 월 사용량 가정 | 월 20만 호출, 300GB 저장 | 사용자 행동에서 역산한다 |
| 최소 시나리오 | 파일럿 고객 1~2곳 | 서비스 유지에 필요한 최저 비용 |
| 기준 시나리오 | 유료 베타 운영 | 사업계획서의 기본 월 손익에 반영 |
| 성장 시나리오 | 고객사 증가, 데이터 증가 | 투자금·매출·자부담 운영비 계획과 연결 |
| 증빙 자료 | 가격 계산기 링크, 견적서, 청구서 | 정부지원사업이면 정산 가능성을 별도로 확인 |
5. 세 가지 시나리오로 나누면 의사결정이 쉬워집니다
운영비를 한 숫자로 고정하면 논의가 막힙니다. 초기 팀에는 보통 ‘검증형 MVP’, ‘유료 베타’, ‘성장형 SaaS’ 세 장의 표가 필요합니다. 같은 코드베이스라도 운영 약속이 달라지면 비용과 인력이 달라집니다.
| 시나리오 | 상황 | 필수 운영비 | 주의할 결정 |
|---|---|---|---|
| 검증형 MVP | 내부 테스트 또는 소수 파일럿 고객 | 최소 서버, 기본 DB, 짧은 로그 보관, 수동 고객지원 | 무료 티어에 의존하더라도 정상가 기준을 별도로 계산한다 |
| 유료 베타 | 결제 또는 B2B 파일럿 계약이 있는 상태 | 백업, 모니터링, 비용 알림, 장애 공지, 관리자 화면 | 고객에게 약속한 응답 시간과 실제 대응 인력을 맞춘다 |
| 성장형 SaaS | 고객사·사용자·데이터가 반복적으로 증가 | 스테이징 분리, 감사 로그, 권한관리, 복구 훈련, 지원 프로세스 | 아키텍처 확장보다 비용 상한과 사용량 제한을 먼저 둔다 |
초기에는 성장형 구조를 전부 만들 필요가 없습니다. 다만 나중에 반드시 필요해질 운영 항목을 ‘로드맵 밖’으로 밀어두면 안 됩니다. 예를 들어 B2B SaaS라면 고객사별 데이터 분리, 관리자 권한, 감사 로그, 데이터 export 요구가 빠르게 등장합니다. 출시 직후 만들기는 어렵지만, 데이터 모델과 관리자 화면 설계에는 미리 반영해야 합니다.
6. 클라우드 비용은 공식 계산기와 비용 알림을 함께 봐야 합니다
클라우드 비용을 산정할 때는 특정 블로그의 예시 금액보다 공식 가격 계산기를 기준으로 삼는 편이 안전합니다. AWS나 Google Cloud 같은 주요 클라우드 사업자는 워크로드 시나리오와 사용량을 입력해 비용 추정을 만들 수 있는 계산기를 제공합니다. 다만 계산기는 추정 도구입니다. 실제 청구서는 리전, 할인, 약정, 데이터 전송, 로그 보관, 사용량 급증에 따라 달라질 수 있습니다.
- 현재 MVP 아키텍처를 구성요소로 나눈다. 예: 웹 서버, API 서버, DB, 스토리지, 캐시, 메시지 큐, 로그.
- 각 구성요소의 과금 단위를 확인한다. 예: 시간, 요청 수, 저장 용량, 전송량, 사용자 수.
- 최소·기준·성장 시나리오별 사용량을 입력한다.
- 가격 계산기 링크 또는 캡처를 저장하고, 어떤 가정으로 계산했는지 표에 남긴다.
- 출시 전 예산 알림을 설정한다. 50%, 80%, 100%처럼 단계별 알림을 두면 갑작스러운 과금을 빨리 발견할 수 있다.
예산 알림과 청구 모니터링을 어떻게 설계할지는 클라우드 비용 알림 자동화 가이드를 함께 보면 좋습니다. 비용 알림은 비용을 줄이는 기능이 아니라 ‘늦게 발견하는 비용’을 줄이는 기능입니다. 특히 외부 API 키 유출, 무한 재시도, 파일 업로드 오류, 로그 폭증은 하루 이틀 사이에도 청구서를 왜곡할 수 있습니다.
7. AI·외부 API 비용은 사용자 행동 단위로 계산해야 합니다
AI 요약, 문서 분석, 챗봇, OCR, 지도, 문자, 이메일, 결제 API는 모두 SaaS의 변동비를 만듭니다. 초기 팀은 ‘기능 1개’로 보지만 실제 과금은 호출 수, 토큰 수, 이미지 수, 메시지 수, 결제 건수로 발생합니다. 따라서 기능 단위가 아니라 사용자 행동 단위로 계산해야 합니다.
예를 들어 AI 문서 요약 기능이 있다면 단순히 ‘요약 API 사용’으로 적으면 부족합니다. 사용자 1명이 월 몇 개의 문서를 올리는지, 문서 평균 길이는 얼마인지, 요약을 재시도할 수 있는지, 결과를 캐싱할지, 실패 시 다시 호출하는지까지 봐야 합니다. 이런 계산은 LLM API 비용 예측 가이드처럼 토큰·캐싱·레이트 리밋 관점으로 분해하면 훨씬 현실적입니다.
외부 API 비용을 줄이는 설계 질문
- 사용자 1회 행동이 외부 API 몇 번으로 이어지는가?
- 동일 결과를 캐싱하거나 재사용할 수 있는가?
- 무료 사용자와 유료 사용자에게 같은 API 한도를 줄 것인가?
- 실패 재시도 횟수와 타임아웃은 제한되어 있는가?
- 관리자 화면에서 고객별 사용량을 볼 수 있는가?
- API 단가가 바뀌거나 공급사를 바꿀 때 코드 수정 범위는 어느 정도인가?
8. 모니터링·로그·백업은 비용이 아니라 보험에 가깝습니다
모니터링을 빼면 월 비용은 줄어듭니다. 하지만 장애가 났을 때 원인을 찾지 못해 고객 신뢰가 더 크게 손상될 수 있습니다. 관측성은 로그, 메트릭, 트레이스 같은 데이터를 수집해 서비스 상태를 이해하는 운영 체계입니다. 문제는 관측성도 공짜가 아니라는 점입니다. 너무 많이 저장하면 비용이 늘고, 너무 적게 저장하면 장애 분석이 어렵습니다.
| 항목 | 최소 기준 | 초기 SaaS 권장 의사결정 |
|---|---|---|
| 로그 | 에러 로그, 로그인·결제·권한 변경 로그 | 개인정보를 그대로 남기지 않고 보관 기간을 정한다 |
| 메트릭 | 응답 시간, 에러율, CPU·메모리, DB 연결 수 | 장애 알림 기준을 너무 민감하게 잡지 않는다 |
| 트레이스 | 주요 API 요청 흐름 | 전체 수집보다 핵심 경로 중심으로 샘플링한다 |
| 백업 | 정기 백업과 복구 테스트 | 백업 성공 알림뿐 아니라 복구 리허설 일정을 둔다 |
백업은 ‘있다’와 ‘복구된다’가 다릅니다. 정부지원사업 산출물 시연 직전, 유료 고객 온보딩 직전, 대규모 데이터 마이그레이션 전에는 복구 테스트를 운영 일정에 넣어야 합니다. 복구 테스트 시간도 결국 운영비입니다.
9. 정부지원사업 예산계획에서는 집행 가능 비용과 운영 런웨이를 분리하세요
정부지원사업에서 가장 위험한 표현은 ‘출시 후 운영비까지 지원금으로 해결’이라고 단정하는 것입니다. 사업별 공고문, 통합관리지침, 세부관리기준, 협약 기간, 비목 정의에 따라 집행 가능 여부가 달라집니다. 2026년 기준 K-Startup 자료실에도 중소기업창업 지원사업 통합관리지침 개정 안내가 게시되어 있으며, 창업진흥원 사업안내는 초기창업패키지 등이 사업화 자금과 창업프로그램을 제공한다고 설명합니다. 그러나 세부 집행 가능 항목은 반드시 해당 사업 공고와 주관기관 안내를 확인해야 합니다.
| 예산 항목 | 사업계획서에 쓰는 방식 | 주의점 |
|---|---|---|
| MVP 개발 외주 | 기능 범위, 산출물, 검수 기준, 일정과 연결 | 운영·유지보수 포함 여부를 계약서에 분리 |
| 클라우드 사용료 | 개발·테스트·시연·초기 운영에 직접 필요한 기간과 용도 명시 | 협약 기간 밖 장기 운영비, 연간 선결제는 사전 확인 |
| 외부 API | 기능 검증에 필요한 호출량과 단가 기준 제시 | 해외 결제, 환율, 영수증, 사용 내역 증빙 가능성 확인 |
| 유지보수 | 버그 수정, 보안 패치, 배포 점검, 장애 대응 범위 구분 | 신규 기능 개발과 운영성 대응을 섞어 쓰면 검수·정산이 복잡 |
| 출시 후 6개월 운영비 | 자부담 또는 투자금 런웨이 계획으로 별도 표시 | 지원금 집행 가능 비용으로 단정하지 않는다 |
정산 리스크를 줄이려면 예산표에 ‘집행 가능성 확인 필요’ 열을 추가하세요. 특히 SaaS 구독료, 클라우드 크레딧, 해외 API, 연간 선결제, 카드 자동결제, 환불 불가 상품은 담당기관 확인 없이 넣으면 문제가 될 수 있습니다. 증빙은 견적서만으로 끝나지 않습니다. 계약서, 거래명세서, 카드전표, 세금계산서 또는 영수증, 사용량 리포트, 산출물과의 관련성을 함께 남겨야 합니다.
10. 외주 개발 견적을 받을 때 반드시 물어볼 운영 질문
초기 SaaS 견적을 비교할 때 금액만 보면 위험합니다. 한 업체는 기능 개발만 포함하고, 다른 업체는 배포·모니터링·백업·관리자 화면 일부까지 포함할 수 있습니다. 같은 ‘MVP 개발’이라는 표현이라도 운영 포함 범위가 다르면 실제 비용은 다릅니다.
- 운영 서버, 스테이징 서버, 개발 서버 구성이 견적에 포함되는가?
- 클라우드 계정은 누구 명의로 만들고, 결제 권한은 어떻게 인수인계하는가?
- DB 백업 주기와 복구 테스트가 산출물에 포함되는가?
- 장애 알림은 이메일, 메신저, 전화 중 어디까지 설정되는가?
- 로그 보관 기간과 개인정보 마스킹 기준은 정해져 있는가?
- 관리자 화면에서 사용자, 결제, API 사용량, 오류 내역을 확인할 수 있는가?
- 외부 API 키와 DB 비밀번호는 어디에 보관하고 누가 접근할 수 있는가?
- 출시 후 버그 수정과 신규 기능 추가의 기준은 어떻게 나누는가?
- 월 유지보수 계약이 있다면 응답 시간, 긴급 대응, 포함 작업 시간을 어떻게 정의하는가?
- 소스코드, 배포 문서, 환경 변수, 계정 권한, 운영 매뉴얼을 언제 인수인계하는가?
이 질문에 답하지 못하면 출시 후 비용이 ‘예상보다 많이 나왔다’가 아니라 ‘처음부터 예산표에 없었다’가 됩니다.
11. 운영비를 줄이는 것보다 상한을 두는 것이 먼저입니다
초기 SaaS는 비용을 무조건 낮추기보다 비용이 어디까지 올라갈 수 있는지 상한을 정해야 합니다. 예를 들어 파일 업로드 용량 제한, 무료 사용자 AI 호출 제한, 고객사별 저장공간 제한, API 레이트 리밋, 관리자 승인 후 대량 작업 실행 같은 장치가 필요합니다. 비용 상한이 없으면 작은 버그나 악성 사용자가 곧바로 청구서 문제로 이어질 수 있습니다.
특히 AI 기능은 사용자 경험을 위해 재시도와 자동 호출을 많이 넣고 싶어집니다. 그러나 자동 요약, 자동 분류, 자동 추천이 백그라운드에서 반복 실행되면 사용자는 모르는 사이 비용이 발생합니다. MVP 단계에서는 ‘기능 완성도’보다 ‘호출 상한과 실패 시 중단 조건’이 더 중요할 때가 많습니다.
12. AgentMit/BizMit가 도울 수 있는 지점
AgentMit는 단순 개발 견적보다 출시 후 운영 가능성을 함께 봐야 한다는 입장입니다. BizMit 기반의 SaaS, 업무 자동화, 관리자 대시보드, AI 기능, 정부지원사업 MVP를 설계할 때도 기능목록만 보지 않고 트래픽 가정, 데이터 보관, 외부 API 의존도, 배포·모니터링·백업 구조를 함께 검토합니다.
다만 정부지원사업 선정이나 특정 비목 집행을 보장하는 기관은 아닙니다. 창업팀이 해야 할 일은 명확합니다. 사업 공고와 지침을 확인하고, MVP 개발 범위를 정하고, 월 운영비 시나리오를 만들고, 지원금으로 집행할 항목과 자부담으로 운영할 항목을 분리하는 것입니다. 구현 파트너가 필요하다면 AgentMit는 그 다음 단계에서 기능 설계, SaaS 아키텍처, 관리자 화면, 자동화, AI API 비용 통제, 배포·운영 인수인계까지 실무적으로 도울 수 있습니다.
마무리: 운영비 산정은 제품 전략의 일부입니다
초기 SaaS 운영비 산정은 회계 작업처럼 보이지만 실제로는 제품 전략입니다. 어떤 고객에게 먼저 팔 것인지, 무료 사용자를 어디까지 허용할 것인지, AI 기능을 얼마나 자동화할 것인지, B2B 고객에게 어떤 안정성을 약속할 것인지가 모두 월 비용으로 바뀝니다.
오늘 바로 할 일은 복잡하지 않습니다. 첫째, 운영 가정서를 만드세요. 둘째, 8가지 비용 항목을 표로 분해하세요. 셋째, 최소·기준·성장 시나리오를 나누세요. 넷째, 공식 가격 계산기와 예산 알림을 연결하세요. 다섯째, 정부지원사업 예산표에서는 집행 가능 비용과 회사가 부담할 운영 런웨이를 분리하세요. 이 다섯 가지를 해두면 MVP 개발비 이후의 불확실성이 훨씬 줄어듭니다.
참고 자료
- K-Startup 창업지원포털 자료실: 중소기업창업 지원사업 통합관리지침 등 사업별 기준 확인에 참고. ([k-startup.go.kr](https://www.k-startup.go.kr/user/board/webRFRR_list_reference.do))
- 창업진흥원 초기창업패키지 사업안내: 사업화 자금, 창업프로그램, 신청·협약 절차 맥락 확인에 참고. ([kised.or.kr](https://www.kised.or.kr/menu.es?mid=a10205020000))
- AWS Pricing Calculator 및 Google Cloud Billing 문서: 클라우드 비용 추정 방법과 계산기 활용 관점에 참고. ([aws.amazon.com](https://aws.amazon.com/aws-cost-management/aws-pricing-calculator/?track=costma))
- AWS Budgets: 비용·사용량 예산 알림 운영 항목에 참고. ([aws.amazon.com](https://aws.amazon.com/aws-cost-management/aws-budgets/?nc2=h_l3_dm))
- OpenTelemetry Documentation: 로그·메트릭·트레이스 기반 관측성 설명에 참고. ([opentelemetry.io](https://opentelemetry.io/docs/))
- AWS Well-Architected Cost Optimization Pillar: 비용 최적화를 설계와 운영의 문제로 보는 관점에 참고. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html))
자주 묻는 질문
Q1. 초기 SaaS 운영비는 개발비의 몇 퍼센트로 잡으면 되나요?
일률적인 퍼센트로 잡는 방식은 위험합니다. 같은 개발비라도 파일 업로드, AI API, B2B 고객사별 데이터 분리, 로그 보관 기간, 장애 대응 수준에 따라 월 운영비가 달라집니다. 개발비 대비 비율보다 서버·DB·스토리지·백업·모니터링·외부 API·고객지원·유지보수 항목을 따로 계산하고, 최소·기준·성장 시나리오를 나누는 편이 실무적으로 안전합니다.
Q2. 정부지원사업 예산에 클라우드와 외부 API 비용을 넣어도 되나요?
사업별 공고문, 통합관리지침, 세부관리기준, 협약서에 따라 다릅니다. MVP 개발·테스트·시연에 직접 필요한 클라우드나 API 사용료는 검토 대상이 될 수 있지만, 사업 종료 후 상용 운영비나 장기 선결제 비용은 제한될 수 있습니다. 반드시 주관기관에 비목, 사용 기간, 결제 방식, 증빙 가능 여부를 확인해야 합니다.
Q3. 출시 전 운영비를 산정할 때 가장 먼저 정해야 할 숫자는 무엇인가요?
가입자 수보다 먼저 월간 활성 사용자, 피크 동시접속, 고객사 수, 파일 업로드 용량, 월 API 호출 수, AI 토큰 사용량, 데이터 보관 기간을 정해야 합니다. 여기에 운영 수준, 예를 들어 베타 서비스인지 유료 B2B 서비스인지, 장애 대응 시간을 어느 정도 약속할지까지 정해야 실제 월 운영비에 가까워집니다.
Q4. 무료 티어나 클라우드 크레딧을 운영비 0원으로 잡아도 되나요?
내부 현금흐름표에서는 무료 티어·크레딧을 별도 열로 관리할 수 있지만, 본래 사용량 기준의 정상가도 함께 계산해야 합니다. 크레딧이 끝난 뒤 비용이 갑자기 늘어나는 경우가 많기 때문입니다. 사업계획서에는 할인 전 기준, 할인 적용 기간, 할인 종료 후 월 비용을 분리해 쓰는 것이 좋습니다.
Q5. 외주 개발 견적을 받을 때 운영비 관련해서 무엇을 꼭 물어봐야 하나요?
배포 환경 구성, 로그·모니터링, 백업과 복구 테스트, 보안 패치, 장애 대응, 관리자 화면, 데이터 추출, API 사용량 제한, 비용 알림, 소스코드와 계정 인수인계가 포함되는지 확인해야 합니다. 단순 기능 개발 견적에는 이런 항목이 빠지는 경우가 있어 별도 유지보수 또는 운영 계약 범위를 명확히 해야 합니다.
