클라우드 벤치마킹으로 한국 B2B 운영 사업 만들기

서버를 싸게 빌려서 조금 비싸게 제공하면 클라우드 사업이 될까. 계산은 간단해 보이지만, 고객이 늘수록 질문이 바뀐다. 새벽에 앱이 멈추면 누가 복구하는가. 고객 하나가 메모리를 모두 사용하면 다른 고객은 안전한가. 해지할 때 데이터는 어떻게 돌려주는가. 이런 질문에 답하는 비용까지 받아야 사업이 유지된다.

이 글에서는 한국의 중소기업과 웹 개발사에 클라우드 운영을 제공하는 1인 B2B 사업을 설계한다. 계약·청구의 단위는 고객사이고, 판매 대상은 기업이 사용하는 업무용 웹 앱의 이전·배포·백업·복구·월간 운영 보고다. 지원하는 런타임과 데이터베이스를 제한하고 고객사별로 운영 범위를 합의한다. 사업자는 혼자 시작하더라도 구매자는 기업의 예산으로 계약한다.

출발 조건은 민간기업에 재직하면서 주 10시간과 작은 실험 예산으로 준비하는 것이다. 재직 중에는 예약형 진단·복구 시험·자동화 구축부터 검증하고, 평일 대응 인력을 확보하거나 전업으로 전환한 뒤 월 운영 계약으로 넓힌다. 정부 지원은 이 과정의 교육·검증·제품화 비용을 보완하는 수단으로 연결한다.

첫 시장은 국내 웹 개발사가 납품한 업무용 앱의 운영이다. 개발사를 직접 계약 고객으로 삼아 운영을 맡거나, 개발사의 소개를 받아 최종 사용 기업과 직접 계약한다. 두 경로의 승인권자·지원 창구·청구 대상을 처음부터 구분한다.

벤치마킹은 두 가지 의미로 사용한다. 하나는 기존 클라우드가 고객의 일을 어떻게 상품으로 만들었는지 배우는 것이고, 다른 하나는 실제 워크로드로 성능과 비용을 측정하는 것이다. 전자는 무엇을 팔지 정하고, 후자는 얼마만큼 약속할 수 있는지 정한다. 아래 구성·요금·통과 기준은 검증할 사업 가설이며, 실제 고객 인터뷰나 성능 실험을 수행한 결과가 아니다. 공식 문서는 2026년 9월 6일에 확인했다.

한국에서 첫 계약을 맺을 고객사를 좁힌다

첫 상품을 “CPU와 메모리를 원하는 만큼 제공하는 클라우드”로 정하면 운영체제·런타임·네트워크·보안 요구가 끝없이 늘어난다. 출발점은 “지원하는 런타임의 웹 앱을 옮기고, 이후 배포와 복구를 관리한다” 정도가 적당하다.

예를 들어 소규모 개발사에는 납품한 앱이 여러 개 있다. 앱은 작지만 도메인 만료, 인증서, 배포 실패, 백업 확인은 계속 발생한다. 이 고객에게는 vCPU 수보다 “새 고객 앱을 하루 안에 이전할 수 있는가”, “퇴사한 개발자의 권한을 바로 회수할 수 있는가”, “복구를 맡길 사람이 있는가”가 더 중요한 구매 기준일 수 있다. 이는 인터뷰에서 확인할 가설이다.

이미 PaaS로 충분히 해결한 팀도 있다. 이들에게 더 싼 서버만 제시하면 이전할 이유가 약하다. 최근 운영 사고, 매달 쓰는 시간, 현재 지출, 결제 결정권자를 확인하고 해결되지 않은 일이 있는 고객을 찾는다.

첫 고객사 가설은 다음처럼 좁힌다. 규모와 우선순위는 시장 통계가 아니라 직접 검증할 영업 기준이다.

첫 제안은 “업무용 웹 앱 2개와 DB 1개의 배포·백업·월간 점검을 맡는다”처럼 쓴다. 기술 스택, 개발·운영 환경 수, 데이터 크기와 지원 시간을 추가해 견적 범위를 고정한다. 업무 부서는 중단과 보고 지연의 영향을 확인하고, 기술 담당자는 인수 가능성을 검토하며, 예산 승인자는 지출을 판단한다. 같은 사람이 여러 역할을 맡더라도 세 질문은 따로 확인한다.

