.NET CORE

온라인 게임 개발 시절 대상 환경이 윈도우였고, 클라이언트에서 전향한 개발자가 많아서 서버가 윈도우인 경우가 많았다.

내 경우만해도 윈도우 서버를 아주 오랜 기간 사용해오다가, Ruby on rails를 사용하면서 조금씩 익숙해진 리눅스 서버가 Django를 거쳐, 자바 스프링으로 클라우드 서비스를 개발하고 운용하면서 리눅스 서버에 친숙해지는 계기가 됐다.

게임 개발에서도 유니티에서 C#을 사용하는 일이 빈번하다보니, 서버도 언어를 맞출 겸 C#으로 사용해보는 것을 검토해보기도 했으나, C#으로 리눅스 서버를 사용하는 것은 mono를 통한 구동 뿐인데, 수 많은 전제 조건하여 쓰여진 코드가 죄다 윈도우 기반인 코드가 완벽하게 호환되지 못했고, 어찌어찌 동작이 된다고 해도, 불안할 수 밖에 없는 것이, 가끔 동작하는 특정한 코드가 런타임에서 문제를 일으킬 소지가 남기 때문에, 결국 C# 서버는 윈도우에서 운용하는 것이 답이었다.

친 리눅스로 MS가 방향을 선회하고, C#의 윈도우, 리눅스, mac OS X 에서 공통적인 구동 환경을 위해 추진 한 것이 바로, .NET Standard이고, 이를 기반으로 구현된 구현체가 .NET CORE다.

https://en.wikipedia.org/wiki/.NET_Core

첫 정식 버전이 2016-06-27 이니, 3년쯤 된 녀석이다. 2016년 말경 .NET CORE 1.0부터, 1.1로 버전업 될 때 까지 사용했었는데, 그 때만해도 대다수의 nuget 패키지들은 .NET Framework에서만 동작했으며, 오픈 소스로 컨버팅 된 프로젝트들은 다수가 사용 불가나 다름없었다. MS가 직접 포팅하지 않은 패키지들 다수에서 버그가 다수 발견됐고, ASP.NET CORE의 실 서비스 사용은 아직 시기 상조라고 생각하게 됐었다.

2019년 6월 현재 시점 .NET CORE의 정식 버전은 2.2이고, 3.0 preview단계인데, 시간이 흐름에 따라 production 레벨로 운용중인 서비스들고 늘어나고, 패키지들 안정성이 높아졌으며, 대다수 .NET Framework 기반의 패키지들이 이식되면서 생산성이 크게 확보된 상황인 것을 알 수 있었다.

리눅스에서의 C#은 아직도 과거의 C#을 경험해본 사람들의 편견과, MS의 태세 전환을 체감하지 못한 사람들로 우려가 많은 것이 사실이지만, 실상 어마어마한 속도로 성장중이다.

이게 얼마나 급격한 성장속도냐하면, 2017년 자료에서의 nuget 패키지 수는 고작 7만개에 부족했는데 2년여만에 두배의 패키지 수가 확보되고 있는 것이다.

2017년에는 패키지 수가 7만여개에 불과했따.

2017 mar module counts

2019년 현재는 python, ruby와 비슷한 패키지 수를 확보한 것을 알 수 있을 것이다.

2019 may module counts

또한 SQL Server (MS-SQL)도 리눅스에서의 안정성 검증이 완료됐으며, WSL 2를 이용하면 성능 저하 없이 리눅스 개발을 윈도우에서 할 수 있고, 테스트도 편하게 가능해지는 장점도 생겼다.

개인적으로 리눅스 서버에서의 운용이 얼마나 편한지와 비용 감소를 겪고 나니, 리눅스에서의 서비스가 가능한 언어나 플랫폼이 기술 선정의 조건 중 하나였는데, 이를 충족 시켜주고 다른 요소들 (언어의 편의성, 개발 툴의 편의성, CLI 도구 지원, 유니티 사용시 서버/클라 언어의 일치, 웹 프레임워크, 소켓 프레임워크 존재) 까지 받쳐주니 선택지가 하나 더 확보됐다고 생각한다.

특히 소켓 서버가 필요한 게임 서버 개발에서는, 웹/소켓 프레임워크의 존재가 선택에 있어 큰 메리트가 된다고 생각한다.

현재 .NET CORE와, DotNetty를 이용한 여러가지 구현을 하고 있는데, 이와 관련된 이야기를 앞으로도 이어가보고자 한다.

게임 서버 개발과 웹 서버 개발의 차이

늘 궁금했다. 웹 개발이란 어떤 것인지.

물론 이것저것 관심이 많다 보니, 임베디드, 보안, 인공지능 등 대부분 관심이 많지만, 좀 더 대중화 되고 컨텐츠 개발에서 주류에 있는 웹개발은 조금 더 궁금했다.

사실상 책 따라하기 수준의 방명록, 게시판 정도론 웹 개발자들이 어떻게 생각하고, 무엇을 중요시 여기고, 어떤 것을 잘해야 하고, 어떻게 일하는지 알 수 없었다.

그저 짐작을 할 뿐이나, 웹알못이 짐작하는 수준이라곤 게임 서버도 보이지 않는 backend 관점이니, 웹 백엔드와 큰 차이가 없을거라고 생각했다.

결론부터 말하자면, 비슷하면서도 아주 많은 간극을 보인다.

특히 문제를 해결하는 방법, 중요시 여기는 가치, 기본기라 여기는 기준들 너무 많은 것이 달랐다.

약간 과장해서, 다른 직업이라고 느껴질 정도로 달랐다. (과장이라고 표현했으나 나는 이렇게 생각하고 있다. 임베디드, 웹, 보안, 플랫폼, 게임 등…각 분야가 의외로 많은 차이를 보인다고 생각한다.)

왜 이런 차이가 생기는 걸까?

웹의 발전은 브라우저 기반위에서 이루어졌다.

브라우저라함은 HTML 파서이자 뷰어라 할 수 있는데, 브라우저가 소화 가능한 규격으로만 통신해야 함을 의미한다.

이를 주고 받기 위한 HTTP 프로토콜이 반론의 여지가 없는 표준이었다. 웹표준과 별개로 HTTP 프로토콜은 웹에선 빠르고, 당연하게 표준으로 자리 잡았다.

