[💬] 초짜개발기: 개발 환경 구축 [장문주의]

[골든정답(rhfemswjdekq)]

안녕? 나는 학식을 벗어난지 이제야 조금 지난, 초짜 개발자야.

(친)동생하고 같이 게임을 만들게 되어서 내가 작업하는 주요 과정을 적어보려고 해.

얼마나 이걸 자주 쓸지 모르겠는데...ㅋㅋㅋ 오늘은 드디어 첫 삽을 뜬 기념으로 구축하는 프로젝트 관리 환경에 대해 적어보려구.

첫 삽 = 유니티 2018 설치. 오홍홍 조와요.

여기에, 나름 개발 프로젝트를 여러번 진행해본 사람도 있을거구, 아닌 사람도 있을거야.

하지만 내가 관심법으로 보니까, 아닌 사람도 많더라구.

또, 게시글들을 대충 검색해 보았는데, 프로젝트 관리를 위한 구성을 적은 갤럼은 없길래 적어보기로 했어.

프로젝트 관리는 4년제 대학을 다니면, 1년짜리 과목으로 갈만큼 심오한 내용이지만, 나는 내가 아는 내용과 실제 적용한 내용만 간단하게(?) 정리해 볼게.

마침 오늘 같이 작업 하는 동생(친동생임)한테도 이걸 설명해줘야 하니까 겸사겸사 이거 보여주고 끝내려구.ㅋㅋㅋ

우선 나는 게임 개발은 처음이야. 하지만 만류귀종 이라고 모든 개발워크로드는 사실 같다고 생각해.

내가 사용할 툴은 우선, GIT, Trello, Slack 이야.

맞어, 이 세개를 조합한 글은 없더라도 각각은 모두들 많이 칭찬하고 있더라구. 하지만 저 새개는 조합하면 훨신 강력해져.

(사실 이미 소개한 글이 있을지도 몰라. 아무튼 난 검색해봤는데 못봄. 그럼 없는거임. 아무튼 그럼)

우선, GIT에 대해서 알아보자.

너희는 GIT을 사용하기 위해 어떤 방법을 사용하고 있어?

유명하기로는 GITHub 이 있지. 하지만 Private 저장소를 위해서는 돈을 내야 해.

학생이라면, GitHub student pack을 사용하면 무료로 Private 저장소 사용이 가능하니까 알아봐~

https://education.github.com/pack

Private 저장소 이용권리 이외에도 제공해주는게 많아!

하지만, 안타깝게도, 세상엔 학생만 있는게 아냐.

그럼, 내가 돈을 내야 할까? 

그런 여러분을 위해, BitBuckit 이라는 훌륭한 사이트가 있습니다.

-아마 이미 알거라고 생각하지만.

https://bitbucket.org

BitBuckit 은 Atlassian 이라는 회사가 유지하는 무료 Git 서버야. GitHub에 비해 다소 부족할수 있지만 충분한 기능을 제공해 주고 있어.

앞으로 내가 활용할 앞서 적은 세 서비스를 연결하기 위해 필요한 기능도 충분해!

심지어 트렐로 하곤 기본적으로 연동 가능하지!

-이건 뒤에 트렐로 설명할때 다시 언급할게.

우선, 개인 서버에 Git 서버를 설치했을때에 비해 큰 장점이 있어. 바로 WebHook 이라는 기능이야.

(GitLab을 설치하는 경우는 역시 빗버킷과 같은 이점이 있어! 하지만 해보면 매우 귀찮아.. 게다가 루비 기반이라 귀찮기만 한게 아니라 좀 지읒 같아)

(요즘엔 깃랩도 제공해주는 서버 있던데, 깃랩 시발 로 검색해봐. 서버가 터져나간단 소식 투성이임 ㅋㅋㅋ 내가 해보고 하는말이야, 그냥 빗버킷 써...)

WebHook은, 특정 이벤트가 발생했을 때 이벤트가 발생했음을 연결된 사이트 등에 알려주는 시스템 이야.

웹훅 을 이용해서, 깃에 푸시 되면 자동으로 빌드 테스트를 한다거나 하는게 가능해.

다음으로 좋은 기능은 Issue Tracker 야 이슈 트래커는 트렐로와 연동해서 사용하기 좋아.

프로젝트에 특정 이슈가 발생했을 때, 담당자와 중요도 그리고 이슈의 종류를 명시해서 작성해 놓을 수 있어. 그렇게 작성한 이슈들은 리스트업 되어 있다가, 해결한 이후에 닫을 수 있어. 그렇게 이슈들을 발견할때마다 리스트업 해놓고 하나 하나 해결해 가는거지.

