산타캅의 샌드박스

회사에서는 언리얼4 엔진을 쓰는데, 집에서는 훈련을 유니티로 해볼까 한다. 양쪽 모두 게임 산업에서는 상당히 널리 쓰이고 있다. 유니티는 원래 Unity 3D 라는 상표명을 사용했던 것 같은데, 올해부터 Unity 2017 이라는 이름으로 바뀐 듯 하다. 아마도 2D, 3D 가 모두 지원 가능하다는 이미지를 주고 싶어서가 아닐까? 그 때문인지 프로젝트 생성 시 2D, 3D 를 선택할 수 있게 되어있다.

몇년 전만 해도 양쪽 엔진 모두 개인은 월 몇만원씩 주고 사용해야 했으나 최근 경쟁이 붙기 시작하면서 개인이나 인디 게임 제작하는 회사 수준에서는 모두 무료로 이용할 수 있도록 바뀌었다. 게다가 MS 도 이와 같은 흐름에 동참하면서 비주얼 스튜디오를 개인에게 무료로 개방하였다. 최소한 윈도우 환경에서 취미 생활로 게임을 만들고자 하는 사람에게는 더 없이 좋은 환경이 만들어진 것이다.

다만 언리얼과는 달리, 유니티는 별도의 라이선스(Pro) 없이는 엔진 소스 코드까지 접근할 수는 없는 듯 하다. 언리얼은 디버깅을 할 때 엔진 소스 코드가 보여서 엔진쪽 버그인지 그리고 엔진 코드가 무슨 일을 하는지 쉽게 파악이 가능했는데 - 물론 엔진쪽 버그면 수정이 어려워서 짜증이 나긴 한다 - 유니티는 그런게 어려울 듯 하다. 

언리얼4 엔진은 C++를 보통 사용하지만 유니티는 C#을 사용한다. 개인적으로는 C++을 선호하는 편이지만 C#도 상당히 좋아한다. C#은 무엇보다도 객체 수명 관리가 간편하며 C++와 같이 복잡하고 지저분한 코드가 덜 만들어진다. 언리얼 엔진에서도 대부분의 객체는 스마트 포인터와 같이 따로 해제를 해줄 필요가 없으며 가비지 콜렉션(GC)으로 수명을 관리해주므로 사실상 C++의 문법을 사용하고는 있지만 C#과 비슷한 느낌으로 사용이 가능하게 만들어두었다.

유니티 설치 시 인상깊었던 점은 유니티 설치 시 비주얼 스튜디오 2017 을 같이 설치해준다는 것이다. 언리얼은 별도로 설치했던 것으로 기억한다. 프로그래밍을 처음 하게 될 게임 제작자도 헤멜 거리가 하나 줄어들게 될 것이므로 긍정적으로 볼 수 있겠다.

아래는 두 엔진의 차이점을 표로 정리해본 것이다:

만약 틀린 정보가 있다면 즉시 업데이트하도록 하겠다.

엔진 이야기는 이 쯤 하고, 이제는 오늘 진행했던 내용이다.

Roll a Ball 이라는 튜토리얼 프로젝트를 하고 있는데 동영상으로 하나씩 따라할 수 있도록 되어 있다. 언리얼로 치자면 블루프린트로만 진행하는 튜토리얼과 같은 수준이지만 유니티에서는 C# 으로 직접 스크립트를 코딩해야 한다. 이 점에서는 언리얼의 진입 장벽이 조금 더 낮다고 볼 수 있겠지만, 블루프린트로 게임을 만드는 경우 (프로그래머 입장에서) 나중에 고생을 많이 하게 되므로 결국엔 별 차이가 없다고도 할 수 있겠다.

몇 가지 인상깊었던 차이점을 하나 보자면, 언리얼은 에디터에서 기본 제공되는 기본 도형 중에 유니티에서 Plane 이라고 불리는 객체가 없다. 이게 없어서 상당히 의아했던 기억이 난다. 언리얼은 부피가 존재하는 블록을 사용하여 평평한 땅을 만든다. 유니티의 Plane 은 부피가 존재하지 않는 평면이다. 대신 앞, 뒷면이 존재하며 반대쪽 방향에서는 이 평면이 컬링되어 보이지 않는다.

또 한가지 다른 점은 축, 좌표계이다. 언리얼은 X, Y축이 지면이고 Z축이 위쪽인데, 유니티에서는 X, Z축이 지면이고 Y축이 위쪽이다. 예를 들어, 위 아래로 길쭉한 캡슐의 크기를 설명할 때 언리얼에서는 1x1x2 라고 표현하지만 유니티에서는 1x2x1 이라고 표현한다. 개인적으로는 Z축을 위쪽으로 보는 것을 선호한다. X, Y축은 위에서 땅을 내려다 보았을때 2D 평면의 좌표가 되고 Z축이 높이(Height)값이 되기 때문이다. 당분간은 이것 때문에 헷갈릴 것 같다.

