장진서

장진서님의 아티클

장진서

장진서

SaaS에 대한 확신과 용기가 필요한 분들께

오늘은 주간SaaS 오리지널 아티클 입니다.

지난 5월에 첫번째 주간SaaS 오리지널에서 B2B SaaS를 만드는 사람들을 위한 추천 책 이라는 제목으로 B2B SaaS에 관한 책을 추천했습니다. 다소 주관적인 의견이 담긴 도서 목록이지만 개인적으로 정말 많은 배움을 얻었던 책들 입니다.

아메리칸 익스프레스 카드를 연상시키는 책표지(출처: 교보문고) 클릭해서 이미지를 올려주세요

책의 표지에 마크 베니오프의 사진이 자리 잡고 있어 세일즈포스닷컴을 창업하고 지금까지의 시간 동안 굵직한 이벤트와 기억을 중심으로 담은 자전적인 이야기겠거니 생각했는데 사실 이 책은 10가지의 비즈니스 전략을 챕터 제목으로 구성되어 있습니다. 이 10가지 비즈니스 전략에는 스타트업 전략을 시작으로 마케팅, 이벤트, 영업, 기술, 사회 공헌, 글로벌, 재무, 리더쉽, 마지막 비밀 전략이 포함되어 있습니다. 그리고 이 10개의 전략들에 세일즈포스닷컴이 탄생하고 성장의 단계를 거치며 부딪히고 해결해야 했던 많은 문제와 도전과정에서 얻은 교훈과 비결 111가지를 더했습니다. 이론과 실전 그리고 실증 예제가 더해진 느낌이랄까요. 그래서 읽으면서 이런 생각이 듭니다. 마치 “SaaS를 의심하는자, 우리를 믿고 앞으로 나아가라"

닷컴 시대의 실리콘밸리의 풍경화

이 책이 흥미진진 하다고 말할 수 있는 이유는 감수자께서도 책에서 언급 했듯이 지금의 사람들이 직접 경험할 수 없는 닷컴 시대 초기의 실리콘밸리의 풍경화를 그것도 그 시대를 살며 성공을 그린 마크 베니오프가 그렸기 때문일 겁니다.

전형적인 캘리포니아 스타트업 회사의 모습이었다. 사무실에는 강아지가 한 마리 있었고 프레첼, 레드 바인스의 감초 사탕 그리고 육포를 먹으며 살아가는 하와이언 셔츠 차림의 에너지 넘치는 젊은이들이 가득했다. 전형적인 닷컴 회사 스타일로 우리는 폭발하듯 성장했다.

책의 내용 중

