이 블로그 글은 첫 프로젝트를 진행하며 팀장으로서 생긴 이슈와 생각, 고민을 중점으로 썼으며

후에 초심을 잃지 않길 바라는 나 자신에게,
혹여나 처음 프로젝트를 접하는 분들을 위해 작성되었습니다.

- 차례

#1

• 팀 편성
• 프로젝트 기획(SR)
• 초기 셋팅

#2

• 1주차
• 2주차(End)
• 발표 준비
• 마치며..

팀 편성 - 발칙한 아재들

본인은 코드스테이츠에서 소프트엔지니어 과정을 탑승하여 마지막 코스인 First, Final 프로젝트 중 First 프로젝트를 진행했다.

코드스테이츠에서 팀편성을 하기 전에 설문조사를 실시하는데 거기엔
시너지가 나는 동료 3명, 함께하기 어려운 동료 3명 을 쓰게 되어있다. 이 곳에 내가 원하는 이름을 쓰면 코드스테이츠 측에서 전체 수강생의 니즈를 고려해서 팀을 짜주는 형식이다.(고생하는 구만..)

개인적으로 코스를 진행하면서 친구같이 케미가 어울렸던 3명을 썼다.
결과적으로 내가 썼던 3명의 친구들이 편성이 되었다.

후에 물어보니 
친구1은 본인, 다른 사람, 다른 사람.
친구2는 본인, 다른 사람, 다른 사람.
친구3은 "아무나 좋아용^^"
을 썼다고 한다.
아무래도 DB스키마 작업하듯 내가 연결고리가 된 느낌??

이렇게 팀 편성 후 팀장 선출을 시작했고,
이런 것에 시간을 끄는 것이 싫었던 본인이 팀장이 되었다.
(사실 모든 구성원의 연결고리인 나에게 몰아주었던 아재들 때문이기도 하지만..)

만약에 팀장을 뽑는 상황이 닥친다면 한번쯤은 시도해보는 것도 좋다고 한다.
자기 자신의 역량 강화와 취업에 있어서도 약간의 가산점이 있다고 합니다.

솔직히 말하면.. 조금은 팀장 하고싶었다 ㅋ
왜냐하면, 처음 이 구성원으로 팀이 되었을 때 뭔가 좋은 아이디어가 떠올랐기 때문!

이 팀이 확정된 직후 생각했던 것은 연결고리이다.

처음으로 하는 프로젝트는 당연히 퀄리티가 나쁠 수 밖에 없다.
그렇다면 여기서 해볼 수 있는 것은 무엇일까?

본인은 아이디어 승부라고 생각했고, 팀 구성원의 공통점을 찾기 시작했다.

공통점 : 30대 초반, 흡연 & 술을 좋아함, 발그레..@_@, 털털

왠지 팀의 대강적인 느낌이 오는 것 같지 않는가..
그렇게 우리는 발칙한 아재들(Pretty Uncles)가 되었다.

그렇다면 아저씨들이 좋아할만한 주제가 무엇이 있을까?
결국, 우리의 주제는 흡연이 되었다.

프로젝트 아이디어를 기획할 때는 절대로 해서는 안되는 것.
바로, 인터넷에 튜토리얼이 있는 것을 하면 안된다.
ex. youtube, instagram...
why? 튜토리얼이 있다는 것은 그만큼 다른 사람이 했을 가능성이 높고,
참고하지 않았다고 하더라도 튜토리얼에 대한 이미지가 박혀있을 수 있다.

프로젝트 기획(SR) - 완벽한 기획은 없다.

본인을 포함한 모든 새내기 개발자의 첫 프로젝트 과정에서 문제는 무엇일까?
바로, 못 올라갈 나무만 찾아서 쳐다본다는 것이다.

당연할 수 있다. 이것을 하기 위해 개발자의 길로 들어섰는데
막상 기회가 오니 터뜨려야 하지 않겠는가!

하지만 인생은 그렇게 핑크색이지 않다.

다시말해 First 프로젝트는 실패하기 위한 프로젝트
여기서 중요한 것은 어떻게 실패 하느냐이다.

초기에는 맵 API를 사용하여 국내에 있는 흡연부스를 띄워주는 컨텐츠를 기획했었다.

해당 컨텐츠가 존재하긴 하지만 그 수가 적었고,
우리 팀(발칙한 아재들)의 이미지 메이킹에 있어 좋았다고 판단했다.

하지만 기획단계에서부터 문제에 봉착하게 되는데.
정부의 금연정책으로 인해 그나마 있던 공공데이터가 2017년부터 업데이트 중지 되었기 때문이다.

만약에 공공데이터를 쓰고 싶다면 공공데이터포털에서 확인하고 진행하자.

실제로 서울시청에 전화걸어 여기저기에 전화를 돌려가며 문의를 해보고 받은 답변이다.

정부는 우리나라는 금연국가로 변화시키기 위해서 여러가지 금연정책은 만들어 놓은 반면,
흡연 정책은 담배세 인상, 과태료 밖에 없다. 즉, 흡연인을 위한 정책이 존재하지 않음.

"아니 그럴거면 담배를 팔지 마!" 라는 마음과 함께
아이디어 기획 전면 수정을 진행했다.

위의 마음의 소리를 담은 그 다음 아이디어는
기본적으로 흡연부스 아이디어는 가져가되
맵에 마커를 찍으면 그 마커가 찍힌 곳은 자신이 정복한 흡연구역이고,
흡연구역을 다른 유저에게 공유하는 흡연구역 공유플랫폼 이다.

물론 실제 서비스가 배포가 되면 여러가지 보완사항들이 있겠지만 초기 단계에서는
나름 정복시스템이라는 게임성과 흡연구역의 상세페이지의 방명록 시스템이라는 커뮤니티성을 녹아내렸다고 본인들은 만족할만한 아이디어를 기획했다.

그리고 서울시청의 답변을 들은 내가 
"그렇다면 흡연하는 사람들은 어디서 하면 되나요?" 라고 물었을 때 
"금연구역이 아닌 곳은 흡연구역으로 보시면 됩니다." 라고 했기 때문에 
금연구역을 분리해내면 큰 문제가 일어나지 않았다.

본인이 생각하기에 아이디어란 '타당성'이 있어야 한다고 생각한다.
자신에게는 흥미로운 주제이지만 보는 사람에 따라서는 "이게뭐야?"가 될 수도 있다.
그래서 만약 실제로 유저를 받아들이기 위해 배포하는 프로젝트에서는
더욱 더 치밀한 기획 & 계산이 들어가야하지 않을까?

초기 셋팅

다시한번 말하지만 이 첫 프로젝트를 실패하기 위한 프로젝트이다.
본인이 과정을 밟고 있는 코드스테이츠를 예를 들어보자.

왜 실패해야 할까?
1. Final과 다르게 First프로젝트는 작업기간이 2주이다.(본인은 설날이 겹쳐 많이 애매했다.) 그 기간안에 완성된 결과물을 내기엔 역부족이다.
2. 어쩌피 Final이라는 본 무대가 있으니 초반에 최대한 이런저런 이슈를 겪고,
그 해결을 Final에 녹여내기 위함이라고 생각한다.

그렇다면 어떻게 하면 좋은 실패를 겪을 수 있을까?
사람마다 그 리스트가 다르겠지만 본인은 다음과 같이 생각했다.

어떻게 하면 좋은 실패를 맛 볼 수 있을까?

• 일단 배포까지는 끝내놓자.(이 프로젝트의 끝까지는 시도하고 해결해보자.)
• 이슈가 생기면 그 이슈에 대해 정리해놓자.
• 팀원들과 최대한 부딪혀본다.(기분나쁜 부딪힘만이 있는 것이 아니다. 협업이란 과정 속엔 기쁨, 분노, 고통 그 모든것들이 존재한다고 생각한다. 그것을 모두 맛 봐야 다른 사람과의 협업 속에서 보이는 자신의 진면목을 볼 수 있다고 생각한다.)
• 그리고 여태까지의 자신을 최대한 객관적으로 평가하자.(너무 후하게도, 너무 짜게도 평가하지 말고 객관적으로!... 이게 어렵지 ㅠ..)

자, 이제 초기셋팅의 서론이 길었으니 본론으로 들어가자.

본인이 경험했던 초기셋팅은 크게 4가지로 나뉜다.

• 깃 허브
• 팀 커뮤니케이션
• 기술스택 셋팅
• 초기 배포

그 중 깃 허브와 초기 배포과정을 다뤄 보겠다.

깃 허브

개발에 대해 공부한 사람은 어느정도 깃 허브를 잘 알겠지만
특히나 프로젝트할때 깃 허브는 협업에 대한 공간을 만든다고 생각하면 좋다.

앞으로 이 곳은 자신의 팀이 코드에 대해 리뷰 & 수정 하게되는홈페이지가 될 것이다.

홈페이지라고 하면 어느 정도 감이 오겠지만 깃 허브의 레포지토리를 꾸미는 것도
초기 셋팅에 들어간다.

레포지토리를 꾸미는 방법은 많겠지만 본인이 알고있는 것은 두 가지다.
Read Me : 레포지토리의 대문. 첫 장. 얼굴이라고 생각하면 되겠다.
WiKi : 레포지토리의 설명서. 우리의 프로젝트가 어떻게 구성되어있는지를 보여줄 수 있다.

깃 브렌치 셋팅에 대해선 후에 다른 블로그로 다루고, 이곳에선 어떠한 항목들을 넣었는지를 보겠다.

(1) 레포지토리에 팀원 초대하기 :

먼저 레포지토리의 Settings에 들어가서 Manage access에 들어가야한다.

처음 Manage access를 들어가기 위해서 비밀번호가 필요하다.
들어가서 팀원의 아이디를 추가하자.

추가하고 나서는 팀원의 아이디 옆 Role: Write를 해야 함께 레포지토리를 수정할 수 있다.

(2) 프로젝트 협업 셋팅(이슈 & 마일스톤 & 프로젝트)

앞으로 협업에 힘을 실어줄 이슈 & 마일스톤 & 프로젝트를 설정해보자.

이슈
제일 처음엔 Settings에서 Options에 있는 Issues의 Set up templates를 설정해야한다.

이 곳에서는 각 이슈 템플릿을 만들어서 템플릿 별로 알맞는 이슈를 프로젝트에 등록한다.

예를들어, 태스크카드를 만들어 프로젝트를 잘게 나눠 할 작업을 계획한다던가,
프로젝트 중 발생되는 이슈만 따로 만드는 템플릿을 만들어 프로젝트 지적 재산인 이슈들을 따로 모아 놓을 수 있다.

태스크 카드 만드는 형식은 여러가지가 있다.
본인은 아주 기본적으로 만들었기 때문에 이미지만 보여주고 넘어가겠다.
(마크업 형식이니 참고하면 좋겠다.)

마일스톤

마일스톤은 현재 진행 위치를 확인할 수 있는 장치이다.

Issues탭에서 Milestones를 눌러 셋팅하면 된다.

셋팅은 어렵지 않으니 자세한 설명은 생략하겠다.

프로젝트
프로젝트는 레포지토리 기본 탭에 있다.

이곳에서는 프로젝트를 나눠서 무엇무엇을 진행할 것인지를 설정할 수 있는데,
본인은 주 차로 나눠서 설정했다.

설정이 처음 해보는 사람에겐 복잡하게 보일 수 있는데
그냥 쉽게 설명하자면..

Project template에서 Basic kanban을 설정하면

자동으로 To do, In progress, Done 콜럼이 생기는데
문자 그대로 할 것, 하는 중, 한 것 들을 나눈 것이라고 생각하면 된다.

(3) 위키 꾸미기

앞서 말한대로 위키는 프로젝트의 설명서이다.
이 곳을 정성스럽게 꾸미면 보는 사람도 프로젝트의 정성을 느끼게 될 것이다.
(본인은 다른 사람들처럼 휘황찬란하게 꾸미지는 못했다.)

위키에는 프로젝트에 중요하다고 생각하는 요소들을 넣으면 될 것이다.

본인은 기본적인 요소를 제외하고 이슈를 추가했다.
이 이슈란에는 프로젝트를 진행하면서 생긴 이슈들을 위키에다가 매일매일 업데이트했다.

이슈들은 왜 따로 모아놨나요?
보통 자신이 작업한 이슈를 자신의 블로그에 쓰지만 우리팀은 필수적으로 하루의 작업 끝에 이슈를 쓰도록 규칙을 정했다.
그래야 그 당시의 자신이 이슈를 만나면서 해결했던 기분&경험을 그대로 레포팅할 수 있다고 생각했다.
또한, 2주라는 짧은 프로젝트 속에 우리가 가져갈 수 있는 지적 재산이라고 생각했다.

초기 배포(AWS)

사실 깃 허브 내용으로 블로그 글이 길어져 배포에 관해선 따로 글을 쓰겠다.

하지만 여기서 이 글을 볼 후배님들 & 나 자신에게 다시한번 충고하자면

HTTPS:// 내가 원하는 도메인.com 을 꼭! 서버&클라이언트에 띄운 다음에 진행할 것을 추천한다. 

AWS 배포과정은 생각보다 어렵다.
이 과정을 먼저 끝내놓지 않고 진행한다면 후에 프로젝트에 차질이 생긴다는 것을 확신한다.

AWS에서 배포과정에 사용되었던 것들
클라이언트 : S3, Cloudfront
서버 : EC2, RDS
공통 : Route53, Certificate Manager