에디터에서 카메라 움직임을 조작하는 법도 다른데, 예를 들어 마우스 휠 버튼을 누른 채로 이동하는 경우 언리얼에서는 카메라의 좌표를 조작한다는 느낌을 준다. 즉 휠을 누르고 마우스를 위쪽으로 움직이면 카메라는 지면에서 멀어지는 쪽(+Z)으로 움직인다. 반대로 유니티는 손으로 화면을 움켜쥐고 이동시키는 느낌이다. 스마트폰에서 화면을 손으로 누르고 밀어서 스크롤하는 느낌과 같다. 휠을 누르고 마우스를 위쪽으로 움직이면 화면의 다른 물체들이 위로 이동하고, 따라서 카메라는 반대로 내려간다. 나는 언리얼 방식을 선호하는 편이다. 아무래도 FPS 게임을 좋아해서 그런지 카메라가 플레이어로 인식되는 느낌이 더 편하다.

유니티 에디터에서 C# 스크립트인 .cs 파일을 여는 경우 내 기대와는 달리 Visual Studio 2017 이 켜지는 대신 처음 보는 에디터가 모습을 드러냈다. 이름은 MonoDevelop-Unity 이다. VS 가 더 편한 나로써는 약간 심기가 불편했지만 이 에디터가 유니티와 더 결합되어 있을 것이라는 기대를 했다. 그러나 한글과 같은 조합형 언어 지원을 제대로 못하는지 주석에 한글을 쓰니 타이핑이 누락되는 처참한 결과를 내고 말았다. 유니티가 한국 지사도 있는 것으로 아는데 이 점은 빨리 개선되어야 할 듯 하다.

"Input" 이라는 스크립트 코드를 입력한 후 Ctrl+' 를 누르면 관련 도움말 사이트로 즉시 넘어가는 기능의 설명을 따라했지만 유니티 사이트에서 404 에러를 뱉어냈다. 아무래도 이 기능이나 레퍼런스 웹 페이지의 유지보수가 필요할 듯 하다. 조금 더 테스트해보니 레퍼런스가 보관된 웹페이지의 주소가 바뀐 듯 하다. 직접 유니티 사이트에서 API 검색을 통해 Input 에 대한 설명을 찾아낼 수 있었다.

이 주소로 직접 이동하여 검색하면 된다: https://docs.unity3d.com/ScriptReference/index.html

C# 스크립트가 C++ 코드보다 더 나은 점이 있다면 엄청난 시간이 걸리는 컴파일 작업을 하지 않아도 된다는 것이다. 언리얼에서는 한 줄의 코드만 바꾸더라도 컴파일을 다시 해야 했는데 프로젝트가 커지면 커질수록 C++ 의 특성상 몇분에서 수십분 정도는 기다려야 했지만 C# 은 컴파일 속도가 엄청나게 빠르므로 그냥 스크립트를 저장하고 에디터로 오면 짠! 하고 게임을 플레이할 수 있다.

요즘 자정 넘어 퇴근하는 일이 많아지고 있다. 담당한 프로젝트가 곧 출시를 앞두고 있는 것과 무관하지는 않을 것이다.

왜 자정 넘어 퇴근을 하는가? 정규 업무 시간이 끝나고 나면 또 무슨 일을 하길래 나는 회사에 이렇게 오래토록 있는가? 야근 없이는 이 프로젝트가 성공할 수는 없는가? 오늘은 이 주제에 대해 약간 다뤄볼까 한다. 하지만 아래에 나올 이야기는 하나의 주제를 가지고 이야기를 풀어 쓴 것이 아니라, 내 생각의 흐름에 맞춰 순서대로 기록되었기 때문에 일관적인 내용을 가지지는 않는다는 것을 알아두었으면 좋겠다.

나는 사람이 하루에 쓸 수 있는 집중의 시간은 정해져 있다고 생각한다. 마라톤 선수라고 해도 하루에 마라톤을 두 번 이상 할 수는 없는 법이다. 난 사실 마라톤을 어떻게 교육하는지는 모르겠지만, 아마도 마라토너 코치가 선수에게 하루에 100km 를 달리라고 한다면 - 참고로 마라톤은 약 42km 달린다 - 코치의 자질을 의심하고도 남을 것이다. 몸의 피로는 너무나도 자명하기 때문에 쉽게 이해할 수 있다. 정신 - 즉 '뇌' - 의 피로는 쉽게 '정신력'이라는 말로 간과당하고는 한다. 정신력은 상황에 따라 거의 무제한에 가까운 능력을 발휘할 수 있다고 믿는 사람들이 있지만 그 또한 뇌 세포의 활동, 즉 신체 활동의 연장에 불과하다. 따라서 적절한 휴식이 따라오지 않으면 정신력은 휴식 없는 마라톤 선수의 근육 상태와 같이 며칠 지나지 않아 더 이상 적절한 생각과 노동을 할 수 없게 될 것이다.

