개요
나는 게임 개발자였다.
첫 시작은 게임 클라이언트였지만, 이후 꽤 긴 시간을 게임 서버 개발자로 보냈다.
꽤 많은 시간을, 꽤 많은 게임을 만들었고, 유지보수도 했다. 하지만 아쉽게도 성공한 프로젝트는 없다.
그 시간 동안 게임 개발과, 게임 플레이는 아주 많은 간극이 있다는 것도 알았고, 엔지니어는 거들 뿐 프로젝트의 성공을 위해선 훌륭한 프로듀서와 훌륭한 기획자가 최우선이란 것도 알았다. (때로는 홍보도)
그렇게 조금씩 지쳐 갈 때 즈음, 웹 서버로 구현하던 많은 라이트한 게임들을 통해, 게임 서버 계에 웹 서버 붐 불었다. 나 역시 흐름에 따라 ruby on rails를 게임 웹 서버로 이용하며 발을 담그긴 했으나, 웹을 제대로 알지 못하고 썼으며, 사실상 DB 트랜잭션+로직 단위를 웹 콜 하나로 묶는 수준의 웹 서버를 구축했다고 봐야했다.
여전히 게이머
나는 여전히 게임을 많이 플레이 한다. 아니 어쩌면, 게임 개발자 일때보다 지금 더 많이 플레이하는 것 같다. 서버 개발자로 주로 지내오면서도, 내가 개발하는 게임이 해외 AAA 게임 보다 부족한 기술력, 기획력, 연출력, 아트 퀄리티, 완성도에 아쉽긴 했다. 그러나, 희망론자인 나는 앞으로 나아질거란 기대를 놓지 않았음은 물론이다.
나는 스토리 기반의 싱글 플레이 게임을 선호하는데, 이는 아마 내 성장기에 즐겨왔던 게임이 주로 그랬던 것과, 엔딩이라는 종착지가 있음이 성취감을 주기 때문이기도 했던 것 같다.
또한 MMORPG나, FPS, TPS등의 일부 장르에서 국내 기술력이 해외 메이저 게임보다 아쉬운 면도 있는건 사실이지만, 그렇다고해서 경쟁이 안될 정도로 벌어져 있는 상태가 아니었기에, 운이 조금 따른다면 충분히 좋은 프로젝트를 만나 재미와 흥행을 모두 잡는 게임을 만들 수 있을 거란 기대를 품고 게임 개발자로써의 성장을 위해 노력했다.
변해버린 시장, 흐름
사람일은 어찌 흘러갈지 모르는 것처럼, 자의 반, 타의 반으로 서버 프로그래머로 전향하고 나서도 몇년간 클라이언트 개발을 다시 하고 싶어 했었으나 실무 기간를 게임 서버를 오래했던지라 경쟁력 문제로 게임 서버 개발을 계속 하게 됐었고, 그렇게 이어가던 게임 서버 개발자로써의 재미와 목표점을 찾게 된 다는, 게임 서버 개발자로서 많은 경험과 노력이 빛을 발할 날을 기다리고 있었다.
모바일로 시장이 급변하고, 라이트한 게임이 시대의 흐름이 되었을 때, 서버 프로그래머인 나는 굉장히 혼란스러웠다.
내가 중요하다고 여겨온 가치 몇가지가 와르르 무너지는 느낌이랄까?
스마트폰 모바일 게임 시장의 초창기에는 서버는 저장소 이상의 가치로 쓰이지 않았다. 사실 그 정도로 쓰인다면 웹서버를 로직 & 데이터베이스 중계역할 정도로도 충분했다.
그렇게 기술적 요구사항이 낮아지고, 온라인 게임에선 해킹, 검증 등의 이유로 절대 해선 안되던 일인, 로직이 클라이언트로 내려갔고, 이는 상시 네트웍 연결 상태가 아닐 수 있다는 이유로 내려가게 됐고, 조작 방식이 터치로만 이루여져야 한다는 한계는 일부 몇개의 게임을 제외하곤 게임의 방향성 마저 내가 좋아하는 장르나 지향점과 많이 멀어지고 있었다.
그렇게 내가 잘해오던, 내가 경쟁력을 가지던 것들이 무색해지면서 느낀 혼란은, 게임 개발의 재미를 급감 시켰다.
이 의문에, 나는 내가 클라이언트 개발을 하면 재미를 찾을 수 있는지 알기 위해, 유니티 클라이언트 개발로 게임을 출시하기도 했지만, 이젠 게임 서버 개발을 더 잘해내고 싶은 목표를 이미 갖고 있던 나에게 만족도를 가져다 주는 경험이 되진 못했다.
이렇게 변한 환경은 기술적 요구사항이 낮아진 만큼 시간을 벌 수 있을테고, 컨텐츠에 조금 더 집중할 수 있지 않냐 라고 물어볼 수 도 있다.
그랬다면 좋았을 텐데, 기술적 요구치가 낮아진 만큼 더 짧은 일정이 주어졌고, 그로 인해 게임 퀄리티는 더더욱 내가 생각하는 좋은 게임과 멀어지는 계기가 됐다.
전직을 한 이유
아쉬웠던 게임 개발에 대한 이유와 별개로 웹&플랫폼 개발을 하고 싶었던 것은, 오픈 소스 환경에서의 생산성을 느끼면서 이다.
애초에 최대한 많은 도구를 인하우스 개발을 해오던 게임 개발자가, 오픈 소스로 패키지들을 가져다가 조립해가며 높은 생산성을 맞이하게 됐을 때, 즐거웠다.
젊은 시절 과도한 야근과, 철야로 해친 건강을, 회복하지 못한 내 잘못도 크겠지만, 그로 인해 예전보다 집중력을 많이 잃으면서 적은 공수로 많은 비즈니스 로직을 구현할 수 있는 오픈 소스 문화권의 잘 가져다 써서, 잘 조립하는 환경에 대한 호기심이 생겨나게 됐다.
사실상 개인 C++ 라이브러리까지 꽤나 긴 유지 보수해가며, 최대한 많은 코드를 내 스타일로 커스텀하고 관리하고, 이를 바탕으로 개발하던 게 습관이던 내가, 다른 사람들이 만든 기능을 조합하는 일을 받아들이고, 재밌어 하는 일은 쉬운 결정은 아니었다.
바퀴를 재발명해서 더 나은 바퀴를 만들기 위해 고민하던 내가, 바퀴를 조합하는 일을 재밌게 할 수 있을지, 또 내 삶에 큰 의미를 가지는 게임 개발이 아닌, 다른 분야에 대한 개발에서 성취감과 재미를 찾을 수 있을지는 확신이 없었다
좀 더 쓰기 좋은 바퀴를 만드는 일 보다, 좀 더 성능 좋은 바퀴를 만드는 데에 집착했던 나로서는 더더욱 그런 면이컸다.
온라인 게임 개발할 땐 게임 서버 팀 내에서도, 주로 네트워크 라이브러리 작업, 커버리지 확보나 안정성 검증 작업을 더 많이 했던 나로서는 컨텐츠 개발을 적게 해서 그랬던 것 같기도 하다.
모바일 게임으로 넘어오면서는 컨텐츠 작업의 비중이 더 커졌는데, 그 과정에서 바퀴를 가져다가 짧은 시간에 원하는 컨텐츠를 구현하는 것이 중요할 수 있다는 것에 공감하게 되면서, 조금씩 다른 것들이 보이기 시작했던 것 같다.
그렇게 적은 공수로 컨텐츠를 만들게 되면서, 사이드잡 내지는 토이 프로젝트에서 C++보다는 다른 언어를 사용하게 됐고, 강력한 언어인 C++보다 효율적인 언어들을 찾아 사용하게 되기도 했다.
웹 개발의 장점
내가 웹 개발이 효율성이 좋다고 말한 이유는, 웹 개발을 이끌고 있는 리더들이, 다수의 개발자가 겪는 공통된 고민들을 오픈소스 환경 위에서 같이 고민하고, 같이 해결하며 발전해온 측면이 컸다.
게임 개발도 그런 노력이 없었던 것은 아니지만, 현시점 마저 공개된 기술의 사용이나 오픈 소스를 이용해서 풀 수 있는 문제가 한정되어 있다. 게임 마다 특화된 주제를 다룰 때도 있고, 표준화 되기 이전에 목표를 달성해 게임 출시에 사용해야 되기 때문이기도 하다. 그렇다 보니 기술의 재사용, 기술의 표준화에 있어서 웹 개발은 게임 개발보다 잘 이루어졌고, 공통 기술 스택이라 불릴 만큼 범용적 기술이나 경험이라 할 만한 것들마저 생겨났다.
결과론 적으로 웹 개발에선 팀바팀도 물론 요소가 많지만 표준들도 많았다 할 수 있고, 게임 개발은 팀바팀이 훨씬 더 크고 개인의 역량과 개인의 경험에 기대는 측면마저 크다고 볼 수 있다. (왜 그런지는 아래에서 좀 더 자세히 언급하겠다.)
이는 그렇게 기대는 개발자 개인의 이탈이 팀과 회사에 큰 리스크를 가져다 줌을 의미하고, 여전히 게임 개발은 그런 측면이 있다.
물론 유니티같은 상대적으로 이전보다 쉬운 개발 환경을 만들어 주는 툴이 히트를 치고, 위에서 언급한 디비 저장용도로만 사용하는 웹서버 등으로 서버 개발의 공수도 줄었다지만, 다시금 코어한 게임 개발로 넘어간 지금은 이전 온라인 게임 개발과 다름없이, 특정 게임만을 위한 수많은 기술이 개발되고, 그에 의존한 게임 서비스를 구축해야 한다.
이런 환경이, 모바일 게임 개발로 넘어오는 시기에 웹/플랫폼과 게임의 기술 대통합이 이뤄질 것처럼 보여졌던 환경에서, 과거로의 회귀같은 느낌마저 난다. (이는 밑에서 정리한 채용 공고만 봐도 느껴질 수 있는 부분이다.)
게임 개발과의 차이
이렇게 큰 차이가 나는 이유는, 문제를 푸는 방식, 문제를 해결하는 방식에서의 접근자체가 다르기 때문이다. 게임 개발자들이 만든 기술을 오픈소스화 하는 데에도 인색한 것은, 아마도 남들도 오픈소스화 하지 않기 때문일 것이다. 또한 그렇게 개발한 기술이 타 게임 개발 업계 전반에 메리트가 있기보다는, 경쟁사의 경쟁 게임에 도움이 되는 기술 공개가 되기 때문인 측면도 분명히 있다고 본다.
현시점마저 특정 팀내에서의 유틸리티, 엔진, 프레임워크 등 다수는 오픈소스가 아니다.
과거에 비해 자체 엔진이 매우 줄어들고, 엔진/툴만이라도 과거에 비해 저렴해진 것이 그나마 위안일 정도랄까?
그리고 게임 개발에서 이견이 없는 주류 언어로 오랜 기간 사용되어왔고, 다시금 선택 받고 있는 C++은 조각 코드 공유가 많지, 가져다 쓰기 쉬운 패키지 단위 배포가 잘 이뤄지지 않았다. (애초에 패키지 매니저 자체가 여타 언어에 비해 매우 늦었고, 아직도 정착 되지 못했다.)
또한 C++ 언어 특성상 라이브러리로 배포된다 한들 그 라이브러리가 세심한 검토 하에 사용되지 않으면 기존 환경 마저 깨뜨릴 수 있는 위험한 환경. 즉 네이티브 환경에서 개발하며, 맘편히 가져다 쓰지 못하고, 잘못 작성된 코드나, 라이브러리 연동과정에서 생긴 각종 트러블에 대한 네거티브한 경험에 의한 결론이 아닐까 싶기도 하다. 남이 만든 코드보다 내 코드, 내 경험, 내 판단, 내 검증만이 높은 퀄리티의 프로덕트의 원동력이라는 결론에 도달한 것 같다.
반면 웹은 브라우저나 웹 프로토콜 기반 하에서의 비슷한 이슈에 대한 고민이 많았고, (상대적으로)꽤나 많은 기능, 해결책들을 가져다 써서 해결 할 수 있었다. 심지어 가져다 써서 생긴 부작용마저 상대적으로 작았고, 웹 서버/웹 프론트엔드는 상대적으로 작은 오류에 대한 파급이 적은 환경이었다. 그런 긍정적인 경험들이 모여 가져다 써서 잘 만드는 데에 집중하는 접근, 환경에 대해 받아들이고 그 것이 옳다고 여길 수 있게 된 거라고 생각한다.
요샌 게임 개발도 효율, 기술의 재사용, 오픈소스로 문제를 많이 푼다는 이야기도 많이들 한다.
하지만 여전히 채용권자 혹은 프로젝트 리더들과 대화 해본 나는 오픈 소스를 사용하되 그 것을 도입하는 방식, 이용하는 방식에서 여전히 큰 차이가 있다고 생각한다.
이 주장을 위해 몇몇 회사의 채용 공고를 가져온다.
채용 공고
플랫폼 개발자
대용량 처리 경험과, 관련 오픈 소스 사용 경험에 치중되어있다.
웹 개발자
RESTful API, DB, Spring, Java 등의 키워드가 보인다.
게임 클라이언트 개발자
공학 기초, 엔진 (언리얼, 유니티), C++, C#, 프로젝트 경험 등이 키워드다.
게임 서버 개발자
C#, C++, DB, 네트웍, 로우 레벨 이해도 (TCP/IP 통신, 멀티 스레드, OS 구조 등), 트러블 슈트 등의 키워드가 나열됐다.
게임 개발에서 중요하게 여기는 요소
일부 공고에 불과하기에 일반화 하기엔 부족하지만, 게임 개발이 전반적으로 기초를 더 중요시 한다.
실제로 공고보다 면접과정, 채용과정에서 로우레벨 이해도가 부족한 사람은 뽑아선 안된다는 기조가, 웹&플랫폼보다 훨씬 더 많이 언급됐고, 작용했다.
이는 프레임워크나, 시스템 구조를 직접 작성해야 되기 때문에, 기초가 부족한 사람이 끼칠 부정적 영향에 대한 우려, 검증과 함께 개발해야 하는 게임 마다 특화된 구조를 지탱하고, 이해할 기초가 중요하다고 보는 경향이 상대적으로 높다고 볼 수 있겠다.
웹과 게임 개발이 왜, 얼마나 다른지 알고 싶었다.
내가 게임 개발자로써 웹 개발자 혹은 플랫폼 개발자 분들과 대화해가며 문제에 대한 접근/해결책에 대해 너무나도 다른 시각과 해결책을 내놓고, 타협이 쉽게 이뤄지지 않는 것을 보고 왜 그런지 많은 고민을 했었다.
결국 다 프로그래머들인데 왜 이렇게 다르지?
이 궁금증에 대한 해답을 얻고 싶었다.
내가 일해오며 존경하는 몇명의 개발자가 있다. 이 개발자 분들은 흔히 말하는 머리 좋은 천재 프로그래머는 아니었다. 대부분 유연한 프로그래머였다. 생각이 경직되어 있지 않고, 자신의 의견보다 더 설득력 있는 주장, 혹은 다른 측면의 주장을 열린 마음으로 토론할 수 있고, 향상심과 함께 겸손함을 가진 분들을 결국엔 존경할 수 있었다.
내가 고집스럽기도했고, C++은 모든걸 할 수 있는 언어인데 왜 다른 언어를 굳이 써야하지? 게임 개발은 어려운 일들이 많이 하니까 가치있어 같은 편협한 생각도 가졌던 나에게, 위에서 언급한 유연하고 겸손하고 훌륭한 분들이 내 생각을 많이 바꿔주셨다.
그리고 나는 그 분들 처럼 되고 싶었다.
그렇게 유연한 사람이 되기 위해, 새로운 분야를 경험해보고자 한 측면도 꽤 컸다.
이렇게 웹&플랫폼 개발자로써 일해보고나니 알 수 있었던 또 다른 요소는, 그나마 웹&플랫폼 개발자는 비슷한 성향이나 근거, 판단이 유사한 측면이있다. 바로 효율, 재사용성에 집착한다는 측면이다.
사실 웹&플랫폼 개발자들은 유연하고, 게임 개발자는 그렇지 않아라고 하기엔 그렇지도 않았다. 실제로 환경이 잘 가져다 쓰는 것이 중요하다고 주입된 것이지, 본인이 그 효율성에 통감하거나, 선택해서가 아닌 경우가 많았고, 그렇게 얻은 효율성을 잘 활용하는 사람이 딱히 많다고 보기 어려웠다.
또한 게임 개발자 중에서도 최근엔 잘 조합해서 효율을 내고자 하는 노력이 여기저기서 이루어지고 있다.
웹&플랫폼 개발자 분들 중에서도 편협하고, 유연하지 못한 분들이 많고, 게임 쪽도 마찬가지다. 어딜가나 고집스럽고, 자신의 경험이나 자신의 실력만 집착하는 사람들이 변화나 발전에 걸림돌이 된다.
안정성이나 합리성을 뒷전으로 둔 채 변화만 쫓는 것도 문제지만, 무작정 자신의 경험, 지금껏 그래왔다는 부족한 근거로 변화를 거부 하는 것도 문제다.
성장 할 수 있는 동력을 갖추기 위해선 겸손하고 유연한 사람이되어, 다른 분야의 장점을 받아들이려고 노력하는 게 필요하지 않을까 싶다.
내 생각
양쪽 다 경험해본 내 입장에선, 게임 개발은 재사용성을 좀 더 높이는 노력과 기술 내재화와 경험을 전파하는 노력이 이뤄진다면 많은 것이 더 좋아질 것이라고 생각한다. 아직은 개인의 역량이나 경험이 조금 더 중요한 경향이 있다. 미들웨어나 프레임워크를 덜 사용하기 때문에, 게임에 따라 특화된 구조가 나오고 이 구조는 안정성 전반에 영향을 주기 때문에, 개인의 역량이 크게 중요하다. 게임 마다 다르게 구성 되어 있는 구조를 이해하고, 그 안에서의 최적의 해를 구하는 것이 중요하기 때문이다.
상대적으로 개인의 역량이 중요하므로, 리드 프로그래머, 메인 프로그래머 영역에 있는 사람은 프로젝트에 빠져선 안될 스폐셜 원이 되기 쉽다.
반면 웹 개발은 국내는 대다수가 스프링이다. 자바와 스프링만 쓸 줄 알면 어떤 업무건 적응해야 될 요소가 상대적으로 크게 적다. 또한 웹 프론트 엔드도 자바 스크립트가 오랜 시간 유일한 선택이었고, 메이저한 프레임워크 (Angular, React, Vue), 플랫폼 개발도 메이저한 시스템 (하둡, 스파크, 엘라스틱 서치 등등)을 사용하기 때문에 그 경험이 통용되기 수월하다.
웹이나 플랫폼 개발에서도 메인이나 리드 프로그래머는 중요하다지만 팀 관점에서도 상대적으로 리스크가 적다. 또한 개발자가 이직시에도 적응 코스트가 낮아지는 장점이 있다.
마치며
지금껏 얘기한 비교는 지극히 내 경험에 한정되어있고, 기껏해야 지인들과의 대화에서 내린 결론에 불과하기에 정답도 아니고, 지향점도 될 수 없다.
다만 어떤 분야의 개발자가 되고 싶은지 고민 중이거나, 전업을 고민하는 개발자들에게 도움이 될 글을 쓰고 싶었다.
또한 내가 너무나도 궁금했던 웹&플랫폼 개발과 게임 개발이 무엇이 다른지 알고 싶은 개발자들에게 조금이나마 도움이 되지 않을까 싶어, 정리가 덜 된 글이라 요약하고 싶지만, 아쉽게도 두서없게 6개월만에 마무리한다.
아마도 이 글에서 다룬 이야기는 더 잘 요약해서 다시금 쓰게 되지 않을까 싶은 예감이 든다.