사이드 프로젝트개발팀을 굴려보자(1) - 팀 빌딩, 목표, 지속가능성, 주제

 

사이드 프로젝트 개발 팀 Dope를 만들고 운영하며 작성한 회고록입니다.

(현재 글) 사이드 프로젝트개발팀을 굴려보자(1)  - 팀 빌딩, 목표, 지속가능성, 주제

사이드 프로젝트개발팀을 굴려보자(2)  - 협업

시간이 흘러갈수록, 대학교는 학문적인 목표를 가지기 보다는 취업사관학교 또는 학원의 포지션으로 점점 변하는 것 같다. 그렇지만 아직까지도 대학에서 배우는 것은 실무와는 조금 거리가 멀다. 실무에서 사용되는 도구들에 대해서 배우지 않고, 깊게 배우지 못한다. 그렇다고 학생들이 실무에서 사용하는 것을 그대로 따라해 보고, 그 경험을 미리 할 수 없는걸까?

 

사이드 프로젝트를 굴려보자.

 

개발팀으로서의 팀의 목표

팀의 목표는 다음과 같다.

1. 실제로 현업에서 사용하는 개발 환경으로 프로덕트 개발
2. 체계적인 협업
3. 코드 퀄리티
4. 테스트 코드

실제로 Pre-A에서 약 5억을 투자 유치한 스타트업이라고 생각하고, 생산성과 코드 품질에 신경쓰면서 프로덕트를 개발한다고 가정한다. 완벽한 비즈니스 모델과 시장가능성을 가지고 있다고 생각하고, 기획이나 운영적인 측면보다 실제 프로덕트가 개발되는 과정에 최대한 집중한다.

• 완전하지 않은 사업계획서
• 시니어 없이 귀여운 신입 개발자로 이루어진 개발팀
  • 디자이너와 기획자없음.

지속가능성

지치지 않는 팀을 만들자

이런 사이드프로젝트 팀에서 가장 중요한 것은, 팀의 지속가능성이다.

이 그룹에서 시간을 투자한다고 해서 월급을 받는 것도 아니며 이 팀에 참가하는 동료들도 열심히 할 것이라는 보장이 없기 때문에  때문에, 팀원에 대한 신뢰와 지속적인 동기부여로 지속가능한 팀을 만들어야한다.

 

다른 구성원을 신뢰 할 수 있는 환경을 만드는 방법은 여러가지가 있다.

 

1. 계약과 월급

자본주의 세상에서 일반적인 방법이다. 회사에서 당신의 능력과 시간을 돈으로 사고, 그것을 계약하는 형태이다.

그러나 자금이 없는 사이드 프로젝트 팀에서는 불가능하다.

 

2. 좋은 팀원을 모은다.

정말 간단한 룰이다. 뜬금없는 룰 같지만, 내가 이번 팀을 만들면서 가장 공을 들인 부분이다.

 

본인 혼자 자기계발에 시간을 투자하고 일에 대한 pride가 있는 사람은, 어떤 조직에 들어갔을때 주어진 일만 하지 않는다. 본인의 skill up과 회사에 기여할 수 있는 일의 방향이 같다면, 위에서 시키거나 본인의 일이 아니더라도 적극적으로 해결하려고 한다. 이런 사람들이 스타트업이나 사이드 프로젝트 팀에 들어왔을때도, 기획자가 없으면 기획자의 자리를 메꿔주며 PM이 없으면 PM의 자리를 메꿔주며, CTO가 없으면 CTO의 자리를 메꿔준다. 그래서 특히 작은 조직일수록 이런 일당백을 하는 인원들이 필요하다. 그저 나의 발전과 프로젝트 진행에서 오는 성취감 만으로도 충분한 동기부여가 되는 그런 팀원이 필요했고, 자세한 팀빌딩에 대한 이야기는 밑에서 서술한다.

 

기업에서 인사팀까지 만들고 어마어마한 비용을 투자하는 것도, 일을 믿고 맡길 수 있을 정도로 신뢰할만하고 좋은 인력을 뽑기 위해서이다.

 

3. 팀 문화

팀 문화는 팀원들이 이 팀에 애정을 갖고, 팀원들과 으쌰으쌰하며 동기부여를 할 수 있게 만들어준다.

요즘 테크 기업들의 채용 공고를 보면 팀 문화에 대해서 굉장히 강조하고 CCO(Chief Culture Officer)라는 직책도 있더라.

 

기업에서 대표적으로 내세우는 팀 문화는 무엇일까? 당근마켓의 팀 문화에 대해 살펴보고, 적용 가능한 항목을 팀에 적용했다.

https://team.daangn.com/culture/

당근마켓의 페이지에 있는 팀 문화

소통, 자율과 책임, 성장

 소통

