1. 뜨거운 노 코드 열기

최근 들어 노 코드 툴에 대한 관심도가 엄청 커짐을 체감하고 있다. 새로운 툴을 배우는 걸 좋아해서 작년에 노 코드 툴, 버블(Bubble)을 혼자서 공부하고 간단한 가이드 글을 작성한 적이 있다. 그리고 최근 1~2달 동안 이 글을 보고 MVP를 만들고 싶은데 버블로 외주를 맡아줄 수 있냐는 연락을 꾸준히 받고 있다.

개발자도 아닌데 서비스 외주라니! 외주 비용을 생각하면 수익이 짭짤하긴 하지만, 최근에 회사를 퇴사하고 창업을 시작해서 잉여 리소스가 없는 상태라서 어쩔 수 없이 거절하고 있다. 그 대신, 컨설팅이나 조언 정도는 하고 있다. 그러다 문득 “왜 사람들은 버블로 직접 서비스를 만들지 않고, 외주를 맡기려고 하는 거지?”라는 의문이 들었다.

• 관련 글 「노 코드 툴, 버블(Bubble) A to Z」

2. 왜 버블일까?

노 코드 툴은 이름 그대로 ‘코드 없이 서비스를 만들 수 있게 돕는 툴’이다. 해외에서는 매우 많은 노코드 툴이 존재하는데, 여기서 큰 영향력을 뽐내는 툴이 버블(bubble)이다.

버블은 웹앱 빌더로 데스크톱과 모바일, 모두 대응 가능한 서비스를 만들 수 있다. 필자가 버블을 선택한 이유는 크게 2가지인데 ① 높은 자유도와 ② 활발한 커뮤니티다. 거의 노 코드 툴계의 인싸라고 보시면 된다.

① 높은 자유도

노 코드 툴에서 ‘자유도’와 ‘빠른 구현’은 트레이드오프의 영역이다. (물론 지극히 개인적인 생각입니다) 노 코드 툴인 Glide와 Bubble을 비교해보자. Glide는 “빠른 구현”이 가능한 노코드 툴이다. 애초에 레이아웃 형식이 고정됐기에 컴포넌트의 세부적인 조율은 불가능하다. 따라서, 고정된 레이아웃에 데이터만 불러오면 서비스가 뚝딱 하고 완성된다.

반대로, Bubble은 “자유도”가 높은 노코드 툴이다. 각 컴포넌트의 위치를 픽셀 단위로 직접 조율 가능하고, 복잡한 로직도 하나하나 설정이 가능하다. 스타일링부터 로직까지 하나하나 직접 설정할 수 있는 만큼, 더 많은 시간이 걸린다.

② 활발한 커뮤니티

개발자라면 공감하겠지만, 커뮤니티는 정말 중요하다. 커뮤니티가 잘 구현될수록 자신이 모르는 부분에 대한 조언이나 정보를 더 쉽게 찾을 수 있다. 버블의 커뮤니티를 보면 커뮤니티가 상당히 활발히 운영됨을 알 수 있다.

버블 어떻게 시작할지 막막해요

1. 한글 아티클이 없다고요?

구글에 ‘노 코드 툴 버블’을 검색하면, 아이러니하게도 작년 9월에 썼던 내 글이 최상단으로 노출이 된다. 즉, 지난 8개월 동안 버블 관련 정보 글이 크게 업데이트된 게 없다는 말이다.

그나마 있는 아티클은 “왜 노코드 툴을 사용해야 하는가?” “버블은 왜 좋은가?”와 같은 이론적인 부분만 다루고 있고, 버블 사용법을 자세하게 다루는 한글 아티클은 거의 찾을 수 없다. 모두가 “노 코드 툴 좋아!”라고 말하지만, 정작 한국에서는 노 코드 툴을 시작할 수 있는 환경이 없는 셈이다.

2. 그래서, 제가 썼습니다

많은 분이 버블을 쓰길 원하지만, 시스템이 이를 뒷받침하지 못한다. 그러니, 나라도 한 번 이 내용을 다뤄보려고 한다. 이전에 버블로 같은 학교 사람들끼리 책을 교환하는 서비스를 일주일 정도 시간을 쏟아서 구현한 적이 있다. (링크 클릭) 누구나 버블로 이런 서비스를 버블로 만들어 볼 수 있도록, 관련 기본기를 하나하나 잡아보려고 한다.

버블 시작하기

1. 회원가입과 앱 생성

우선 버블에서 회원가입을 하고, 새로운 앱을 만들어야 한다. 로그인 후 우측 상단의 [Menu] 버튼을 누르면 뜨는 팝업에서 [My Apps]를 클릭한다. 이동된 페이지에서 [New App]을 클릭하면, 새로운 앱을 만들 수 있다.

참고로 버블의 요금 모델은 앱을 기준으로 한 구독료다. 각각의 앱마다 결제를 해야지 배포를 할 수 있다. 학생 계정(ex. @yonsei.ac.kr)으로 회원가입을 하고 문의를 남기면, 결제 할인 쿠폰을 받을 수 있으니 참고하자.

새로운 앱을 생성하면, 아래와 같은 페이지로 이동한다. 여기서 왼쪽 상단의 [Page:index] 드롭다운을 클릭하면, 서비스의 각 페이지나 재생산 컴포넌트로 이동할 수 있는 팝업이 뜬다. 그 밑에 [Design], [workflow] 등이 있는 GNB에서 다른 설정 페이지로 이동할 수 있다.

2. 페이지 뜯어보기

왼쪽 상단의 [Page] 드롭다운을 클릭하면, 아래와 같은 창이 뜬다. 여기서는 서비스의 여러 페이지나 재생산이 가능한 컴포넌트로 이동할 수 있다. 버블에서 신규 앱을 생성하면 기본 페이지로 ① Index ② reset_pw, ③ 404 페이지가 함께 생성된다. 그리고 아래의 [Add a new page]를 누르면, 신규 페이지를 생성할 수 있다.

그런데 새롭게 생성한 페이지는 오른쪽에 쓰레기통 삭제 아이콘이 있는데, 기본 페이지는 존재하지 않는다. 즉, 3개의 기본 페이지는 삭제가 불가능한 페이지다.

왜 기본 페이지는 삭제가 불가능할까? 기본 페이지 1개만 삭제되지 않도록 하면 되지 않을까?

Index 페이지는 서비스의 기본 페이지고, reset_pw와 404 페이지는 서비스에서 일어나는 특수한 상황을 대응하기 위해 존재한다. 우선, 404 페이지는 서비스에서 404 오류가 뜰 때 자동으로 이동하는 페이지다. 즉, 별도 설정 없이 404 오류가 뜨면, 별도 설정을 하지 않아도 해당 페이지로 자동 이동된다.

reset_pw 페이지는 비밀번호 초기화 기능이 있는 페이지다. 버블은 자체 DB를 제공하지만, 이 DB에서 유저가 회원가입에 사용한 패스워드를 볼 수 없다.

만약 유저가 서비스를 사용하다가 비밀번호를 잊어버렸다면? 버블 DB에서 유저의 비밀번호를 찾아줄 수 없고, 그 대신에 유저가 비밀번호를 초기화할 수 있게 만든다. 이때 사용하는 게 reset_pw 페이지다. 유저가 비밀번호 초기화를 요청하면, reset_pw 페이지가 자동 전송된다.

3. GNB 뜯어보기

GNB를 통해 이동하는 각 페이지에서는 아래의 설정을 추가 및 변경할 수 있다. 보다 자세한 설명은 이 링크를 참고하자!

• [Design] : 웹앱의 요소(element)를 배치 및 수정
• [Workflow] : 각 페이지마다 워크 플로우(Trigger – Action)를 설정
• [Data] : 데이터 속성값을 설정 + 생성된 데이터가 모인 DB를 확인
• [Styles] : 요소(element)에 범용적으로 적용 가능한 스타일을 설정
• [Plugins] : 웹앱에 적용할 플러그인 탐색 및 설정
• [Settings] : 도메인, 웹앱 언어, HTML Header 및 Body 등을 설정
• [Logs] : 서버 상태, 워크 플로우 로그 확인

회원가입 메뉴바 만들기

1. Header 설정

기본 페이지 외에도 3개의 재생산 컴포넌트인 ① Header ② Footer 그리고 ③ Signup / login popup이 자동 생성된다. 여기서 Header를 이용해 회원가입과 로그인을 구현해보자! 검색 팝업에서 Header를 클릭하면, Header 컴포넌트 창이 나온다.

왼쪽의 UI Bilder 창에서 필요한 컴포넌트를 바로 추가하거나, 기존에 생성한 재생산 컴포넌트를 불러올 수 있다. UI Bilder는 크게 아래의 섹션으로 구성되는데, 각 섹션의 요소는 다음의 상황에서 사용된다.

1. Visual Elements : 특정 도형, 요소를 만들 때
2. Containers : 생성한 컴포넌트를 그룹화할 때 or 특정 컴포넌트를 반복적으로 만들어야 할 때 or 팝업, 모달을 구현해야 할 때
3. Input Forms : 유저와 인터렉션 할 때 or 유저에게 데이터를 받을 때
4. Reusable Elements : 기존에 생성한 재생산 컴포넌트를 불러올 때

헤더에서 버튼이 있고, 이 버튼을 클릭하면 팝업이 나와서 로그인 및 회원가입이 가능하게 만들어 보자. 우선 이미지와 아이콘 요소를 활용해, Header 컴포넌트를 아래와 같이 만든다.

2. 메뉴바 만들기

그리고 UI Bilder에서 Container 요소 유형 중의 하나인 [Group Focus] 요소를 추가한다. 해당 요소는 여러 요소를 그룹화시켜주는 요소인데, [Group] 요소와 다른 특징이 있다. 특정 요소를 기준으로 설정한다면, 이 기준 요소의 위치 값에 따라 자신도 위치를 자동으로 조정한다.

아래 설정 아이콘 밑에 있는 팝업은 [Group Focus] 요소이고, 이 요소 안에는 회원가입, 로그인 등 다양한 버튼 요소가 포함됐다. 팝업의 설정 창을 보면, [Reference element]에 [icon Tab] 요소가 선택된 걸 볼 수 있다. 여기서 ‘icon tab’은 팝업 바로 위에 위치한 설정 아이콘의 이름이다.

따라서 팝업은 설정 아이콘의 위치를 기준으로, 자신의 위치를 자동 조정한다. 굳이 [Group Focuse] 요소를 쓰는 이유는 반응형에서의 팝업 위치 때문이다. 버블을 반응형 UI로 구현한다면, 기기에 따라서 컴포넌트의 위치가 달라질 수 있다. 이때, [Group Focuse] 요소를 쓰면, 기준 컴포넌트의 위치에 맞춰서 함께 이동한다.

이제 설정 아이콘을 선택할 때, 팝업을 뜨게 설정하면 된다. 설정 아이콘의 설정 창에서 [Start/Edit Workflow]를 클릭한다. 그러면, 작동 로직을 설정할 수 있는 [Workflow] 페이지로 이동한다.

3. 메뉴바 띄우기

WorkFlow는 크게 ① 트리거와 ② 액션으로 구성된다. 트리거는 ‘해당 워크플로우를 작동시키는 이벤트’를 뜻하고, 액션은 ‘해당 워크플로우가 작동되고, 자동으로 발생하는 이벤트’를 뜻한다. 아래 이미지를 보면 ‘When’이라 적힌 부분이 트리거가 들어가고, 그 아래 ‘Step’이라 적힌 부분에 여러 액션이 들어간다.

트리거로 다양한 이벤트를 설정할 수 있다. 버튼을 클릭했을 때, 팝업이 뜨게 만드려고 하니깐 트리거로 [Elements] – [An element is clicked]를 선택하면 된다. 그러면, 트리거 설정 창이 나오는데 여기서 [Element] 입력 필드에 클릭할 아이콘을 선택한다.

어떤 버튼을 클릭할지 설정했으니, 이제 띄울 팝업을 설정할 차례다. 액션으로 [Elements] – [Show]를 선택하고, 액션 설정 창에서 [Element] 입력 필드에 띄울 팝업을 선택하면 된다.

트리거, 액션을 설정할 때 그 자체에 조건문을 걸 수 있다. 예를 들어, 비회원과 회원이 아이콘을 눌렀을 때 뜨는 팝업을 다르게 만들고 싶을 수 있다. 이

런 경우 비회원과 회원, 각각이 볼 팝업을 만들고 액션을 만들 때 [only When] 부분에 조건문을 걸면 된다. only When 부분의 조건이 맞다면 액션이 진행되고, 그렇지 않으면 해당 액션은 스킵되고 다음 액션으로 넘어간다.

회원가입 로직 구현하기

1. 회원가입 팝업 만들기

이제 헤더에 설정 아이콘을 누르면, 설정 팝업이 나온다. 그다음으로 팝업에 회원가입 버튼을 구현하고, 이 버튼을 클릭했을 때 회원가입을 진행하는 팝업이 뜨게 만들면 된다. 이번에는 UI builder에서 [pop up] 요소를 생성해 보기로 했다. 그러면 페이지와 독립적인 빈 팝업이 생성된다. 이후, 팝업 안에 이메일과 비밀번호를 입력받을 [input] 요소를 생성한다.

생성한 input 요소를 클릭해서 설정 창에 들어가고, 관련 설정을 입력하면 된다. [PlaceHolder]는 데이터를 입력받지 않은 상태에서 보여주는 값이다. [Initial content]는 입력 초기 값으로, 별도 입력을 하지 않으면 해당 값이 그대로 적용된다. [Content Format]은 입력값의 형식을 설정한다. 이런 식으로 이메일과 비밀번호를 입력받는다.

2. 유저 속성 추가하기

만약 이메일, 비밀번호 외 또 다른 정보를 회원가입 때 받아야 한다면? 그러면 우선 해당 데이터를 저장할 수 있는 공간을 만들어야 한다.

DB 수정을 위해 GNB에 있는 [Data]로 이동한다. 처음 들어가 보면 User 개체가 기본적으로 존재한다. 여기서 [Create a new field]를 클릭하고 User 개체에 새로운 속성을 추가할 수 있다. 유저의 닉네임, 프로필 사진, 정보 등의 속성값을 자유롭게 추가하면 된다.

3. 회원가입 로직 만들기

이제 회원가입 버튼을 클릭했을 때, 회원가입 관련 이벤트를 처리하는 워크플로우를 생성하면 된다. 방금처럼, ‘버튼 클릭’을 트리거로 설정하면 된다.

액션으로 [Account] – [Sign the user up]을 선택한다. 그러면 오른쪽과 같은 설정 창이 뜬다. [Eamil]과 [Password]는 회원가입 때 쓴 이메일, 비밀번호를 입력하는 곳이다. [Confirmation]은 비밀번호 재입력 값을 입력하는 곳이다. 만약 [Password] 값과 [Confirmation] 값이 다르면, 오류가 뜬다.

해당 입력 필드의 값으로, 회원가입 팝업에서 추가한 input 요소의 입력 값을 불러오면 된다. 입력 필드에서 요소의 이름을 입력하면, 해당 요소가 바로 나온다.

회원가입 과정에서 이메일, 비밀번호뿐만 아니라 닉네임, 회원 정보 등을 입력받는다면, [Change another field]를 클릭하고 User 개체의 속성을 추가로 입력하게 만들 수 있다.

회원가입 완료 이메일을 보내고 싶다면, 다음 액션으로 [Email] – [Send email]을 추가하면 된다. 회원가입과 이메일 보내기 액션을 모두 완료했으면, 마지막으로 회원가입 팝업을 닫아야 한다. 해당 액션은 [element] – [hide]를 하면 된다.

이제 회원가입 기능 구현을 완료했다! 이렇게 보면 매우 복잡하고 많아 보이지만, 회원가입을 한번 구현해보면 그 외의 기능은 모두 쉽게 배울 수 있다. 애초에 작동 원리가 모두 비슷하기 때문이다.

버블을 더 자세하게 알고 싶다면?

버블의 모든 기능을 하나하나 짚어가며 서비스를 만드는 과정은 아래 링크에서 확인할 수 있습니다.

원문: FameLee의 브런치

이 필자의 다른 글 읽기

• 노션으로 만드는 궁극의 휴가 관리 시스템
• 프로덕트가 ‘될 놈’인지 알아내는 방법
• 노 코드 툴, ‘버블’의 A to Z

5월에 PM으로 근무해 온 스타트업을 퇴사했고, 창업을 시작했다. 퇴사 직후 2개월 동안 팀 빌딩 과정을 거쳤고, 7월이 돼서야 만족스러운 팀 빌딩이 끝났다. 팀이 새로 만들어지면서, 서비스도 새롭게 리빌딩됐다. 문제와 핵심 가치도 새로 정의했으며, 전반적인 UI도 개편이 진행됐다. 무엇보다 서비스명도 ‘마이플랜잇’에서 ‘투두몰’로 바뀌었다. 마이플랜잇은 일단 회사명으로 가져가기로.

• 투두몰 알아보기

창업에 진심인 사람들이 모인 덕분에, 팀이 결성된 직후부터 지난 2개월 동안 많은 성과를 달성했다.

와! 정말 행동력이 미쳤네요!

지금까지 다양한 창업 팀, VC, 엑셀레이터 등을 만났고, 우리가 어떻게 일해왔는지를 이야기하면 모두가 이처럼 말한다. 특히 개발 없이 오직 노션만을 이용해 MVP 테스트를 진행한 이야기를 들려주면, 모두가 신기한 사람을 보는 듯한 눈빛을 보냈다. 노션 장인 FameLee 이번 글에는 우리 팀이 노션을 어떻게 활용해서 MVP 테스트를 성공적으로 마쳤는지 다뤄보려고 한다.

MVP 테스트, 왜 필요해?

1. 가설 검증의 도구

스타트업은 다양한 가설을 설정하고, 검증하는 과정을 반복한다. 애초에 검증을 하지 않는다면, 이는 탁상공론에 불과하다. 아무런 검증도 하지 않고 계속 서비스를 만든다면, ‘유저가 필요한 서비스’가 아니라 ‘나의 편견에 기반한 서비스’가 탄생할 수도 있다.

