유저가 좋아하는 제품을 빨리 만드는 법.

1. 유저가 좋아하는 제품을 빨리 만든다는 것

어떻게 하면 유저가 좋아하는 제품을 “빨리“ 만들 수 있을까?

창업을 하면서 내가 가장 어려웠던 것 중 하나는 유저가 좋아하는 제품을 “빨리“ 만드는 것이었다. 유저가 좋아하는 제품을 만드는 일 그 자체도 어려운데, 그것을 빨리 만드는 일은 더 더 어려운 일이다.

유저가 좋아하는 제품을 만들기 위해서는 크게 다섯 가지의 과정이 필요하다.

• 문제점 파악하기 - 유저를 만나 유저의 페인포인트가 뭔지 파악해야하고,

• 솔루션 정하기 - 유저 반응을 토대로 무엇을, 어떻게 만들지 정해야하고,

• 디자인하기 - 결정된 아이디어를 실제 디자인으로 만들어야하고,

• 개발하기 - 그 디자인을 실제 작동하는 프로덕트로 개발해야한다.

• 피드백 받기 - 그리고 유저 피드백을 받아 위의 과정을 반복한다.

이 중 가장 시간이 오래 걸리는 것 중 하나는 개발이다. 그렇기 때문에 “빨리” 만들기 위해서 나는 항상 노션, 구글폼, 각종 노코드 및 다른 서비스 등을 이용하여 아예 개발하지 않는 방법을 먼저 생각해왔다.

하지만 이러한 노력에도 불구하고 가끔은 개발을 피할 수 없는 상황이 올 때가 종종 있었다.

2.개발을 피할 수 없는 상황

몇 년 전 내가 한창 프로덕트를 만드는 방법론에 관심이 많았을 때, 나는 해외 Saas 스타트업 사례들을 하루종일 찾아보곤 했었다. 당시 개발 없이 엑셀, 구글폼 등 만으로도 MVP를 만든 사례를 많이 접하게 되었었는데, 그걸 보며 ‘아 개발 없이도 참 많은 것이 가능하구나’ 라고 생각했었다.

하지만 내가 막상 MVP를 만들어보니 정말 다양한 이유로 개발이 필요한 경우가 참 많았다.

1. (신뢰도) 기능은 다 있지만 조금 없어보이고 신뢰도가 떨어져서

2. (학습비용) 노코드 툴을 새로 배워서 쓰는 것보다 개발하는 것이 더 빨라서

3. (사용자인식) 기능은 되는데 디자인이 안좋아 사용자 인식에 악영향을 줘서

4. (UX) 기능은 되는데 UX가 일반적이지 않아서 헷갈려서

5. (팀 합의) 논의할 시간이 그냥 개발할 시간보다 더 걸려서

등등…

이 중에서 신뢰도적인 문제가 가장 어려웠는데, 개발 없이 만든 서비스는 특히 기업을 상대할 때 악영향을 미치는 경우가 많았다. 처음에는 이런 내 생각을 “스타트업적이지 못한 자세”라고 생각했었다. “아니, 그런 건 사소한 거야, 집중해야하는 건 저런 게 아니라 핵심기능과 가설검증이야” 라면서 말이다.

하지만 반복적으로 유저반응을 지켜보면서 내가 느꼈던 것은 “사소하지 않을 수도 있겠다”라는 점이었다. 스타트업은 개발없이 빠른 시간내에 가설검증하는 것에 집중해야한다. 하지만 빠르게 검증하기 위해 생기는 여러 사소한 요소들이 모여 유저 경험에 나쁜 영향을 주고, 그것이 가설 검증에까지 나쁜 영향을 미치게 된다면, 조금 속도를 늦추더라도 개발을 고려해야한다는 생각이 들었다.

예전에 한 강연에서 레딧과 트위치의 창업자가 “유저가 안쓰는 이유”에 대해 얘기한 적이 있다. 유저가 안쓰는 이유는 마치 대단하고 큰 이유 때문일 것만 같지만, 대부분은 굉장히 사소한 것 때문인 경우가 많았다고 한다. 트위치의 경우, 유저들이 자주 쓰는 한 웹사이트에 등록을 안 해놓았다는 이유로 3,000여명의 사용자를 잃었다고 한다. 나 또한 “유저가 안쓰는 이유”가 생각보다 굉장히 작은 것에서 결정된다는 것을 나중에서야 깨달았고, 이제는 그 작은 것을 위해 가끔은 개발이 필요할 때도 있다는 사실을 받아들이기로 했다.

하지만 여전히 개발을 한다는 것은 굉장히 시간적, 재정적 비용이 많이 드는 일인 것은 사실이다.

그렇다면 이렇게 개발을 피할 수 없는 경우, 어떻게 하면 시간을 최소화 할 수 있을까?

3. 개발을 피할 수 없을때 제품을 “빨리” 만드는 법

나는 사실 처음 스타트업을 시작했을때만 해도 “프로덕트를 빨리 만드는 법”에 대해서 잘 알지 못했다. 여기서 “빨리 만든다는 것”은 단지 개발을 빠르게 하는 방법을 얘기하는 것은 아니다. 개발 속도는 그냥 개발자로써 최선을 다해야하는 것이고, 그것보다 알고 싶었던 것은 전체적인 프로세스였다.

내가 알고 있던 린하게 하는 방법은 “개발을 최소화한다” 라는 것이었는데, 개발이 불가피해 졌을 때 나는 어떻게 시간을 줄일 수 있는지 몰라서 헤멨다. 내가 할 수 있었던 것은 “범위를 최소화한다”, “애자일로 빠르게 출시하고 계속 개선한다”, “오픈소스를 활용한다.” 라는 원론적인 방법 밖에 없었고, 그래서 그냥 어쩔 수 없는 대로 시간을 줄이는 데 최선을 다할 수 밖에 없었다.

그러던 도중 우연히 한 계기로 개발을 하면서도 빨리 만드는 방법에 대한 힌트를 얻을 수 있었는데, 그것은 바로 시작클럽이라는 서비스를 만들면서였다.

4. 시작클럽을 만들게 되다.

작년 9월, 당시 우리 팀은 개발없이 노션으로 만든 채용플랫폼 MVP를 운영하고 있었는데, 여러 노력에도 유저 수가 잘 늘지 않아 고민하고 있었다. 그러다 우리는 유저를 늘릴 방안으로 초대 받은 사람만 가입할 수 있는 프라이빗 커뮤니티를 운영해보기로 했다.

나는 여느 때와 마찬가지로 그 중에 실제 출시되는 프로덕트를 만드는 일을 담당하게 됐다. 여의도에서 팀 회식을 마치고 늦은 밤, 모두 각자의 집으로 발길을 돌렸다. 집으로 돌아가는 길, 어두컴컴한 텅 빈 도로를 달리는 352번 버스에 자리를 잡고 앉았다. 그리고 덜컹거리는 버스 안 의자에 앉아 무엇을, 어떻게 만들어야하는지 고민을 하며 깊은 생각에 잠겼다.

처음엔 개발없이 할 수 있는 방법들이 없을까도 고민해봤지만 몇 가지 이유들 때문에 결국 개발이 필요해보였다. 하지만 개발이 필요하다는 사실은 나에게 큰 부담으로 다가왔다. 나는 디자인하는 것도, 개발하는 것도 너무너무 좋아하지만, 인원과 시간이 부족한 우리 팀의 여러 조건들을 고려하면 적어도 한 달 이상은 소요될 것 같았기 때문이다. 음….어떡하지..? 그렇게 고민하다가 문득 이런 생각이 들었다,

그냥 주말 이틀동안 MVP를 개발해버릴 수는 없을까?

5. 어차피 오래 걸릴 거면 아예 빨리 만들어보자

여러 고민을 하다가 그냥 주말 이틀동안 MVP를 개발해버릴 수는 없을까?라는 대책없는 생각이 문득 들었다. 바로 뾰족한 수가 떠오르지는 않았지만, 이 참에 한번 이 질문에 대한 해답을 찾아보기로했다.

주어진 기간은 단 이틀 밖에 없었기에 시간 내에 만들기 위해서는 디자인 → 개발에 드는 모든 양을 최소화해야했다. 그래서 내가 고안한 방법은 바로 이미 만들어진 서비스를 최대한 활용하는 것이었다. 그러기 위해서 우선 시작클럽 MVP에서 꼭 필요한 기능들이 무엇인지 정의해봤다.

[필요한 기능들]

• 가입제한: 초대 받은 사람만 가입할 수 있는 프라이빗 커뮤니티를 만든다.

• 이벤트 알림: 시작에서 열리는 네트워킹 이벤트들은 클럽 멤버들만 볼 수 있어야 한다.

• 초대 기능: 시작클럽 멤버는 친구를 2명씩 초대가능해야한다.

• 커뮤니티 기능: 멤버들끼리 각 주제별로 서로 떠들고 교류할 수 있는 온라인 공간을 만든다.

• 가입정보 트랙킹: 해당 멤버가 누구에게 초대를 받았고, 몇 단계에 걸쳐 초대된 멤버인지 추적할 수 있게 한다.

필요한 기능들을 정의하고 나서는 해당 기능들을 대체할 수 있는 서비스들에 대해 알아보기 시작했다. 각 기능별로 대체 가능한 서비스들을 찾아보니 어느 새 전체적인 그림이 그려졌다. 전체적인 그림이 나오고나서는 그 그림을 바탕으로 서둘러서 디자인과 개발을 시작했다. 각 기능들을 대체하기 위해 사용했던 서비스들은 아래와 같다.

[사용한 외부 서비스 목록]

** 아무래도 개발에 관한 내용이 있다보니 개발용어/개념들이 많지만 비개발자도 이해하는데 어려움이 없도록 최대한 풀어서 써보겠다.

• Nextjs (빠른 개발)

  • 웹사이트 개발을 빠르게 할 수 있게 도와주는 여러 기능이 포함된 툴이라고 생각하면 된다.(이런 걸 프레임워크라고 한다) 보통은 다른 기능 때문에 많이 사용하지만 나같은 경우에는 개발 속도를 위해서 사용했다.

• Firebase (백엔드 대체)

  • 회원정보, 초대코드 등 어떤 정보를 데이터베이스(엑셀) 에 저장해놓고 사용하려면 관련 코드를 작성해야한다.(이걸 보통 백엔드라고 한다) 그런데 BaaS(Backend-as-a-Service) 라고 이런 코드를 개발하지 않아도 마치 그냥 폰에서 카톡을 설치해서 쓰듯이 이런 일들을 대신 해주는 서비스들이 있다. 개발 속도를 위해 백엔드 코드를 대부분 Firebase라는 서비스로 대체했다.

• referral-codes (초대코드 발급)

  • 신규 유저를 초대할 수 있는 코드를 발급하는 것은 생각보다 복잡하다. 숫자로 할 지, 소문자를 포함할지, 대문자로 할 지, 코드는 몇자리인지, 여태 발급된 코드와 중복되지 않는지 등등 은근 결정해야할 로직들이 많다. 따라서 이를 하나씩 다 개발하기보다 이미 개발된 코드를 사용했다.

• react-barcode (바코드 발급)

  • 아무리 초대가 초대코드로 이루어진다고 하더라도 그냥 코드만 띡 알려주는 것은 별로 좋은 UX가 아니라고 생각했다. 따라서 초대권 같은 형태의 디자인을 생각했는데, 이 티켓에 들어갈 바코드를 해당 오픈소스로 대체하였다.

• 카카오로그인 API (회원가입, 본인인증)

  • 사람들이 시작클럽에 가입할 수 있도록 회원가입 기능이 필요했다. 처음에는 Firebase로 로그인을 구현하려고 했었는데 Firebase는 본인 인증이 어렵다는 어려움이 있었다(가능한데 유료다). 따라서 무료로 본인인증을 할 수 있는 카카오로그인 API로 로그인을 구현하여 본인인증과 로그인을 둘 다 구현하였다.

• 카카오톡 공유하기 (초대권 공유)

  • 시작클럽에 가입한 사람은 친구를 초대할 수 있는 두 개의 초대코드를 발급받는다. 이를 공유하기 쉽도록 카카오톡 공유하기 API 를 사용하여 카톡으로 초대권을 공유할 수 있도록 개발했다.

• 디스코드 앱 (커뮤니티 기능, 초대 기능)

  • 커뮤니티 기능을 개발하는 대신 디스코드로 커뮤니티 기능을 대체했다. 가장 핵심적인 기능은 프라이빗 네트워킹 모임을 공지할 수 있는 기능과 서로 소통할 수 있는 기능이었기 때문에 디스코드로 충분히 대체할 수 있었다.

  • 디스코드 API를 활용하여 회원가입시 시작클럽 전용채널에 가입 가능한 초대링크를 자동으로 발급받을 수 있게 자동화했다. 커뮤니티 기능을 대체할 서비스를 찾을때 또 중요하게 생각했던 것은 바로 초대 기능이었는데, 디스코드는 API(외부개발자들도 사용할 수 있도록 만들어놓은 코드라고 생각하면 된다)를 통해 초대링크를 생성할 수 있기 때문에 디스코드를 선택했다. 사실 바로 쓸 수 있도록 만들어져있던 것은 아니었어서 살짝의 자체 개발이 필요했다.

• mui, nextjs-progressbar

  • 버튼, 입력폼 등 사소하지만 은근히 개발시간이 걸리는 작은 컴포넌트들은 이미 만들어진 오픈소스를 사용했다. mui 등 이미 만들어진 컴포넌트들을 적극 활용하여 디자인과 개발시간을 최소화 했다.

모든 방법을 총 동원해서 디자인 단계부터 개발량을 최소화한 결과, 디자인과 개발시간을 2일로 단축할 수 있었다. 그렇게 완성된 제품을 가지고 회사에 출근하여 월요일 아침 팀원들에게 보여주었더니 팀원들이 빠른 개발속도에 놀라워했다. 팀원들의 추가적인 도움을 받아 여러 디테일들을 추가하여 얼마 뒤에 바로 제품을 바로 출시할 수 있었다.

6. 빠른 출시……. 그리고 망하다.

그렇게 빠르게 출시한 시작클럽, 결론부터 얘기하자면 망했다.

약 2주 정도만에 130여명의 디자이너를 가입시켰고 최대 5번을 걸쳐 초대권이 사용되는 등 나름 괜찮은 성과가 있기도 했지만, 생각했던 것보다 커뮤니티를 활성화 시키기는 것은 쉬운 일이 아니었다. 가설과는 조금 달랐던 몇 가지 결과들 때문에 열심히 만든 시작클럽 프로덕트는 런칭 한 달여 만에 서비스를 종료하게 되었다

비록 열심히 만든 서비스는 한 달 만에 사르르 없어졌어도 마냥 아쉽지 만은 않았다. 이번 개발을 통해 무엇보다도 중요한 교훈을 얻게 되었기 때문이다.

아 디자인 단계부터 이미 만들어진 서비스를 미리 고려한다면 이렇게 빨리 만들 수 있구나

라는 교훈이었다.

그래서 알게 된 게 바로 디자인 단계부터 대체 가능한 서비스를 고려하는 ODD라는 방법론이다.

7. ODD란?

ODD 는 Open-source Driven Development 의 약자로, 디자인 단계부터 대체 가능한 서비스를 고려하여 개발속도를 올리는 프로덕트 제작법을 얘기한다. 원래 있는 말은 아니고 TDD와 BDD의 영감을 받아 내가 만든 말이다.

폰DD….