개발사 경유 계약에서는 최종 고객이 누구에게 장애를 접수하고 누가 변경을 승인하는지 정한다. 개발사가 계약 고객이면 개발사에 보고·청구하고, 최종 기업과 직접 계약하면 그 기업이 검수·승인한다. 여러 최종 고객의 운영을 개발사 한 곳에 묶어 판매해도 앱 수와 지원량을 원가에 포함해야 한다.

클라우드에서 무엇을 벤치마킹할 것인가

국내 MSP(클라우드 관리 서비스 사업자)의 업무 범위와 클라우드 제품의 운영 기능을 함께 관찰한다. 네이버 클라우드의 파트너 목록에는 컨설팅·이전·매니지드 서비스를 제공하는 업체가 소개되어 있다. 이를 경쟁 서비스 조사 출발점으로 삼되, 목록 등재만으로 실제 품질이나 우리 사업의 수요가 검증되는 것은 아니다. 네이버 클라우드 파트너 목록.

공개된 서비스 소개와 제안 범위에서 이전 산출물, 지원 시간, 고객의 승인 책임, 월간 보고, 계약 종료 시 인계를 비교한다. 무료 가입 전환율보다 견적을 받은 기업이 운영 범위를 이해하고 내부 승인을 받을 수 있는지를 본다.

AWS는 개별 부품만 시험하거나 운영 환경과 다른 환경에서 시험하는 문제를 지적한다. Hetzner는 공유 vCPU에서 다른 사용자의 활동이 응답 시간에 영향을 줄 수 있다고 설명한다. 따라서 같은 “2 vCPU” 표기만으로 상품의 품질이 같다고 보기는 어렵다. AWS 부하 시험 지침, Hetzner 서버 FAQ.

Render에서는 새 인스턴스의 헬스 체크를 통과한 뒤 트래픽을 전환하며, 이전 배포 산출물을 재사용해 롤백할 수 있다. 디스크의 데이터 상태까지 배포 롤백으로 돌아가지는 않는다. 이 구분은 작은 서비스에도 필요하다. 여기서 배울 것은 버튼의 모양보다 고객에게 약속하는 성공·실패·복구의 의미다. Render 헬스 체크, Render 롤백.

한국 기업을 위한 벤치마킹에는 계정 소유권과 비용 설명도 넣는다. 네이버 클라우드의 Sub Account는 부여된 권한으로 자원을 관리하는 구조이고, 요금 안내는 서비스별 비용 확인의 출발점이다. 위임 계정 생성·회수와 고객사별 비용 보고를 직접 시험할 항목으로 잡는다. Sub Account 개요, 네이버 클라우드 요금 안내.

직접 사용해 측정할 때는 접근 권한 승인부터 첫 배포까지의 시간, 실패 배포 안내, 복구 단계 수, 데이터 반출 시간을 같은 시나리오로 기록한다. 문서로 확인한 기능과 직접 경험한 결과를 별도 열에 남긴다. 국내 리전이 필요한 계약에서는 그 조건을 충족한 후보끼리 성능·원가를 비교한다. Hetzner 같은 해외 공급자의 자원 설계에서 배울 수 있는 점과 실제 고객사에 배치할 수 있는지는 별개로 판단한다.

성능 벤치마크를 판매 가능한 한도로 바꾼다

실험은 고객의 대표 앱으로 시작한다. 인증을 포함한 API 요청, DB 읽기와 쓰기, 파일 업로드, 예약 작업을 정해진 비율로 실행한다. 민감한 실제 고객 데이터 대신 합성 데이터를 사용한다. 전체 요청 경로를 재현하는 접근은 AWS의 부하 시험 지침에 근거한다. 다음 수치와 실험 순서는 이 사업을 위한 제안이다.

같은 리전 조건과 소프트웨어 버전에서 공유 VM, 전용 vCPU VM, 관리형 플랫폼을 후보로 비교한다. 모든 후보에 동일한 이미지 digest, DB 크기, 요청 비율, 캐시 조건을 적용한다. 한국 고객 대상 서비스라면 한국의 부하 생성기에서 왕복 지연을 재고, 서버 내부 처리 시간도 따로 수집한다. 다른 지역을 비교했다면 그 차이를 결과에 명시한다.