가설을 검증하기 위한 다양한 방법론이 있다. 피그마로 프로토타입을 만들거나, 랜딩 페이지를 제작해서 사람들의 반응을 볼 수 있다. 하지만 ‘가동되지 않은 프로덕트’로 검증할 수 있는 영역은 한정된다. (1) 피그마로 만든 프로토타입을 10분 동안 눈으로 본 후에 말하는 피드백과 (2) 실제로 구현되는 프로덕트를 며칠 동안 사용하고 주는 피드백, 이 둘을 비교하면 당연히 후자가 많은 인사이트를 줄 수밖에 없다.

MVP 테스트를 진행하는 이유도 마찬가지다. 구현되는 프로덕트를 유저가 직접 사용해봐야, 더 많은 인사이트를 얻을 수 있다.

여기서 잠깐! MVP의 기초 개념을 짚고 넘어가자. MVP는 Minimum Viable Product, ‘최소 기능 제품’을 뜻하며 좀 더 풀어서 설명하면 ‘핵심 가치를 전달할 수 있는, 최소한의 기능을 담은 제품’이다.

여기서 ‘최소한의 기능’에 주목해야 한다. MVP는 완벽한 프로덕트가 아니라, 가설 검증을 위한 실험 도구에 가깝다. 가설을 명확하고 확실하게 검증하기 위해서 유저가 직접 구현되는 서비스를 쓰는 게 가장 좋다. 이때 사용하는 게 바로 MVP다.

2. 무엇을 검증할까?

다시 본론으로 돌아오자. MVP 테스트를 위해, 가장 먼저 해야 할 일은 “어떤 가설을 검증할까?”를 답하는 것이다. 앞서 말했, MVP는 가설 검증을 위한 실험 도구다. 따라서 어떤 가설을 검증할지 명확히 정의해야 MVP 테스트가 의미가 있다. 일단 서비스를 만들어서 배포하고, 수집한 데이터를 기반으로 아무 가설이나 검증하는 것 자체는 너무 비효율적이다.

우리 팀은 ‘프로덕트 선언문’을 사용한다. 프로덕트 선언문이란 1장의 페이지에 다음과 같은 정의를 기재한 문서다.

1. 타겟은 누구이며, 이들이 겪는 문제는 무엇이다
2. 이를 위해 제공하는 핵심 가치
3. 핵심 가치를 전달하는 프로덕트 기능

※ 해당 용어는 FameLee가 인위적으로 정의한 용어입니다.

이 프로덕트 선언문에 적힌 내용은 모두 가설에 불과하며, 계속 변경될 수밖에 없다. 매번 업데이트가 필요한 문서이기에 번거로워 보이지만, 이렇게 구체적으로 정의한다면 팀이 어떤 가설을 검증해야 하는지 동기화하여 결과적으로 같은 방향을 그릴 수 있다.

1. 타겟은 누구이며, 이들이 겪는 문제는 무엇인가? → 문제 가설
2. 이를 위해 제공할 핵심 가치는 무엇인가? → 가치 가설
3. 핵심 가치를 전달한 프로덕트 기능은 무엇인가? → 솔루션 가설

과거 랜딩 페이지 실험과 인터뷰 등을 통해 우리가 정의한 서비스는 “전문가의 경험을 담은 체크리스트 기반의 클래스”였다. 이때 선언문에 적은 1. 문제 가설과 2. 핵심 가치 가설을 MVP를 통해 검증하기로 했다.

즉 1. 우리가 생각한 ‘타겟 고객의 문제’가 정말로 문제가 맞는지와 (2) 우리가 생각한 ‘고객이 원하는 가치’가 정말로 원하는 게 맞는지를 알아보는 걸 MVP 테스트의 목적으로 삼았다. (과거에 진행한 랜딩 페이지 실험이 궁금하면, 아래 링크 참고!)

• 「스타트업 실험, 그거 도대체 어떻게 하는 거야?」

3. 어떻게 검증할까?

무엇을 검증할지 명확히 정의했으니, 이제 어떻게 검증할지를 정의해야 했다. 검증을 위해 MVP를 만들어야 하지만, 이를 개발 기반으로 검증하기엔 ROI가 높지 않다. 애초에 MVP는 가설 검증을 위한 도구인데, 이 실험 도구를 만들기 위해 하나하나 개발하는 건 리소스 낭비다.

문득 든 생각, 개발 없이 노션만을 활용해 MVP 프로덕트를 만들 수 있지 않을까? 후다닥 노션으로 서비스 소개 사이트와 MVP 프로덕트 제작에 돌입했다. 노션 장인이라고 불러주세요

개발 없이 MVP 테스트!

1. 서비스 사이트 만들기

MVP 테스터 모집을 위해 먼저 서비스 사이트가 필요했고, 노 코드 툴을 활용해 하루 만에 모집 시스템을 구축했다.

1. 노션과 우피를 활용해 하루 만에 사이트를 제작했고, 전문가의 경험을 담은 10개의 클래스를 소개했다.
2. 탈리를 통해 개별 클래스 참가 신청을 받았고,
3. 자피어를 이용해, 신청이 완료되면 바로 참가 확인 메일을 전송했다.
4. 탈리와 슬랙을 연동해 신청 알림을 받았다.
5. 마지막으로 실시간 현황 파악을 위해 탈리 데이터를 구글 스프레드시트와 연동한 후
6. 다시 시트를 구글 데이터 스튜디오와 연결해서 대시보드를 구현했다.

100명의 테스터를 모으는 걸 목표로 여러 커뮤니티에 서비스 홍보 글을 올렸다. 테스터가 모이기까지 일주일의 시간을 예측했지만, 놀랍게도 2일 만에 수요가 넘쳐나서 모집을 마감했다.

2. 프로덕트 만들기

MVP 프로덕트도 개발 없이 노션으로 구현했다. 투두몰의 대표 기능은 크게 아래와 같다.

• “클래스”가 여러 “세션(목차)”로 구성되고, 각 세션에는 따라 해야 하는 “체크리스트”가 있다.
• “체크리스트” 안에는 어떻게 따라 하면 되는지 구체적으로 알려주는 “가이드라인”이 있다.
• 각 “세션”마다 “데드라인”이 있으며, 데드라인이 끝나기 전까지 “미션”을 인증해야 한다.
• “미션”을 인증해야지, 그다음 세션이 열린다.

이와 같은 기능을 노션의 데이터베이스, 관계형 속성과 필터 기능을 활용해 클래스 시스템을 구현했다.

하나의 페이지는 한 개의 클래스가 운영될 공간이다. 총 신청 클래스는 약 200개에 달하며, 이에 맞춰 200개의 클래스 페이지를 만들어야 한다. 200개의 페이지 하나하나에 내용을 직접 채워 넣는 건 리소스가 너무 많이 들기에, DB의 템플릿 기능을 사용했다. 클래스를 생성 및 관리할 DB를 만들고, 각 클래스를 템플릿으로 구현했다.

이후, 각 클래스 신청자 수에 맞춰서 템플릿 기능을 활용해 페이지를 만들었다. 각 페이지마다 신청자를 초대하고, 페이지 권한 설정 기능을 활용해 설정을 조작을 하지 못하게 만들었다.

미션 인증은 휴먼 지능을 사용했다. 죽여줘… 매일 아침 10시, 각 클래스에서 세션 미션을 달성했는지 하나하나 파악했고, 페이지 댓글 기능을 활용해 클래스 도전 상황을 공유했다.

3. 데이터 수집하기

MVP 프로덕트를 어떻게 만들지도 중요하지만, 데이터를 어떻게 수집할지도 놓치면 안 된다. 노션 DB에 저장된 클래스 상태 값(Ex. 현재 도전 중인 세션, 클래스 상태 등)은 Notion2Sheet를 활용해 구글 스프레드 시트로 불러왔다. 그리고, 노션에서 자동 수집되기 어려운, 상세 데이터(ex. 세션 오픈일, 단축 시간 등)는 매일 아침에 미션 유무를 확인하면서 시트에 직접 입력했다. 추가적으로, 탈리에 저장된 신청자 데이터를 쿼리로 불러와서 클래스 정보와 합쳤다.

파편화된 데이터를 한곳으로 모은 후, 구글 데이터 스튜디오를 이용해 대시보드를 구현해서 MVP 테스트의 진행 상황 및 이슈를 대시보드로 빠르게 파악할 수 있었다. 파편화된 데이터를 모은 구조는 대략 아래와 같다.

마지막 과정, MVP 인터뷰

1. 세그먼트 나누기

MVP 테스트에서 수집한 정량 데이터로 인사이트를 얻을 수 있지만, 가설을 명확하게 검증하기 위해서 정성 데이터가 필요하다. 테스트가 종료되자마자, 인터뷰 설계를 진행했다. 창업 팀은 쉴 틈이 없다…

MVP 테스터를 모두 동일 집단으로 보고 인터뷰를 진행하면, 자칫 데이터에 오류가 생길 수 있다. 예를 들어 대학교 1학년과 대학교 3학년은 놓인 환경이 다르기에 완전히 다른 행동 패턴을 보인다. 이를 고려하지 못하고 이들을 하나의 집단으로 본다면 데이터에 오류가 생긴다. 따라서 MVP 테스터를 여러 세그먼트로 구분 짓는 게 먼저 필요했다. MVP 테스트 동안에 수집한 데이터를 기반으로, 세그먼트를 분류했다.

2. 인터뷰 방법과 질문 정하기

전화, 줌, 오프라인 미팅 등 다양한 인터뷰 방법을 두고, 어떤 방법을 택해야 할지 고민했다. 각 세그먼트에서 인사이트를 뽑아내려면 충분한 모수가 모여야 한다. 만약 세그먼트에서 1~2명이 응답을 한다면, 자칫 편향된 정성 데이터를 얻을 수도 있기 때문이다.

따라서 인터뷰 응답률을 판단 기준으로 뒀고, 전화 인터뷰를 진행하기로 했다. 전화 인터뷰가 다른 방법에 비해 (1) 부담감이 가장 적고, (2) 즉각적으로 응답을 받아주리라 생각했다.

각 세그먼트마다 보인 행동 패턴을 데이터로 유추하고, 인터뷰 질문을 설계했다. 이때, MVP 테스트의 목적에 맞게 “(1) 문제 가설과 (2) 핵심 가치 가설을 검증하기 위해서 어떤 질문을 해야 할까?”를 생각하며 질문을 리스팅 했다.

3. 진행하기

각 세그먼트별로 전화 인터뷰를 진행했다. 전화 인터뷰 진행 프로세스도 최대한 응답률을 높일 수 있는 방향으로 설계했다. 전화를 받으면 (1) 서비스를 이용해서 고맙다는 감사 인사와 (2) 인터뷰 목적을 먼저 전달드려서, 낯섦과 거부감을 최대한 없애는 데 중점을 뒀다. 이후, (3) 참가 혜택과 (4) 인터뷰 예상 소요 시간을 전달드려서, 인터뷰 참가를 회유(?)했다.

추가적으로, 인터뷰 진행자에 따른 수집 데이터의 차이가 생기지 않도록 1명이 대화를 이끌고, 다른 1명이 응답을 기록하는 식으로 진행했다.

4. 인사이트 뽑아내기

전화 인터뷰에 엄청나게 높은 응답률을 보여줬고, 많은 정성 데이터를 수집할 수 있었다. 이제 정성 데이터에서 인사이트를 정의 내릴 차례다. 정성 데이터 분석으로 어피니티 다이어그램 방법을 사용했다. 세그먼트마다 얻은 정성 데이터를 포스트잇에 리스팅 하고, 화이트보드에서 클러스터링 해서 인사이트를 뽑아내는 과정을 몇 시간 동안 반복했다.

클러스터링 결과, 최종 정의한 인사이트를 기반으로 ① 문제 가설과 ② 핵심 가치 가설을 검증했고, 최종적으로 프로덕트 선언문을 업데이트했다.

마치며

이렇게 MVP 테스트의 AtoZ 경험을 기록해보니 생각보다 엄청나고 많은 걸 진행했다. 다양한 노 코드 툴을 쓸 줄 아는 덕분에 개발에 의존하지 않고도 아이디어를 구현하고, 체계적인 시스템을 구축할 수 있었다. 만약 초기 창업 팀이라면, 틈내서 노 코드 툴을 공부해보길 추천한다!

• 투두몰 바로가기

원문: FameLee의 브런치

이 필자의 다른 글 읽기

• 회고를 까먹지 않고, 매주 하고 싶다면?
• 의사결정에 품격을 더하다, 데이터 시각화!
• 1인 사이드 프로젝트에서 B2B 서비스로 확장하기까지

• 노션박스 바로가기

머릿속에 떠오르는 아이디어를 만들길 좋아하다 보니 혼자서 다양한 프로젝트를 진행해왔는데, 이렇게 오랫동안 지속해 온 프로젝트는 처음이었다. 약 1년이란 시간 동안 학교와 회사라는 바쁜 일정에도 불구하고, 혼자서 프로젝트를 끌고 온 이유는 프로덕트를 좋아하는 분들이 있기 때문이었다. 유저에게 사랑받는 프로덕트를 만들었다는 신호는 PM에게 가장 좋은 원동력이다. 잠시 시간을 내서 최근의 기록을 남겨본다.

프로덕트가 떠오른 순간

재미를 목적으로 1인 사이드 프로젝트를 해왔지만, 많고 많은 아이템 중에서 왜 하필 노션이었을까? 과거, UGC (User Generated Content) 시장을 다루는 아티클을 본 적이 있다. 아티클에서 굿노트의 사례가 나왔는데, 굿노트 유저가 직접 다이어리, 스티커 템플릿을 만들어서 판매하는 굿노트 다꾸 시장을 소개했다.

굿노트의 다꾸와 노션, 모두 같은 가치를 제공하는 것 같은데 왜 노션 템플릿 시장은 없을까? 주변에서 노션을 활용해 일기를 쓰거나 일정을 관리하는 분들이 많았고, 다꾸와 비슷한 목적으로 노션을 쓰고 있다고 느꼈다. 동시에 국내에서 ‘노션 템플릿 시장’을 처음 형성한 사람이 될 수 있지 않을까란 생각이 들었다.

Joey를 운영하시는 대표님의 인사이트로 해외에선 노션 템플릿 시장이 있음을 뒤늦게 알게 됐다. 솔직히 말하면, 노션박스를 처음 구상할 당시 해외 사례는 찾아보지도 않았다. 사이드 프로젝트니까 어떠한 전략도 고민하지 않고, 재밌어 보이는 걸 바로 하자는 마인드였기 때문이었다. 실제로 이런 마인드로 했다가 재미만 보고 망한 프로젝트가 한두 개가 아니다.

프로덕트를 개발 없이 만들기까지

프로덕트를 완벽하게 만드는 게 아니라, 프로덕트를 가볍게 만들어서 검증하는 게 트렌드가 됐다. 불과 몇 년 전까지만 해도 프로덕트를 만들기 위해서 ‘개발’이란 수단이 필수적이었다. 하지만 ‘린’, ‘가설 검증’과 같이 개발에 크게 의존하지 않는 흐름이 생겼고, 다양한 노코드 툴이 보급되면서 프로덕트의 개발 의존도가 떨어졌다. 이러한 탈 개발 트렌드는 1인 사이드 프로젝트를 가능케 만들었다.

빠른 가설 검증에 최적화된 사람이 되고자 다양한 노 코드 툴을 혼자서 공부해왔고, 덕분에 개발 없이도 프로덕트를 만들 수 있게 됐다. 노션박스도 노션, 자피어, 탈리 등 다양한 SaaS 툴을 접목시켜서 만든 프로덕트다. 겉보기에는 평범한 웹사이트처럼 보이지만, 백스테이지 단에는 다양한 툴이 사용됐다.

• 관련 글 「노코드로 2만 명이 사용한 프로덕트 만들기 (1)」

유저가 알아서 찾아오기까지

노션박스가 ‘유저에게 사랑받는 프로덕트’라고 생각한 이유는 매우 심플했다. 어떠한 액션을 취하지 않아도 사람들이 찾아오는 서비스였기 때문이다. 애초에 재미를 목적으로 시작한 1인 사이드 프로젝트라서, 여기에 큰돈을 쏟기 싫었다. 결국 내가 할 수 있는 건 사람들이 알아서 찾아올 수 있도록, SEO를 잘하는 일뿐이었다.

당연히 서비스를 처음 런칭했을 때, 별도의 유입은 없었다. 새로운 템플릿을 추가할 때마다 노션 페이스북 커뮤니티에 글을 올렸고, 커뮤니티로부터 유입되는 게 전부였다. 그러나 서비스를 런칭하고 2개월이 지난 시점부터 갑작스럽게 유입이 폭발했다. 이때 대다수의 유입이 구글 검색을 통해 들어왔다. SEO가 워킹하는 순간이었다.

• 관련 글 「한 달 동안 검색 유저가 750% 증가했다고?」

SEO가 워킹한 이후, 매주 약 200명의 유저가 검색을 통해 유입되고 있다. 최근에는 거의 80% 정도의 유저가 검색을 통해 들어오고 있다. 이제는 유저가 알아서 찾아오는 서비스로 완전히 자리 잡혔다.

매출이 발생하기까지

유저가 꾸준히 들어오고 있는 모습을 보고, 새로운 실험을 진행했다.

이 서비스를 사람들이 돈 주고 사용하는가?

서비스를 얼마나 많은 사람들이 찾아오는지도 중요하지만, 찾아온 사람들이 돈을 내는지가 무엇보다 중요하다. 애초에 돈을 벌 수 없는 서비스면, 지속되기 어렵다.

이전까지 모든 템플릿은 무료였고, 많은 사람들은 무료 템플릿을 다운로드했다. 그러면 무료가 아닌 유료 템플릿도 사람들이 구매할까? 실험을 위해 ‘크티’라는 크리에이터 마켓 플레이스 서비스를 이용해, 기존의 무료 템플릿 중 일부를 유료로 판매해봤다. 매출의 발생 유무에 따라서, 사람들이 돈을 내면서까지 쓰고 싶은 서비스인지 아닌지 검증할 수 있다.

• 관련 글 「부수익을 만드는 나홀로 사이드 프로젝트」

놀랍게도, 유료 템플릿을 판매하자마자 사람들은 돈을 지불하며 템플릿을 구매했다. 가격 실험을 약 2개월 동안 진행해왔는데 매일 템플릿이 판매되고, 매출이 꾸준하게 발생했다. “서비스를 사람들이 돈 주고 사용하는가?”에 대한 확신을 얻었다.

B2B 서비스로 확장하기까지

