사이드프로젝트 후일담
: 런칭의 고지에 오르는 법(1)
[Menual : 나를 새롭게 하는 일기장, 메뉴얼 ] 앱서비스 제작기
2022년 12월. 일 년 남짓한 시간 동안 사이드프로젝트를 진행한 끝에,
Menual : 나를 새롭게 하는 일기장, 메뉴얼'이라는 일기 서비스를 앱스토어에 런칭할 수 있었다.
우 오 ㅏ! 앱스토 ㅇ ㅓ 에 나온ㄷ ㅏ!!!우여곡절이 많았던 프로젝트지만, 앱스토어 랭킹에 서비스가 노출되고 SNS를 통해 지인들에게 축하 메세지를 받으며 그간의 노고나 어려움이 눈 녹듯 사라졌다. 이제 진짜 사이드프로젝트가 완성으로 끝났다는 생각이 들었다.
사이드프로젝트... 해치웠나...!?하지만 서비스를 런칭한 이후로도 사이드프로젝트는 계속되고 있다. 런칭이 곧 완성을 뜻하는 것은 아니기 때문이다. 메뉴얼 팀은 지난 1년의 시간은 서비스의 런칭을 위해, 이제는 서비스를 운영하고 개선하는 Phase-2로 사이드 프로젝트를 지속하고 있다.
이 글에서는 좌충우돌 수많은 실패와 어려움을 헤치고, 결국 런칭이라는 고지를 밟게 된 사이드프로젝트 경험담을 적어보려고 한다.
열 길 물속은 알아도 한 길 사람 속은 모른다고, 나도 잘 모르겠는 내 속 좀 알려줄 수 있는 설명서가 있었으면 좋겠다 하는 생각에 제작된 메뉴얼이라는 서비스. 이와 비슷하게 열길 성공한 프로젝트를 봐도, 내 프로젝트는 어렵다고. 직접 겪은 사이드프로젝트의 이야기가 모여 누군가(혹은 나)의 설명서가 될 수 있도록.
1. 가장 먼저, 사이드 프로젝트에 대한 ‘팀’의 정의 내리기
메뉴얼 서비스는 함께 졸업전시를 진행했던 팀원들과의 채팅방에 올라온 메세지 하나로 아주 단순하게 시작했다.
개발자 : 행님들 요즘 사이드프로젝트 생각 없음?
디자이너 1 : 나는 좋아
디자이너 2 : 나도 좋음
개발자 : ㅇㅋ ㄱ
너두 나두 유캔두~ 사이두 짧디 짧은 장난스러운 메세지로 사이드프로젝트가 오랜 기간 이어졌다.
가벼운 시작에 앞서 우리가 가장 먼저 나눈 대화는 각자가 생각하는 사이드프로젝트에 대한 정의였다. 서로가 생각하는 사이드프로젝트의 간극을 줄여, 팀이 되고자 한 것이다.
대화 끝에 합의된 점은. 사이드프로젝트는 말 그대로 ‘사이드’ 프로젝트라는 것이다. 이미 각자의 본업이 있는 상태에서 새로운 프로젝트를 위해 할애할 수 있는 시간은 한정되어 있기에, 속도의 이점을 버리더라도, 탈 나지 않는 길을 선택한 것이다.
따라서 우리는 세 가지 사항을 먼저 정했다.
각자의 본업에 큰 영향을 주지 않는 선에서 간단히 진행한다.
서버를 사용하지 않는 가벼운 서비스를 제작한다.
단, 천천히 진행하더라도 꼭 운영할 수 있는 서비스를 완성하도록 한다.
본업도 힘든데 사이드를 어떻게 해요...팀원들이 생각하는 사이드 프로젝트는 각자 다 다를 수밖에 없다. 어떤 사람은 3개월 안에 빠르게 서비스를 완성해서, 취업 혹은 이직에 도움을 받기를 원할 것이고, 누군가는 부가적인 수익을 창출하기 위해 사이드 프로젝트를 결심했을 수 있다. 더러는 그냥 사이드 프로젝트를 통해 업계에서의 인맥을 늘리고 싶다는 목적을 가지고 있기도 하다.
이처럼 팀원들이 생각하고 있는 사이드프로젝트는 각자 다 다를 수밖에 없다. 따라서 사이드프로젝트를 ‘팀’으로서 재정의 한다면, 런칭의 고지까지 함께 하는데에 큰 도움이 될 것이다.
2. 미래의 자신을 신뢰하지 않기.
사이드프로젝트를 진행하기 위해 아이디에이션을 진행하다 보면, 어쩐지 지금 내는 아이디어로 세상을 뒤흔들어놔야 할 것 같은 생각이 들기도 하고, 가능성보다는 신선함을 추구하게 되기도 한다. 하지만 잊지 말아야 하는 것은 ‘미래의 나를 믿어서는 안된다.’는 점이다.
잘 지내지 미래의 나?3D 툴을 다뤄본 적 없는 디자이너가 블랜더나 C4D를 배워서 사이드프로젝트를 진행하겠다거나, 개발이 불가능한 인터렉션을 지금부터 공부해서 구현하겠다는 개발자의 말에 기대어 프로젝트를 진행해서는 안된다. 정도에 따라 짧은 시간 안에 공부할 수 있는 영역은 있겠지만, 무에서 유를 창조해 내기란 쉽지 않고, 당장의 내가 아닌 미래의 내가 그러기란 더욱 쉽지 않다.
팀 사이드프로젝트의 가장 큰 속성은 ‘각자의 본업이 다르다는 것’이다. 이는 곧 각자의 미래도 어떤 방향으로 흘러가게 될지 예측할 수 없다는 점이다. ‘지금부터 공부한다면 그때쯤에는 할 수 있을 거야…’ 위험한 생각. 그때쯤에는 이미 사이드프로젝트가 와해되었을지도 모른다.
3. 혼자 진행해도 함께 결정하기.
프로젝트를 진행함에 있어서 소통의 중요성은 수없이 반복할 수밖에 없다.
하지만 같은 시간에 특정 장소에 모두가 모여 작업을 진행하는 게 사실상 불가능한 사이드 프로젝트의 특성상, 원활한 소통은 굉장히 어렵고 더욱이, 각자의 역할이 나누어져 있기 때문에 함께 작업을 진행하는 것 또한 불가능한 경우가 많다.
하지만 우리에게는 피그마, 노션, 카카오톡, 슬랙, 잔디, 팀즈 등 작업의 소통을 위한 다양한 도구가 준비되어 있다. 작업 진행이 막히거나, 혼자서는 결정할 수 없는 중대한 사항이 생겼을 때는 선택을 잠시 뒤로 미루고, 팀원들에게 공유하여 의견을 기다리는 것이 현명하다.
프로젝트는 혼자서 진행하는 것이 아니기 때문이다. 디자이너의 시각으로 결정한 사항이 개발자에게는 지나친 비효율이 될 수도 있고, 개발자의 관점에서 결정한 사항이 디자이너의 시각에서 중요한 오류를 범할 수도 있다.
결국 결정은 함께하게 되어있다.혼자서 결정을 내리기 위해 많은 시간을 투자하는 것보다, 다른 팀원들의 의견을 들어보는 것이 백번 더 낫다. 목표는 서비스다. 뛰어난 기획만 하겠다, 예쁜 디자인을 하겠다거나, 기깔나는 개발을 하겠다 등의 각자 역할에만 지나치게 집중하게 된다면, 서비스는 조화와 균형을 이루지 못하고 무너지고 말 것이다.
4. 진행과정을 알아볼 수 있도록 작업하기.
팀원 1 : 그래서… 어쩔 수 없이 바텀시트의 형식으로 가야 할 것 같습니다.
팀원 2 : 근데 그것보다 키보드에 탭바 형식으로 붙이는 게 낫지 않나? 그게 깔끔할 것 같은데
팀원 1 : 저번주에 탭바로 붙여왔었는데 통일성을 해치니까 바텀시트로 가자고 하셨잖아요…?
팀원 2 : 제가 그랬나요…? 제가 그랬나요 팀원 3님?
팀원 3 : 어 그… 저는 잘 모르겠네요 잘 기억이 안 나요
팀원 모두 : … ㅎㅎ… ㅎ… ㅋㅎ..
부끄럽지만 메뉴얼을 진행하면서 실제로 있었던 일이다. 최초 기획에서 문제가 발생해 수정사항을 반영하여 작업을 진행했고, 반영된 작업물을 들고 가니 맨 처음 기획을 기억하지 못하는 팀원이 처음 것이 더 낫다는 이야기를 하는 상황. 그것만으로도 벅차지만, 가장 웃픈 상황은 아무도 이 과정을 기억하지 못했다는 것.
가만 생각해 보니 회의 때 뭔가 반짝였던 것 같기도...?함께 진행했기에 당연히 기억할 거라 생각하는 부분도 사이드프로젝트이기에 잊혀질 수 있다. 본업 외의 프로젝트를 진행하며 정해진 시간과 날짜가 절대적으로 지켜질 수 있다면 좋겠지만, 사람이 많아지는 만큼 사정도 많아진다.
따라서 되도록 진행과정을 알아볼 수 있도록 작업하며 아래의 네 가지 사항과 함께 정리해 두는 것이 좋다.
날짜
작업내용 요약
변경사항
논의사항
이러한 방식으로 작업파일을 정리해 둔다면, 잠시 프로젝트에 참여하지 못했던 팀원도 내용을 놓치지 않고 빠르게 따라올 수 있고, 팀원들과 코멘트를 남겨가며 시간과 장소의 제약 없이 소통할 수 있으며, 혹여 기존의 팀원들이 나가고, 새로운 팀원이 들어오게 됐을 때 별도의 설명 없이도 기존 작업과정을 자유롭게 확인해 볼 수 있을 것이다. 더하여 진행사항을 누구도 기억하지 못하는 불상사를 막을 수 있다.
실제 작업화면, 화면의 그림보다는 내용에 집중했다.물론, 진행과정을 모두 저장해 놓으면 파일이 너무 거대해지고, 작업환경의 원활함을 방해가 되어 비효율적이라고 생각될 수 있지만, 일정 기간의 텀을 두고 오래된 내용의 파일을 분리하여 저장해 두면 해결할 수 있다.
(2편에서 계속됩니다.)