예를 들어 10분 예열, 30분 지속 부하, 단계적 과부하, 작업 프로세스 강제 종료, 백업 복원 순서로 시험한다. 서로 다른 시간대에 적어도 세 번 반복하고 초기 시험을 통과한 후보는 24시간 이상 지속 시험한다. 공유 자원에서는 단 한 번의 최고 점수로 용량을 확정하지 않는다. 부하 생성기 자체가 병목인지도 확인한다.

실험 전에 “대표 API에서 p95 300ms 이하, 오류율 0.1% 미만”과 같은 통과 조건을 적는다. 이는 예시 목표이며 서비스 보장치가 아니다. 지연이 긴 실패 요청을 통계에서 숨기지 않고, 지연과 오류를 함께 판정한다. 콜드 스타트와 캐시 적중 조건도 나눠 보고한다.

가령 한 시험에서 해당 조건을 만족한 최대 처리량이 100 RPS였다면, 초기에는 그 60%인 60 RPS를 내부 용량 계획의 상한 후보로 둘 수 있다. 이 역시 가정이며 재시험이 필요하다. 앱마다 DB 사용량이 다르므로 이를 모든 고객에게 “앱당 60 RPS 보장”으로 판매하지 않는다. 실제 상품에는 메모리·동시 실행·저장·전송 한도를 표시하고, 고객 앱의 수용 시험으로 적용 가능성을 판단한다.

결과물은 순위표보다 재현 가능한 기록이어야 한다. 공급자와 상품, 리전, 실행 일시, 이미지 버전, 설정, 원시 측정값, 비용 산정 기간, 탈락 이유를 함께 보관한다. 후보를 다시 시험할 때 같은 조건인지 확인할 수 있어야 한다.

자원은 고객별 VM에서 시작한다

초기 서빙 방식은 공급자의 VM을 빌리고 고객별로 런타임을 분리하는 방식으로 잡는다. 컨테이너는 앱 포장과 자원 제한에 사용한다. 직접 장비를 구매하거나 첫 고객부터 공용 Kubernetes 클러스터를 운영하는 결정은, 임대 구조에서 수요와 운영 원가를 확인한 뒤 내린다.

기본 상품은 고객사 소유 클라우드 계정에서 운영하고 관리료를 받는 BYOC 방식으로 잡는다. 고객사가 인프라 요금을 공급자에게 직접 결제하고, 우리는 인수·자동화·월 운영에 대해 청구한다. 계정과 결제 정보는 고객사가 보유하고 운영자는 작업별로 제한된 권한을 위임받는다. 계약 종료 때 접근을 회수하고 다른 운영 업체가 인수할 수 있어야 한다.

견적에는 공급자·리전·계정 소유자·예상 인프라비·운영료를 분리해서 적는다. 데이터 저장 위치, 백업 위치, 지원 도구로 전송되는 로그 범위도 고객사와 합의한다. 국내 리전 요구가 있다면 운영 데이터와 백업 모두 배치 조건을 검토한다. 운영자 계정의 인프라 포함형은 별도 상품으로 두고, 공급자 조건과 미수금·원가 변동을 감당할 수 있을 때 추가한다.

고객의 배포 요청
  → 관리 API: 인증·플랜·권한 확인
  → 작업 DB와 큐: 요청 ID·목표 버전·상태 저장
  → 조정 작업자: VM·DNS·인증서·배포 상태 맞추기

서비스 이용자
  → DNS / TLS 진입점
  → 고객별 VM의 프록시
  → 앱 컨테이너 → 고객별 DB
                → 객체 스토리지

별도 관측 경로: 외부 상태 확인·메트릭·감사 로그
별도 복구 경로: 운영 VM 밖의 백업 → 새 VM 복원

관리 API가 멈춰도 이미 배포된 앱은 계속 요청을 받을 수 있게 한다. 관리 계층은 계정·플랜·배포 상태를 다루고, 서비스 트래픽은 고객 VM으로 직접 흐른다. 단, 이 분리만으로 앱이나 DB가 고가용성이 되는 것은 아니다. 단일 VM 장애는 복구가 끝날 때까지 중단으로 이어진다.

첫 버전에서는 관리 화면이 작아도 된다. 인증된 신청서, 검토된 설정, 반복 실행 가능한 프로비저닝 작업부터 시작한다. VM 생성 성공 직후 작업자가 죽어도 재시도하면서 같은 VM을 찾아야 한다. 요청 ID로 중복 생성을 막고 requested → provisioning → deploying → ready와 실패·삭제 상태를 저장한다. 주기적으로 실제 자원과 기록을 대조해 고아 VM과 청구 누락을 찾는다.

