프로덕트

아티클

전체 보기
장진서

장진서

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

포스트

아직 포스트가 없습니다.