• 직급이 없어요 : 직급이 없다! 나는 팀 전체를 리딩하는 PM이지만, 그냥 의사 결정을 최종적으로 내리는 사람일 뿐이다.
• 영어 이름을 사용해요 : 우리는 닉네임제를 도입했다. 닉네임제는 어색한 분위기를 한 층 해소해주고, 나이 차이에서 오는 장벽도 없애준다.
• 모든 정보를 공유해요 : 우리 팀의 슬랙에는 총 18개의 채널이 있다. 보통 슬랙을 사용하면, 본인과 관련된 채널에만 초대되어서 사용하게 되는데, 모든 인원을 모든 채널에 다 초대했다. 그리고 팀원들이 직접 채널의 알림을 관리하도록 했다. 프로젝트를 진행하는 총 인원이 7명이라서 가능한 방법이였고, 어떤 의사결정에 대한 토픽이 열렸을때, 누군가 지나가다가 붙잡여서 같이 토론을 할 수 있어서 좋았다.

우리 팀의 슬랙 채널들

 

자율과 책임

• 스스로 업무를 선택하고, 규칙 없이 스스로 판단해요 : 작으면 작은 팀일수록, 모두가 리더가 되어야한다고 생각한다. 규율을 최소화하고 규율 위에 자유로 맡기며, 구성원들이 직접 작은 부분들을 판단하고 실행에 옮길 수 있게끔 환경을 만들어줘야한다. 나(PM)의 의견은 '결정'이 아닌 조직원 중 한명의 '의견'일 뿐이라는 것을 계속 어필하고,  팀원들에게서 의견을 이끌어 낼 수 있도록 적극적으로 의사를 물어봐야한다.

 

성장

• 나보다 뛰어난 동료가 있어요, 우린 팀으로 일해요 : 나보다 뛰어난 동료는 없다. 개발자 시장 전체에서 봤을때, 우리는 모두 고만고만한 실력을 가지고 있다. 그렇기 때문에 하루에 한 번 이상 특정 부분에 대해 앎과 모름이 갈린다. 어떤 문제가 주어졌고 그 문제를 이것저것 찾아서 해결했다고 했을때, 그것을 해결한 사람은 해당 부분에 대해서 다른 사람들보다 뛰어나다. 그러면 해당 부분에 대해서 팀원들과 공유하고, 같이 성장한다. 이것이 이상적인 학습 공동체의 힘이다. 
• 즐겁게 일하고, 크게 성장해요 : 이 일에 대해 스트레스를 받지 않는다! 위에서 뭐라고 하는 사람도 없고, 우리의 목적은 프로젝트의 완성이 아닌 개인의 발전에 더 가깝기 때문에 시간에 쫒길 일도 없다. 그리고 개인의 발전을 위해서 일하기 때문에, 모두 크게 성장했음을 느낀다. 실제로 팀원들과 각자 1:1로 대화할 일이 있으면, 항상 "프로젝트 좀 어때?" 라고 물어본다. 현재 이 글을 작성하고 있는 5주차까지도, 팀원들이 많이 성장했고 진심으로 이 환경에 감사하고 있음을 느낀다.

 

이렇게 명시된 문화들은 당근마켓의 팀 문화를 보며 재정의했다. 그런데 이것만으로는 사람들이 성장을 하며 즐겁게 일을 할 수는 있어도, '재미있게' 일을 할 수 없다고 생각한다. '재미있게' 일하기 위해서는 구성원들 사이의 어색함을 없애야하고, 대화를 할 때마다 웃음소리가 들려와야한다. 여기에서 중요하게 생각했던 것이 팀원들이 함께 즐길 수 있는 '컨텐츠'인데, 돈이 없는 조직에서는 사람이 컨텐츠가 되면 된다. 온라인에서 일하기 때문에 할 수 있는 것들이 있다.

 

"컨텐츠가 없으면, 내가 컨텐츠가 된다!!!"

팀원들과의 즐거운(?) 소통

 

 

4. 그리고 규칙

지속 가능한 팀을 위해서는 조금의 다음 규칙들이 필요하다.

 

규칙

 

출퇴근시간

평일 오전10시 ~ 오후4시에는 Gather town에 상주

월급도 안주면서 이 팀에는 출퇴근시간이 있다.

 

이 시간은 커뮤니케이션을 원활하게 하기 위한 시간이다. Gather town에서 마치 실제 오피스에 있는 것처럼 일하고 있는데, 해당 시간에는 즉각적인 커뮤니케이션을 원활하게 할 수 있는 시간이다. 뭔가 궁금한게 있으면, 바로 게더타운에 가서 벨을 누르고 바로 붙으면 된다. 기획과 정책에만 시간을 할애하는 사람이 없기 때문에 즉각적인 의사결정과 피드백이 필요한 우리의 환경에서 반드시 필요한 시간이다.

 