판매하는 자원은 CPU·메모리만이 아니다. 디스크 용량, 업로드 크기, 요청 본문 크기, 실행 시간, DB 연결 수, 작업 동시성, 월 전송량을 제한해야 과부하와 비용이 통제된다. 사용량 80% 알림, 상한 도달 시 업그레이드 또는 제한, 초과 과금은 사전 동의 같은 규칙을 상품에 명시한다. 초과 과금에 동의하지 않은 고객에게 자동으로 비용을 늘리지 않는다.

공용 Kubernetes로 옮길 때도 namespace만 생성해서 고객 격리가 끝났다고 볼 수 없다. 공식 문서는 네트워크 정책, 접근 통제, 자원 할당 등 추가 구성을 요구한다. 신뢰할 수 없는 고객 코드의 실행은 별도 격리 설계가 필요하다. Kubernetes 멀티테넌시.

이 사업에서는 고객별 자격 증명, 최소 권한, 비밀의 암호화 보관, 비공개 DB 접속, 관리 작업 감사 기록을 기본 설계에 넣는다. 빌드는 운영 VM과 별도 작업자에서 실행해 빌드 부하와 비밀 접근을 제한한다. 고객별 VM도 잘못 공유한 자격 증명이나 관리 API의 권한 오류를 대신 해결해 주지는 않는다.

배포보다 복구와 해지가 상품의 완성도를 결정한다

배포는 이미지 digest와 설정 버전을 기록하고 새 버전의 준비 상태를 확인한 다음 트래픽을 전환한다. 실패하면 기존 버전을 유지한다. DB 변경은 이전 앱과 함께 동작할 수 있는 확장·전환·정리 단계로 나눈다. 파괴적인 스키마 변경이 있었다면 앱 이미지만 되돌리는 것으로 복구되지 않을 수 있다.

백업은 운영 VM 밖에 보관하고 고객별 접근을 분리한다. 백업 성공 알림과 별개로 새 VM에 복원해 앱이 데이터를 읽고 쓰는지 검사한다. 최초 온보딩과 이후 정기 복구 훈련에서 데이터 양, 복구 소요 시간, 마지막 복원 가능한 시점을 기록한다.

파일럿의 목표를 RPO 24시간, RTO 4시간으로 잡았다고 하자. RPO는 허용하는 데이터 손실 시간이고, RTO는 서비스 복구 목표 시간이다. 하루 간격 백업이 계속 성공해야 24시간 목표에 접근할 수 있으며, 백업 실패를 방치하면 이를 넘는다. RTO는 서비스 중단부터 측정할지 등 시작점을 먼저 정해야 한다. 야간에 사람이 대응하지 않는 구조라면 밤에 발생한 사고의 4시간 복구를 약속하기 어렵다. 24시간 복구 목표가 필요한 고객은 자동 복구나 대응 인력을 확보한 플랜에서 받는다.

지원 시간과 최초 응답 목표를 공개하고 복구 시간과 구분한다. 혼자 운영한다면 휴가와 장기 부재의 대체 담당자·권한 부여 절차도 필요하다. 실측과 대응 체계가 준비되기 전에는 목표를 계약상 SLA처럼 홍보하지 않는다.

업무 중단을 수반하는 변경은 고객사의 승인자, 한국 시간 기준 작업 창구, 되돌리기 기준을 작업 전에 기록한다. 긴급 조치의 사전 위임 범위도 정한다. 장애가 나면 고객사의 지정 담당자에게 영향 범위·임시 조치·다음 업데이트 시각을 알리고, 종료 후 원인과 재발 방지 조치를 전달한다. 월간 보고에는 비용 변동, 배포 이력, 백업·복원 확인, 남은 위험과 다음 달 작업을 담는다.

해지도 미리 구현한다. 고객이 DB와 파일을 내보낼 수 있고, 도메인·계정 소유권을 확인할 수 있어야 한다. 서비스 종료일, 데이터 반출 기간, 운영 데이터 삭제일, 백업 만료일을 주문 전에 설명한다. 계약에는 지원 범위와 책임, 데이터 처리 범위, 이용 제한, 환불·종료 조건을 구체화한다. 국내 거래에 필요한 사업자 정보, 정산 담당자, 증빙 수령 방식과 지급일을 온보딩 때 확인한다. 세금계산서 발급 등 실제 세무 처리와 개인정보 처리 위탁에 필요한 조건은 사업자 유형·거래·취급 데이터에 맞춰 별도로 확인한다.

