SaaS 프로덕트를 만들며 얻은 것들

SaaS 제품을 만드는 것은, 커리어의 측면에서 누군가에겐 매력적이지 않을 수 있다.

특히 개발 직군보다 기획자나 디자이너들이 그렇게 생각하는 경향이 있다고 느낀다. 명확한 타겟과 문제를 정의하고 그에 맞는 뾰족한 솔루션을 도출하는 것이 '잘하는 것'으로 통하는 직무에게, 그렇게 하기 힘든 카테고리의 프로덕트로 여겨지기 때문일 것이다.

 

나는 3년 반동안 SaaS 프로덕트를 만드는 스타트업에서 PM·기획자·QA로 일했다. 일하면서 나 역시도 위에 언급한 것과 비슷한 배고픔을 느꼈고, 종국에 퇴사를 결정한 데에도 이 제품군이 주는 필연적인 아쉬움이 영향을 준 것도 맞다.

하지만 나는 그 3년 반에 대한 후회가 없고, 오히려 연차 평균에 비해 높은 밀도의 경험을 했다고 생각한다. 애정과 에너지를 쏟아 일했기 때문이기도 하겠지만, 내가 만들었던 제품이 SaaS이기 때문에 특히나 얻을 수 있었던 것도 있다. 

 

기획자, 디자이너, PM/PO 등 제품을 만드는 앞단의 단계를 책임지는 사람들이, SaaS 제품으로 커리어를 채우는 것에 대한 막연한 거부감 혹은 두려움 같은 것들을 덜기를 바라며 이 글을 쓴다. 

 

⚠️ Disclaimer(a.k.a 밑밥)

바야흐로 SaaS 대홍수의 시대(내가 방금 만든 말이다)에, SaaS라는 대분류로 퉁칠 수 없는 수많은 카테고리들이 있다. 그 중에서 나의 경험은 고객사들이 자신의 서비스를 만들 수 있게 하는 B2B2C 노코드 SaaS 툴에 해당한다. Shopify, 카페24 등의 서비스로 대표될 수 있겠다.

 

이렇노코드 SaaS 툴의 관점에서는 꽤 일반적인 요소들을 꼽았다고 생각하지만, 그럼에도 불구하고 내가 만든 제품과 일한 맥락의 특징점들이 이러한 요소들을 부스트한 측면이 분명 있을 테니, 개인적인 경험의 특징들을 먼저 공유한다. 

 

내가 만들었던 제품

나는 커머스, 커뮤니티, Web3 등 다양한 비즈니스 분야에서의 웹/앱을 빌드할 수 있는 canD(공식 사이트)라는 노코드 SaaS 툴을 만들었다. 커뮤니티적인 요소가 고객사들이 canD를 고르는 공통적인 소구점이었던 것과 별개로, 고객들의 비즈니스 도메인은 매우 다양했다. 앞서 말한 커머스, 커뮤니티, Web3 등 비즈니스 모델의 구분에서도, 사회적 가치, 수산물, 헬스케어, 아웃도어 등 제품의 주제에서도 말이다.

canD로 서비스를 구축한 고객사 예시 (수산물 직거래 서비스 '파도상자' - 사회적 가치 커뮤니티 플랫폼 '베이크' - 웰빙 식문화 챌린지 서비스 '지글지글' - 글로벌 캠핑 커뮤니티 'iKamper' - 헬스케어 챌린지 커뮤니티 '크링키')

 

 

회사는 초기 스타트업이었고, 고객사들 또한 상당수가 사업 초기 단계에 있었다

규모가 큰 회사들은 제품을 본인들이 원하는 대로 만들 수 있는 사내 프로덕트팀을 두거나 외주개발사를 구할 가능성이 높다. 위에 언급했듯  내가 만든 SaaS는 협업 툴이나 ERP와 같이 사내에서 활용하는 것이 아닌, 각 고객사가 자신의 서비스 자체를 구축하기 위한 툴이었기 때문에 더욱 그러했다. 

내가 다닐 당시에는 우리 회사도 스타트업이었고, 우리 제품을 활용해서 서비스를 구축하는 고객들도 비슷한 단계의 스타트업이거나 새로운 사업의 초기에 우리를 찾은 경우가 많았다. '서비스 MVP를 빠르게 만들어볼 수 있다'는 것이 초기 영업의 포인트이기도 했다. 고객의 제품을 세상에 처음 내놓는 우당탕탕한 과정을 긴밀히 함께했다는 것이, 아래에 언급할 포인트들을 강화한 측면이 있다.

 

