스타트업과 소규모 팀에게 SaaS가 실제로 의미하는 것

회사 카드 명세서를 열어 반복되는 청구액을 세어보세요. 대부분의 소규모 팀은 8개에서 20개 사이를 발견합니다. 채팅 앱, 디자인 도구, 프로젝트 보드 두 개(왜냐하면 모두가 하나에 동의하지 않았기 때문에), 이메일 플랫폼, 모니터링 서비스, 그리고 아무도 가입한 것을 기억하지 못하는 몇 가지 항목들입니다.

이것이 현실 속 SaaS입니다. 이것은 유행어가 아닙니다. 소프트웨어가 구매되고 판매되는 기본 방식이며, 당신이 생각하든 안 하든 당신의 결정에 영향을 미칩니다.

이 글은 창업가(founders), 인디 빌더(indie builders), 그리고 소규모 팀 개발자를 위한 것입니다. 여기서 얻을 수 있는 내용은 다음과 같습니다:

교과서적인 버전이 아닌, SaaS의 실용적 정의
모델이 작동하는 곳과 조용히 무너지는 곳
구매할지, 확장할지, 아니면 구축할지를 결정하기 위한 간단한 순서
직접 SaaS 제품을 구축하기 전에 검증해야 할 것들

만약 당신의 목적이 커스텀(custom)으로 무엇인가를 만들지 결정하는 것이라면, '구매, 확장 또는 구축' 섹션으로 건너뛰세요.

실질적인 용어로서의 SaaS

SaaS는 소프트웨어 서비스(software as a service)의 약자입니다. 교과서적 정의는 '구독 기반으로 인터넷을 통해 제공되는 소프트웨어'입니다. 이것은 정확하지만, 당신에게 중요한 것을 놓치고 있습니다.

실제적으로 SaaS가 의미하는 것은 세 가지입니다:

다른 사람이 서버를 운영한다. 당신은 아무것도 배포하거나(deploy), 패치하거나(patch), 확장할 필요가 없습니다. 공급업체(vendor)가 합니다.
소유하는 것이 아니라 임대한다. 비용 지불을 중단하면 접근이 중단됩니다. 당신의 데이터는 함께 오지 않을 수도 있고, 올 수도 있습니다.
제품이 당신 앞에서 바뀐다. 업데이트는 당신이 요청했는지 여부와 관계없이 배포됩니다. 보통은 좋은 일입니다. 하지만 때로는 의존하는 기능이 더 높은 등급 뒤로 이동하기도 합니다.

개발자에게 있어 정신적 모델(mental model)은 간단합니다. 당신은 UI나 API를 통해 다른 사람의 프로덕션 환경을 소비하고 있는 것입니다. 그들의 가동 시간(uptime)이 곧 당신의 가동 시간이 됩니다. 그들의 로드맵(roadmap)은 부분적으로 당신의 로드맵입니다.

이 모델이 지배적이 된 이유

SaaS가 유행했기 때문에 승리한 것이 아닙니다. 양측 모두에게 경제성이 작동하기 때문에 승리했습니다.

벤더(vendors) 입장에서, 반복적인 수익(recurring revenue)은 일회성 라이선스 판매보다 훨씬 예측 가능합니다. 하나의 코드베이스가 모든 고객에게 서비스를 제공하므로, 버그 수정이 한 번 배포되면 모두에게 도달하게 됩니다. 여러 고객이 격리된 데이터와 동일한 인프라를 공유하는 멀티테넌트 아키텍처(Multi-tenant architecture)는 고객당 호스팅 비용을 낮게 유지합니다.

구매자(buyers) 입장에서, 초기 비용은 거의 제로에 가깝습니다. 화요일에 도구를 사용해 보고, 금요일까지 팀 전체에 배포한 다음, 적합하지 않으면 다음 달에 취소할 수 있습니다. 구매 절차(procurement cycle)도 없고, 설치 프로젝트도 필요 없습니다.

클라우드 인프라 덕분에 이 모든 것이 일반적일 만큼 저렴해졌습니다. 서버를 가동하는 것이 더 이상 데이터 센터를 요구하지 않게 되면서, 좋은 아이디어와 Stripe 계정만 있으면 누구나 소프트웨어를 월 단위로 판매할 수 있게 된 것입니다.