기업의 구매 과정을 산출물로 연결한다

이 사업의 영업 절차는 소개·접촉 → 문제 확인 → 유료 진단 → 제안·견적 → 계약 → 인수·검수 → 월 운영 → 갱신으로 설계한다. 모든 기업이 같은 절차를 쓰는 것은 아니므로 첫 미팅에서 공급업체 등록, 결재권자, 보안 검토 여부, 예산 시점과 지급 조건을 확인한다.

검수 기준은 “운영 안정화 완료”처럼 쓰지 않는다. 예를 들어 새 환경 배포, 합의한 표본 데이터의 복원 확인, 장애 알림 도착, 고객 관리자 접근, 데이터 반출 시험을 체크리스트로 정한다. 검수 기한과 미완료 항목 처리도 계약 전에 합의한다. 초기 진단은 운영 가능성을 조사하는 작업이며, 기존 앱의 모든 결함을 고치는 계약으로 확대하지 않는다.

가격은 고객사별 운영 계약으로 계산한다

다음 월 운영 상품과 손익 예시는 평일 대응이 가능한 전업 또는 파트너 운영 단계를 가정한다. 재직 중 혼자 시작하는 준비 단계의 시간·예산과는 구분한다.

기본 견적은 일회성 진단·인수비와 월 운영료로 나누고, 인프라비는 BYOC 고객사가 직접 부담한다. 월 운영 상품의 예시 범위는 웹 앱 2개·DB 1개, 개발·운영 환경 각 1개, 평일 한국 시간 09~18시 지원, 예약 변경 월 2회, 월간 보고다. 지원 스택과 자원 한도는 별첨에 적고 회의·문의·변경·보고를 합한 월 작업 한도는 6시간으로 가정한다. 초과 작업은 견적과 고객사 승인을 거쳐 진행한다. 24시간 대응, 기능 개발, 새 시스템 구축은 별도 범위다.

다음은 한국 B2B BYOC 운영 계약의 가상 계산이다. 실제 국내 시세나 공급자 견적이 아니며 월 단위 원화, 부가세를 제외한 공급가액으로 계산한다. 인프라비는 고객사 직접 지출이므로 아래 운영 매출과 비용에서 제외한다.

고객사당 공헌이익 = 월 운영료 - 고객사별 도구·운영 시간·예상 보상 비용
월 고정비 = 공용 도구·관리 시스템 1,000,000원
          + 영업·개발·공통 관리 50시간 × 50,000원
          = 3,500,000원
경제적 손익분기 고객사 수 = 올림(3,500,000 / 700,000) = 5곳

8개 고객사라면 월 운영 매출은 960만 원, 공헌이익 합계는 560만 원, 고정비 차감 후 잔여는 210만 원이다. 창업자의 시간가를 반영한 경제적 계산이며 세후 순이익이나 현금 잔액을 뜻하지 않는다. 일회성 진단·인수 매출은 반복 매출의 손익분기 계산에서 제외한다.

고객사별 작업이 6시간에서 12시간으로 늘면 시간비용은 60만 원, 공헌이익은 40만 원, 손익분기점은 9곳이 된다. 고객사 작업에 108시간, 공통 업무에 50시간이 필요하다. 월 고객사 대응 예산을 60시간으로 잡았다면 이미 수용 한도를 넘는다. 계약 수를 늘리기 전에 범위·가격을 바꾸거나 수행 인력을 확보해야 한다.

6시간 기준 산술 상한은 10곳이지만, 초기 모집 목표는 3곳으로 두고 실제 상한은 동시 장애·휴가·인수 작업의 여유를 남겨 정한다. 개발사 한 곳이 최종 고객 앱을 추가하는 경우에는 계약 수가 그대로여도 원가가 늘어난다. 한 고객사의 매출 비중과 업무량을 함께 기록해 특정 거래처 의존도도 관리한다.

진단·인수비는 예상 투입 시간과 검수 산출물로 별도 산정한다. 고객 획득 비용에는 첫 미팅, 기술 조사, 제안서, 보안 질의 응답에 쓴 시간을 포함하고 고객별 분석에서는 반복 운영 시간과 중복 계산하지 않는다. 계약 총액과 입금액도 구분한다. 선금·잔금, 검수일, 월 청구일, 지급 기한을 합의하고 회수 지연을 견딜 현금을 계산한다. 인프라 포함형을 추가하면 공급자 대금 선지급과 미수금 위험까지 다시 모델링한다.