나는 이 회사에서 커리어를 시작했다

같은 회사와 제품도, 커리어의 어떤 단계에서 만나는지에 따라 그 경험이 천차만별로 조망될 수 있다고 생각한다. 나는 사회생활의 첫 시작을 이 제품과 함께했고, QA 인턴 부터 정규직 전환, 기획자·PM으로의 직무 전환까지 - 초심자로서 경험할 수 있는 가파른 성장곡선을 이 회사에서 겪었다. 아래에 자세히 설명하겠지만, SaaS 내 첫번째 경력에 있었기 때문에 분명 더 매력적이었다고 생각하기에 덧붙인다.

---

밑밥 충분히 깔았으니, 내가 SaaS를 만들면서 얻은 것들에 대해 이야기해보겠다!

 

첫번째, 여러 도메인의 비즈니스를  찍먹 이상으로 경험할 수 있다.

SaaS BM의 꽃은 하나의 툴로 서로 다른 수많은 서비스들을 만들 수 있다는 확장성(scalability)일텐데, 이것은 곧 SaaS를 확장(scale)하기까지가 그토록 어렵다는 뜻이기도 하다. 그렇기에 사업 시작 단계에는 고객사 한 케이스 한 케이스가 너무 귀중하다. 

 

특히 우리 프로덕트에 유의미한 성장을 가져다 줄 것으로 보이는 고객사라면 더 그런데, 이들에게는 거의 우리가 그들의 인하우스 제품팀인 것처럼 앞단부터 함께 몰입해서 서비스를 빌딩하게 된다.

 

이 때 SaaS 제품팀으로서 주의해야 할 매우 중요한 부분이 있다. 우리는 외주개발사가 아니고 고객이 우리의 프로덕트를 '활용'해서 자신의 비즈니스를 성공하도록 돕는 것이기 때문에, 그들이 원하는 대로 만들어주는 것이 능사가 아니다.

역설적으로 그들이 원하는 대로 다 만들 수 없기 때문에 그들의 비즈니스 목표가 무엇인지, 제품의 이해관계자가 어떻게 움직이는지에 대해서 더욱 제대로 이해해야 한다. 

우리 제품으로 그들의 필요에 적합한 솔루션을 제공할 수 있을지, SaaS로서의 정체성을 생각했을 때 이 기능을 구현하는 게 맞을지, 구현하기로 결정한다면 이 고객사 외의 다른 케이스들에는 어떤 영향을 미칠지, 구현하지 않기로 결정한다면 또 어떻게 다르게 풀 수 있을지 - 등을 다각도로 고민해야 한다.

 

나의 경우에는 Disclaimer에서 언급했듯 '고객사들 또한 상당수가 사업 초기 단계에 있었'기 때문에, 이렇게 고객 서비스를 만드는 앞단에서 함께 고민하는 밀도가 높았다. 

서비스 구축을 우리 제품에 의지하기로 결정한 고객들의 특성 상, 대부분이 IT 프로덕트 전반에 대한 이해도가 높지 않았다. 물론 그 비즈니스 영역에 대해서는 말할 것도 없는 전문가들이었지만, 그것이 앱/웹서비스의 영역으로 왔을 때에는 무엇을 고려해서 어떤 모양으로 만들어야 하는지 등에 대한 고민의 성숙도가 낮았다. 제품에 대해서는 우리가 그들에게 전문가였기 때문에, 마치 서로가 서로의 비즈니스팀 & 프로덕트팀인 것처럼 협업했다.

고객으로부터는 대체로 (프로덕트의 관점에서는) 모호하고 단편적인 요구사항이 전달되기 때문에, 먼저 유저 플로우를 그려서 각 요구사항들이 사용자 여정의 어느 지점에서 어떻게 만나게 되는지를 정리하고, 구체화가 필요한 부분들을 고객에 공유했다. 나아가서는 디자인 혹은 개발을 포함한 프로토타이핑을 진행하면서, 고려하지 못한 구멍들을 선제적으로 발견하고 비즈니스적인 맥락을 포함해 의사결정할 수 있도록 고객과 계속 핑퐁을 주고받았다. 

 

