[팀 프로젝트][KPT 회고] 최종. 스파르탄 온라인

유저들과 실시간 소통장소: 마을

캐릭터 성장을 위한 턴제 전투 컨텐츠: 던전

3인칭 보스 레이드 컨텐츠: 버그의 둥지

개요

내일배움캠프 Node.js 트랙에서의 최종 프로젝트인 스파르탄 온라인 프로젝트가 마무리되었다. 5명의 팀원들과 함께 

7/19~8/27까지 약 5주동안 협력하면서 무엇이 좋았고, 어떤 문제가 발생했었는지, 그리고 문제를 어떤 식으로 해결했는지 또는 어떤 식으로 해결하면 좋았을 지 KPT 방식으로 회고해보자.

 

팀에서의 내 역할: 팀원

 

참고

• 이번 KPT 회고록은 개인적인 생각만을 담도록 하겠다. 팀원들에게 회고록을 작성하자는 의견을 제안했지만 부리더님이 이번 프로젝트는 너무 만족스러워서 딱히 적을게 없을 것 같다하여 그냥 나 혼자서 적기로 했다. 

서버 코드 깃헙 링크

https://github.com/pledge24/Project_F_Server

GitHub - pledge24/Project_F_Server

 

 

클라이언트 코드 깃헙 링크

https://github.com/pledge24/Project_F_Client

GitHub - pledge24/Project_F_Client

 

---

Keep - 현재 만족하고 있는 부분

능동적인 개발 참여

• 이번 최종 프로젝트를 하면서 이전 팀 프로젝트들과 달랐던 점은 바로 기간이다. 이전 팀 프로젝트들은 길어봤자 2주였었고, 보통은 7~10일 정도의 기간을 받았다. 하지만, 최종 프로젝트는 기간이 무려 5주이기 때문에 개발 사이클이 1~2번이 아닌 그 이상의 횟수로 돌았었다. 그렇기 때문에 개개인이 어떤 일을 해야하는 지 리더가 지정해주기가 어려웠는데, 놀랍게도 모든 팀원이 본인이 할 수 있는 작업들을 능동적으로 가져가서 개발을 하였다. 
  이렇게 각 팀원이 능동적으로 할 일을 찾고 개발하여 리더가 좀 더 개발에 힘을 쓸 수 있었던 것 같다. 이것이 우리 팀이 빠른 속도로 개발을 해나갈 수 있었던 원인이었다고 생각한다.

적극적인 소통 참여

• 이번 팀원들은 소통이 아주아주 적극적이었다. 거의 대부분의 팀원들이 디스코드에서 접속하여 화면공유로 하는 작업을 모니터링 해두었고, 필요한 경우 서로 협력하여 코딩을 진행하였다. 그래서 다른 작업의 진행도가 궁금하면 그 방에 가서 진행상황을 물어보면 됐었다. 이런 원활한 소통이 '정말로 작업을 하고 있는건가?'하는 팀원들에 대한 의심을 줄이지 않았나 싶다.

페어 프로그래밍

• 프로젝트 초반부터 후반까지 적극적으로 사용했었다. 페어 프로그래밍을 하면 좋다는 이야기는 들어봤지만, 제대로 적용하여 사용한 적은 없었는데, 이번에 팀원 6명을 2명씩 짝지어서 3팀을 운영하니 개발 속도도 빨라지고, 무엇보다 내가 짠 코드를 알고 있는 사람이 한 명 생겨 다른 팀원들에게 설명하기가 좀 편했다.(같이 짠 팀원도 코드를 알고 있으니 일부 코드는 그 팀원에게 설명해달라고 할 수 있다) 반대로 물어보기도 편했다.
  
  

Problem - 불편하게 느끼는 부분

서버 구조 설계의 부재