재직 중에는 예약형 업무부터 주 10시간으로 검증한다

회사를 다니면서 시작한다면 첫 상품은 고객사 환경의 읽기 전용 진단, 격리된 시험 환경의 백업 복원, 배포 자동화 구축처럼 완료 조건과 작업 시간을 정할 수 있는 일이다. 운영 시스템의 평일 장애 접수 책임은 기존 담당자나 별도 계약한 운영 파트너가 유지한다. 자동 알림을 켜는 것만으로 낮 시간 대응 책임이 해결되지는 않는다. 실제 운영 변경은 승인된 작업 시간과 복구 담당자를 확보한 뒤 수행한다.

민간기업 재직자의 겸직은 근로계약·취업규칙의 제한부터 확인한다. 고용노동부 상담도 사업장의 겸직 규정을 먼저 확인하도록 안내한다. 이 안내를 모든 직장과 업무에 대한 일괄 허용으로 해석하지 않는다. 공무원·공공기관 등은 해당 신분과 기관의 별도 규정 확인이 필요하다. 고용노동부 겸직 상담.

개인 장비·계정·저장소·클라우드 비용을 사용하고 회사 코드, 고객 명단, 내부 자료와 근무시간을 사업에 사용하지 않는 방식으로 준비한다. 사업 분야가 회사 업무와 겹치면 겸업 승인, 이해충돌, 비밀유지와 결과물 권리 범위를 문서로 확인한다. 필요한 승인 절차가 있다면 유료 계약 전에 마친다. 승인받기 전에는 회사 거래처를 개인 영업 경로로 이용하지 않는다.

주간 시간표는 아래처럼 10시간으로 제한하는 가설을 둔다. 고객이 평일 낮에만 만날 수 있으면 사전 합의한 휴가·업무 외 시간으로 조정하고, 그 주의 개발 시간을 줄인다. 지원사업 발표나 교육도 같은 시간 예산 안에 넣는다.

처음에는 동시에 수행하는 유료 진단을 1곳으로 제한한다. 진단 1건을 끝내는 데 8시간이 든다면 제안·회의·수정 시간까지 포함해 기록한다. 수요가 있어도 계속 야간 대응을 요구한다면 즉시 상시 운영을 인수하는 대신 수행 파트너를 구하거나 해당 계약을 보류한다.

정부 지원은 현재 단계에 맞는 경로로 찾는다

아래는 2026년 9월 6일에 확인한 공식 자료다. 나이, 거주지·사업장 소재지, 기존 사업자등록·법인 대표 이력, 과거 지원 이력을 모르는 상태이므로 개인의 신청 자격을 확정한 목록은 아니다. 마감된 공고는 다음 준비의 참고 자료이며, 차년도 일정이나 동일 조건의 재공고를 보장하지 않는다.

접수 공고는 K-Startup 창업지원포털과 기업마당에서 창업 단계·지역·교육·사업화 분야로 찾는다. 신청 후보는 최대 2개로 줄이고, 해당 기관에 현재 재직 형태, 나이, 지역, 등록 이력, 수행 가능한 시간을 전달해 맞는지 확인한다. 공간 지원은 실제 방문·입주 시간을 쓸 수 있을 때 검토한다.

사업자등록 여부와 재직 여부는 서로 다른 확인 항목이다. 예비창업패키지의 위 수정 공고는 사업자등록증·법인 대표권에 관한 특정 기준일을 둔다. 이를 단순히 “등록 전이면 신청 가능”이나 “직장인이므로 가능·불가능”으로 바꾸지 않는다. 재직 유지 가능 여부, 선정 후 창업 완료 시점, 대표자 직접 수행, 평일 교육·발표 참석은 해당 연도의 공고·FAQ와 주관기관 답변으로 확인하고 답변을 보관한다. 이 글에서는 재직 유지 자격을 확정하지 않는다.