초창기 성능이나 네트웍 속도에 제약으로, 정적 페이지를 적극 사용했는데, 이는 소수의 관리자가 컨텐츠를 편집했기에 가능한 접근이었다.

반면 게임 서버는 커스텀한 클라이언트 프로그램인 게임을 위해 발전해왔다. 브라우저라는 제약이 없었고, 그러므로 반드시 HTTP 프로토콜을 사용할 필요는 없었다. 그렇다 보니, HTTP 프로토콜에서 소요되는 cost마저 아끼고 싶어했다. (소켓을 직접 통제하고, 헤더와 인증, 보안 처리 모두 커스텀하게 처리했음을 말한다.)

또한 HTTP 프로토콜의 특징인 connectionless, stateless는 게임에 어울리지 않았다.

이는 아래서 설명할 반응성이 웹보다 훨씬 중요하기 때문이다.


당시에도 그랬고, 지금도 게임은 반응성이 웹보다 훨씬 더 중요한 분야다. connection을 맺고 끊는 비용, connection이 생성되고 필요한 작업을 위해 매번 db를 질의하는 비용 모두 줄여서라도 반응성을 유지하는 것이 더 중요했다.

그렇다보니 표준이 아닌, 게임 마다 다른 TCP 프로토콜 위에 게임별 프로토콜이 각기 다른 모습으로 구현됐다.

동적 컨텐츠인 게임은, 웹처럼 다수의 사용자에게 유사한 HTML 코드를 동일하게 전송할 수 없었고, 실시간으로 변동되는 데이터를 다뤄야했기에, 다른 방향으로 발전했다.

요새의 게임 개발에선 아닌 경우가 더 많아 졌지만, 내가 처음 게임 개발에 입문했을 때만해도, 패킷 만들 때 최소한의 비트를 사용하고, 어셈코드로 렌더링하며, 메모리 정렬 단위를 계산하며, 복사 연산을 최소화 하기 위한 코딩을 했어야 했다.

이는 제한된 서버 자원을 잘 활용해야만 동접이 높은 게임을 만들 수 있기 때문이다. 그 게임 내에서 수많은 동작이 실시간으로 이루어지는데, 이 로직들을 최대한 가볍게 짜고, 의도치 않은 큰 연산이 일어나지 않아야 렉이 생기지 않기 때문이다.

실제로 온라인 게임의 렉(latency)은 대부분 네트워크 환경으로 인한 문제보다는 서버 내부의 로직이 도는 시간보다 더 많은 처리 요청이 발생해 처리가 밀리면서 발생한 현상이었다. 멀티스레드로 구현하면서, 블러킹 포인트를 만들어 생기는 경우도 없었다고 할순 없겠다.

이는 패킷을 처리하고, 사용자에게 응답하기 까지의 시간을 유지하지 못하면 응답성이 떨어지며, 이 응답성이 게임 클라이언트가 허용한 범주보다 늦어지게 되면 사용자는 렉을 느끼게 된다. 이를 해결하는 방향성 중 하나는 모든 연산을 최저치로 낮출 수 있는 데로 낮추는 접근이었다고 말할 수 있겠다.

반응속도와 함께, 데이터 무결성을 보장해주어야 한다. 게임 사용자는 조금의 지연도 용납해주지 않는다.

내가 조금전 획득한 아이템이 10초후에 인벤토리에 들어온다고 치자. 사용자들은 바로 불편함과 우려를 표할 것이다. 아이템 시스템에 오류가 생긴것이 아닐까 불안해하며, 자신이 획득할 아이템에 대한 신뢰도마저 의심하곤 한다.

마찬가지로, 내가 싸우는 몬스터의 HP 감소가 10초후에 이루어진다면? 내 체력도 10초후에 감소 된다면? 사용자들은 해당 게임이 정상적이지 않고, 문제가 있다고 인지하는 상황이 된다.

그리고 만약 재접속 해야만 아이템 보상이 들어온다면? 현재 내 아이템 상황과, 내 눈에 보이는 상황이 달랐을 때 사용자들은 이 상황을 문제라고 인지하게 된다. 아마도 디아블로2의 복사 아이템 사건등을 겪은 사용자들이, 이런 현상이 아이템 복사 등으로 이어질지 모른다는 불안감도 한몫 해서 불안함을 갖기도 한다.

지연적인 아이템, 상태 반영이 해당 게임의 시스템적으로 구성되어있다면, 불편함과 비직관성으로 큰 비판을 받게될 요소다.


반면 웹은 실제 디비에서 처리되고 있는 데이터보다 조금 예전 데이터를 주더라도 크게 문제 삼지 않는다.

그렇다보니 캐싱이 더 쉬워지고, 브라우저도 캐싱을 하며, 사용자도 이를 인정하고 새로운 데이터를 전달 받기 위해 새로고침을 직접 한다. (사용자들 마저 이 과정을 불쾌감으로, 오류로 받아들이지 않고 자연스럽게 받아들이는 것이 포인트다.)

이는 훨씬 더 많은 사용자에게 컨텐츠를 제공하는 방향으로 발전할 수 있는 원동력이 되기도 했다. 캐싱과 스케일아웃이 유연할 수 있는 근거는, 지금 언급한 조금의 지연이 있는 데이터, 혹은 소수의 사용자가 편집한 데이터를 전달하는 것도 용인 될 수 있는 웹 환경이 그 근거다.

애초에 데이터의 변화량/응답속도가 너무나도 중요한 가치인 게임과, 생산성/확장성이 더 중요한 웹은 궤를 달리 할 수 밖에 없었던 운명이었던 걸지도 모른다.

이제와서 서로 간의 기술 융합과 응용이 이루어지고 있는 모습은 아주 긍정적이라고 생각한다. 이 흐름이 상대적으로 서버의 역할을 한정 지었던 모바일 게임에서의 웹 서버 기반의 서비스였긴 하지만, 그렇게 많은 게임 서버 개발자들이 웹 이해도가 늘었다.