물론 팀에게 이 프로젝트에 투자하는 시간을 반 강제로 할애하기를 기대했던 점도 있다. 그러나 이것에 대해서는 사실 큰 기대를 하지 않았다. 왜냐하면 팀원 하나하나를 전적으로 믿고 신뢰하기 때문이다. 다음 팀 빌딩을 읽어보면, 왜이렇게까지 팀원을 신뢰하는지 알 수 있을 것이다.

 

 

커뮤니케이션 룰

gather town 뿐만 아니라 기본적으로 slack 메신저를 통해 소통했고, 노션과 git wiki를 문서화 도구로 사용했다.

 

질문이나 의사결정이 필요하면, 다음과 같은 기승전결을 따른다.

1. 알맞은 슬랙 채널에 정리하여 질문 (포지션, 주제 별로 나뉘어 있다)

2. gather town 미팅 시간 잡기

3. 자유롭게 회의

4. 결론을 slack thread에 작성 후 종결

5. 결론의 내용이 길어지거나, 팀원과 공유해야 하는 내용이라면, git wiki나 notion에 정리

 

커뮤니케이션 룰이 필요한 이유는, 커뮤니케이션 비용을 절감하기 위해서다. 커뮤니케이션 비용은 생각보다 사람을 지치게 하고, 만약 여기에서 문제가 발생하면, 추후에 다른 비용들을 상승시킨다.

• 질문에 대해 잘 정리하고 생각해보면, 답변이 질문에 있는 경우도 있다.
• 이전에 나왔던 주제에 대해 다시 묻고 똑같은 과정을 거쳐 똑같은 결정을 내린다면 문서화에 문제가 있는 것이다.

개발 관련 규칙

다음 포스트에서 협업에 대해 글을 쓰며 중점적으로 다룰 것 같다.

일단 우리 팀에서는, 무조건 테스트코드를 작성한다. 스프린트 6 정도 

 

팀 빌딩

우리 팀은 다음과 같이 구성되어 있다.

• 백엔드 개발자 (3명) - Spring
• 프론트 개발자 (2명) - React.js
• 안드로이드 개발자 (2명) - Kotlin

사이드 프로젝트 치고는 꽤 많은 인원이고, 나도 이렇게 많은 인원을 관리하며 프로젝트를 성공적으로 이끌어 나갈 수 있을지 의문이였다. 그러나 초석만 잘 다져놓으면, 팀 빌딩 이후의 관리에 대해서 크게 많은 cost가 들어가지 않는다. 내가 중요하다고 생각되는 점을 몇 개 적어본다.

 

1. 개개인의 의지

주변에서 데려올 수 있는 최고의 사람들을 데려오자

서론에서 언급했듯이, 대학은 취업사관학교 혹은 학원에 비슷해지고 있다. 그래서 대학에서의 인적 네트워크가 좀 더 중요도가 높아지는 것 같다. 학과 생활을 하다 보면, 뭔가 혼자서 끄적끄적 거리고 있는 친구들이 있다. 본인의 의지로 학교에서 배운 것 외에 다른 것을 공부하거나, 방학에도 시간을 내서 혼자 프로젝트를 하는 친구들이 있다. 이런 고급 인력들을 데려올 수 있다면, 개발 파트 하나와 팀 내에 한두명 정도는 맡기고 진행해도 된다. 이런 친구들을 잘 기억해두고, 프로젝트를 함께하자고 권유해보자. 월급을 주지 않는 이런 프로젝트일수록, 인원 한 명 한 명이 중요하다. 

 

나는 대학교 1학년때 여기저기 빠지지 않고 뛰어다녔고, 학과에 있는 150명의 얼굴과 대략적인 성향을 모두 기억한다. 현재 이 프로젝트에 참여하고 있는 6명의 인원은, 적어도 학과에서 만큼은 열심히 살아가는 부류에 속하고, 혼자 가만히 냅둬도 굴러가는 사람들이다. 이런 사람들이 팀에 합류해야, 능력 없는 관리자(나)가 리딩하는 팀이더라도 잘 굴러간다.

 

2. 팀의 목표에 대한 전달

철저하게 개인의 자기계발을 위한 팀

이 팀이 최종적으로 어떤 것을 목표로 하는지에 대해서 정확하게 알려줘야한다.

• 개개인의 자기계발을 위한 팀
• 창업을 위한 팀
• 공모전/해커톤을 위한 팀

위의 세가지는 개발 프로세스나 일정에서 굉장히 많은 차이가 나며, 배울 수 있는 것과 얻을 수 있는 것이 명확하게 다르다. 이 팀의 목표와 성향에 대해 정확하게 전달해야 구성원들이 이루고자 하는 목표의 방향성이 일치하고, 팀의 일정과 프로세스를 정확하게 조율할 수 있다.

 

 