준비 경로는 둘로 나눈다. 예비창업 지원을 먼저 검토하는 경로는 고객 인터뷰·합성 데이터 데모·비구속적 구매의향 확인으로 수요를 검증하면서 등록 시점을 상담한다. 당장 유료 진단을 판매하는 경로는 겸업 조건과 등록·세무 처리를 먼저 갖추고, 그 등록 이력에 맞는 초기창업·지역 지원을 찾는다. 지원 자격을 유지하려고 실제 영업이나 등록 이력을 숨기지 않는다. 법인 설립은 고객의 계약 요건, 공동 소유·투자 계획과 관리 비용이 구체화된 시점에 판단한다.

지원금 신청서는 고객 검증과 자동화 산출물을 연결한다

지원사업에 맞춘 가설은 “국내 소규모 개발사가 납품한 앱의 복구 가능성과 운영 비용을 반복 확인하는 도구”로 잡을 수 있다. 기존의 수작업 운영 서비스를 실제 공통 소프트웨어로 발전시킬 계획이 있을 때 선택하는 방향이다. 단순 운영 대행을 이름만 바꿔 기술개발로 표현하지 않는다. 지원 여부는 사업 취지와 평가에 따라 결정되므로, 현재 사업이 서비스 대행에 더 적합하면 고객 매출과 교육·상담을 중심으로 준비한다.

신청 전에는 최신 양식에 맞춰 다음 증거를 모은다. 이는 공식 평가 배점이 아니라 이 사업의 준비 목록이다.

• 고객 문제: 회사 자료를 제외한 인터뷰 기록, 반복 장애·복구 공백, 예산 승인자의 요구.
• 해결책: 고객별 격리 환경에서 배포·복구 시험과 비용 보고가 동작하는 데모.
• 성과 목표: 진단 소요 시간, 복원 성공 여부, 보고 작성 시간, 유료 검수·입금 기록. 아직 측정하지 않은 값은 목표로 표시.
• 수행 계획: 재직 중 가능한 시간, 담당 업무, 평일 참석·대응 방안, 외주 범위와 산출물.
• 예산 근거: 검증 인프라·시험·개발 등 작업별 견적, 집행 시점, 자부담 가능 현금과 정산 자료.

지원사업 관리표에는 공고 버전·마감, 신청 기준일, 나이·지역·업종, 재직 조건, 과거 수혜·중복 수행 제한, 자부담 현금·현물, 집행 가능 항목, 필수 참석, 창업·성과 의무를 기록한다. 신청 → 평가 → 선정 → 협약 → 집행·보고 → 정산을 별도 일정으로 잡고, 협약 전 지출의 인정 여부와 부가세·대표자 인건비·클라우드 이용료의 처리 기준은 지출 전에 확인한다. 공고문과 협약에서 허용하는 항목만 사업비로 집행한다.

계획상 사업화 지원금은 사용 목적과 정산이 연결된 자금으로 취급한다. 생활비나 제한 없는 매출로 계산하지 않고, 융자·보증은 상환·보증 조건을 검토할 별도 조달 수단으로 분리한다. 민간 클라우드 크레딧도 현금 지원금과 구분한다. 승인 전 지원금과 다음 회차 예상 지원금은 기본 현금 계획에 0원으로 둔다.

재직 상태에서 6개월, 현금 300만 원으로 준비한다

다음은 주 10시간·6개월 실험비 300만 원이라는 작성자의 가정이다. 개인 생활비와 보유 장비는 제외하며, 정부가 정한 예산이나 지원 금액이 아니다. 월 30만 원 × 6개월은 시험용 클라우드·도구·미팅에, 나머지 120만 원은 필요한 계약·세무 상담과 예측하지 못한 실험 지출에 한도로 남긴다. 지출 전에 견적을 확인하고 한도를 넘으면 실험 범위를 줄인다. 무료 교육을 활용하고 사무실 임차·장비 구매·장기 서버 약정은 수요 검증 이후로 둔다.

정부 지원에서 탈락하거나 모집이 없더라도 인터뷰와 데모, 예약형 진단은 남는다. 2026년 9월부터 시작하면 이 6개월은 2027년 초까지 걸치지만, 차년도 모집일과 조건은 발표 전 확정해서 쓰지 않는다. 지원사업 문서 작성 때문에 고객 검증을 중단하지 않도록 신청 준비 시간도 주간 한도에 포함한다.