나는 프로그래머인 관계로 마라톤과는 일 하는 방식이 다르지만, 이렇게 일정 시간 동안 집중하여 생산할 수 있는 능력을 나는 '코딩력'이라고 표현한다. 하루에 내가 코딩할 수 있는 노동의 총 량을 의미하는 것이다. 오래달리기 선수라고 한다면 하루에 달릴 수 있는 총 거리와 비슷한 느낌일 것이다. 그리고 '코딩력'을 전부 소진하고 나서도 만약 일을 더 해야 한다면, '생명력'을 사용한다고 표현한다. 생명력을 소진하는 것은 말하자면 이자율이 비싼 대출과 비슷하다. 내일의 코딩력을 오늘 땡겨 쓴다고 생각할 수도 있고, 아니면 내 체력을 팔아서 코딩력을 산다고 생각할 수도 있다. 그렇지만 어제나 비싼 이자를 지불해야 하기 때문에 단기간의 능력은 향상되나 장기간의 능력은 감소한다.

요즘 더 알려진 용어로는, 이렇게 생명력을 소진하는 행위를 '크런치 모드'(crunch mode 또는 crunch time)라고 한다. 재미있게도, 구글에 crunch mode 를 검색하면 상위권에 다음 링크가 나온다:

https://cs.stanford.edu/people/eroberts/cs181/projects/crunchmode/index.html

<위는 구글 검색 내용을 캡처한 것이다>

일단 두 번째 링크의 주소를 살펴보면, 미국의 명문 대학교인 스탠포드 대학교(stanford.edu)라는 것을 알 수 있다. 그리고 내 경험으로 미루어 보아, 앞의 "cs" 는 보통 Computer Science 를 의미한다. 즉, 스탠포드 대학교 컴퓨터 학과라는 것이다. 이게 어느 정도 레벨인지 모르는 사람을 위해서 설명하자면, 만약 내가 여길 수석으로 졸업할 정도의 실력이라면 아마 10년마다 대출 없이 집을 한 채 살 수 있을 정도의 급여는 받고 살 수 있을 정도라고 말할 수 있겠다. 전 마이크로소프트 CEO, 페이팔 설립자, 구글, 야후, HP, Nvidia, 썬 마크로시스템즈, 스냅챗 창업자가 여기서 나왔으니 대충 어느 정도 수준인지 느낌이 올 것이다.

다시 본론으로 돌아와서, 크런치 모드의 검색 결과가 의미하는 것은 무엇일까? 세계 최강의 명문대 조차도 야근은 피할 수 없다, 또는 우리야 말로 야근에 대해 가장 권위있게 설명할 수 있는 곳이다 라는 의미가 아닐까 한다. 구글 검색 결과의 상위를 차지하고 있다는 것이야말로 권위를 나타내는 지표일 것이다.

미국의 대학교는 한국과는 달리 들어가는 것은 그렇게 어렵지 않지만 졸업하는 것이 정말로 어려운 것으로 알려져 있다. 비교하자면 한국의 고3 수능 시험을 준비하는 공부의 강도가 미국에서는 대학교 4년 내내 이어지는 것이다. 잘 떠올려보면, 미국의 영화 중 치어리더 나오고 운동남 나오고 파티를 하는 코믹 학원물은 우리 눈에는 마치 대학생들 이야기처럼 느껴지지만, 실제로 영화 내에서는 고등학교 시절 이야기다. 말하자면 우리와는 고3과 대학 생활이 반대라고도 할 수 있겠다. 조금 슬픈 이야기지만, 우리나라에서는 고3 학생들이 시험 공부를 하다가 자살을 하고는 하지만 미국에서는 대학생들이 자살을 한다. 나도 돌이켜 생각하보면 가장 끔찍했던 시절이 바로 고3이었다. 누군가는 젊은 시절로 돌아가고 싶다지만 나는 다시는 그 시절로 돌아가지 않으리라.

그렇다. 야근이야말로, 지구상에서 가장 위대한 IT 업계의 업적인 구글 창업자 또한 피할 수 없는 일이었을 것이리라.

나 또한 회사에서 이루었던 가장 큰 업적들은 야근 속에서 만들어진 것이 많다고 생각한다.