사용자도 찾아오고, 매출도 발생하고 있다. 다만, 이 수치가 급격히 변화하지는 않았다. 검색 유입은 일정했고, 매일 발생하는 매출도 일정했다. 현재 서비스가 임계점에 도달했다고 판단했다.

그렇다면, 넥스트 액션은 무엇을 해야 할까? 현재 서비스를 개선하는 건 큰 의미가 없다고 판단했다. 문득, 이전 토스 강의에서 접한 Carrying Capacity가 떠올랐다. 해당 강의에서는 CC 규모를 늘리기 위해선 ① Inflow를 늘리거나 ② Chrun Rate를 줄이는 방법밖에 없다고 말했다.

• 관련 글 「토스 세션, Carrying Capacity 요약」

애초에 서비스가 앱처럼 주기적으로 접근하는 서비스는 아니기에, Chrun Rate를 개선하는 방법은 한계가 있다. 노션박스의 서비스 특성상, CC를 효과적으로 늘리기 위해서 Inflow를 늘려야 했다. Inflow를 늘리기 위해 완전히 새로운 서비스를 노션박스에서 추가하기로 했다.

어떤 서비스를 추가해야 할지 고민했고, B2B 서비스를 시작하기로 했다. 노션박스를 처음 런칭할 때, 내 인생에 큰 영향력을 끼친 PO님에게 이야기를 드리니 기업을 대상으로 서비스를 해보는 건 어떻냐는 의견을 주신 적이 있었다. 실제로 메일을 통해 기업 시스템을 구축해달라는 요청을 많이 받기도 했고, 기업을 타겟으로 한 템플릿의 다운로드 전환율도 높은 편이었다.

• 노션 올인원 기업 솔루션 Notion Box Enterprise

새로운 팀원을 모집하기까지

B2B 서비스는 B2C와 결이 다르다. B2B 서비스의 경우, 고객 개개인이 창출하는 가치가 매우 높기 때문에 지속적인 케어를 해야만 한다. 기존 노션박스의 템플릿은 딱히 고객에 의존하지 않고, 시간이 있을 때마다 작업을 하면 됐지만, B2B는 상황이 다르다. B2B 고객과 꾸준하게 연락을 해야 하며, 즉, B2B 서비스를 런칭하기 위해 그만한 고객 관리 리소스가 필요하다. 하지만, 창업을 하고 있기에 B2B 서비스에 그만한 리소스를 쏟는 게 사실상 힘들었다.

기업 고객 관리 리소스는 필수적인데, 내가 투자 가능한 리소스는 한정됐다. 그러면 어떻게 해야 할까? 답은 간단했다. 서비스에 투자하는 총 리소스를 늘리면 된다. 즉, 1인 사이드 프로젝트에서 벗어나, 이제는 함께 리소스를 투자할 수 있는 분을 모셔오면 됐다. 노션 기업 서비스를 운영할 수 있는 팀원을 모집했고, 감사하게도 노션 전문가 4명이 합류하게 됐다.

창업과 프로젝트를 함께 하는 이유

주변 사람들이 나에게 항상 물어보는 질문이 있다.

창업도 하고 있는데, 프로젝트를 할 수 있는 시간이 돼?

본업은 창업이기에 우선순위가 여기에 더 높을 수밖에 없고, 몸을 갈아가며 여유 리소스가 생길 때마다 프로젝트에 쏟고 있다. 왜냐하면, 창업과 프로젝트에서 배울 수 있는 부분이 전혀 다르며, 결과적으로 나의 성장에 큰 영향을 주기 때문이다.

진행 중인 창업 서비스는 아직 PMF를 검증하기 전 단계로, 여러 가설을 검증해야만 한다. 반면, 현재 프로젝트는 PMF를 검증한 후의 단계에 있다. 유저가 꾸준하게 찾아오고, 심지어 돈을 내면서까지 서비스를 사용하고 있기에, PMF를 어느 정도 달성했다고 판단했다.

PMF 검증 유무에 의해서 액션은 크게 달라진다. PMF를 검증하기 전이라면 다양한 가설을 설정하고, 이 가설을 검증하는데 초점을 맞춘다. PMF를 검증한 후라면, 이 서비스를 그로스 하기 위한 액션에 초점이 맞춰진다. 개인이 성장하는데 가장 큰 영향을 주는 건 경험이다. 그리고, 창업 팀은 PMF 검증 전 단계의 경험을, 프로젝트는 PMF 검증 후 단계의 경험을 제공한다. 이렇게 개인의 성장에 큰 영향을 주는데, 리소스를 갈아 넣지 않을 이유가 있을까? 성장을 갈망하는 만큼 리소스를 갈아 넣어서 둘 다 가져가는 욕심을 부리고 있다. 물론 몸이 갈려나가고 있다.

원문: FameLee의 브런치

표지 이미지 출처

• 작가 pikisuperstar / 출처 Freepik

이 필자의 다른 글 읽기

• 회고를 까먹지 않고, 매주 하고 싶다면?
• 의사결정에 품격을 더하다, 데이터 시각화!
• 부수익을 만드는 나홀로 사이드 프로젝트

1. FameLee가 부수익을 생각한 이유

5월에 다니는 회사를 퇴사하고, 창업을 시작했다. 문제는 창업을 하고, 수익을 만들기까지 생계(?)를 유지할 수 있을지 고민이었다. 서비스가 당장 대박이 나서 돈이 나면 좋겠지만, 모든 창업이 그렇듯 수익이 발생하기까지 시간을 예측할 수 없었다. 회사를 다니면서 모은 돈이 있지만, 언젠가 이 돈은 바닥날 것이다.그 이후에 버틸 수 있을지 의문이다. 하고 싶은 일이 있지만, 돈이 없어서 할 수 없는 상황은 막고 싶었다.

창업과 별개로, 생계를 유지할 수 있는 캐쉬 카우가 있어야 한다는 결론을 내렸다. 그렇다고, 캐쉬 카우를 만들 수 있는 무엇인가를 만드는 데 리소스가 아까웠다. 창업에 모든 리소스를 쏟아야 하는데, 캐쉬 카우에 신경을 쓴다니… 이건 사치다!

2. 사이드 프로젝트로 돈 벌기

문득 떠오른 아이디어! 작년 10월부터 사이드 프로젝트로 노션 템플릿 사이트를 만들어 배포했고, SEO를 잘 설정한 덕분에 이제 신경 쓰지 않아도 유저가 검색 유입으로 꾸준히 들어오는 단계에 이르렀다. 이 사이트를 잘 활용하면, 캐쉬 카우를 충분히 만들 수 있겠다는 확신이 생겼다.

• 나의 노션 무료 템플릿

콘텐츠를 유료로 판매하기

노션 박스에서 직접 만든 노션 템플릿을 제공해왔고, 그동안 제공한 템플릿 중 일부를 유료로 판매하면 캐쉬 카우로 워킹하리라 판단했다. 다만, 사이트 내 결제 시스템을 구축하는 게 막막했다. 사이트 자체도 노션과 우피를 활용해 만들었기에, 자체 결제 시스템을 구현하는 게 쉽지 않았다.

그렇다고 결제 대행사와 컨택하기에는 배보다 배꼽이 크고, 결제 시스템을 기본 기능으로 제공하는 웹사이트 툴로 새로 사이트를 개설하는 것도 의미가 없었다. 사이트의 SEO를 잘한 덕분에 많은 유저가 검색으로 들어왔는데, 이 사이트를 포기하는 건 말이 안 됐다.

기존 사이트를 유지하면서, 유료 템플릿을 판매할 수 있는 방법이 필요했다. 그런데 서칭을 열심히 해본 결과 콘텐츠를 자유롭게 판매 가능한 크티라는 서비스를 알게 됐다. 사이트에서 크티 마켓 플레이스를 연결시켜유료 템플릿을 판매한다면 문제를 해결할 수 있으리라 판단한 것이다.

바로 노션박스 사이트에서 유료 템플릿을 구매할 수 있는 크티 마켓 플레이스를 연결시켰다. 덕분에, “어떻게 템플릿을 유료로 판매하지?”라는 가장 큰 난관은 해결했다.

• 크티에서 볼 수 있는 ‘이명성 콘텐츠상점’

어떤 콘텐츠를, 어떤 가격으로 팔아야 할까?

다만, 아직까지 풀어야 할 문제가 2개나 남았다. 바로 (1) 판매할 템플릿 선정 기준과 (2) 적정 가격선이었다.

1. 어떤 템플릿을 유료로 팔아야 할까?
2. 유료 템플릿 가격 군은 어떻게 만들어야 할까?

1. 판매할 콘텐츠 정하기

첫 번째 풀어야 할 문제는 “판매해야 할 템플릿을 어떻게 선정할까?”였다. 애초에 노션 박스는 무료 템플릿을 지향했기에, 등록된 모든 템플릿을 유료로 판매할 수 없었다. 무지성으로 템플릿을 판매한다면 (1) 템플릿의 가치에 의문을 가질 수 있고, (2) 판매 상품의 폭이 무분별하게 넓어지리라 판단했다. 최소한의 템플릿만 판매해서 노션 박스의 가치를 지키고 싶었다.

다행히도 데이터의 중요성을 알고 있었기에, 사이트를 개설한 직후부터 모든 페이지와 이벤트 데이터를 구글 애널리틱스와 구글 태그 매니저로 수집해왔다. 구글 데이터 스튜디오를 활용해서 해당 데이터를 대쉬보드로 만들어 트래킹해 왔고, 각 템플릿별 조회와 다운로드 수를 확인했고, 가장 인기 있는 템플릿이 무엇인지 쉽게 알아낼 수 있었다.

2. 콘텐츠 가격 정하기

두 번째 풀어야 할 질문은 “템플릿의 적당한 가격은 얼마일까?”였다. 템플릿이 지나치게 비싸면 사람들은 템플릿을 구매하지 않을 거고, 반대로 템플릿이 지나치게 싸다면 캐쉬 카우의 역할을 하지 못한다. 어떻게 하면, 적정 가격선을 만들 수 있을지 고민에 빠졌다.

템플릿을 유료로 판매하는 아이디어는 UGC(User Generated Content) 시장을 다룬 아티클에서 시작됐었다. 몇 개월 전 UGC 아티클을 봤었는데, 많은 사람들이 다꾸(다이어리 꾸미기) 아이템을 직접 만들어서 판매하고 있다는 걸 흥미롭게 접했다. 문득, 노션 템플릿의 가격선도 다꾸 아이템의 가격선에 맞춘다면 적정 가격선을 만드리라 생각했다.

판단 근거는 노션 템플릿과 다꾸 아이템의 공통점에 기반했다. 둘 다 (1) 자신이 직접 만들 수 있지만, 이 시간을 아끼기 위해 다른 사람이 만든 콘텐츠를 구매하며, (2) 일상에서 자주 사용한다는 공통점을 지녔다. 즉, 노션 템플릿이나 다꾸 아이템은 (1) 모두 사용하는 상황이 비슷하고 (2) 비슷한 가치를 제공하기 때문에 가격선이 서로 유사하리라 판단했다.

다꾸 아이템이 활발하게 유통되는 채널은 네이버 스마트 스토어였다. 따라서 스토어에서 판매되는 다꾸 아이템의 가격을 집계한다면 적정 가격선을 알 수 있으리라 판단했다. PM으로서 가져야 할 핵심 능력은 데이터 분석이라고 생각해 작년부터 데이터 분석 코딩을 공부해왔고, 그 덕분에 바로 크롤링을 할 수 있었다. 코드에 대한 자세한 설명은 생략ㅎㅎ

네이버 스마트 스토어에서 다꾸 아이템의 모든 정보를 크롤링했고, 201페이지의 데이터를 크롤링해서 5765개의 다꾸 아이템 정보를 얻었다. 이 모든 정보를 크롤링 없이 직접 했다면 생각만 해도 끔찍하다…

이제 가격 데이터를 얻었으니, 가장 많이 분포된 가격선을 시각화해서 알아내면 됐다. 데이터를 히스토그램으로 시각화했고, 결과적으로 2,20~2,400원에 다꾸 아이템의 적정 가격선이 형성됐음을 데이터로 파악했다.

와 이게 진짜 팔리네

데이터를 기반으로, 노션 템플릿 가격을 2,400원에 판매하기로 결정했다. 양심적으로(?) 리소스가 별로 들지 않은 템플릿은 그보다 싼 가격으로 업로드했다.

가격이 타당해서 그럴까? 크티 마켓 플레이스를 오픈한 지 하루 만에 매출이 발생했다. 물론 해당 가격선이 타당한지를 보기 위해서 CVR(Conversion Rate)를 봐야 알겠지만, 크티는 해당 정보는 제공하지 않는다. 그래도 하루 만에 매출이 발생했으니 유효할지도? 반박 시, 여러분 말이 맞습니다.

인생에서 가장 비참한 때는 하고 싶은 일이 돈 때문에 못 하는 상황이 아닐까 싶다. 캐쉬 카우를 만든다면, 내가 하고 싶은 일을 부담 없이 더 할 수 있지 않을까? 많은 분들이 자신이 하고 싶은 일을 하기 위한 환경을 만든다면, 세상은 더 재밌게 돌아갈 것이다.

원문: Famelee의 브런치

이 필자의 다른 글 보기

• 노션으로 만드는 궁극의 휴가 관리 시스템
• 의사결정에 품격을 더하다, 데이터 시각화!
• 회고를 까먹지 않고, 매주 하고 싶다면?

엑셀이 답답해서 속이 터집니다!

컴공이 아닌 대학생이 가장 먼저 배우는 데이터 분석 툴은 엑셀이 아닐까 싶다. 엑셀의 그래프 기능을 통해 데이터를 다양한 방식으로 빠르게 시각화할 수 있고, 피벗 테이블 기능으로 수많은 데이터를 빠르게 군집화하고 분석할 수 있다. 무엇보다 편리한 UI 덕분에 별다른 전문 지식 없이 누구나 사용 가능하다.

하지만, 엑셀이 만능 데이터 분석 툴은 아니다. 데이터가 많아질수록, 렉이 급격히 심해지고 튕기는 현상이 많아진다. 다룰 수 있는 데이터 개수도 제한이 있는데, 한 시트마다 생성 가능한 행의 개수는 1,048,576개다. 이전에 다닌 스타트업은 AI로 영상을 분석해 데이터를 추출하는 서비스를 제공하는 곳으로, 서비스 특성상 실시간으로 엄청나게 많은 데이터가 생성된다. 모든 데이터를 엑셀로 뜯어보는 건 당연히 무리였다. 엑셀이 버벅거려 답답해하는 나에게 개발자가 찾아와 말했다.

명성님, 이참에 판다스 공부해보는 건 어떠세요?

많은 데이터를 엑셀로 처리하기 답답하다면, 판다스가 하나의 수단이 될 수 있다. 판다스는 파이썬의 데이터 처리 및 분석 라이브러리로, 많은 양의 데이터를 단기간 내 처리해준다. 데이터셋 내에서 특정 조건을 입력해 일부 데이터만 추출하거나, 특정 칼럼이나 데이터만 함수를 적용하는 등 많은 것을 할 수 있다. 엑셀에 익숙한 사람이라면 쉽게 배울 수 있는데, 약간 엑셀을 코딩으로 다루는 느낌이다.

의사결정의 품격, 데이터 시각화

데이터의 흐름을 보는 자!

데이터 시각화가 중요한 이유는 무엇일까? 모든 의사결정은 데이터에 기반해야 하는데, 그렇지 않으면 개인의 경험이나 주관적 판단에 의해 잘못된 해석을 할 수도 있다. 그렇다고 무작정 개별 데이터를 하나하나 보는 게 의사결정에 큰 도움이 되는 것도 아니다.

의사결정을 위한 데이터 인사이트를 얻으려면, 수많은 데이터 사이에 존재하는 흐름을 찾아야 한다. 이 흐름은 개별 데이터를 하나하나 보면 볼 수 없고, 모든 데이터를 전체적으로 봐야지만 찾을 수 있는데 이를 가능케 하는 게 ‘데이터 시각화’다.

판다스와 함께 자주 쓰이는 파이썬의 데이터 시각화 라이브러리로 시본(Seaborn)이 있다. 판다스와 시본, 2가지를 공부한다면 엄청난 수의 데이터를 판다스로 처리 및 분석하고, 시본으로 시각화해서 데이터의 흐름을 파악할 수 있다. 만약 판다스와 시본, 둘 다 공부하기 힘들다면 그냥 시본만 공부해도 큰 도움이 될 수 있다. 사실 판다스면 몰라도, 시본은 함수명도 직관적이고 코드도 어렵지 않아서 누구나 쉽게 배울 수 있다.

누구나 이 정도로 데이터 시각화를 할 수 있다고?

0. 변수 개념

시본의 시각화 함수를 알아보기 전에 ‘범주형 변수(categorical variable)’와 ‘연속형 변수(continuous variable)’ 개념을 먼저 뜯어보자! 정량 변수는 특성에 의해 크게 ‘범주형 변수’와 ‘연속형 변수’로 구분된다. 범주형 변수는 측정 대상들이 서로 떨어진 값을 갖고 있어서 명확하게 구분되는 변수인데, 성별(남성 / 여성), 연령대(10대 / 20대 / 30대 / 40대…) 등이 여기에 속한다. 반대로, 연속형 변수는 측정 대상들이 서로 연속된 값을 갖고 있다. 예를 들어, 키(150cm ~ 200cm), 온도(0’C~100’C), 나이 (0살 ~ 100살) 등이 있다. 이 두 변수의 특성을 구분할 줄 안다면, 시본을 더 익숙하게 사용할 수 있다.

범주형 변수와 연속형 변수를 이해했으니, 이제 시본에서 제공하는 시각화 함수를 느껴볼 차례다. 시본에서 제공하는 시각화 함수 중에서 가장 자주 쓰이는 몇 가지를 가져왔으니, 편한 마음으로 “아 시본을 공부하면 이 정도 수준으로 시각화가 가능하구나?” 정도만 느끼면서 구경하자.

1. 특정 변수의 빈도, 횟수를 확인 -> countplot, distplot
2. 범주형 변수와 연속형 변수의 관계 확인 -> boxplot, violinplot, stripplot.
3. 연속형 변수와 연속형 변수의 관계 확인 -> regplot, kdeplot

1. 특정 변수의 빈도, 횟수 확인하기

• countplot 함수

