길었다면 길었고, 짧았다면 짧았던 도전을 마치고, 본업이었던 게임 개발로 복귀한다.
2년여간의 경험은 꽤나 의미가 있었다.
내가 웹&플랫폼 개발을 해보고 싶었던 계기는, 이전 글에서 언급했던 대로, 기술적으로, 문화적으로 궁금한 것이 컸다.
여기에 더해서, 게임 개발을 오래하다보니 매너리즘에 빠진 문제도 있었다.
비슷 비슷한 업무에 지치기도 했고, 중견 회사나 소규모 회사를 주로 다녔다보니 매번 출시하거나, 출시했던 게임을 서비스 하던 내가, 짧은 기간에 여러 번의 프로젝트 드랍을 경험하기도 했다.
또 당시 NHN Entertainment(현 NHN)에 입사하게 되면서 플랫폼이나 웹 개발 비중이 높은 회사로 왔다보니, 보는거 듣는게 많아지면서 궁금해지기도 했다.
게다가 개인적인 호기심으로 ruby on rails, python django 등을 사용해봤던 내가, (반강요로 인한) 자바와 스프링을 사용하게 됐다.
언어나 경험적으로 너무 큰 장벽이 있어, 쉽사리 도전하기 어려웠던 상태에서 어느정도는 도전 가능한 범주로 경험적 차이를 좁혀가다보니, 지적 호기심이 더 커졌다. 이제와서 밝히자면, 내가 과연 게임 개발이 아닌 다른 분야에서도 잘 할 수 있는지, 프로그래머로만 구성된 조직, 팀에서 내가 어떤 부분에서 장단점을 내비칠 수 있는지, 또 플랫폼 개발자나 웹 개발자들 사이에서 어떤 자극, 어떠한 인사이트, 어떠한 성장 계기를 가질 수 있는지 너무 궁금했다.
어쩌면 잠깐의 도전이, 내 인생의 많은 부분을 차지하는 일이라는 측면을 송두리째 바꿀 수 있음에도 궁금했다.
C++ 게임 개발자로 시작했고, 자연스레 만들어 쓰는 것에 익숙하던 나는, 만들어서, 써보고, 적용하고 나서야 결과를 알 수 있는 방식으로는 기술적 성장이 생각만큼 속도가 붙지 못함에 아쉬움을 느꼈다.
또한 상태 기반의 서버의 스케일아웃에 대한 경험과, 판단은 할 수 있었지만, 내가 떠올린 방식 다수가 공수가 많이 든다거나, 많은 규칙을 가지고 코딩해야 하는 강제성, 그 규칙을 유지하기 위한 높은 유지보수 비용이 필요한 방식이었다.
물론 웹/플랫폼이 다른 방식으로 스케일 아웃하고, 트래픽을 처리한다는 것은 알 수 있었으나, 분명 게임 개발에서 웹 개발의 장점을 녹일 수 있다면, 생각을 좀 더 다양한 측면에서 고려하고, 다양한 방식으로 생각 할 수 있다면 좋지 않을까 하는 기대감을 가졌다.
이렇게 도전을 나선 나에게 2년여의 경험은 큰 도움이 됐다. 그들이 왜 저렇게 생각하는지, 왜 저렇게 말하는지, 왜 저런 것들이 중요하다고 말하는지 알아들을 수 있게 됐다.
또 웹 백엔드, 프론트엔드도 개발 할 수 있을 만큼의 학습도 했고, 그들이 일하는 방식에서의 장단점도 배웠다. 플랫폼 개발자는 그래도 조금이라도 더 게임 개발자와 가까운 측면이 있었다. 모듈을 직접 구현해야 되는 경우가 많았고, 대신 오픈소스를 잘 활용하는 데에 게임 개발자들 보다 능숙했다.
실제로 웹 개발자 성향과 플랫폼 개발자들 사이에서의 차이도 꽤 컸는데, 이는 나중에 다시 얘기해보도록 하겠다.
결론적으로 게임 개발자들은 직접 만드는 데에 익숙하고, 웹이나 플랫폼 개발자들은 가져다 쓰는 데에 익숙한데, 이 과정에서 인사이트에 대한 갭도 흥미로웠다.
게임 개발자들은 직접 만들어 쓰다보니 원리에 대해 파고드는 접근을 보이는 반면, 웹이나 플랫폼 개발자들은 가져다 쓴 모듈을 검증하고, 사용하는 방식에 대해 검증하려는 접근을 보였다.
애초에 검증을 하는 방식도 테스트를 통한 검증이 많았는데, 테스트 방식으로 검증할 수 없는 부분은 결국 커버리지에 아쉬움을 보일 수 밖에 없었다.
반면 직접 만들어 쓰는 게임 개발자들은 시간이 부족하거나, 원리 이해를 잘못했을 때의 리스크를 가졌고, 테스트에 대한 리스크도 똑같이 짊어지는, 즉 고강도 노동에 시달리는 슬픈 현실을 마주하기도 했다.
그런 과정을 나도 겪었다보니, 이런 부분에 대한 해결책이 궁금해 웹/플랫폼 개발은 어떻게 하는지 알고 싶었다.
아무래도 모바일로 넘어오면서 웹 서버로 컨텐츠를 개발하기 시작한 게임은 웹 호출을 이용해서 connectionless 특성을 가져갔을 뿐, 실질적인 개발과 운용에서의 접근은 웹의 장점을 많이 못 가져왔다.
여전히 결합도를 만드는 접근, 잘 가져다 조립하지 못하는 구현, 확장성 낮은 구조는 아쉬움이 많았다.
결과 저장소와, DB 대행정도로만 구현 가능한 라이트한 게임들이라면 모를까, 조금만이라도 인터랙티브한 요소가 들어가서 소켓 프로그래밍이 필요한 경우엔 또 과거로의 회귀가 이어졌다.
상태를 들고 있는 서버는 크래시에 치명적이다. 그렇다고 서버를 잘게 쪼개 놓으면, 구현도 어렵고, 예외 처리도 어렵다.
격리할 수 있는 요소를 많이 쪼개고, MQ를 적정 지점에 배치해서 서비스 간의 통신에서 사용해, 순서와 이벤트 유실을 막는 것이 필요하다.
규칙은 최소한 프로젝트 단위에선 일관되게 만들고, 단순화 시켜서 실수를 줄이고 관리 코스트를 낮춰야 한다.
협업이 필요한 파트별로, 자신들이 만든 결과물을 자체적으로 검증하는 툴을 만들거나, 가져다 쓸 수 있어야 한다. 그래야 파트간 소통에 들어가는 코스트를 최소화 할 수 있고, 유연하게 변화를 줄 수 있으며, 조립하는 과정 즉 연동하는 과정에서의 문제를 최소화할 수 있다.
검증과 테스트 도구를 파트별로 보유 했을 때의 또다른 장점은, 새로운 시도도하기 쉽다는 거다. 아무래도 협업하는 사람이 많아질 수록, 확정적인 것 들로만 진행해야 하는데, 이는 잦은 변화로 인한 코스트 낭비를 줄이기 위해서라도 필요하다. 하지만, 파트 자체적으로 시도해볼 수 있는 환경이 갖춰진다면 다양한 시도도 할 수 있고, 완성도도 높일 수 있다.
마치며
아마도 더 오랜 기간을 웹/플랫폼 개발을 했다면 생산성 높은 환경에서 얻을 수 있는 다양한 인사이트를 얻었을 거라고 생각한다.
특히 개인적으로는 리눅스 환경이 익숙해지고, 거부감이 사라지는 데에선 플랫폼 개발 했던 기간이 큰 영향이 있었다. 또한 부서가 부서였다보니, 클라우드 환경이나 인프라에 대한 이해도도 함께 높아졌다.
그리고 오픈 소스 도구에 대한 접근, 이해도도 아주 아주 큰 도움이 됐다고 생각한다. git flow와 같은 브랜치 관리라거나, 온라인 코드리뷰 문화도 좋았다.
이유야 어찌됐든 다시 돌아오게 됐기에 웹/플랫폼 개발에서의 경험을 게임 개발에서 녹여내고자 한다.
짧은 시간이었지만, 발을 담그게 됐던 환경에서, 나에게 자극이 되어주고, 가르침을 주시고, 배울 수 있게, 성장할 수 있게, 경험할 수 있게 해주신 분들께 감사한다.
또 다시금 게임 개발 전선에 뛰어들 수 있게 도와준 분들께도 감사한다.
내년에는, 또 후년에는 하고자 했던 것들을 이뤄내서, 나의 게임 개발 복귀가 의미 있게, 가치 있었다고 말할 수 있게 된다면 좋겠다.