그렇다면 야근은 결국 프로그래머에게 필요불가결한 존재인 것인가? 그렇지는 않다고 생각한다.

위에서 이야기했던 '업적'을 이루었던 야근의 형태는 어느 정도의 패턴을 가지고 있다. 그 중 가장 중요한 것은 "강한 동기"이다. 뭔가를 이루고자 하는 마음이 일정의 마감과 겹쳐 시너지를 낸 것이다. 만약 내가 내 일에 대해서 책임감과 관심, 그리고 사적인 흥미를 느끼지 않았다면 그런 업적은 이루지 못했을 것이다. 반대로 말하면, 사적인 동기가 없는 야근은 아무런 의미가 없다. 내가 아닌 다른 사람이 아무리 급해봤자 내가 그것에 대해 공감하고 동의하지 않으면 아무 소용이 없는 것이다. 대중교통을 이용할 때 내 뒷 사람이 나를 아무리 밀어봤자 내가 여기서 내릴 역이 아니면 나는 꿈쩍하고 싶은 마음이 들지 않는 것이다.

그래서, 요즈음의 야근은 과연 나에게 사적인 동기가 있었고 자발적인 것이었는가? 나는 분명 책임감을 느끼고는 있지만 그게 사적인 동기로까지 이어지려면 그 보상 또한 나에게 연결되어 있을 것이라는 믿음을 가지고 있기 때문일 것이다. 그러니까 생명력을 불태우면서까지 납기일을 맞추는 행위가, 내년 내 급여와 인센티브에 직접적인 영향을 줄 것이라는 강한 믿음을 가지고 있기 때문이다. 그리고 또한 내가 담당한 업무가 제대로 돌아가는 것을 보고 싶은 것 또한 있다. 만약 이러한 업무와 보상과의 연결고리가 부정된다면 나는 야근을 할 필요가 없다. 야근을 하면 내 개인 시간이 없어지고, 안하면 평가는 나빠질 수도 있지만 솔직히 회사에서 잘려도 내가 갈 곳은 많으니까. 굳이 시간을 돈으로 바꾸는 업무에서 내 시급을 일부러 희석시킬 필요가 뭐 있겠는가? - 참고로 우리 회사는 포괄임금제라서 야근을 해도 돈을 더 주지 않는다.

어제 일기에서 내가 팀을 이동했다고 이야기했다. 

나는 게임 회사를 다니고 있으며, 이동 전 프로젝트는 내가 회사를 이 회사에 입사하면서 들어갔고 약 4년 동안 있었다. 이동 후 현 프로젝트에서 일한지는 이제 2년이 다 되어간다.

팀 이동을 하고 나니 보이는 것들

나는 구직을 할 때 그 회사가 어떤 회사인지가 중요한 것이 아니라, 내가 들어갈 팀이 어떤 팀인지가 훨씬 중요하다고 생각한다. 예를 들어, 이직을 한다면 회사를 보고 고르는 것이 아니라, 어떤 게임을 만들게 될 것인지, 그리고 같이 일하게 될 사람들은 어떤 사람들인지를 훨씬 중요하게 본다는 것이다. 그런 면에서, 팀 이동은 이직과 다를 바 없다고 생각한다. 비록 같은 건물, 같은 유관부서, 같은 편의시설, 같은 전산 시스템 등을 공유하지만 말이다.

그리고 실제로 프로젝트 이동을 하고 나니, 비록 같은 회사지만 팀 마다 다르다고 느끼게 된 것들이 몇 가지 있다. 

다른 사람들이 나를 대하는 태도

먼저 이전 팀에 입사할 때 나는 SI 회사와 안티 바이러스 회사 경력은 있었지만 게임 업계는 처음이었을 때였고 나이 또한 아주 어려서 팀에서 거의 막내급이었다. 그래서 그런지 많은 사람들에게 사회 초년생으로 인식되었던 것 같다. 직급은 입사할 때부터 아래에서 두번째 - 대리 정도 - 였지만 말이다. 덕분에 어느 정도 실수를 해도 이해해주고 귀여움받을 수 있는 장점도 있었지만, 의견을 냈을 때 진지하게 받아지는 일 또한 많지 않았다는 느낌이었다. 또 코드를 작성하는 방식에 대해 간섭을 많이 받았는데 이것이 상당한 스트레스였다. 거기서 설득을 하려면 어떤 권위가 필요했지만 나이는 남들이 보기엔 너무 어렸고 내가 가진 경력은 대부분의 사람에게 인식되지 못했다. 한 가지 예를 들자면, 코드에 클래스, 변수, 함수 이름을 지을 때 헝가리안 표기법을 사용했었는데, 나는 일찌감찌 이 방식을 SI 회사 다닐 때 쓰다가 단점을 깨닫고 버렸던 방식이다 - 이 내용에 대해선 별도로 포스팅을 하겠다.