ODD는 디자인 단계에서부터 오픈소스를 고려하여 불필요한 개발을 막는 것이 핵심이다. 사실 오픈소스는 개발자에게는 흔한 개념이지만 디자이너에게는 그렇지 않다. 그래서 일을 하다보면 이미 시중에 충분히 괜찮은 퀄리티의 컴포넌트, 기능 등이 있음에도 불구하고 새로 만드는 일도 종종 생기되고, 이에 따라 불필요한 디자인, 개발 시간이 소요된다.

따라서 이를 막기 위해서는 개발자와 디자이너가 적극적으로 소통하여 기획단계부터 오픈소스를 고려하고, 최대한 개발량을 줄이는 작업이 필요하다. 여기서 오픈소스란 꼭 개발적인 “오픈소스” 말고도 노션, 구글폼, 구글스프레드시트 등 일반인을 대상으로 한 여러 서비스를 활용하는 것도 포함한다.

8. ODD 케이스 스터디: 디자이너 전문 채용플랫폼, 시작(seezak)

ODD는 시작클럽 뿐만 아니라 그 이후에 시작(seezak.com)을 개발할 때도 유용하게 쓰였는데, ODD를 활용하여 2주만에 시작 플랫폼을 출시한 사례를 공유해보고자 한다. 시작에서 쓰인 ODD 방법은 크게 네 가지가 있는데 하나씩 봐보면 다음과 같다.

방법 1. 만들어진 디자인을 그대로 쓴다 (css 프레임워크)

1-1. CSS 프레임워크

seezak의 개발 시간을 줄이기 위해서 이미 만들어진 디자인 컴포넌트, 즉 CSS 프레임워크를 많이 활용했다. css 프레임워크(이미 만들어진 디자인&코드라고 생각하면 된다)라고 검색하면 여러 프레임워크들을 확인할 수 있는데 각 서비스 별로 특징이 다르다.

여러 프레임워크 중 두 가지를 추천해보자면 mui 와 antd가 나름 괜찮다.

• mui: 구글 머티리얼 디자인을 바탕으로 한 컴포넌트들을 사용할 수 있다. 문서 정리가 굉장히 잘되어있고 여러 상황에서 적용이 잘 되도록 깔끔하게 개발되어있다. 따라서 개발자 입장에서 사용하기 편하지만 아직 최신 머터리얼 디자인이 적용되지 않아 살짝 한국서비스와 맞지 않는 디자인 ui를 가지고 있는게 단점이라면 단점이다.

• antd: antd 는 디자인은 살짝 디자인이 더 한국스럽고 이쁘지만, 개발적으로 mui보다 사용하기 살짝 불편하다. 가끔 달력이라던가 한글화가 안되거나 어색하게 되어있는 부분도 있는데 그래도 그냥저냥 쓸만하다. 사실 불편하다고 하기에는 너무 잘되어있고 문서화도 나름 잘 되어있는 편이여서 잘 활용하면 좋다.

대부분 커스터마이징이 가능하기 때문에 조금 마음에 들지 않더라도 자신의 상황에 맞게 커스터마이징해서 쓰면 된다. 미리 디자이너와 소통해서 CSS 프레임워크의 기초적인 개념과, 어느 걸 사용할 건지를 미리 알려주면 서로 더 편하게 작업할 수 있다. 시작을 만들 때는 각종 입력 폼, 탭, 테이블 등 복잡한 컴포넌트를 모두 antd나 mui를 사용해서 빠르게 개발할 수 있었다.

방법 2. 만들어진 기능을 그대로 쓴다 (오픈소스 라이브러리)

2-1 테이블형 UI (AG grid)

• 시작의 핵심 UX 중 하나는 데이터를 한눈에 볼 수 있는 테이블형 UI이다. 테이블형 UI는 기능적으로도, 개발적으로도 카드형 UI에 비해서 생각보다 손이 많이 간다. 따라서 다양한 기능을 가진 표를 빠르게 구현하기 위해서 초기버전에서는 ag grid 라는 오픈소스를 활용하여 개발했다. 스크롤, 커스터마이징, 필터, 디자인 등 여러 한계가 있어서 나중에는 결국 자체 개발로 넘어가야했지만 오픈소스를 활용하여 빠르게 런칭한 덕분에 유저의 피드백을 빠르게 듣는데 큰 도움이 되었다.

  