전업 전환 기준은 선정 통보와 별도로 둔다. 예를 들어 서로 독립적인 고객사 2곳 이상의 검수·입금, 3개월간 반복 수요와 작업 원가, 평일 대응 인수 방안, 계약 종료 시 인계 절차를 확인한다. 이 수치도 개인의 의사결정을 위한 예시다. 필요한 생활비와 사업 고정 현금 지출의 6~12개월분을 지원금·미수금과 분리해서 계산하고, 가장 큰 고객이 빠지는 경우도 검토한다. 앞의 시간가를 포함한 경제적 손익과 생활비를 위한 현금 계산을 중복 합산하지 않는다. 수요와 현금이 충분하지 않으면 직장을 유지하며 범위가 작은 일을 반복한다.

첫 90일은 국내 고객사 3곳의 유료 계약을 검증한다

이 90일은 앞의 재직 중 준비를 거쳐 평일 대응 인력과 계약·정산 체계를 확보한 뒤 시작하는 운영 사업 확장 계획이다. 재직 중 혼자 진행할 때는 앞의 6개월·동시 진단 1곳 계획을 적용한다. 다음 일정과 통과 기준은 제안이며 수요나 수익이 검증되었다는 뜻은 아니다. 구매 승인이나 검수가 90일을 넘으면 단계별 지연 이유와 다음 결재 일정을 기록한다. 연간 계약은 이 기간 안에 갱신을 관찰할 수 없으므로 파일럿의 본계약 전환과 월 운영료 회수로 구분해 평가한다.

인터뷰에서는 “이 서비스가 있으면 쓰겠는가”보다 “최근 장애를 어떻게 해결했고 몇 시간을 썼는가”를 묻는다. 관심 표현, 견적 요청, 계약, 입금, 갱신은 서로 다른 증거다. 무료 이용자 수로 유료 수요를 대신 판단하지 않는다.

첫 영업 목록은 국내 웹 개발사 20곳을 가설로 잡고 지원 스택·납품 유형·유지보수 담당 유무를 조사해 만든다. 기존 개발 인맥의 소개로 담당자를 연결하고, 납품 후 운영 인수라는 한 가지 제안으로 미팅을 요청한다. 관심이 확인된 회사에만 범위를 정한 유료 진단을 제안한다. 개발사와 협업할 때는 소개 수수료나 운영 위탁 여부, 최종 고객 접촉 범위, 장애 접수 책임을 합의한다. 클라우드 공식 파트너 지위나 재판매 권한은 실제 확보한 범위에서만 표시한다.

진단 보고서에는 현재 비용, 운영 공백, 인수 작업, 월 관리 범위를 적는다. 영업 기록은 접촉 수보다 예산 승인자가 있는 기회 수, 진단 계약, 검수, 입금, 운영 전환으로 관리한다. 고객사 이름·시스템 화면·비용 절감 사례의 공개는 사전 동의 범위로 제한한다.

이전 비용은 투입 시간을 기록해 책정하고, 첫 월 운영료와 별도로 제시한다. 초기에 공용 대시보드를 크게 만드는 것보다 고객에게 비용·배포·백업·문의 내역을 정확히 전달하는 일이 중요하다. 같은 수작업이 반복되어 매주 시간을 쓰게 되는 지점부터 자동화한다.

90일 후에는 갱신율의 분모와 함께 실제 계약 고객사 수, 고객사당 공헌이익, 지원 시간의 평균·상위 구간, 복구 목표 달성 여부, 영업 비용·대금 회수 일수를 확인한다. 파일럿이 3곳이라면 갱신율만으로 시장 전체를 추정하기 어렵다. 영업 비용에는 광고비뿐 아니라 진단과 상담 시간도 포함한다.

고객이 갱신하고 약속한 범위 안에서 이익과 운영 여유가 남으면 같은 고객군을 조금씩 늘린다. 수요는 있는데 특정 스택만 지원 시간을 크게 쓰게 하면 지원 범위와 가격을 바꾼다. 갱신이 없거나 감당할 수 없는 복구 약속만 계약으로 이어진다면 증설을 멈추고 고객군이나 상품을 다시 정한다.

클라우드를 벤치마킹한 결과물은 서버 사양표에서 끝나지 않는다. 누구의 어떤 운영 일을 맡을지, 어떤 부하까지 감당할지, 실패하면 어떻게 복구할지, 그 약속을 이행하고 얼마가 남는지까지 연결되어야 한다. 한국의 고객사 담당자가 예산을 승인받고, 검수한 운영 결과에 대금을 지급하며, 다음 기간에도 맡길 수 있을 때 작은 인프라가 B2B 사업의 기반이 된다.