현재 팀에서는 어떤 이유에선지는 몰라도 시니어 프로그래머 취급을 받는 느낌이다. 직장 상사만 해도 가끔 나를 부를 때가 있는데 심장이 쿵쾅거리면서 혹시 뭔가 실수한 것은 아닌가, 호통을 듣는 것이 아닌가 하고 긴장했었는데 대부분 어떤 구현을 하고 싶은데 어떤식으로 구현하는게 좋을 것인가에 대해 의견을 물어보는 것이어서 어리둥절한 적이 많다. 또 다른 팀원들도 프로젝트에서 잘 모르는 부분이 있으면 나에게 질문을 하는데 사실 나도 이 프로젝트에 온지 얼마 안되서 모르는 것이 많아 당황할 때가 많았다. 그래도 잘 모르겠다고 대답을 하기 보다는 내 힘이 닿는 한까지 최대한 답을 찾아서 알려주었다.

업무 분위기

이전 팀은 상당히 시끌벅적한 느낌이었다. 좋게 말하면 즐겁고 게임 회사같은 분위기였고 나쁘게 말하면 업무 집중도가 높지 않은 분위기였다.  나는 프로그래밍을 할 때는 조용하고 혼자 있는 느낌에서 좋은 퍼포먼스가 나왔기 때문에 중요하거나 빠른 시일 내에 처리해야 하는 일이 있으면 새벽 시간에 코딩하는 것을 선호했다. 그러다가 업무 시간에도 그런 집중도를 내보기 위해 노이즈 캔슬링 헤드폰을 구매했으며 어느 정도 효과는 보았지만 만족할만한 수준은 아니었다.

현재 팀은 비교적 조용한 분위기이다. 테스트를 위해 단체로 게임을 할 때가 있는데 이 때는 시끌벅적해지긴 하지만 눈치를 주거나 하지는 않는다. 처음에는 상대적으로 너무 조용한 분위기 때문에 말 소리도 크게 못냈지만 현재는 익숙해져서 별 이상한 느낌은 받지 않는다. 노이즈 캔슬링 헤드폰은 큰맘 먹고 더 좋은 것으로 구매했는데 역시 소음이 적을 수록 집중도가 높아지는 것을 느낀다.

업무 규칙

당연히 다른 팀인 만큼 규칙 또한 다르다. 예를 들면, 이전 팀에서는 늦은 시간까지 야근을 하는 경우에는 다음 날 늦게 출근을 할 수 있다는 것이 공식적으로 인정되었다. 

여기서는 딱히 그런 규칙은 없지만 반대로 늦게 온다고 해서 특별히 문제를 제기하지도 않는다. 전일 늦게까지 작업하다가 피곤하면 늦게 올 수 있고 그 대신 업무 시간에 집중해서 빨리 끝내는 느낌. 개인적으론 전 팀의 제도가 마음에 들었지만 여기도 크게 스트레스받지는 않는다. 이 때문에 회사에서 공용으로 사용하는 출퇴근 기록 대신 별도의 팀 전용 관리 페이지를 만들어볼까 하고 생각하고 있다.

사람

그렇다. 무엇보다도, 다른 팀에 가면 다른 사람들이 있다. 위에서 말한 태도, 분위기, 규칙이 다른 이유도 당연히 사람이 다르기 때문에 다른 것이다. 거기에는 나를 좋아하는 사람도 있고, 나를 싫어하는 사람도 있고, 나를 신경도 쓰지 않는 사람도 있고, 상황에 따라 나를 좋아하거나 싫어하는 사람도 있다.

팀 인원이 이동 전이나 후나 상당히 많은 관계로 모두의 성격을 다 나열할 수는 없을 것이고, 또한 여기에 적기에는 부적절하다고 생각한다. 하지만 사람이 바뀌면서 내가 회사를 다니면서 어떤 생각을 하게 되는지에 대해 주는 영향 또한 상당히 변했다는 것은 분명한 사실이다.

팀 이동을 생각하는 당신에게

여기서부턴 내 이야기가 아니라 조언.

회사에서 받는 스트레스의 대부분은 업무가 아니라 사람으로부터 나온다. 그래서 좋은 사람들과 일하는 것이 무엇보다 중요하다고 생각한다. 

