성장하는 사람들을 위한 콘텐츠 파킹랏 | 쿠키파킹 Cookieparking 기획 과정과 PM을 하며 배운 것

쿠키파킹 서비스를 런칭했어요!

쿠키파킹 | 성장하는 사람들의 가장 간편한 콘텐츠 파킹랏

*크롬 웹스토어에서 쿠키파킹 크롬익스텐션으로 만나볼 수 있습니다.
www.cookieparking.com/landing

 

---

 

목차 

1. 서론
2. '쿠키파킹' 서비스 기획 배경과 기획 의도
3. 쿠키파킹의 '핵심 기능' 소개
4. 팀빌딩을 위한 기획문서와 소통
5. 랜딩 페이지 배포와 성과 
6. 프로젝트 매니징을 하며 배운 것 

---

1. 12명이 함께한 프로젝트, '쿠키파킹' 

 

 

 

 

 

 

혼자서 기획했던 서비스를 실제로 구현하기 위해, 지난 12월 나는 3-5주의 기간 동안 나를 제외하고 기획자 1명, 디자이너 3명, 서버 개발자 2명, 웹 프론트엔드 개발자 5명이 함께하는 12명의 팀을 매니징했다. 지난 10월달 부터 세 달간은 홀로 서비스를 기획하고 디벨롭하는 시기를 거쳐, 베타 서비스 런칭을 앞두고 있다. 일단 프로젝트가 일차적으로 일단락되어, 잠시 처음으로 PM이 되어 프로덕트를 매니징한 지금까지의 회고를 진행하고자 한다. 좀더 자세한 서비스 맥락과 브랜드 스토리는 하단의 노션 페이지에서 살펴볼 수 있다. 

쿠키파킹 서비스 Notion Page : www.notion.so/a5f04ad03fe14940801520d1d2bd20ae

 

2. 서비스 기획 배경과 기획 의도

 

 

 

쿠키파킹이 주목한 Pain point @Cooieparking SOPT 데모데이 발표 장표 일부

 

 

 

우리가 기획한 서비스명은 '쿠키파킹'이며, 평소 수십개의 카톡내게보내기로, 정돈되지 않은 웹브라우저창 / 웹 북마크에 저장해두고는 매번 정작 필요할 때 찾기 어렵다는 'pain point'를 개선하고자 했다. 단순하게 말해, 쿠키파킹은 크롬익스텐션으로 구성된 북마크 서비스다. 

 

 

 

 

최종 서비스 발표 장표 일부 / @Cookieparking

 

 

 

성장에 대한 욕심이 많은 사람들이라면, 우리를 둘러싼 수많은 콘텐츠들 가운데 소화해야할 양질의 정보가 참 많다는 것에 공감할 것이다. 매번 그 속에서 인사이트를 잘 관리하고 소화하기란 쉬운 일이 아니다. 120명 이상의 2030에게 직접 설문조사를 하고, 심층 인터뷰를 진행한 결과, 한 두명만의 문제가 아니라는 것을 파악했다. 

 

 

 

최종 서비스 발표 장표 일부 / @Cookieparking

 

 

 

노션이나 블로깅을 하는 등 잘 정리/기록하는 방법이 있지만, 우리 서비스 타깃은 그러한 방법이 몹시 귀찮다고 여기는 사용자다. 애초에 '여기저기 분산되어 있는 콘텐츠들을 매번 한 곳에 모으는게 번거롭고', '분류해서 정리하자니 귀찮고', '쌓이면 이전 기록이 눈에 잘 안 띄어 찾기 귀찮아지는' 그런 사용자들을 타깃으로 한다. 그래서 우리의 서비스는 '분산된 걸 모아주고', '분류를 편하게 해주고', '한눈에 잘 안 보이던 것들을 펼쳐서 보여주는' 기능을 제공한다. 나는 초기에 서비스의 핵심 키워드를 'Light', 'Closer', 'Joyful'로 잡았다. 사람들이 거부감 없이 자주 활용할 수 있도록 부담감을 줄여주고, 가까이에서 즐겁게 방문할 수 있도록 하는 것이다. 이러한 포인트들을 디자인적으로도 잘 풀어내기 위해 고민하다 보니, '쿠키파킹'이라는 네이밍이라든지 '재치있는 캐릭터 브랜딩'이 나올 수 있었다. 

 

 

 