2-2 관리자용 어드민 (Django admin)

실제 서비스를 출시하기 위해서는 유저가 사용하는 화면뿐만 아니라 관리자가 사용할 수 있는 최소의 어드민 또한 필요하다. 하지만 유저기능을 개발하기도 정신이 없기에 어드민은 개발할 시간은 항상 부족하기 나름이다. 그래서 시작을 개발할 때는 Django(백엔드 프레임워크)에 내장 되어있는 장고 어드민을 적극 사용했다. 장고 어드민의 기본 세팅으로 해결이 안되는 기능들은 추가 개발을 하여 필요할때마다 하나씩 추가해나갔다.

방법 3. 만들어진 프로그램을 그대로 쓴다. (노션, 구글폼,이메일)

3-1 노션 활용 (랜딩페이지 필요할 때)

시작에서는 기업서비스나 FAQ, 채용후기 등 랜딩페이지가 필요할 때 노션을 활용했다. 보통 랜딩페이지 같은 경우 운영에 따라 자주 바뀌는 경우가 많은데 그럴 때마다 새로 디자인해서 개발하는 것보다 노션을 활용해서 바로바로 수정할 수 있게 했다. 요즘 많은 사람들이 노션 쓰는 것에 익숙하므로 관리도 편하고 디자인도 자연스럽다는 장점이 있다. 또한 소개자료는 특히 디자인이 중요하기 마련인데, 노션을 사용하니 디자이너가 필요할 때마다 바로 바로 확인하고 수정해줄 수 있어서 좋았다.

노션이나 다른 외부 서비스들을 이용할 때 한 가지 주의할 점은 새 탭을 어디에서 열지 신중히 결정해야한다는 것이다. 수 차례 유저 테스팅을 하면서 옆에서 시작을 사용하는 것을 직접 지켜봤었는데 PC의 경우 새 탭에서 띄우는 것을 훨씬 편하게 생각했지만, 모바일의 경우 새 탭으로 열면 다시 전 탭으로 돌아가야해서 엄청 불편해했다. 따라서 현재 외부서비스 대부분은 PC는 새 탭, 모바일은 현재 탭에 띄우도록 수정했다. 사소하지만 이를 참고하면 더 좋은 UX를 만드는데 도움이 될 것이다.

3-2 구글 폼 활용 (폼이 필요할 때)

시작에서 기업을 등록받거나 인재풀에 유저를 등록받을 때와 같이 정보를 입력받아야 할 일이 있을 경우 대부분 구글폼을 사용했다. 스타트업 특성상 받는 데이터가 달라질 때도 많고, 그 데이터를 가지고 활용해야할 상황도 많다. 만약 개발로 되어있다면, 폼을 수정하거나 데이터가 필요할 때마다 개발자에게 요청을 해야한다 (다른 추가 툴을 쓰지 않는다면). 하지만 구글 폼을 사용하면 하면 개발자가 아닌 팀원도 바로 필요할때마다 폼을 만들 수 있고, 수정이 필요하더라도 바로 바로 수정 및 추가를 할 수 있게 되어 효율적으로 일할 수 있다.

단점은 개발하는 것에 비해 자동화가 덜 된다는 것인데 그 점을 보완하기 위해 손이 많이가거나 복잡한 프로세스가 필요한 부분은 개발로 자동화 시키고, 시간이 별로 안걸리는 부분은 수기로 직접 입력하는 식으로 나누어서 사용했다. 그리고 폼 등록시에는 웹 훅이라는 것을 이용하여 자동으로 팀 메신저로 알람을 오게하여 놓치는 일이 없도록 알림 기능도 추가했다.

3-3 구글 스프레드시트 활용 (리스트를 보여주고 싶을 때)

