게임 개발로 복귀 하는 이야기

길었다면 길었고, 짧았다면 짧았던 도전을 마치고, 본업이었던 게임 개발로 복귀한다.

2년여간의 경험은 꽤나 의미가 있었다.

내가 웹&플랫폼 개발을 해보고 싶었던 계기는, 이전 글에서 언급했던 대로, 기술적으로, 문화적으로 궁금한 것이 컸다.

여기에 더해서, 게임 개발을 오래하다보니 매너리즘에 빠진 문제도 있었다.

비슷 비슷한 업무에 지치기도 했고, 중견 회사나 소규모 회사를 주로 다녔다보니 매번 출시하거나, 출시했던 게임을 서비스 하던 내가, 짧은 기간에 여러 번의 프로젝트 드랍을 경험하기도 했다.

또 당시 NHN Entertainment(현 NHN)에 입사하게 되면서 플랫폼이나 웹 개발 비중이 높은 회사로 왔다보니, 보는거 듣는게 많아지면서 궁금해지기도 했다.

게다가 개인적인 호기심으로 ruby on rails, python django 등을 사용해봤던 내가, (반강요로 인한) 자바와 스프링을 사용하게 됐다.

언어나 경험적으로 너무 큰 장벽이 있어, 쉽사리 도전하기 어려웠던 상태에서 어느정도는 도전 가능한 범주로 경험적 차이를 좁혀가다보니, 지적 호기심이 더 커졌다. 이제와서 밝히자면, 내가 과연 게임 개발이 아닌 다른 분야에서도 잘 할 수 있는지, 프로그래머로만 구성된 조직, 팀에서 내가 어떤 부분에서 장단점을 내비칠 수 있는지, 또 플랫폼 개발자나 웹 개발자들 사이에서 어떤 자극, 어떠한 인사이트, 어떠한 성장 계기를 가질 수 있는지 너무 궁금했다.

어쩌면 잠깐의 도전이, 내 인생의 많은 부분을 차지하는 일이라는 측면을 송두리째 바꿀 수 있음에도 궁금했다.

C++ 게임 개발자로 시작했고, 자연스레 만들어 쓰는 것에 익숙하던 나는, 만들어서, 써보고, 적용하고 나서야 결과를 알 수 있는 방식으로는 기술적 성장이 생각만큼 속도가 붙지 못함에 아쉬움을 느꼈다.

또한 상태 기반의 서버의 스케일아웃에 대한 경험과, 판단은 할 수 있었지만, 내가 떠올린 방식 다수가 공수가 많이 든다거나, 많은 규칙을 가지고 코딩해야 하는 강제성, 그 규칙을 유지하기 위한 높은 유지보수 비용이 필요한 방식이었다.

물론 웹/플랫폼이 다른 방식으로 스케일 아웃하고, 트래픽을 처리한다는 것은 알 수 있었으나, 분명 게임 개발에서 웹 개발의 장점을 녹일 수 있다면, 생각을 좀 더 다양한 측면에서 고려하고, 다양한 방식으로 생각 할 수 있다면 좋지 않을까 하는 기대감을 가졌다.


이렇게 도전을 나선 나에게 2년여의 경험은 큰 도움이 됐다. 그들이 왜 저렇게 생각하는지, 왜 저렇게 말하는지, 왜 저런 것들이 중요하다고 말하는지 알아들을 수 있게 됐다.

또 웹 백엔드, 프론트엔드도 개발 할 수 있을 만큼의 학습도 했고, 그들이 일하는 방식에서의 장단점도 배웠다. 플랫폼 개발자는 그래도 조금이라도 더 게임 개발자와 가까운 측면이 있었다. 모듈을 직접 구현해야 되는 경우가 많았고, 대신 오픈소스를 잘 활용하는 데에 게임 개발자들 보다 능숙했다.

실제로 웹 개발자 성향과 플랫폼 개발자들 사이에서의 차이도 꽤 컸는데, 이는 나중에 다시 얘기해보도록 하겠다.

결론적으로 게임 개발자들은 직접 만드는 데에 익숙하고, 웹이나 플랫폼 개발자들은 가져다 쓰는 데에 익숙한데, 이 과정에서 인사이트에 대한 갭도 흥미로웠다.

게임 개발자들은 직접 만들어 쓰다보니 원리에 대해 파고드는 접근을 보이는 반면, 웹이나 플랫폼 개발자들은 가져다 쓴 모듈을 검증하고, 사용하는 방식에 대해 검증하려는 접근을 보였다.

애초에 검증을 하는 방식도 테스트를 통한 검증이 많았는데, 테스트 방식으로 검증할 수 없는 부분은 결국 커버리지에 아쉬움을 보일 수 밖에 없었다.

반면 직접 만들어 쓰는 게임 개발자들은 시간이 부족하거나, 원리 이해를 잘못했을 때의 리스크를 가졌고, 테스트에 대한 리스크도 똑같이 짊어지는, 즉 고강도 노동에 시달리는 슬픈 현실을 마주하기도 했다.

그런 과정을 나도 겪었다보니, 이런 부분에 대한 해결책이 궁금해 웹/플랫폼 개발은 어떻게 하는지 알고 싶었다.