기획/디자인 팀빌딩 이후 정리한 제1퍼소나 변인 @Deep Wide Studio 

 

 

 

 

---

 

3. '쿠키파킹'의 핵심기능 소개 

구현된 기능은 다음과 같다. 현재 크롬 웹스토어 승인 대기중이다. 아마 앞으로 2주 정도간, 간단한 QA를 거쳐 디테일한 수정사항 등을 보완해 재 업데이트 과정을 거칠 예정이다.

1) 크롬 익스텐션 - 파비콘 클릭으로, 손쉬운 저장

 

 

 

2) 저장된 콘텐츠는 쿠키파킹 웹페이지에서 카드형태로  한눈에 모아보기

 

 

 

 

3) 카드별, 손쉬운 디렉토리 분류

 

 

 

잘 분류된 디렉토리는, 간단한 링크공유로 누구에게나 공유 가능하다. 

 

4) 새탭에서 열어보는 쿠키 파킹랏 

 

 

 

그동안 모아놓은 콘텐츠를, 새탭을 열때마다 확인할 수 있다. 크롬익스텐션 뉴탭 구현을 통해, 새탭을 열때마다 파킹랏이 열리도록 구현해놨다. 저장해둔 콘텐츠까지 가는 뎁스를 줄여, 접근성을 높이고 놓치는 콘텐츠들이 없도록 돕기 위함이다.

 

---

4. Branding

 

 

 

Cookieparking 로고 모션 @Cookieparking

Cookieparking Deisign Keyword

 

 

 

디자인팀과 함께 브랜딩에 대한 숱한 논의 끝에 우리는 이와 같은 쿠키파킹의 디자인 컨셉을 잡을 수 있었다. 나는 기존의 북마크 서비스들의 한계는, "딱딱하고 재미없는 것"도 한 몫 한다고 생각했다. 북마크 서비스를 포함한 정보 관리, 정리를 위한 생산성 툴이 가진 특유의 '깔끔하고 딱딱하고 정리된 듯한' 그런 형상을 벗어나고 싶었다. 매번 방문하는 그 과정과 여정이 즐겁고 재미있어야 재방문율이 높을 수 있다고 생각했다.사용자 인터뷰를 하면서, 아웃스탠딩/북저널리즘/퍼블리와 같은 유료 콘텐츠 플랫폼에 돈을 내고서도 좀처럼 잘 안 들어가게 되는 이유에서 힌트를 얻었었다. '해당 플랫폼에 들어가면 양질의 정보가 있다는 사실은 알고 있지만, 왠지 각잡고 봐야할 것 같은 부담이 느껴져서 자주 안들어가게 된다'는 이야기를 들었다. 반면, 페이스북에서도 양질의 콘텐츠를 제공해주는 그룹/ 페이지/ 사람을 팔로우 해두는데, 페북은 들어가서 슥슥 읽으면 돼서 부담이 없어 자주 들어가게 된다는 의견을 받았다. 쿠키파킹은 '안 그래도 읽을 게 너무 많은' 사용자에게, 다시 방문해서 글을 읽는 과정이 가볍고 즐거운 경험을 제공해야 했다. 즉, '가볍고', '단순하면서도', '재미있어야 했다'. 컴퓨터 속 쿠키와 파킹랏에 파킹하는 행위에서 모티브를 따온 것도, '두리번'이라는 브랜드 캐릭터 미어캣을 사용하게 된 것도 바로 이런 문제의식에서 출발한 것이다. 

 

 

 

브랜딩/디자인 발표 장표 일부 @Cookieparking

 

 

 