시작에서는 인재풀이라는 서비스가 있다. 디자이너를 찾고 있는 기업들을 위해 희망연봉, 관심사, 나이, 학교, 전공,사용가능한 툴 등 여러 디자이너 정보들을 한눈에 보여주고 원하는 디자이너와의 커피챗을 잡아주는 서비스이다.

이러한 인재풀 서비스의 구현을 위해 개발 대신 구글 스프레드시트를 사용했다. 처음에는 자체 개발이나 에어테이블 등 다양한 옵션들을 고려해봤지만, 쉽고 빠르게 만들 수 있다는 점, 누구나 쓰기 편하다는 점, 구글 폼 및 노션과 연결되어 사용할 수 있다는 점 때문에 구글 스프레드시트가 가장 적합하다는 결정을 내렸다. 유저든, 운영팀이든 누구든 추가 학습없이 사용할 수 있다는 것도 큰 장점이고 그 덕분에 여태 정말 잘 사용하고 있다.

인재풀에 들일 디자인,개발시간을 아낀 덕분에 신규 디자이너 유치, 데이터 추가 등 실제 가치를 전달하는데 집중할 수 있었고 그 결과 이미 여러 기업들이 구매해서 잘 쓰고 있는 서비스를 만들 수 있었다. 인재풀은 나중에 개발이 필요해질때 개발버전으로 전환할 예정이다.

3-4 오픈카톡방 활용 (푸시알림 기능 또는 커뮤니티 기능이 필요할 때)

보통 대부분의 서비스에서는 앱푸시 알람을 통해서 새 소식을 알려주지만 시작에서는 카카오톡으로 앱 푸시 알림을 대체하고 있다. 시작은 약 650명정도의 디자이너가 보고 있는 공고알림방 오픈카톡방을 운영하고 있는데, 매일 아침 카카오톡 오픈채팅방을 통해 유저들에게 새로운 공고들을 알려주고 있다.

이 카톡방을 통해서 사이트로 주기적으로 유입되는 트래픽이 상당히 많은데, 한 유저는 크롬보다 카톡이 더 편해 이걸로 더 많이 들어온다는 피드백을 남기기도 했다. 채용알림 공고방 이외에도 약 300명정도의 디자이너가 자유롭게 디자인 얘기를 나누는 자유채팅방도 있다.

이렇게 시작에서는 카카오톡을 이용하여 앱과 커뮤니티 개발 없이도 앱푸시와 커뮤니티 기능을 대체할 수 있었다.

방법 4. 개발이 필요하다면 최소화시켜서 만든다 (자체 개발)

4-1 지원하기 기능 간소화.

아무리 여러 서비스들을 적극적으로 잘 이용하더라도 가끔은 다른 서비스로 대체가 불가능한 경우가 있다. 이런 경우에는 해당 기능을 최대한 간소화해서 개발하려고 노력하고 있다. 지원하기 기능이 그 대표적인 예시 중 하나이다.

처음 플랫폼을 출시 했을 때부터 지원하기 기능을 개발했던 것은 아니다. 처음에는 구글폼으로 대체하여 출시 했었다. 하지만 구글폼을 이용하니 폼 입력시 지원할 기업의 공고 url을 다시 입력해야하는 큰 불편점이 있었다. 보는 건 편해서 시작에서 보지만 지원은 너무 불편해서 다른 곳에서 한다는 유저 피드백까지 나올 정도였다. 따라서 이 문제에 대한 빠른 보완이 필요했다.

하지만 한 가지 큰 문제가 있었으니, 지원하기를 개발하려면 생각보다 많은 시간이 필요하다는 문제가 있었다. “지원하기” 를 위해서는 로그인, 유저 마이페이지, 기업 어드민 등 생각보다 여러 페이지의 추가가 필요했다.

• 유저는 내가 어디를 지원했는지 볼 수 있는 화면이 있어야 했고,

• 서류 합격인지 불합격인지, 면접은 어떻게보는지 등 현황에 대해 볼 수 있는 화면도 필요했고,

• 기업은 누가 지원했는지 볼 수 있는 화면, 그리고 합격처리를 할 수 있는 프로세스 등 다양하고 복잡한 기획들이 추가적으로 필요했다.