고객의 비즈니스를 긴밀히 들여다보게 되는 것은, 이렇게 그들의 서비스를 구축하고 런칭할 때뿐이 아니다. 고객사 서비스가 새로운 국면 혹은 다음 비즈니스 스테이지를 맞이할 때면, 우리 제품은 그것을 지원할 수 있을지를 지속적으로 검증받게 된다. 그러면서 그 도메인의 비즈니스를 하는 이들이 어떤 스테이지에서 어떤 문제를 겪는지, 그것을 어떻게 해결하고자 하는지를 지속적으로 추적하게 된다.

당연하게도, 비슷한 도메인의 여러 고객사들을 여러 번 만날수록 그 경험의 밀도는 더욱 높아진다.

 

이런 과정들을 서로 다른 도메인의 고객사들과 함께하면서, 좁은 타겟에 집중된 제품에 비해 여러 분야의 비즈니스를 겪어볼 수 있게 된다. 물론 하나만 파는 사람들만큼의 깊이를 얻기는 어렵겠지만 소위 말하는 '찍먹'보다는 유의미한 깊이로 도메인을 이해하게 된다고 생각한다.

 

그렇게 여러 분야들을 경험해보면서, 나는 어떤 도메인과 잘 맞는지에 대해서도도 알수 있게 된다.

특히 Disclaimer에서 언급했듯 나는 이 회사에서 커리어를 시작했고, 입사 전까지 일하고 싶은 도메인에 대한 취향이 정립되지 않았기 때문에 이러한 '조금 깊은 찍먹'들이 큰 도움이 되었다.

커뮤니티 도메인에서는 지금껏 인터넷 인간(..)으로 살아온 경험이 UX 감각에서 빛을 발했다. 그에 반해 너무 '커머스커머스한' 논리의 비즈니스는 내가 잘 할 수 없음을 느꼈고, Web3 세계는 아직 낯설지만 더 알아보고 싶은 마음이 생겼다. 이렇게 대표적인 비즈니스의 구분에서 내가 어떤 영역을 잘할 수 있을지가 명확해졌다. 

서비스가 제공하는 구체적인 제품에 대한 분류인, 수직적인(Vertical) 도메인 구분에서도 마찬가지였다. 헬스케어나 아웃도어같이 내가 안 써본 제품에 대해서는 몰입하기 어렵다는 것을 깨달았다. 반면 사회적 가치와 결부된 NGO나 교육, 하다 못해 어부에게 이익을 가져다주는 수산물 직거래와 같은 분야에서 동력이 높아지는 것을 느꼈다. 

특히 나처럼 '해봐야 안다'가 통하는 사람이라면, 매력적인 포인트라고 생각한다.

 

두번째, 복잡다양한 요소를 고려하며 제품을 만드는 근육이 생긴다

 

하나의 시스템으로 다양한 서비스를 만들 수 있는 SaaS의 이면에는, 서로 매우 복잡하게 얽혀 있는 수없이 많은 기능들이 있다.

 

예컨대, 가입 프로세스에서 고객사가 사용자들로부터 추가정보를 입력받는 단계를 둘 수 있도록 하는 기능을 업데이트한다고 생각해보자. 사용자가 입력한 추가정보는 유저 데이터에 들어갈 테니, 가입하고 난 뒤의 사용자의 프로필이나 내 정보 설정에도 영향을 미칠 수 있다. 더 나아가서는 사용자가 게시글을 작성했을 때, 작성자 프로필을 더 매력적으로 보이기 위해 가입할 때 입력한 추가정보가 표시되게 할 수도 있다. 예컨대 뷰티 크리에이터 커뮤니티라고 했을 때, 후기글의 작성자 정보에 '웜톤', '악건성'과 같은 정보가 도움이 되는 것처럼 말이다.

여기서 가장 중요하지만 동시에 놓치기 쉬운 점은, 어떤 고객사는 가입 과정을 최대한 짧게 만드는 것이 중요해서 추가정보 입력 단계를 쓰지 않을 수도 있고, 필요에 따라 프로모션과 같은 특정 기간에만 켰다가 끌 수도 있다는 것이다.

이런 다양한 케이스들을 고려하지 못하면, 가입 시 추가정보 입력 단계를 업데이트했더니, 추가정보 입력 기능을 사용하지도 않는 고객사의, 가입 단계도 아닌 게시글 화면이나 프로필 화면이 고장나는 사태가 벌어지는 것이다... (실제는 이보다 더 기상천외한 일들이 일어난다)

 

분명 기능 A에 업데이트를 했는데, A'도 아니고 A''도 아니고 B도 아니고 Z가 고장나는 이런 일이, 이렇게 SaaS에서는 비일비재하게 일어난다. 