디자이너와 함께 화면공유로 레퍼런스를 찾다가, 하찮은 그림체의 캐릭터 레퍼런스를 보고 '이거다!' 하는 모먼트가 있었다. 손으로 낙서하듯 서비스도 쉽고 편하게 방문할 수 있도록 친근한 캐릭터를 활용하기로 했다.

열정 넘치는 우리 팀 디자이너들의 열일 덕분에 이처럼 귀엽고 매력적인 캐릭터가 탄생할 수 있었다. 콘텐츠의 홍수 속에서 '두리번 두리번' 영감을 찾는 미어캣이 쿠키파킹의 마스코트가 되었다. 

 

 

 

 

 

 

 

 

 

 

Cookieparking의 치명적인 로딩 모션 @Cookieparking

 

 

 

 

4. 팀빌딩을 위한 기획 문서와 소통

(1) 기획자/디자이너와의 소통을 위한 최초 기획 문서 1

내가 잘했다고 생각하는 점 중의 하나는 바로 '기록'이다. 최초에 기획/ 디자인/개발자 팀빌딩을 위해, 내가 기획했던 서비스를 소개하는 Notion Page를 공유했었는데, 굉장히 상세하게 기록해뒀다. 세달 정도에 걸쳐서 Pain point 분석, 고객 인터뷰, 솔루션을 위한 모든 고민을 최대한 문서화하여 모든 팀원들과 공유할 수 있도록 했다. 서비스가 탄생하기까지 고민의 흔적, IA, Wireframe을 포함한 서비스 소개, 그리고 지향하는 팀원의 모습 등을 담아 팀빌딩을 준비했다. 굉장히 꼼꼼히 기록하고, 공유했는데 이점 덕분에, 팀빌딩 이후에도 새로운 팀원들이 서비스에 대한 공감대와 이해도를 높은 수준으로 가져갈 수 있었다. 

 

 

팀빌딩 이전, 혼자 고민하고 기획했던 서비스 관련 사전 공유 자료 @Deep Wide Studio

 

 

 

 

(2) 개발자/디자이너와의 소통을 위한 기획문서 2

구체적인 와프나 기능에 대한 틀이 이미 나와있었기 때문에, 개발자 팀빌딩 당시 크롬 익스텐션의 초기 설정을 미리 구현해온 개발자 팀원도 있었다. 개발자 팀빌딩 직전에는, 기능명세서까지 작성해서 Figma에 와이어프레임/ 워크플로우/ 기능명세를 한번에 정리해두었다. 스토리보드 문서를 따로 만들려고 하다가, 우리같은 단기간에 성과를 뽑아내는 작은 프로젝트에는 불필요한 작업이라는 생각이 들었다. 그래서 All-in-one문서로서 피그마에서 한방에 해결하니 간편했다.

 

 

 

와프/ 워크플로우/ 기능명세/ Notification을 한번에 담은 Figma 일부 @Cookieparking

 

 

 

개발자 팀빌딩 이후 첫주에 GUI가 포함된 디자인 뷰가 완전히 구현되기 전까지, 개발자들이 위의 피그마 뷰를 보며 필요한 기능에 대한 공부를 해두며 밑작업을 진행했다. 크롬 익스텐션은 국내 개발 자료가 많지 않기 때문에, 웹 개발자들에게 도전적인 서비스였다. 팀빌딩 이후에도, 크롬 익스텐션의 기본적인 세팅 관련된 공부를 하는데 우리 팀 웹개발자들의 시간을 많이 할애했다. 특히 쿠키파킹은 팝업 익스텐션과 뉴탭 익스텐션을 동시에 필요로 하는 서비스이기 때문에, 이것을 구현하는 데 다소 까다로운 작업과정이 있었다. 처음에 두개의 익스텐션 서비스로 분리해서 만들어야하는가 싶었는데, 웹개발자들의 노력 덕에 하나의 익스텐션 서비스로도 가능한 형태로 구현될 수 있었다. 

 

 