다시금 모바일 게임도 MMORPG붐이 일면서, C++, C# TCP 게임 서버가 다시금 도입되고 있다. 최근 몇년간 게임 개발을 하고 있지 않아서 정확히 말하긴 어렵지만, 커스텀 게임 서버만으로 모든 컨텐츠를 만들어오던 과거와는 달리 이제는 적절한 지점에 웹서버도 이용하지 않을까 싶은 생각도 든다.

트랜잭션 위주의 로직 서버로 웹 서버는 탁월한 선택이 될 수 있다. 또한 인게임 컨텐츠 중 일부(예를 들어 인게임 공략, 공지사항, 상점, 광고, 일부 이벤트 등)의 경우 웹 서버를 통해 구현하면 훨씬 더 수월하게 구현 가능하기도 하다.

또한, 게임마다 다른 내부 구조를 이해하지 않고도, 사용되는 웹 프레임워크만 이해하는 사람도, 부분적인 분업도 가능해지므로 이 또한 협업과 분업의 메리트가 생길 수 있는 부분이다.

또한 성능상의 이슈에서 상대적으로 자유로울 수 있는 컨텐츠 위주로 웹 서버를 이용한다면, 생산성 좋은 언어, 프레임워크를 선정할 수 있다는 장점도 있다.

그렇게 유연한 선택을 통해, 안정성과 생산성을 얻을 수 있다면, 좀 더 고민이 많이 필요하고, 시간이 많이 필요한 작업에서 필요한 시간을 버는 데에 쓸 수 있을 것이다.

게임 서버는 특수성으로 인해 웹서버만으로 모든 시스템을 구축/운용 하는 것도 안되고, 커스텀 TCP 서버는 생산성이 너무 떨어진다. 이제는 게임 서버 개발에서도 폴리글랏 아키텍쳐가 필요할 때가 아닐까?

C++ 게임 서버 개발자의 웹 프론트엔드 적응기

다른 언어도 몇년간 실무에 썼음에도, 난 아직도 C++이 아직도 가장 익숙한 언어다.

C++을 제외하고, 내가 가장 적응하기 쉬웠던 다른 언어는 C#과 루비다.

사실 파이썬은 indent 강제에 대한 거부감이 크게 작용해서 기피했었는데, 막상 업무상 필요해서 써보니 indent 강제는 장점도 많았고, 루비와 비슷한 측면도 꽤 많아서 (다른 측면도 매우 많지만) 쉽게 적응할 수 있었다.

사실 의외로 자바는 적응하기 힘들었는데, 이는 다른 글에서 몇 번 언급한 자바 개발자들의 문화와 규칙 때문이었다. 하지만, 이는 게임 서버도 나름의 규칙과 접근, 룰이 이해할 수 있는 부분이었다.

또 다른 어려웠던 점은 자바의 발전 속도가 더뎌 다른 언어에서 이미 사용하던 기능 여럿을 쓸 수 없었고, 어노테이션 같은 확장 기능으로 커버해도 여타 언어만큼 편의성을 제공하지도 못한 자바를 (타의로) 사용하게 되고 나서 보니, 불편함 덩어리라서 굳이 이걸 각 잡고 배워야하는 가에 대한 회의감도 함께 했음을 고백한다.

여하튼 그렇게 웹 개발, 플랫폼 개발에 발을 들였는데 처음 발을 들였을 때는 플랫폼과 백엔드 작업으로 한정짓다보니 자바에 비중이 높았고, 시간이 약이라고 나도 자바에 어느정도는 익숙해져가고 있었다.


