캠프 지원
동아리에 메일이 왔었다. 스마일게이트의 '윈터 데브 캠프' 모집 글이었다. 지원을 위해 C++ 서버 공부를 바로 시작했다.
"프로그램에 참가하면 좋겠다." 라고 생각했었는데 진짜 할 줄이야.
팀이 정해졌다는 메일을 받았다. 바로 단톡방을 만들었고 다음에 해당하는 이야기를 나눴다.
- 개인의 기술
- 개발 경험
- 관심사
서로에 대한 이해를 할 수 있었다. 웹과 게임을 좋아하는 사람들이 극명하게 나뉘어져서 로비와 인게임으로 나눠 웹 개발자도 자신이 원하는 분야를 다룰 수 있게 하면 좋겠다고 생각했다.
비대면으로 작업을 하다 보니 의사소통이 어려웠다. 또 화면 상으로만 만나니까 우리가 한 팀이라는 사실이 와닿지 않았다.
팀원 3명이 광주에 있었고 나는 대면 작업을 위해 광주로 거주지를 옮겼다.
대면으로 프로젝트를 진행하면서 직접 느낀 장점은
- 예정되지 않은 작업이 필요할 때 곧바로 만날 수 있다.
- 의사 결정의 속도가 빨라졌다.
다음에도 프로젝트를 한다면 대면으로 진행할 것이다. 거리가 가까우면 자리를 만들기 쉽고 사람들이 참여하기 수월하다. 다들 성실하게 프로젝트에 임할 수 있었다.
OT
"나 정도면 취업할 수 있지 않을까?"라고 생각했었다. 하지만 OT가 끝난 뒤 내 지식이 정말 짧다는 것을 깨달았다.
더 열심히 하자고 다짐했다. C++ 사용에 우려가 있어서 공부했던 것을 정리하여 검토 받기도 했다.
특히 이때 들었던 이사님의 성장을 주제로 한 강의가 인상 깊었고 이후의 활동에 큰 영향을 끼쳤다.
개인 프로젝트
개인 프로젝트 URL Shortener로 정하고 C++ IOCP를 이용해 만들었다. 캠프 지원 후 C++ 서버 공부를 했었는데 이 때의 지식을 활용할 수 있었다.
에코 서버에서 발전된 형태였지만 다음과 같은 것을 얻을 수 있었다.
- 기능을 생각하고 어떻게 만들지 설계하는 능력
- 설계한 것을 구현하는 능력
- 네트워크 구조 이해
- 비동기, 멀티 스레드 활용 능력
- 개발 자신감
팀 프로젝트를 준비할 수 있는 방향으로 진행하였다. 게임 서버를 만드는데 좋은 초석이 되었다.
PMP, 아키텍처 그리고 위험
무수히 많은 시간을 예시 파일을 분석하는데 사용했다. 그러나 그럴 필요는 없었다. 예시를 이해하려고 애쓰면서 시간을 소비했지만, 결국 큰 의미는 없었다.
'다른 팀의 중간 발표 보기'는 큰 도움이 되었다. 다른 팀의 발표를 들으며 아키텍처에 대한 인식과 설계 능력을 향상시킬 수 있었다. 특히 중간 발표가 이틀 남은 시점에서 좋은 생각이 났다.
"위험 관리와 문제 해결 능력"
앞으로의 프로젝트에서 위험 관리가 가능할까? 아니면 여전히 개발에만 집중할 것인가? 이번 기회에 이 주제를 적극적으로 다뤄보지 않으면 학교 생활 동안 경험할 수 없을 것 같았다. 또한, 프로젝트 수행 중 발생 가능한 문제들을 예측하고, 이를 해결하는 능력을 키울 수 있을 것이라 생각했다.
프로젝트 중 다음과 같은 작업을 했다.
- 위험 예측
- 전략을 세우고 평가
- 위험을 예방
- 위험이 발생했을 때 해결하고 기록
위험 예측
프로젝트와 구성원의 특성을 생각했다.
(뒤에 언급 되겠지만 개발 환경을 다뤘으면 예측 범위가 늘었을 것이다.)
- 프로젝트의 특성
- 다양한 언어, 프레임워크, 서버가 사용되는 아키텍처의 특성
- 네트워크 환경에서의 게임 등
- 구성원의 특성
- 이해도, 기술, 성격, 집중하는 방식
- 요구되는 능력과 우리의 능력 간의 간극 등
- (개발 환경의 특성)
시간이 부족했던 만큼 예측에 시간을 많이 쓰지 못했다. 이 때 놓친 부분은 '프로젝트에서 배운 것'에서 다룬다.
위험을 예측하는 것과 문제를 식별하는 것이 유사했다.
전략을 세우고 평가
식별한 위험에 대해, (예방, 해결, 무시) 세 가지 측면을 생각하고 비용을 평가하여 어떤 방법이 좋을 지 골랐다.
- 예방: 위험이 발생하지 않게 힘쓰는 행동
- 해결: 위험 발생 후 사후 처리 (해결이라는 네이밍이 별로인 것 같다...)
- 무시: 무시
주로 예방이었는데 간혹 사후 처리가 비용이 적을 때도 있었다. 모임을 참가 못할 때 회의록을 건네준다거나...
프로젝트
네트워크 코드
- 연결
- 입출력
- 연결 해제
개인 프로젝트와 boost/asio 를 충분히 공부해서 나름 쉬웠다. 하지만 공부했던 내용과 내가 사용한 최신 버전 boost/asio에서 호환되지 않는 부분이 있어 추가적인 공부가 필요했다.
io_service가 io_context로 바뀌고 몇몇 함수도 따라 바뀌었다.
개인 프로젝트에서는 패킷이 온전히 도착했다 가정하고 서버를 만들었다. 팀 프로젝트에서는 Circular Buffer를 만들어 패킷이 다 도착하면 사용할 수 있게 했다.
패킷 처리
- 방 생성
- 유저 입장
- 이동
- 공격
- 피격
- 사망
- 종료
패킷과 이를 처리하는 동작을 추가하다 보니 방 안의 클라이언트 끼리 패킷만 전달하는 이상한 형태가 되었다. 만들면서도 이렇게 처리가 없는 서버가 무슨 의미가 있나 싶었다.
이 때 락 관련 이슈를 처음 겪었는데 락을 잡은 상태에서 다른 락을 잡으려 하다가 데드락이 발생했다.
또 C# 서버가 늦어지면서 전체적인 일정이 늦춰졌다.
게임 서버
코드 리뷰 후에야 사양을 제대로 파악하지 못했다는 것을 깨달았고, 이에 따라 필요한 기능을 추가하게 되었다.
기존 구조에 뒤늦게 끼워넣다 보니 Single Responsibility Principle 이 지켜지지 않았다. User 포인터를 여러 클래스가 사용했고 예외가 많이 생겼다. 리팩토링으로 구조를 바꿔 하나의 클래스만 User를 관리하게 하였다.
처음 만드는 것인 만큼 사양을 제대로 파악했어야 했다. 기능을 추가하는 중에 오류가 많이 터졌다. 포인터, 락 관련...
새로운 것을 개발할 때는 시행착오를 동반한다.
도메인에 대한 이해가 부족하면 잘못된 계획을 세우게 되고, 이를 따라가면 예상치 못한 결과를 초래하게 될 것이다. 이때 중요한 것은 문제를 인식하고 현재 상황을 정확히 파악하는 것이다.
개발 중에는 무언가 미진한 점을 느낄 수 있었지만 제대로 인식하지 못했다. 하지만 코드 리뷰를 통해 제대로 현 상황을 파악할 수 있었다.
이 과정에서, 두 가지 중요성을 배웠는데
-
개발 과정에서 문제를 인식하고 현재 상황을 객관적으로 파악하는 것
-
목표와 실제 결과물 간의 차이를 지속적으로 확인하고, 이를 통해 현재 상황과 목표를 비교하여 계획을 수정하고 실행하는 것
이러한 과정은 처음 계획하는 단계에서 시행착오를 불가피하게 겪을 수 있음을 보여준다.
따라서 개발 중, 문제를 인식한 후에는 계획을 재정비하고, 실행하는 과정을 반복적으로 수행하면서 점진적으로 목표를 달성하는 방향으로 나아갈 수 있다.
연동
연동 또한 시간이 많이 들었고 클라이언트의 코드 작성을 다 끝내지 못했다. 게임 서버의 동작을 제대로 확인하지 못해 아쉬웠다.
기한이 지나도 아쉬운 마음에 기능을 축소하지 못하고 계속 개발하였다. 일정에 맞춰 개발을 했다면 여러 유저를 서버에 붙여 볼 수 있었겠지만 그러면 기능이 부족했을 것이다.
두 방향(기능, 연동)을 평가 후, 더 바람직한 방향으로 빠르게 결정할 필요가 있었다.
목표는?
우리는 다양한 조건을 고려하며 위험을 식별하는 과정에서, 시행착오를 겪으며 문제를 해결하는 과정에서, 그리고 다양한 해결 방법을 고민하고 선택하는 과정에서 문제 해결 능력을 향상시켰다.
앞으로의 프로젝트에서는 겪은 문제에 대해 예측하고 대비할 수 있을 것이다.
협업을 통한 문제 해결 능력도 같이 얻을 수 있었다. 의사 결정과 소통에서 효과적인 방법을 배우고, 이를 통해 오해를 줄이고 의사소통을 명확하게 할 수 있었다. 팀원 간의 역할과 책임 분담, 문제 발생 시 이를 공유하고 함께 해결책을 찾는 과정에서 협업 능력도 개선되었다.
기술 학습과 자기 개발 능력 역시 향상되었다. 문제 해결을 위해 필요한 기술을 선정하고 학습하는 과정, 그리고 그 기술을 실제로 적용하면서 겪는 시행착오를 통해 지식을 검증하고 이해도를 높일 수 있었다.
마지막으로, 프로젝트 관리 능력도 배울 수 있었다. 일정 관리와 작업 정리의 중요성을 인식하고, 프로젝트 중 발생하는 위험을 신속하게 파악하고 대응하는 능력을 키웠다.
처음에 계획했던 문제 해결 능력뿐만 아니라, 5명의 팀으로 프로젝트를 진행하며 협력을 통한 문제 해결 능력까지 향상시킬 수 있었다.
다음 글로 이어진다.