아무래도 모바일로 넘어오면서 웹 서버로 컨텐츠를 개발하기 시작한 게임은 웹 호출을 이용해서 connectionless 특성을 가져갔을 뿐, 실질적인 개발과 운용에서의 접근은 웹의 장점을 많이 못 가져왔다.

여전히 결합도를 만드는 접근, 잘 가져다 조립하지 못하는 구현, 확장성 낮은 구조는 아쉬움이 많았다.

결과 저장소와, DB 대행정도로만 구현 가능한 라이트한 게임들이라면 모를까, 조금만이라도 인터랙티브한 요소가 들어가서 소켓 프로그래밍이 필요한 경우엔 또 과거로의 회귀가 이어졌다.

상태를 들고 있는 서버는 크래시에 치명적이다. 그렇다고 서버를 잘게 쪼개 놓으면, 구현도 어렵고, 예외 처리도 어렵다.

격리할 수 있는 요소를 많이 쪼개고, MQ를 적정 지점에 배치해서 서비스 간의 통신에서 사용해, 순서와 이벤트 유실을 막는 것이 필요하다.

규칙은 최소한 프로젝트 단위에선 일관되게 만들고, 단순화 시켜서 실수를 줄이고 관리 코스트를 낮춰야 한다.

협업이 필요한 파트별로, 자신들이 만든 결과물을 자체적으로 검증하는 툴을 만들거나, 가져다 쓸 수 있어야 한다. 그래야 파트간 소통에 들어가는 코스트를 최소화 할 수 있고, 유연하게 변화를 줄 수 있으며, 조립하는 과정 즉 연동하는 과정에서의 문제를 최소화할 수 있다.

검증과 테스트 도구를 파트별로 보유 했을 때의 또다른 장점은, 새로운 시도도하기 쉽다는 거다. 아무래도 협업하는 사람이 많아질 수록, 확정적인 것 들로만 진행해야 하는데, 이는 잦은 변화로 인한 코스트 낭비를 줄이기 위해서라도 필요하다. 하지만, 파트 자체적으로 시도해볼 수 있는 환경이 갖춰진다면 다양한 시도도 할 수 있고, 완성도도 높일 수 있다.


아마도 더 오랜 기간을 웹/플랫폼 개발을 했다면 생산성 높은 환경에서 얻을 수 있는 다양한 인사이트를 얻었을 거라고 생각한다.

특히 개인적으로는 리눅스 환경이 익숙해지고, 거부감이 사라지는 데에선 플랫폼 개발 했던 기간이 큰 영향이 있었다. 또한 부서가 부서였다보니, 클라우드 환경이나 인프라에 대한 이해도도 함께 높아졌다.

그리고 오픈 소스 도구에 대한 접근, 이해도도 아주 아주 큰 도움이 됐다고 생각한다. git flow와 같은 브랜치 관리라거나, 온라인 코드리뷰 문화도 좋았다.

그럼에도 나는 한명의 게이머이고, 게임이 좋아서 게임 개발자가 됐던 내가 게임 개발을 떠나서 행복할 수 없었다는 걸 알게 됐다.

그리고 웹/플랫폼 개발에서의 경험을 게임 개발에서 녹여내고자 한다.

가장 중요한 것은 내가 언제까지 개발자를 할 수 있을지 모르지만, 내가 재밌는 일, 하고 싶은 일을 해야 겠다라는 생각이 들었다.

짧은 시간이었지만, 발을 담그게 됐던 환경에서, 나에게 자극이 되어주고, 가르침을 주시고, 배울 수 있게, 성장할 수 있게, 경험할 수 있게 해주신 분들께 감사한다.

또 다시금 게임 개발 전선에 뛰어들 수 있게 도와준 분들께도 감사한다.

내년에는, 또 후년에는 하고자 했던 것들을 이뤄내서, 나의 게임 개발 복귀가 의미 있게, 가치 있었다고 말할 수 있게 된다면 좋겠다.

.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 (https://github.com/elky84/community_board) 였다. Vue.js를 팀 내부적으로 사용하고 있었고, 나도 이에 맞춰 복습 및 경험치 획득을 위해 만들게 됐다.

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

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

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

  1. 자바 스크립트 자체는 linter가 없인 너무 큰 자유도로 코드 가독성이 들쭉날쭉해지기 쉽상이라는 것.
    • 이를 해소하기 위한 방법으로 linter와 framework를 사용함으로써 팀 규칙대로 코드를 작성하게 (반)강제하고, 다양한 스타일의 난립을 억제하려 하는 것 같다.
  2. 자바 스크립트 자체는 아직도 불편하지만, lodash 같은 편의성 높은 패키지로 대체하고, module counts (http://www.modulecounts.com/) 의 최다 패키지 보유 플랫폼 답게, 수많은 기능을 가져다 사용해서 개발 공수를 낮출 수 있다는 것
    • 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 등의 특정 언어에 편중된 서적은 따로 작성하는 것이 맞겠다는 싶더라. 다음 필독서 모음은 그렇게 작성해보겠다.