만약 당신이 팀 이동을 생각한다면 반드시 같이 일할 사람들에 대한 고려를 해야 한다. 가장 좋은 것은 이동할 팀의 사람들에 대한 정보를 듣는 것이겠지만, 그 정보가 객관적이라는 법은 없다는 것 또한 잘 생각해야 한다. 누군가 자기와는 성향이 안 맞다는 이유로 당신에게는 그 사람을 안 좋게 이야기할 수 있지만 실제로 가봤더니 나에게는 친절하게 대할 수 있는 것이다. 반대로 좋다고 이야기했지만 나에게는 매우 안 좋은 경우 또한 있을 수 있다.

당신의 상사가 될 사람이 어떤 사람인지 파악하는 것 또한 중요하다. 만약 면접을 보러 갔다면 그 때 이야기를 나누면서 어느 정도 느낌을 받을 수 있을 것이다. 당신이 원하는 이상적인 팀의 요건에 대해 말해보고 어떻게 반응하는지 살펴보면 좋을 것이다.

혹시라도 팀 이동의 이유가 현재 당신과 일하고 있는 사람이 마음에 들지 않아서라면 특히 주의해야 한다. 그 사람도 나를 마음에 들고 있지 않을 가능성이 매우매우 높으며, 내가 이동할 팀의 상위권자에게 나에 대해 나쁜 이야기를 할 수도 있다. 만약 그런 경우엔 팀 이동 후 본인의 실력을 발휘한다면 금방 오해가 풀릴 것이지만 알아는 둘 것.

오랜만에 블로그에 글을 쓴다.

그 동안 많은 일들이 있었다. 팀도 이동하고 사용하는 개발 환경도 바뀌고. 어느 순간 돌아보니 주변에서 나를 시니어 프로그래머로 생각하는 것도 같고. 그에 걸맞는 능력도 요구하고. 또 나이도 그 만큼 먹었고. 이 이야기를 하자면 글이 몇 편은 필요해서 나중에 다시 해야할 듯 하다.

지금은 왜 블로그를 방치하다가 이제 와서 글을 쓰는가? 그 동기는 무엇인가? 에 대한 이야기를 하고 싶다.

그 시작은 지인의 블로그 포스팅 - 정확히는 그 분의 페이스북에서 본 것 - 에서 시작되었다. 셀프 인테리어를 했다는 내용이었는데 정말 놀라웠다. 우중충한 집이 인테리어 변경으로 이렇게 예쁘게 변할 수 있다니! 게다가 이걸 스스로 공사를 하다니! 돈을 아낄 수는 있었겠지만 힘도 많이 들고 시간도 많이 들고 장비도 사야되고 하다가 망하면 어떻게 하나 이런 걱정도 많이 했을 것이지만 그 결과물은 전문 시공사가 와서 해줬다고 해도 믿을 정도였다. 물론 사진에 담긴 아름다움 뒤에는 아마 말로 다 구구절절히 늘어놓기 힘들 정도의 고생이 있었을 것이다.

그러다가 생각이 닿아, 예전에 사놓고 잠깐 하다가 봉인해둔 심즈4를 켰다. 심즈에서는 인테리어가 - 현실에 비해 - 아주 쉬울 뿐만 아니라, 시간도 단 1초도 걸리지 않고 즉시 바뀌며, 비용도 아주 싸다. 벽 한 칸 놓거나 뜯는 비용이 피자보다 싼 정도

오랜만에 하는 만큼 이전 세이브 파일은 대체 어디까지 했는지 기억이 나지 않았기 때문에 바로 날려버리고, 나를 닮은 캐릭터, 아바타를 만들었다. 당연히 성격은 괴짜(nerd)에 직업은 아직 정하진 않았지만 아마 프로그래머로 할까 했다. 돈이 없으니 1층짜리 작은 단독 주택을 샀다. 작은 거실에 주방이 연결되어있고 2인용 침대가 겨우 들어가는 방 하나에 조그만 화장실 하나밖에 없는 집이다 (생각해보니 이놈은 작긴 해도 자기 집 가지고 있다). 

처음 시작하면 아무 직업도 없기 때문에 핸드폰으로 기술 전문가(프로그래머) 커리어 직장을 구했다. 아직 PC도 집안에 없었기 때문에 핸드폰을 사용했다. 심즈도 예전에는 집의 유선 전화를 썼는데 이제는 모바일 폰을 쓰니 격세지감이 느껴진다. 그리고 직장을 구하면 이력서고 면접이고 다 생략하고 바로 취직이 되고 다음 날 바로 출근이 결정된다. 글을 쓰면서 생각하니 이거 진짜 대단한 세상이 아닐 수 없다.