countplot 함수는 범주형 변수의 빈도, 횟수 등을 막대그래프로 보여주는 함수다. 아래 그림처럼, 각각의 범주형 변수가 데이터에서 몇 개가 있는지 막대로 보여준다. 아래 차트를 보면, 각 요일의 응답 수를 확인할 수 있다. 여기서 요일인 목, 금, 토, 일이 범주형 변수다.

• distplot 함수

연속형 변수의 빈도, 횟수 등을 확인하려면 distplot을 사용하면 된다. distplot은 연속된 각 변수의 개수를 히스토그램으로 보여준다. 별도 설정을 통해 커널 밀도(kde)를 그릴 수 있는데, ‘커널 밀도’는 앞선 히스토그램을 기반으로 만든 확률 함수다. 즉, 특정 데이터를 랜덤하게 뽑았을 때 해당 값이 있을 확률을 뜻하는데, 그냥 편하게 추세선으로 생각하자!

2. 범주형 변수와 연속형 변수의 관계 보기

• boxplot 함수

boxplot은 범주형 변수와 연속형 변수 사이의 관계를 보여준다. 이때, 연속형 변수에서 최솟값, 1분위 수, 중간값, 3분위 수, 최댓값, 이상치 등의 다양한 통계량을 함께 보여준다.

• violinplot 함수

위의 boxplot은 다양한 통계 수치를 확인하기 위해 자주 사용된다. 하지만, 특정 분위 수나 중간값을 보여줄 뿐, 데이터 분산을 정확하게 보여주지 않는다. 이때 violnplot 함수를 사용하는데, 통계량을 다루지 않는 대신에 커널 밀도를 통해 데이터 분산을 확인할 수 있다.

• stripplot 함수

violinplot, boxplot 함수는 개별 관측치를 종합해 특정 형태로 보여준다. 만약 개별 관측치 하나하나를 보고 싶다면, stripplot 함수를 사용하면 된다.

3. 연속형 변수와 연속형 변수의 관계 보기

• regplot 함수

서로 다른 연속형 변수 사이의 관계가 어떻게 됐는지를 알고 싶을 때, 산점도를 그리는 regplot 함수를 사용한다. 두 변 사이에 회귀선을 보여줘서 상관관계를 어느 정도 예측할 수 있고, 데이터가 많아서 겹치는 점이 많은 경우에 투명도를 설정해서 각 구간마다 데이터가 얼마나 몰려있는지 알아낼 수 있다.

• kdeplot 함수

두 연속형 변수 사이의 관계를 보여준다는 점에서 regplot과 비슷하지만, 보여주는 방식이 다르다. regplot은 각 관측치를 모두 점으로 보여준 것에 반해, kedplot은 이차원 밀집도로 보여준다.

데이터 시각화로 진짜 문제 찾기

1. 창업 팀 사례

얼마 전 창업 팀에서 PSF(Problem Solutin Fit)을 찾기 위한 실험을 진행했다. 당시 여러 문제 중에서 고객이 가장 크게 느끼는 문제가 무엇인지 알아내기 위해 설문 조사를 진행했고, 수집한 데이터를 분석해 팀의 방향을 설정했었다. 이 사례를 짧게 공유해보고자 한다.

문제 순위를 매겨보자!

고객의 문제를 찾는 방법 중에 CPSR이란 방법이 있다. 고객에게 하나의 문제가 아니라, 여러 문제를 보여주고 순위를 매기는 방식이다. 하나의 문제만 물어본다면, 고객은 그 문제 외의 것은 모두 잊어버리고 그 문제만 집중하는데, CPSR은 이런 상황을 방지한다. 이 점에 착안해 1개의 문제 가설을 검증하기보다 우선순위가 높다고 판단한 4개의 문제를 고객에게 모두 보여주고, 이 중에서 어떤 게 가장 큰 페인 포인트인지 알아내는 실험을 진행했다. 각 문제마다 고객에게 불편도를 묻는 여러 문항으로 설문지를 구성하고, 이를 관련 커뮤니티에 배포해 데이터를 수집했다.

판다스로 데이터 처리

이렇게 수집한 데이터를 csv로 추출하고, Pandas를 이용해 데이터를 시각화하기 전에 전처리했다. 각 문제의 불편도를 측정하기 위한 여러 문항에 가중치를 적용해 점수로 환산했고, 아래와 같이 process, menu, pay, coupon 칼럼을 생성해 입력했다. 즉, 각 칼럼은 이번에 순위를 매기고자 한 4가지 문제와 불편함 점수를 뜻한다.

아래 수치는 설문지 응답을 기반으로, 각 문제에 느낀 불편함을 정량적으로 환산한 것이다. age, gender 칼럼은 인구통계학 정보를 보여준다. seaborn로 데이터를 시각화하려면, str(남성, 여성, 20-23) 타입이 아니라 int 타입으로 바꿔주는 게 유리하다.

어떤 문제가 가장 큰 문제일까?

연속형 변수의 빈도, 분포도를 알고 싶다면, seaborn의 distplot을 활용하면 좋다. 아래 그래프는 distplot으로 구현된 커널 밀도 그래프이다. 봉오리가 x축의 오른쪽으로 갈수록, 문제가 불편하다고 말하는 사람이 많음을 뜻한다.

해당 그래프를 보면, Pay(초록)의 봉오리가 가장 왼쪽에 있고, Menu(주황)의 봉오리가 가장 오른쪽에 있음을 볼 수 있다. 즉, 데이터를 보면 Menu 문제에서 가장 큰 불편함을 느끼고 있다.

fig, ax = plt.subplots(1,1, figsize= (20,10))
sns.distplot(df_pt[‘process’], hist = False, label = “Process”)
sns.distplot(df_pt[‘menu’], hist = False, label = “Menu”)
sns.distplot(df_pt[‘pay’], hist = False, label = “pay”)
sns.distplot(df_pt[‘coupon’], hist = False, label = “coupon”)
plt.grid(True)
plt.legend()
plt.show()

각 성별, 연령대에서는 어떨까?

이 그래프를 좀 더 딥 다이빙해보자! 해당 그래프는 모든 성별, 연령대의 데이터로 그려본 커널 밀도니, 다음과 같은 질문을 던질 수 있다.

“고객이 가장 불편하다고 말한 ‘Menu 문제’가 알고 보니, 특정 성별, 연령대에만 한정적인 건 아닐까?”

이제 각 성별, 연령대 세그먼트로 불편함을 확인하기 위해 violinplot과 stripplot을 사용했다. 두 함수는 범주형 변수(성별, 연령대)와 연속형 변수(불편도 점수) 사이의 관계를 알아낼 때 사용하면 좋다. violinplot은 각 데이터가 어떤 구간에 주로 분포하는지 커널 밀도로 보여주고, stripplot은 개별 데이터가 어디에 위치하는지를 보여준다. 따라서, 이 둘을 하나의 그래프에 함께 그리면 더 보기 편하다.

결과 그래프를 확인해보면, 24~26세 여성이 메뉴의 불편함을 가장 크게 느끼고 있음을 알 수 있다. 이제 ‘Menu 문제’를 가장 크게 불편하다고 느끼는 건 24~26세 여성임을 알아냈다.

fig, ax = plt.subplots(1,1, figsize= (10, 5))
sns.violinplot(x = ‘age’, y = ‘menu’, data = df_pt, hue = ‘gender’, split = True, orient=’v’, legend =[‘여성’, ‘남성’])
sns.stripplot(x = ‘age’, y = ‘menu’, data = df_pt, hue = ‘gender’, size = 5)
ax.set_xticklabels([’20세 미만’, ’20 – 23′, ’24 – 26′, ’27 이상’]) plt.grid(True)
plt.legend([‘여성’, ‘남성’])
plt.show()

다른 변수 사이의 상관관계는 없을까?

여기서 좀 더 깊이 들어가 보자. 24~26세 여성이 답한 응답이 사실 다른 문제로부터 어떤 영향을 받은 건 아닐까? 서로 다른 연속형 변수 사이의 상관관계를 보고 싶다면 regplot을 활용하면 좋다. regplot은 두 변수 사이의 데이터 위치를 산점도로 보여주고, 회귀선을 그려서 변수 사이의 상관관계를 보여준다.

아래의 각 그래프는 Menu 문제와 각각 Process, Pay, Coupon 문제 사이의 상관성을 회귀선으로 보여준다. 회귀선을 보면, 메뉴와 다른 요소 사이의 상관성은 크게 없음을 알 수 있다.

df_target = df_pt.groupby([‘age’, ‘gender’]).get_group((2,0))
fig, axes = plt.subplots(1,3, figsize= (30,8))
sns.regplot(x = ‘menu’, y = ‘process’, data = df_target, ax= axes[0])
sns.regplot(x = ‘menu’, y = ‘pay’, data = df_target, ax= axes[1])
sns.regplot(x = ‘menu’, y = ‘coupon’, data = df_target, ax= axes[2])
for n in range(0,3):
axes[n].grid(True)
axes[n].set_ylim([1, 5])
plt.show()

세 그래프를 하나의 그래프에 그려보고 비교할 수도 있다.

df_target = df_pt.groupby([‘age’, ‘gender’]).get_group((2,0))
fig, axe = plt.subplots(1,1, figsize= (10,10))
sns.regplot(x = ‘menu’, y = ‘process’, data = df_target, label = ‘process’)
sns.regplot(x = ‘menu’, y = ‘pay’, data = df_target, label = ‘pay’)
sns.regplot(x = ‘menu’, y = ‘coupon’, data = df_target, label = ‘coupon’)
plt.legend()

2. 100% 정확하지 않아도 괜찮다!

사실 이 데이터가 더 신뢰성을 얻기 위해선 더 많은 데이터가 필요하다. 하지만, 스타트업에서 필요한 건 빠른 속도다. 따라서, 100% 정확한 정보를 얻을 때까지 기다리는 것보다, 어느 정도의 정확성을 가진 정보를 갖고 바로 다음 액션을 하는 게 더 효과적이다.

팀에서 ‘Menu 문제’를 24-26세 여성 고객의 핵심 문제로 설정하고, 넥스트 액션을 이에 맞춰서 진행했다. 만약, 데이터를 분석하지 않았다면, ‘process’나 ‘coupon’을 핵심 문제로 설정했을 수도 있다. 해당 그래프의 일부는 엑셀로도 충분히 구현할 수 있지만, 좀 더 데이터 기반의 의사결정 능력을 키우기 위해 데이터 분석 코딩 공부를 해보는 건 어떨까?

그래서 어떻게 공부하지?

판다스와 시본은 혼자서 독학으로 공부했다. 처음에 책을 통해 입문헀고, 이후 무료 강의 영상을 보면서 기본기를 다졌다. 사실 데이터 애널리티스트를 꿈꾸는 게 아니라면, 이 정도만 해도 충분하지 않을까? (물론 주관적인 뇌피셜이다)

개발자가 『 Do it! 데이터 분석을 위한 판다스 입문』을 빌려줘서 판다스와 시본 기본기를 뗐다. 판다스 입문이지만, 데이터 시각화를 위해 시본을 다루는 챕터가 있어서 좋았다. 이어서 김문과님이 seaborn 패키지 번역본을 올리셨다. 한땀한땀 번역하셨다고 했는데 존경스러울 정도다…! 시본만 공부해보고 싶다면, 이 번역본을 한 번 봐보자!

글을 읽는 게 싫다면, 유튜버 ‘나도코딩’님의 시각화 강의 영상을 참고해보자! 강의도 엄청 친절하고 기초부터 차근차근 다뤄주셔서, 글을 읽으면 잠이 오는 분들에게 좋을 듯하다.

원문: FameLee의 브런치

이 필자의 다른 글 보기

• 노 코드 툴, ‘버블’의 A to Z
• 린하고 스마트하게, 나 홀로 사이드 프로젝트
• 좋은 PM은 어떤 능력을 갖춰야 할까?

개발 효율을 높이기 위해 개발자가 환경을 세팅하는 것처럼, 기획 및 PO 업무를 할 때마다 관련 환경을 먼저 만든다. 처음 구축하는 데 시간이 들지만, 환경을 구축해 놓는다면 기획 및 매니징 작업을 하는 데 업무 효율을 급격히 증가시킨다. 무엇보다 주기적으로 처리해야 하는 태스크를 빠르게 해결할 수 있다.

주기적으로 처리하는 태스크 중에서 ‘개인 회고’가 있다. 스타트업에서는 성장을 위해서 회고를 강조하고, 이전에 다닌 AI 스타트업에서도 금요일마다 팀원 회고를 진행했었다. 비록 회사를 퇴사하고 학교로 돌아가는 복학생이 됐지만, 이후에도 계속 개인 회고를 주말마다 짧게 진행했었다. 벌써 개인 회고를 노션에 기록한 지 1년이 다 돼가는데, 매번 아래의 항목을 질문했었다.

1. 이번 주 부족한 점은?
2. 이번 주 성장한 점은?
3. 다음 주 목표는?
4. 이번 주는 1~5점 중에서 평가한다면?

요즘 들어 ‘회고’를 자주 까먹었다. 저번 주에 회고를 까먹은 걸 뒤늦게 알아서, 뒤늦게 밀린 구몬 숙제를 해치우듯이 몰아서 2주 치 회고를 진행한 적이 여러 번 있었다. 왜 회고를 계속 까먹을까? 곰곰이 생각해보니 회사에 다닐 때 PO가 항상 회고 시간을 공지해줘서 강제로(?) 했었는데, 이제 그런 사람이 없다 보니 계속 까먹은 것 같다. 개인 업무에 집중해서 회고를 까먹을 때, PO가 “금요일 회고 잊지 마세요!”라는 말로 리마인드 시켜줬다. 최근에 학교 생활 및 사이드 프로젝트에 집중하다 보니 회고를 까먹었을 뿐만 아니라, 리마인드 조차 할 수 없었다.

코딩 없이 회고 자동화 시스템 만들기

그렇다면, 정기적으로 알림을 주면 회고 타이밍을 놓치지 않을까?

몇 달 전에 노션 API 기능이 베타 버전으로 출시됐고, 자피어(Zapier)에서도 이를 지원하고 있다. 문득, 자피어를 통해 노션과 슬랙을 잘 연결하면, 이 문제를 해결할 수 있다는 생각이 들었다.

노션에는 알림 기능이 없지만, 회고 DB를 만들 수 있다. 반면에, 슬랙은 봇을 활용해 정기 알림을 보낼 수 있고, 응답도 받을 수 있다. 이 둘을 결합해, 아래와 같이 정기 개인 회고의 자동화 프로세스를 스케치했다.

1. 슬랙 봇이 토요일 아침에 회고 DM을 보낸다.
2. 시간이 날 때, DM을 확인하고 회고를 작성한다.
3. 자피어가 작성한 회고를 노션에 전달한다.
4. 노션에서 회고 DB에 이번 주 회고 내용을 로깅한다.

A. 슬랙 봇으로 질문받기

슬랙에는 플러그인 기능을 활용해 다양한 App의 기능을 내 워크 스페이스에 불러와서 사용할 수 있다. 이 중에서 정기적으로 특정 질문을 하고, 대답을 받는 App도 존재한다. 이 App은 스타트업에서 주로 정기 업무인 스탠드 업 미팅, 회고 등을 위해 사용한다.

토요일 아침마다 회고 질문을 던져주는 App으로 긱봇(Geekbot)을 선택했다. 긱봇을 선택한 이유는 매우 단순한데 이 기능을 구현하는 정도는 무료 플랜으로 충분하기 때문이다.

개인 워크스페이스에 긱봇을 연동시키면, 이제 특정 요일과 시간에 봇이 나에게 물어볼 질문을 설정할 수 있다. 또한, 질문의 응답을 출력할 채널도 설정할 수 있다. 전체적인 프로세스는 아래와 같다.

1. 긱봇이 ‘나’에게 DM으로 질문한다.
2. ‘나’가 DM으로 질문에 답변한다.
3. 이 답변 내용을 수집해서 특정 채널에 출력한다.

긱봇에서 매주 토요일 아침 8시에 부족한 점 / 성장한 점 / 다음 주 목표 / 이번 주 점수 평가, 총 4개의 항목을 물어보도록 설정했고, 질문의 답을 #weekly-feedback 채널에 보여주도록 설정했다.

설정한 요일 및 시간에 아래와 같이 DM이 온다. 봇이 한 개씩 질문을 물어보면, 여기에 답하면 된다. 해당 응답 기록은 질문과 함께 설정한 채널에 출력된다. 아래의 첫 번째 이미지는 긱봇이 나에게 보낸 DM이고, 다음 이미지는 응답 결과를 보여주는 채널이다. 참고로 시간과 프로필은  테스트 값으로 마구 설정한 값이다.

B. 자피어로 슬랙과 노션 이어 주기

이제 자피어로 슬랙의 채널에 남긴 응답을 노션으로 보내줘서, 계속 로깅할 수 있게 만들어야 한다. 잽(Zap, 자피어의 단일 워크 플로우)은 ①워크플로우의 시작 이벤트인 트리거와 ②트리거 후에 자동으로 작동될 이벤트인 액션으로 구성된다.

나는 ‘#weekly-feedback 채널에 메시지가 생성될 때’를 트리거로 설정했다. 이제 토요일에 Geekbot의 회고 DM에 응답하면, 연동 채널에 회고 내용이 출력되고 ,이 출력 이벤트를 트리거로 잽이 작동한다.

왼쪽 이미지는 설정한 채널에 남겨진 메시지고, 오른쪽 이미지는 자피어가 이 메시지로부터 수집한 데이터다. 타이틀 필드에는 긱봇에서 나에게 물어본 DM 질문이, 텍스트 필드에는 이 질문에 대한 내 응답이 적혀있음을 알 수 있다.

C. 실수를 방지하자!

위 트리거는 ‘#weekly-feedback 채널에 메시지가 생성될 때’이다. 즉, 내가 실수로 아무 말이나 남겨도 이 워크플로우가 작동된다. 이로 인한 오작동을 막기 위해, 후속 액션으로 필터를 설정했다. 만약 실수로 채널에 말을 입력해도, 특정 필드의 데이터가 존재하지 않는다면 알아서 멈추게 만들 수 있다.

D. 노션에 회고 DB 만들기

이제 회고 내용을 노션의 회고 DB에 로깅 시키면 끝이다. 노션의 기존 데이터베이스에 블록을 추가하는 액션을 잽에 추가시켰다. 자피어와 노션을 연동하기 위해선 노션의 토큰을 자피어에게 제공하고, 노션 워크스페이스 수정 권한을 넘겨야 한다. 이에 대한 자세한 과정은 해당 링크를 참고하자!