3. 이 팀과 내가 제공할 수 있는 것에 대한 전달

실제 현업과 똑같은 협업 방식과 프로세스

"당신이 이 팀에 들어온다면 ..."

상대방이 이 팀에 합류했을때, 어떤 것을 얻을 수 있는지에 대해서 정확하게 전달해야한다. 자기계발을 혼자 하는 것이 아닌, 우리 팀에 들어와서 해야하는 이유를 설명할 수 있어야한다. 혹시라도 이것이 설명이 안된다면, 나 중심의 이기적인 팀이 아닌가 생각해보자. 팀에 합류하면 다양한 사람들이 있고, 다양한 의견들이 충돌하면서 많은 스트레스와 시간이 소모된다. 이런 것을 극복했을때 개인에게 어떤 발전이 있을지 기대해도 좋은 점을 적극적으로 어필해야한다.

 

그리고 '내가' 이 팀과 당신을 위해서 무엇을 해줄 수 있는가도 중요하다. 팀에 있어서 리더인 나의 역할은 무엇인지, 어떻게 많은 인원들을 리드하고 관리할 것인지 솔직하게 털어놓자.

 

당신에게 내가 제공할 수 있는게 생각나지 않는다면,  팀에 합류할 수 없습니다.

초기 팀 빌딩 당시, 사실 이 팀에 UI/UX 디자이너를 데려오고 싶었다. 그래서 커뮤니티에 공고를 올리고, 10명 이상의 학부생과 직장인들을 직접 interview 했다. 그러나 이런 저런 사람을 만나고 아무리 생각해도 UI/UX 디자이너가 팀에 합류했을때, 일정을 어떻게 조율해야할지, 어떤 방식으로 협업해야할지, 어떤 경험을 줄 수 있는지에 대해서 떠오르지 않았다. 돌고 돌아 생각했을때, 겉보기에 괜찮아 보이는 결과를 얻기 위한 개인적인 이기심에 디자이너를 데려오는 것이 아니던가. 결국 얼마 안가서 디자이너를 데려오는 것을 깔끔하게 포기했다.

 

이 프로젝트 이후에, 내가 완전히 다른 포지션에 대해서 이해도가 생기고 여유가 생기면 그 때 다시 데려오면 되겠다는 생각이 들었다. 팀원 한 명을 더 관리하기 위해서는 관리자의 더 많은 역량과 공부가 필요하다.  

 

디자이너를 기대하고 있던 클라이언트 개발팀원들에게는 정확한 프로세스나 목적 없이 디자이너를 데려왔을때, 팀과 개인에게 어떤 악영향을 끼치는지 미리 경고했었다.

 

4. 위의 내용을 가지고 많이 대화하기

지금 대답하지 마. 물어보고 싶은게 있으면 얼마든지 연락주고, 일주일 이상 고민해보고 합류해.

우리 프로젝트는 최소 10주짜리 프로젝트다. 한 주에 최소 30시간 이상 투자해야하며, 금쪽같은 20대 초반에 3달을 투자하는 것은 굉장히 부담스럽고 생각보다 리스크가 큰 일이다. 개인적인 생각으로, 기업이 사람을 채용하는 것 보다 더욱더 리스크가 크고 부담스러운 일이라고 생각한다. 그렇기에 나도 엄청난 책임감을 가져야하고, 상대방도 신중에 신중을 기해야한다.  때문에 한 치의 오차 없이 나와 팀의 비전이 전달되도록 많은 대화가 필요하다.

 

그리고 팀 합류 권유를 위한 약속이 잡히면, 항상 내가 밥이나 커피를 사줬다. (요근래 기업에서 면접비를 주는 이유와 동일하다)

 

프로젝트 주제

팀에 대한 이야기가 끝났다. 이제 프로젝트 주제에 대해 잠깐 소개하고 이 글을 끝내려고 한다.

 

브레이킹
 -모두가 기자가 된다 -

 

이 서비스의 이름인 '브레이킹(Breaking)'은, 긴급 속보를 뜻하는 breaking news에서 가져왔다.

한 줄로 요약하면, '제보 기반 SNS' 이 맞겠다.

 

핵심 기능들은 다음이 있다.

• 일반 시민들이 해당 SNS 처럼 글을 작성하여 공개적으로 제보하기
• 언론사들은 해당 글과 미디어의 저작권을 구매하고, 뉴스나 기사에 활용
• 언론사에서 필요한 미디어를 상금을 걸고 시민들에게 대신 수집을 요청하는 '브레이킹 미션'

 

군생활 도중 팀원 중 한명과 창업 경진 대회에 나가고자 기획한 아이템이였고, IR 발표 이후에 모 벤처캐피탈에서 직접 시드투자 제의도 받게 되었던 아이템이다.