그래서 모든 걸 기획하고 개발하는 대신 ODD스러운 방법을 택했다. 로그인 없이도 한번에 그냥 바로 지원할 수 있도록 지원하기 절차를 엄청 간소화시켜 출시한 것이다. 모든 플로우를 최소화하여 한 번의 버튼 클릭과 폼 입력만 남겨놓았다. 그렇게 간소화한 덕분에 유저의 피드백을 들은지 이틀 만에 지원하기 기능을 바로 출시할 수 있었다. 개발 시간이 반의 반의 반으로 줄었을 뿐더러, UX적으로도 다른 곳과 다르게 한번에 지원할 수 있어서 좋다는 유저의 피드백도 들을 수 있었다.

위와 같은 다양한 방법들로 우리 팀은 단 2주만에 MVP 플랫폼을 런칭할 수 있었다. 위에 있는 많은 기능들은 사실 첫 2주 동안에 나왔다기보다는 오랜 기간에 걸쳐 여러번의 피드백을 받아 조금씩 보완하여 나온 결과물이다. 처음부터 완성도가 높았던 것은 아니지만 항상 전체 업무양 자체를 줄이는 ODD 정신을 토대로 접근한 덕분에 많은 기능들을 비교적 빠르게 출시할 수 있었다. 그리고 그런 덕분에 기존에 “우리가 중요하게 생각하는 기능”이 아닌 “유저들이 중요하게 생각하는 기능”들에 집중하여 개선할 수 있었다.

9. 그래서 좋은 프로덕트, 어떻게 빨리 만드는 건데

그래서 이제 슬슬 글의 시작에서 던졌던 질문,

어떻게 하면 유저가 좋아하는 제품을 빨리 만들 수 있을까?

에 대한 나의 생각을 얘기해보고자 한다.

시작에서 프로덕트를 만들면서, 그리고 여러 가설들을 테스트하면서 내가 얻게 된 교훈이 하나 있다.

답은 항상 유저에게 있다는 것이다.

처음에는 유저들이 로그인이 있는 지원기능을 원할 것이라고 생각했었지만, 막상 만들고보니 로그인이 없는 지원기능을 더 좋아했다. 처음에는 유저들이 표를 커스터마이징하는 기능을 원할 것이라고 생각했었지만, 막상 만들고보니 경력연차, 사수여부 등 데이터들이 추가되는 것을 더 좋아했다. 유저들은 생각보다 사소한 것들을 좋아했다. 조금 더 정확히 말하자면 나에게는 사소해보였던 것들을 유저들은 더 좋아했다.

이제는 우리 유저에 대해 더 알게되면서 전에는 사소해보였던 것들이 더 이상 그렇지 않아 보이게 되었다. 그래서 이제 새로운 기능을 기획할 때면 전보다는 더 유저의 마음을 잘 맞출 수 있게 되었다. 하지만 그럼에도 불구하고 여전히 모르는 부분들도 있고 여전히 사소해보이는 것들도 있다.

그렇기에 좋은 프로덕트를 빨리 만들기 위해서는 가볍고 빠르게 출시해서 자꾸 유저의 “사소함”을 찾아가는 수 밖에 없는 듯 하다. 좋은 프로덕트를 만든다는 것은 누구에겐 사소해보이지만 누구에게는 그렇지 않은 것들을 찾아, 더 이상 사소하지 않게 만들어주는 일인 것 같다. 그래서 결국 좋은 프로덕트를 빨리 만들기 위해 가장 중요한 것은 그런 사소한 점을 알아내려는 의지와 그리고 그것을 사소하지 않게 만들어줄 수 있는 속도라는 생각이 든다.

그래서 마지막으로 “어떻게 하면 유저가 좋아하는 제품을 빨리 만들 수 있을까?” 라는 쉽지 않은 이 질문에 나는 이런 답을 내놓아 보고자 한다.

“무엇이든 일단 가볍게 만들고, 그걸 유저가 좋아하는 제품으로 만들어나간다.”