이것이 바로 여러분의 카드 명세서가 보이는 구조적인 이유입니다.

SaaS가 잘 작동하는 경우

SaaS는 대부분의 경우 올바른 선택입니다. 다음과 같은 상황에서 가장 효과적입니다:

문제가 일반적일 때. 이메일, 급여 처리(payroll), 청구서 발행(invoicing), 팀 채팅, 오류 추적 등. 수많은 회사가 동일한 것을 필요로 하므로, 벤더들이 이미 이를 다듬어 놓았습니다.
그 작업이 여러분의 경쟁 우위가 아닐 때. 아무도 여러분의 회계 소프트웨어 때문에 제품을 선택하지 않습니다.
이번 주에 실행해야 할 때. 초기 단계에서는 적합성보다 속도가 더 중요합니다.
팀 규모가 작을 때. 좌석당 가격(Per-seat pricing)은 5개의 좌석만 있어도 저렴합니다.
규정 준수(Compliance)가 다른 사람의 일일 때. SOC 2와 같은 인증을 보유한 성숙한 벤더는 여러분이 따라잡기 어려울 보안 작업을 이미 완료했습니다.

초기 단계 스타트업에게, 핵심 제품이 아닌 모든 것에 대해 기성품 도구를 구매하는 것이 보통 가장 현명한 움직임입니다. 엔지니어링 시간은 여러분이 가진 가장 희소한 자원입니다. 도움말 데스크(help desk)를 재구축하는 데 시간을 낭비하지 마십시오.

SaaS가 무너지는 경우

SaaS를 채택하기 쉽게 만드는 특성들이 특정 지점에서는 고통스럽게 만듭니다. 일반적으로 문제가 생기는 곳은 다음과 같습니다.

여러분의 워크플로우 자체가 제품일 때

만약 귀사의 비즈니스가 다른 누구도 그렇게 하지 않는 프로세스에 의존한다면, 범용적인 도구들은 여러분이 억지로 맞춰가도록 강요합니다. 결국에는 임시방편(workarounds)을 만들고, 앱들 사이의 격차를 메우는 스프레드시트를 사용하며, 소프트웨어와 싸우는 데 실제 시간을 보내는 팀이 생겨납니다.

처음에는 괜찮습니다. 하지만 규모가 커지면서 비용이 엄청나게 발생합니다.

규모에 따른 사용자당 비용 계산 (Per-Seat Math at Scale)

사용자 한 명당 월 $15인 도구는 6명에게는 아무것도 아닌 것처럼 느껴집니다. 하지만 사용자가 80명이 되면, 같은 도구가 연간 $14,000가 넘게 됩니다. 이것을 열두 가지 도구에 걸쳐 곱하면, 직원을 고용할 때마다 증가하는 의미 있는 비용 항목(line item)을 보게 될 것입니다.

데이터 종속성 (Data Lock-In)

SaaS 제품에 데이터를 넣는 것은 항상 쉽습니다. 하지만 그 데이터를 빼내는 것은 이야기가 다릅니다. 일부 공급업체는 깨끗하게 내보낼 수 있는 기능을 제공합니다. 다른 곳은 관계(relationships)의 절반이 빠진 CSV 파일만 줍니다. 중요한 워크플로우를 특정 도구에 구축하기 전에, 이탈할 경우 어떤 상황이 될지 확인해 보세요.

공유 로드맵, 제로 통제 (Shared Roadmap, Zero Control)

여러분은 기능 요청(feature requests)을 제출할 수 있습니다. 하지만 공급업체가 그것들을 우선순위에 두도록 만들 수는 없습니다. 만약 도구가 여러분의 통합(integration)이 의존하는 API 엔드포인트를 사용 중단(deprecates)한다면, 여러분의 스케줄이 아닌 그들의 일정에 맞춰 적응해야 합니다.

예산 책정하지 않는 구독료 세금 (The Subscription Tax Nobody Budgets For)

표시된 가격은 SaaS 도구 비용 중 가장 작은 부분일 뿐입니다. 숨겨진 비용들은 다른 곳에서 쌓여갑니다:

통합 접착제(Integration glue). 서로 소통하지 못하는 모든 도구는 Zapier 플로우, 웹훅 핸들러(webhook handler) 또는 데이터를 수동으로 복사하는 사람을 필요로 합니다.
맥락 전환(Context switching). 팀원들은 하루 종일 탭 사이를 오갑니다. 이 마찰은 청구서에 나타나지 않더라도 실제적인 문제입니다.
중복 도구(Duplicate tools). 마케팅팀은 하나의 프로젝트 보드를 사용하고, 엔지니어링팀은 다른 것을 사용하며, 둘 다 비용을 지불하게 됩니다.
퇴사 과정의 공백(Offboarding gaps). 활성 계정을 가진 전 직원은 보안 위험이자 청구 누수 지점입니다.
확장된 공격 표면(Expanded attack surface). 여러분의 데이터에 접근할 수 있는 모든 공급업체는 해킹이 발생할 수 있는 또 다른 장소입니다.

6개월마다 신속한 감사(audit)를 진행하세요:

반복되는 모든 소프트웨어 비용 목록을 작성합니다.
각 도구의 소유자가 누구인지, 활성 사용자 수가 몇 명인지 기록합니다.
두 도구가 같은 작업을 수행하는 중복 부분을 표시합니다.
소유자가 없는 도구를 확인하고, 그것부터 취소합니다.

대부분의 팀은 첫 번째 검토만으로도 제거할 수 있는 구독 서비스가 한두 개씩 있다는 것을 발견합니다.

구매(Buy), 확장(Extend), 또는 구축(Build): 결정 순서

새로운 필요성이 생길 때, 이 옵션들을 순서대로 고려하세요. 더 흥미롭게 들린다고 해서 바로 구축으로 뛰어들지 마세요.

옵션 1: 기존 도구 구매(Buy an Existing Tool)

여기서 시작하세요. 성숙한 제품이 사용 사례를 충족한다면, 그것을 사용하세요. 이것은 거의 모든 핵심 기능 외의 부분에 대해 가장 빠르고 저렴한 경로입니다.

옵션 2: 기존 것 확장(Extend What You Already Have)

기존 도구들이 대부분의 필요성을 충족하지만 잘 연결되지 않는 경우, '접착제'를 만드세요. CRM과 결제 시스템을 동기화하는 작은 내부 서비스나 세 개의 API에서 데이터를 가져오는 대시보드가 전체 구축 비용의 일부만으로 간극을 메우는 경우가 많습니다.

옵션 3: 맞춤형 소프트웨어 구축(Build Custom Software)

다음 중 적어도 하나가 사실일 때 구축하세요:

워크플로우가 수익 창출 방식에 핵심적일 경우
현재의 임시방편 구독 비용이 몇 년 동안 맞춤형으로 구축하는 비용을 초과할 경우
기성 도구들이 팀에게 지속적인 수동 우회 작업을 강요할 경우
다른 회사에 판매할 수 있는 격차를 발견한 경우

마지막 지점이 바로 내부 소프트웨어를 구축하는 것이 SaaS 제품을 구축하는 것으로 변모하는 지점입니다. 완전히 다른 게임입니다.

자체 SaaS 제품 구축 전

많은 개발자들이 SaaS가 될 수 있는 사이드 프로젝트를 가지고 있습니다. 대부분은 돈을 벌지 못하는데, 코드가 나빴기 때문인 경우는 드뭅니다. 비즈니스를 먼저 검증하지 않았기 때문입니다.

진지하게 코드를 작성하기 전에 다음 사항들을 검증하세요:

문제는 고통스러워야 합니다. 사람들이 별다른 계기 없이도 그 문제에 대해 불평합니다. 이미 스프레드시트나 임시방편적인 도구로 해결하려고 시도해 봤습니다.
누군가 돈을 지불할 것입니다. 관심(Interest)이 의도(Intent)는 아닙니다. 선주문, 보증금, 또는 구매 의향서(letter of intent)를 요청하세요. 칭찬은 계산에 포함되지 않습니다.
구매자에게 도달할 수 있어야 합니다. 고객들이 온라인상에서 어디에 모여 있는지 모른다면, 그것은 제품 문제가 아니라 유통(distribution) 문제입니다.
가격이 비즈니스를 지탱해야 합니다. 월 $5짜리 도구는 호스팅, 지원, 그리고 당신의 시간을 충당하기 위해 엄청나게 많은 고객을 필요로 합니다.
가장 작은 유용한 버전은 작아야 합니다. 만약 MVP(Minimum Viable Product)가 유용하려면 40가지 기능이 필요하다면, 범위를 재고해야 합니다.