그러던 와중 합류한 팀에서 1-tier 개발을 한다고 하더라. 그래서 자바 스크립트도 배워야 했는데, 나는 Jscript(https://ko.wikipedia.org/wiki/J%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8)라는 Java Script의 윈도우 스크립트 엔진으로 써본게 다였다보니, 조금 걱정이 됐다.

다행히 Admin Tool 작업을 몇번 하다가, 본격적으로 frontend 작업을 하게 됐는데, 이 마저도 몇번의 작업은 국지적인 수정이라서 다행이었다.

하지만 무언가 수정 사항이나 기능 개발, 이슈 확인을 위해선 자바 스크립트 코드를 읽어야 되는 상황을 맞이하게 됐고, 이 부담감을 지워내기 위해 본격적인 학습에 돌입했다.

그렇게 만든 것이 Community Board 였다. Vue.js를 팀 내부적으로 사용하고 있었고, 나도 이에 맞춰 복습 및 경험치 획득을 위해 만들게 됐다.

이렇게 데브 토이로 Vue.js를 썼음에도, 자바 스크립트 자체에 대한 낮은 숙련도는 계속 업무적 비효율로 이어지고 있었고, 스트레스의 원인 중 하나가 됐다.

그러던 차에 업무적으로 진행된 서비스 하나가, backend/frontend 중에 선택 가능한 상황이 됐고, 나는 여기서 자바스크립트 숙련도 향상을 위해 frontend를 선택하게 됐다.

그 결과 확실히 거부감이 많이 줄어들었고, 익숙해졌고, 그만큼 많은 감상이 들었다.

  1. 자바 스크립트 자체는 linter가 없인 너무 큰 자유도로 코드 가독성이 들쭉날쭉해지기 쉽상이라는 것.
    • 이를 해소하기 위한 방법으로 linter와 framework를 사용함으로써 팀 규칙대로 코드를 작성하게 (반)강제하고, 다양한 스타일의 난립을 억제하려 하는 것 같다.
  2. 자바 스크립트 자체는 아직도 불편하지만, lodash 같은 편의성 높은 패키지로 대체하고, module counts 의 최다 패키지 보유 플랫폼 답게, 수많은 기능을 가져다 사용해서 개발 공수를 낮출 수 있다는 것
    • download 카운트가 높다고해서, 딱히 완성도 있거나, 깔끔하게 동작하지만은 않았다.
    • 초기에 만들어진 패키지라 다운로드 수가 많고, 이후에도 낚인 사람이 많아서 높은 download 수인 경우가 많으니 이 점에 주의하라.
  3. 웹 프론트엔드에선 (변환기로써 구현되는 경우를 제외하면) 사실상 javascript가 필수나 다름없다보니 javascript 자체에 익숙해지려고 노력해온게 frontend 개발자 다수의 선택이고, 그렇다보니 javascript 자체의 점유율이 늘고 있다.
    • 앞으로의 javascript 성장세는 미지수지만, frontend에서라도 확고한 위치는 확실하다는 것
    • 개인적으로는 backend에서의 성장세는 꺾였고, 더 늘진 않을 것이라고 생각한다.
  4. JSON을 다루는 것이 너무나도 편하다는 것.
    • 애초에 Java Script Object Notation의 약자가 말해주듯, 다루기 너무 쉽다. 다른 동적언어보다도 훨씬 쉽다.
  5. 역시 동적 언어는 까다롭다는 점.
    • 여러 번 언급한 얘기지만, 동적 언어는 테스트 코드로 이를 커버해야 한다.
    • 하지만 아래에 언급할 프론트엔드가 단위 테스트를 작성하기 상대적으로 까다롭고, 내가 익숙하지 못한 이유도 있다.
    • 또한 단위 테스트로 커버를 한다고 해도, 정적 언어보다 실수할 여지, 놓치는 부분이 있을 여지는 압도적으로 많다.
  6. 자동화 테스트에 대한 해결책은 아직 갖추지 못했다. 남들은 다 잘 하는 것 같은데, 내 프론트엔드 테스트 코드는 제로에 가깝다.
    • 이는 자바 스크립트의 문제라기 보단, 프론트엔드 단위 테스트, 자동화 테스트가 로직 테스트보다 어려운 문제에 가깝다.
    • 아직 이 문제에 대한 완벽한 해결책을 갖지 못한 것이 큰 아쉬움.

결과적으로 아주 좋은 경험이었는데, 내가 가진 자바스크립트라는 언어 자체에 대한 편견을 조금 내려 놓는다면, 그만큼 많은 성장과 시야가 넓어지는 계기가 될 수 있을 거라는 생각이 들었다. 또한 아직은 몇가지 편견을 버리지 못했다. 언어적 한계로, backend에 어울리지 못하는 언어라는 생각. Node.js처럼 학습 코스트는 높을대로 높고, 언어적 한계는 명확히 가졌고, 자유도 마저 쥐어줘서 생기는 복잡도에 대한 리스크가 내가 가진 편견이다. 이 편견을 과연 깰 수 있을지는 잘 모르겠다. 나는 아직도 여전히, 프레임워크가 도와준다해도 동적 언어가 가질 수 있는 안정성은 한계가 있다고 생각하기 때문이다.


반면 frontend로 한정 짓는다면 패키지를 조합해서 해결 할 수 있는 문제가 아주 많았다. 프레임워크도 훌륭하고, 관련한 레퍼런스나 질의 응답도 많아서, 해결책이 존재하는 편이었다. HTML 코드와 자바스크립트 코드간의 연동도 프레임워크가 적정선으로 끌어내려준 느낌을 확실히 받을 수 있었다. 과거의 노가다스러웠다던 frontend 개발을 모르지만, 적어도 지금의 frontend 개발 환경은 충분히 장점이 많았다. Webpack의 도움도 아주 아주 편하고 좋은 개발 환경에 보탬이 됐다고 할 수 있겠다.

아직은 내가 frontend 개발자라는 말을 꺼내기엔 경험치도, 이해도도 부족하지만, 그럼에도 서비스 하나에 frontend를 온전히 구현하고 나서의 감상을 꼭 한번 정리하고 싶었다.

내가 게임 클라이언트에서도 재미를 느꼈던 만큼, frontend도 꽤나 재밌었다.

두번째, 세번째 경험도, 또 요구 사항이 조금 더 복잡한 경험도 해보고 싶을 만큼 재밌는 요소가 많았기에, 멀지 않은 시기에 다음 기회도 있었으면 하는 바램이다.

(내맘대로 선정한) 프로그래머를 위한 필독서 두번째

지난 번 글에 이어, 2번째 필독서 추천을 해보고자 한다.

지난번에 16선으로 추리면서, 포함되지 못한 서적과 최근 지인들에게 추천해준 책들 위주로 골라보았다.

  1. Joel On Software & More Joel On Software
    • Trello와, 사업적 영역을 담당했지만 stack overflow로 더 유명한 조엘.
    • 그의 통찰력 있는 개발에 대한 철학과 철칙을 배울 수 있는 멋진 서적이다.
      • 처음 읽었던게 2005년인데, 주기적으로 읽을 때 마다 더 많은 걸 공감하고, 느껴지는게 많아지는 좋은 책이다.
      • 애초에 그가 블로그에 쓴 글 중 일부러 옮겨온 만큼, 좋은 개발자는 어때야 하며, 좋은 개발팀은 어때야 하고, 좋은 회사는 좋은 개발자를 위해 무엇을 해야 하는지 뚜렷하게 제시했고, 합당했다.
  2. 소프트웨어 장인
    • 큰 기대를 하지 않고 봤으나, 꽤나 괜찮은 내용이 많았다.
    • 다만 현재 상황이 어떤가에 개의치 않고, 너는 잘해야되 라는 내용이 많아서, 꼰대같은 내용이라는 생각이 들 수도 있는 책이었다.
    • 내 생각과 동일한 부분은 환경이 사람을 만든다는 말도 맞지만, 환경이 여의치 않더라도 내 자신을 발전 시켜놔야 더 좋은 환경을 내가 만들 수도, 그 환경을 쟁취할 수도 있다고는 생각한다.
  3. Effective 시리즈
    • 저자는 다르지만, C++의 scott meyers씨처럼 저명한 분들이 각 언어로 저술해주고 있는 언어의 철학, 깊이를 충족 시켜줄 수 있는 좋은 서적이다.
    • C++만해도, Effective C++, More Effective C++, Modern Effective C++ 3권이나 있고, Effective Java, Effective C# 등의 서적이 존재하는데, 해당 언어를 좀 더 이해하고 싶다면 꼭 읽어보는 것이 좋다고 생각한다.
      • 저자가 다른데도 퀄리티가 준수한 것은, 애초에 언어의 문화, 철학에 대한 이해를 돕는 주제 자체가 좋은 거 같기도 하다.
  4. C로 배우는 알고리즘 1 & 2
    • 특정 언어에 편중된 책은 가급적 추천을 하고 싶지 않지만, 자료 구조와 알고리즘의 기초 언어로 가장 적합한 것이 C언어이다보니, 추천을 하게 됐다.
      • 나 역시 대학 교재의 부족한 설명과 모호한 설명을, 이 책이 대신해줬다.
        • 두고 두고 기억에 남는 자료 구조 및 알고리즘 기초 서적이라고 볼 수 있다.
  5. 린 소프트웨어 개발
    • 애자일 개발서라지만, 실제론 효율론에 가깝다고 볼 수 있다.
    • 수많은 애자일 방법론 서적이 있지만, 그 중에 가장 와닿고, 효율에 대해 다시 생각할 수 있는 거리들도 많아서 큰 도움이 된 서적이다.
  6. 피플웨어
    • 요즘 들어 많이 중요하다고 더 느껴지는 책이다.
    • 목표 지향적, 결과 중시 적어도 한국의 게임 회사에서, IT 회사에선 너무 많이 봤다.
    • 조직의 동기부여에는 실패해놓고, 왜 열정이 없느냐고, 자신이 만들고 있는 제품을 사랑하지 않느냐고?
      • 애사심이라는 것이 어떻게 생기는 것이고, 그것이 어떤 결과를 가져다 주는지 고민해봐야 하는 사람들 (관리자, 경영진)이 읽어봤으면 좋겠는 책.
        • 하지만 그 들은 이런 책 읽지 않겠지….
  7. 사랑하지 않으면 떠나라
    • 절판 된 서적이라 구하기 쉽지 않겠지만, 나는 개발자 들이라면 꼭 한번은 읽었으면 좋겠다고 생각하는 책이다.
    • 꽤나 많은 개발자들이 곰같다. 둔하고 무던하고, 변화를 두려워한다.
    • 그래서 불편하고, 괴롭고, 동기부여가 부족함에도 자신의 문제로 치부하고 묵묵히 일한다.
      • 그렇다고 최상의 결과나, 좀 더 나아진 결과를 내는 데에도 실패한다.
        • 왜냐면 이미 일은 일이 되어버렸고, 열정은 사그라졌지만 별다른 대안을 찾기에 두려움도 존재해 현실에 안주하기 때문이다.
    • 또한 회사의 선택과 회사에서의 자신의 포지션, 자신의 업무가 그 회사에서 어떤 가치를 가지는 업무인지 등에 대한 다양한 생각을 가질 수 있게 도와준다.
    • 책 제목이 강하게 번역되서 그렇지, 실제론 이직 추천서, 이직 종용서는 아니고 회사 생활을 좀 더 가치있고, 즐겁게, 동기부여 되어 업무에서의 성취감을 찾을 수 있게 도와주는 자기 개발서라고 보는 것이 더 옳다.
    • 제목에 대한 편견을 버릴 수 있다면, 어떠한 마음가짐으로 개발자로써의 회사 생활을 맞이해야 하는지 판단에 도움을 줄 책이라고 생각한다.
  8. 해커와 화가
    • 해커 (뛰어난 프로그래머. 프로그래밍 그 과정 자체를 즐기는 사람이라는 의미가 강하게 사용됨)를 화가에 비유하는 독특한 시점으로 쓰여진 책.
    • 역자 서문에서 임백준씨도 밝히지만, 책 곳곳에서 느껴지는 오만하게 보일 수 있는 보수적인 관점이 불편할 수도 있다.
    • 다만 프로그래밍을 온전히 즐기고자 했을 때, 어떠한 부분이 화가의 그것과 비슷한 지에 대한 그의 생각은 흥미로웠다.
    • 프로그래머를 단순 공돌이로만 치부하기도 하는 현실도 무시하기 힘든 건 사실이지만, 프로그래밍에 대한 개념을 좀 더 독특한 관점에서 말해주기에, 그런 생각이 꽤 많은 프로그래머들에게 자극이었고, 발상의 전환에 도움이 될 좋은 이단스러운 책이라고 생각한다.

전반적으로 측정 언어에 편중된 책은 배제하려다보니, 인문학 관점에 가까운 책들을 더 많이 추천한 것 같다.

특정 언어에 편중된 책들 중에서 좋은 책을 추천하고 싶었는데, 아무래도 프로그래머 필독서로는 애매한게 아닌가 싶더라.

C++, C#, Java 등의 특정 언어에 편중된 서적은 따로 작성하는 것이 맞겠다는 싶더라. 다음 필독서 모음은 그렇게 작성해보겠다.

C++ 게임 개발자의 웹 & 플랫폼 개발 적응기

나는 게임 개발자였다.

첫 시작은 게임 클라이언트였지만, 이후 꽤 긴 시간을 게임 서버 개발자로 보냈다.

꽤 많은 시간을, 꽤 많은 게임을 만들었고, 유지보수도 했다. 하지만 아쉽게도 성공한 프로젝트는 없다.

그 시간 동안 게임 개발과, 게임 플레이는 아주 많은 간극이 있다는 것도 알았고, 엔지니어는 거들 뿐 프로젝트의 성공을 위해선 훌륭한 프로듀서와 훌륭한 기획자가 최우선이란 것도 알았다. (때로는 홍보도)

그렇게 조금씩 지쳐 갈 때 즈음, 웹 서버로 구현하던 많은 라이트한 게임들을 통해, 게임 서버 계에 웹 서버 붐 불었다.   나 역시 흐름에 따라 ruby on rails를 게임 웹 서버로 이용하며 발을 담그긴 했으나, 웹을 제대로 알지 못하고 썼으며, 사실상 DB 트랜잭션+로직 단위를 웹 콜 하나로 묶는 수준의 웹 서버를 구축했다고 봐야했다.


나는 여전히 게임을 많이 플레이 한다. 아니 어쩌면, 게임 개발자 일때보다 지금 더 많이 플레이하는 것 같다.   서버 개발자로 주로 지내오면서도, 내가 개발하는 게임이 해외 AAA 게임 보다 부족한 기술력, 기획력, 연출력, 아트 퀄리티, 완성도에 아쉽긴 했다. 그러나, 희망론자인 나는 앞으로 나아질거란 기대를 놓지 않았음은 물론이다.

나는 스토리 기반의 싱글 플레이 게임을 선호하는데, 이는 아마 내 성장기에 즐겨왔던 게임이 주로 그랬던 것과, 엔딩이라는 종착지가 있음이 성취감을 주기 때문이기도 했던 것 같다.

또한 MMORPG나, FPS, TPS등의 일부 장르에서 국내 기술력이 해외 메이저 게임보다 아쉬운 면도 있는건 사실이지만, 그렇다고해서 경쟁이 안될 정도로 벌어져 있는 상태가 아니었기에, 운이 조금 따른다면 충분히 좋은 프로젝트를 만나 재미와 흥행을 모두 잡는 게임을 만들 수 있을 거란 기대를 품고 게임 개발자로써의 성장을 위해 노력했다.


사람일은 어찌 흘러갈지 모르는 것처럼, 자의 반, 타의 반으로 서버 프로그래머로 전향하고 나서도 몇년간 클라이언트 개발을 다시 하고 싶어 했었으나 실무 기간를 게임 서버를 오래했던지라 경쟁력 문제로 게임 서버 개발을 계속 하게 됐었고, 그렇게 이어가던 게임 서버 개발자로써의 재미와 목표점을 찾게 된 다는, 게임 서버 개발자로서 많은 경험과 노력이 빛을 발할 날을 기다리고 있었다.

모바일로 시장이 급변하고, 라이트한 게임이 시대의 흐름이 되었을 때, 서버 프로그래머인 나는 굉장히 혼란스러웠다.

내가 중요하다고 여겨온 가치 몇가지가 와르르 무너지는 느낌이랄까?

스마트폰 모바일 게임 시장의 초창기에는 서버는 저장소 이상의 가치로 쓰이지 않았다. 사실 그 정도로 쓰인다면 웹서버를 로직 & 데이터베이스 중계역할 정도로도 충분했다.

그렇게 기술적 요구사항이 낮아지고, 온라인 게임에선 해킹, 검증 등의 이유로 절대 해선 안되던 일인, 로직이 클라이언트로 내려갔고, 이는 상시 네트웍 연결 상태가 아닐 수 있다는 이유로 내려가게 됐고, 조작 방식이 터치로만 이루여져야 한다는 한계는 일부 몇개의 게임을 제외하곤 게임의 방향성 마저 내가 좋아하는 장르나 지향점과 많이 멀어지고 있었다.

그렇게 내가 잘해오던, 내가 경쟁력을 가지던 것들이 무색해지면서 느낀 혼란은, 게임 개발의 재미를 급감 시켰다.

이 의문에, 나는 내가 클라이언트 개발을 하면 재미를 찾을 수 있는지 알기 위해, 유니티 클라이언트 개발로 게임을 출시하기도 했지만, 이젠 게임 서버 개발을 더 잘해내고 싶은 목표를 이미 갖고 있던 나에게 만족도를 가져다 주는 경험이 되진 못했다.

이렇게 변한 환경은 기술적 요구사항이 낮아진 만큼 시간을 벌 수 있을테고, 컨텐츠에 조금 더 집중할 수 있지 않냐 라고 물어볼 수 도 있다.

그랬다면 좋았을 텐데, 기술적 요구치가 낮아진 만큼 더 짧은 일정이 주어졌고, 그로 인해 게임 퀄리티는 더더욱 내가 생각하는 좋은 게임과 멀어지는 계기가 됐다.


아쉬웠던 게임 개발에 대한 이유와 별개로 웹&플랫폼 개발을 하고 싶었던 것은, 오픈 소스 환경에서의 생산성을 느끼면서 이다.

애초에 최대한 많은 도구를 인하우스 개발을 해오던 게임 개발자가, 오픈 소스로 패키지들을 가져다가 조립해가며 높은 생산성을 맞이하게 됐을 때, 즐거웠다.

젊은 시절 과도한 야근과, 철야로 해친 건강을, 회복하지 못한 내 잘못도 크겠지만, 그로 인해 예전보다 집중력을 많이 잃으면서 적은 공수로 많은 비즈니스 로직을 구현할 수 있는 오픈 소스 문화권의 잘 가져다 써서, 잘 조립하는 환경에 대한 호기심이 생겨나게 됐다.

사실상 개인 C++ 라이브러리까지 꽤나 긴 유지 보수해가며, 최대한 많은 코드를 내 스타일로 커스텀하고 관리하고, 이를 바탕으로 개발하던 게 습관이던 내가, 다른 사람들이 만든 기능을 조합하는 일을 받아들이고, 재밌어 하는 일은 쉬운 결정은 아니었다.

바퀴를 재발명해서 더 나은 바퀴를 만들기 위해 고민하던 내가, 바퀴를 조합하는 일을 재밌게 할 수 있을지, 또 내 삶에 큰 의미를 가지는 게임 개발이 아닌, 다른 분야에 대한 개발에서 성취감과 재미를 찾을 수 있을지는 확신이 없었다

좀 더 쓰기 좋은 바퀴를 만드는 일 보다, 좀 더 성능 좋은 바퀴를 만드는 데에 집착했던 나로서는 더더욱 그런 면이컸다.

온라인 게임 개발할 땐 게임 서버 팀 내에서도, 주로 네트워크 라이브러리 작업, 커버리지 확보나 안정성 검증 작업을 더 많이 했던 나로서는 컨텐츠 개발을 적게 해서 그랬던 것 같기도 하다.

모바일 게임으로 넘어오면서는 컨텐츠 작업의 비중이 더 커졌는데, 그 과정에서 바퀴를 가져다가 짧은 시간에 원하는 컨텐츠를 구현하는 것이 중요할 수 있다는 것에 공감하게 되면서, 조금씩 다른 것들이 보이기 시작했던 것 같다.

그렇게 적은 공수로 컨텐츠를 만들게 되면서, 사이드잡 내지는 토이 프로젝트에서 C++보다는 다른 언어를 사용하게 됐고, 강력한 언어인 C++보다 효율적인 언어들을 찾아 사용하게 되기도 했다.


내가 웹 개발이 효율성이 좋다고 말한 이유는, 웹 개발을 이끌고 있는 리더들이, 다수의 개발자가 겪는 공통된 고민들을 오픈소스 환경 위에서 같이 고민하고, 같이 해결하며 발전해온 측면이 컸다.

게임 개발도 그런 노력이 없었던 것은 아니지만, 현시점 마저 공개된 기술의 사용이나 오픈 소스를 이용해서 풀 수 있는 문제가 한정되어 있다. 게임 마다 특화된 주제를 다룰 때도 있고, 표준화 되기 이전에 목표를 달성해 게임 출시에 사용해야 되기 때문이기도 하다.   그렇다 보니 기술의 재사용, 기술의 표준화에 있어서 웹 개발은 게임 개발보다 잘 이루어졌고, 공통 기술 스택이라 불릴 만큼 범용적 기술이나 경험이라 할 만한 것들마저 생겨났다.

결과론 적으로 웹 개발에선 팀바팀도 물론 요소가 많지만 표준들도 많았다 할 수 있고, 게임 개발은 팀바팀이 훨씬 더 크고 개인의 역량과 개인의 경험에 기대는 측면마저 크다고 볼 수 있다. (왜 그런지는 아래에서 좀 더 자세히 언급하겠다.)

이는 그렇게 기대는 개발자 개인의 이탈이 팀과 회사에 큰 리스크를 가져다 줌을 의미하고, 여전히 게임 개발은 그런 측면이 있다.

물론 유니티같은 상대적으로 이전보다 쉬운 개발 환경을 만들어 주는 툴이 히트를 치고, 위에서 언급한 디비 저장용도로만 사용하는 웹서버 등으로 서버 개발의 공수도 줄었다지만, 다시금 코어한 게임 개발로 넘어간 지금은 이전 온라인 게임 개발과 다름없이, 특정 게임만을 위한 수많은 기술이 개발되고, 그에 의존한 게임 서비스를 구축해야 한다.

이런 환경이, 모바일 게임 개발로 넘어오는 시기에 웹/플랫폼과 게임의 기술 대통합이 이뤄질 것처럼 보여졌던 환경에서, 과거로의 회귀같은 느낌마저 난다. (이는 밑에서 정리한 채용 공고만 봐도 느껴질 수 있는 부분이다.)

  이렇게 큰 차이가 나는 이유는, 문제를 푸는 방식, 문제를 해결하는 방식에서의 접근자체가 다르기 때문이다.   게임 개발자들이 만든 기술을 오픈소스화 하는 데에도 인색한 것은, 아마도 남들도 오픈소스화 하지 않기 때문일 것이다. 또한 그렇게 개발한 기술이 타 게임 개발 업계 전반에 메리트가 있기보다는, 경쟁사의 경쟁 게임에 도움이 되는 기술 공개가 되기 때문인 측면도 분명히 있다고 본다.

현시점마저 특정 팀내에서의 유틸리티, 엔진, 프레임워크 등 다수는 오픈소스가 아니다.

과거에 비해 자체 엔진이 매우 줄어들고, 엔진/툴만이라도 과거에 비해 저렴해진 것이 그나마 위안일 정도랄까?

그리고 게임 개발에서 이견이 없는 주류 언어로 오랜 기간 사용되어왔고, 다시금 선택 받고 있는 C++은 조각 코드 공유가 많지, 가져다 쓰기 쉬운 패키지 단위 배포가 잘 이뤄지지 않았다. (애초에 패키지 매니저 자체가 여타 언어에 비해 매우 늦었고, 아직도 정착 되지 못했다.)

또한 C++ 언어 특성상 라이브러리로 배포된다 한들 그 라이브러리가 세심한 검토 하에 사용되지 않으면 기존 환경 마저 깨뜨릴 수 있는 위험한 환경. 즉 네이티브 환경에서 개발하며, 맘편히 가져다 쓰지 못하고, 잘못 작성된 코드나, 라이브러리 연동과정에서 생긴 각종 트러블에 대한 네거티브한 경험에 의한 결론이 아닐까 싶기도 하다. 남이 만든 코드보다 내 코드, 내 경험, 내 판단, 내 검증만이 높은 퀄리티의 프로덕트의 원동력이라는 결론에 도달한 것 같다.

반면 웹은 브라우저나 웹 프로토콜 기반 하에서의 비슷한 이슈에 대한 고민이 많았고, (상대적으로)꽤나 많은 기능, 해결책들을 가져다 써서 해결 할 수 있었다. 심지어 가져다 써서 생긴 부작용마저 상대적으로 작았고, 웹 서버/웹 프론트엔드는 상대적으로 작은 오류에 대한 파급이 적은 환경이었다. 그런 긍정적인 경험들이 모여 가져다 써서 잘 만드는 데에 집중하는 접근, 환경에 대해 받아들이고 그 것이 옳다고 여길 수 있게 된 거라고 생각한다.


요샌 게임 개발도 효율, 기술의 재사용, 오픈소스로 문제를 많이 푼다는 이야기도 많이들 한다.

하지만 여전히 채용권자 혹은 프로젝트 리더들과 대화 해본 나는 오픈 소스를 사용하되 그 것을 도입하는 방식, 이용하는 방식에서 여전히 큰 차이가 있다고 생각한다.

이 주장을 위해 몇몇 회사의 채용 공고를 가져온다.


플랫폼 개발자

카카오 플랫폼

네이버 플랫폼

NHN 플랫폼

대용량 처리 경험과, 관련 오픈 소스 사용 경험에 치중되어있다.

웹 개발자

카카오 WEB

네이버 WEB

NHN WEB

RESTful API, DB, Spring, Java 등의 키워드가 보인다.

게임 클라이언트 개발자

넷마블 넥서스 클라이언트

넷게임즈 클라이언트

PUBG 클라이언트

공학 기초, 엔진 (언리얼, 유니티), C++, C#, 프로젝트 경험 등이 키워드다.

게임 서버 개발자

넷마블 넥서스 서버

넷마블 몬스터 서버

넷마블 블루 서버

넷게임즈 서버

넥슨 서버

엔씨 서버

C#, C++, DB, 네트웍, 로우 레벨 이해도 (TCP/IP 통신, 멀티 스레드, OS 구조 등), 트러블 슈트 등의 키워드가 나열됐다.


일부 공고에 불과하기에 일반화 하기엔 부족하지만, 게임 개발이 전반적으로 기초를 더 중요시 한다.

실제로 공고보다 면접과정, 채용과정에서 로우레벨 이해도가 부족한 사람은 뽑아선 안된다는 기조가, 웹&플랫폼보다 훨씬 더 많이 언급됐고, 작용했다.

이는 프레임워크나, 시스템 구조를 직접 작성해야 되기 때문에, 기초가 부족한 사람이 끼칠 부정적 영향에 대한 우려, 검증과 함께 개발해야 하는 게임 마다 특화된 구조를 지탱하고, 이해할 기초가 중요하다고 보는 경향이 상대적으로 높다고 볼 수 있겠다.


내가 게임 개발자로써 웹 개발자 혹은 플랫폼 개발자 분들과 대화해가며 문제에 대한 접근/해결책에 대해 너무나도 다른 시각과 해결책을 내놓고, 타협이 쉽게 이뤄지지 않는 것을 보고 왜 그런지 많은 고민을 했었다.

결국 다 프로그래머들인데 왜 이렇게 다르지?

이 궁금증에 대한 해답을 얻고 싶었다.

내가 일해오며 존경하는 몇명의 개발자가 있다. 이 개발자 분들은 흔히 말하는 머리 좋은 천재 프로그래머는 아니었다. 대부분 유연한 프로그래머였다. 생각이 경직되어 있지 않고, 자신의 의견보다 더 설득력 있는 주장, 혹은 다른 측면의 주장을 열린 마음으로 토론할 수 있고, 향상심과 함께 겸손함을 가진 분들을 결국엔 존경할 수 있었다.

내가 고집스럽기도했고, C++은 모든걸 할 수 있는 언어인데 왜 다른 언어를 굳이 써야하지? 게임 개발은 어려운 일들이 많이 하니까 가치있어 같은 편협한 생각도 가졌던 나에게, 위에서 언급한 유연하고 겸손하고 훌륭한 분들이 내 생각을 많이 바꿔주셨다.

그리고 나는 그 분들 처럼 되고 싶었다.

그렇게 유연한 사람이 되기 위해, 새로운 분야를 경험해보고자 한 측면도 꽤 컸다.

이렇게 웹&플랫폼 개발자로써 일해보고나니 알 수 있었던 또 다른 요소는, 그나마 웹&플랫폼 개발자는 비슷한 성향이나 근거, 판단이 유사한 측면이있다. 바로 효율, 재사용성에 집착한다는 측면이다.

사실 웹&플랫폼 개발자들은 유연하고, 게임 개발자는 그렇지 않아라고 하기엔 그렇지도 않았다. 실제로 환경이 잘 가져다 쓰는 것이 중요하다고 주입된 것이지, 본인이 그 효율성에 통감하거나, 선택해서가 아닌 경우가 많았고, 그렇게 얻은 효율성을 잘 활용하는 사람이 딱히 많다고 보기 어려웠다.

또한 게임 개발자 중에서도 최근엔 잘 조합해서 효율을 내고자 하는 노력이 여기저기서 이루어지고 있다.

웹&플랫폼 개발자 분들 중에서도 편협하고, 유연하지 못한 분들이 많고, 게임 쪽도 마찬가지다. 어딜가나 고집스럽고, 자신의 경험이나 자신의 실력만 집착하는 사람들이 변화나 발전에 걸림돌이 된다.

안정성이나 합리성을 뒷전으로 둔 채 변화만 쫓는 것도 문제지만, 무작정 자신의 경험, 지금껏 그래왔다는 부족한 근거로 변화를 거부 하는 것도 문제다.

성장 할 수 있는 동력을 갖추기 위해선 겸손하고 유연한 사람이되어, 다른 분야의 장점을 받아들이려고 노력하는 게 필요하지 않을까 싶다.


양쪽 다 경험해본 내 입장에선, 게임 개발은 재사용성을 좀 더 높이는 노력과 기술 내재화와 경험을 전파하는 노력이 이뤄진다면 많은 것이 더 좋아질 것이라고 생각한다. 아직은 개인의 역량이나 경험이 조금 더 중요한 경향이 있다. 미들웨어나 프레임워크를 덜 사용하기 때문에, 게임에 따라 특화된 구조가 나오고 이 구조는 안정성 전반에 영향을 주기 때문에, 개인의 역량이 크게 중요하다. 게임 마다 다르게 구성 되어 있는 구조를 이해하고, 그 안에서의 최적의 해를 구하는 것이 중요하기 때문이다.

상대적으로 개인의 역량이 중요하므로, 리드 프로그래머, 메인 프로그래머 영역에 있는 사람은 프로젝트에 빠져선 안될 스폐셜 원이 되기 쉽다.

반면 웹 개발은 국내는 대다수가 스프링이다. 자바와 스프링만 쓸 줄 알면 어떤 업무건 적응해야 될 요소가 상대적으로 크게 적다. 또한 웹 프론트 엔드도 자바 스크립트가 오랜 시간 유일한 선택이었고, 메이저한 프레임워크 (Angular, React, Vue), 플랫폼 개발도 메이저한 시스템 (하둡, 스파크, 엘라스틱 서치 등등)을 사용하기 때문에 그 경험이 통용되기 수월하다.

웹이나 플랫폼 개발에서도 메인이나 리드 프로그래머는 중요하다지만 팀 관점에서도 상대적으로 리스크가 적다. 또한 개발자가 이직시에도 적응 코스트가 낮아지는 장점이 있다.


지금껏 얘기한 비교는 지극히 내 경험에 한정되어있고, 기껏해야 지인들과의 대화에서 내린 결론에 불과하기에 정답도 아니고, 지향점도 될 수 없다.

다만 어떤 분야의 개발자가 되고 싶은지 고민 중이거나, 전업을 고민하는 개발자들에게 도움이 될 글을 쓰고 싶었다.

또한 내가 너무나도 궁금했던 웹&플랫폼 개발과 게임 개발이 무엇이 다른지 알고 싶은 개발자들에게 조금이나마 도움이 되지 않을까 싶어, 정리가 덜 된 글이라 요약하고 싶지만, 아쉽게도 두서없게 6개월만에 마무리한다.

아마도 이 글에서 다룬 이야기는 더 잘 요약해서 다시금 쓰게 되지 않을까 싶은 예감이 든다.