사이드프로젝트 후일담
:런칭의 고지에 오르는 법 (2)
Manual이 아닌, Menual! 매뉴얼이 아닌, 메뉴얼!해당 글은 Menual : 나를 새롭게 하는 일기장, 메뉴얼 앱서비스를 제작하며 느낀 점과 겪은 경험을 바탕으로 작성되었습니다. 1편에 이어 후속으로 작성된 글이니, 원활한 내용 전개를 위해 아래의1편을 읽고 오시는 것을 추천드립니다!
‘사이드프로젝트는 필수인가?’와 비슷한 기조의 제목으로 올라오는 글들을 심심찮게 볼 수 있는 요즘, 그만큼 뜨겁게 피어나는 수많은 사이드 프로젝트가 결실을 보지 못하고 분해되곤 한다.
이렇다 할 결과물이 없다는 건 과정을 설명할 수 있는 구체적인 자료가 없다는 것이고, 그만큼 과정에서 배운 것들을 다른 사람들과 나누기 어려워질 것이다. 사이드 프로젝트를 시도하는 것 자체도 대단한 의지인데 과정과 결과를 사람들과 나눌 수 없게 흐지부지 된다면, 다음 걸음을 위한 열정도 사그라드는 안타까운 상황이 벌어질 수 있다.
때문에 해당 글은 성공적인 사이드 프로젝트 런칭에 도움이 되는 자세들에 대해 다루고 있다. 이 전글의 네 가지 팁에 이어 남은 다섯 가지 팁도 사이드 프로젝트를 시작하기로 결심했거나, 진행 중인 여러분에게 도움이 되길…!
5. 서로의 영역에 적극적으로 침범하기.
이게 무슨 말도 안 되는 소리야…? 싶을 수도 있다. 각자의 능력에 따라 포지션을 달리 해두었는데 서로의 영역을 침범하라니. 각자 맡은 역할만으로도 할 일은 충분히 넘치는데 말이다. 회사와 같이 부서로 나뉘어, 저마다의 소통 방식과 절차가 정해져 있다면 해당 방식을 따르며 서로의 영역을 침범하지 않는 게 맞지만, 팀원들이 수십 명씩 있는 게 아닌 사이드프로젝트는 다르다. 오히려 서로의 영역에 적절하게 침범하여 서로의 짐을 덜어주는 것이 런칭에 한걸음 더 가까이 다가설 수 있다.
선을 긋고 지나치게 영역을 강조하는 행위는 좋지 않다.물론, 디자이너가 개발을 진행하기는 어렵고, 개발자가 기획을 진행하는 것도 쉽지 않다. 하지만 서로의 영역에 대한 어느 정도의 배경지식이 있다면 다양한 아이디어를 제시하고, 의견을 나눌 수 있다. 서로의 피드백과 아이디에이션을 각자의 영역을 침범당한다고 느끼지 않고, 한정된 시간 속에서 다양한 방향성을 살필 수 있는 기회로 생각한다면 혼자서는 생각해 볼 수 없었던 새로운 의견들 속에서 프로젝트의 돌파구를 찾아낼지 모르는 일이다.
보다 열린 마음으로 서로의 서로의 짐을 나누고, 받아들이는 자세가 필요하다. 디자이너가 Lottie 파일의 코드를 개발자가 지정해 둔 영역에 붙여 넣는 단순작업이라도 도와준다거나, 디자이너가 세팅해 둔 시스템을 이용하여 간단한 UI 화면을 PM이 제작해 보는 등 내가 맡은 일이 아님에도 여의치 않은 상황을 생각하여 행동하는 자세가 필요하다는 뜻이다.
물론, ‘색깔 이게 나을 것 같은데 바꿔주세요.’, ‘이 정도는 개발자님이 알아서 해줄 수 있죠?’라는 식으로 서로의 영역을 침략하고, 이를 받아들이라는 뜻이 아니다. 다만 인원도, 시간도 부족한 사이드 프로젝트 과정에서 ‘이건 제 일이 아닌데요…?’ 라며 지나치게 선을 긋는 자세는 결국 런칭에서 멀어지는 길이라는 점을 기억해야 할 것이다.
6. 다양한 채널로 소통하고, 한 곳에 기록하기
Jira, Slack, Jandi, Notion 등 다양한 업무용 협업 툴들은 저마다 장점이 많고, 사랑스럽다. 하지만 회사마다 주로 사용하는 협업 툴이 다르듯, 팀원들이 사용하는 협업 툴이 하나로 통일될 가능성은 매우 낮다.
어떤 툴이 가장 좋지...사이드 프로젝트 역시 커뮤니케이션을 위한 특정 툴을 선정해야 한다. 여기서 중요한 점은, ‘만능 툴’ 이지만, 기록에 초점을 맞추어 툴을 설정하는 것이 좋은 방향이라는 것이다.
왜냐하면 사이드 프로젝트의 경우 각자 작업하는 시간이 다르기 때문이다. 이 말인즉슨 팀원의 의견이 필요한 시점이 달라진다는 뜻이고, 이는 곧 소통의 시급함에 따라 사용하는 툴(프로그램)이 달라진다는 뜻이다.
예를 들어 디자이너가 와이어프레임을 짜다가, 회의에서는 말하지 못했던 새로운 방향의 아이디어가 떠올랐다고 해보자. 새로운 아이디어에 대한 참신함은 있지만, 강한 확신은 부족한 상태라면 팀원들과의 소통이 당장에 필요하지는 않으므로, 협업 툴이나 피그마의 코멘트, 혹은 개인의 기록을 통해 다음 미팅 시간의 회의를 위해 내용을 정리해 둘 것이다. 하지만, 기존의 내용과 확연히 달라진 디자인에 강한 확신과, 해당 방향으로의 디벨롭이 필요하다면 팀원들의 의견이 당장 필요해서 카카오톡 등의 메신저를 활용하게 된다. 즉, 팀원들과의 소통, 회의를 하나의 도구로만 진행할 수는 없는 노릇이다.
따라서, 소통은 팀원들 각자가 필요에 따라 원하는 채널을 이용하는 것이 효율적이다. 피그마의 코멘트가 될 수 있고, 메세지나 카카오톡이 될 수 있다. 어떤 때는 급하게 특정 팀원과의 전화통화가 필요하기도 하다. 그리고 이 모든 소통은, 기록이 아닌 소통에 초점이 맞춰져 있기 때문에 이 모든 결정 사항을 팀 프로젝트에서 선정한 협업 툴에 기록해야 할 것이다. 과정이 없는 결과는 없기 때문이다.
기록의 중요성을 잊지 말자. 기억은 휘발성이 강하다. 메뉴얼을 진행하면서 가장 많이 활용한 서비스는 피그마, 노션, 카카오톡이다. 일정은 카카오톡 죠르디의 힘을 빌렸고, 노션에 회의 내용과 작업과정을 기록했다. 작업물 없이 소통하기 어려운 부분은 피그마에 코멘트를 남기고 급한 경우 카카오톡을 통해 나누기도 했다. 그리고 결정된 내용은 피그마와 노션에 중복해서 기록했다. 하나의 툴을 활용해서 프로젝트를 진행하고 싶은 마음이 굴뚝같겠지만, 사이드프로젝트의 특성상 협업 툴에서 중요한 것은 과정의 통일이 아닌, 기록의 집중이라는 점을 기억하자.
7. 프로젝트만 진행하지 않기
쉽게 말하자면, 프로젝트에 관련된 내용으로만 소통하길 고집하지 않고, 잡다한 이야기도 나누자는 것이다.
프로젝트가 어느 정도 진행되고 있는 중간 시점에 오면, 협의를 거쳐야 할 여러 사항과 각각의 업무가 바쁘기 때문에 어느새 소통채널은 어쩐지 엄숙하고 딱딱해져 있을 가능성이 높다. 이러한 분위기는 서로를 향한 피드백이나 요청에도 지대한 영향을 끼친다.
메신저 너머 팀원들의 표정을 생각해 보자.사이드프로젝트는 회사와는 달리 월급과 같은 확정된 보상이 없고, 팀원들의 의지와 팀이 설정한 목표로 결속되는데, 의사소통 과정이 냉담하고 딱딱해진다면 상하는 감정에 의지가 흔들리고 목표와는 더욱 멀어질 수밖에 없다. 가벼운 잡담과 프로젝트와 관련 없는 소통이 오히려 프로젝트에 효율을 가져오고, 결속력에 도움을 줄 수 있다.
프로젝트와 관련하지 않는 소통이 꼭 개발, 디자인, IT, 트렌드 등과 관련된 내용이 아니어도 상관없다. SNS에 떠도는 개발자 디자이너 공감 짤 등 팀원들이 공감하고 웃을 수 있는 가벼운 내용을 나누거나, 프로젝트가 끝나면 다 같이 회식으로 가볼 식당을 공유해 보는 것도 좋겠고 일상을 공유하고, 응원의 메세지를 보내보는 것도 좋겠다.
8. 회의는 정해진 시간 30분 전부터.
회의시간이 9시라면, 8시 반부터는 오늘 어떤 내용을 팀원들과 나눠봐야 할지 정리해 보는 시간을 가지자. 명확한 분업과 절대로 지켜지는 정기적 회의 및 업무공유 시간이 있다면 좋겠지만, 사이드프로젝트는 그러기가 쉽지 않다. 갑자기 출장을 가는 팀원, 야근 등의 이유로 미뤄지는 회의 등 일사천리로 진행될 수 없는 수많은 이유가 있기 때문이다. 때문에 종종 회의를 ‘우리 어떤 이야기해야 하지…?’ 라며 시작하는 경우를 볼 수 있게 된다.
바쁘게 본업을 끝내고 회의를 시작한 우리...물론 PM을 맡은 팀원이 있다면, 이런 불상사는 최소화할 수 있겠지만 PM이 디자인과 개발 작업과정의 A-Z를 모두 알고 있기는 어렵다. 따라서 최소한 아래의 세 가지 사항은 회의 시작 30분 전의 시간을 할애하여 준비하는 것이 좋겠다.
1. 지금까지의 작업 상황
2. 팀원에게 물어볼, 요구할 사항
3. 다음 회의까지의 예상 작업량 및 작업 일정
위 세 가지 사항을 정리해 보며 회의를 준비하면, 추후 내가 작업하는 영역에도 분명한 도움이 될 것이고, 이는 곧 좋은 결과물로 향하는 믿거름이 될 것이다.
9. 서비스는 업데이트가 가능함을 잊지 않기
모든 계획이 착착 맞아떨어져서, 맨 처음 팀원을 구하면서 구상했던 대로 프로젝트가 진행된다면 얼마나 좋을까? 알라딘의 요술램프가 있다면, 반질반질 빛이 나도록 열심히 비벼서 ‘앞으로 제가 계획하는 모든 일들이 계획대로 잘 진행될 수 있게 해 주세요’라고 빌고 싶은 심정이다.
저 진짜 열심히 빌 수 있어요하지만 프로젝트를 진행할수록 현실적인 장벽에 자주 부딪힌다. 한정된 시간에 알맞은 적당한 기획, 적당한 디자인, 적당한 개발을 통해 제품을 내기란 쉽지 않고, 셋 중 하나의 영역이 지나치게 커지거나 작아져 팀원들의 기대를 충족시키지 못할 수 있고, 처음 예상과는 다르게 프로젝트가 흘러갈 수도 있다. 중요한 건 꺾이지 않는 마음이라고, 프로젝트의 성공적인 완성을 위해 노력하고 애를 써야 하는 개인의 자세는 변함이 없어야 하지만, 개인이 모인 프로젝트는 어느 순간 꺾여버릴 수 있다.
중간에 포기한 프로젝트에 대하여...이런 상황에서 기억해야 하는 점은 ‘꼭 처음부터 최고의 프로젝트’를 제작할 필요는 없다는 것.
디지털 환경의 서비스는 언제든지 수정할 수 있으므로 사이드프로젝트에는 최후의 보루가 있는 셈이다. 정해진 기간 내에 할 수 없다면, Phase 2를 계획하는 것도 나쁘지 않은 방법이다. 우여곡절이 많은 프로젝트를 성공적으로 끝마칠 수 있다면 더할 나위 없겠으나, 극복할 수 없는 우여곡절이 있을 경우 완성의 틀을 갖추어 우선적으로 프로젝트를 출시하고, 서비스를 운영하며 못다 한 부분을 보충해 나가는 것이다.
이렇게 하면 서비스를 출시하지 않고는 보이지 않던 문제점과 개선사항을 새롭게 환기할 수 있으니 어쩌면 더욱 완성도 높은 서비스를 향한 지름길이 될 수도 있다. 무엇보다도 프로젝트가 공중분해 되지 않고 결과물로 쌓인다. 기억하자. 포기는 미숙한 완성보다 나쁘다.
지금까지 Menual : 나를 새롭게 하는 일기장, 메뉴얼을 제작하면서 느낀 점과 경험을 바탕으로, 사이드프로젝트를 런칭의 고지에 올리는 법에 대한 후일담을 적어봤습니다. 아무래도 ‘런칭’에 초점이 맞춰져 있고, 기간을 한정 지어 스프린트 하는 동아리 형식이 아니라, 아닌 비교적 기간을 넓게 잡아 진행한 팀 프로젝트였기 때문에 IT동아리 등에 속해서 작업을 진행하시는 분들에게는 적용가능한 부분이 크지 않을 수도 있을 것 같습니다만, 사이드 프로젝트가 가지는 특성과 가져야 할 기본적인 자세에 있어서 누군가에게 작은 도움이나마 된다면 좋겠습니다. 가볍게 읽으실 수 있도록 풀어서 적는 방식으로 글을 작성해 봤는데, 읽으시면서 새로운 영감과 발전된 인사이트가 되셨길 바랍니다.
행복한 하루 보내세요!