어느 정도 복잡도가 있는 제품을 만드는 누구나 겪는 어려움이겠지만, 커버하는 도메인이 넓은 데다 수만명씩의 유저를 가진 각 고객사가 설정을 휙휙 바꿀 수 있다는 SaaS의 특성은 이런 문제의 임팩트를 배로 강화한다.

 

때문에 일하는 전 과정에 걸쳐서, 지금 내가 놓치고 있을 만한 고려사항들을 계속 생각해내는 훈련을 하게 된다. 

지금 집중 서포트하고 있는 고객사에게 최적인 정책과 UX가 다른 케이스들에서는 문제가 되지 않을지, 지금 업데이트하려는 이 기능이 n번의 다리를 건너 연결되어 있는 다른 기능들에 영향을 주지는 않을지... 그러려면 PM과 디자이너들도 프로덕트 내부의 구조와 복잡한 로직을 개발자만큼은 아니더라도 깊이 이해하고 있어야 하며, 기획 및 디자인하는 최대한의 앞단의 단계에서 개발자들과 빠른 시점에 긴밀히 논의할 수 있어야 한다. 개발하고 테스트하는 단계에서는 사용 케이스에 대한 상상력을 발휘하여(..) 여러 고객사들을 페르소나 삼아 다양한 테스트 플로우를 타며 확인해보야 한다. 

특히, 특정 고객사 혹은 도메인에 집중한 기능 개발을 하게 되는 기간에는 놓쳐지는 것들이 특히나 많기에 주의를 가지고 만들어야 한다.

 

 

쓰고 보니 '이 하고 많은 것들을 고려해야 한다니' 하는 하소연의 나열인 듯 보이지만... 나는 특히 이 특징들이 PM으로서, 그리고 조직 구성원으로서의 내게 엄청난 자산이 되었다고 느낀다. 

어떤 프로덕트를 만들든 다양한 제약들이 존재한다. 인력·시간과 같은 리소스, 제품의 정체성, 제품 안에서 복잡하게 얽혀 있는 기능들, 조직 안팎의 다양하 이해관계자들...

SaaS를 만들면서 얻은 복잡다양한 요소를 고려하는 역량은, 특정 카테고리의 제품에만 한정적인 것이 아닌 근육으로서 내 몸에 깊이 남았다. 제품 안팎의 복잡한 고려사항들을 이해하고 머릿 속에 항상 그려두고 있는 것, 새로운 기능을 만들 그 그림을 지도삼아 도처에 도사리고 있는 위험요소를 떠올려내는 것, 그리고 그것을 자연스럽게 제품에 녹여내는 것. 앞으로 내가 어떤 제품을 만들고 어떤 종류의 제약을 마주하든 유의미하게 발휘될 수 있는 역량이라고 생각한다.

 

 

세번째, 여러 층위의 사용자들을 고려하며 제품을 만드는 경험을 할 수 있다

복잡다양한 것을 고려해야 한다는 특성은, 비단 서로 다른 고객사 케이스와 도메인에 대한 것이 아니고 하나의 서비스 안에서도 유효하다. 두번째 포인트의 세부 항목이라고 볼 수 있는 이 부분을 특히 집고자 했던 것은, 기획·디자인을 하는 사람들에게 유저에 대한 이해라는 것이 특히 중요한 영역이기 때문이다. 

 

어떤 서비스이든 다양한 유저군을 고려하며 제품을 만들어야 하는 어려움이 있겠지만, SaaS의 경우 페르소나가 다양한 것뿐 아니라 기본적으로 마주하게 되는 사용자의 '층위' 자체가 여러 겹이기 때문에 더욱 그렇다. 최종 사용자에게 가닿기까지, B2B2C SaaS 제품은 웹, 앱, 관리자페이지 등의 다양한 터치포인트에서 여러 층위의 사용자들을 마주한다.

 

Disclaimer에 남기진 않았지만 내가 만들었던 canD는 각 서비스가 그 하위에 멀티 커뮤니티를 구성할 수 있기 때문에 더욱 그러했다.

예시로 canD의 고객사 중 한 곳인 사회적 가치 커뮤니티 플랫폼 베이크 는, '액션'이라는 하위 커뮤니티들을 두어 다양한 사회적 가치를 베이크라는 한 플랫폼 안에서 실천할 수 있도록 한다. 

