brunch

You can make anything
by writing

C.S.Lewis

by 스티브 Nov 18. 2019

팀 프로젝트 시작 백그라운드

개발 소모임에 진행한 프로젝트에 진행함에 따른 후기 입니다.

현재 오프라인 개발자 모임을 주관하고 있다. 개발 관련된 이야기를 하고, 사회적인 이슈에 대해 토론을 진행하며 개발 지식 축적과 커뮤니케이션 스킬을 향상 하려는 모임이다. 그러던 중 3개월 전 부터 멤버들끼리 안드로이드 어플리케이션을 만들어 보자는 제안으로 프로젝트를 시작했고, 최근 서비스 배포하는 과정까지 마쳤다. 비록 조금의 오류는 있었지만, 성공적으로 런칭까지 했다. 총 10주간 조금씩 시간을 할애하며 진행했고, 의외로 회사에서 배울 수 없었던 것을 많이 배웠던 시간이었다. 이러한 과정을 프로젝트를 시작부터 마무리까지 3단계에 걸쳐 글을 써 보려고 한다.

프로젝트 시작하게 된 배경

개발자 모임 멤버 중 한 명이 우리끼리 프로젝트 해보면 재밌을 것 같다는 의견이 있었다. 나도 회사 프로젝트 외에 개인적인 프로젝트를 한 번쯤은 해보고 싶었다. 같이 프로젝트를 시작 하게 되면 혼자할 때보다는 더 책임감이 생기기 때문에 끝까지 마무리 해볼 수도 있겠다는 생각도 들었다. 그리고 모두가 개발자이다 보니, 같이 프로젝트를 직접 만들면 서로 성장할 수 있는 포인트가 될수 있다고 생각했다.

나는 무엇보다 여러 개발자를 리드하는 역할을 해보고 싶었다. 지금까지 개발자로서 경력도 2년 차 밖에 되지 않고, 회사 규모도 적었다 보니 이러한 기회가 쉽게 오지는 않았다. 언젠가 개발팀을 혹은 회사를 이끈다면 겪을 수 있는 상황을 선행 학습할 수 있다고 생각했다.

그러나 위의 기대와 더불어 고민도 있었다.

시간을 규칙적으로 할애하는 것이 힘들다는 의견이다. 긴 시간 동안 프로젝트를 하려면 각자의 회사 혹은 개인 사정에 의해 중간에 시간 투자가 힘들 수 있다는 점이다.

서비스, 기술에 대한 공통 분모. 각자가 만들어보고 싶은 서비스, 그리고 기술 능력치도 다 다르다는 점이다. 서비스는 어느정도 협의를 볼 수 있겠지만, 기술에 대해서는 서로 조금은 다른 영역을 하고 있다보니 누군가는 처음 사용하는 기술을 배워야 했다.

이전 스터디와의 충돌 이전에 진행하고 있던 스터디 커리큘럼(개발이야기+토론)을 유지하거나 혹은 완전히 방향성을 바꿔야 했다. 모든 인원이 참여한다면 바꿀 수 있겠지만, 비참여 인원인 생길 경우 기존에 하고 있던 방식도 쉽사리 바꿀 수 없다는 점이다.

뒤로 갈수록 흐지부지 되지 않을까 걱정 사실 꾸준히 무언가를 마무리 하는 건 쉽지 않을 일이다. 더군다나 성향이 서로 다른 인원이 끝까지 잘 마무리할 수 있는 건 쉽지 않다. 그래서 프로젝트가 애매하게 중간에 사장된다면 차라리 시작도 하지 않은게 더 나을 수도 있기 때문이다.

이에 대해 나는 아래와 같이 제안하며 설득했다.

시간 할애에 대한 고민
우선 자율적인 참여를 기본으로 하고, 매주 각자가 참여할 수 있는 시간을 직접 산정하여 개발을 진행 하자고 했다. 이렇게 제안한 이유는 참여 시간이 적은 것 보다 각자의 스케쥴이 예측이 안되는 점이 더 문제가 될 수 있다고 생각 했다. 3개월 정도를 진행하다 보면 누군가는 사정이 생겨 시간을 적게 쓸 수 밖에 없다. 그렇다면 미리 공유를 하여 서로에게 피해를 최소한으로 하고, 프로젝트 전체 방향성이 예측 가능해야 한다고 생각했다. 나는 보통 비행기가 연착 됐을 때, 연착된 시간에 보다 미리 그 상황을 알지 못하는게 더 화가 난다. 조금 더 빨리 알았다면 공항 터미널에서 멍하니 기다리고 있지는 않을 테니 말이다.

서비스, 기술에 대한 고민
이번 프로젝트의 가장 큰 목적은 시행착오라고 이야기 했다. 이 프로젝트로 수익적인 면을 기대하기 보다는 대부분 업무 경력이 짧고 규모가 적은 회사에서 일하고 있으니, 여러 개발자가 협업을 하게 됨에 따라 발생할 수 있는 이슈에 대해 경험을 쌓자는 것이었다. 그래서 각자에게 회사에서 경험 해보지 못한 역할을 부여하고, 매주 서로에게 피드백 하는 시간을 가지자고 했다. 그래서 각자가 가지고 있는 문제점을 찾고 점점 해결해 나가면서 우리가 조금씩 성장하길 바라는 의도 였다. 이처럼 시행착오라는 타이틀을 목표로 했기 때문에, 최대한 기술 및 서비스는 단순하게 가려고 했다. 복잡도가 증가하고 새로운게 많을 수록 예측 불가한 변수가 많기 때문에, 이를 최소한으로 가자는 목적이었다. 따라서, 일전에 모두 안드로이드를 공부 해본 경험이 있어서 프론트엔드는 안드로이드 플랫폼을 선택했고, 서버는 제일 공통분모가 많은 Node.js를 선택했다.

스터디 대체에 대한 고민
만약 모두가 프로젝트 참여에 동의할 경우 커리큘럼을 프로젝트 진행으로 전환하고자 했다. 기존에 커리큘럼도 유지하고 프로젝트도 한다면 몰입도가 적어지고, 모임으로 인해 각자에게 너무 부담을 준다고 생각했다. 그리고 매주 리뷰를 진행해야 하기 때문에, 모임 시간 자체도 늘어날 수 밖에 없어서, 둘 중 하나를 택해야 했다. 모두 참여하거나 아니면 프로젝트를 시작하지 않거나 말이다. 결과적으로 1명을 빼고는 모두 참여하기로 했고, 1명은 프로젝트가 끝나면 다시 모임에 참여하기로 했다.

프로젝트 마무리에 대한 고민
이건 내가 잘하면 된다고 생각했다. 내가 결국 이 프로젝트를 리드하고 있으니 내가 역할을 잘해서 팀원들이 잘 따라와 준다면, 마무리까지 갈 수 있다고 생각했다.

결국, 프로젝트를 진행하기로 최종 결정하고 모임의 방향을 프로젝트에 초점을 두었다. 여기서 나의 역할은 이 프로젝트 총괄이었고, 우리는 아래와 같이 본격적으로 진행하였다.

프로젝트 전체 일정:
- 아이디어 선정 -1주
- 기획 정의 - 1주
- 서비스 설계 및 개발 - 10주

멤버 및 역할 구성:
-PM 1명
-안드로이드 개발 - 팀장 1명, 팀원 2명
-서버 개발 - 팀장 1명, 팀원3명, PM은 서버 개발도 참여

프로젝트 진행 방식:

- 아이디어 선정은 오프라인 회의로 진행했고, 각자가 준비해온 아이디어에 대한 협의를 하는 방식으로 진행했다. 프로젝트의 난이도, 흥미도를 기준으로 투표를 통해 최종적으로 '초성게임' 선정하였다.

- 기획 정의 및 서비스 설계도 오프라인 회의로 진행했고, 나는 전체적인 프로세스의 스토리 보드 정의, 프론트팀에서 UI 및 UX 설계, 백엔드 에서 DB 설계, 서버 인프라 설계, API 설계를 담당했다. 그리고 각 팀 별로 코드 컨벤션 및 사전 협의 해야할 사항들에 대해 정의 하였다.

- 개발은 주 단위로 전체적인 로드맵을 정하고, 이에 따른 세부 일정을 매주 각 플랫폼 별로 협의하여 각자의 Task를 정의 했다.

- 그리고 매주 개발 진행 사항에 대한 리뷰를 진행했으며, 이는 모두 온라인 화상 회의(행아웃)이를 통해 실시하였다. 회의는 각 플랫폼 별 1회, 전체회의 1회, 총 2회 진행하기로 정하였다.

- 플랫폼 별 회의는 각 팀원의 한 주간 진행한 Task를 리뷰, 차주 계획 수립, 팀원간의 피드백을 진행 하였다. 전체 회의의 경우 각 플랫폼의 계획 대비 진행 사항을 공유했고, 프로젝트 전체적으로 협의가 필요한 사항에 대해 의사결정을 하였다.

keyword