• 이게 최종에서 가장 큰 문제였다고 본다. 이번 최종 프로젝트는 기존에 했던 TCP개인 과제 구조를 그대로 들고와서 리폼하는 방식을 썼는데, 우리 프로젝트에 맞게 어떤 식으로 설계를 해서 바꿔야 할 지를 너무 생각을 안했던 것 같다. 그래서 어느 정도 만들어진 서버에 서버 인사이트를 추가하는 데에 문제가 많이 발생했었다. 특히 Redis으로 유저 세션을 이전하는 작업은 기존 코드가 데이터를 못찾아오는 오류들이 발생하는 바람에 사흘이라는 기간동안 오류만 잡았었다. 아무리 초반에 설계한 서버 구조가 나중가면 바뀌기 때문에 의미가 없다고는하지만, 초반에 설계를 어느정도 해두고 코드를 짜는것과 해두지 않고 짠 코드는 서버 인사이트를 추가하는데 있어 용이함의 차이가 있었을 것이다.

확장성이 없는 코드: 코드 리팩토링의 부재

• 확장성이 부족한 코드들이 올라온 경우가 종종 발생했었다. config로 넘겨야 할 내용들이 숫자로 하드코딩 했다거나, 같은 데이터들 다른 구조에 중복되게 넣어 핸들러마다 해당 데이터를 불러오는 방법이 일관적이지 않다거나, 데이터를 가져오는데 의존성이 높은 코드들이 있었다. 이러한 문제들을 해결하려고 리팩토링을 중간에 한 번 했었는데, 프로젝트가 끝난 지금도 문제가 많아보인다... 짧은 기간동안 하는 프로젝트가 아니기 때문에 이런 문제가 한 번 터지니 겉잡을 수 없이 커지는 것 같다. 

Try - Problem에 대한 해결책, 당장 실행 가능한 것

서버 설계는 천천히 길게 짰어야했다.

• 아무리 기능 구현이 중요하다고는 하지만, 그렇다고 서버 설계적인 부분을 전혀 생각하지 않고 있다가 한 번에 해결하려고 했으면 안됐던것 같다. 서버 설계는 상당히 어려운 부분이고, 설령 설계를 했더라도 그대로 코드를 맞춰 짜는 것도 그리 쉬운 일은 아니다. 그런데, 갑자기 서버 설계에 맞춰서 코드를 재설계한다는 건 너무 위험하고, 실제로 우리 프로젝트는 이러한 부분때문에 문제가 생긴 것 같다.(문제라고 할 정도는 아니고 시간이 끌리는 정도이긴하지만)
  서버 설계는 천천히 길게 짰어야한다고 생각한다. 프로젝트의 구현 뼈대가 어느정도 잡혀있을 때 프로젝트의 서버 설계를 조금씩 생각해뒀어야했다. 그래서 서버 인사이트를 추가하는 시점에는 이미 어느정도 완성본이 있고, 그 때부터 인사이트를 위한 재설계가 들어갔어야 했다. 만약 이럴 시간조차 없다면, 하루 날 잡고 팀원들과 서버 설계를 같이 고민해야 될 것 같다.

코드 리뷰를 각자 요청하자

• 코드 리뷰는 하면 좋다. 다른 사람 코드에 대한 이해도를 높일 수 있고, 이렇게 높아진 이해도는 하나의 소통이 되어 잘못된 방향으로 코드를 짜는 경우 자체를 줄여준다.
  하지만, 일정이 바쁘면 코드 리뷰하는 시간을 따로 두지 못한 뿐더러, 다들 바쁜데 매번 '제 코드 봐주세요!' 하기엔 코드 리뷰를 요청하는 사람도, 코드 리뷰를 받은 사람도 부담이 된다.그래서 능동적으로 요청을 받아야 하는 부분이 있는 경우에만 개인이 알아서 코드 리뷰를 요청 방식이 좋을 것으로 보인다.

---

마지막으로...

짧다면 짧고, 길다면 길었던 5주가 지났다. 시작할 때 한없이 높아보였던 서버 인사이트의 벽을 뚫고, 수많은 컨텐츠들을 제작하며 목표했던 결과물을 만들고, 지금 나는 이렇게 회고를 적어내었다. 정말 힘들었고 몸도 많이 상했지만, 너무나도 좋아했던 게임과 게임서버 개발을 능력좋은 팀원들과 함께 동고동락하며 하나씩 만들어갔던 일들을 생각하니 후회는 전혀없다.

가슴 뭉클해질 정도로 행복했던 5주. 이 5주의 경험을 토대로 삼아 더 좋은 게임 서버 개발자가 되야겠다.