brunch

You can make anything
by writing

C.S.Lewis

by JunWoo Lee Feb 12. 2021

팀 사이드 프로젝트 할 때 알면 좋은 것들

팀 사이드 프로젝트 소소한 팁들

다른 사람들과 함께 사이드 프로젝트를 진행할 때는 이것저것 신경 쓸 것들이 많다. 그래서 사실 사이드 프로젝트에 익숙하지 않은 사람은 일단 혼자서 진행해보는 걸 추천한다.

(그래서 관련된 글을 쓰기도 했다..!)


하지만 언제까지고 혼자만 사이드 프로젝트를 할 수는 없는 노릇이다. 다른 사람들과 사이드 프로젝트를 하며 배우는 점도 참 많기 때문이다.


그래서 최근엔 나도 다양한 사람들과 사이드 프로젝트를 진행하고 있는데.. 팀 사이드 프로젝트 경험이 많지 않아서 여러 가지 시행착오를 겪게 된다.


그런데 오히려 좋다! 사이드 프로젝트는 배우려고 하는 거니까.

오늘은 팀 사이드 프로젝트를 하며 배운 점들을 소소한 팁 형태로 정리해보려 한다.


#앞으로 팀 사이드 프로젝트를 진행하며 얻은 팁들은 이곳에 업데이트할 예정


주로 앱 서비스를 만드는 사이드 프로젝트에 초점이 맞춰져 있습니다. 이 점 참고하여 읽어주세요!



팀으로 사이드 프로젝트 할 때 알면 좋은 것들




목차

무작정 팀원 구하지 말기

아이디어 낼 때는 기술 내려놓기

회의 시간에 아이디어 짜내지 않기

아이디어 돌아보기

프로덕트 채널 만들기

무료/유료 신중히 정하기

신중히 퍼주기



1. 무작정 팀원 구하지 말기


아이디어가 정해지지 않은 상황에서 팀원이 든든하다면 참 좋다. 어떤 아이디어든 멋지게 만들 수 있을 것 같으니까.


그래서 여기저기 수소문하여 각 분야의 실력자들을 드래곤볼처럼 찾으려 한다. 최고의 기획자, 디자이너, 개발자, 마케터 등등..


그런데 실력자라는 이유로 무턱대고 팀에 영입하면 나중에 본격적으로 프로젝트 진행할 때 애매해진다. 다음의 상황을 한번 살펴보자.

A: 오! 그 아이디어 완전 좋아요!
B: 그러게요. 저도 있으면 꼭 쓸 것 같아요!!
C: 아.. 그런데 그 아이디어 만들 때 저는 필요 없을 것 같은데요..
D: 앗 그러네요..! 그러면 딴 거를 해야 하나..?

멋진 아이디어가 나왔지만 진행하기 애매하다. 그 아이디어를 진행하면 C라는 사람이 필요 없어지기 때문이다.


실력자라고 영입해놓고 C에게 나가달라고 하거나 이참에 새로운 걸 배우라고 요청하기도 그렇다. 프로젝트의 시작 단계인 아이데이션부터 난관에 부딪히는 셈이다.


저런 경우가 많나 싶겠지만 실제로 꽤 된다. 멋진 아이디어가 나왔지만 웹으로 만드는 게 더 효율적이거나.. 서버가 필요 없는 경우거나..


다시 말해 팀원은 팀의 자원임과 동시에 아이디어의 조건이 되기도 한다는 것이다. 안 그래도 멋진 아이디어 내기 힘든데 팀원 각각의 역할까지 고려해야 한다.


그러니 개인적으로는 팀원을 한 번에 모으는 것보다 단계적으로 모으는 것을 추천한다.


1단계 - 최소 인원

2단계 - 아이데이션

3단계 - 필요 인원


처음에는 2~3명 정도의 최소 인원으로 아이데이션을 한 후 필요한 인원을 추가 영입하는 식이다. 이래야 아이데이션 할 때 조금이라도 더 자유롭게 할 수 있다.


최소 인원에 들어갈 추천 포지션으로는 사람마다 견해가 다르겠지만.. 나는 디자이너와 웹 개발자를 뽑고 싶다. 두 포지션 모두 대부분의 아이디어에서 필요시 되는 역할인 것 같다.




2. 아이디어 낼 때는 기술 내려놓기


주변 지인들로부터 사이드 프로젝트 썰을 가끔 듣는다. 그럴 때마다 종종 등장하는 타입의 인물들이 있는데 일명 기술 만능주의자들이다.


