AngelHack Seoul 2020 엔젤핵 해커톤 4일차_Maker가 되느냐, 어설픈 전략가로 남느냐, 전략적인 Maker가 되느냐

우리의 감정곡선은..

프로젝트 진행시 감정곡선/김진아 멘토님의 디자인씽킹 세션 중 zoom 화면캡쳐

우리의 감정곡선은 정확히 저 Prototyping 단계의 바닥으로 향하고 있었다. 엄밀히 말하면 나의 감정곡선이 그랬던 것 같다. 개괄적인 프로젝트 아이디에이션이 나온 이후, 피크를 찍었던 우리의 감정상태는 구체화 단계로 들어서면서 삐그덕 삐그덕하더니 급하강했다. 

 

사실 우리 프로젝트는 3일차였지만, 월요일을 거의 재낀 상태였다. 최종 제출 마감일은 일요일 자정이었다. 개괄적인 아이디어가 나오기까지 화요일, 수요일 이틀이 걸렸다. 원래는 수요일~목요일까지 기능구조도와 화면설계가 나오는 것이 목표였으나 수요일에 아이디어 구체화에 돌입하면서 약간의 난항을 겪기 시작했다. 나와 산이 멘토링을 받고 와아!했던 것이 바로 수요일 자정즈음이었다. 

 

수요일 자정, 나와 산이 발견한 기획 단에서의 현재 문제와 Task는 다음과 같았다. 

1) 구체적인 고객 Pain point에 대한 확실한 근거 부족과, 그에 따른 구체적인 퍼소나 부재 
->고객 분석&리서치와 그것을 바탕으로 서비스의 누가봐도 명확한 'Value Proposition'세우기
2) Value Proposition을 바탕으로=> 서비스 필요한 기능 & 데이터 정의 및 설계
3) 이에 따른 User Flow & 화면 구성

 

원래 계획은 목요일에, 해당 이슈들을 순차적으로 함께 해결하면 될 것이라 생각했다. 그런데 다음날 회의실에 갔을 때 이미 조제와 준이 뭔가를 만들고 있었다. 일요일이 마감인 상황에서 목요일이 되니, 제작에 착수하지 않으면 아무것도 제출할 수 없겠다는 판단을 한 모양이었다. 입장 코드를 주고 엔터하는 첫 화면의 프론트를 만들고 있었는데, 나는 사실 지금 그게 중요한 부분인건지 이해가 되지 않았다. 우리 서비스 전체 기능과 플로우에서 당시 만들고 있던 그 화면이 critical한 기능은 아니라고 생각했기 때문이다. 아직 합의가 이루어지지 않아서 일어난 일이라고 생각했다. 그래서 나는 빨리 우리서비스에 필요한 기능과 데이터 정의, 이에 따른 화면 구성에 대한 합의가 필요하다고 생각했다.   

 

그러나, 늘 말이 없던 준이 무언가 개발과 제작에 들어가니 즐겁게 이야기하기 시작했고, 조제도 그간 공부해왔던 html과 css를 이용해 프론트 화면을 뚝딱뚝딱 만들어내는 것에 한창 신이나 보였다. 즐거워보이는 두 사람의 분위기를 차마 꺾을 수 없었다. ㅠㅠ 전날 멘토링을 유일하게 같이 들었던 산이 오지 못했기도 했고, 나는 혼자 심각해져 이 상황에서 나는 무얼 해야할까 고민에 빠졌다. 한참 시간이 지난 뒤, 전날 pxd 김민우 디자이너님께 들었던 이야기들을 브리핑할 기회가 생겼다. 오자마자 하고 싶었던 그 내용들을 와르르 쏟아냈다. 그 내용 중에는, 김민우 디자이너님이 말씀해주신 '이 해커톤 기간 동안 개발에 너무 목숨걸지 말고, 여기서 발견한 문제의 논리와 시장성을 더 탄탄하게 구축하는 것의 중요성'을 언급한 부분도 있었다. 나와 산은 이 부분에 일부 동의했다. 당시 우리는 해커톤 이후에도, 여기서 발견한 이 아이디어를 지속적으로 끌고갈 의향이 있는 상황이었다. 그렇다면 더더욱 위에 적어놓은 1)이 명확해야 BM설계도 보다 튼튼해질 수 있다고 생각했다. 개발을 포기하자는 맥락은 아니었다. 큰 그림을 먼저 잘 짜고, 해커톤에서는 그 그림 중 key feature 1-3개에 대해서만 개발을 진행하면 어떨까 하는 생각이었다. 그런데 여기서 의견이 갈렸다. 지금 상황은 '기획과 개발'의 양자택일의 문제가 아니라고 반박하며, 이미 기획에서 화요일, 수요일까지 쓴 상황에서 더 이상 기획에 품을 들일 수 없다는 이야기를 들었다. 이제는 어찌되었든 화면이 나오고 개발에 들어가야만 한다는 것이었다. 

 