이후, 디자이너 - 프론트엔드 개발자들 간의 소통도 Figma 상에서 바로바로 이루어졌다. 디자이너들이 GUI 작업물을 figma export 페이지에 코멘트와 함께 넘겨주면, 웹 개발자들이 바로 figma export페이지에서 해당 뷰를 보며 필요한 것들 export해서 작업하는 식으로 진행했다. Slack에 새로운 업데이트가 있을 때마다, 디자인 채널/ 웹 채널에 노티를 주거나, 이슈가 있을 때마다 바로바로 슬랙에서 논의를 진행하는 식이었다. 그리고 파트별로 진행상황은 노션의 전체 칸반보드를 이용해 상호 확인할 수 있도록 했다. 우리는 거의 초기 기획에서 벗어나는 바가 많지 않았기 때문에 큰 혼란 없이 무탈히 진행될 수 있었다. 

 

 

 

쿠키파킹 FIgma 익스포트 페이지 일부; 디자이너 - 웹개발자 간 뷰 전달/소통 방식 @Cookieparking

 

 

 

---

 

5. 광고 마케팅 & 랜딩 페이지 배포와 성과 

Facebook/Instagram Marketing

 

 

 

페이스북/인스타그램 광고 @Deep Wide Studio

 

 

 

5주차에 가서는 능숙하지는 않았으나, FB, IG 광고까지 실제로 돌려보았다. 사실 처음 해보는 거다 보니, 광고세트에 소재를 2개씩 넣어서 적은 금액을 돌렸더니 큰 효율은 나지 않았다. 마지막에 가장 그나마 효율 좋았던 소재 1개에 랜딩페이지를 연결해 광고를 태웠더니 개중에는 도달과 노출이 높았다. 

 

deep-wide-studio.tistory.com/214

페이스북/인스타그램 광고 초심자를 위한 초기 세팅 일지

 

차라리 우리가 가설로 세운 유저 타깃이 집중되어 있는 페이스북 그룹에 서비스에 대한 소개를 해보고 반응을 확인하는 편이 더 낫겠다고 생각했다. 개발자 유저들이 많이 모인 '생활코딩' 페이스북 그룹, IT 기획자/UX기획자가 많이 모여있는 '힙한 서비스들의 비밀' 페이스북 그룹에 서비스 소개를 올렸는데 반응이 생각보다 엄청났다. 

 

 

 

페이스북 페이지에 올린 쿠키파킹 서비스 소개 글 반응 @Cookieparking

 

 

랜딩페이지로 수집된 이메일 수, 482명

랜딩페이지 마지막 화면 @Cookieparking

랜딩페이지로 수집한 이메일 수집 기록 *보안상 이메일 은 제외하고 제출시간 기록 일부를 캡쳐해왔다. @Cookieparking

 

 

 

14일부터, 19일인 오늘까지 꾸준히 쌓이더니 랜딩페이지로만 출시 알림을 요청한 449명의 이메일이 쌓였다. 이전에 서비스 설문조사 등을 통해 출시 알림 사전 수집했던 이메일 33명까지 합치면, 거의 500명에 달하는 숫자였다. 이틀만에 400명이 넘는 고객의 이메일을 수집했다는 것은 꽤나 고무적인 성과라고 생각된다. 

Landing Page 보러가기: www.official.cookieparking.com/

HOME | cookieparking

---

6. 프로젝트 매니징을 하며 배운 것 

1. 기능 구현 타임라인은 어떻게 계획하면 좋을까? 

처음에는 기능별로 타이트하게 버전을 구분하고, 데드라인을 설정하는 게 어떨까 생각했었다. 그러나 특히 우리처럼 개발 주니어들로 구성되어 있을 경우, 새로운 기능이나 이슈가 생겼을 때 해결하는데 얼마나 걸릴지 예상소요시간이 파악되지 않아서 이러한 방식이 딱 들어맞지는 않는다는 것을 이해했다. 숙련된 개발자와 기획자가 되는 기준은, 해당 작업에 얼마만큼의 리소스가 쓰이고 얼마나 시간이 소요될지를 파악할 수 있다는 점인 것 같다.

 