그럼, 우리는 왜 GIT을 써야 할까?

이건 당연한 얘긴데, 소스코드의 형상관리를 위해서야.

형상관리 라는건, 간단하게 생각하면, 항상 정상작동하는 코드를 가지고 있어야 한다는 뜻 이야.

만약 현재 작동하는 버전 0.16.8 이 있어, 그러면 Git에서 제공하는 Tag기능을 이용해서 0.16.8을 태그로 만들거야. 그러면 이제 아무리 코드를 작업하다가 터뜨려도, 0.16.8 버전의 소스코드는 남아있는거지. 

항상 정상작동하는 코드를 가지고 있는건, 개발하는데 있어서 앞으로 설명할 에자일 이라는 기법에서 중요하게 다뤄지는 내용이니까 명심해줘.

Git을 이용해서 Branch나 Tag를 이용, 항상 정상 작동하는 버전의 관리를 유지해야 해!

다음으로 트렐로로 넘어갈게,

트렐로는 간단하게 말하면, 온라인 보드야. 그 보드에는 메모지 역할을 하는, 다양한 리스트들이 있고, 여기에 할 일들, 또는 한 일들 등을 정리해서 올리게 돼.

트렐로를 사용해서 한 일. 할 일. 언젠간 해야 할 일. 등을 정리하면 끝없이 이어지는거 같은 개발에 있어서 매번 작은 목표와, 작은 목표를 성취할 수 있어서 힘이 돼.

역시 이때도, 앞서 말한 정상 동작하는 버전을 유지하는게 중요해.

각 작은 이슈의 해결은 별도의 Branch에서 작업하고, 정상 동작이 확인된 다음에야 Master Branch에 머지 하는거야.

이 와중에, 해결만 하는게 아니라, 해당 단위 코드를 최대한 깔끔하게 만드는 과정이 포함돼! 이렇게 하면, 나중에 코드를 정리하는 수고를 피할수 있어.

코드가 이미 전체 규모의 코드에 적용된 다음에 정리하는건, 처음 적용시에 정리하는거에 비해 몇배의 노력이 들어.

-> 내 말이 아니라, 개발론에서 일반적으로 말하는 이론이야!

그리고, 한 규모의 해결이 되어서 버전업을 할 때에는 현재의 Master Branch를 Tag로 버전업을 해주는거야.

이렇게 계속, 작은 규모의 개발을 하고, 이걸 다시 정상 동작하는 버전에 합치는 과정을 반복하는 개발 방법론을 애자일 이라고 해.

애자일 에는 이것 이외에도 커뮤니케이션 방법을 포함한 여러가지 많은 방법론이 포함되는데, 나중에 기회가 되면 소개해 볼게.

그럼 다시 애자일로 돌아와서, 애자일(Agile)방법론은 기존의 폭포수 모델(워터폴, Waterfall) 모델과 작업 수행 순서에서 큰 차이점을 가져.

기존의 폭포수 모델은 사실 아주 큰 기업 단위의 개발에서는 잘 동작할지 몰라. 하지만, 팀 단위의 현실에서 폭포수 모델의 적용이 가능할지는 잘 모르겠어.

※폭포수 모델 이란? : 요구사항 분석 --> 디자인 --> 개발 --> 테스트 의 순서로 최종 결과물을 만들어내는 개발 모델

그럼 애자일 모델은 뭐가 다른걸까? 바로, 작은 단위의 개발 을 한다는 점 이야.

앞서 계속 강조했던, 정상 동작하는 버전을 유지 하는 것 이 어떻게 보면 애자일 방법론의 핵심인데

우선 가장 작은 목표를 설정해(디자인, 기획) 그리고 그 디자인을 충족하는 가장 간단한 버전을 만들어내는거지.

다음에 다음 목표 기능을 다시 설정하고, 그 기획(디자인)에 따른 기능이 추가된 다음 버전을 만들어.

앞서 적어온 개발 방법론과 같지?

이렇게 하므로서, 여러가지 이점을 가질수 있는데, 우선 계속 정상 동작하는 버전이 유지되기 때문에 성취감을 크게 느낄 수 있어. 또 기획자 또는 고객의 입장에서 계속 현재 동작하는 버전의 상태를 알 수 있지. 그니까 계속 플레이 가능한 버전이 유지 되니까, 실제 플레이 해보면서 의사소통이 잘못 됐던 부분이 있더라고 빠르게 수정 가능한거야.

여기서 각 한번의 개발 단위 반복을 이터레이션 이라고 해.