자피어와 연동한 노션 회고 DB의 필드 값은 아래와 같다. 자피어를 통해 슬랙의 회고 내용과 각 필드를 매칭하면 끝이다.

짜잔! 테스트를 진행하면, 코딩 없는 회고 자동화 시스템이 완성됐다.

1. 슬랙이 회고 질문 DM을 정기적으로 보낸다.
2. 이 질문에 답하면 자동으로 슬랙에 기록이 남는다.
3. 동시에 자피어가 슬랙과 노션을 연동한다.
4. 노션의 회고 DB에 추가로 로깅한다.

E. 회고 시스템에 디테일 추가하기

1. 함수 이용하기

이번 주 회고 점수를 숫자로만 보는 건 너무 삭막하다고? 그렇다면, 함수 필드를 사용해보자. 함수 필드는 마치 엑셀의 함수처럼, 다른 필드의 데이터를 변수 값으로 받아서 특정 결과를 출력하는 필드다. 자피어가 노션 DB의 특정 필드에 데이터를 채우는 순간, 자동으로 함수 필드가 작동된다.

아래에 보이듯이 [점수] 필드는 텍스트 필드고, [점수 보드] 필드는 함수 필드다. [점수]의 수치에 따라, 서로 다른 이모지를 보여주게 설정했다.

2. 차트로 시각화하기

최근 고위드에서 SaaS Cracker라는 서비스를 런칭했다. SaaS 툴을 추천해주는 플랫폼인데, 이곳에서 노션의 특정 DB의 데이터로 차트를 그려주는 Notion Charts 서비스를 알게 됐다. 노션 애호가로서, 이건 꼭 써봐야겠다고 생각하고 바로 사용해봤다.

해당 서비스는 무료, 유료 플랜을 모두 제공한다. 무료 플랜은 노션의 DB와 연동된 5개의 차트를 생성할 수 있다. 이걸 활용하면, 아래와 같은 차트를 노션에서 구현할 수 있다.

NotionCharts에서 노션 페이지를 연동하면, 해당 페이지 내부에 있는 데이터베이스를 알아서 연결해준다. 이렇게 연결한 DB의 데이터를 차트로 만들 때 사용할 수 있다. 참고로, Inline DB는 읽지 못하고 Full Page DB만 읽어오니 주의하자!

총 9가지의 차트를 제공하며, 아래 왼쪽 이미지의 오른쪽에 있는 “Data Settings”에서 DB에서 어떤 데이터를 어떻게 사용해서 차트를 만들지 선택할 수 있다. 각 항목의 내용은 아래와 같다.

• Notion Table : 차트를 그리기 위해, 불러올 노션 데이터베이스. 앞 단계를 통해 연동한 DB만 선택할 수 있다.
• X Axis : 선택한 노션 DB의 필드 값으로, X축이 된다.
• Y Axis : 선택한 노션 DB의 필드 값으로, Y축이 된다. 텍스트 필드가 아닌, 숫자 필드를 선택해야지 오류가 안 뜬다.
• Sort By : X축에 적용할 솔팅 기준.
• Group By : Y축 집계 방식을 결정한다. 예) Count, Sum, Average

그래프가 완성되면, “Copy Embed Url”을 눌러서 URL 링크를 복사하고, 노션에 임베디드 해보자! 그러면, 아래 오른쪽 이미지처럼 차트가 출력된다. 인터렉션도 가능하다.

참고로 [Y Axis]는 텍스트 필드가 아닌, 숫자 필드가 와야 한다. 텍스트 필드를 선택하면, 노션에 임베디드해도 차트가 그려지지 않을 수 있다. 만약 숫자가 텍스트 형식이라면, 아래처럼 함수를 이용해 숫자로 바꿔주자!

원문: FameLee의 브런치

참고 사이트

• https://saascracker.gowid.com/index
• https://notioncharts.io/

함께 보면 좋은 글

• 자신을 빠르게 성장시키는 ‘회고’
• 노션으로 “나다운” 이력서 만들기.pdf
• 노션으로 위키 페이지 만들기: 생각보다 대박이다

1. 회사 휴가 관리가 너무 막막한 HR 담당자
2. ERP 시스템에 관심 있는 주니어
3. 노션 변태(?)

최근에 회사에서 노션으로 휴가 관리 시스템을 만드는 일을 맡았는데, 꽤나 많은 고민을 했다. 고민이 많은 만큼 만들어 낸 시스템이 생각보다 고퀄리티인 것 같아서 공유를 하고자 한다. 나 같이 노션 변태거나 새로운 SaaS 툴을 도입하는 게 부담이 되는 작은 규모의 스타트업이라면, 어느 정도 만족할 만한 휴가 관리 시스템을 노션에서 구현할 수 있다.

• 이 링크에서 관련 템플릿을 다운로드할 수 있습니다.

휴가 관리 시스템, 그게 그렇게 어려워?

휴가, 그냥 신청하고 받아주면 되는 거 아니야?

이렇게 생각하는 분들이 많을 것 같다. 휴가 관리는 HR 담당자가 아니면, 이걸 처리하는 게 얼마나 머리 아프고 복잡한 일인지 공감하기 어렵다. 이 프로젝트를 하기 전까지 휴가 관리 시스템이 엄청 쉽고 간단할 줄 알았다. 휴가 관리가 복잡한 이유는 워낙 경우의 수가 많고, 회사 자체 제도와 별개로 근로기준법에 해당하는 부분을 고려해야 하기 때문이다.

반차, 연차, 본인 결혼, 자녀 결혼, 친족 관계 사망 등등…

그래도 아직 체감이 안 되는 분들을 위해 몇 가지 사례를 가져왔다. 많은 분들이 자신이 갖고 있는 휴가일 수를 사용하는 ‘반차’나 ‘연차’ 개념을 알고 있을 것이다. 하지만, 휴가 유형에 ‘반차’나 ‘연차’만 있다고 생각하면 오산이다. 근로기준법에 의해 회사에서 준수해야 하는 몇 가지 휴가 제도가 있다.

예를 들면, 본인이 결혼하는 경우에 자신이 보유한 휴가일 수를 소진하지 않고, 3일을 쉴 수 있다. 이걸 모르고 연차 3일을 박아버린다면? 오우 쉣! 본인이나 배우자의 부모님이 돌아가신 경우에도 휴가일 수를 소진하지 않고 5일을 쉴 수 있다. 앞선 경우에는 유급 휴가가 적용된다. 하지만 한 달마다 쓸 수 있는 생리 휴가는 어떨까? 생리 휴가는 휴가일 소진 없이 하루를 쉴 수 있는데, 여기서는 무급 휴가로 처리된다. 이처럼 휴가 유형은 너무 다양하고, 각 유형마다 적용되는 부분도 다른데, 이 모든 것을 항상 숙지할 수 있을까?

네? 입사 연도는 같은데 전 15일 연차가 안 나온다고요?

휴가 제도 말고도, 생성되는 연차를 계산하는 과정도 복잡하다. A군은 21년 3월 1일, B 군은 21년 10월 1일에 입사했다고 해보자. 그다음 연도의 1월 1일에 A 군은 15일의 휴가일 수를 받는다. 반면, B 군은 22년 10월 1일에 3일의 휴가일 수를 받는다. 왜 A 군과 B 군이 받는 휴가일 수는 다르고, 받는 일자도 다를까?

입사 연도에 1년(365일)의 80% 이상을 근무했다면, 그다음 년 1월 1일에 15일의 휴가일 수를 받는다. 하지만, 80 % 미만을 근무했다면, 입사 날로부터 1년이 지난 시점에 근무일 수에 비례(15일×10월 1일부터 12월 31일까지의 일 수/365일)해 휴가일 수를 부여받는다.

부여된 휴가일 수는 평생 가지 않습니다.

근속에 따라 부여되는 휴가일 수는 크게 ‘연차’와 ‘월차’로 구분된다. ‘월차’는 입사일로부터 1달이 지날 때마다 1개씩 생성이 되며, 총 11개가 생성이 된다. 사용하지 않은 월차는 입사일로부터 1년이 지난 시점에서 소멸된다. 반면 연차는 거의 1월 1일에 생성되고 12월 31일에 모두 소멸된다. 또한 연차 휴가 사용 촉진 제도에 의해 HR 담당자는 연차와 월차가 소멸되기 전에 사람들에게 공지를 해야 한다.

노션으로 만드는 궁극의 휴가 관리 시스템

노션으로 구현한 연차 시스템이 이 모든 경우의 수를 감당할 수 있을까? 정답은 NO다. FLEX 등 다양한 휴가 관리 SaaS 툴을 많은 분들이 찾는 이유도, 회사 자체적으로 이를 모두 커버하기 어렵기 때문이다. 모든 팀원이 입사한 일자가 다르므로 고려해야 하는 경우의 수가 너무 많아져서 관리가 복잡해진다.

하지만 규모가 작은 회사라면, 킹갓 ‘노션’으로 충분히 (1) 다양한 휴가 제도를 모두 반영할 수 있고 (2) 복잡한 휴가 계산을 자동 처리할 수 있다. 이번에 프로젝트로 노션 기반의 휴가 관리 시스템을 만들었는데, 이를 공유해보고자 한다.

0. 시스템 구성

노션 휴가 관리 시스템은 [연차 보드], [연차 기록 대장], [휴가 제도]라는 3가지 데이터베이스로 구성된다. [연차 보드] DB는 [연차 기록 대장] DB와 관계를 맺고 있고, [연차 기록 대장] DB는 [휴가 제도] DB와 관계를 맺는다.

• [연차 보드] DB : 각 팀원이 갖고 있는 휴가일 수를 보여주고, [연차 기록 대장] DB의 휴가 신청 정보를 활용해 잔여 연차를 계산함
• [연차 기록 대장] DB : 팀원이 신청한 휴가를 기록함. 이때, [휴가 제도] DB의 정보를 활용해 반차, 연차, 경조사, 생리 휴가 등의 휴가 유형을 선택
• [휴가 제도] DB : 선택 가능한 휴가 유형을 보여줌. 각 휴가 유형 별(반차, 연차, 경조사 등)로, 연차 소진 유무, 연차 소진일 등의 정보를 저장함

전반적인 플로우는 아래와 같다.

1. [연차 보드]에 팀원의 입사일을 적으면, 생성 연차와 월차를 자동 계산
2. [휴가 제도]에 회사에서 제공하는 휴가 유형을 저장
3. 팀원이 휴가를 신청하면, [연차 기록 대장]에 해당 신청을 기록
4. 이때, [휴가 제도]에서 신청한 휴가 유형이 무엇인지 선택
5. [연차 기록 대장]에서 기록한 내용은 [연차 보드]에 바로 반영되고, 잔여 연차를 계산함

1. 연차 기록하기

우선 연차를 기록할 공간인 [연차 기록 대장]을 만든다. 노션에서 Table DB를 만들고 아래와 같은 칼럼을 만든다

• [휴가자] 칼럼 : 휴가를 신청한 사람을 선택
• [휴가 기간(시작-끝)] : 휴가 기간을 입력
• [휴가일 수] : 입력한 휴가 기간을 활용해 총 휴가일 수를 계산

[휴가일 수] 칼럼은 휴가 기간을 입력하면, 자동으로 휴가일 수를 집계할 수 있도록 함수 칼럼을 활용한다. 함수 칼럼은 노션에서 제공하는 기능으로, 엑셀의 함수처럼 DB 내 데이터를 불러오고 여러 계산을 할 수 있다.

여기서 활용하는 함수는 dateBetween과 start, end 함수다. dateBetween(date 1, date 2, type) 함수는 서로 다른 두 날짜 사이의 시간을 특정한 유형(월, 일, 시 등)으로 바꿔서 Return한다. start(date range)와 end(date range) 함수는 날짜 범위에서 시작과 끝을 각각 return 한다. 아래와 같이 함수를 입력하면, [휴가 기간(시작-끝)]에 입력한 기간의 일 수를 계산할 수 있다. 마지막에 +1을 더한 이유는 휴가가 끝나는 날도 포함시키기 위해서다.

2. 휴가 제도 설정하기

이 정도 수준에 만족한다면 ‘궁극의 노션 휴가 관리 시스템’이라 말할 수 없다. 앞서 말했듯이, 휴가 유형 중에는 ‘연차를 소진하는 휴가’와 ‘그렇지 않은 휴가’가 있다. 예를 들어 본인이나 자녀의 결혼인 경우, 연차를 소진하지 않고 회사를 쉴 수 있는데 결혼, 출산, 친족 관계 사망 등은 근로기준법상으로 회사가 의무적으로 보장해야 하는 휴가다. 이 모든 것을 하나하나 다 외울 수 있을까? 절대 불가능이다.

따라서 굳이 외울 필요 없이 휴가를 신청할 때, 어떤 휴가 유형을 사용할지 선택할 수 있는 기능을 구현해야 한다. 이를 위해선, 각각의 휴가 유형에 대한 정보를 저장한 [휴가 제도] DB를 만들어야 한다. [휴가 제도] DB를 만들기 위해, 다시 새로운 Table DB를 만들고 아래와 같은 칼럼을 만든다.

• [연차 소비] 칼럼 : 해당 휴가 유형이 연차를 소비하는지 알려줌
• [연차 단위] 칼럼 : 단위 당 회사를 얼마나 쉬는지 보여줌
• [소진 단위] 칼럼 : 단위 당 보유한 연차를 얼마나 소진하는지 보여줌

반차는 한 번 쓸 때마다 0.5일을 쉬고, 0.5의 연차가 소진된다. 따라서 [연차 소비] 칼럼은 True가 되고, [연차 단위]와 [소진 단위] 칼럼은 모두 0.5다. 반면 본인 결혼은 한 번 쓸 때마다 5일을 쉬는데, 이때 근로기준법상으로 연차는 소진되지 않는다. 따라서, [연차 소비] 칼럼은 False가 되고, [연차 단위]는 5, [소진 단위]는 0이다.

이처럼 회사에서 제공하고 있는 휴가 유형을 해당 DB에 모두 만든다. 유급 휴가/무급 휴가를 알려주는 칼럼 등을 추가해 더 많은 정보를 전달할 수도 있다.

여기서 끝나면 뭔가 섭섭하다. 이런 식으로 우리 회사의 휴가 제도를 보여주면 사람들이 재밌어할까? ‘보기 좋은 떡이 먹기도 좋다!’라는 말이 있듯이, 디자인이 이뻐야지 계속 보는 맛이 난다. 이걸 살짝 더 이쁘게 만들고 싶다면, 2개의 함수 칼럼을 추가해주자.

함수 칼럼을 이용해 [연차 단위]와 [소진 단위] 칼럼을 더 이쁘고 직관적으로 보여줄 수 있다. 이번에 사용할 함수는 format()과 concat() 함수다. format(number)은 number 타입을 str 타입으로 바꿔주고, concat(str1, str2)는 str 타입끼리 이어준다. 두 함수를 아래처럼 이용해서 누구나 쉽게 이해 가능한 표현으로 바꿀 수 있다.

이제 이렇게 완성된 [휴가 제도] DB의 View를 Table 형식이 아니라, Gallery 형식으로 바꿔준다.

이렇게 설정한 갤러리 뷰에서 [속성] – [property] – [card preview]에서 ‘None’을 선택한다. 그러면, 아래와 같이 깔끔한 휴가 제도판을 만들 수 있다.

3. 휴가 신청 시 유형 선택하기

이렇게 완성한 [휴가 제도] DB를 앞서 작업한 [연차 기록 대장] DB와 Relation 기능을 통해 이어준다면, [연차 기록 대장]에서 팀원의 휴가 신청을 기록할 때마다 휴가 유형을 선택할 수 있다. 또한, role up 기능을 이용한다면, 선택한 유형과 관련된 데이터도 불러올 수 있다.

이때 [연차 기록 대장] DB를 구성하는 [휴가 일 수] 함수 칼럼에 약간의 수정이 필요하다. 왜냐하면 ‘반차’를 고려해야 하기 때문이다. 예를 들어 2021년 12월 2일에 연차를 쓴다고 해보자. 그러면 [휴가 기간(시작 – 끝)]은 2021.12.2 ~ 2021.12.2를 범위로 설정하면 된다. 하지만, 이때 연차가 아니라 반차를 쓴다면? 마찬가지로 [휴가 기간(시작 – 끝)]은 2021.12.2 ~ 2021.12.2를 범위로 한다.

하지만 전자와 후자에서 소비하는 연차 수는 각각 1과 0.5이다. 즉 동일한 칼럼 값을 갖고 있지만, 실제로 소비하는 연차 수는 다르다. 하지만 앞서 만든 [휴가일 수] 칼럼에서는 이를 반영하지 못한다.

앞서 [휴가 제도] DB와 [연차 기록 대장] DB를 연결함으로써, 쓰고자 하는 휴가 유형을 선택할 수 있다. 여기서 선택한 휴가 유형이 ‘반차’라면, [휴가일 수] 칼럼에서 다른 계산법을 적용하면 된다. 즉, ‘반차’를 쓴다면 0.5의 휴가일이라고 예외적으로 처리하면 되는데, 이는 if()와 contains() 함수를 사용하면 된다.

if(boolean, val 1, val 2) 함수는 boolean이 True인 경우에 val 1을, False인 경우에 val 2를 return 한다. contains(str 1, str 2)는 str 2가 str 1 안에 들어가는지에 대한 boolean을 return 한다. 아래의 이미지처럼 함수를 구성하면, (1) 반차인 경우에 휴가 일 수를 0.5로, (2) 그 외의 경우에는 이전과 마찬가지로 서로 다른 두 날 사이의 일 수를 계산하게 만들 수 있다.

이제 앞서 계산한 휴가일 수를 기반으로, 실제로 연차가 얼마나 소진됐는지를 보여주는 [연차 소진일 수] 칼럼을 만들 차례다. 예를 들어 12월 1일부터 12월 3일까지 나간다고 해보자. 이때 사유가 자녀의 결혼 때문이라면, 근로기준법에 의해서 연차를 소진하지 않고 그냥 나갔다 오면 된다. 하지만, 별다른 이유 없이 그냥 쉬고 싶은 것이라면, 총 3개의 연차를 소비해야 한다. 우리는 팀원이 선택한 휴가 유형이 연차를 소비하는지 그렇지 않은지에 대한 정보를 [휴가 제도] DB에서 이미 갖고 있다.