버전별로 모든 기능을 나누고, 촘촘히 데드라인을 세우는 것은 사실상 우리 수준에서는 무의미했다. 촘촘하게 계획을 한들, 개발자들의 역량에 따라 그것이 얼마만에 가능한지가 사전에 파악되기 어려웠기 때문이다. 예를 들어, 우리 서비스 중에 파킹한 콘텐츠를 디렉토리에 분류하는 기능이 있었다.

 

[우선순위 1순위] 최소 구현되어야 하는 기능은, 콘텐츠 카드에 마우스를 호버했을 때, 그동안 생성해뒀던 모든 디렉토리 리스트를 보여주는 것이었다.

[우선순위 2순위]나아가 가능하다면, 디렉토리 리스트를 보여줄 때, '최근에 사용 기록이 있는 디렉토리'를 먼저 보여주고, 그 밑에 '알파벳 순으로 모든 디렉토리 명을 노출시키는' 기능을 원했다.

[우선순위 3순위] 디렉토리 생성하기 버튼이 있어서, 해당 리스트 뷰에서 바로 새로운 디렉토리를 생성할 수 있도록 하는 기능이 추가되었으면 했다. 

처음에는 '간편한 디렉토리 분류 기능'이라는 동일한 카테고리 안에 묶인 촘촘한 이 우선순위별 기능들을 버전 1, 2, 3로 나누고, 데드라인을 정해놓고자 했었다. 그러나, 개발자들이 실제 개발을 해보면서 한번에 진행하기 편한 기능이 있을 수도 있고, 막상 해보니 빨리 구현하기 어려울 수도 있다는 것을 알게 되었다. 따라서, '간편한 디렉토리 분류 기능'이라는 큰 틀만 마감 일정을 정해두고, 그 안에서 우선순위 1순위는 기본으로 가져가되, 나머지는 상황에 따라 유동적으로 개발/구현하는 방식을 택했다. 오히려 개발자들이 자유롭게 고민하고 시도해보며, 애초에 후순위였던 기능들까지도 커버될 수 있었다. 일정을 큼직큼직하게 나누어 그 안에서 우선순위만 명확하게 합의해둬도 충분하다는 것을 배웠다.

 

2. 파트 간 작업의 오차 범위를 줄이기 위한 왕도는?

1) 없다. 오직 피나는 무한 소통 뿐.

프로젝트가 진행되며 GUI 디자인이 개선되는 과정 중에 개발팀과의 소통이 굉장히 많이 필요하다는 것을 몸소 경험했다. 특히 중간에서 PM의 역할이 중요했다. 파트별로 작업하는 것들의 오차 범위를 줄이기 위해서는 자잘자잘하게 계속 누군가가 주도적으로 '소통'을 많이 하는 것이 정말 중요하다는 것을 다시금 깨달았다. 

 

일례로, 디렉토리 리스트 뷰에서 gui 디자인 파트가 오렌지색 쩜을 하나 추가하는 일이었는데, 웹파트에서는 해당 기능을 구현하기 위해 5시간을 사용했었다. 뉴비 개발자 친구 혼자서 새벽동안 끙끙 고민하며 구현을 했다고 한다. 그런데, 이같은 상황을 모르는 디자인파트에서 어떤 이유로 나중에 해당 뷰에서 바로 그 문제의 '쩜'을 다시 제거할 뻔한 상황이 있었다. 당시 내가 개발자와 1:1 면담을 진행하며, 최초 와프에는 없었는데 갑자기 생긴 "쩜"을 구현하기 위해 5시간 밤새서 적용했다는 것을 사전에 알게 되었다. 때문에, 디자인 파트 회의에 참여했을 때 최대한 그 쩜을 살리를 방향으로 조절가능했다. 모든 파트의 회의에 가능하면 거의 참여해야겠다는 생각을 이때 했다. 디자인에서는 개발의 상황을 잘 모르고, 개발도 디자인 파트의 상황을 100% 이해하기 어렵기 때문에 서로의 이해관계와 리소스 분배 등을 잘 파악하고 소통을 중재해줄 누군가가 필요하다는 것을 느꼈다. 그것이 바로 PM의 역할이 아닐까 싶었다.