그리고 나서 항상 심즈 할 때와 같이 똑같은 짓을 하기 시작했다. 바로 승진을 위해서 자기계발을 시작한 것이다. 처음 취직을 하면 급여가 낮기 때문에 빨리 승진을 해야 급여가 올라간다. 그러려면 각 직종에 맞는 스킬을 익혀야 한다. 프로그래머라면 컴퓨터로 프로그래밍 연습을 하면 된다.

현실에서와 마찬가지로 평일에는 출퇴근을 해야 되므로 사실 개인 시간을 쓰기가 힘들다. 아침에는 일어나서 샤워하고 아침 먹고 바로 출근, 저녁에 퇴근 후에는 저녁 먹고 심의 떨어진 욕구 - 보통 재미와 사교 - 를 위해 게임을 하거나 친구들과 수다를 떨거나 채팅을 해야 한다. 그럼에도 불구하고 승진에 대한 욕심 때문에 그런 원초적인 욕구는 무시하고 바로 컴퓨터 앞에 심을 앉혀서 프로그래밍 연습을 시키거나 심지어 게임 스킬을 올리기 위해 강제로 게임을 시킬 때가 있다(?!). 주말에도 돈을 벌기 위해서 게임 대회에 내보내거나 플러그인 개발, 프리랜서 활동을 시켰다.

그러다 보니 뭔가 이상한 기분이 들기 시작했다. 현실의 나는 지금 재미 욕구를 채우기 위해 심즈라는 게임을 하고 있으면서, 게임 내의 아바타에게는 욕구를 무시하거나 기본적인 욕구만 채워주고 자기계발을 시키고 있는 것이었다. 여기서 뭔가 깨달음이 생겼다. 현실의 나도 자기계발을 해야되는게 아닐까? 이게 지금 이 글을 쓰고 있는 동기이다.

사실 자기계발을 해야겠다는 생각은 거의 맨날 하지만 집에만 오면 프로그래밍 관련 툴은 전혀 켜질 않고 게임만 하니 이뤄질 턱이 없다. 물론 게임 스킬은 나날이 늘어났으니까 아주 계발이 안됐다고는 못하겠지만!

오늘부터는 매일 아주 조금이라도 어제보다 더 나은 오늘의 나를 만들기 위해 이런 식으로 일기 또는 일지를 써볼까 한다. 이 글 쓰는데만도 벌써 2시간 걸렸으므로 오늘은 여기까지!

책 세 권을 샀다.

패턴을 활용한 리팩터링, 클린 코드, More Effective C++이다. 

일단 C++을 다루는 프로그래머라면 Effective C++ 3판, More Effective C++, 마틴 파울러의 리팩토링 책은 거의 필수로 가지고 있어야 한다고 생각했기 때문에 이걸 사려고 했는데 Effective C++이랑 리팩토링은 현재 품절 상태였다.

품절이 되니까 조금 겁이 나는게, 이러다 절판되서 영영 구할 수 없으면 어쩌나 하는 생각이 들었다. 제발 나와줘 ㅠㅠ

게임 프로그래밍을 하면서 많이 듣는 말이 있는데, 라이브 게임은 소스 코드가 더러울 수 밖에 없다는 말이다. 하지만 난 그 말에 동의하지 않는다. 더러울 수 밖에 없다는 말에는 자포자기와 자기 합리화가 엿보이기 때문이다.

라이브 게임의 코드는 24시간 언제나 변한다. 마감도 항상 빠듯하고, 버그가 발생하면 타격도 크다. 따라서 코드를 수정하는 데 보수적이 되는 경향이 있는 것 같다.

처음엔 클래스가 작았는데, 사소한 기능을 추가하거나 변경하다 보니 새로운 클래스를 만들지 않고 조건문 등을 추가해서 기존의 클래스 내에 기능을 추가하는 경우가 많다. 메소드 하나 짜리 일을 클래스로 빼려면 심리적으로 부담이 되기 마련이다.

하지만 이게 누적이 되다 보니, 클래스가 신적인 존재 - Super Class 또는 God Class - 가 되는 경우가 많다. 물론 코드는 잘 동작한다. 단지 이해하기 힘들고 변경하기 힘들게 될 뿐.

나는 코드가 더러우면 결국엔 프로젝트가 망한다는 믿음을 가지고 있다. 지금 작업 중인 코드를 계속 리팩터링해나가고 있다. 수 년간 쌓여온 코드는 단지 한 가지 기능을 추가하거나 수정할 때 수십개의 파일 또는 클래스를 수정해야 할 정도이다. 

가혹한 환경과 조건에서 프로그래밍을 했던 선임들의 마음은 충분히 이해하지만, 그렇다고 해서 지금 그들의 코드를 그대로 놔두는 것 또한 같은 프로그래머로서의 도리가 아닌 것 같다.

클린 코드(Clean Code) 책 뒤편을 보면 이런 말이 있다.