이 갤에 "1인 개발자를 위한 워크플로우" 레딧 번역이 있길래 흥미롭게 읽었는데, 거기서도 애자일 스러운 방법론을 많이 사용하더라구.

아까, 애자일은 커뮤니케이션 방법을 포함한 개발 방법론 이랬지?

그걸 위한 툴이 바로 Trello 야. 애자일 에서는 모두가 할 일, 하는 일, 완료된 일, 리뷰할 일 등을 적을 포스트 잇 을 붙일 보드를 사용하길 말하고 있거든

사족

물론, 정확한 애자일 방법론을 적용하지는 않을거야, 애자일을 정확히 적용시키는건 어려운 일 이거든. 심지어 애자일을 정확히 적용시키는 전문가도 있어. 애자일 자체에 대해 더 궁금하면, 애자일 선언문 이라는 키워드로 검색해봐.

Trello 사용법에 대해 말하기에 앞서서, 애자일의 특징에 대해 조금 더 말하고 시작해야 할거같아.

일반적인 폭포수 모델 방식의 개발 방법론에서 기획서는 목표에 도달하기 위한 커다란 절대 선에 가까워. 해당 기획에 맞춰서 각각의 작은 부품을 만들고, 이어붙이면 하나의 완성물이 나오는거지.

하지만 애자일 방식에서의 기획서는 하나의 제안에 가깝다고 생각해. 이미 기획되고 만들어진 내용도 필요에 따라 언제나 변할 수 있는 유연함을 가지지. 이 글을 적으면서 애자일과 워터폴의 차이가 잘 비교된 일터스트를 발견해서 첨부하려고 해.

위의 부품을 더해가는 과정이 워터폴 방식이고, 아래의 점점 발전해 나가는 방식이 애자일 이야.

이런 방법론은 요즘 많이 얘기 되는 "린스타트업" 에서 말하는 방법론 과도 일맥상통해.

다시 한 번 강조하게 되는 정상 동작하는 최소 버전에 대한 이해도 이 그림을 통해 보면 더욱 쉽게 이해될거야.

위 사진의 부품들 처럼 하나 하나의 부품을 유지 한다는게 아니라, 최소 기능만 동작하는 버전에서 점점 기능이 추가되는 버전으로 진화해 나가는 방식이라는 거지.

다시 트렐로로 돌아와서, 트렐로 화면은 각각의 큰 리스트와, 각 리스트에 포함되는 카드로 구성되어 있어.

각 카드는 다른 리스트로 쉽게 이동 가능하고, 각 카드에는 참여 멤버를 등록 한다거나, 작업의 종류에 따른 태깅도 가능해.

이 글을 작성하면서 참고중인 블로그에 올라와있는 사진이야. 트렐로와 유사한 기능을 제공해주는 JIRA 의 화면이야. 트렐로의 구성도 이와 크게 다르지 않아.

이 사진과 같이, 현재 할 일, 지금 하는 일, 완료된 일 순으로 카드를 정리하는거야.

아이디어나 개선점이 떠오르면 ToDo에 올려놓고, 작업중일때 InProgress로 옮기고 완료되면 리뷰로 옮겨서 리뷰 하고, 최종 머지 되면 Done으로 옮기는거지.

이런 방식을 통해서 애자일에서의 기능 추가 이터레이션을 반복하는거야.

여기서 애자일의 함정이 있어.

애자일은 다시 말하면, 무한반복이라고 할 수 있어. 결국 무한히 최종 완성에 도달하지 않는다는거지.

폭포수 모델의 기획에서는 완성된 도달점이 있고, 그걸 완성한다는 소기의 목적이 있잖아? 그리고 어떻게든 거기까지 가면 출시할수 있겠지.

하지만 애자일 모델에서 출시 시점 또는 완성 시점은 개인들의 판단이야. 욕심을 내려놓지 못하면 무한히 개발만 하다 끝날 수 있어.

또, 애자일은 매우 개발자 친화적인 방법론이야.

워크플로우의 많은 부분을 개발자 역량에 의존하고 있고, 디자인과 기획이 자주 변할수 있기 때문에 기존에 한번 작업한 리소스를 조합하는 방식에 익숙해진 팀 에서는
처음 도입시 다소간의 어려움이 있을 수 있어.

근데 내가 개발자 입장에서는.. 개발자의 개발된 내용은 기존에도 쉽게 자주 변했잖아...?

마지막으로 Slack이 남았네.

슬랙은 개발자들이 선호하는 작업 내용 전달 통로야. E-mail과 메신저의 중간 용도로 자주 사용해.