당시, 디자인 파트와 함께 더 본격적으로 해당 뷰에 대한 gui 개선을 진행하기 전에, Gather사무실에서 웹파트에게 다같이 찾아갔다. 일단 해당 뷰 개발 진행상황을 파악하고자 했다. 만약에 우리가 변경을 생각하는 부분의 개발이 너무 많이 진행된 상황이라면, 개선안을 제안하지 말자고 디자인 파트와는 이야기를 해두었다.

 

디자이너들과 함께 웹파트로 가서 직접 화면공유를 받으며, 구현이 어디까지 진행되었는지 시연해보고, 지금까지 리소스가 얼마나 투입되었는지 등등을 확인했다. 디자이너들과 회의하며 변경하고 싶었던 사항은 디렉토리 리스트 뷰에서 1) 검색기능을 제거한다, 2) 하단에 디렉토리 추가 버튼의 기능을 모달창 띄우기에서 바로 입력하는 형태로 변경한다- 였다. (*하단 이미지 참조) 

 

 

디렉토리 리스트 뷰 @Cookieparking

 

 

당시 웹파트의 구현 현황을 보니, 검색기능은 외관상으로만 만들어두고 뒷단의 기능적인 부분은 구현에 들어가지 않은 상태였다. 디렉토리 추가 기능 역시 마찬가지였다. 그리고 당시, 변동사항이 없는 부분을 개발 진행중이었다. 우리는 다행이다 싶어, 슬쩍 개선안에 대한 의견을 구했다. 그랬더니 검색 뷰가 빠지는게 훨씬 쉬워진다며 좋아했고, 디렉토리 추가 부분이 바뀌는건 큰 문제가 아니라는 피드백을 받았다. 만약에 웹파트에서 해당 기능이나 뷰에 투입한 리소스를 인지하지 못하고 개선안을 가져갔다면, 안좋은 감정이 생길 수도 있었을텐데 다행이라는 생각이 들었다.

그런데 예상치 못하게, 밤에 전체 공유 시간에 디렉토리 검색기능이 빠진 것을 알고 서버 파트가 살짝 당황을 했었다. 디렉토리 검색 기능을 서버 쪽에서 구현을 해놨었는데, 이렇게 변경되면 필요 없게 되는 것이기 때문이다. 다행히, 다른 뷰의 Gui를 확인해보니, 만들어뒀던 디렉토리 검색 서버부분을 그대로 사용하면 되는 부분이 있어서, 결론적으로는 그 누구의 감정이 상하는 일 없이 잘 해결되었다. 이번에는 운이 좋았으나, 변경 이슈가 있을때 이게 서버 단에서, 그리고 웹 단에서 어떤 파장을 일으킬지 더 잘 이해할 수 있도록 공부가 역시 더 필요하다는 생각을 하게 되었다. 바로바로 이해하는 역량이 부족하다면, 변경에 대한 니즈가 있을 때마다, 그때그때 모든 파트와 빠르게 소통하고 피드백을 얻는 것을 두려워하지 말아야 한다는 것을 배웠다. 또한 PM이 파트별로 얼마나 어떤 리소스를 투입하고 있는지를 파악하고, 그 사이에서 잘 중재/조절해줘야 한다는 것을 배웠다. 각 파트는 자기 작업을 일단 하는게 급하기 때문에, 피엠이 그들에게 필요한 커뮤니케이션을 더 많이 도맡아서 해줄 필요가 있다고 느꼈다. 물론 디자이너와 개발자가 서로 그때그때 좀더 많이 소통하면 더 좋긴 한데, 아직 그런 것들이 서로 좀 익숙하지 않은 부분도 있고 전면 온라인 상이라는 한계도 있어서, PM이 주도적으로 파트 간 소통의 장을 만들고, 같이 가서 질문하고 이런 문화를 잘 정착시키면 좋겠다는 생각을 했다.

 

 

2) 일단 최대한 각자의 입장을 잘 들어보고, 파트별 이해관계를 잘 파악하자.