기술 만능주의자는 프로덕트의 차별점을 기술에서 찾는다. 기존에 시장에 출시된 앱에서 더 이쁘게, 인터랙션만 멋지게 만들면 잘 팔릴 거라 생각한다.


그래서 아이디어적으로는 큰 차별성이 없는 껍데기만 다른 앱들이 출시되곤 한다. 그리고 그런 앱들은 대부분 소리 소문 없이 사라진다.


디자인, 개발 모든 것이 상향평준화 되어가는 시점에 기술로 승부 보려고 하는 것은 안일한 생각이다. 이제는 아이디어 단계부터 깊은 고민이 필요하다.


그리고 이를 위해선 시장 조사, 아이데이션 단계에서 디자인, 개발 등 기술적 관점을 의식적으로 내려놓을 필요가 있다. 사람의 사고방식에도 관성이라는 게 있어서 가만히 두면 결국 자신의 배경대로 생각하게 되기 때문이다.


우리가 만들 건 핀터레스트에 올라갈 목업, 테크 세미나에서 발표할 기술이 아닌 사용자가 실제로 쓸 서비스라는 점을 기억해두자.


일단 서비스가 쓸모가 있어야 사용자가 들어와 디자인이든 기술이든 확인할 것이다. 쓸모가 없는 서비스의 완성도는 그저 공허한 외침에 불과하다.




3. 회의 시간에 아이디어 짜내지 않기


회의 시간에 팀원들이 브레인스토밍 하여 무에서 유를 창조해내는 것


뭔가 굉장히 IT스럽고 쿨해보인다. 하지만 사실은 전혀 그렇지 않고 스트레스 받는 일이다. 이상과 달리 현실에선 괜찮은 아이디어가 정-말 안 나오기 때문이다.


그래도 시행착오의 일환이라 생각하고 아이데이션 회의를 반복한다. 팀원들끼리 티키타카를 반복하다 보면 언젠가 좋은 아이디어가 나올 것이라 굳게 믿고..


하지만 한, 두 시간짜리 회의에서 멋진 아이디어가 나올 정도로 세상은 만만하지 않다. 우리가 생각한 건 이미 다른 사람이 만들어 놓았고, 누군가 안 하고 있다면 안 할 만한 이유가 다 있다.


결론 없는 탁상공론이 반복되면 누구든 지치기 마련이다. 그래서 결국 한 사람씩 팀에서 나가거나 자포자기하고 아무거나 만들게 된다.


그러면 어떻게 해야 된다는 말인가?


우선 회의 시간에 아이디어를 처음부터 발전시킬 생각을 버리고 아이디어 제안자부터 모집하자. 제안자는 이름 그대로 시장 조사와 고민을 하여 회의 때 아이디어를 들고 오는 사람이다.


제안자는 회의 때 자신의 아이디어를 팀원들에게 공유하고 설득한다. 중요한 건 제안자가 아이디어를 어느 정도 발전시켜와야 한다는 것이다.


적어도 아래의 세 가지 정도는 정리해와야 한다.

시장 조사(경쟁 서비스)

페인 포인트

핵심 기능


팀원들은 위의 내용에 대해 듣고 그때부터 브레인스토밍을 시작한다. 아이디어에 대한 피드백을 주고 더 발전시킬 방법에 대해 함께 고민해본다.


아이디어 제안자 방식의 장점은 회의에 방향을 설정해준다는 것이다.


다들 빈손으로 와서 처음부터 아이디어를 발전시키려고 하면 말이 티키타카지 논의가 정리가 안된다. 넓고 얕게 얘기만 하고 깊게 파고들지는 못한다.


반면 누군가가 책임지고 논의할 내용을 가져오면 이야기가 다르다. 아이디어에 대한 배경 지식을 나누며 더 깊고 발전적인 고민을 할 수 있게 된다.


그래서 회의 때 단번에 결론은 안 나더라도 점차 아이디어가 정립되고 나아가는 양상을 띤다. 이는 팀원들을 덜 지치게 하고 더 좋은 아이디어를 나올 수 있게 만든다.




4. 아이디어 돌아보기


소설 작가들은 글을 다 쓰면 일정 시간 묵혀두고 나중에 다시 읽어본다고 한다.

왜 그럴까?


글을 쓰는 중에는 자신의 창작 행위에 취해 보이지 않는 점들이 있기 때문이다. 그래서 글을 다 쓰면 눈에 안 보이게 치워놓고 한 달 정도 후에 제 3자의 눈으로 다시 읽어보는 것이다.