[연차 기록 대장] DB에서 선택한 휴가 유형이 연차를 소비하는지 보여주기 위해 Role up 칼럼을 이용한다. Role up 칼럼은 관계를 맺은 DB의 아이템이 갖고 있는 특정 칼럼의 데이터를 불러올 수 있다. 예를 들어, 본인 결혼은 연차를 소비하지 않는 의무 휴가이므로, [휴가 제도]에서 [연차 소비] 칼럼이 ‘X’ 값으로 설정했다. 이 데이터를 불러오는 [연차 소비 여부] 칼럼은 아래처럼 ‘X’ 값을 보여주고 있다.

이제 실제로 얼마큼의 연차가 소비되는지를 보여주는 [연차 소진일 수] 함수 칼럼을 만들면 된다. 아래의 이미지처럼, 선택한 휴가 유형이 연차를 소비하지 않는 경우에 if() 함수를 통해 0으로 인식하면 된다.

적용 예시로 101% 이해하기

위 과정을 통해서 팀원이 (1) 얼마나 휴가를 나갔다 오고, (2) 이때 어떤 휴가 유형으로 나갈 수 있는지 선택 가능하며 (3) 선택한 유형에 따라 얼마나 내가 보유한 휴가일 수가 소진되는지 알 수 있다. 더 쉬운 이해를 위해 예를 들어보자.

위의 [연차 기록 대장] DB를 보면 이명성이 총 2번의 휴가를 나갔음을 알 수 있다. 우선 10월 28일부터 11월 1일까지 결혼을 사유로 휴가를 나갔다. 본인 결혼인 경우, 근로기준법상으로 개인이 갖고 있는 휴가일 수를 소비하지 않는다. 이는 [연차 소비 여부] role up 칼럼에서 확인할 수 있다. 따라서, [휴가일 수] 칼럼을 보면 총 5일 휴가를 나갔지만, [연차 소진일 수] 칼럼은 0일을 보여준다.

그다음으로 11월 1일부터 11월 3일까지 여름휴가를 감을 알 수 있다. [휴가 종류] relation 칼럼을 보면, 휴가 유형이 ‘연차’가 아니라 ‘여름 특별 휴가 제도’를 활용했음을 알 수 있다. 해당 제도는 리프레쉬 휴가 차원으로, 개인이 보유한 휴가일 수를 소비하지 않으므로 [연차 소진일 수] 칼럼이 동일하게 0이 된다.

이번 년도 내 휴가 갯수는?

이번에는 입사일만 입력하면 얼만큼의 휴가가 생성되는지 알려주고, 연차 기록 대장과 연동해 연차를 쉽게 보여주는 대시보드를 만들어 보자!

1. 3월 입사자와 4월 입사자는 연차 갯수가 다릅니다.

대시보드를 만들기 전에, 다시 한 번 휴가 생성과 소멸에 대해 알아보자. 휴가 생성은 연차와 월차로 나뉜다. 월차는 입사일로부터 한 달이 지날 때마다, 1개씩 월차가 부여된다. 이 월차는 최대 11개까지 부여되며, 입사일로부터 1년이 지나는 시점에서 모두 소멸된다.

이후부터는 월차는 생성되지 않고, 대신 연차가 생긴다. 연차는 근속연수가 1년이 됐을 때부터 생기는 휴가일로 12월 31일이 지나면 모두 소멸된다. 여기까지는 휴가일 계산이 꽤 쉬워보인다.

하지만, 이 계산이 여기서 끝난다면 휴가 관리가 골치 아프다고 말할 수 없다. 휴가 관리가 복잡한 이유 중 하나는 입사일에 따라서, 휴가 계산 방법에 차이가 생긴다. A군은 21년 3월 1일, B 군은 21년 10월 1일에 입사했다고 해보자. 그다음 연도의 1월 1일에 A 군은 15일의 휴가일 수를 받는다. 반면, B 군은 3일의 휴가일 수를 받는다. 이 차이는 근로기준법을 보면 알 수 있다.

근로기준법상으로 입사 연도에 1년(365일)의 80% 이상을 근무했다면, 그다음 년에 15일의 휴가일 수를 받는다. 하지만, 80 % 미만을 근무했다면, 근무일 수에 비례(15일×10월 1일부터 12월 31일까지의 일 수/365일)해 휴가일 수를 부여받는다.

2. 오래 다닐수록, 연차도 많아져요!

또한 근속연수에 따라서도 휴가일 수가 달라진다. 근속연수가 3년이 되면, 휴가일 수가 15일에서 16일로 바뀐다. 이 후, 매 2년마다 휴가일 수가 +1이 된다. 다시 A군과 B군의 이야기로 가보자. 21년 3월 1일에 입사한 A군은 24년 1월 1일에 16일의 연차를 받는다. 왜냐하면, 22년, 23년, 24년까지 총 3번이 거쳤기 때문이다. 그렇다면 같은 년도의 10월 1일에 입사한 B군도 24년 1월 1일에 16일의 연차를 받을까?

답은 NO다. B군은 25년 1월 1일에 16일의 연차를 받는데, 이는 B군이 15일의 연차를 받는게 23년 1월 1일이기 때문이다. 15일 연차를 받는 년 수를 기준으로 하므로, B군은 25년 1월 1일이 되서야 16일의 연차를 받는다.

결론적으로 입사일이 언제인지에 따라서 서로 다른 연차 계산법이 적용된다. 이를 바꿔 말하면, 입사일을 입력 받고, 각 상황에 맞는 계산법을 적용하면 휴가일 수 계산을 자동화 시킬 수 있다.

월차 계산? 입사일만 입력하세요!

A. 칼럼 구성

휴가 생성에 대해 알아봤으니, 이제 입사일만 입력해도 바로 얼만큼의 휴가가 생성되는지를 계산하는 대시보드를 만들어보자! 우선, 새로운 Table DB를 만든다. 그리고, 입사일을 입력할 [입사일] 칼럼을 만든다. 여기에 입력한 날짜를 함수에 사용함으로써, 휴가일 수를 자동 계산할 것이다.

먼저 월차를 다뤄보자. 입사일로부터 1달이 지날 때마다 월차가 생긴다. 그리고 이 월차는 입사일로부터 1년이 지날 때 모두 소멸되고, 앞으로 월차가 생기지 않는다. 이를 반영하기 위해, 현재 시점에서 (1) 월차가 생성 가능한 상태인지를 보여주는 칼럼과, 그렇다면 (2) 지금까지 생성된 월차는 몇 개인지 보여주는 칼럼을 만들어야 한다. 이 칼럼은 함수 칼럼을 이용한다.

• [입사일] 칼럼 : 입사일을 입력하는 곳으로, 이 입력 값에 따라 다른 칼럼 값이 자동으로 도출된다.
• [월차 생성 여부] 칼럼 : 입력한 입사일과 현재 시점을 비교해, 월차가 생성되는지 보여준다.
• [월차 발생] 칼럼 : 입력한 입사일과 현재 시점을 비교해, 몇 개의 월차가 생성되는지 보여준다.

B. 오늘 날짜를 어떻게 구할까?

[월차 생성 여부] 칼럼은 입사일로부터 1년이 지났는지 그렇지 않은지를 판단하는 함수를 구현하면 된다. 이를 위해 dateBetween(), dateAdd()와 fromTimestamp() 총 3가지 함수를 이용한다. 이 3가지 함수는 이후에도 계속 다룰 예정이니 여기서 완전히 숙지하고 가자!

• dateBetween(date 1, date 2, type)는 서로 다른 두 날짜 사이의 시간을 특정한 유형(월, 일, 시 등)으로 바꿔서 Return한다.
• dateAdd(date, number, type)는날짜로부터 숫자 만큼의 년, 월, 일 등을 더한 날짜를 return 하는 함수다. 예를 들어, dateAdd(now(), 10, “days”)라면, 오늘로부터 10일 이후의 날짜를 return 한다.
• 마지막으로, fromTimestamp(number)은 입력한 숫자를 Unix millisecond로 인식하고 날짜로 바꿔주는 함수다. 이 때, fromTimestamp(0)은 1970년 1월 1일이다.

이 3가지 함수 외에도 now()와 year(), month(), date() 함수가 함께 사용된다. now()는 현재 시점을 return하는 함수인데, 여기서 현재 시점은 날짜와 시간을 모두 포함한다. 예를 들어, 2021년 10월 21일 오후 10시 36분 42초를 리턴한다.

여기서 우리에게 필요한 건 ‘오후 10시 36분 42초’인 시간 데이터가 아니다. 오직, ‘2021년 10월 21일’인 날짜 데이터 뿐이다. 날짜 데이터만 추출하기 위해 year(), month(), date() 함수를 활용한다. year(date), month(date)와 date(date)는 각각 입력한 날짜에서 연, 월, 일을 추출한다. 따라서, 오늘의 날짜 데이터는 year(now()), month(now()), date(now()) 로 추출할 수 있다.

위 함수를 종합해서 아래와 같이 사용하면 오늘 날짜를 리턴할 수 있다. 한 가지 의문이 생길 수 있다. 왜 오늘 시점을 구하는데 now()가 아니라, 이렇게 복잡한 함수를 쓸까? 위에서도 말햇듯이, now()의 리턴값에는 시간도 포함하고 있다. 그러나 계산에서 필요한 건 시간이 아니라 날짜만이므로, dateAdd()와 fromTimestamp()를 이용한다.

dateAdd(dateAdd(dateAdd(fromTimestamp(0), year(now()) – 1970, “years”), month(now()), “months”), date(now()), “days”)

3. 이 사람은 월차가 만들어질까?

다시 [월차 생성 여부] 함수 칼럼으로 돌아가자. 월차는 입사일로부터 1년이 지나기 전까지만 생성되는 휴가가이며, 입사일로부터 1년이 되는 시점에서 모두 소멸된다. 따라서 월차의 생성 및 소멸을 고려하기 위해선 현재 날짜가 입사일로부터 1년이 지난 날과 계속 비교를 해야 한다.

입사일로부터 1년이 지난 날짜는 dateAdd()와 fromTimestamp() 함수를 통해 구할 수 있다. 앞서 말했듯이, fromTimestamp(0)은 1970년 1월 1일을 리턴한다. year(입사일), month(입사일), date(입사일)는 입사일의 년, 월, 일을 리턴한다. 아래와 같은 함수를 입력하면, 입사일로부터 정확히 1년이 지나기 전날을 구할 수 있다.

dateAdd(dateAdd(dateAdd(fromTimestamp(0), year(prop(“입사일”)) – 1969, “years”), month(prop(“입사일”)), “months”), date(prop(“입사일”)) – 1, “days”)

오늘 날짜와 입사일로부터 1년이 지난 날짜를 DateBetween() 을 이용해 비교함으로써, 월차가 아직까지 생성되는지 계산할 수 있다. 아래 왼쪽은 1년이 지나지 않았기에, [월차 생성 여부] 칼럼이 체크됐지만, 오른쪽은 1년이 훨씬 지났으므로 체크되지 않음을 볼 수 있다.

D. 그렇다면, 몇 개의 월차가 생성될까?

이제 현재 날짜에 월차가 몇 개가 생성됐는지를 보여주는 [월차 발생] 칼럼을 만들어보자. 해당 칼럼은 앞서 구한 [월차 생성 여부] 칼럼에 True일 때만 계산이 되고, False가 되면 0이 나오도록 해야 한다. 왜냐하면, 현행법상으로 월차는 입사일로부터 1년이 됐을 때, 모두 사라지기 때문이다. if()로 월차가 생성되는지 판단하고, 생성되는 경우에 월차는 dateBetween()과 now()를 사용해 계산할 수 있다.

연차 계산도, 입사일만 있으면 끝!

A. 칼럼 구성

월차 파트는 끝났으니, 이제 연차 파트로 넘어가보자. 연차 계산을 위해서 아래와 같은 칼럼이 필요하다. 전반적인 계산 방식은 앞선 월차와 비슷하지만, 특이하게 ‘입사년도에 1년 중의 80%를 근무했는가?’를 고려해야 한다.

• [근속 연수] : 15일의 연차가 나오는 년수를 보여준다.
• [입사년도 80% 근무] 칼럼 : 입사년도에 1년 중 80%를 근무했는지를 보여준다.
• [연차 생성 여부] 칼럼 : 연차가 생성되는지 보여주는 칼럼으로, 입사년도로부터 그 다음 년 1월 1일부터 체크된다.
• [연차 발생] 칼럼 : 입력한 입사일과 현재 시점을 비교해 발생하는 연차를 보여준다.

B. 이 사람은 연차가 생성될까?

연차는 입사년도의 그 다음 년에 발생한다. 즉, 현재 시점이 입사년도의 그 다음 년 1월 1일을 지났을 때, 연차가 생성된다고 볼 수 있다. 이를 보여주는 [연차 생성 여부] 칼럼을 아래와 같이 만든다.

C. 입사년도에 80% 이상 근무했나?

여기서 추가적으로 고려해야 할 부분은 입사년도에서 365일 중에 80% 이상을 근무했는지 확인하는 것이다. 법에 따르면, 입사년도에 1년의 80% (=365 * 0.8) 이상을 근무하는 경우, 그 다음 년 1월 1일에 15일의 연차를 제공해야 한다. 80% 미만 근무인 경우, (입사년도의 근무일 수 / 365일 * 15일)의 연차를 제공해야 한다.

입사년도에 80% 이상 근무했는지 파악하려면, 입사일과 입사년도의 12월 31일 사이의 일 수를 계산하고, 이 결과값이 365일 * 0.8보다 큰지를 알아내야 한다. 이는 아래와 같은 함수로 구현 가능하며, 일 수가 365 * 0.8보다 큰 경우에 True를, 그렇지 않으면 False를 리턴한다.

D. 이 사람은 몇 개의 연차가 생성될까?

입사년도의 80% 근무 유무를 파악할 수 있으니, 이제 생성되는 연차를 계산하면 된다. 이 때, 근속 연수가 3년이 됐을 때 연차가 16일이 되며, 그 이후로 2년마다 연차가 +1이 된다는 점을 추가로 고려해야 한다.

여기서의 근속 연수는 ’15일의 연차가 발생한 년도의 수’를 따져야 한다. 예를 들어, 21년 10월 입사자라면, 입사년도에 80% 이상 근무를 하지 못했다. 따라서, 그 다음 년에 ‘입사년도의 근무일 수/365일 * 15’일의 연차가 들어오는데, 이는 15일의 연차에 해당하지 않는다. 이 입사자는 15일의 연차를 23년 1월 1일에 받게 된다. 따라서, 16일의 연차가 발생하는 시점은 24년 1월 1일(입사년도 + 2)이 아니라, 25년 1월 1일(15일 연차가 발생하 년도+ 2)이다.

이 부분을 반영하기 위해 [근속 연수] 칼럼을 만들고, 아래와 같이 구현하면 된다. [입사년도 80% 근무] 칼럼을 통해 입사자가 입사년도에 80% 이상 근무했는지를 알 수 있다. 따라서, 만약 80% 이상 근무시에는 그 다음 년 1월 1일부터 근속 연수(편의상 앞으로 15일의 연차가 받은 년 수를 지칭)를 1이라고 계산하고, 80% 미만 근무 시에는 0으로 계산한다.

이렇게 계산한 근속 연수를 활용해 연차 발생 수를 계산할 수 있다. 근속연수가 1 ~ 2 일 때는 15일의 연차가 발생하고, 3 부터 16일의 연차가 발생한다. 이 후, 2년이 지날 때마다 연차가 + 1이 된다. 또한, 근속 연수가 0이지만 연차가 생성되는 경우(=입사년도에서 80% 미만 근무)에 (입사년도의 근무일 수 / 365일 * 15일)의 연차가 생성된다.

잔여 휴가까지 완벽한 휴가 대시보드!

앞선 과정을 통해 입사일에 따른 연차와 월차 생성 갯수를 자동 계산할 수 있게 됐다. 이제 휴가를 얼마나 소비했는지를 보여주는 [소비 연차]칼럼과, 잔여 연차를 보여주는 [남은 연차] 칼럼을 만들면 대시보드가 완성된다.

1. 소비 연차를 하나하나 신경쓰기 귀찮다면?

그렇다고 여기서 끝나긴 뭔가 아쉽다. 소비 연차를 하나하나 카운팅하는 게 매우 번거롭지 않을까? 앞선 게시글에서 구현한 [연차 기록 대장]을 가져올 차례다. 관계형 칼럼을 하나 추가하고, [연차 기록 대장] DB와 연결한다. 이 후, 해당 유저가 [연차 기록 대장]에서 작성한 내용을 모두 불러온다. 이제 팀원이 어떤 휴가를 등록했는지를 [연차 보드]에서 확인할 수 있다.

이제 기존 [소비 연차] 칼럼을 롤업 칼럼으로 바꾼다. 아래와 같이, 관계를 맺은 [연차 기록 대장] DB 내 [휴가일 수] 칼럼의 데이터를 불러오고, 여기서 SUM 계산을 적용하자! 이제 [연차 기록 대장]에 휴가를 쓰기만 해도, 각자가 얼마나 연차가 남았는지 확인할 수 있다.

2. 이걸 어떻게 다 구현해요?

위와 같은 템플릿을 사이드 프로젝트로 운영하는 노션 무료 템플릿 홈페이지에 업로드했습니다. 필요하신 분은 다운 받아서 쓰시길 바랍니다!

• 휴가 관리 대시보드 탬플릿 바로가기

원문: Feme Lee의 브런치

이 필자의 다른 글 보기

• 회고를 까먹지 않고, 매주 하고 싶다면?
• 노 코드 툴, ‘버블’의 A to Z
• 린하고 스마트하게, 나 홀로 사이드 프로젝트

회사 문화 자체가 주체적이라서, 입사하자마자 바로 ERP 프로덕트를 기획할 수 있었다. ERP 시스템을 공유하고, 저번 주에 프로덕트 팀의 PO와 미팅을 잠시 가졌다. 궁극적 커리어를 PO, PM을 생각하고 있어서, 해당 직무로 오랫동안 경력을 쌓아온 PO에게 많은 부분을 물어봤다. PO는 내가 정말 좋은 PM이 되고 싶다면, 몇 가지 능력을 갖추길 노력하라고 조언해줬다. 좋은 PM은 어떤 능력을 갖춰야 할까?

무지성 인터뷰 멈춰! 태스크 관찰(Task Observation)

1. 어딘가 묘하게 부족한 리서치