크롬 익스텐션에서, 팝업익스텐션의 R값을 넣느냐 마느냐가 injection을 위해 jQuery를 쓰느냐, 리액트를 사용하느냐 차이의 문제가 되었다. 디자인 파트에서는 라운딩 값이 들어가야, 애초에 디자인했던 대로 미감적으로 만족스럽게 나올 수 있었으나, 개발 파트에서는 라운딩 값 하나 때문에 추가적으로 진행해야하는 사항이 너무 많았다. 익스텐션이라는 특수성 때문에 발생한 예상치 못한 문제였다. 파트별 입장차이, 이해관계가 다르기 때문에, 이런 상황에는 PM이 기획단에서의 중요도와 파트별 리소스 투입을 감안해서 결정을 내려줄 필요가 있는 부분이었다. 이럴 땐 빠르게 치고 넘어가는 것이 중요한 것 같다. 라운딩이 들어가지 않으면 아쉽긴 하지만, 기능 구현에는 문제가 없기 때문에 아쉽지만 일단 베타 버전에서는 포기하자는 결정을 내리고 빠르게 넘어갔다. 

 

 

3. MVP(Minimun Viable Product, 최소 기능 제품) 를 MVP 답게

단순해 보여도, 개발자들은 해당 기능 구현을 위해 밤새 공부하고 있을 가능성이 높다. 갑자기 새로운 기능이 추가되거나, 있던 기능을 제거하는 일은 개발자에게 뒷골 땡기는 일이 된다. 우리 프로젝트에서는 비교적 잘 지켜진 부분이었는데, 갑자기 기능이 추가되거나 확장의 충동이 일 때마다 두 가지 장치가 있었다. 첫째, '군더더기 없는 유저 시나리오 한바퀴를 돌 수 있는' 기능만 구현한다는 점을 늘 염두하고 있었다. 개발자 투입 후 3주라는 시간 밖에 없었기 때문이기도 했다. '이런 기능이 추가되는 거 어때?'라는 의견이 나올 때면, 항상 어디선가 누군가가 '잠깐, 그런데 그거 없다고 유저 시나리오 한 바퀴 도는데 문제 있어?'라는 질문을 해주었다. 둘째, 우리 개발자들이 3주 안에 안될 것 같은 건 확실하게 어렵다/ 안된다고 사전에 말해줬다. 단호박처럼 단호하게 말해주는 순간들이 있었는데, 팀 차원에서 불필요한 리소스 낭비를 줄일 수 있어서 굉장히 도움이 되었다. 이 두가지가 우리 팀원들의 에너지를 나름 지켜줄 수 있었던 장치였다. 디자인 파트에서는 정말 '최소한'만 남기고, 포기해야하는 부분들이 많아서 아쉬움을 느껴하기도 했다. 

 

 

4. 컴팩트한 회의 지향

전체 회의를 하다보면, A 문제에 대해 이야기하고 있다가 어느샌가 곁가지 딸려나온 A-2, A-3, B, C 라는 문제가 논의되고 있을 가능성이 높다. 우리는 이렇게 무한히 회의가 늘어지고 길어지는 상황을 방지하기 위해 매 회의 전에 사전에 공유할 사항, 질문할 사항들을 리스트 업해서 공유하는 문화를 가졌다. 논의중, 예상치 못한 새로운 이슈가 생겨나면 그 부분은 따로 기록해두고, 정해진 회의 이후에 다시 시간을 잡아 논의하기로 합의했다. 

 

 

 

데일리 전체 미팅 예시 @Cookieparking

 

 

 

5. 1:1 대화의 중요성

기획파트는 반반씩 나눠서 총 1차, 2차에 걸친 1:1 면담을 진행했다. 1:1 면담을 통해, 모든 팀원들과 1:1로 1시간 가량의 대화를 나눌 수 있었다. 파트 내에서 별다른 이슈는 없는지, 고민하고 있는 부분이 있는지, 파트 내/ 파트 간 소통은 잘 되고 있는지 외에도 개별적으로 해당 프로젝트에서 목표로 한 바는 무엇이고 현재 어느정도 달성되고 있다고 체감하고 있는지 등을 들을 수 있는 시간이었다. 

 

 

 

 

