1차 회의 이후 변경 사항 (11/19)

지난주 일요일, 아침10시부터 저녁 10시까지 회의 및 다양한 변경사항들을 적용했다.
회의 이후 변경된 부분들을 기록해보았다.

협업 툴 사용 (Jira)

• Jira (minecraft_ie)
  Jira Summary url

회의 중 가장 첫번째로 언급되었던 내용은

"우리 개발 일정 관리 해야하지 않아? 계획도 세워야하고.." 였다.

맞는 말이다. 우리 프로젝트의 경우, 3명이 참여하고 있고 기간도 짧지 않다. 효율적으로 계획을 세우고, 인원을 분배하려면 협업툴 사용은 반드시 해야하는 일이기에 모두 동의했다.

Notion, Slack, Jira 등. 다양한 협업 툴이 있다. 그 중, 우리는 Jira를 사용하기로 했다.

선정 이유

1. 이전 인턴 근무 당시 버전업 기간에 버그들을 리포트하는 과정에서 사용을 해 본 경험이 있음
2. 요약 기능을 통해 개발 진행 현황을 한눈에 파악 가능
3. 이슈 리포팅, 담당자 할당, 기간 설정, 우선순위 선정 등 Jira에서 제공하는 다양한 기능들도 매우 유용하다는 점
4. 현업에서 많이 사용하는 것으로 알고있기에, 익숙해지면 좋은 툴이라고 생각했음

개발 파트 분류

사실 이 부분이 좀 막막했다. 왜?
우리는 기업이 아니다. 3명이서 진행하는 일개 프로젝트일 뿐 이고, 전문 인력도 아니다. (프로젝트 진행하며 그저 배워나가는 말하는 감자......)

일정이나 개발 과정은 계속 수정되겠지만, 큰 뼈대를 잡는 것은 중요하기에 나름대로 개발 파트 분류를 해보았다.

• 개발 파트 분류 보드
  
  현재 예시로 INFRA-서버구축 파트만 간단하게 일정을 기록해보았다.
  

• 개발 파트 분류 요약
  

크게 다음 5개 파트로 나누었다.

• INFRA : 게임 서버 구축, 디스코드 개발, 보안 & 최적화, DevOps
• FRONT-END : 서버 웹 구축 (자체 제작)
• BACK-END : 게임 플러그인 개발, 데이터 분석 및 시각화
• DB : ERD & 흐름도 관리, DB 관리 및 운영(플러그인, 유저 데이터), DB 연동
• QA : 서버 웹 테스트 케이스(시나리오) 작성, 테스트 자동화 (Cypress) & 리포팅, 유저 & 로그 데이터 분석에 기반한 서비스 개선

우선 순위, 이슈 사용 기준, 담당자 할당 기준, 기한 설정 등
다음 회의 이후에 더 진행할 예정이다.

디스코드 (Discord)

디스코드란 무엇인가? (나무위키 참조)

음성, 채팅, 화상 통화 등을 지원하는 인스턴트 메신저. 2015년 5월 13일에 모바일 MOBA 게임인 Fates Forever를 지원하기 위하여 출시하였다.

한국에서는 주로 온라인 게임을 즐기는 사람들이 많이 이용하는 편이며, 업무 또는 원격 교육에서 실시간 질의응답을 위한 용도로 사용되기도 한다. 뛰어난 성능과 간편함을 바탕으로 후발 주자로서 그 이전의 게임 유저들이 애용하던 여러 보이스 메신저를 제치고 주류로 올라서는 데 성공했다. 사실상 게이밍 메신저의 대명사.

라고 한다.. 게이밍 메신저의 대명사.

본인은 이전에 QA로 근무하며, 자동화 테스트의 결과를 매일 오전 6시에 사내 TEAMS에 보고되도록 체계를 갖춘 경험이 있다. 서버를 운영한다면, 개발 과정에서 우리 팀이 소통할 메신저가 따로 필요하다고 생각했다.

선정 이유

1. 게이밍 메신저의 대명사. 말이 더 필요한가?
2. 이후 서버를 오픈하더라도, 유저용 디스코드는 어차피 만들어야 하기에, 미리 익숙해져보자 라는 취지
3. 웹훅, 채팅 봇, 화면 공유 등 메신저 관리와 소통에 유용한 다양한 기능들이 존재

채널 생성

• 채널 방 분류
  

지라와 비슷하게 방을 나누었다. 대부분의 회의 및 소통은 음성채널에서 진행하며 각 개발 파트 별 관련 자료들을 업로드하기로 하였다. (카톡으로 자료 올리면 나중에 찾기 너무 어렵더라...)

각 방들에 대한 설명은 이후 INFRA - 디스코드 개발 파트 글에서 더 자세하게 다루겠다.

진행 방향

긴 시간 회의를 진행하며 프로젝트 진행 방향에 변경점도 몇 가지 생겼다.

1. 정기 회의는 매주 1회
   정기 회의 이외에도 맡은 파트 별로 꾸준히 소통하고 있지만, 정규 회의는 따로 정할 필요가 있다고 느꼈다. 날짜는 각자 일정이 있기 때문에 크게 정하진 않았지만, 주 1회는 무조건 실시하도록 정하였다.

2. Test 서버, Origin 서버
   백업을 하면서 개발을 진행하기에는, 아직 본인을 포함한 팀 인원들의 지식이 부족하다는 생각이들었다. 이에, Test 서버와 Origin 서버 두 파트로 나누어 1주일동안 Test 서버에서 개발을 진행하고, 안정적 & 깔끔 2가지 요소를 고려하여 정기 회의 때 Origin 서버에 Push 하는 느낌으로 진행하려 한다.

3. 하고싶은거 다 해!
   우리팀은 창업이 목적이라거나, 돈을 받고 서비스를 제공하는 업체는 아니다. 마감을 정해두고 프로젝트를 진행하지만, 서로 스트레스 받지않고 가감없이 프로젝트를 진행하기로 했다. 조금 무리일 것 같은 서비스도 구현하려 시도해보고, 우리 프로젝트에 적용할 좋은 기술이 있다면 언제든지 적용하며 다양한 시행착오의 늪? 으로 들어가보려 한다. 우리팀 화이팅!