베이크의 다양한 액션들

베이크의 스토리에 집중해 제품을 빌딩한다고 가정하면, 베이크 서비스의 최종 관리자부터 각 하위 커뮤니티인 액션의 운영자, 그리고 각 액션에 참가하는 사용자와 베이크 메인 서비스 자체를 중점으로 사용하는 사용자들 - 다양한 주체들을 고려해야 한다. 

 

위 두번째 포인트에서 언급했던, 우리가 아닌 고객들이 운영하기 때문에 복잡도가 기하급수적으로 증가하는 SaaS 제품의 특성은 이렇듯, 이해해야 하는 주체의 다양성에서도 그렇다.

이렇게 서로 다른 주체들 각각의 니즈를 탐구하고, 또 주체들 서로의 관계가 어떠하고 사용자 여정의 어떤 지점에서 어떤 상호작용을 하게 되는지 등의 문법을 이해하면서 만드는 것이 SaaS 제품에서는 매우 중요하다.

canD 제품 개발 당시에 작성한 유저 플로우. 고려해야 할 각 주체 각각의 플로우를 나눠 그리거나, 한 플로우 안에서 주체들의 상호작용을 표현하는 것이 일상이다.

 

기획·디자인 단계에서는 주체들마다의 유저 플로우를 그리거나, 하나의 플로우 차트 안에서 다른 주체들의 여정이나 서로 간의 상호작용을 표현하며 기능이나 UX 적으로 놓쳐지는 유저 케이스가 없는지를 확인한다. 이후 개발을 하고 QA할 때에도 각 유저군들 마다의 유저 플로우에서 마주할 만한 엣지 케이스들을 놓치지 않고 테스트하는 것이 중요하다. (이렇게 하더라도 놓쳐지는 것이 많다🥲)

 

이러한 유저에 대한 다층적인 접근이 필수적인 환경은 단순 UX 설계 이상의 역량을 선물한다.

다양한 주체들의 니즈를 하나의 시스템 안에서 풀어내기 위해 사용자들 간 상호작용의 문법을 깊이 탐구하게 된다. 복잡하게 얽힌 유저 플로우의 모든 지점에서 발생할 수 있는 다양한 케이스를 예측하고 해결하는 능력을 강화한다. 또 어떤 주체의 경험에 우선순위를 두고 집중할지 의사결정할 때에는 비즈니스 전략을 연결시켜 고민해야 하기도 한다. 다양한 유저들의 시선에 몰입해 제품과 비즈니스를 바라보면서, 보다 견고한 제품을 만드는 훈련을 하게 된다고 느낀다. 

 

 

마무리하며

SaaS를 만들면서 나는, 다양한 도메인을 경험하며 앞으로의 내 커리어 방향성을 보다 명확히 할 수 있었고, 복잡한 상황과 다양한 케이스를 위한 솔루션을 도출하는 논리적인 사고를 성장시켰으며, 다양한 사용자들의 스토리를 하나의 그림으로 풀어내는 역량을 길렀다.

개인적으로 나는 이 제품을 내 커리어의 시작점에서 만난 게 행운이었다고 생각한다. 

 

이 글은 어쩌면 나의 커리어에 대한 변호일 수도, 또 수년간 모든 걸 쏟은 대상에 대한 미련 섞인 애정일 수도 있다.

완벽한 회사나 제품은 없고, 나도 다른 이들이 SaaS 제품을 만들면서 느낄만한 배고픔을 느끼기도 했다. 무엇을 그 다음 스텝으로 삼을지에대한 결정도 그 아쉬움이 영향을 줬지만, 서두에 언급했듯 나는 이 제품을 만든 시간에 후회가 없다. 퇴사한 뒤 3년 반의 시간을 돌아보며 Lesson Learned를 정리할 수록 더욱 그렇다.

내가 모든 SaaS를 만드는 경험을 대변할 수는 없지만 적어도 SaaS를 만든다는 것이 마냥 '납작한' 경험일 거라는 막연한 추측만은 조금이나마 해소할 수 있으면 좋겠다. 사실 그 과정은 오히려, 굉장히 (때로는 너무나) 입체적이기 때문이다.

 

이 글을 읽고 제품을 만드는 커리어로서 무매력이라는 SaaS에 대한 오해를 풀 수 있길, 혹은 읽고 난 결론이 '역시 SaaS는 아니다'하는 것일지라도 막연함을 덜 수 있기를 바란다!