SaaS로 전환될 때 기술적으로 바뀌는 것들

SaaS 제품을 구축하는 것은 앱을 구축하는 것과 같지 않습니다. 몇 가지 요소들이 '있으면 좋은 것(nice to have)'에서 빠르게 '필수적인 것(required)'으로 바뀝니다:

멀티테넌시(Multi-tenancy). 고객 데이터 격리 방식을 초기에 결정해야 합니다: 테넌트 ID를 사용한 공유 테이블, 별도의 스키마, 또는 별도의 데이터베이스. 나중에 이를 끼워 맞추는 것은 매우 고통스럽습니다.
인증 및 권한(Auth and permissions). 팀, 역할, 초대, 대규모 고객을 위한 SSO(Single Sign-On) 등이 필요합니다. 보이는 것보다 항상 더 많은 작업이 필요합니다.
결제 시스템(Billing). 플랜, 체험판, 업그레이드, 비례 배분(proration), 결제 실패 처리, 디닝 이메일(dunning emails) 등을 고려해야 합니다. 결제 제공업체(billing provider)를 사용하세요. 직접 구축하지 마십시오.
관측 가능성(Observability). 고객이
데모 기반 도구 선택. 데모는 성공적인 경로(happy path)만 보여줍니다. 전념하기 전에 실제 워크플로우를 체험판으로 실행해 보세요.
내보내기 옵션 무시. 떠나려고 할 때가 아니라, 첫날부터 데이터 이식성(data portability)을 확인하세요.
고객과 대화하기 전에 구축. 당연하게 들리지만, 여전히 SaaS 사이드 프로젝트가 실패하는 가장 큰 이유입니다.
저가 책정. 저렴한 플랜은 빠르게 이탈하고 가장 많은 지원이 필요한 고객들을 끌어들입니다.
온보딩을 사후 고려 사항으로 취급. 신규 사용자가 첫 세션에서 가치를 얻지 못하면, 대부분 돌아오지 않습니다.
출시 전 마케팅 건너뛰기. 잠재 고객(audience)은 구축하는 동안 몇 달이 걸립니다. 구축하는 동시에 글을 쓰고, 공유하고, 이메일 주소를 수집하기 시작하세요.

더 넓은 비즈니스 관점을 원하십니까?

본 게시물은 의사 결정의 개발자 및 창업가 측면에 초점을 맞추고 있습니다. SaaS 대 전통 소프트웨어 비교, 일반적인 가격 모델, 공급업체와 계약하기 전 보안 점검 사항, 그리고 외부 도움이 적절한 실제 비즈니스 시나리오를 다루는 더 완전한 분석을 원한다면, Razen Creations LLC 팀이 상세한 글을 작성했습니다: What Is SaaS? A Complete Guide for Businesses and Startups.

기술적이지 않은 공동 창업자나 전체 그림이 필요한 고객과 공유하기 좋은 참고 자료입니다.

마무리하며

SaaS는 소규모 팀이 필요로 하는 대부분의 것에 적절한 기본값(default)입니다. 하지만 워크플로우 자체가 경쟁 우위가 되거나, 사용자당 비용이 맞춤형 구축을 초과하거나, 해결책을 팔 가치가 있는 문제를 발견했다면 더 이상 적절한 기본값이 아닙니다.

다음으로 할 일은 다음과 같습니다:

이번 주에 현재 구독 목록을 감사하고 소유자가 없는 것은 모두 취소하세요.
다음 소프트웨어 필요 사항에 대해서는 구매(buy), 확장(extend), 구축(build) 순서로 접근하세요.
자체 SaaS 출시를 고려하고 있다면, 결제 코드를 작성하기 전에 유료 고객 약정 하나를 확보하세요.

솔로 빌더라면 3단계부터 시작하세요. 성장하는 팀을 운영하고 있다면 1단계부터 시작하세요. 어느 쪽이든, 기본값에 의존하기보다 목적을 가지고 결정하세요.