안녕하세요 구독자 님
주간 SaaS 는 B2B SaaS 비즈니스 모델과 기술 아키텍처 설계를 일 로 하는 사람들이 만들어가는 뉴스레터 입니다.
저희는 SaaS 를 다루는 사람들이지만 여전히 배우고 있습니다. '일 때문에 배우는 과정이 여간 재미없겠다' 라고 생각할 수 있습니다. 하지만 저희는 SaaS 비즈니스 모델과 기술을 알아 갈수록 기분좋고 일을 하는 모든 과정이 흥미롭습니다. 이제 저희가 느끼는 유익하고 즐거운 과정을 SaaS 를 일 로 하는 다른 사람들과 나누려고 합니다.
주간 SaaS 는 저희가 한 주간 배움의 과정에서 만난 좋은 콘텐츠를 골라 담은 뉴스레터 입니다. 이 콘텐츠는 SaaS 비즈니스 모델과 이를 구현하는데 활용되는 다양한 기술(Technology)에 관한 것들이 될 예정 입니다.
호기심을 바탕으로 늘 배움을 멈추지 않는 마음으로 주간 SaaS 시작 합니다.
주간 SaaS 는 SaaS Business, SaaS Tech 순서로 구성 되어 있습니다.
SaaS Business
B2B SaaS 는 일반적인 B2C 비즈니스와 무엇이 다를까요?
일반적인 디지털 제품 혹은 물리적 제품은 고객 1명을 기준으로 우리 회사에게 기여하는 이익의 크기를 계산하여 이 비즈니스 모델의 경제성과 지속 가능성을 판단 한다면, SaaS 제품의 경우 개별 고객이 SaaS 제품/서비스를 이용하는 동안 우리에게 가져다 주는 이익에 주목 합니다. 이 관점에서 부터 일반적인 비즈니스와 B2B SaaS 비즈니스는 달라집니다.
이 차이를 바탕으로 실제 수치, 도표 그리고 SaaS 주요 Metrics 예시를 통해 B2B SaaS 비즈니스와 일반적인 B2C 비즈니스의 차이점을 설명해주는 좋은 글입니다.
제가 개인적으로 너무 감명 깊게 읽었던 원문 일부를 러닝스푼즈에서 한글로 번역해주셨네요! 전체 원문에 보다 많은 내용이 담겨 있습니다 ➡️[SaaS Metrics 2.0 – A Guide to Measuring and Improving what Matters]
--
대기업 고객의 커스텀 기능요청 어디까지 받아들여야 하나요?
SaaS 서비스를 만들어가는 과정에서 직면하는 많은 문제들 가운데 가장 풀기 어려운 문제가 바로 "고객의 커스텀 기능 요청은 어떻게 처리 할까" 입니다. SaaS 기반의 Chat API 서비스를 글로벌 하게 전개하는 Sendbird 의 김동신 대표께서 이에 대한 Sendbird의 경험을 이렇게 이야기 합니다.
- 우리도 여전히 고민하고 있는 부분
- 미국에서는 어느 정도의 MRR 전까지는 이 문제는 너무 고민하지 마라고 함
- 지금 우리가 봤을 땐 분명 커스텀 기능 이지만 실제로 시장이 고객이 원하는 기능일 수 도 있음. 따라서 유연하게 바라볼 필요
- 한국은 SI 에 대한 문화적 거부감 과 공포감이 있어 이 문제가 더욱 예민하게 다가오기도
짧은 영상 이지만 고객의 커스텀 기능요청에 대한 새로운 관점을 얻을 수 있습니다.
--
MoviePass는 어떻게 파산 했나
월 $9.95 구독료로 매일 극장에서 영화 1편을 관람 혜택을 제공하던 MoviePass 를 아시나요? 촉망받던 이 구독 서비스는 결국 파산 했지만 MoviePass의 실패가 남긴 여러가지 교훈들은 많은 책, 아티클에서 case study 로 다뤄집니다.
저자가 지적하는 MoviePass 파산의 주요 원인 이렇습니다.
- MoviePass는 비즈니스 모델과 가격 구조로 인해 손실
- MoviePass는 고객 확보에 많은 돈을 쓴 반면 이 비용을 감당할 만큼 충분한 수익을 거두지 못함.
- 영화 티켓 구매 비용을 포함하는 MoviePass의 매출원가(COGS)는 구독 수익을 상회
- 마케팅 및 직원 급여와 같은 높은 간접비
MoviePass 사례를 통해 최근 B2B SaaS 기업들에게 화두가 되고 있는 매출원가(COGS) 그리고 가격 정책의 중요성을 다시 한번 느낄 수 있습니다.
SaaS Tech
SaaS 기업을 지탱하는 것(aka 멀티 테넌시 의 중요성)
SaaS 서비스를 제공하는 많은 기업들이 추구 하는 아키텍처는 멀티 테넌시 입니다. 멀티 테넌시 아키텍처는 SaaS 기업이 높은 마진을 기대할 수 있게 해줍니다. 높은 기대 마진외에 많은 장점을 제공하는 멀티 테넌시 아키텍처 지만 풀기 쉽지 않은 복잡한 문제를 던지기도 합니다.
이 아티클은 멀티 테넌시를 지하철 시스템을 만드는 것에 비유 하는걸 시작으로, 왜 멀티 테넌시가 필요한지, 멀티 테넌지의 장점은 무엇인지, 멀티 테넌시 아키텍처를 만들기 위해 해결해야 하는 복잡한 문제는 무엇인지를 쉽게 설명 해줍니다.
--
Amazon 의 새로운 이커머스 SaaS 서비스, Buy with Prime SaaS 아키텍쳐
이번에는 최근에 나온 따끈따끈한 2022년 AWS re-invent 영상입니다. Amazon 이 새로운 이커머스 SaaS 서비스인 Buy with Prime 을 위해 설계한 멀티 테넌트 아키텍처를 소개하고 있는데요. Buy with Prime 서비스를 만들 때에 확장성과 유연성은 물론이며 특히 데이터가 다른 테넌트 에게 유출되지 않도록, Noisy neighbors(시끄러운 이웃) 문제를 해결할 수 있도록 설계 했다고 합니다. 세션의 내용을 요약해 보면 다음과 같습니다.
- 서비스 설계시, Customer 와 interact 하는 부분을 따로 두고, 여기에 확장성과 User 의 권한을 판단하는 로직을 넣어서 보안을 챙겼습니다.
- DB 에 데이터를 저장할때에는 Tenant 별로 분배한 Key 로 암호화를 하게 해서 해당 Tenant 만 데이터에 접근할 수 있게 합니다.
- Noisy neighbors 를 해결하기 위해서는 적절한 throttling 전략이 필요합니다. 작은 기능단위에도 이를 고려해야 합니다.
- Tenant 의 metrics 를 항상 감시하면서 Noisy neighbors 가 있는지 파악해서 조치해야 합니다.
멀티 테넌트 아키텍처 설계에 어려움을 겪는 분들이 꼭 보셨으면 하는 영상입니다.
--
SaaS 아키텍처 성숙도 모델
실제로 많은 사람들이 멀티 테넌트 아키텍처 수준이 어느 정도되어야 하는지 가이드라인은 있는지 궁금해 합니다(저도 그랬습니다). 과거에도 그런 분들이 있었는지 SaaS 아키텍처 성숙도 모델 이라는 것이 있습니다.
2021년 기준 $1300M 매출을 기록 중인 Hubspot의 CTO는 2008년 남긴 이 글에서 SaaS 아키텍처 성숙도 모델에 대한 자신의 의견과 HubSpot은 성숙도 모델 가운데 어디에 위치하고 있는지 말합니다. 참고로 2008년이면 Hubspot이 창업한지 2년이 되어가던 시점 입니다. 글 아래 남겨진 댓글과 응답도 흥미롭습니다.
저희는 이 글을 통해 다음에 대해 배울 수 있었습니다.
- SaaS 회사를 위한 확장 가능하고 유연한 아키텍처의 중요성.
- SaaS 아키텍처 성숙도 모델의 5가지 Emerging, Development, Established, Optimizing 및 Leading 레벨의 특징
- SaaS 회사가 프로세스, 기술 및 비즈니스 모델을 개선하여 한 수준에서 다음 수준으로 이동할 수 있는 방법
전반적으로 이 짧은 글을 통해 SaaS 아키텍처 및 SaaS 성숙도 모델에 대해 자세히 이해할 수 있으며 이를 지금 우리에게 적절한 SaaS 설계 전략은 무엇일지 생각해볼 수 있습니다.
--
이번 주간 SaaS 여기서 마무리 합니다.
의견을 남겨주세요