마크는 실제로 달라이라마에 심취해 있었다고 한다. 1999년 세일즈포스 시작 즈음의 사무실 모습(출처: https://rapitek.com/en/blog/short-history-salesforce-and-salesforcecom/)

보통 출간 된지 오래된 원서의 경우 출판사가 번역을 꺼리는 것으로 아는데 이 책은 원작이 출간 된지 21년 만인 2021년 한국어 번역서가 출간되었습니다. 원서와 번역서 사이의 시간이 길 수록 원서의 혜안이 현재에 적용 되기에는 진부하거나 사실들이 바뀌는 경우가 많을 수 있는데 이 책에 담겨진 내용은 개인적으로 버릴 내용이 하나 없을 뿐 아니라 흥미진진해서 읽는 재미도 선사하는 책입니다.

SaaS 그리고 멀티테넌시에 대한 강한 믿음

세일즈포스닷컴이 세상에 처음 나오던 때 서비스형 소프트웨어(SaaS)와 클라우드 컴퓨팅에 대한 세상의 인식의 수준이 굉장히 낮은 상태였습니다. 그래서 그들은 클라우드 컴퓨팅 기반의 서비스형 소프트웨어를 만드는 도전뿐 아니라 서비스형 소프트웨어 모델에 대한 회의론자들을 설득해야 하는 더 큰 도전을 해야 했습니다. 그들의 의견에 반대하고 회의를 갖는 사람들을 대상으로 설득하고 결과를 만들어낸 비결이 책에 담겨 있어 같은 과정을 겪고 있는 많은 SaaS 빌더들에게 좋은 참고가 되지 않을까 생각 됩니다.

“게다가 사람들은 현재 시스템에 무척 불만이 많아요. 이게 훨씬 나을 겁니다. 우리 애플리케이션으 이용하기 쉽도록 웹사이트를 통해서 전달될 거예요. 마치 아마존이나 야후 만큼이나 쉬울걸요. 처음 부터 엄청난 투자를 요구하지도 않죠. 이 콘셉트는 한 달에 한 사용자 당 50달러만 내면 되는 단순한 모델이에요. 시벨을 이용하는 사람들이 지불하는 비용의 10퍼센트에 불과하고 시벨과는 다르게 평생 고객을 얻을 수 있는 거죠”

“그 시벨은 어떻게 할거죠? 그 회사의 높은 점유율이 두렵지 않나요?” 데이브가 물었다.”

“다른 회사가 끼어들 자리가 있을까요? 시벨은 대부분의 회사를 만족시키지 못합니다. 인터넷을 통해 우리는 현존하는 모든 회사들에게 큰 비용이 들지 않으면서 즐겁게 이용할 수 있는 대안을 제공하는 거죠. 인터넷은 엄청난 힘과 가능성을 통해 오늘날에 건재한 클라이언트-서버 모델을 쓰는 회사를 전부 다 파멸 시킬 겁니다. 기술은 언제나 저렴해지고 사용하기 쉬워지고 있어요. 연속체란 말이죠. 우리 전부 여기에 탑승합시다”
책의 내용 중

내부 팀원을 설득하는 과정을 담은 대화 중에 거론되는 시벨이라는 회사는 시벨시스템즈를 말합니다. 실제로 마크 베니오프는 시벨시스템즈의 설립자 톰 시벨과 오라클에서 함께 오래 일했던 사이라고 합니다. 그리고 마크 베니오프가 자신이 가지고 있던 SaaS 서비스에 대한 아이디어를 먼저 시벨을 창업한 톰 시벨에게 이야기 했을때 톰은 마크의 아이디어를 흥미로워 하며 톰 시벨로 오라는 제안까지 했다고 합니다. 하지만 SaaS에 대한 가치를 작게 생각 하는 것 같아 마크는 그 제안을 거절 했다고 합니다. 나중에 세일즈포스닷컴의 서비스형 소프트웨어가 시장에 소위 통하며 성공을 만들어 나가는 중에도 시벨시스템즈는 기존 소프트웨어 공급 방식을 고집하며 서비스형 소프트웨어 모델에 대해 회의적 이었던것 같습니다. 실제로 서비스형 소프트웨어 모델을 추진하다 2001년 해당 사업부를 철수 한걸로 알려져 있습니다.

(*참고: 시벨시스템즈는 결국 2005년 오라클에 인수 됩니다 . 오라클 출신의 기업이 다시 오라클 품으로 인수되는 결과 였는데요, 오라클맨 마크는 이 인수를 두고 혹평을 했습니다.)

용기 있게 혁신을 밀어 붙여라

SaaS 나아가서 클라우드 컴퓨팅 모델은 당시에도 쉽게 받아들이기 어려웠던것 같습니다. 세일즈포스닷컴 역시 클라우드 컴퓨팅과 SaaS모델에 대해 사람들이 가지는 불신과 오해를 해결하기 위해 많은 노력을 기울였는데 이 때 무엇보다 중요한 것은 나 그리고 팀 모두가 이 혁신에 대한 믿음과 용기일겁니다. 나조차 확신이 없다면 다른 사람을 설득하기 어려울테니 까요.

그런 맥락으로 마크 그리고 그의 팀은 SaaS모델의 근간이 되는 멀티테넌시에 대한 믿음이 확고 했습니다.

이 서비스는 100퍼센트 세일즈포스닷컴이 호스팅하는 하나의 커다란 로직 시스템이었고 새로운 고객과 신청자들이 이 서비스를 사용하면 역동적으로 규모가 확장되는 방식이었다. 이것은 고객들에게 공통 역량(데이터베이스 엔진과 같은 IT 자산, 디스크 공간, 보안 등)을 공유함으로써 위험과 비용을 절감시킬 수 있는 이점을 제공해 주었다. 동시에 각 고객은 안전학게 구분되어 있으면서 자기 자신의 데이터, 논리 그리고 최종 사용자 경험으로 고도의 개인 맞춤화된 경험을 누릴 수 있었다. 우리는 이 기술 모델을 ‘멀티테넌시multitenancy’라고 한다.책의 내용 중

SaaS로 인해 소프트웨어 종말을 예고하는 마크 베니오프(출처: https://rapitek.com/en/blog/short-history-salesforce-and-salesforcecom/)

멀티테넌시 기반의 SaaS를 만들다 보면 많은 유혹과 도전에 직면 합니다. 대표적으로 현실과 타협과 아키텍처 또는 제품 포트폴리오를 갖추라는 유혹이 있습니다. 가령 특정 고객에게는 멀티테넌시, 특정 고객에게는 통제권 전부를 제공하는 형태 같은것 말이죠. 세일즈포스닷컴 역시 이 유혹과 도전에 직면 했습니다.

똑같은 우려의 목소리를 계속 반복해서 들었다. 그건 통제권을 넘기는 것에 대한 공포였다. 나는 그 두려움이 이성적이라기 보다는 감정적이라는 생각이 들었지만 그건 우리에게 또 다른 선택지를 제공하라는 압력을 불러 일으켰다. 벤처 캐피털리스트들은 우리가 선택지가 있는 기술 모델을 만들어야 한다는 주장을 했다. 작은 회사들에게는 회사 서버가 호스팅 하는 모델을 제공하고 큰 회사들에게는 전통적인 회사가 제공하는 것과 비슷한 사내 패키지 소프트웨어를 선택할 수 있게 해주는 것이었다. 하지만 우리는 그건 절대로 안 될 일이라는 결론을 내렸다. 위험을 분산시키는 것이 때로는 신중한 결정일 수 있지만 만약에 우리가 선택지를 제공한다면 우리의 아이디어는 절대 성공할 수 없었기 때문이었다. 그렇게 하면 모든 것을 망칠 수도 있었다. 온디맨드 모델하에서 모두가 이익을 누리기 위해서는 고객들 전부가 한 버전을 공통으로 이용해야 했다. 그래야만 가능한 이점들인 지속적인 유지 혹은 업그레이드를 실행했을 때 모두가 동시에 똑같은 구성 요소를 이용할 수 있었다.

책의 내용 중

책에서 마크가 아마존에 대한 이야기를 자주 거론합니다. 인터넷 기술을 바탕으로 전에 없던 리테일 혁신을 만든 아마존의 컨셉이 부터 전에 없던 서비스형 소프트웨어를 목표로 하는 마크에게 많은 영감과 용기를 주었던것 같습니다.

잠을 자다가 세일즈포스닷컴에 대한 아이디어가 떠올랐다. 아마존이긴 한데 책,CD,DVD 대신에 계정, 연락처, 기회, 전망, 보고서라고 적힌 탭이 있는 웹사이트에 대한 이상한 꿈을 꿨다.

책의 내용 중

마크에게 영감을 준 아마존의 웹페이지 탭 도입 초기 모습(출처: https://www.versionmuseum.com/history-of/amazon-website) 클릭해서 이미지를 올려주세요

기술적인 패러다임을 초월하라

B2B SaaS가 직면하는 많은 도전 가운데 하나는 고객의 다양한 요구 사항 수용, 즉 커스터마이징 입니다. 어느 정도의 커스터마이징을 허용할지 그리고 이를 위해 어떤 기술적인 준비를 해야 할지 정답이 있다면 좋겠지만 아쉽게도 없습니다. 그래서 다양한 시도와 연구가 있기도 합니다.

세일즈포스닷컴 역시 같은 고민을 합니다. 고객에게 자유도를 많이 줄 수록 더욱 많은 고객을 유치 할 기회도 얻을 수 있기 때문입니다.

플랫폼형 소프트웨어 PaaS에 대한 내 믿음은 매우 낙관적이었지만 그 아이디어를 실행시킬 것이지 말 것 인지에 대한 결정은 쉽지 않았다. 우리가 과연 인터넷 운영 시스템을 만들 수 있을까? 다른 사람의 코드를 우리의 시스템에서 운영할 수 있게 하는 것은 잠재적으로 커다란 호환성 관련 위험이 존재했다. 게다가 고객들이 시스템을 신뢰할 수 있을 지도 장담할 수 없었다.

결정하고 구매할 일들이 너무 많았다. 네트워크 장비, 저장 시스템, 데이터베이스, 오픈 소스 데이터베이스, 데이터 센터까지. 그리고 그건 겨우 스타트업 소프트웨어를 만들 때의 고려 사항에 불과했다. 소프트웨어를 만들고 나서는 다양한 언어로 동작하는 지 다양한 장비에서 작동하는 지 확인해야 했고 그 외 다른 문제점들도 있었다. 그 이후에는 인증이나 유용성 같은 기술 문제들도 다뤄야 했다.

책의 내용 중

세일즈포스닷컴은 결국 고객에게 더욱 많은 자유도를 주는 기술 전략을 선택하고 이 전략을 바탕으로 서비스형 소프트웨어에 이어 플랫폼형 소프트웨어 PaaS를 현실로 만듭니다. 고객들은 원하는 기능이 담긴 애플리케이션을 세일포스가 제공하는 프로그래밍 언어인 Apex를 통해 만들 수 있게 됩니다. 이것은 나중에 그들의 생태계를 구축하는데 큰 중심축이 되기도 합니다.


책을 읽는 동안 밑줄 그은 부분이 참 많았지만 모두 소개 하지는 못했습니다. 이 책은 SaaS를 만들며 많은 난관에 부딪히고 계신 분들께 용기와 확신 그리고 훌륭한 조언을 줄 수 있는 내용을 담고 있습니다. 오늘 주간SaaS에서는 책에 담긴 10개의 전략 챕터들 가운데 기술 전략 챕터 중에 뽑은 인상 적인 부분들을 중심으로 소개 했지만 꼭 한번 시간내어 읽어 보시면 좋겠습니다!

주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

7
0
장진서

장진서

SaaS 빌더들을 위한 컨퍼런스, SaaS Talk

주간 SaaS 는 B2B SaaS 비즈니스 모델과 기술을 만드는 사람들을 위해 좋은 B2B SaaS 콘텐츠를 선별해 제공하는 뉴스레터 입니다. 그런데 이번에는 조금 색다른 형태의 콘텐츠를 제공하려고 합니다. 바로 SaaS 를 만들어가는 사람들 위한 SaaS 컨퍼런스, SaaS Talk 입니다.

2023년 7월 4일 화요일 오후에 진행할 네 번째 SaaS Talk 는 시장에서 B2B SaaS 를 만들고 있는 세 개의 B2B SaaS 기업과 함께 SaaS 여정의 경험과 인사이트를 나누려고 합니다.



SaaS Talk 무엇이냐면

SaaS Talk 는 시장에서 SaaS 를 만들어가는 여러분들이 주인공이 되어 SaaS 여정에서 겪은 경험, 시행 착오, 통찰, 지식을 함께 나누고 성장하는 힘을 얻는 SaaS 컨퍼런스 를 만들자는 목표로 2022년 부터 시작 되었습니다.

SaaS Talk 는 C-level, Product Manager, 엔지니어, 기획자, 디자이너 등등 SaaS 를 만들어가는 사람들이라면 누구나 함께 할 수 있습니다.

SaaS Talk 가 지향하는 테마는 Learn, Share, Networking 입니다. SaaS 기술, 비즈니스에 관한 지식과 경험을 배우고, 나누며 서로를 알아가는 컨퍼런스 테마를 지향 합니다.

SaaS Talk 를 통해 함께 나누고자 하는 이야기는 이렇습니다.

SaaS 기술

  • 멀티테넌시
  • SaaS 를 위한 DevOps
  • SaaS 를 위한 모니터링
  • SaaS 개발 경험
  • 애자일
  • ...

SaaS 비즈니스

  • SaaS 가격 모델
  • SaaS MVS 전략
  • SaaS GTM 전략
  • SaaS 비즈니스 메트릭
  • SaaS Product led growth
  • SaaS 모델을 위한 조직 구조
  • SaaS 고객 Engagement model
  • 전통적인 SW 모델에서 SaaS 로의 전환
  • SaaS 매출 모델
  • ...

이외 에도 SaaS 서비스 빌딩 과정에서 겪은 경험, 지식, 통찰을 함께 나눌 수 있는 주제라면 무엇이든 함께 나누고자 합니다.

그래서 결론은...


구독자 님 네번째 SaaS Talk 에 초대 합니다!

한정된 좌석으로 등록이 일찍 마감 될 수 있으니 참가를 희망하시는 분들은 서둘러주세요! 🥹

지금 바로 SaaS Talk 참가 등록

SaaS Talk 상세 페이지

참고

- SaaS Talk 는 AWS 서비스 홍보 행사가 아님을 말씀 드립니다.

- 한정된 좌석으로 등록이 조기 마감될 수 있습니다.

- 세부 아젠다와 시간표는 곧 아래 SaaS Talk 상세 페이지에 다시 업데이트 됩니다.

- 지난 SaaS Talk 영상은 이곳에서 볼 수 있습니다.

SaaS Talk

SaaS 빌더들을 위한 국내 첫 SaaS 컨퍼런스

4
0
장진서

장진서

B2B SaaS 를 만드는 사람들을 위한 추천 책

주간 SaaS 는 좋은 B2B SaaS 에 관한 좋은 콘텐츠를 발굴해 제공하는 뉴스레터 입니다. 앞으로는 주간 SaaS 오리지널 이라는 이름으로 주간 SaaS 가 직접 작성한 콘텐츠를 Mix 할 계획 입니다.

첫번째 주간 SaaS 오리지날 은 “B2B SaaS 만드는 사람들을 위한 필독서” 입니다. 사실 이 책 들을 공개 할까 말까 고민을 좀 했습니다. 추천 기준에 개인적인 의견이 듬뿍 들어가 있기도 하고 제 씨간장을 나눠 주는것 같았거든요🥹. 그 만큼 B2B SaaS 를 일로 하는 제가 너무나도 큰 은혜를 받은 책 이기도 합니다.

오늘 추천 하는 책을 모두 읽으실 분이라면 아래 소개 하는 순서대로 책을 완독 하시기를 추천 드려요. 왜냐하면 as a Service 모델을 바로 이해한 다음 큰 그림을 그리고 가격, GTM, 세일즈 등에 관한 세부 요소에 대한 전략을 그리실 수 있을거라 생각되기 때문입니다. 저 역시 그랬거든요.

오늘은 다소 비즈니스모델, GTM, 가격, 세일즈에 관한 책을 소개하지만 반응이 좋다면 Product Management 관점의 도서도 추천 해보겠습니다.

--

Disclaimer

책 추천을 통해 출판사, 저자, 판매자로 부터 어떠한 금전적,물질적 지원을 받지 않은 내돈내독 인 점을 밝힙니다.

 

Technology-as-a-Service Playbook: How to Grow a Profitable Subscription Business

이미지: Amazon

대학 전공 기초 과목 교재로 사용 되는 ㅇㅇ개론, ㅇㅇ원론 과 같은 책이 아닐까 생각 된다. 조금 더 과장을 허락한다면, B2B SaaS 비즈니스를 하려는 사람들이라면 반드시 읽어야 하는 바이블 같은 도서라고 생각 된다.

초판이 2016년인 이 책이 2023년 B2B SaaS 일을 하는 사람들에게 여전히 좋은 인사이트와 지식을 줄 수 있는 이유는 As a Service 모델의 핵심을 다루고 있기 때문이다. 엇 그런데 왜 SaaS 가 아니라 as a Service 모델의 핵심이라고? as a Service 모델 앞에 Software 가 붙든 DB 가 붙든 as a Service 비즈니스 모델을 근간으로 삼고 있기 때문이다. 그래서 이 챌은 XaaS 라는 용어를 사용한다.

이 책은 개념을 알려줄 뿐 아니라 실제로 우리의 Case 에 적용하려면 어떻게 접근하고 무엇을 해야 하는지 고민할 수 있는 기회를 주는 Playbook을 각 챕터 마다 배치하고 있어 더욱 유용하게 활용할 수 있다.

이 책은 as a Service 비즈니스 모델을 만들 때 고려해야 하는 프레임워크, as a Service 모델의 재무 핵심, as a Service 모델의 제품 포트폴리오 프레임워크, 그리고 정말 정말 나만 알고 싶은 as a Service 모델이 가져가야 하는 고객 인게이지먼트 모델과 이에 따른 조직 구성 내용이 벤치마크 데이터와 실제 사례와 함께 제공한다.

이 책이 초판된 2016년 이후 나온 유명 as a Service 기업가들이 이 책의 도움을 많이 받지 않았을까 생각된..본인의 뇌피셜이다. 뇌피셜을 팩트로 생각할 만큼 훌륭하고 유용한 책이다. 

개인적으로 이 책을 B2B SaaS를 만드는 사람들 뿐 아니라 as a Service 기업에 근무하는 주변 사람들에게도 추천한다. 이유는 as a Service 라는 업 을 제대로 이해할 때 보다 회사의 비전과 철학에 정렬(alignment)되어 목표를 달성할 수 있기 때문이다.

Monetizing Innovation: How Smart Companies Design the Product Around the Price

이미지: Wiley

아마도 B2B SaaS 를 만드는 사람들이 갖는 가장 큰 고민과 궁금증이 “어떻게 SaaS 가격 책정 하나요” 아닐까 생각한다. SaaS 가격 책정, 전략, 접근 방법, 이론 등 에 관한 자료가 이미 너무 많지만 이를 어떻게 적용해야 할지 무엇부터 시작해야 할 지 막막하다. 제목 부터 가슴이 웅장해지고 실웃음이 나오는 제목의 이 책이 막막함을 거둬 주리라 믿는다.

사실 이 책이 모두가 원하는 촌철살인 같은 정답을 내어주지 않는다. 그럼에도 불구하고 이 책이 독자에게 충분한 힌트와 용기를 준다고 믿는 이유는 “가치를 기반으로 가격을 정해야 한다. 경쟁 가격에 휘둘리면 안된다” 와 같이 뻔한 훈수만 두는게 아니라 그럼 가치를 기반으로 가격을 정할 때 원칙, 자문해봐야 하는 질문, 단계 별 해야 하는 일 들을 차근차근 하게 알려주기 때문이다.

이 책이 갖는 Wow moment 는 이거다. 보통 가격을 정할 때 제품을 만들고 나서 혹은 어느 정도 만들고 가격 전략을 고민한다. 이 책은 “그-러-지-마” 라고 말한다. 가격을 정하고 제품을 만들라고 말한다. 그래서 아주 이른 시점 부터 고객과의 소통을 통해서 고객이 원하는 제품 그리고 고객이 이 제품이 기꺼이 지불할 의사가 있는 금액(Willing To Pay) 을 찾을 것을 강조한다. 물론 강조만 하는게 아니라 고객이 원하는 제품이 무엇인지, 지불할 의사가 있는 금액이 얼마인지 찾아가는 방법을 구체적으로 안내 한다. 또한 이 책은 단지 가격을 찾는 것을 넘어 최대의 매출과 수익을 얻기 위한 번들링/패키징 전략 역시 소개 한다.

책 곳곳에서 저자가 말하는 주장을 뒷받침 하는 실제 기업 사례(포르쉐, 옵티마이즐리, etc)가 포함되어져 있어 이 책을 끝내고 나면 우리 역시 결국 가격 전략에 대한 답을 찾을 거라는 믿음과 용기가 생긴다. 

생존을 넘어 번창으로 스타트업 창업과 경영 A-Z

이미지: 예스24

가슴 뛰는 제목을 가진 이 책은 B2B 스타트업을 위한 책이다. 스타트업을 위한 책이라고 하면 “우리는 스타트업 아니니까” 하는 분들 위해서 다시 말하면 B2B 비즈니스를 하려는 혹은 하고 있는 기업이라면 모두에게 도움이 될 책 이다.

이 책은 먼저 B2B 기업의 여정을 생존과 번창 이라는 관점에서 창업-제품/시장 최적화-시장 진출 최적화-영역 리더로 가속화-지속 가능한 업종 리더 의 단계로 나눈다. 그리고 각 단계 별로 어떤 변화가 펼쳐질지 그리고 그 변화 속에서 기업은 무엇을 어떻게 해야 하는지 정말 진심어리게 조언한다.

이 책이 더욱 가치있게 느껴지는 이유는 B2B 기업의 성장에 있어 매우 매우 중요하지만 그 동안 이를 구체적으로 다룬 책이 없었던 시장 진출 최적화(Go To Market Fit)에 대해서 소개 하기 때문이다.

실제로 저자가 창업한 모빌아이언이 생존을 넘어 번창으로 성장하는데 활용한 시장 진출 플레이북을 자세히 설명하고 있다. 이 책에서 소개하는 시장 진출 최적화에 관한 방법과 플레이북은 실제로 다수의 스타트업들이 채택해 그 효과를 보고 있다고 알려져…여기까지. 너무 많이 나누면 내 씨간장이 장독이 바닥을 드러낼까 봐 이만.

챌린저 세일

이미지: 예스24

“성공적인 B2B SaaS 를 만들기 위해서 필요한 것 중 가장 중요한 것은?” 이라고 질문을 받는 다면 세일즈 라고 말하겠다.(*나는 테크 가이 이지만) 그럼 B2B 영업은 어떻게 해야할까?

이 책은 B2B 영업에 대한 마인드셋을 제품 기반 영업에서 솔루션 기반의 영업으로 바꿀 필요가 있다고 말한다. 즉 영업 사원이 단순히 고객의 요구 사항을 정확히 파악해 신뢰할 만한 제품을 제공하는데 그치지 않고 고객이 놓치고 있는 새로운 관점과 위험 요소를 발견해 요구 사항에 대한 해결 뿐 아니라 고객 비즈니스의 성공을 이끌 수 있도록 통찰력을 제공해야 한다고 이야기 한다. 그리고 이를 챌린저 세일 이라고 말한다.

저자는 챌린저 세일을 위해 B2B 영업 사원에게 아래의 모습이 기대된다고 말한다.

  • 고객에게 고유의 관점을 제공
  • 뛰어난 커뮤니케이션 능력
  • 고객의 핵심 가치 파악
  • 고객 비즈니스의 핵심에 대한 경제적 가치 파악
  • 고객을 압박 할 수 있는 능력

그리고 모습을 바탕으로 

  • 고객을 가르치고
  • 고객에게 맞추어 제안하고
  • 영업 주도권을 확보하라

고 말한다. 

여기 까지 들으면 “쉽지 않겠는데…” "정말 저렇게 한다고?" 라는 생각이 절로 들 수 있다. 그런데 실제로 가까운 as a Service 의 세일즈 역할을 하는 분들로 부터 챌린저 세일즈 모습을 찾을 수 있다. 야너두 야나두 라는 이야기다. 챌린저 세일을 하기위한 절차와 절차별 action item을 다이어그램과 함께 자세히 설명 하고 있어 이 책을 다 읽고 나서 분명 "야나두" 라는 생각이 들거라 확신한다.

 

주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

3
2
장진서

장진서

멀티테넌트 데이터베이스 성능 보장을 위한 격리(isolation) 설계 방법

Cloudflare 정도 규모에서 운영한다는 것은 기술 스택 전체에서 다양한 부하 조건을 처리하는 데 많은 시간을 들여야 한다는 것을 의미합니다. 이번 블로그에서는 Postgres 클러스터로 성능 문제를 해결한 방법에 대해 설명합니다. 이러한 클러스터는 많은 수의 테넌트와 매우 가변적인 부하 조건을 지원해야 하기 때문에 테넌트가 다른 테넌트로부터 너무 많은 자원과 시간을 빼앗기지 않도록 테넌트 활동을 격리해야 할 필요가 있습니다.

저는 Cloudflare의 인턴으로서 데이터베이스 클러스터가 부하 상황에서 작동하는 방식을 개선하고 그 결과를 담은 코드를 오픈 소스화하는 작업을 하게 되었습니다.

Cloudflare는 데이터 센터의 여러 지역에 걸쳐 Postgres 클러스터를 운영합니다. DNS Resolver, 방화벽, DDoS 보호와 같은 초기 서비스 중 일부는 OLTP 워크로드를 위해 Postgres 클러스터의 고가용성에 의존하고 있습니다. 고가용성 클러스터 매니저인 Stolon은 모든 클러스터에서 사용되어 Postgres 인스턴스 전반에서 데이터를 독립적으로 제어 및 복제하고, 부하가 높은 시나리오에서 Postgres leader 를 선출 하고 Fail-over 합니다.

PgBouncer와 HAProxy는 각 클러스터에서 게이트웨이 계층의 역할을 합니다. 각 테넌트는 Postgres 로 부터 직접 연결하지 않고 PgBouncer로 부터 클라이언트 측 연결을 획득합니다. PgBouncer는 Postgres에 대한 최대 connection pool 을 보유하며, 여러 테넌트에 걸쳐 이를 할당하여 Postgres 연결 고갈을 방지합니다. 연결이 이루어지면 이제 PgBouncer는 쿼리를 HAProxy로 전달하고 HAProxy는 Postgres primary와 읽기 복제본에 걸쳐 쿼리에 대한 로드 밸런싱을 합니다.

cloudflare 멀티 테넌트 데이베이스 아키텍처

문제

Cloudflare의 멀티테넌트 Postgres 인스턴스들은 컨테이너화 되지 않은 환경의 베어메탈 서버에서 작동합니다. 각 백엔드 애플리케이션 서비스는 하나의 테넌트로 간주되며, 이 테넌트는 여러 역할로 나뉜 Postgres 인스턴스 중 하나를 사용할 수 있습니다. 각 클러스터가 여러 테넌트를 지원하기 때문에 모든 테넌트는 각 클러스터 컴퓨터에서 CPU 시간, 메모리, 디스크 IO와 같은 사용 가능한 시스템 리소스는 물론 서버 측 Postgres connection pool 및 table lock 같은 유한한 데이터베이스 리소스를 공유하고 서로 경합을 벌입니다. 각 테넌트는 다양한 시스템 수준 리소스 사용량 특징을 갖는 워크로드를 가지고 있으므로 공통적인 전역 값을 사용하여 데이터베이스 사용을 스로틀링(Throttling)하는 것이 불가능합니다.

이런 상황은 저희 운영 환경에서 인접 이웃 테넌트에 영향을 미치는 문제가 되었습니다. 문제들은 이것들 입니다:

  • 처리량(Throughput): 한 테넌트가 트랜잭션을 대량으로 발행하여 다른 테넌트의 공유 리소스를 고갈시키고 성능을 저하시킬 수 있습니다.
  • 지연 시간(Latency): 단일 테넌트가 ETL 추출을 위한 대규모 테이블 스캔이나 긴 테이블 잠금이 있는 쿼리와 같이 매우 길거나 비용이 많이 드는 쿼리를 동시에 실행할 수 있습니다.

이 두 가지 시나리오 모두 인접한 이웃 테넌트의 쿼리 실행을 저하시킬 수 있습니다. CPU 공유 시간 감소 또는 오작동하는 테넌트의 빈번한 데이터 탐색으로 인해 디스크 IO 작업 속도가 느려져 트랜잭션이 중단되거나 실행 시간이 상당히 오래 걸릴 수 있습니다(지연 시간 증가). 또한, 기존 테넌트가 오래 수행되고 비용이 많이 드는 쿼리를 실행 하느라 대기 중인 다른 테넌트가 데이터베이스 프록시 수준(PgBouncer)에서 데이터베이스 연결을 획득하지 못하도록 차단될 수 있습니다.

이전 해결책

데이터베이스 클러스터 부하가 크게 증가하면 어떤 테넌트가 이 부하에 대한 원인을 제공하는 찾는 것이 가장 먼저 해결해야 할 과제입니다. 이를 위한 몇 가지 기술이 있는데 예를 들어 모든 테넌트의 이전 쿼리를 검색하고 Postgres의 pg_stat_activity view 에서 비용이 많이 드는 새로운 쿼리가 요청 되었는지 확인하는 방법이 있습니다.

데이터베이스 동시성/연결(connection) 스로틀링(Throttling)

비정상적인 테넌트가 식별되면 Postgres 쿼리를 사용하여 Postgres 서버 측 연결 제한을 수동으로 적용합니다.

ALTER USER "some_bad-user" WITH CONNECTION LIMIT 123;

이렇게 하면 기본적으로 단일 사용자의 동시 처리량을 제한하거나 "압박(Squeezes)"하게 되며, 각 테넌트는 자신의 몫으로만 할당된 연결만을 소진할 수 있습니다.

이런식의 수동 동시성/연결(connection) 스로틀링은 프로덕션 워크로드가 많은 동안 Postgres의 부하를 줄이는 데 개선 효과를 보여주었습니다:

이 접근 방식은 성공을 거두긴 했지만 완벽하지 않고 끔찍한 수작업으로 적용됩니다. 또한 다음과 같은 문제도 있습니다:

  • 새 사용자 제한이 설정되면 Postgres는 기존 테넌트 연결을 즉시 종료하지 않으며, 사용자는 계속해서 버스트 쿼리 또는 고비용 쿼리를 발행할 수 있습니다.
  • 테넌트는 동시성(connection pool 크기)이 줄어든 경우에도 여전히 매우 비싸고 리소스 집약적인 쿼리(인접 이웃 테넌트에 영향을 미침)를 실행할 수 있습니다.
  • 잘못된 행동을 하는 테넌트에 대해 수동으로 연결 제한을 적용하는 것은 번거로운 작업이며, 하루 중 언제든지 SRE 팀을 호출하여 물리적으로 새 제한을 적용해야만 합니다.
  • 특히 인시던트 발생 시 쿼리를 기반으로 잘못된 동작을 하는 테넌트를 수동으로 분석하고 탐지하는 작업은 프로덕션 수준의 SQL 분석 경험이 있어야 하므로 시간과 스트레스가 많이 소요될 수 있습니다.
  • 또한 할당된 연결 수와 같이 user/pool 단위로 새로운 스로틀링 제한을 적용하는 것은 임의적이고 실험적일 수 있으며 테넌트 워크로드에 대한 광범위한 이해가 필요합니다. (*즉 테넌트의 워크로드 편차에 대한 고려가 누락될 수 있음)
  • 때때로 Postgres는 너무 많은 부하를 받아 중단(hang)되기 시작할 수 있습니다(CPU 고갈). 이런 상황에서 SRE팀은 과부하 상황 해소를 위해 기본 인터페이스를 통해 테넌트를 수동으로 조절을 시도하지 못할 수 있습니다.

새로운 해결책

게이트웨이 동시성/연결(Connection) 스로틀링(Throttling)

일반적으로 쿼리의 시스템 수준 리소스 소비는 실행을 위해 서버 또는 데이터베이스 시스템에 제출된 후에는 제어 및 격리하기가 어렵습니다. 그러나 일반적인 접근 방식은 게이트웨이 계층에서 연결 또는 쿼리를 차단하고 스로틀링하여 시스템 리소스 소비에 따라 사용자별/풀 트래픽 특성을 제어하는 것입니다.

저희는 데이터베이스 프록시 서버/연결 풀링을 관리하는 PgBouncer 레벨 에서 연결 스로틀링을 구현했습니다. 이전에는 PgBouncer의 사용자 수준 연결 제한이 기존 연결을 종료하지 않고 제한을 초과하는 것만 방지했습니다. 하지만 이제 설정을 통해 정적으로 또는 새로운 관리 명령을 통해 런타임 중에 각 사용자 또는 각 사용자의 연결 풀이 소유한 기존 연결을 스로틀링하고 종료할 수 있도록 했습니다.

PgBouncer 설정

[users]

dns_service_user = max_user_connections=60

firewall_service_user = max_user_connections=80

[pools]

user1.database1 = pool_size=90

PgBouncer Runtime Commands

SET USER dns_service_user = 'max_user_connections=40';

SET POOL dns_service_user.dns_db = 'pool_size=30';

이를 위해서 저희는 저희 PgBouncer folk 버전에 주요 버그 수정, 리팩토링 및 구현을 더해야했습니다. 저희는 또한 PgBouncer 오픈 소스에 기여하기 위해 이 모든 기능을 담아 몇 차례 PR(pull request)를 올렸습니다. PgBouncer에 더한 저희의 모든 작업에 대해 알아보려면 이 블로그를 참조하세요.

이제 이러한 새로운 기능을 통해 오작동하는 테넌트의 동시성(연결 풀, 사용자 및 데이터베이스 쌍)에 대해 더 빠르고 세분화된 '부하 분산'이 가능하며, 성능 격리를 더욱 엄격하게 수행할 수 있습니다.

향후 해결책

테넌트별 리소스 소비를 모니터링하고 과거 기준선과 비교한 시스템 리소스 지표를 기반으로 어떤 테넌트가 잘못 작동하는지 감지하는 인프라 구성 요소를 계속 구축하고 있습니다. 이러한 새로운 관리 명령을 사용해 테넌트에 대한 연결 및 쿼리 스로틀링을 자동화하는 것을 목표로 하고 있습니다.

또한 테넌트 성능 격리를 엄격하게 적용하기 위해 다양한 자동화된 접근 방식을 실험하고 있습니다.

혼잡 방지

TCP Vegas 혼잡 회피 알고리즘을 채택하면 각 테넌트의 최적 동시성을 추정하고 적용하는 동시에 인접한 이웃 테넌트에 대한 낮은 지연 시간과 높은 처리량을 유지할 수 있습니다. 이 접근 방식은 리소스 소비 프로파일링, 수동 임계값 조정, 기본 시스템 하드웨어에 대한 지식 또는 고비용 계산이 필요하지 않습니다.

전통적으로 TCP Vegas는 초기에 알려지지 않은 최적의 혼잡 window(동시에 전송할 수 있는 최대 패킷 수)으로 수렴합니다. 같은 논리로 알수 없는 혼잡 구간을 데이터베이스 쿼리에 대한 최적의 동시성 또는 연결 풀 크기로 간주할 수 있습니다. 구체적으로 설명 하자면, 게이트웨이 계층인 PgBouncer에서 각 테넌트는 작은 연결 풀 크기로 시작하며, 각 테넌트의 트랜잭션의 왕복 시간(RTT)을 Postgres와 비교하여 동적으로 샘플링합니다. 트랜잭션 RTT가 악화되지 않는 한 테넌트의 연결 풀 크기(혼잡 window)를 점진적으로 늘립니다.

반면 테넌트의 샘플링된 트랜잭션 지연 시간이 증가하면 샘플링된 요청 지연 시간 비율에 의한 최소 계산(minimum request latency / sampled request latency)이 감소하여 결국 테넌트가 사용 가능한 동시성/연결이 자연스럽게 감소하여 데이터베이스 부하가 감소합니다.

기본적으로 이 알고리즘은 높은 데이터베이스 부하를 나타내는 지표로서 높은 쿼리 대기 시간이 관찰되면 이 대기 시간이 CPU 시간 또는 디스크/네트워크 IO 차단 등으로 인한 것인지 여부에 관계없이 일정한/랜덤한 시간동안 대기후 다시 동작 합니다.이 공식은 sampeld request latency 가 충분히 커질 수 록 *latency 비율(**minimum request latency / sampled request latency)이 항상 0에 수렴 하므로 최적의 동시성 제한(Connection pool 크기)을 찾을수 있습니다. current tenant pool size 의 제곱근이 connection pool 크기의 빠른 성장 속도와 작은 pool 크기 대비 상대적으로 큰 값 때문에 고정 요청 “Burst head room”으로 선택되었습니다. 대기 시간이 낮을 때(pool 크기가 작은 경우) 이 값은 크지만, 대기 시간이 높을 때(pool 크기가 줄어드는 경우) 수렴합니다.

혼잡 회피 방식은 부하를 사후적으로 줄이는 대신 부하로 인한 성능 저하가 문제가 되기 전에 트래픽을 예방적으로 또는 "원활하게" 조절합니다. 이 알고리즘은 다른 쿼리를 중단 시키는 데이터베이스 서버 리소스 고갈과 같은 문제를 방지하는 것을 목표로 합니다.

이론적으로 한 테넌트가 잘못 동작하여 다른 테넌트에 지연 시간을 유발하는 경우, 이 TCP 혼잡 알고리즘은 모든 테넌트를 맹목적으로 스로틀링할 수 있습니다. 따라서 시스템 성능이 저하될 때 CPU와 지연 시간의 상관관계가 높은 테넌트에 대해서만 이 적응형 스로틀링을 적용해야 할 수도 있습니다.

테넌트 리소스 할당량

각 테넌트별로 리소스 할당량을 도입할 수 도 있습니다. 즉 데이터베이스로 요청을 보내는 애플리케이션 서비스 테넌트는 초당 CPU 사용률 및 최대 메모리로 표시되는 할당된 리소스 점유율로 제한될 수 있습니다. 테넌트가 자신의 몫을 넘어 과도하게 사용하는 경우, 데이터베이스 게이트웨이(PgBouncer)는 동시성, 초당 쿼리 및 ingress 바이트를 스로틀링하여 할당된 슬라이스 내에서 소비하도록 강제해야 합니다.

테넌트의 리소스 제한은 다른 테넌트가 같은 클러스터에 액세스하는 것에 영향을 주거나 "넘쳐흐르지" 않아야 합니다. 그렇지 않으면 다른 고객 대면 애플리케이션의 가용성이 저하되고 SLO(서비스 수준 목표)를 위반할 수 있습니다. 리소스 제한은 각 테넌트로 격리되어야 합니다.

Postgres 인스턴스에 대한 트래픽이 적은 경우 테넌트가 할당 한도를 초과할 수 있도록 허용해야 합니다. 그러나 클러스터에 대한 부하로 인해 시스템의 전체 성능(지연 시간)이 저하되는 경우, 테넌트의 제한은 게이트웨이 계층인 PgBouncer에서 다시 적용되어야 합니다. 이를 위해 사전 정의된 임계값에 대한 평균 쿼리 지연 시간의 변화율과 같은 지표를 기반으로 전체 데이터베이스 서버의 상태를 추론할 수 있습니다. 모든 테넌트는 리소스 소비가 초과되면 특정 패턴의 쿼리 스로틀링이 발생할 수 있다는 데 동의해야 합니다.

각 테넌트는 고유하고 가변적인 워크로드를 가지고 있어 언제든지 멀티 테넌트 성능이 저하될 수 있습니다. 빠른 탐지를 위해서는 각 테넌트(또는 connection pooling 된 테넌트의 워크로드)의 기준 리소스 소비량을 거의 실시간으로 각 로컬 Postgres 서버(백엔드 pid) 기준으로 프로파일링 해야 합니다. 여기에서 "기준" 트래픽 특성을 데이터베이스 인스턴스당 시스템 수준 리소스 소비량과 연관시킬 수 있습니다.

분산 노드 전체에 걸쳐 평균을 내거나 통계적 측정값을 일반화하는 것은 리더(leader) 인스턴스와 복제 인스턴스에 대한 트래픽의 편차가 크기 때문에 정확하지 않을 수 있습니다(이 경우 각 테넌트의 Postgres 인스턴스 리소스 소비량). 이로 인해 사용자에게 잘못된 스로틀링 결정이 적용될 수 있습니다. 예를 들어, 사용자가 기본 데이터베이스 인스턴스에서 과도한 리소스를 사용하더라도 유휴 읽기 복제본에 대한 사용자의 동시성을 스로틀링해서는 안 됩니다. 따라서 테넌트 사용량을 Postgres 인스턴스 수준에서 캡처하고 전체 클러스터가 아닌 인스턴스별로 스로틀링을 적용하는 것이 바람직합니다.

독립 변수(동시성, 초당 쿼리 수, 수집된 바이트 수)와 종속 변수(시스템 수준 리소스 소비량) 간의 관계를 모델링하기 위해 다변량 회귀를 사용할 수 있습니다. 부하가 높은 시나리오에서 테넌트별로 최적의 독립 변수를 계산하고 적용할 수 있습니다. 워크로드 변화를 고려 하려면 워크로드 소비를 캡처할 때 슬라이딩 윈도우 크기(프로파일링된 데이터 포인트를 유지하는 시간)를 조정하여 회귀 적응성과 정확도를 조정해야 합니다.

게이트웨이 쿼리 대기(queuing)

Postgres 로 보내지는 사용자 쿼리는 게이트웨이 계층(PgBouncer)에서 우선순위를 분류될 수 있습니다. 하나 또는 여러 개의 글로벌 우선순위 대기열 내에서 모든 테넌트의 쿼리 제출은 테넌트의 connection pool 또는 테넌트 자체의 현재 리소스 소비량을 기준으로 순서가 지정됩니다. 또는 각 쿼리가 독립적으로 프로파일링되는 각 쿼리의 과거 리소스 소비량을 기준으로 순서를 정할 수도 있습니다. 각 Postgres 인스턴스의 서버에서 캡처한 테넌트 리소스 소비의 변경 사항을 기반으로, 스케줄러가 제출할 쿼리를 전달할 때마다 큐에 대기 중인 모든 쿼리의 순서를 다시 지정할 수 있습니다.

우선순위 큐 고갈(한 테넌트의 쿼리가 큐의 끝에 위치하여 실행되지 않는 현상)을 방지하기 위해, 게이트웨이 수준 쿼리 큐잉은 Postgres 인스턴스에 대한 최대 부하/트래픽이 있을 때만 활성화되도록 구성할 수 있습니다. 또는 쿼리를 큐에 대기시키는 시간을 우선 순위 지정에 반영할 수 있습니다.

이 접근 방식은 문제가 없는 테넌트가 연결을 계속 예약하고 쿼리(예: 중요한 상태 모니터링 쿼리)를 실행할 수 있도록 허용하여 테넌트 성능을 격리합니다. 더 많은 리소스를 사용하는 테넌트(트랜잭션이 많거나 비용이 많이 드는 테넌트)에서만 더 높은 지연 시간이 관찰될 수 있습니다. 이 접근 방식은 이해하기 쉽고, 애플리케이션에서 일반적으로 사용되는 접근이며(다른 입력 메트릭을 기반으로 트랜잭션을 큐에 대기시킬 수 있음), 클라이언트/서버 연결을 종료하지 않으므로 비파괴적인 방법 입니다. 그리고 이 방법은 인메모리 우선순위 큐가 용량에 도달할 때만 쿼리를 드롭 해야 합니다.

결론

멀티테넌트 스토리지 환경에서의 성능 격리는 OS 리소스 관리, 데이터베이스 내부, 큐잉 이론, 혼잡 알고리즘, 심지어 통계까지 포함하는 영역에 영향을 미치는 매우 흥미로운 과제입니다. 커뮤니티에서 테넌트 성능을 대규모로 격리하여 "시끄러운 이웃" 문제를 어떻게 해결했는지 여러분의 의견을 듣고 싶습니다!


---

안녕하세요 주간 SaaS 입니다. 오늘은 Cloudflare 의 멀티 테넌트 데이터베이스 운영 사례를 담은 아티클을 소개 했습니다. 원문은 이곳에서 확인할 수 있습니다.

B2B SaaS 서비스에서 격리(Isolation)는 선택의 문제가 아니라 필수 입니다. 또한 테넌트 데이터 격리 실패로 보안 문제로 이어진다면 생존의 문제가 되기도 합니다. 중요한 문제인 만큼 SaaS 서비스 아키텍처 모든 레벨에서 격리 구조를 설계하는 것은 분명 도전 과제 입니다.

특별히 데이터베이스 계층에서 테넌트 격리를 구현할 때는 여러 요소가 고려되어야 합니다. 이 과정에서 때로는 규모의 경제 달성, 테넌트 성능 격리/보장, 시끄러운 이웃 문제 해결, 테넌트 간 교차 접근 방지 등 상충되는 목표들이 서로 충돌하기도 합니다. 오늘 소개한 Cloudflare 의 멀티 테넌트 성능/격리에 관한 사례는 이 과정에서 최적의 해결책을 찾는데 도움이 되는 내용을 담고 있습니다. 꼭 읽어보세요!

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요




주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

3
0
장진서

장진서

사람들이 정말 사용하는 SaaS 서비스 만드는 방법

기술의 발전에도 불구하고 훌륭한 사용자 경험을 제공하는 제품을 만드는 것은 여전히 어려운 과제입니다. 많은 기업이 우수한 제품 디자인은 사용자의 관점에서 구축하는 것이 아니라 최고의 엔지니어를 고용하고 최신 소프트웨어에 가입하는 데서 나온다고 믿고 있습니다.

Stripe은 제품 디자인 프로세스에 대한 접근 방식을 바꾸고 사용자와 지속적으로 소통함 으로 써 훌륭한 제품 디자인의 비밀을 풀어낸 몇 안 되는 기업 중 하나 입니다. Stripe의 CTO인 David Singleton 이 피드백, 반복, 빠른 출시 시스템을 사용하여 사용자의 기대에 부응하는 제품을 만드는 방법을 공유합니다.

David는 이 방법이 켄트 벡이 대중화시킨 익스트림 프로그래밍 접근법을 수정한 익스트림 제품 디자인(EPD)이라고 설명합니다. 익스트림 프로그래밍 접근법은 테스트 중심 개발의 원칙을 사용하는데, 이는 인간의 현실과 분리된 완벽한 코드가 있는 제품에 초점을 맞추기보다는 문제를 해결하는 제품을 만드는 데 더 중점을 둡니다.

EPD는 세 가지 필수 원칙을 준수하면 더 나은 사용자 경험, 제품 전략 및 제품 출시로 이어질 수 있습니다.

 

원칙 1: 빠르게 반복하고 적절한 사용자로부터 피드백을 얻어야 합니다

EPD에는 사용자 중심의 사고방식이 필요합니다. Stripe는 최소한의 실행 가능한 제품을 만들고 사용자에게 검토를 요청하는 방식으로 이 접근 방식을 따릅니다. Stripe은 다음 작업을 수행하기 전에 이 피드백을 문서화 합니다.

이는 관련 없는 기능으로 복잡한 제품을 만드는 것과는 완전히 대조적 입니다. 보통 이러한 제품은 제품 디자인이 아이디어 → 제작 → 출시의 단방향 프로세스로 진행될 때 발생합니다. 여기에 피드백 계층을 추가하고 프로세스를 반복적으로 루프처럼 처리함 으로 써 Stripe는 사용자의 기대에 지속적으로 부합하는 제품을 만들 수 있었습니다.

"사용자들은 우리가 생각하는 것보다 훨씬 더 많은 요구 사항을 가지고 있기 때문에 이를 이해하고 피드백을 받을 수 있는 방법을 찾아야 합니다."

예를 들어, Stripe의 초기 제품은 스타트업이 겪고 있던 온라인 결제 문제를 해결 하기 위한 것이었습니다. Stripe은 이 문제를 해결할 방법을 찾아내고, 일부 잠재 사용자와 직접 접촉 하면서 솔루션을 모델링 하는 코드를 만들어가며 다음 제품을 출시 했습니다.

Lyft는 이 온라인 결제 문제를 풀고자 하는 초기 사용자들 중 하나 였습니다. 그 덕분에 시스템에 Stripe를 내장할 수 있었고, 이를 통해 더 많은 드라이버를 채용하고 회사를 성장시킬 수 있었습니다.

David는 이 테넌트와의 경험을 바탕으로 디자인 프로세스의 다섯 가지 원칙으로 요약합니다.

  1. 사용자 우선
  2. 긴박하고 집중해서 움직입니다
  3. 세심한 주의를 기울 이세요
  4. 피드백을 구합니다
  5. 뛰어난 결과물을 제공하세요

 

원칙 2: 마찰을 찾아서 신속하게 제거하기

사용자의 피드백을 처리하고 사용자의 참여를 유지하려면 속도가 중요합니다. 따라서 모든 프로젝트를 시작할 때 24시간 피드백 루프를 만드세요:

  1. 사용자가 무언가를 봅니다
  2. 사용자로부터 피드백을 받습니다
  3. 반복하여 개선 사항을 출시 합니다
"제품 경험의 핵심 약속을 이행한 후에는 최대한 빨리 이를 개선하기 시작하세요."

여기서 목표는 고객 경험 과정을 디버깅 하여 문제를 발견하고 가능한 한 빨리 수정하는 것입니다. 하지만 이를 위해서는 기술 팀에 문제를 즉시 해결할 수 있는 올바른 도구와 리더의 역량을 강화해야 합니다.

Stripe는 사내 개발자 생산성 팀이 개발자와 제품 팀의 업무를 감독하여 그들이 항상 최고의 상태를 유지할 수 있도록 지원합니다. 따라서 사용자와 소통하는 외부 시스템과 함께 업무 관련 문제를 경영진에게 전달하는 내부 시스템도 갖추고 있습니다.

 

원칙 3: 규모를 확장하고, 학습 커뮤니티로 거듭나며, 지속적으로 개선하세요

제품 디자인 프로세스를 시작할 때는 모든 마일스톤을 예측하고 관리하는 것이 쉽습니다. 하지만 제품이 성장하고 이에 맞춰 프로세스를 확장하려고 하면 상황이 통제 불능 상태가 될 수 있으며, 이런 상황은 사용자 우선 접근 방식을 유지하기 위해 더 많은 작업이 필요하다는 것을 의미합니다.

이 사용자 우선 접근 방식이라는 표준을 유지하는 데 더욱 신중을 기하면 회사가 학습 커뮤니티로 변모할 것입니다. 이 개념은 MIT의 피터 센지가 대중화 했으며 다음과 같은 내용을 포함합니다:

  • 조직이 어떻게 운영되어야 하는지에 대한 개인적인 비전 개발
  • 이러한 인식의 바탕이 되는 가정을 이해
  • 대화를 장려하고 모두에게 적합한 실행 가능한 전략을 개발

Stripe는 회사의 여러 부서, 특히 구축 단계에서부터 사용자와 관계를 맺어야 하는 기술팀이 고객과 소통할 수 있도록 함으로써 위 그림과 같은 프로세스를 구현 하고 있습니다.

 

핵심 사항 정리

사용자가 사랑할 만한 제품을 만드는 비결은 작게 시작하고 유연성을 유지하며 빠르게 적응하는 것입니다. 최고의 기술을 보유하고 있더라도 사용자의 의견을 경청하고 사용자가 원하는 것을 제공하지 못하면 비즈니스는 실패할 수 있습니다. Stripe의 익스트림 제품 디자인 방법은 실행에 대한 편견이 있고 사용자의 요구 사항을 파악하고 있다면 모든 산업에 걸쳐 구현할 수 있습니다.

"시간이 지남에 따라 실행하는 것이 중요합니다. 올바른 초점을 맞추면 수백만 명의 삶에 영향을 미치고 성공을 돕는 제품을 만들 수 있습니다."


--------

안녕하세요. 이번 주간 SaaS 는 Stripe 의 CTO David Singleton 이 SaaStr 에서 발표한 내용을 정리한 블로그를 소개 했습니다.

Stripe 이 어떻게 고객 중심 사고 방식을 바탕으로 고객에게 밀착하여 고객의 피드백을 수집하고 이를 반영하는 과정을 끊임 없이 반복해 끝내 사랑 받는 제품이 되었는지 핵심만 정리한 이번 블로그는 이제 막 SaaS 서비스를 만들어 가는 기업들에게 좋은 인사이트를 주고 있습니다. 

원문 블로그 내용에는 포함되어 있지 않지만 Stripe이 익스트림 제품 개발(EPD)를 뿌리 내리기 위해 정착 시킨 Amazon의 거꾸로 일하기(Working Backward) 문화 에 대한 소개도 Stripe CTO의 발표 영상에 포함되어 있습니다. 이외 많은 인사이트가 발표 영상에 포함되어 있습니다. 시간 내어 원본 발표 영상도 아래 유튜브 링크를 통해 꼭 시청해보시기를 추천 합니다.

https://youtu.be/N2BPdAk_riU


마지막으로!

저희 주간 SaaS 역시 구독자 분들과의 피드백 루프를 만들기 위해 구독자 분들이 언제든 편하게 익명으로 피드백을 남길 수 있는 설문 채널을 만들었습니다. 아래 "주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요" 버튼을 누르고 양한 의견을 남겨주세요. 피드백을 반영해 여러분들에게 도움이 되는 뉴스레터가 되겠습니다.


주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요

주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

6
0
장진서

장진서

SaaS 멀티 테넌트 아키텍처 정의 오해와 진실, 멀티 테넌시 다시 정의 하기

멀티 테넌시와 SaaS 라는 용어는 종종 긴밀하게 연결됩니다. 때로는 어떤 조직에서 “SaaS는 곧 멀티 테넌시” 라고 설명하기도 합니다. 물론 이 설명이 자연스러운 것처럼 보일 수 있지만, SaaS와 멀티 테넌시를 동일시하는 것은 여러분의 팀이 SaaS 를 기술 적인 관점으로만 바라보게 합니다. 실제로는 SaaS 는 아키텍처 전략이 아니라 비즈니스 모델인데 말이죠.

이 개념을 더 잘 이해하기 위해서 전통적인 멀티 테넌시 관점부터 살펴 보겠습니다. 이 순전히 인프라 중심적인 관점에서는 멀티 테넌시는 테넌트가 리소스를 서로 공유하여 민첩성과 비용 효율성을 증진하는 방법으로 설명됩니다.

예를 들어, 여러 테넌트가 사용하는 마이크로서비스 또는 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스가 있다면, 이 서비스는 멀티 테넌시 모델에서 실행된다고 볼 수 있습니다. 왜냐하면 테넌트들이 이 서비스를 실행하는 인프라를 공유하기 때문입니다.

이러한 정의의 문제점은 기술적인 멀티 테넌시 개념을 SaaS와 너무 직접적으로 연결한다는 것입니다. 이는 SaaS의 결정적인 특징이 자원을 서로 공유하는 멀티 테넌트 인프라를 반드시 갖추어야 한다는 가정을 만들어 버립니다. 이런식의 SaaS에 대한 관점은 다른 환경에서 SaaS가 구현되는 다양한 방식을 볼 때 그 논리가 무너지기 시작 합니다.(*즉, SaaS가 단순히 기술적인 멀티 테넌시 측면에서만 이해될 수 없으며, 다양한 환경에서 다양한 형태로 구현될 수 있다는 것을 의미합니다.)

다음 다이어그램은 우리가 멀티 테넌시를 정의하는 데 어려움을 겪을 수 있는 경우를 보여 줍니다.

이전에 설명한 클래식한 SaaS 모델 처럼, 여러 테넌트를 관리하고 운영할 수 있는 공통 서비스(회색 박스, 예, Onboarding, Identity, Billing and metering 등)로 둘러싸인 일련의 애플케이션 서비스들이 있습니다.

다이어그램을 보면 애플리케이션 서비스들은 제품, 주문 및 카탈로그라는 세 가지 샘플 마이크로서비스로 구성되어 있습니다. 각 서비스의 테넌시 모델을 자세히 살펴보면, 서로 약간은 다른 테넌시 패턴이 적용되었다는 사실을 알 수 있습니다.

제품 서비스는 모든 테넌트와 컴퓨팅 및 스토리지를 공유합니다. 이는 멀티 테넌시의 클래식한 정의와 일치합니다. 그러나 주문 서비스를 살펴보면, 공유하는 컴퓨팅이 있지만 각 테넌트별로 별도의 스토리지가 사용 되고 있음을 알 수 있습니다.

카탈로그 서비스는 각 테넌트에 대해 컴퓨팅이 별도로 지정되어 있지만 (각 테넌트마다 별도의 마이크로서비스 배포), 모든 테넌트는 스토리지를 공유합니다.

이러한 종류의 변형은 사실 SaaS 환경에서 흔하게 나타납니다. 시끄러운 이웃 문제, 티어링 모델, 격리 요구 등 다양한 이유로 SaaS 솔루션의 일부를 선택적으로 공유하거나 서로 분리(silo)할 수 있습니다.

이러한 변형 과 이런 모습을 만들어 낼 또 다른 가능성들을 고려하면 전통적인 관점의 멀티 테넌시 용어를 사용하여 이런 환경을 설명 하는 것이 더 어려워집니다. 즉 고객(테넌트) 입장에서는 전반적으로 멀티 테넌트 환경이라고 할 수 있습니다. 그러나 조금 더 기술적으로 깊이 들어가보면, 이 환경의 일부는 멀티 테넌트이고 일부는 아니라는 겁니다.

그렇기 때문에 멀티 테넌시 용어를 사용하여 SaaS 환경을 특성화 하거나 일반화 하는 것을 피할 필요가 있습니다. 대신, 멀티 테넌트 라는 용어를 사용해야 한다면, 아키텍처 일부가 공유되고 일부가 공유되지 않을 수 있다는 점을 염두에 두고 시스템 전체 적인 관점에서 SaaS 환경을 멀티 테넌트로 설명 하는 것이 더 의미가 있습니다.(*이미 제품과 주문 서비스의 컴퓨팅 환경 뿐 아니라 onboarding, Identity 와 같은 SaaS 컨트롤 플레인의 구성 서비스들이 공통 자원 형태로 제공 되고 있기 때문 입니다)

극단적인 경우

테넌시 개념을 더 잘 강조하기 위해, 자원을 전혀 공유하지 않는 테넌트를 가진 SaaS 모델을 살펴보겠습니다. 다음 다이어그램은 일부 SaaS 제공업체에서 사용하는 예시 SaaS 환경을 보여줍니다.

이 다이어그램 에서는 여전히 테넌트를 둘러싼 공통 환경이(예, Onboarding, Identity 등) 있습니다. 그러나 각 테넌트는 전용 자원들로(*테넌트 별 제품 주문 서비스) 배포됩니다. 이 모델에서 테넌트들 간에는 아무것도 공유되지 않습니다.

이 예제는 멀티 테넌트의 의미에 대해서 다시 한번 고민하게 합니다. 자원이 전혀 공유되지 않는데도 이 환경은 멀티 테넌트 환경 일까요? 이 시스템을 사용하는 테넌트들은 자원을 공유하며 사용해야 하는 SaaS 환경에서 기대하는 수준과 동일한 기대를 가지고 있을 겁니다. 사실, 이들 테넌트들은 SaaS 환경의 내부에서 자신들의 자원이 공유 되던 분리 되던 어떻게 배포 되는지를 인식할 필요가 없을 수도 있습니다.

이 예시의 테넌트들을 위한 서비스는 격리된 인프라 자원에서 실행되지만 여전히 공동으로 관리되고 운영됩니다. 즉 회색 박스와 같은 통합된 Onboarding, Identity, Metrics and analytics, Billing and metering, DevOps and deployment 같은 서비스를 공유합니다. 또한 새 버전이 출시되면 모든 테넌트에 똑같이 배포됩니다. 특정 테넌트를 위한 배포를 위해 일회성 커스터마이제이션을 허용하지 않습니다..

이 극단적인 예제는 멀티 테넌트 SaaS 개념을 새롭게 정의하기에 좋은 기회를 제공 합니다. 공유 인프라로 인한 모든 효율성을 실현 하지는 않을 수 있지만, 이런 형태 역시 완전히 유효한 멀티 테넌트 SaaS 환경입니다. 어떤 경우에는 일부 고객에게는 별도 도메인을 제공하여 위와 같은 독립된 자원으로 구성된 모델을 제공할 수 도 있습니다. 그렇다고 이런 케이스가 SaaS가 아니다 라고 할 수 없습니다. 공유 서비스를 사용하고 모든 테넌트가 동일한 버전의 서비스 실행하는 경우, 이는 여전히 SaaS 가 요구하는 기본적인 원리와 원칙을 따르고 있다고 볼 수 있습니다.

이상에서 살펴본 다양한 케이스와 좀 더 넓은 범위의 SaaS 정의를 고려하면, 멀티 테넌트 라는 용어를 사용하는 방식을 좀더 바꿀 필요가 있습니다. 이제는 관리 및 운영이 공동으로 이루어지는 모든 SaaS 시스템을 멀티 테넌트로 참조하는 것이 더 합리적 입니다. 그런 다음, SaaS 솔루션 안에서 어떻게 리소스가 공유되거나 전용으로 사용 되는지 설명하기 위해 다른 접근과 세분화된 용어나 개념을 사용할 수 있을 겁니다.

---

🐶안녕하세요 오늘 주간 SaaS 는 멀티 테넌시 정의 다시 하기 라는 제목으로 발행된 AWS Whitepaper를 소개 했습니다.

SaaS 대한 흔한 오해 중 하나가 SaaS 아키텍처를 구성하는 모든 자원이 모든 테넌트들에게 공유 되어야 하며 그렇지 않을 경우 이건 SaaS 가 아니다! 입니다. 이런 오해는 SaaS 와 멀티 테넌시를 동일시 하기 때문에 발생 합니다.

SaaS 아키텍처에는 테넌트에게 통합된 사용자 경험을 제공함과 동시에 테넌트를 온보딩, 운영, 분석 그리고 관리할 수 있는 환경이 포함되어 있어야 합니다. 때로는 이런 환경을 SaaS 컨트롤플레이니 이라고 하기도 합니다.그리고 좋은 SaaS 아키텍처는 테넌트 마다 개별 적인 아티팩트를 갖기 보다 신속하게 테넌트를 온보딩 하고 서비스를 업데이트할 수 있도록 하는 효율성과 민첩함을 우선시 하며 이를 바탕으로 SaaS 아키텍처는 SaaS 비즈니스의 빠른 혁신과 성장 그리고 비용 효율성을 달성할 수 있도록 지원해야 합니다.

이런 관점에서 SaaS 아키텍처를 바라 보고 테넌트의 요구 사항과 우리 비즈니스 목표의 접점에서 테넌트 자원을 공유 하거나 분리 하는 유연한 접근이 필요 합니다.

오늘 주제에 대한 여러분의 생각이 궁금 합니다!

주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

3
0
장진서

장진서

빌드 서버 투자의 효과: 개발자와 회사의 생산성 향상 및 비용 절감 전략

컴퓨팅 리소스에 대한 비용은 SaaS 솔루션의 운영 관점에서 쉽게 체감되는 항목입니다. 즉 줄이고 싶은 항목입니다. 반면 개발팀은 항상 더 좋은 성능을 요구합니다. 성능이 좋은 리소스는 빌드 대기 시간을 줄여 다음 기능을 배포하거나 버그를 수정하는 데 더 많은 시간을 할애할 수 있기 때문입니다.

그렇다면, 초기 비용이 더 비싼 고성능 리소스를 사용하는 것이 개발자 생산성과 비교했을 때 가치있는 선택일까요?

이를 알아보기 위해 강력한 클라우드 기반 컴퓨팅 리소스를 제공하는 새로운 larger hosted runner를 사용하여 2코어부터 64코어까지 각 컴퓨팅 계층에서 대규모 빌드를 실행하는 실험을 진행했습니다. 각 빌드 시간의 비용을 확인한 다음 미국 개발자의 평균 시간당 급여와 비교하여 비즈니스의 실제 운영 비용을 파악하는 것이 이번 실험의 목표입니다.

컴퓨팅 리소스 코어 크기별 빌드 시간 vs 비용 테스트

실험을 위해 Fedora 35 및 Fedora 36용 Linux 커널을 컴파일하는 것을 시나리오로 사용했습니다. 소프트웨어 빌드로서 실행하는데 오랜 시간이 걸리는 시나리오 입니다.

위에서 말씀드린 것처럼 2코어부터 64코어까지 각 컴퓨팅 티어에서 이 프로젝트의 빌드를 시작한 다음, 각 빌드에 걸리는 시간과 GitHub larger hosted runner에 소요되는 비용을 알아볼 것입니다. 마지막으로 빌드 주기 동안 얼마나 많은 시간을 절약할 수 있는지 비교하고 이를 개발자가 생산성을 높이기 위해 얼마나 더 많은 시간을 투자해야 하는지 제곱해서 실제 비즈니스 비용을 알아볼 것입니다.

여기서 가정은 개발자가 빌드가 실행되는 내내 기다리거나 빌드가 실행되는 동안 다른 작업을 하기 위해 업무를 전환을 할 수 있다는 것입니다. 이 두 가지 모두 전반적인 생산성에 영향을 미칩니다(자세한 내용은 아래 참조).

계산을 단순화하기 위해 컴퓨팅 티어당 두 빌드의 평균 런타임을 사용했습니다.

1. 느린 빌드 시간으로 인한 기업의 비용 손실

실험의 첫 번째 시나리오에서는 개발자가 빌드가 실행될 때까지 기다리기만 하고 그 기간 동안 다른 작업을 하지 않는다고 가정해 보겠습니다.(이는 좋은 상황은 아니지만 실제로 일어날 수 있는 일입니다)

그렇다면 이로 인해 기업은 어떤 손해를 볼까요? StackOverflow의 2022 개발자 설문조사에 따르면 미국 내 개발자의 평균 연간 비용은 부가 혜택, 세금 등을 포함하여 연간 약 15만 달러입니다. 이를 시간당으로 환산하면 약 75달러(USD)입니다. 즉, 개발자가 1시간 동안 빌드 실행을 기다리면서 그 시간 동안 아무것도 하지 않는다면, 기업은 여전히 그 개발자의 시간 동안 평균 75달러를 지출하고 있으며, 개발자가 더 많은 코드를 빌드하는 데 집중할 수 있는 시간을 잃고 있는 것입니다. (🐧 :) 우리나라는 2022년 적용 sw기술자 평균 임금 공표 기준으로 응용sw 개발자 시간당 급여는 ₩38,254 입니다. 혹 우리나라 식으로 계산 하실 분이 있다면 이 수치를 이용하시면 됩니다)

이제부터 재미있는 부분은 각 컴퓨팅 성능 계층을 사용하여 빌드를 실행하는 데 드는 런타임과 비용, 그리고 빌드를 기다리는 데 소요되는 개발자의 시간 비용을 계산하는 것입니다. (각 계층에서 각각을 두 번 실행한 다음 결과를 합산하여 평균을 냈습니다)

다음과 같은 결과가 나옵니다:

당연히, 성능이 좋을 수록 빠른 빌드가 이루어집니다. 하지만 빌드를 실행하는 데 걸리는 시간 동안 기업이 평균적으로 개발자에게 지불하는 비용이 얼마나 되는지 알면 놀랄 것입니다.

이를 종합해 보면 더 강력한 하드웨어에 더 많은 비용을 지출해야 하는 매우 설득력 있는 이유를 알 수 있습니다.

이 그래프를 보면 하드웨어 비용은 개발자에게 드는 총 비용(*시간당 급여)보다 훨씬 적으며, 엔지니어링 팀에 더 많은 CPU 성능을 제공하면 빌드가 완료될 때까지 기다리는 대신 소프트웨어 개발에 더 많은 시간을 할애할 수 있다는 것을 알 수 있습니다. 조직 내 팀 규모가 클수록 더 뛰어난 성능의 컴퓨팅 리소스에 투자할 수 있는 이점이 더 커지게 될 것입니다.

2. 컨텍스트(업무) 전환으로 인한 기업의 비용 부담

이제 실험의 시나리오를 바꿔보겠습니다: 개발자가 빌드가 완료되기를 기다리는 동안 멍하니 앉아 있다고 가정하는 대신, 빌드가 실행되는 동안 다른 작업을 시작한다고 가정해 보겠습니다.

이는 컨텍스트 전환의 전형적인 예이며 비용도 발생합니다. 연구에 따르면 컨텍스트 전환은 주의를 산만하게 하고 집중력과 생산성을 저해하는 것으로 나타났습니다. 실제로 캘리포니아 대학교 어바인 캠퍼스의 정보학 교수인 글로리아 마크는 컨텍스트 전환 후 원래 작업으로 돌아가는 데 약 23분이 걸리며, 이는 깊이 관여하는 작업이 많은 개발 작업에만 국한되지 않는다는 사실을 발견했습니다.

컨텍스트 전환 시간을 1시간으로 설정후, 비교를 우선 해보겠습니다.

여기서의 수치는 다른 이야기를 들려줍니다. 즉, 어차피 작업을 전환할 것이라면 빌드 실행 속도는 크게 중요하지 않다는 것입니다. 인건비는 컴퓨팅 리소스보다 훨씬 더 비쌉니다. 즉, 빌드 속도를 높이기 위해 몇 달러를 더 지출하는 것은 장기적으로 볼 때 중요하지 않습니다.

물론 이는 개발자가 컨텍스트 전환 후 다시 정상으로 돌아가는 데 한 시간이 걸린다고 가정한 것입니다. 하지만 위에서 인용한 연구에 따르면 어떤 사람들은 23분 만에 정상으로 돌아갈 수 있다고 합니다(Cornell의 추가 연구에 따르면 10분 정도밖에 걸리지 않는 경우도 있다고 합니다).

이를 고려하여 시간 프레임을 30분과 15분으로 단축해 보겠습니다:

이 데이터를 그래프로 시각화하면 개발자 한 명이 빌드를 기다리거나 작업을 전환하는 데 드는 비용이 다음과 같이 표시됩니다:

개발자의 평균 시간당 요금을 $75라고 가정할 때, 위의 그래프는 개발자가 대기하거나 컨텍스트 전환을 하지 않도록 더 많은 컴퓨팅 성능을 위해 더 많은 비용을 지불하는 것이 거의 항상 합리적이라는 것을 보여줍니다.

가장 비싼 컴퓨팅 옵션(64코어 및 256GB RAM의 경우 시간당 $15)도 개발자 한 명의 시간당 비용의 5분의 1에 불과합니다. 개발자 급여가 증가하면 하드웨어 비용이 감소하거나 작업을 실행하는 데 걸리는 시간이 감소하며, 이러한 반비례 관계는 더 나은 장비를 구입해야 하는 이유를 가리키고 있습니다.

 

결론

  • 더 나은 하드웨어에 더 많은 비용을 지불하는 것이 결국 더 저렴하고 개발자의 불만도 덜합니다.
  • 이 경우 빌드 컴퓨팅에 $4~5를 추가로 지출하면 개인 개발자의 경우 빌드당 약 $40, 5명으로 구성된 팀의 경우 빌드당 약 $200를 절약할 수 있으며, 약 1시간의 생산성 손실과 함께 작업 전환에 따른 불편함을 줄일 수 있습니다. 이 정도는 아무것도 아닙니다. 물론 규모에 따라 $4~5의 추가 비용이 빠르게 증가할 수 있지만, 생산성 저하로 인한 비용도 마찬가지입니다.
  • 여기서는 GitHub의 larger hosted runners 를 예로 들었지만, 이러한 결과는 자체 호스팅이든 클라우드든 모든 유형의 하드웨어에 적용될 수 있습니다. 즉 더 높은 CPU 성능을 위한 초기 비용은 시간이 지남에 따라 보상받을 수 있습니다. 


🐧 오늘 주간SaaS는 느린 빌드 시간 뒤에 숨겨진 비용을 구체적인 데이터를 기반으로 보여주고 있는 GitHub 팀의 블로그,Experiment: The hidden costs of waiting on slow build times 를 소개 했습니다.

SaaS 는 빠른 서비스 릴리스 사이클을 장점으로 가져가는 모델 입니다. 이 장점을 극대화 하기 위해서는 제품 릴리스 과정을 느리게 하는 요소를 제거 하는 것이 중요한 활동이라고 생각 됩니다. 느린 빌드 시간이 제품 릴리스 속도도 느리게 하고 낮은 생산성과 눈에 보이지 않는 비용발생의 원인이 된다면 개선이 필요 합니다. 여러분의 의견은 어떠신가요? 댓글로 남겨주세요!

주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

2
0
장진서

장진서

중요한 SaaS 가격 전략 중 하나

사람들은 일반적으로 SaaS 에서 비용 기반의 가격 전략을 무시하지만, 이는 위험한 실수라고 생각합니다.

비용 기반 가격 전략을 비판하는 사람들은 소프트웨어가 일반적으로 더 높은 가치 기반 가격으로 판매되어 총 마진이 60~80%에 달하기 때문에 비용 기반 가격 전략을 사용하면 "더 가져갈 수 있는 돈을 남기고 가는 것"이라고 주장합니다.

하지만 소프트웨어 업계에서도 비즈니스 단가가 고객이 인식하는 가치보다 높으면 오래 비즈니스를 지속할 수 없습니다. 따라서 SaaS 에서 비용과 가격 책정의 역학을 이해하는 것이 중요합니다.

비용 기반(Cost-plus) 가격 이란

비용 기반 가격 책정이란 비즈니스의 비용을 계산하고 원하는 인상률을 추가하여 제품 판매 가격을 책정하는 것을 의미합니다. 원가에 따라 부과할 수 있는 최저 가격을 결정하면서도 수익성을 유지할 수 있기 때문에 모든 가격 책정 전략에 필수적인 요소입니다.

 클릭해서 이미지를 올려주세요

사람들은 비용 기반 가격 책정 방식에 대해 생각할 때 매출 원가(CoGS)만 생각하는 경향이 있습니다. 클라우드 인프라, 고객 지원, 소프트웨어 엔지니어링 및 기타 제품 비용과 같은 것이 일반적인 SaaS CoGS입니다. 20개 이상의 SaaS 스타트업과 함께 일해 온 저희 팀은 평균적으로 CoGS가 전체 매출의 약 30%를 차지한다는 사실을 알게 되었습니다. 비즈니스에 실제 제품, 하드웨어 또는 맞춤형 개발이 필요한 경우 CoGS는 더 높을 수 있습니다.

그러나 CoGS만 사용하여 비용 기반 가격을 계산하면 판매 및 마케팅 비용을 무시하기 때문에 부정확한 벤치마크 데이터를 제공합니다. 또한 이러한 운영 비용에는 많은 비즈니스에서 가장 중요한 SaaS 지표 중 하나인 고객 확보 비용(CAC)이 숨겨져 있습니다.

 클릭해서 이미지를 올려주세요

고객 확보 비용 계산(그리고 또다른 중요한 지표)

고객 확보 비용은 신규 유료 고객을 확보하기 위해 지출해야 하는 평균 금액입니다. 일반적으로 단위당 CoGS 비용보다 높으며 현금 흐름에 큰 영향을 미칠 수 있기 때문에 가장 중요한 SaaS 지표 중 하나 입니다.

CAC를 계산 하려면 다음과 같이 합니다:

  1. CAC를 회수할 목표 월, 즉 회수 기간을 결정합니다.
  2. 해당 기간 동안 직원(마케팅 및 영업팀), 광고 비용, 간접비를 포함한 총 판매 및 마케팅 비용을 합산합니다.
  3. 이 수치를 해당 기간 동안 확보한 고객 수로 나눕니다.

 클릭해서 이미지를 올려주세요

이제 고객 확보 비용이 완성되었습니다. CAC를 평균 고객 생애 가치(LTV: CAC)와 결합하면 비즈니스의 건전성을 파악할 수 있습니다. 이 비율이 높을수록 더 빠르게 성장하고 더 높은 수익성을 얻을 수 있습니다. 일반적으로 건전한 SaaS 회사의 LTV:CAC 비율은 3:1입니다.

그러나 가격 책정의 맥락에서 CAC와 CoGS를 가장 관련성 있게 만들어야 합니다. 이는 비용 회수 목표 월을 사용하여 고객별, 기간별 기준으로 정규화하여 수행할 수 있습니다. 정규화는 각 청구 주기에 얼만큼의 금액을 할당해야 하는지 이해하는데 도움이 됩니다.

예를 들어 월 단위로 제품을 판매하고 다음과 같이 결정 했다고 가정해 보겠습니다:

  • CAC: $324
  • 고객당 CoGS: $144
  • 회수 목표 개월 수: 12개월

그리고

  • 월별 CAC 27($324/12개월)
  • 월별 CoGS 12($144/12개월)

를 매월 비용 기반 가격에 더함으로써 해당 고객을 확보하고 서비스를 제공하는 데 지출한 비용을 가격에 반영 합니다.

 클릭해서 이미지를 올려주세요

어떻게 고객 확보 전략이 비용 기반 가격에 영향을 미치는가

제품 판매 방식은 고객 확보 비용 그리고 결과적으로 가격 결정에 큰 영향을 미칩니다.

이전에 고객 확보 전략이 SaaS 가격 책정 전략에 어떤 영향을 미치는지에 대해 이야기한 적이 있지만, 다시 한 번 살펴볼 필요가 있습니다. 간단히 말해, 개인화된 관계형 판매 모델을 통해 판매하면 상대적으로 더 높은 CAC가 필요하고 이는 다시 더 높은 가격의 이유가 됩니다. 반대로 확장 가능한 셀프 서비스 모델을 통해 판매하면 상대적으로 낮은 CAC로 이어져 더 낮은 가격을 책정할 수 있습니다. 두 가지 접근 방식 모두 더 양호한 LTV:CAC 비율을 보장하지는 않습니다.

고객 확보 전략으로서의 관계 영업

관계 영업은 영업 및 리드 생성 팀에 더 많은 자원을 투자하게 합니다. 고객을 확보하기 위해 관계 영업 접근 방식을 사용하는 경우 다음과 같은 시간과 비용을 고려해야 합니다:

  • 잠재 고객 조사
  • 전화 걸기
  • 잠재 고객과의 관계 구축
  • 데모 제공
  • 회의 참석을 위한 출장

이러한 모든 활동의 총 비용은 잠재 고객 당 2,000~3,000달러 이상에 달할 수 있습니다.

이처럼 고도로 개인화된 접근 방식을 통해 관계 영업을 통해 고객을 확보하는 기업은 한 달에 최소 $1,000~$1,500를 비용으로 사용하는 경우가 많습니다. 제품의 이탈률, 전환율, 고객 생애 가치에 따라 일부 기업은 더 적은 비용을 사용 하기도 합니다.

관계형 영업은 더 높은 CAC로 이어지는 경향이 있지만, 제품에 훨씬 더 많은 비용을 반영할 수 있습니다.

고객 확보 전략으로서의 셀프 서비스

셀프 서비스 또는 셀프 가입은 SaaS 고객 확보 전략으로서 관계 판매와 같이 업계에서 흔히 볼 수 있습니다. 그런데 소프트웨어의 가격은 상대적으로 고객 확보 비용이 낮기 때문에 일반적으로 훨씬 저렴합니다.

셀프 서비스 SaaS 는 마케팅 팀, 콘텐츠 및 광고에 더 많은 리소스를 집중할 수 있습니다. 셀프 서비스 접근 방식을 사용하여 고객을 확보하는 경우 다음 내용과 관련된 마케팅 및 인건비를 고려해야 합니다:

  • 디지털 광고
  • 전자책, 블로그, 동영상, 팟캐스트 등의 마케팅 자산 제작
  • 무료 평가판 또는 부분 유료화 계정의 고객 지원
  • 웨비나 진행, 이벤트 참석, 강연을 위한 출장 비용

이러한 콘텐츠 및 광고 중심 접근 방식을 통해 일부 SaaS 기업은 한 달에 $5 또는 $10의 낮은 요금을 부과할 수 있습니다. 이러한 방식이 성공하려면 마케팅 활동을 통해 상대적으로 더 많은 고객을 확보해야 합니다. 마찬가지로, 상대적으로 더 적은 수의 고객을 확보 하려는 경우에는 최소 월 $25~$100 보다 더 많은 요금을 청구해야 할 것입니다.

결론은 셀프 가입 기업은 상대적으로 낮은 CAC 의 이점을 누릴 수 있지만, 관계 판매 기업보다 비용이 가격에 보다 적게 반영되는 경향이 있습니다.

 클릭해서 이미지를 올려주세요

성장에 따라 비용 기반 가격 책정이 중요해

이해하는 데 도움이 되기는 하지만, 비용 기반 가격 책정이 반드시 제품 가격 책정 방식을 대표하는 것은 아닙니다. 또한 전체적인 SaaS 가격 책정 전략을 구성하는 것도 아닙니다. 여전히 고객의 지불 의향, 고객에 대한 가치, 경쟁사의 가격 책정 등을 고려해야 합니다.

하지만 비용 기반 가격 책정은 비즈니스의 실제 비용을 파악하여 향후 수익성 있는 운영을 하는 데 도움이 됩니다. 또한 고객 확보 전략이 변화하고 성장하는 과정에서도 유용합니다.

새로운 제품이나 서비스는 가치에 따라 가격을 책정할 수 있다는 이점이 있으며, 수익을 극대화하기 위해 그렇게 해야 합니다. 하지만 이는 단기적인 가격 책정 전략일 뿐입니다. 수익 마진이 높으면 경쟁업체가 시장에 진입할 가능성이 높습니다. 따라서 강력한 제품 차별화 전략, 건전한 수준의 제품 충성도, 높은 고객 가치를 유지하지 않으면 가격을 책정할 수 있는 범위가 제한됩니다.

----


안녕하세요 주간 SaaS 입니다.

오늘은 Cheddar 라는 빌링 플랫폼 기업이 발행한 Why a Cost Plus Pricing Strategy is Still Important in SaaS 라는 제목의 아티클을 소개 했습니다. 

일을 하다보면 SaaS 가격 전략에 관해서 정말 많은 질문을 받습니다. SaaS 가격 전략은 접근 방법도 다양하고 고려해야 하는 것들도 많고 무엇보다 정답이 없어 많은 실험이 필요한 문제 같습니다. 

개인적으로 이 아티클을 추천하는 이유는 비용 기반의 가격 전략이 가격 실험의 좋은 출발점이 되고 무엇보다 손해 보지 않는 가격을 마련하는 근거가 되기 때문 입니다. 

여러분의 의견은 어떠십니까? 😃

주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

14
3
장진서

장진서

혼자 SaaS 서비스를 1년 동안 운영하며 배운 것들

작년 이맘때(2021년 2월), 저는 AWS Lambda 에서 Next.js 를 바탕으로 구축한 시스템 가동 시간 검사기(Uptime checker) 프로토타입을 인터넷에 공개했습니다. 이걸 완성하는 데 일주일이라는 시간이 걸렸습니다.

이 후 일 년 동안 비즈니스가 어떻게 진행되고 있는지에 대한 몇 가지 글을 쓰기도 했습니다:

제가 서비스 개발을 위해 선택한 접근 방식의 요점은 다음과 같습니다:

정적 웹 사이트가 온라인 상태인지 확인하고, 오프라인 상태인 경우 이메일 알림을 추가하고, 인증 기능을 감싸고, Stripe를 통합하고, Lambda 를 통해 출시. 그리고 한 해 동안 계속해서 기능을 추가했습니다. 

제가 '동일한' 서비스를 제공하는 200여 개의 경쟁업체가 있는 분야에 제품을 출시 하고도 고객을 확보할 수 있었던 비결은 무엇 일까요?

  • 평일 하루 2시간씩 OnlineOrNot에 집중하고 다른 부업은 하지 않습니다. 그 덕분에 올해 약 10개월 동안 이 일을 계속할 수 있었습니다(중간에 2개월 정도 번아웃 시간도 있었지만요).
  • 저는 특히 고객의 고통을 해결하는 기능에 집중합니다(그리고 고객에게 그 고통이 무엇인지 묻습니다).
  • 저는 끊임없이 반복합니다. 2시간 안에 기능을 완성할 수 없다면 범위를 2시간 단위로 줄이는 방법을 찾아서 출시를 해냅니다. 그런 다음 반복합니다.

1년 후 제가 배운 것은 다음과 같습니다:

SaaS 구독을 판매하는 것이 아니라 문제를 해결하는 것입니다

제품을 구축할 때는 구독 판매라는 목표보다는 고객의 관점에서 생각하는 것이 도움이 됩니다.

이렇게 하면 "기능을 계속 만들면 언젠가는 다 나오겠지!"라는 사고방식에서 "사용자가 이 성가신 문제를 해결하도록 도와야지"라는 사고방식으로 전환할 수 있습니다.

SaaS는 문제를 해결하는 여러 방법 중 하나일 뿐입니다. 스크린캐스트, 문서, 기사, 책, 워크샵, 코드 샘플 또는 소프트웨어 등 도움을 줄 수 있는 모든 방법을 검토해야 합니다.

문서는 사용자 경험의 일부입니다

사람들은 종종 "개발자는 문서를 읽지 않는다"고 말하지만 이는 부분만 맞는 사실 같습니다. 그들은 읽지 않고 제목만 훑어봅니다.

제 경험에 비추어 볼 때, 어떤 사람들은 OnlineOrNot의 UI에서 직접 작업을 수행하는 방법을 알아내려고 하다가 좌절하고 문서를 확인하거나 두 가지 중 하나가 발생하곤 했습니다:

  1. 원하는 작업을 수행할 수 있는 방법을 찾지 못해 바로 이탈합니다.
  2. 원하는 페이지를 찾아서 제목으로 이동하여 해당 작업을 수행합니다.

OnlineOrNot의 문서를 성공적으로 사용하면 고객 유지율(Retention) 높아지므로 이제는 문서 기능을 부수적인 것이 아니라 핵심 제품의 일부로 취급하고 있습니다.

모바일용 개발

(B2B SaaS에 대한) 일반적인 믿음과는 달리, 사람들은 실제로 휴대폰으로 작업합니다.

OnlineOrNot.com 트래픽의 약 50%가 모바일을 사용하는 사람들로부터 발생합니다. 이들은 빠르게 계정을 만들고 모니터링할 페이지를 몇 개 추가한 다음 노트북/데스크톱으로 이동하여 수표를 수시로 검토하는 경향이 있습니다.

약 6개월 동안 모바일을 제대로 지원하지 않았기 때문에 휴대폰으로 가입한 사용자들이 빠르게 이탈했습니다. 결국 시간을 들여 모바일용 반응형 보기를 구축 했고, 지금은 새로운 모바일 사용자가 꾸준히 유입되고 있습니다.

사람들에게 우리 서비스를 어떻게 찾았는지 물어보세요

올해 제가 만든 가장 가치 있는 코드 변경 중 하나는 가입할 때 사람들에게 하는 질문을 위한 코드 입니다: "OnlineOrNot을 어떻게 알게 되었나요?"라고요.

사용자가 어디에서 여러분을 찾는지 알아야 합니다.

잠재 고객을 유치하기 위해 사용할 수 있는 채널은 수십 가지가 있으며, 유료 광고, 콘텐츠 마케팅 또는 트위터 포스팅을 통해 사용자를 유치할지 여부를 파악하는데 이런 질문이 유용합니다.

애널리틱스 사용, 퍼널 추적 설정

마케팅 퍼널은 비즈니스의 건전성을 파악하는 데 도움이 됩니다. 얼마나 많은 사람들이 개별 페이지를 방문하는지 확인하는 것도 좋지만, 여러 페이지에 걸쳐 사람들이 어떻게 이동하는지 확인하는 것은 더욱 좋습니다.

마케팅 퍼널이란 홈페이지를 방문한 사람들이 최종적으로 가입 양식으로 이동하여 실제 제품을 구매 하기까지의 흐름을 추적하는 것을 의미합니다. 이를 통해 마케팅 카피, 가입 양식 자체, 그리고 사용자가 실제로 앱을 보기 전에 발생할 수 있는 온보딩 문제를 진단할 수 있습니다.

때로는 스스로 실수를 해야 할 때도 있습니다

저는 다른 사람들이 저지른 실수를 반복하고 싶지 않아서 비즈니스 서적을 꽤 많이 읽었습니다.

하지만 때로는 스스로 실수를 해야 할 때도 있습니다.

예를 들어, 해커 뉴스의 첫 페이지에 올라가고, 6천 명이 랜딩 페이지를 방문하고, 수백 명이 가입을 시도하고, 그 중 한 자릿수의 사람들만이 가입 후 저의 앱으로 이동하는 모습을 관찰한 후에야 무언가 잘못되었다는 것을 깨달았습니다.

가입 양식에서만 75% 정도의 이탈률이 발생 하고 있었던 겁니다. 약간의 A/B 테스트를 통해 OAuth 로그인 공급업체를 추가하는 것만으로 이탈률을 50%로 낮출 수 있었습니다.

적절한 가격 책정은 정말 어렵습니다

가격이 너무 높으면 앱이 모든 것을 다 해줄 것으로 기대하는 고객들이 결국 이탈할 수 있습니다. 너무 낮게 책정하면 9달러를 주었다는 이유만으로 앱을 새롭게 작성해야 하는 상황을 만드는 고객이 생길 것입니다. 어려운 고객에게 환불하고 가격을 인상한 다음 계속 진행하세요.

가격 책정에 대해 많은 실험을 할 준비를 하세요.

MRR에 너무 집중하는 경우

MRR(Monthly Recurring Revenue)을 추적하는 것은 초기에 비즈니스 성과를 측정하는 데 매우 형편없는 방법입니다.

몇 주(몇 달은 아니더라도) 전에 수행한 작업이 현재 MRR 에 영향을 미치므로 이미 고객 여정의 여러 단계를 거치는 상당한 수의 고객을 확보하기 전까지는 가격 변경이 효과가 있는지 알 수 없습니다.

저는 일일 활성 사용자 수 또는 고객에 대한 일종의 '성공 지표'(예: 확인된 페이지 수, 생성된 이미지 수 등)를 측정하는 것이 MRR 보다 더 유용 하다고 생각합니다. 이를 통해 사람들이 실제로 제품을 사용하고 있는지, 그리고 제품이 가치를 제공하고 있는지 파악할 수 있습니다.

여전히 유료 티어를 위해 무료 평가판이 필요합니다

무료 티어는 사람들을 끌어들이고 제품에 대해 이야기하게 만드는 좋은 방법이지만, 무료 티어가 유료 티어보다 고객에게 덜 유용 하다고 판단되면 여러분의 "좋은 제품"을 고객들이 시험해볼 수 있는 더 좋은 방법을 생각해야 합니다.

저는 온보딩 플로우를 구축하고 무료 평가판을 제공하기 시작해야 한다는 사실을 깨닫는 데 11개월이나 걸렸습니다. 무료 티어를 제공 했음에도 불구하고 신규 사용자의 95%가 프로 티어의 무료 평가판을 선택했습니다.

더 많은 트래픽을 유도 하기는 어렵지만, 현재 트래픽의 패턴을 변경 하기는 쉽습니다

인터넷에서 주목받는 것은 길고 느린 게임입니다.

결국 몇 달(몇 년은 아니더라도)에 걸쳐 양질의 콘텐츠 마케팅을 꾸준히 수행하면 하루에 1~2명 정도 였던 콘텐츠 독자 수가 하루에 수백 명으로 늘어날 것입니다.

사이트에 방문하는 사람의 수를 늘리는 것은 그리 쉬운 일이 아닙니다.

반면에 사람들이 사이트에 방문한 후 무엇을 하느냐는 전적으로 회원님의 영향력 안에 있으며, 앞서 언급한 것처럼 가입 양식에 OAuth 로그인 공급업체를 추가하는 등 지금 바로 변경할 수 있는 사항도 있습니다.

콘텐츠 마케팅은 시간을 벌어줍니다

콘텐츠 마케팅에 투자하면 한동안 비즈니스가 저절로 운영되도록 내버려둘 수 있습니다.

한 해 동안 가끔 저의 서비스에 관한 아티클이 입소문을 타서 한 달 동안 수만 명의 방문자를 유치할 때도 있었지만, 아무것도 하지 않아도 약 1,500명의 사람들이 제가 작성한 아티클을 보기 위해 사이트를 방문했습니다.

OnlineOrNot 트래픽

이 방법은 팬데믹 상황에서 프랑스에 살기 위해 전 세계를 돌아다니며 약간의 지쳐 있을 때 특히 유용했습니다.

작게, 자주 출시하기

사람들이 여러분의 제품을 개선하기 위해 특정 기능을 구축해야 한다고 제안할 겁니다.

하지만 그런 기능을 실제로 사용할 사람은 거의 없을 것입니다.

다른 제품에서 비슷한 기능을 본 적이 있어서 도움을 주려는 말일 수도 있습니다. 아마도 SaaS 를 처음 운영하기 때문에 사람들이 실제로 말을 걸어온다는 사실에 흥분하여 서둘러 해당 기능을 구축하게 될 것입니다.

그 기능을 만들지 말라는 말은 하지 않겠습니다(저도 그렇게 조언을 받았고 어쨌든 사용하지 않는 기능을 만들기도 했습니다). 하지만 고객이 해당 기능을 어떻게 사용할지 물어보고, 다른 고객에게 문제를 어떻게 해결하는지 물어보고, 해당 기능의 가능한 가장 작은 버전을 만든 다음 나머지 고객이 어떻게 사용하는지 확인해야 합니다. 여러분도 분명 한 사람만 사용하는 기능을 만들고 싶지는 않을 겁니다.

아무도 원하지 않는 기능을 몇 달이 아니라 몇 시간만 사용한 후 제거하는 것이 훨씬 덜 고통스럽습니다.

먼저 출시하고 확장성은 나중에 걱정

OnlineOrNot 출시 초기에는 아키텍처를 전혀 최적화하지 않았습니다.

각 uptime check 작업은 자체 데이터베이스 연결을 사용했기 때문에 더 많은 사용자가 서비스를 찾을수록 추가 사용자가 앱을 사용하기가 더 어려웠습니다. 또한 적절한 오류 상태를 만들지 않았기 때문에 데이터베이스가 사용 중일 때 신규 사용자가 이런 오류를 보게 되었습니다:

기존 OnlineOrNot 오류 화면

보기 좋지 않았죠.

동시에 저는 사람들에게 필요 없는 것을 만드는 것보다 불완전한 UI로 인해 당황하는 것을 더 선호 했던것 같습니다. OnlineOrNot이 수백 명의 사용자를 끌어들일 수 있다는 보장은 없었고, 저 혼자만 사용하는 또 다른 SaaS 로 끝날 수도 있었습니다.

결국 가장 작은 AWS RDS 인스턴스에서 매주 수백만 건의 검사를 처리할 수 있도록 아키텍처를 재 설계하고 오류 화면을 정리했습니다:

새로운 OnlineOrNot 오류 화면

생각만큼 문제 해결에 많은 시간을 할애하지 않아도 됩니다

올해 프로그래밍에 할애한 시간 중 절반은 제가 해결하고 싶었던 문제(사이트가 다운 되었는지 파악하고 다운 되었면 사람들에게 알림을 보내는 것)를 실제로 해결하는 데 사용했습니다. 그리고 나머지 절반은 그 문제를 중심으로 SaaS 플랫폼을 구축하는 데 사용했습니다.

SaaS 플랫폼이 여러 유형의 인증 및 사용자 관리, 평가판, 온보딩, 팀 관리 및 송장 관리, 라이프사이클 이메일 등 이 필요하다고 생각하지도 못했습니다.

이 중 많은 부분을 아웃소싱 할 수 있습니다(실제로 아웃소싱하고 있습니다! 만약 Stripe 이 없었다면 서비스를 판매하거나 구독 기반 청구를 사용하지 못했을 겁니다.) 하지만 아웃소싱하기 불편하거나 다른 방식으로 처리해야 하는 부분도 항상 있기 때문에 직접 구축해야 합니다.


--

오늘 주간SaaS 는 "혼자 SaaS를 1년 동안 운영 하는 동안 배운것들" 이라는 제목의 아티클을 한글로 소개했습니다. 

저자는 OnlineOrNot 이라는 서비스를 개발 하고 시장에 출시 한 이후 1년 간 배운 내용을 글에 담았습니다. 다양한 SaaS 관련 서적과 아티클에서 말하는 모범 사례들이 저자의 실제 경험과 함께 나오는 좋은 아티클 입니다. 

아래는 원문 글입니다. 원문과 함께 저자의 다른 글도 꼭 보시면 좋을것 같습니다. B2B SaaS 서비스를 만들고 있는 많은 분들께 도움이 되길 바라며 오늘 주간 SaaS 는 여기서 마칩니다.

What I learned running a SaaS for a year - OnlineOrNot


주간 SaaS

B2B SaaS 비즈니스 모델과 기술 아키텍처 설계에 관한 좋은 콘텐츠를 담은 뉴스레터

8
2