면담일지 @cookieparking

 

 

 

확실히 이렇게 1:1로 자리를 마련했을 때 들을 수 있는 이야기들이 있었고, 파악해둘 수 있는 점들이 있었다. 개개인에게 좀더 동기부여를 해줄 수 있다거나, 팀에게 필요한 사항들을 개선할 수 있었다. 막상 면담을 시작하면 시간이 훌쩍 흘러서 1시간이 금방 지나가있는 경험을 했는데, 더욱이 우리는 온라인으로 진행했기때문에 Zoom이나 Gather 상에서 화상 대화로 진행했는데도 그랬다. 조금 귀찮을 수 있지만, 지나고보니 반드시 필요한 작업이며 주기적으로 진행했을 때 그 효과를 더 발휘할 수 있을 것이라 생각된다. 면담 일지를 면담자에게 공유해주어 진척도에 따라 스스로의 변화와 생각의 기록을 확인할 수 있도록 하는 것이 도움이 된다고 한다. 좀더 여유가 된다면, 그 부분까지 잘 반영했으면 좋았겠다 싶다. 

 

쿠키파킹 비대면 협업에 관한 참고글: deep-wide-studio.tistory.com/211

코로나 시대에 서비스 기획자, 디자이너, 개발자 12명이 Notion, Slack, Gather.town, Zoom으로 비대면 협

 

많은 것을 배울 수 있는 기간이었다. 상당히 많은 시간을 올인하며 집중했던 프로젝트였다. 이제 지금까지 배운 것들을 바탕으로, 한 단계 성장할 수 있는 방법을 고민해볼 차례다. 사실 어느정도의 무게를 가지고 지속해야할지 생각이 많다. 지금 나의 넥스트로 향해야할 지점이 무엇인지, 내가 원하고 내게 필요한 다음 단계는 무엇일지 고민중이다. 앱잼이 끝나면 뭔가 뚜렷한 다음 지점이 보일 줄 알았는데, BM 구현 없이는 쿠키파킹도 토이프로젝트에 지나지 않는다는 것을 깨달았다. 처음에는 단지 웹스토어에 등록하고 릴리즈하는 것이 목표였다면, 지금은 '릴리즈 그자체'는 그냥 여기서 멈추는 것과 크게 다르지 않다는 생각을 하게 되었다. 지금까지 안한 것은 아니지만, 쿠키파킹에 누적되는 데이터에 대한 고민, BM에 대한 좀더 구체적인 고민들이 필요하다. 구체적인 기능 정책이나 UX에 대한 고민, 리텐션에 대한 고민 등이 비즈니스의 지속성에 기초하지 않는 한 속 빈 강정같은 느낌이 들었기 때문이다. 이론적으로만 알고 있던 내용을 이렇게 체감하게 된 것도, 여기까지 와보니까 알 수 있게 된 것 같다. 나의 넥스트는 과연 어디에 있을까? 

 

일단은, 팀원 전체가 웹스토어에 등록하고 실제 사용자들이 유입되는 과정을 보고 싶어한다는 점에서, 본격적인 릴리즈를 위한 일정을 다시 조절하고 각자 목표하는 것들을 추합하고 있다. 빠른 시일 내에 릴리즈를 위한 여정에 대한 기록도 진행할 생각이다. 

 

 

 

.

.

.

DEEP WIDE STUDIO

스피노자는 말했습니다. "나는 깊게 파기 위해 넓게 파기 시작했다."

저는 '철학'을 전공하며 인간의 근본에 대해 탐구했고, 

인간의 일상을 기술적으로 혁신하는  'IT 업계'에 관심을 갖게 되었습니다.

깊어지기 위해, 천천히 넓은 물로 나아가는 중입니다. 

인스타그램으로 더 가까이 소통해요!

Instagram @skyblueyekk

Github: https://github.com/yekyung2

Gmail skybluee2014@gmail.com