당시 나는 제대로 된 1) 없이 2),3)을 했을 때 실효성 있는 서비스가 될 수 있을까? 하는 생각을 했다. 지금 와서 돌이켜보면, 나머지 팀원들은 위에 언급한 1),2),3)중에서 1)에는 이틀을 이미 할애 했으니 한정된 자원을 고려했을 때 일단 2),3)으로 넘어가자는 의미였다. 그날 나는 "1) 없이 2),3)을 하는게 어떤 의미가 있지?"라고 말했던 것 같다. 나의 그 발언이 상당히 큰 파장을 일으켰다. '한정된 자원을 고려해 최종 결과물을 만들어내는 것'의 관점에서 나의 해당 발언은, 팀원들에게 어쩌면 기획만 7일하다가 끝날 수도 있겠다는 불안감을 주었던 것 같다. 당시에 나는 여전히 답답함이 풀리지 않았지만, 다 함께 2),3)으로 넘어가기로 했다.

 

---

 

우리의 아이디에이션은 어디까지 왔나

Angelhack Seoul 2020 online에서 마지막까지 팀빌딩으로 고군분투하던 현장의 모습 일부

우리는 이번 온라인 해커톤처럼 비대면 팀 빌딩을 필요로 하는 상황이 점점 많아지고 있는데, 이때 보다 효율적이고 안정적인 팀 빌딩을 돕는 서비스를 생각했다. 해커톤 내에서도 슬랙을 통해 팀빌딩하는 과정 중에 커뮤니케이션 코스트가 상당히 많이 들고, 운영진 측에서도 그 점에 있어서 어려움을 겪고 있는 모습을 목격할 수 있었기 때문이었다. (대회가 다 끝나고 수상작들을 보며, 우리가 출제의도를 잘못 이해했다는 것을 깨달았지만 아무튼 우리의 서비스는 대략 이런 방향의 주제였다.)

 

'팀빌딩'이라는 핵심 기획 아이디어가 이미 나왔으니 이걸 이제 어떻게 보여줄 것인지에 대한 이야기를 나누게 되었다. 전날 우리가 이야기 나누었던 '매칭 알고리즘 시스템'을 어떻게 구현할 것이냐 하는 토픽으로 넘어왔다. 전날, 우리는 마치 안정적인 결혼 문제 SMP(Stable Marriage Problem)를 해결하기 위해 고안된 매칭 알고리즘처럼, 안정적인 팀을 만들어 줄 수 있는 우리만의 '팀 매칭 알고리즘'을 통해 기술적인 차별성을 주자는 이야기를 했었다. 팀빌딩 계의 듀오 같은 느낌을 상상했다. 설이 알고리즘을 짜는 기술적인 부분을 전담했는데, 매칭의 방식이 상당히 복잡하고 다양했다. 나는 당시에 이 기술적인 관점에 대해 전혀 이해하지 못한 상태였다. '매칭 시스템'이나 '추천 시스템'이나 뭐가 크게 다른지 잘 알지 못했다. 그런 상태에서, 오로지 고객 입장에 빙의해, 짠하고 완벽하게 팀이 매칭&빌딩되어 보여주는 것보다, 내게 적합한 팀&팀원을 추천해주는 것이 더 좋을 것 같다는 이야기를 했다. 그렇게 조제와 나의 몇 마디로, '매칭 알고리즘'에서 '추천 시스템'으로 키 기능이 변경되었다. 나중에 알게 된 사실이었는데, 그 몇 마디가 설이 밤을 꼬박새서 구상한 알고리즘을 날려버린 것이었다. 지금와서 돌이켜보면, 내가 조금만 더 SMP와 매칭 알고리즘에 대해, 우리 서비스의 기술적 차별성이라는 관점에 대해, 앞단의 '문제 인식과 고객정의'만큼 만이라도 공부하고 이해했더라면 아마 다른 대화가 오갈 수 있지 않았을까 싶다. 나는 기술적인 부분에 대해 공부하지 않고, 내가 고민했던 것을 이해해주기만을 기대했던 것 같아 많이 부끄럽고 미안하다. 

 

이렇게 적고 보니, 팀원들이 왜 1)이 아닌 2),3)으로 일단 넘어가서 구체화시키자는 이야기를 했는지도 알 것 같다. 실은 이 날 1)에 대해 무작정 재껴버린 것도 아니었다. 팀원들은 내 의견을 최대한 존중해서 이날, 슬랙에서 애써주시는 엔젤핵의 이수정 매니저님께 간단하게 인터뷰까지 진행했다. 

 

<운영진 인터뷰 질문지>

1. 안녕하세요! 혹시 해커톤 운영진으로서의 경험은 이번이 몇 번째이실까요?
엔젤핵 해커톤에서는 3번째이고, 교육 회사에서 일할때 3~4회 해커톤을 운영해보았고, 외부 개발커뮤니티에서 1번 또 있네요! (대부분 오프라인이었어요)

2. 온라인 해커톤이 오프라인 해커톤을 비교하자면 어떤 점이 새로울까요?
(장점, 단점 등 자유롭게) 온라인 해커톤 : 장점 (시공간 제약이 없다. 규모를 키울 수 있다. 참가자들 입장에서는 개발 시간이 길어진다.) 단점 (운영적으로 흔치 않기 때문에 경험이 많은 사람이 없구요. 참가자들이 현장감 있게 참여하기가 어려운 단점, 노쇼 참가 비율도 높고, 중간에 포기하는 비율도 높아질 수 있어요) 오프라인 해커톤 : 장덤 (현장감이 주는 매력) / 단점 (공간 제약이 있어요. 하루 3끼씩 밥과 간식도 챙겨야하고 예산도 훨씬 많이 들어가요, 1박 2일 운영진이 꼬박 밤을 새야해서 힘들기도 하구요),

3. 밤낮으로 여러 공지들을 해 주시고 계세요! 해커톤을 운영하시면서 가장 힘든 점은 무엇이신가요?
아무래도 지금 얼마나 몇명이 어느 정도로 작업을 하는지, 힘든 사람은 없는지 파악하기가 어려워요. 그래서 구글 설문지로 단계별로 나눠서 최대한 파악하려고 하고 있어요. 공지를 하고 있지만, 또 어떤 분들은 공지를 아무리 많이해도 관심 없으시기도 하고, 반대로 잦은 공지에 불편함을 느끼시기도 해요.

4. 팀빌딩을 관리하는 운영진은 본인 1명이신가요?
따로 팀 빌딩을 관리하는 운영진, 이라고 되어 있지는 않지만 주로 저와 홍승환 운영진님이 도와주고 있습니다. 그 외에 전체 행사는 10여명의 운영진들이 돌아가며 담당하고 있어요.

5. 피칭까지 가는 팀의 특징은 무엇일까요?
능력치or분위기 등등, 어떤 특징을 지닌 팀이 성공적인 결과를 거둘까요? 온/오프라인 해커톤 무관하게 재밌게, 서로 소통을 꾸준히 하는 팀. 그리고 서로가 시간을 많이 내면 낼 수록 끝까지 가는 확률이 높아요. 또, 해커톤의 본질을 잊고 너무~~ 딥하게 개발하다가 마감 기한을 놓치거나, 힘들어서 지쳐 떨어지는 경우가 있는데요. 애자일하고, MVP를 빠르게 만드는데 신경쓰는 팀은 끝까지 잘 가는 것 같아요.

6. 현재 #끝까지간다_팀빌딩 채널에서 애써주시는 것을 목격하고 있습니다. 랜덤 팀매칭은 수작업으로 매칭해주시나요? 어떤 기준인가요?
현재 수요일 이후로 팀 빌딩 채널이 조금 조용해졌어요. 일~화까지는 상황을 보고, 수작업으로 해드리도 했구요. 물론 정말 랜덤이기 떄문에 거기서 팀이 되는 경우도 있고 안되는 경우도 있었어요. 반대로 중간 중간에 참가자들에게 DM을 보내서 팀 빌딩 상황을 확인하면서 도와드리기도 했구요. 현재로는 거의 팀빌딩이 종료된 것 같아요.

7. 참가자가 잠수타는 경우 제외, 팀빌딩이 늦게까지 이루어지지 않는 경우 원인은 무엇일까요?
이번 같은 경우에, 일단 늦게 슬랙에 들어오신 분들은 거의 팀빌딩을 못했고, 본업이 바빠서 접속자체를 못한 분들도 있는 것 같아요. 대부분 금요일토요일쯤 들어온 분들은 왠만해서는 다 팀빌딩이 이루어진 것 같구요. 정말~ 내가 꼭 하고 싶은 아이디어가 있거나, 너무 팀원을 가려서 뽑거나 하는 분, 너무~~ 샤이해서 아예 팀원 구하시는 분들에게 연락을 못한 분들 아니고서는 팀 빌딩이 거의 완료 된 것 같아요.

8. 참가자들에게 엔젤핵 설문지를 받으셨는데, 참여자들이 온라인 참여에 대해 불편한 점에 관해 언급된 것들이 뭐가 있는지 혹시 공유해주실 수 있으실까요?
아, 네 생각보다 많은 분들이 피드백을 주진 않으셨는데요. 일단, 처음에 멘토링 시간이 짧았다. 아니면 게임이 재밌었다. 팀원들이 이미 자기들끼리 너무 친하다. 그런 사례들이 있었고, 일부는 다음 날 반영을 할 수 있었습니다. 아직까지는 대부분이 좋아해주시는 것 같아요. 물론 끝나고 나면 조금 더 제대로 행사 후 피드백을 받을 예정입니다.

 

이와 같은 인터뷰 자료도 수집할 수 있었다. 이날 내 주장대로 최대한 할 수 있는 선에서 이해관계자 인터뷰도 진행하고, 단 몇 마디 말로 열심히 준비했던 '매칭 알고리즘'도 날려버린 나는, 집에 돌아가면서 뭐가 그렇게 혼란스럽고 서운했을까? 나는 이때도 계속 운영진 외의 해커톤 참여자들로부터도 가능하다면 설문을 돌리고 싶었다. 팀빌딩 시 어떤 요소들을 고려하는지, 이번 온라인 팀빌딩을 하면서 어려운 점이 있었는지, 우리 서비스의 직접적인 고객으로부터 생생한 VOC를 얻고 싶었기 때문이다. 

 

 

Maker가 되느냐, 어설픈 전략가로 남느냐, 전략적인 Maker가 되느냐

어찌되었든 우리는 어디론가 건너편으로 길을 건너가고 있었다.

사실 뭐를 우선순위에 둘지는 우리 팀의 목표와 목적에 따라 달린 일 같다. 이날 나머지 세 사람은 내가 하는 말들의 논리를 이해했다. 그리고 내가 말한 것들이 서비스를 만드는데 중요하다는 것도 이미 알고 있었다. 그렇게 정석대로 모든 것을 챙기며 가는 것이 best지만, 지금은 시간과 자원이 한정되어 있으니 일단 Move on하자는 이야기였다.

 

"한정된 시간과 자원."

들을 땐 안다고 생각했는데, 이제와서 보니 그것을 나는 모르고 있었다. 지금와서 깨달은 바는, 내가 지극히 '기획자'라는 포지션에 갇혀서 마치 개발은 남 일인양 감놔라 배놔라 했던게 아닐까? 하는 것이다. 내가 직접 '개발을 해야한다고 염두하고 있었다면, 아마 조금은 다른 생각과 발언을 했을 것 같다. 무엇보다, 내가 처음에 생각했던 큰 그림을 먼저 잘 짜고, 해커톤에서는 그 그림 중 key feature 1-3개에 대해서만 개발을 진행하면 어떨까 중에 우리 수준에서 "Key feature 1-3개에 대해서만 개발을 진행"하는데 투입되어야 할 시간에 대해서 고려했을 것이다. 저 간단해보이는 "key feature에 대해서만 개발을 진행"하기 위해서 지금 당장 시작해도 시간이 모자란 상황이었던 것이다. 아..! 설이 내게 "너가 직접 디자인, 개발 단까지 한 번쯤은 갔다 와봐야해"라고 말했던 것이 이제 명확히 이해가 되었다. 사실 그 말들을 들을 때는, 결국 뒤에 가서는 내가 산이랑 같이 유저플로우도 정리하고, figma로 화면 디자인도 했는데 이게 무슨 말이야! 하며 조금 서운하기도 하고, 조금 아프게 들렸었다. 근데 웬걸.. 이렇게 차분히 앉아 돌아보니 내가 서러워할 일은 1도 없었구먼... 사과를 해도 모자랄 판이라는 생각이 든다. 앞단의 중요성을 이해하는 것과 별개로, 실제 이 서비스의 Maker가 되느냐 어설픈 전략가로 남느냐, 전략적인 Maker가 되느냐의 문제였다. 

 

반쪽짜리 시선으로 나머지에 대해서는 이해하려 하지 않았던 것 같다. 내 딴에는 우리 서비스를 위해, 우리 팀을 위해 한 생각이었는데, 지극히 '기획자' 그것도 엄밀히 말하자면 '반쪽짜리 기획자'의 시선에서 한 생각들이었던 것이다. 진짜 기획자는 모든 것을 조망할 줄 알아야 하는데, 나는 반쪽의 반쪽도 안되는 기획의 시선으로 답답해하고 있었다. 아픈만큼 이렇게 성장이 있구려.. 물론 여전히 고객정의와 BM 설계 부분에 대해서는 명백한 아쉬움과 한계를 느끼고 있다. 그 부분에 대해서는 우리 팀원 모두가 앞으로 성장해야 할 부분이라고 생각한다. 

 

이제야 조금씩 꼬였던 생각의 실타래가 풀리는 기분이 든다.