나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못하면 개발 조직이 기어간다.

참고: 2011/07/10 - [일기] - 기계식 키보드 첫 사용기 - 스카이디지탈 nKeyboard 메카닉 브라운

약 1년간 스카이디지탈 nKeyboard 메카닉 브라운(갈축)을 사용하다가, 이번에 레오폴드 FC300R 갈축을 또 마련하게 되었다.

링크: http://www.leopold.co.kr/?doc=cart/item.php&it_id=1301970288

9만 9천원에 구입했다. 사는 김에 키캡 리무버도 샀다 ^^ 지금 스카이디지탈 키보드가 너무 드러워서....

스카이디지탈 엔키보드 메카닉 브라운은 얼마 전에 회사에서 사용하기 위해 이동을 했는데, 집에서 멤브레인을 쓰기 시작하니 너무 허전하여 또다시 갈축으로 마련하게 되었다. 기왕 사는 김에 이번엔 유명한 모델을 사보자는 생각에 레오폴드의 FC300R을 구입하였다.

일단 느낌만 비교해 보자면, 스카이디지탈에 비해 좀더 쫀득거리는 - 기계식 키보드를 아시는 분들을 위해 설명하자면 더 흑축스러운 - 느낌이다. 그러니까 사각거림은 더 적고, 반발력이 좀 더 강하다. 그리고 키캡 높이가 더 낮은 느낌이다. 상대적으로 좀 더 구름타법스럽게 사용할 수 있다고 할까...? 내가 멤브레인을 오래 썼고 손가락 힘이 강해서 키를 누를 때 바닥 끝까지 팍팍 치는 스타일인데, 스카이디지탈은 바닥을 딱 딱 하고 치는 반면 레오폴드는 같은 압력을 주었을 때 바닥을 치는 딱 소리가 상대적으로 작았다. 좀 더 소음 면에서 준수하다고 생각된다. 또 F, J 키에 위치한 돌기가 좀 더 강한 느낌이다 - 사실 스카이디지탈쪽이 너무 돌기가 작았던 것 같다.

다른 차이로는 키 구성인데, 스카이디지탈 엔키보드 메카닉 브라운은 106키이고 레오폴드 FC300R 갈축은 104키이다. 그러니까 한/영키랑 한자키가 없다. 대신 오른쪽에 위치한 Alt 키가 한/영키, 그리고 오른쪽 Ctrl키가 한자키 기능을 하게 된다. 약간 어색했던 점은 한/영키를 누를 때 기존에 비해 위치가 좀 더 오른쪽이라서 스페이스랑 자꾸 헷갈렸다는 점이다. 아직 한자키는 쓸 일이 없어서 모르겠고...

또 다른 차이는 엔터키와 백슬래시(/의 반대 방향 기호, 또는 대한민국의 원화 기호인 \), 그리고 백스페이스 키가 다르다는 것이다. 엔터키는 좌우를 뒤집은 ㄴ자 대신에 작은 일자(ㅡ) 모양이고, 원래 엔터키의 상단 부분에는 백슬래시키가 위치한다. 그래서 엔터를 때리는 대신 백슬래시를 입력하는 불상사가 생기기도 한다... 

결론!

기계식 키보드에 첫 입문이고 한국식 106키 멤브레인 키보드가 매우 익숙하다면 스카이디지탈 nKeyboard 메카닉을 추천한다. 기계식 키보드 중 가장 저렴한 축에 속하고 익숙한 106키 방식이다.

엔터키 일자형이고 한영키 한자키 없는 104키 방식도 상관없으며, 멤브레인에 비해 키캡이 높은 기계식이 싫다면 레오폴드 FC300R도 괜찮은 선택이다.

키보드는 음식과 같아서 개인마다 취향 차이가 극명하다. 나는 회사에서 프로그래밍을 하는데 멤브레인 쓰면 손가락이 아프다 ㅠㅠ 스카이디지탈 엔키보드 메카닉 브라운은 키압이 상당히 낮은 편이라 이런 경우 유용할 듯. 

회사에 필코 마제스터치2 옐로우 청축을 쓰는 사람이 있어서 써봤는데 청축을 찰칵거리는 경쾌함이 느껴지긴 했지만 약 20여년간 멤브레인으로 코딩과 게임을 즐겼던 나에게는 상당히 익숙하지 않았다.

흑축은 전 회사에서 쓰는 사람이 많아서 써봤는데 멤브레인보다 키압이 강해서 별로 맞지 않았다.

리얼포스도 시타해봤는데 도각도각 느낌나는 멤브레인 느낌... 가격에 비해 많은 메리트가 느껴지지는 않았다.