내가 프로덕트를 기획하는 과정은 크게 아래와 같다. 리서치를 통해 데이터를 수집하고, 이 데이터를 해석해 문제를 파악한다. 이후, 문제와 일치하는 목표를 설정하고 기능을 기획 및 개발 작업에 들어간다.

1. 리서치 : 다양한 데이터를 수집
2. 문제 파악 : 수집한 데이터를 해석해서 진짜 문제 찾아내기
3. 목표 설정 : 프로덕트의 전반적 방향을 결정하는 목표를 설정
4. 프로덕트 기획 : 목표 달성을 가능케 하는 기능을 구상
5. 제작 : 개발자에게 프로덕트의 맥락과 방향 등을 공유하고, 제작을 진행

ERP 프로덕트를 기획할 때도 위와 같은 과정을 거쳤는데, PO는 여기서 ‘리서치’ 단계에 아쉬움이 남았다고 말했다. ERP 프로덕트는 팀원이 쓰는 내부 프로덕트이므로 팀원의 니즈와 페인포인트를 알아내야 했다. 이를 위해 (1) 조사할 내용을 사전에 정리하고 (2) 인터뷰를 통해 하나하나 파악해 나갔다. 이렇게 보면 정말 평범하고 대표적인 리서치 방법인 거 같은데, 뭐가 부족했을까?

PO는 문제를 파악하기 위한 방법으로 인터뷰도 좋지만 가장 먼저 태스크 관찰 방식을 하라고 추천했다. 즉 리서치 단계에서 가장 먼저 할 일은 고객에게 물어보는 게 아니라, 고객이 먼저 무엇을 하는지 조용히 지켜봐야 한다는 말이다. 프로덕트를 사용하는 고객이 어떤 것을 하기 위해 무슨 일(Task)을 하는지 지켜보고, 거기서 인사이트를 뽑아내서 인터뷰를 진행하는 게 훨씬 효과적이라고 한다.

2. 인터뷰 Stay…!

왜 PO는 인터뷰를 가장 먼저 하지 말라고 했을까? 고객을 이해하기 위해 대게 ‘인터뷰’라는 방법을 사용한다. 인터뷰는 계속 고객에게 “왜?”를 질문함으로써 겉으로 보이지 않는, 숨겨진 니즈와 페인포인트를 끄집어낼 수 있다.

하지만, 인터뷰가 항상 100% 성공적인 리서치 방법이 되는 건 아니다. 이는 ‘인터뷰’가 ‘나’에게 크게 의존하기 때문이다. 이게 무슨 말일까?

‘아는 만큼 보인다!’라는 말이 인터뷰에 그대로 적용된다. 고객을 잘 알수록 인터뷰에서 유효한 인사이트를 얻을 확률이 높아지지만, 반대로 고객을 잘 모른다면 인터뷰에서 얻을 수 있는 건 별로 없어진다.

애초에, 고객에 대해 잘 모르기 때문에 무엇을 질문할지도 모르기 때문이다. 고객을 애매하게 안 상태에서 인터뷰를 진행한다면 어떠한 인사이트도 얻지 못할 수 있고 혹은 아예 잘못된 인사이트를 얻을 수도 있다.

고객에게 빙의해봅시다.

1. 고객이 하는 일 관찰하기

프로덕트의 기능은 ‘고객이 겪는 니즈와 페인포인트’와 잘 맞춰져야 한다. 즉 고객을 더 잘 이해할수록 더 좋은 프로덕트가 탄생할 수 있으며, 이를 위해서는 고객에게 빙의돼야 한다. 그리고 고객에게 빙의되기 위해선 이들이 평소에 어떤 생각과 감정을 갖고 있는지 알아내야 한다.

그렇다면 질문을 바꿔서 어떻게 해야지 이들이 어떤 생각과 감정을 갖는지 알 수 있을까? 고객이 평소에 어떤 일을 하는지 유심히 지켜봄으로써 알 수 있다.

즉, 방금 말한 태스크 관찰이 필요하다. 고객이 특정 목표를 위해 어떤 일을 하는지 지켜보고 이걸 ‘나’가 직접 한다고 가정해보고 고객을 이해해야 한다. 빙의를 통해 고객의 생각과 감정을 알아내고 “고객은 이런 걸 불편해하지 않을까?”라고 생각할 수 있다.

또한 이런 부분은 다시 인터뷰를 통해 검증할 수도 있다. 결국 “인터뷰에서 무엇을 물어볼까?”를 알아내기 위해 ‘태스크 관찰’이 선행돼야 한다.

2. 저에게 설명해주세요!

물론 상황에 따라서, 타겟 고객이 어떻게 일하는지 지켜보기 어려울 수도 있다. 내부 프로덕트를 만들기 위해선, 이 프로덕트를 사용하는 팀원의 모습을 봐야 하는데 재택근무를 하고 있다면? 구성원의 집에 찾아가 지켜볼 수도 없는 노릇이다.

이런 경우엔 “저에게 업무를 한 번 설명해주세요”라고 요청하면 된다. 고객이 업무를 설명하는 걸 듣고, 여기서 불편해 보이는 부분을 되물음으로써 알아낼 수 있다.

3. 오늘은 내가 고객!

직접 구성원의 업무를 해보는 것도 방법이 될 수 있다. 예를 들어 휴가를 관리하는 인사 담당자를 위한 프로덕트를 만들고 싶다면, 인사 담당자가 된 것처럼 실제로 휴가를 관리하는 시나리오를 대입해보면 좋다.

조금씩 붙여나가기, 빌드 업(Build Up)

PM에게 필요한 또 다른 능력은 프로덕트를 조금씩 개선하게 만들 수 있는 빌드 업 능력이다. 어떠한 프로덕트도 처음부터 크게 만들 수도, 100% 완벽하게 만들 수도 없다. 프로덕트는 조금씩 개선되며, 이렇게 완성된 작은 기능 하나하나가 모여서 큰 프로덕트가 탄생한다.

이때도 무턱대고 기능을 붙이는 게 아니다. 건물을 공사할 때, 밑에서부터 마구잡이로 쌓지 않고, 완성된 모습을 계속 그려가며 건설한다. 이처럼 지금 프로덕트의 기능과 앞으로 구현할 기능 사이의 조화를 생각하고, 미래에 완성된 프로덕트가 어떤 모습일지 생각해가며 빌드 업을 해야 한다.

또한 단순히 필요한 기능만 스케치하는 게 아니라 새로운 기능을 고안하면서 다양한 이해관계자에게 어떠한 영향을 줄지도 고려해야 한다.

예를 들어 새로운 기능을 구현함에 따라 백엔드에서 데이터셋이 어떻게 영향을 주는지 고려해야 하고, 프론트에서 어떻게 새로운 기능을 잘 합칠 수 있는지 고민해야 한다.

원문: Famelee의 브런치

함께 보면 좋은 글

• 좋은 PM이 반드시 알아야 할 우선순위 정하기 기법 4가지
• 좋은 PM은 “현재 진행 학습형”이다
• 화성에서 온 디자이너와 금성에서 온 PM

1. 사이드 프로젝트를 진행하고 싶다.
2. 아이디어를 상상만 하는 게 아니라, 직접 구현하고 싶다.
3. 진취적인 기획자가 되고 싶다.

구현하지 못하면 죽도 밥도 못 된다.

데이터 분석 용도로 어느 정도 파이선을 다룰 줄 알지만, 웹이나 앱 개발을 위한 코딩은 전혀 해본 적이 없다. 개발자와 협업 및 커뮤니케이션을 위한 지식은 갖췄지만, ‘커뮤니케이션을 위한 코딩 지식’과 ‘개발을 위한 코딩 지식’은 전혀 다름을 누구나 알 것이다. 주변 지인이 개발 코딩을 배워보라고 권유하지만 아직까지 배울 생각은 딱히 없다. 개발자만큼 코딩을 잘할 수 없음을 알고, 그 시간에 내가 할 수 있는 일에 더 집중하는 게 효율적이라고 생각하기 때문이다.

아이디어를 ‘생각’하는 것과 ‘구현’하는 것은 완전히 별개의 영역이다. 기획자가 제아무리 고객과 시장을 치밀하게 분석해서 훌륭한 앱을 기획했다고 해보자. 근데, 앱을 개발할 사람이 마지막에 없다면? 이 프로덕트는 상상 속 동물일 뿐이다. 더군다나, 기획자의 상상 속에서만 존재한다. 이 상상 속 동물을 현실로 끄집어내기 위해선 디자인과 개발이 필요하다. 디자인과 개발은 무형의 아이디어를 유형의 프로덕트로 바꿔주는 수단이다.

앞서 말했듯이 기획자는 기획하는 사람이지 디자인이나 개발을 하는 사람이 아니다. 제아무리 기획자가 개발 공부를 열심히 해도, 결과적으로 개발자의 손을 빌릴 수밖에 없다. 그렇다면, 기획자는 영원히 개발자에게만 매달릴 수밖에 없을까? 기획자 스스로 아이디어를 내고, 이걸 프로덕트로 구현할 방법이 없을까?

왜 ‘버블’인가?

노 코드 툴을 사용하는 이유

우선 “기획자는 개발자에게 매달릴 수밖에 없다.” 그렇다고 너무 실망하지 말자! 기획자도 특별한 방법을 이용하면, 어느 수준까지는 개발자에 매달리지 않을 수 있다. 이 특별한 방법이 바로 ‘노 코드 툴’이다.

노 코드 툴은 이름 그대로 코딩 없이 프로덕트를 만들게 돕는 툴이다. 아직까지 국내에서 노 코드 툴 보급이 활성화가 안 됐지만, 이미 해외에서는 다양한 노 코드 툴이 사용되고 있다. 글라이드(Glide), 웹플로우(Webflow) 등 다양한 툴이 있다. 사실, 이 글을 쓴 이유도 구글링에서 노 코드 툴을 검색해보면, 관련된 국내 이야기를 찾기 어려웠기 때문이다.

앞선 답에 ‘어느 수준까지’란 말을 붙인 이유는 노 코드 툴의 한계 때문이다. 노 코드 툴은 MVP, beta 버전 등 작은 규모의 프로덕트를 만드는 데 적합하다. 프로덕트의 규모가 일정 수준을 넘어간다면, 노 코드 툴이 거대한 규모를 감당하지 못한다. 노 코드 툴은 ‘거대한 프로덕트’를 완벽하게 만들기 위해 쓰는 게 아니라, ‘간단한 프로덕트’를 빠르게 만들기 위해서 사용된다.

자유도가 뛰어난 노 코드 툴, 버블

노 코드 툴에 관심을 갖게 된 이유는 ‘나 홀로 사이드 프로젝트’ 덕분이었다. 혼자서 사이드 프로젝트를 자주 했는데, ‘사이드’라는 말처럼 큰 규모의 프로덕트를 필요로 하지 않았다. 그 대신, 일종의 린 프로세스 같이 작은 프로덕트를 만들고 이 아이디어를 검증 및 개선하는 과정을 반복하는 과정이 요구된다. 물론, ‘작은 프로덕트여도 충분하다’라고 말했지만, 그럼에도 코딩 능력의 부재는 큰 장벽이었다. 이때, 지인으로부터 노 코드 툴을 소개받았고, 현재는 다양한 노 코드 툴 중에서 ‘버블(Bubble)’을 사용한다.

버블은 웹 앱 빌더다. 흡사 하이브리드 앱처럼 모바일 랩 래퍼(Wrapper)를 사용해 웹 앱을 덮어서 모바일 앱도 구현할 수 있다. 다양한 노 코드 툴 중에서 버블을 선택한 이유는 높은 자유도 때문이다. 가령 글라이드의 경우 구글 스프레드시트와 연동되어 쉽게 사용할 수 있지만 미리 설정된 레이아웃을 따라야만 한다. 반대로 버블은 요소(element)를 자유롭게 배치할 수 있지만, 그만큼 신경 써야 하는 부분이 많다.

결국 어떤 노코드 툴을 선택할지는 트레이드오프(trade-off)의 영역이다. 자유도가 높지만 그만큼 설정할 게 많은 툴을 쓸지 아니면, 자유도가 낮은 대신에 쉽고 간편한 툴을 쓸지 개인의 취향에 달려있다. 지금까지 버블로 2가지 사이드 프로젝트를 진행해봤다. ‘대학교 친구들끼리 책을 교환하는 플랫폼’을 구현 및 배포했고, 최근 ‘크루를 만들어서 운동 기록으로 경쟁하는 플랫폼‘을 구현했다. (지금은 창업 팀 합류로 모두 중단했다. 링크에서 디버그 모드로만 확인할 수 있다.)

버블 기능 맛보기!

버블에 접속하면 7개의 탭을 볼 수 있다. 각 탭에서 어떤 것을 할 수 있는지 짧고 굵게 알아보자!

• 디자인(Design): 웹 앱의 요소를 배치 및 수정
• 워크플로우(Workflow): 페이지마다 트리거와 액션으로 구성된 워크플로우를 설정
• 데이터(Data): 데이터 속성값을 설정, 생성된 데이터가 모인 DB를 확인
• 스타일(Styles): 요소에 범용적으로 적용 가능한 스타일을 설정
• 플러그인(Plugins): 웹 앱에 적용할 플러그인 탐색 및 설정
• 세팅(Settings): 도메인, 웹 앱 언어, HTML Header 및 Body 등을 설정
• 로그(Logs): 서버 상태, 워크플로우 로그 확인

1. 디자인 탭 Design Tab

웹 앱의 요소를 배치 및 수정

텍스트, 버튼, 아이콘 등의 시각 요소(Visual Elements)를 생성 및 배치할 수 있다. 컨테이너(Containers)를 활용해 각기 다른 요소를 그루핑해서 관리할 수도 있다. 유저로부터 인풋값을 받는 인풋 폼(Input Forms)도 만들 수 있다.

데이터 탭에 있는 특정 데이터를 불러와서 텍스트의 일부분으로 바로 사용할 수도 있다. 예를 들어, 유저의 닉네임이 FameLee라고 해보자. “안녕하세요 [불러온 유저의 닉네임] 님!”을 입력하면, “안녕하세요 FameLee님!”을 출력할 수 있다.

특정 요소의 클릭을 바로 워크플로우의 트리거(Trigger)로 설정할 수 있다. 트리거가 작동되면, 이후에 설정된 액션(Action)이 자동 실행된다. 아래 이미지를 보면, 유저가 ‘경쟁전 참가하기’ 버튼을 클릭하면, 바로 팝업을 보여줌을 알 수 있다. 이 워크플로우는 워크플로우 탭에서도 확인 가능하다.

워크플로우와 별개로, 아예 요소 자체적으로 if 설정값을 가질 수 있다. 각 요소의 설정 창에 있는 컨디셔널(conditional) 탭에서 특정 조건마다 서로 다른 설정값을 적용할 수 있다.

아래의 이미지를 보면, 텍스트 내 ‘홈트’가 포함되지 않을 경우에 배경색이 #E3E3E3로 변경됨을 볼 수 있다. 반대로 해당 값을 포함했다면 기존 헥사 코드가 적용된다. 디자인 말고도 작동 설정값을 바꿀 수 있다. 가령 로그인을 하지 않는 유저는 버튼을 클릭하지 못하게 만들 수도 있다.

[Style] 탭에서 설정한 요소별 스타일을 바로 적용해 쉬운 유지 보수도 가능하다. 텍스트, 버튼, 아이콘 등 각각의 요소별로 스타일을 설정할 수 있다.

2. 워크플로우 탭 Workflow Tab

페이지마다 워크플로우를 설정

이곳에서는 트리거와 액션으로 구성된 워크플로우를 페이지마다 생성 및 관리할 수 있다. 트리거 이벤트가 발생할 때, 후속의 액션들이 자동 집행된다. 가령, 어떤 버튼을 클릭했을 때 팝업을 보여준다고 할 때, 여기서 ‘버튼 클릭’이 트리거가 되고 ‘팝업 출력’이 액션이 된다.

요소와 무관한 트리거를 설정할 수 있는데 유저의 로그인 유무, 페이지 로딩, 에러 발생 등이 있다. 반대로 클릭, 팝업 생성/제거 등 요소와 관련된 트리거를 설정할 수도 있다.

액션은 더 다양한 설정값을 제공한다. 단순히 페이지 이동이나 팝업창 생성/제거뿐 아니라 로그인, 회원가입, 이메일 전송 등 계정 관련 액션도 가능하다. DB에 있는 특정 데이터를 수정 및 제거하거나, 새로운 데이터를 추가할 수도 있고 심지어 외부 플러그인과 관련된 액션도 가능하다.

3. 데이터 탭 Data Tab

데이터 속성값을 설정 + 생성된 데이터가 모인 DB를 확인

웹 앱에서 발생하는 데이터의 설정 및 관리가 가능하다. 유저 DB, 프로덕트 로그 DB 등 각각의 DB를 자유롭게 만든 후, 용도에 맞게 각 DB의 필드를 생성 및 관리할 수 있다. 관계형 데이터베이스처럼 서로 다른 DB끼리 연결도 가능하다. 물론 쿼리 기반이 아니라서, SQL 급으로 높은 자유도를 보장하지는 않는다.

DB 내 데이터를 직접 확인할 수도 있다. 그렇다고 모든 데이터를 볼 수 있는 건 아니다. 버블은 DB 필드 타입 중 ‘패스워드’가 있는데, 이 타입의 데이터는 확인이 불가능하다. 번외로, DB마다 별도의 데이터 정책을 설정할 수 있다.

4. 스타일 탭 Style Tab

요소에 범용적으로 적용 가능한 스타일을 설정

디자인 탭에서 생성한 요소별 스타일을 설정 및 관리할 수 있다. UXUI 작업을 하신 분들이라면 알겠지만, 이렇게 한 번 스타일을 만들고 재사용을 함으로써 작업 시간을 크게 단축할 수 있다.

디자인뿐 아니라 작동값도 설정할 수 있다. 피그마(Figma), XD의 컴포넌트 기능과 비슷하다고 생각하면 될 듯하다.

5. 플러그인 탭 Plug-in Tab

웹 앱에 적용할 플러그인 탐색 및 설정

외부 플러그인을 자유롭게 다운받아서 사용할 수 있고, 이를 통해 버블이 가진 기본 기능 외의 것을 구현할 수 있다. 무료 플러그인도 있지만, 유료 플러그인도 존재한다. 유료 플러그인의 경우, 보통 구독제로 요금이 차감된다.