(실제로 창작하는 뇌와 첨삭하는 뇌는 다르다고 한다.)


사이드 프로젝트의 아이디어도 마찬가지라 생각한다. 우여곡절을 통해 멋진 아이디어가 나온 것 같으면 신이 나고 엔돌핀이 돌기 시작한다.


팀원들과 아이디어에 대해 이런저런 설레는 이야기를 하며 장밋빛 미래를 그려본다. 이거 성공시켜서 퇴사하자라는 농담과 함께..


찬물을 끼얹어서 안타깝지만 엔돌핀이 넘치는 현장 속에서 놓친 부분이 존재할 수 있다. 작은 장점은 크게 보이고 큰 단점은 사소해보인다.


그러니까 아직 경주마처럼 앞만 보고 달릴 시기가 아니라는 얘기다. 아무리 멋진 아이디어인 것 같아도 최종 확정은 일주일 정도 보류해보자.


일주일 동안 각자 떨어져 일상 속에서 생활하며 가끔씩 아이디어에 대해 생각해본다. 주위 사람들 혹은 아이디어의 타겟을 살펴보며 저들이 과연 우리의 아이디어에 흥미를 보일까 고민하는 것이다.


이렇게 아이디어를 돌아보는 과정을 통해 회의 시간에 놓쳤던 부분들을 발견할 수 있다. 그런 부분들은 잘 정리해놓았다가 다음 회의 때 공유한다.


만약 일주일 후에도 팀원들 사이에 이견이 없다면 아이디어는 그대로 확정일 것이고 아니라면 조금 더 고민해보면 된다.


아이디어가 확정되지 않았다고 아쉬워할 필요 없다. 일주일이라는 기간을 통해 이후 한, 두 달 정도에 들어갈 노력을 아낀 셈이니까.


쇠뿔도 단김에 빼라는 말이 있지만..

돌다리도 두들겨 보고 건너라는 말도 있다.


혼자가 아닌 팀으로 하는 만큼 아이디어를 더 신중히 정해야 한다는 점 잊지 말자. 모두의 소중한 노력과 시간이 들어가는 일이다.




5. 프로덕트 홍보 채널 만들기    


우여곡절 끝에 아이디어를 내서 멋진 프로덕트를 만들었다. 그러면 처음에 그렸던 장밋빛 미래가 그대로 펼쳐질까?


그러기 쉽지 않다.


아무리 좋은 프로덕트를 만들어도 노출이 안되면 흥행하기 어렵다.


얼마나 억울한가?


시간과 노력을 들여 멋진 프로덕트를 만들었는데 금방 묻히다니. 물론 만들면서 배운 것들이 많겠지만.. 어쨌든 성적이 안 좋으면 기분도 다운된다.


이런 불상사를 막기 위해선 프로덕트를 홍보할 채널을 미리 만들놓아야 한다. 인스타그램이든 페이스북이든 채널을 키워보자.


물론 팀 내에 인플루언서 혹은 전문가가 있지 않는 이상 채널을 키우는 건 쉽지 않다. 프로덕트가 완성된 시점에도 팔로워 수가 민망할 정도로 적을 수도 있다.


하지만 그럼에도 채널을 만드는 건 의미가 있다.


일단 적은 확률이지만 확보한 팔로워 중에 바이럴의 발화점이 되는 사람이 존재할 수도 있다. 한 사람이 올린 글이 이곳저곳에서 파장을 일으키는 세상이니 아예 불가능한 일도 아니다.


채널은 바이럴의 촉매가 된다. 누군가가 프로덕트가 마음에 들어서 SNS에 공유할 때 채널 ID를 태그 할 수 있다는 얘기다. 이는 바이럴이 더 잘 퍼져나갈 수 있도록 돕는다.


그리고 채널은 바이럴 추적에도 용이하다. 앱스토어 콘솔 등을 통해 앱 노출량/다운로드 수가 확 튄 걸 확인했는데 이유를 모를 때가 있다.


이럴 때 채널을 통해 사용자에게 프로덕트에 대해 어떻게 알게 되었는지 질문할 수 있다. 바이럴이 어디서 일어났는지 알게 되면 그에 대응하는 게 가능해진다.

모지또 바이럴 찾기

위처럼 꼭 바이럴이 되지 않더라도 채널은 서비스 문의 혹은 공지용으로도 쓸 수 있으니 손해보는 건 없는 셈이다.


그러니까 꼭 프로덕트만 만들지 말고 채널을 함께 만들어 운영해보자.