여럿이 같이 작업할 때, 연락방식을 카톡으로 할수도 있지만, 카톡은 개발 관련 이외의 잡담도 많이 하니까... 이야기한 내용을 다시 찾기 힘들 수 있어.

하지만, 슬랙은 해당 프로젝트의 내용을 위한 통로로 이용 되므로, 로그가 남을 수 있지.

물론 그런 용도면 E-mail을 사용하는게 일반적이어왔어.

하지만, E-mail 보다 메신저가 간편함이나 빠른 의사소통에 있어 장점이 있는게 사실이잖아.

그래서 두 매체의 장점을 흡수한 중간자적 존재로 등장한게 Slack이야.

Slack은 Trello 의 특정 카드를 불러오고, 디스커션 중에 바로 그 카드에 특정 인원을 태그 한다거나, 대화 내용을 첨부하여 카드를 바로 추가한다거나

Git의 이슈 또는 특정 커밋을 언급하면서 얘기한다거나 하는 내용이 지원돼!

그래서 Slack과 앞서 말한 두 개발도구를 연동해서 사용하면 좀 더 편리하지!

사실 더 길고 자세히 쓰고 싶었는데.. 쓰다보니 힘이 빠지네...

시간도 너무 오래 걸리고. 일단 이정도로 마무리 지을게. 그럼 모두 즐거운 개발!

사족 1 : 내가 잘못 작성한 내용이 있다면 가차없이 지적해줘!

사족 2 : 나도 전문가는 아니고, 내가 이런 생각으로 이렇게 구상했다 정도라서 질문은 못 받지만, 댓글로 달아주면 나도 한번 고민해 볼게.

[익명(58.125)]

와 너무 좋은글이다 추천버튼 누르는데 세상에.. 비추 2개 박혀있는거보고 깜짝놀랐다 글쓴이는 꼭 비추수는 무시하고 다음글도 작성해줬으면 좋겠다

[익명(211.226)]

인겜갤 역사상 가장 훌륭하고 위대한 글 개추준다

[익명(119.198)]

비추상태 보니까 분위기 안좋을때 첫글써서 학벌,지식 부심에 찌든 찌질이가 멋모르고 아는척하러 온거라고 오해받았나보네;; 요즘들어서 인디겜갤에 유용한 글이 꼭 필요했어 계속 이렇게 이야기해줘. 고마워!

[@@(175.223)]

초짜가 아니잖어 - dc App

[익명(183.101)]

진짜 좋은 글인데 여기다 비추박는건 정말 너무하네

[골든정답(rhfemswjdekq)]

[골든정답(rhfemswjdekq)]

좋은 댓글들 고마워!

[익명(1.229)]

초짜 환경 구축이라길래 방구석 치우고 컴퓨터 세팅하는건줄 알았는데 음... 잘 모르겠으니 아는 척 하고 추천 누르고걈

[설냥이(sulnyang712)]

개인적으로 아스나가 트렐로 상위호환이라고 생각함 - dc App

[설냥이(sulnyang712)]

아스나가 아니라 아사나 - dc App

[익명(211.105)]

즉 애자일 방식 = 얼리엑세스 방식 같은거임?

[익명(ohwooya)]

git서버 설치해보실분은 yona 설치 해보세요 갓갓임

[골든정답(rhfemswjdekq)]

ㄴ yona가 그 yobi가 네이버 내부 사정으로 개인프로젝트로 분리되면서 나온거 맞지? yobi때만 썼었는데 설치도 간편하고 좋았었어.

[골든정답(rhfemswjdekq)]

ㄴㄴ 애자일은, 얼리엑세스 처럼 출시 했을때보단 출시 전 부터의 개발 방식이야!. 물론 개발과정은 얼리엑세스 하고 유사하게 진행될거야. 굳이 얼리엑세스 하고 다르다고 얘기한 건, 아주 처음의 개발부터 정상적으로 동작 가능한 버전을 유지하고 개발하는게 중요시 되는 방식이라서 강조해봤어!

[골든정답(rhfemswjdekq)]

ㄴㄴㄴ 아, 아스나 아시는구나. 아사나는 이번에 처음 알게 되었는데, 좋아보인다! 난 트렐로는 빗버킷에서 바로 연동되서 편하더라구!

[헉해골이다(vipkill78)]

[임연수어(boxoffruits)]

ㄹㅇ 웃긴게 빗버킷+트렐로 쓰다보면 아틀라시안의 노예됨ㅋㅋㅋ 개발환경장사하는애들 다 머단함 - dc App

[도적코볼트(w9716www)]

추천. 머단한 글..