생각보다 많은 플러그인을 제공한다. 플러그인을 활용해 기존에 없는 요소를 추가할 수 있다. 예를 들어, 기존 버블에는 1개의 항목을 선택 가능한 ‘드롭다운 요소(Dropdown element)’는 있지만, 2개 이상의 항목을 선택 가능한 ‘멀티셀렉 드롭다운 요소(Multiselect Dropdown Element)’는 존재하지 않는다. 이때, 멀티셀렉 드롭다운 플러그인을 추가해 기존에 없는 ‘멀티셀렉 드롭다운 요소’를 생성할 수 있다.

외부 서드 파티 툴과 연동해 새로운 기능을 부여할 수도 있다. 예를 들어, GA, GTM 플러그인을 추가하면 별도의 HTML 코드 수정 없이 쉽게 웹 앱에 데이터 분석 툴을 추가할 수 있다.

6. 세팅 탭 Settings Tab

도메인, 웹 앱 언어, HTML Header 및 Body 등을 설정

세팅 탭에서 웹 앱의 기본 설정의 변경 및 관리가 가능하다. 웹 앱의 기본 언어를 설정하거나, 특정 케이스에서의 출력 메시지를 한 번에 설정할 수 있다. 참고로 한국어도 지원된다! UI 작업을 편하게 하기 위해, 개별 폰트를 추가하거나 컬러 팔레트 설정도 가능하다.

메타 타이틀(meta Title), 메타 디스트립션(meta Description)을 바로 설정해 간단한 SEO 작업이 가능하고, 아예 HTML의 값도 설정할 수 있다.

버블이 bubbleapps.io라는 도메인을 기본으로 제공하지만, 자신이 소유한 도메인을 직접 연결할 수도 있다. 도메인 연결 말고도, API를 설정해서 서드 파티 툴과 직접 연동시킬 수 있다. (사실 이 기능은 아직 써보지는 않았다.)

7. 로그 탭 log tab

서버 상태, 워크플로우 로그 확인

로그 탭에서 서버의 안정성(capacity)을 확인하거나, 워크플로우 탭에서 생성한 워크플로우의 작동 기록을 확인할 수 있다.

버블로 이런 것도 돼?

탭(Tab)을 기준으로 버블이 어떤 기능을 제공하는지 간략하게 훑어봤다. 위의 내용만 어느 정도 숙지하면, 버블이 어떤 툴이고, 무엇을 할 수 있는지 짐작할 수 있을 것이다. 위에서 다룬 것 외에도, 버블에서 꽤 도움이 된 기능을 몇 가지를 더 소개하고자 한다. 이 기능은 특히 핫픽스 이슈로 고생하는 개발자나, UI를 중요하게 여기는 디자이너에게 꿀 기능이다.

모바일, 태블릿, 데스크톱 모두 가능!

width, margine 등을 설정해 반응형 UI를 설정할 수 있다. 이를 통해 화면 크기가 다른 모바일, 태블릿, 데스크톱 모두 대응 가능한 프로덕트를 만들 수 있다. 단 기기별로 width를 설정하는 형식이 아니라 기존 요소의 width에서 비율이 적용되는 식이라서 어느 정도 제한이 있다.

아이고! 이번 버전에 큰 버그가 있었어요!

배포한 프로덕트의 히스토리(History) 기능을 제공한다. 프로덕트를 배포했는데 예상치 못한 버그나 이슈가 발생했을 경우, 빠르게 이전 버전을 복원해서 재배포할 수 있다.

재사용이 얼마나 편하게요

피그마, XD의 컴포넌트 – 인스턴트 기능처럼, 재사용 가능한 요소(Reusable elements)를 만들 수 있다. 컴포넌트를 수정하면, 복제된 인스턴트 요소들 모두 수정이 반영되서 유지 보수가 편하다.

태그 느낌을 추가하고 싶다면?

식당 추천 서비스를 구현 중인데, 식당 정보를 ‘한식’ ‘일식’ ‘중식’ ‘일식’으로 분류해서 제공하고 싶다고 해보자. 식당 DB에 식당 종류(‘한식’ ‘일식’ etc) 필드를 추가했을 때, 어떤 타입의 데이터를 설정해야 할까?

이렇게 유한한 선택지가 있는 경우에 문자열 데이터가 아니라 범주형(=카테고리) 데이터를 쓰는 게 좋으며, 버블에서는 범주형 데이터 세트를 따로 관리하는 공간이 있다. GNB의 데이터 탭에 들어가 보면, LNB에 옵션 세트(Option sets) 탭을 볼 수 있는데, 이곳에서 여기서 범주형(카테고리형) 데이터 세트를 생성 및 관리할 수 있다.

원문: FameLee의 브런치

관련 글

• Tae Kim, 「노코드: 개발자 없이 소프트웨어 개발을 할 수 있는 14가지 툴」, 10x LESSONS

이 필자의 다른 글

• 프로덕트가 ‘될 놈’인지 알아내는 방법
• 린하고 스마트하게, 나 홀로 사이드 프로젝트
• 이렇게만 해보자! OKR 도입하기

1. 내 아이디어가 ‘될 놈’인지 궁금하다.
2. 가설을 검증할 방법을 고민 중이다.
3. 어디서 책 읽어본 척하고 싶다.

이 아이디어는 ‘될 놈’일까?

많은 기업이 오랜 시간과 노력을 들여서 프로덕트를 만든다. 하지만, 이렇게 탄생한 프로덕트 중에서 살아남는 비율은 고작 10%다. 90%의 프로덕트가 망하는 이유는, 아이디어가 처음부터 ‘될 놈’이 아니기 때문이다.

따라서 스타트업은 이 아이디어가 처음부터 ‘될 놈’인지를 알아내야 한다. 아이디어가 ‘될 놈’임을 알아냈다면 자원을 집중해서 성공 확률을 높일 수 있고, ‘될 놈’이 아니라면 아까운 자원을 아낄 수 있다. 이 아이디어가 ‘될 놈’인지 알기 위해선 가설을 세우고, 실험을 통해 검증해야 한다.

알베르토 사보이아의 『아이디어 불패의 법칙』(인플루엔셜)은 아이디어가 ‘될 놈’인지 알 수 있는 내용을 소개한 책이다. 이전 글 「90%의 제품이 망하는 건 ○○ 때문이다」에서 가설을 어떻게 세워야 하는지 다뤘다면, 이번 글에선 어떻게 실험하는지 다룬다.

Do you Know ‘Pretotype’?

쓰레기가 들어가면 쓰레기가 나온다

프리토타이핑 도구를 적절히 사용한다면 어느 아이디어가 ‘될 놈’인지 ‘안 될 놈’인지를 결정하도록 도와줄 것이다.

• 143쪽

아이디어의 가능성을 객관적으로 판단하기 위해, 고객이 어떻게 반응했는지를 보여주는 데이터가 필요하다. 데이터의 중요성을 가장 잘 보여주는 표현으로, ‘쓰레기가 들어가면 쓰레기가 나온다(Garbage in, garbage out)’는 말이 있다. 좋은 결과가 나오기 위해선 좋은 데이터가 필요하다는 말이다. 이는 가설 검증에서도 마찬가지다. 좋은 데이터가 있어야지 가설의 올바른 검증이 가능하다.

아이디어의 가능성을 알기 위해 서베이, FGI 등 다양한 조사가 진행되고, 여기서 수많은 고객 반응 데이터를 수집한다. 근데, 프로덕트가 없는 상태에서 수집한 고객 반응 데이터가 정말 타당할까? 이렇게 수집한 데이터엔 노이즈가 끼어 있을 수밖에 없다.

실체 없는 프로덕트는 오로지 고객의 상상에 의존한다. 프로덕트가 어떤 형태고, 어떤 가치를 제공하는지 모두 고객이 생각해야 한다. 프로덕트뿐 아니라 이걸 쓰는 상황도 고객이 생각해야 한다. 이 과정에서 ‘우리가 생각한 프로덕트’와 ‘고객이 생각한 프로덕트’가 달라질 수 있다. 무엇보다도 고객은 프로덕트를 쓰기 위해 실제로 돈과 시간을 쓰지 않는다. 따라서 객관적이고 이성적인 판단을 할 가능성이 작아진다.

완성된 것’처럼’! 프리토타입!

올바른 고객 반응 데이터를 얻기 위해선, 프로덕트가 있어야 한다. 프로덕트가 필요하다니? 프로덕트를 만드는 데 얼마나 많은 시간과 노력이 드는데, 무작정 만드는 게 말이 되는가? 물론 데이터 없이 프로덕트를 만드는 건 말도 안 된다. 여기서 핵심은 ‘완성’이 아니라 ‘실체’에 있다. 즉 진짜 완성된 프로덕트는 아니지만, 고객이 봤을 때 완성된 것’처럼’ 느껴지는 프로덕트면 충분하다.

실제로 완성된 건 아니지만, 고객의 시선에서 완성된 것처럼 보이는 프로덕트를 프리토타입(pretotype) 모델이라 부른다. 프리토타입은 우리가 흔히 아는 시제품, 즉 프로토타입(prototype) 모델과 목적을 달리한다.

• 프로토타입의 목적은 ‘프로덕트를 어떻게 만들어야 하는가?’ ‘프로덕트가 어떻게 작동하는가?’를 알기 위함에 있다. 이와 다르게 프리토타입은 ‘아이디어가 만들 가치가 있는가?’를 빠르게 검증하는 걸 목적으로 한다.
• 프로토타입은 ‘1 to 100’의 영역이라면, 프리토타입은 ‘0 to 1’의 영역에 있다. 프리토타입으로 아이디어의 가능성 유무(0 to 1)를 검증하고, 프로토타입으로 이 아이디어의 퀄리티(1 to 100)을 높여간다.

다양한 프리토타입, 씹고 뜯고 맛보기

생각랜드에서 의견과 그들의 데이터에 너무 많은 시간을 들이고 다시 사업 계획서를 쓰느라 몇 달씩 시간을 보내는 팀은 보통 실패한다. 계획과 검증은 최소만 실시하고 출시를 서두르는 팀은 보통 실패한다. 시장 ‘테스트’를 서두르는 팀은 보통 성공한다.

• 276쪽

프리토타입은 형태가 아닌 본질에 항상 집중해야 한다. 프리토타입의 본질은 1) 유효한 데이터를 2) 빠르고 3) 저렴하게 만들어서, 아이디어가 ‘될 놈’인지 알아내는 것에 있다. 스타트업은 다양한 가설을 빠르고 효율적으로 검증해가면서 올바른 길을 찾는데, 프리토타입도 가설 검증의 일환이다. 프리토타입을 통해 실제 데이터를 수집할 수 있고, 이 덕분에 효과적이고 객관적인 검증이 가능하다. 책에서 다룬 프리토 타입 기법 몇 가지와 사례를 가져왔다.

1. 미캐니컬 터크 프리토타입

예전에 세계를 돌면서 체스를 둔 기계 ‘터크’의 일화에서 비롯된 이름이다. 당시 사람들은 ‘터크’가 체스를 두기 위해 정교하게 프로그래밍 된 기계라고 믿었다. 그러나 사실은 체구가 작은 프로 체스 선수가 숨어서 마네킹을 조종했던 것이다.

이와 관련된 사례가 IBM의 음성 인식 실험이다. 과거에 IBM은 음성 인식 컴퓨터를 개발할지 고민했다. 당시에 음성 인식 기술은 고차원의 기술이었으므로 이를 개발하기 위해선 많은 자원을 쏟아야만 했다. 따라서 IBM은 이 사업이 투자할 만한 가치가 있는지 알아내야 했고 실험을 진행했다.

새로운 프로덕트가 나왔다고 홍보하고, 이를 체험할 참가자를 모집했다. 실험실에 참가자를 데려오고, 참가자에게 실험실에 설치된 기계에게 자유롭게 말을 하도록 했다. 참가자가 한 말은 곧바로 기계의 화면에 텍스트로 출력됐고, 이들은 자신의 목소리를 들은 기계가 바로 음성을 텍스트로 변환했다고 생각했다.

사실은 기계가 아니라, 숨어 있는 타이피스트가 참가자의 목소리를 듣고 바로 텍스트로 입력했던 것이었다. 즉, 기계가 아닌 사람이 한 일이지만, 참가자 시선에선 마치 기계가 한 일처럼 보였다. 실험 결과, 참가자는 음성 인식에 부정적인 반응을 보였고, IBM은 이 서비스가 ‘안 될 놈’임을 사전에 알아내서 자원을 낭비하지 않게 됐다.

2. 피노키오 프리토타입

리텐션(retention)은 프로덕트가 PMF(Product Market Fit)를 달성했는지 가장 직관적으로 보여주는 지표인데, 그만큼 사람들이 프로덕트를 얼마나 자주 사용하는지가 매우 중요하다. 근데 한 번도 경험해 보지 못한 프로덕트를 어떤 상황에서 주로 쓰고, 얼마나 자주 사용하는지 생각할 수 있을까?

제프 호킨스는 PDA를 만들기 전, 사람들이 이 프로덕트를 얼마나 자주 사용할지 알고 싶어 했다. 그는 나무 조각으로 목재 모형을 만들고, 마치 PDA가 작동하는 것처럼 행동했다. 사람들이 일정을 물어볼 때마다 목재 모형을 꺼내서 일정표를 확인하는 것처럼 두드렸고, 전화번호가 필요하면 모형 위에서 찾아보는 척을 했다. 이렇게 모은 데이터로 PDA가 어떤 상황에서, 얼마나 자주 쓰이는지 알아냈고, 개발을 착수했다.

3. 가짜 문 프리토타입

가짜 문 프리토타입은 아직 내놓을 게 아무것도 없다 하더라도, 프로덕트가 마치 존재하는 것처럼 보일 만한 현관문을 설치해서 고객 반응을 보는 기법이다. 고객이 이 프로덕트에 관심이 있다면, 현관문을 두드릴 것이고 이 노크 데이터를 통해 가능성을 판단한다.

책에서는 가짜 문 사례로 앤토니아와 앤티크 서점을 다룬다. 앤토니아는 직장을 그만두고 자신만의 앤티크 서점을 오픈하고 싶어 한다. 그러나 오프라인 서점을 열기 위해선 많은 비용과 시간이 필요했고, 돈을 쏟기 전에 가능성을 먼저 검증하고 싶었다. 사람들이 길가의 서점에 실제로 방문하는지 어떻게 알 수 있을까? 가게를 대여하고, 이 가게를 채울 서적을 구매하고… 이러면 오히려 배보다 배꼽이 더 커지는 셈이다.

대신 입점하고자 한 길가에 앤티크 서점 문’처럼’ 보이는 안내판을 설치했다. 이후 지나가는 사람 중에서 얼마나 많은 사람이 이 가짜 문을 지나치다가 관심을 보였는지, 실제로 문을 열려고 했는지 등을 기록했다. 이처럼 그녀는 큰돈을 들이지 않고 앤티크 서점의 가능성을 데이터 기반으로 알아낼 수 있었다.

4. 하룻밤 프리토타입, 한 입 프리토타입

하룻밤 프리토타입은 특정 장소에서 한 번밖에 하지 않는 공연 형태에서 따온 이름으로, 아이디어를 실제로 매우 짧은 동안 진행해보는 방식이다. 가장 대표적인 사례가 에어비앤비다.

모두에게 익숙한 이야기겠지만, 에어비앤비의 이름은 ‘에어 매트리스’와 ‘아침 식사’에서 나왔다. 에어비앤비 설립자는 아파트 방 한 칸에 있는 에어 매트리스를 하루 동안 임대하자는 아이디어를 냈고, 실제로 사람들이 와서 숙박하고 갔다. 에어비앤비의 핵심 기능을 프리토타입으로 하루 동안 진행한 셈이다.

한 입 프리토타입는 하룻밤 프리토타입와 결이 유사하다. 하룻밤 프리토타입이 짧은 기간에 아이디어를 모두 체험해볼 수 있게 한다면, 한 입 프리토타입은 오랜 기간 동안 아이디어를 조금씩 체험하게 만든다.

많은 분이 화성에서 살아남는 우주비행사를 다룬 책 『마션』을 알 것이다. 『마션』의 저자인 앤디 위어는 책을 출판하기 위해 에이전시와 출판사를 찾아갔지만, 줄줄이 거절을 당했다. 실망한 위어는 일부 챕터를 그의 사이트에서 공짜로 연재했고, 매주 이 우주비행사의 이야기를 듣기 위해 많은 사람이 몰려왔다. 사이트에 찾아온 사람 수를 통해 『마션』의 가능성을 데이터로 증명한 셈이다.

5. 잠입자 프리토타입, 상표 바꾸기 프리토타입

잠입자 프리토타입은 우리 제품을 다른 누군가의 기존 판매 환경에 몰래 끼워 넣는 방식이다. 평소 비슷한 제품이 놓이는 곳에 제품을 가져다 두고, 사람들이 이 제품을 실제로 가져가는지 지켜본다.

대표적인 사례로 저스틴 포카노와 월허브가 있다. 그는 자신이 만든 스위치판인, 월허브(Walhub)가 실제로 고객들이 원하는 프로덕트인지 알기 위해, 이케아에 잠입했다. 이케아 직원 셔츠를 중고로 샀고, 이케아 제품처럼 보이는 라벨과 가격표를 몇 개 제작해서 월허브에 붙였다. 이후, 이케아에서 직원 몰래 자신의 제품을 진열했고, 쇼핑객들이 집어가는지 지켜봤다.

책 표지를 예시로 들 수 있다. 서점에 방문한 사람은 다양한 책 중에서 표지를 보고 책을 고른다. 이 점을 활용하면 새 책을 실제로 출판하지 않고도 책이 ‘될 놈’인지를 알 수 있다. 진열된 기존 책에 출판하고자 한 책의 표지를 덮어씌우고, 사람들이 책의 거짓된 표지에 관심을 보이는지 지켜보면 된다. 만약 표지에 관심을 두고 집어 든 사람이 많으면, 자신이 집필하려고 준비하는 책은 그만큼 ‘될 놈’일 확률이 높음을 뜻한다.

원문: FameLee의 브런치

함께 보면 좋은 글

• 프로토타이핑의 세 얼굴
• 좋은 PM이 반드시 알아야 할 우선순위 정하기 기법 4가지
• 구린 서비스를 시장에 맞게 개선하기: 프로덕트 마켓 핏이 가장 중요하다