가능성 0%와 1%는 천지차이다.




6. 무료/유료 신중히 정하기

열심히 만든 프로덕트를 스토어에 무료로 낼지 유료로 낼지 고민하게 되는 시점이 온다. 특히 운영 비용이 발생하는 프로덕트의 경우엔 더더욱 그럴 것이다.


무료 출시
사용자 좀 모으고 돈 벌어보자!

유료 출시
사용자가 좀 적더라도 바로 돈 벌어보자!


개인적으론 이런 상황에선 보통 무료쪽으로 기울게 되는 것 같다. 사람들이 돈까지 내며 이 서비스를 쓸까 고민이 되기 때문이다.


그런데 여기에 대해선 조금 더 생각해봐야 할 부분이 있다.

과연 무료로 하는 게 사용자 확보에 무조건 더 좋을까?


위에서도 말했지만 사이드 프로젝트의 경우 프로덕트를 알리는 게 굉장히 어렵다. 직접 만든 채널 혹은 지인 홍보 외엔 딱히 프로덕트를 알릴 수단이 없다.


그래서 보통은 스토어 에디터에 의해 피처드(추천) 되는 것을 기대하는데.. 그것도 단발적인 이벤트라 효과가 제한적이다.


가장 이상적인 것은 앱 인기 차트에 안착하는 것인데 무료 앱의 경우 그게 정말 어렵다. 무료 앱 인기 차트엔 대기업 프로덕트들이 대거 포진해있기 때문이다.


반면 유료 앱의 경우는 그렇지 않다. 대기업 앱만큼의 다운로드 혹은 사용이 발생하지 않아도 높은 순위에 랭크될 수 있다.

랭킹 차트

인기 차트는 프로덕트를 사람들에게 알릴 수 있는 최고의 수단이다. 인기 차트라는 좋은 인상을 주는 지면에서 노출되니 일석이조다.


그러니까 앱을 유료/무료 중 어떤 방식으로 출시할지 고민할 때 이 점도 고려해보자. 무료 앱으로 낸다고 무조건 사용자 확보를 더 할 수 있는 건 아니다.



7. 신중히 퍼주기


일단 무료로 앱을 내지만 이후 수익화할 계획(인앱 결제 등)이 있다면 출시 버전의 기능을 다시 한번 살펴봐야 한다. 처음부터 너무 많은 기능을 사용자에게 무료로 열어주고 있는 게 아닌지 검토해보자.


핵심 기능을 모두 무료로 열어버리면 나중에 돈 받을 만한 기능을 기획하는 게 어려워진다. 한번 무료로 연 기능은 유료로 전환하기가 무척이나 어려우니 고민이 필요하다.


가입 후 일정 기간 동안은 무료 정책을 펼치는 것도 방법이다. 해당 경우 무료 기간을 서비스에 맞게 잘 설정하는 게 중요할 것으로 보인다.


어쨌든 중요한 건 언젠가 수익화할 계획이 있다면 마구잡이로 기능들을 퍼줘서는 안 된다는 점이다. 출시 시점엔 사용자의 반응이 어떨지 예측이 안돼 최대한 많은 걸 제공하고 싶은 마음이 생기지만.. 잘 참아보자.





지금도 팀으로 사이드 프로젝트를 진행하고 있는데 어려우면서도 참 배우는 점이 많다. 또 다양한 사람들과 얘기하는 기회도 되어 요즘엔 이 재미로 사는 것 같다.


지금까지는 회사 일에 큰 부담이 없어 본업과 사이드 병행하는 게 가능했는데.. 앞으로도 이렇게 할 수 있을지 차츰 걱정이 되긴 한다.


그래도 결국엔 병행하는 방향으로 나아가지 않을까 생각한다. 그만큼 사이드 프로젝트는 재밌고 본업에도 꽤 도움이 된다.


소속 없이 나를 설명할 수 있는 사람이 되기


올해 나의 목표인데 이걸 이루려면 사이드 프로젝트를 조금 더 열심히 해야 한다. 이룰 수 있을지는 모르겠지만 목표가 높으면 그만큼 성취도 따라오지 않을까 싶다.


미루고 미루다 결국 설 연휴에 글을 완성하게 되는데.. 제 글을 읽어주시는 분들을 포함하여 함께하는 모든 분들이 새해엔 더 잘 풀렸으면 좋겠다!


오늘도 긴 글 읽어주셔서 감사합니다!

- 꾸벅 -


매거진의 이전글 물 들어올 때 노 젓지 않은 죄
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari