Survival Shooter 튜토리얼을 끝냈다.

https://unity3d.com/kr/learn/tutorials/s/survival-shooter-tutorial

이전 Space Shooter 튜토리얼 완료 이후 거의 반년만이다.


이번 튜토리얼의 특징

비디오가 강의 전용으로 준비된 것이 아니라 워크샵을 녹화한 것을 보여준 것이라는 점이다. 그리고 비전문가를 대상으로 한 것인지 이런 저런 부연 설명이 많다. 따라서 이전 튜토리얼들과는 달리 시간적으로 분량이 매우 길다. 하나씩 따라하면 큰 문제는 없다. 다만 너무 분량이 많다보니 시작하기도 전에 스트레스를 받는 점은 있었다. 또 자막은 한국어는 없으며 영어만 존재한다. 개발 용어 특성상 불필요하거나 문학적이거나 못 알아듣는 말은 별로 하지 않으니 큰 문제는 없다.


워크샵은 유니티 직원 3명이 진행하는 방식이다. 중간중간 개그를 치는 것도 있는데 생각보다 반응이 썰렁해서 보는 내가 좀 민망한 느낌. 유튜브 영상 댓글에는 직원 숨소리가 매우 거슬린다는 글이 보인다. 나는 그렇게 거슬리진 않았다. 어떤 사람은 우리를 위해 힘써주는 직원에게 숨소리 타령이나 하고 있냐며 호통치는 댓글도 달았다.


이전 튜토리얼들과 마찬가지로 지금의 유니티와 버전이 좀 차이가 나므로 몇몇 기능은 이름이나 레이아웃 등이 좀 바뀌었다. 이것도 pdf 로 어떤 점이 차이점인지 제공되기도 하고, 잘 모르겠으면 유튜브 댓글만 봐도 해결책을 써둔 것이 있어 유용하다.


해결하지 못한 것

라이팅 관련해서 해결을 못한 게 있는데, 게임 오버가 된 후 게임이 다시 시작되었을 때 매우 어두워지는 문제가 있었다. LoadLevel 을 다시 했을 때 발생하는 듯. 디버깅은 귀찮아서 패스했다.


다음 할 일

이제 'Tanks' 튜토리얼을 할 차례이다. 반년 사이 유니티 튜토리얼에 '2D Game Kit' 라는 것이 추가되었다. 할 일이 어째 더 늘어난 느낌이다.

반응형

다양한 출퇴근 시간

나는 게임 회사에 근무한다. 여기서 출근 시간은 팀 마다 다르다. 이르면 오전 8시에 출근, 오후 5시에 퇴근하는 팀도 있고, 오전 10시에 출근, 오후 7시에 퇴근하는 팀도 있다. 자유롭게 오전 8~10시 안에 출근해서 +9시간 뒤에 퇴근하는 팀도 있다. 나는 현재 약 6년 째 10시 출근, 오후 7시 퇴근중이다.


예전의 나 - 늦게 자고 늦게 일어나자

원래 나는 10시 출근 19시 퇴근을 선호했다. 그 이유는:

* 어차피 야근하니까 출근이라도 늦춰야 해서(?) - 이건 시스템적인 문제

* 늦게 일어날 수 있으니까

* 늦게 잘 수 있으니까 (사실 조삼모사)

* 10시 출근, 7시 퇴근 시간대에는 대중교통이 덜 혼잡하므로


요즘의 나 - 일찍 퇴근하는게 더 낫지 않나?

현재는 8시 출근 17시 퇴근이 더 낫지 않나 하는 생각을 한다. 그 이유는:

* 하루가 길어지는 느낌

* 퇴근 후 친구들 만날 때 정할 수 있는 시간의 범위가 넓어짐 - 오후 7시 퇴근이면 어디서 만나든 보통 8시 이후에나 갈 수 있고 막차 시간때문에 오래 볼 수 없다.

* 가족과 보낼 수 있는 시간이 더 많아짐 - 조삼모사 같기는 한데, 보통 아침에 가족과 시간을 보내기보다는 저녁에 몰아서 보내는 편이 많으니까. 늦게 퇴근하면 집에 가면 오후 8시, 저녁 먹고 나면 9~10시 인데 이게 너무 늦는게 아닌가 싶다. 아침에는 다들 출근하고 나 혼자 집에 남아있게 된다. 어쩔때는 집에 늦게 가면 가족들이 전부 자고 있을 때도 많다.

* 퇴근하면서 해를 볼 수 있다.


반응형

문제 상황

지난 주 RIVAL 500 마우스를 컴스빌에 보내서 - 휠에 문제가 좀 있었다 - 오늘 택배로 새 제품을 받은 후 새로 받은 마우스를 꽂았더니 SteelSeries Engine 3 에서 펌웨어 업데이트를 하라고 한다. 펌웨어 업데이트를 눌렀더니 0% 에서 바로 펌웨어 업데이트 실패했다는 팝업이 뜨면서 (거의 펌웨어 업데이트 버튼을 누르자 마자 1~2초도 안되어서 실패한다) 마우스에서 파란 불빛이 점멸하는 문제가 생겼다. 사실 문제 때문에 초반에 한번 교환받은 적 있었는데 - 교환받은 제품은 펌웨어 업데이트가 한번에 잘 되었다. 그게 이번에 컴스빌에 보낸 제품 - 또 이런 일이 일어나서 상당히 불쾌했다.


해결 시도

해결 시도 1차 (실패)

USB 재연결 후 펌웨어 설치 재시도, 다른 USB 포트 사용 >> 실패


해결 시도 2차 (실패)

리부트, 안티바이러스 프로그램 비활성화 (아마 회사 컴퓨터라서 백신을 끄더라도 실제로는 꺼지지 않는 것으로 알고 있다), 스틸시리즈 엔진 3 재설치 >> 실패


해결 시도 3차 (대실패)

스틸시리즈 엔진 3 제거, 마우스 드라이버 제거, 마우스 연결 해제, 전원 종료, 마우스 연결, 전원 켜기, 스틸시리즈 엔진 3 재설치 >> 뭔가 펌웨어 업데이트가 아주 약간 진행되더니 역시나 실패. 심지어 약간 진행되버린 터라 아예 이제부터는 마우스에 DPI 조정이나 특수 기능 할당같은것도 못하게 되어버렸다. 이때부터는 에러 메시지가 "최근 펌웨어 업데이트가 실패했습니다" 정도로 바뀌고 펌웨어 설치를 하지 않으면 마우스 설정을 바꿀 수 없음. 여기서 다시 AS를 보낼까 말까 고민함





해결 시도 4차 (성공)

* 아래 두 파일에 대해서:

C:\Program Files\SteelSeries\SteelSeries Engine 3\SteelSeriesEngine3.exe

C:\Program Files\SteelSeries\SteelSeries Engine 3\SteelSeriesEngine3Client.exe

각각 마우스 오른쪽 클릭-속성-호환성 탭-"관리자 권한에서 이 프로그램 실행" 체크 후 확인 버튼 클릭

(위 스크린샷은 윈도우10에서 캡처한 것이지만 윈도우7도 거의 동일하다)


* 여기서 관리자 권한으로 프로세스를 실행했다가 작업 관리자에서 종료했다가 별 짓을 다 했지만 안됨


* 스틸시리즈 엔진 3 언인스톨


* http://downloads.steelseriescdn.com/drivers/engine/SteelSeriesEngine_3.1.4.exe 설치 (구 버전 엔진)


* 언인스톨 (appwiz.cpl 또는 프로그램 추가/삭제에 안 뜨기 때문에 직접 언인스톨러를 찾아서 실행함)


* C:\Program Files\SteelSeries\SteelSeries Engine 3 폴더를 통째로 삭제 (왠지 이게 중요했던 것 같다)

 이 때 삭제 시 관리자 권한을 왠지 모르게 요구함


* 최신 스틸시리즈 엔진 3 설치


* 펌웨어 업데이트 시도 - 잘 됨


참고한 것들

* 스틸시리즈 공식 FAQ: https://support.steelseries.com/hc/en-us/articles/115000030751-The-firmware-update-fails-or-freezes-and-I-am-unable-to-complete-it-

(그러나 비추가 많은 것을 보면 효과를 못 본 사람이 많은 듯 하다.)

* https://linustechtips.com/main/topic/172028-how-to-fix-steelseries-firmware/

* https://www.reddit.com/r/steelseries/comments/3rbw3n/rival_firmware_fix/


정리

솔직히 말해서 너무 해본게 많아서 어떤게 결정적이었는지는 모르겠다. 하지만 두 .exe 파일에 관리자 권한을 할당하고 언인스톨 후 폴더를 완전 삭제했던 게 효과가 있었던 것 같은 그런 느낌이 든다. 어쩌면 그냥 우연일지도 모른다. 검색해보면 마우스 펌웨어 업데이트에 대한 불만이 상당히 많은 것 같은데 소프트웨어 지원이 좀 미흡해보이는 느낌이다. 차라리 제품을 팔 때 펌웨어 업데이트를 미리 해서 보내주면 안될까?


USB 포트 바꿔서 끼운 것은 효과가 없었던 것 같은 느낌. 맨 처음 업데이트 실패했던 USB 포트에서 결국 최종적으로는 성공했다. 해당 포트는 USB 연장기를 쓰고 있었는데 그것 때문에 전압이나 저항, 전류에 영향이 있어서인가 했지만 결국엔 잘 되었고 본체 앞 USB 2.0, USB 3.0 포트에 직접 연결해도 안되었기 때문에 포트나 연장기 때문은 아니었을것 같다.


SteelSeries 는 요즘 내가 Razer 마우스의 내구성에 실망한 이후 가장 주목하고 있는 브랜드이다. 가격도 큰 차이가 나지 않으면서 마우스의 그립감, 클릭감, 내구성 모두 쓸만하다. 나중에 RIVAL 300 및 RIVAL 500 리뷰를 한 번 올려야겠다.


반응형

Space Shooter 튜토리얼을 끝냈다. 

틈틈이 작업하다보니 거의 한 달이 걸렸다. 


기록의 중요성

한 달이 걸렸다는 사실도 저번 일지를 쓴 것 때문에 정확히 알 수 있었다. 이래서 기록은 중요하다. 과거를 되돌아볼 수 있게 해주기 때문이기도 하지만, 머릿속에 두루뭉술하게 존재했던 것이 실체를 가지고 명확하게 바라볼 수 있는 형태로 바뀌기 때문이다. 내가 알고 있다고 느끼지만 실제로는 모르는 것이, 완전하게 알 수 있도록 바뀐다. 거기다가 '내가 몰랐다'라는 사실을 깨닫게 해주는 것은 덤이다.


게임 확장은 건너뜀

정확히는 기본적인 튜토리얼만 끝냈고, "Extending Space Shooter" 항목은 건너뛰었다. 여긴 두 가지 항목이 추가로 있다. 첫번째는 게임을 확장하여 더 많은 적과 다양한 패턴, 무기 업그레이드 등을 다루는 것이다. 실질적인 게임 컨텐츠를 만들어서 게임으로서의 핵심적인 기능 - 재미 - 에 더 충실하도록 하는 것이다. 두번째는 모바일로 게임을 만드는 방법에 대해 다룬다. 둘 다 좋은 내용일 것이 분명하나 각 항목 당 동영상 시간이 2시간 정도 되므로 일단 다른 튜토리얼도 해보기 위해서 그냥 동영상만 훑어보고 넘기기로 했다. 이 동영상들은 앞의 기본적인 내용을 다루는 동영상들과는 다른 사람이 진행한다. 목소리가 상당히 쾌활하다.


다음에 할 일은?

Survival Shooter 를 진행할 예정이다. 빨리 2D Roguelike 튜토리얼을 해보고 싶지만 표시된 순서대로 진행하고 싶다. 순서는 다음과 같다:

1. Roll-a-ball (간단한 공 굴리기)

2. Space Shooter (2D 탑다운 비행슈팅)

3. Survival Shooter (3D 쿼터뷰isometric 슈터)

4. Tanks (1키보드로 2인 플레이 가능한 탱크 슈터)

5. 2D Roguelike (2D 로그라이크)


반성

별것도 아닌데 한 달이나 걸린 것이 큰 문제로 와닿는다. 이 속도면 로그라이크 튜토리얼을 끝냈을 때 내년 봄이 되어버릴 것 같다. 다만 요즘 회사에서 밴드를 하느라 연습을 해야 하기 때문에 시간이 더 줄어든 것이 문제이자 핑계이긴 하다.

반응형

Roll a Ball 튜토리얼 완료


튜토리얼 주소: https://unity3d.com/kr/learn/tutorials/projects/roll-ball-tutorial



사실 Roll a Ball 튜토리얼 완료한 지는 꽤 되었는데 글을 이제야 쓴다.


인상깊게도 모든 튜토리얼이 유튜브 동영상으로 되어 있다. 영어로 이야기하지만 어떤 고마우신 분이 한국어 자막을 붙여두었으므로 보는 데 큰 지장은 없다. 단, 일부 동영상은 번역이 되어 있지 않다. 그래도 프로그래머라면 다 알아들을 수 있는 영어만 사용하고 동영상을 따라만 하면 되니까 영어를 못하는 사람도 큰 문제는 없을 것이다.


이야기하시는 분이 성우인건지 아니면 프로그래머인건지는 모르겠지만 굉장히 목소리가 깔끔해서 혹시 보이스웨어가 아닌가 하는 느낌이 든다. 특히 See the documentation below 같은 부분은 복붙한것 같은 느낌마저 준다.




Space Shooter 튜토리얼 시작


튜토리얼 주소: https://unity3d.com/kr/learn/tutorials/projects/space-shooter-tutorial


시작한 지 약 2주 정도 되었다.


1945 시리즈와 비슷한 종방향 탑다운 비행 슈팅 게임. 예전에 비슷한 2D 게임을 만들어 본 적 있어서 더욱 흥미로운 튜토리얼이다. 게임 자체는 만들기 크기 어렵지 않을 것 같은데 다만 3D 엔진으로 만드는 것이라 어떤 구현 방식 등에서 차이가 나는지 궁금했다. 예를 들면 주인공, 적, 총알이 동일한 Y축(언리얼에서는 Z축) 좌표에 놓여있는지 등이다. 높이가 다르면 카메라 상에서는 피격될 것 같지만 3D 엔진에서는 충돌이 안 되기 때문이다.


위의 Roll a Ball 튜토리얼과 같은 사람이 동영상 목소리로 나오는데, 조금 목소리 느낌이 다르다. 이 튜토리얼이 Roll a Ball 보다 훨씬 전에 만들어진 것 같다. 또 유니티 3D 엔진 4.x 버전 기준으로 만들어진 것이라 현재 유니티 2017 엔진 버전인 5.x 버전에서는 약간 다른 점이 있지만 유튜브 주석으로 설명이 되어 있기도 하고 영어가 된다면 문서를 봐도 되고 대충 짱구를 굴려서 뭐가 없다면 비슷한 메뉴를 사용하든지 주변의 버튼을 눌러봐서 비슷한 창이 뜨는지를 확인해봐도 된다.


동영상을 보다 보면 딱 한번 아주 살짝 웃는 경우가 있는데 이걸 들으면서 보이스웨어가 아니라고 확신하게 되었다.

반응형

'일기' 카테고리의 다른 글

출근 시간에 대한 생각  (0) 2018.01.21
유니티 Space Shooter 튜토리얼 완료  (0) 2017.11.20
Unity 2017 공부 시작  (2) 2017.10.03
게임 회사는 야근의 연속  (0) 2017.09.22
팀 이동에 관한 이야기  (0) 2017.09.20

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



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


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


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


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


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

 

Unreal Engine 4

Unity 2017 - Personal 버전

가격

무료

무료

과금 조건 (로열티)

분기 매출 당 $3,000 초과분의 5%

연매출 10만 달러 이상인 경우 Plus 또는 Pro 버전으로 바꿔야 함

엔진 소스 코드 제공

X  (Pro 이상 버전)

주 프로그래밍 언어

C++ 

C# 

프로그래밍 IDE (Windows 기준)

Visual Studio 2017 (또는 2015)

Visual Studio 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# 은 컴파일 속도가 엄청나게 빠르므로 그냥 스크립트를 저장하고 에디터로 오면 짠! 하고 게임을 플레이할 수 있다.

반응형

때는 2007년 봄. 나는 대학교 외에서의 첫 실무 프로젝트를 시작하게 되었다. 20명 남짓 규모의 작은 SI 회사에 취직하게 되었고, 나에게 주어진 임무는 이 회사에서 기존에 만들었던 것과 비슷한, 하지만 다른 고객 회사를 위한 어플리케이션을 작성하는 것이었다.

작은 회사가 원래 다 그런건지 아니면 SI 회사가 다 그런건지는 모르겠지만, 목표만 던져줬을 뿐, 코딩 스타일 가이드나 기본적인 설계와 철학, 이 회사에서 사용하는 라이브러리나 기본적인 프로젝트 시작 방법에 관하여 별 다른 업무 지도를 받지 못하였다. 뭘 어떻게 만들라는건지 갈피를 못 잡다가 마감일이 점점 다가오기 시작하자 나는 조급해졌다. 아무래도 이대로는 힘들다 싶어 선배님의 코드를 열어 살피기 시작했다.

참고로 당시 비주얼 C++ 6.0 을 사용하고 있었다. 비주얼 스튜디오 프로젝트 파일을 더블클릭하는 순간, 나는 어디선가에서 나는 강한 악취를 느꼈다. 그 악취는 바로 눈앞의 소스 코드에서 풍겨져 나오고 있었던 것이다.

당시 내가 보았던 코드는 내 기억에 따르면 아래와 비슷했다:

---------------
char g_szMstNum[3];
...
memset(g_szMstNum, 0, 3);
memcpy(g_szMstNum, "Bar", 3);
---------------

위 코드를 보고 혹시 문제점을 몇 가지 찾아낸 사람 있는가? 아니면 이해가 잘 되고 어디가 문제라는건지 모르겠는가?

내가 생각하는 이 코드의 문제점은 다음과 같다.

1. sz라고 써있지만 null로 끝나는 문자열이 아니다.

일반적으로 C/C++ 에서는 스트링의 마지막을 표시하기 위해 0 또는 null 을 사용한다. 그런데 여기서는 3바이트 캐릭터 배열에 3글자를 집어넣었기 때문에 sprintf(file, "%s", g_szMstNum); 따위의 코드를 넣었다가는 수백 수천 바이트가 파일에 기록될 수도 있고 잘못된 메모리 주소에 접근하여 크래시가 날 수도 있다. 그러나 변수 이름에서 이 사실을 알아낼 수 없으며 오직 정의 부분과 "Bar"를 대입하는 코드를 둘 다 찾아보고 메모리 크기와 스트링 크기가 정확히 일치한다는 것을 눈치채야만 알 수 있다. 요약하자면 완전히 잘못된 정보를 주고 있다.


2. 변수 이름만 봐서는 이 변수가 무엇을 의미하는지, 어디서 사용되는지 쉽게 알 수 없다.

g_szMstNum 변수에서 헝가리안 표기법에 해당하는 g_sz 를 떼어내고 나면 "MstNum"이 남는다. 이게 무슨 의미인지 알 수가 없다. Master 인지 Most 인지 Minimum Spanning Tree 인지 보는 사람마다 다르게 해석할 수 있을 것이다.


3. 변수 이름과 변수 내용에 접점이 없다.

Num으로 미루어 보아 숫자일 것이지만 sz 접두어를 보면 문자열이다.


위는 약간 각색하긴 했지만 실제로 있었던 일이다. 특히 sz 접두어를 붙였지만 문자열이 null 로 끝나지 않도록 만들어 둔 바람에 여기다가 스트링 처리를 했던 모든 코드들에서 문제가 생겼었다. 몇 시간 동안 디버거를 통해 변수가 어떻게 초기화되는지 찾아보고 나서 위와 같은 코드를 찾은 나는 헝가리안 표기법에 대한 깊은 의구심이 들기 시작했고 이에 대한 외국 포럼의 토론 글을 찾아보기 시작했다. 그리고 내린 결론이다:




나는 헝가리안 표기법(Hungrian notation)은 이제 사용하지 않아야 한다고 강력히 주장하는 바이다.

첫 번째 이유는 사람들이 헝가리안 표기법을 잘 못 이해하고 사용할 가능성이 높으며, 이 경우 큰 혼란을 초래할 수 있다는 것이다. 가령 sz가 String terminated by Zero 의 약자인데도 사람들이 잘 모르고 스트링을 대표하는 접두어로 그냥 쓴다는 것이다. 만약 해당 변수가 null로 끝나지 않는다면 나와 같은 상황이 생길 수도 있다. 이 외에도 int 형 변수의 접두어를 누구는 n을 쓰고 누구는 i를 쓰고, bool 변수는 b를 쓰기도 하고 is를 쓰기도 하며 float 변수는 f를 쓰기도 하고 fl을 쓰기도 하며 static 변수 앞에 s를 붙이기도 하지만 스트링 앞에 s를 붙이기도 하는 등 일관성이 없는 문제가 있다. 일관성이 없어지기 쉽다는 것이야말로 이 방법이 잘못되기 쉽다는 반증이기도 하다.

두 번째 이유는 변수의 '타입'을 변수 이름에 기재해야 하는 이유가 없다는 것이다. 요즘은 IDE가 발달해서 변수의 타입 정도는 아주 빨리 알아낼 수 있다. 그리고 C와 달리 C++은 클래스가 도입되어 사용자가 원하는 타입을 거의 무한대로 만들 수 있는데 접두어를 일일히 고안해낼 수도 없는 일이다. PlayerState 클래스 변수의 접두어는 무엇을 할 것인가? ps? iAge를 생각해보자. 나이는 당연히 숫자인데 int 형이라는 정보를 굳이 줄 필요가 있는가?

세 번째 이유는 변수의 가독성이 떨어지고 변수명이 쓸데없이 길어진다는 것이다. 우리는 대부분의 시간에 코드를 쓰기보다는 "읽는다". 변수의 이름은 변수가 어떤 역할을 하는지에 충실해야지 타입을 나타내는데 낭비되어서는 안된다고 생각한다. m_iAge 와 Age 중 어떤게 보기 편할까? 별 차이가 없다고 생각할 지 모르겠지만, 사람은 문자를 읽을 때 마음속으로 모든 글자를 소리내어 발음하려는 경향이 있다. m_iAge 는 "엠, 아이 에이지"로 읽지만 Age 는 그냥 "에이지"로 읽게 된다. 불필요한 문자들의 추가는 가독성을 현저히 떨어뜨리며 코드를 이해하는데 방해가 된다.


네 번째 이유는 변수의 타입이 변경될 경우 변수명을 모두 교체해야 한다는 것이다. 간혹 겪는 일인데, 정수로 계산하던 값이 부동소수점이 되어야 할 일이 생겨서 타입을 바꾸는 경우가 있다. 예를 들어, 캐릭터의 체력은 화면에 정수로 표시되므로 int 타입을 줘서 iHealth 로 만들었다가 나중에 초당 0.5씩의 피해량, 또는 50% 감쇠된 피해량 등을 계산해야되서 float 로 바꾸는 경우가 그것이다.

다섯번째 이유는 타입을 알아야 하는 것 자체가 문제라는 것이다. 예를 들어, 총알을 쐈을 때 적에게 주는 피해량을 50% 증가시키는 버프를 만든다고 생각해보자. 아마 여기서 enemyHealth -= damage * damageBuffRate; 정도의 코드면 이해하는 데 문제가 없다. 그러나 이게 m_iEnemyHealth -= iDamage * fDamageBuffRate; 이면 눈이 피로해지고 잘 읽어지지 않는다. 물론 타입을 알아야 할 순간이 오기는 한다. 그런데 왜 그걸 선언부가 아니고 변수명에 주렁주렁 달고 다니는가?


여섯번째 이유는 기본 타입(Primitive type) 강박증이 생기기 딱 좋은 습관이라는 것이다. 위 g_szMstNum 을 보면 알겠지만 C++ 에 기본적으로 딸려오는 STL 클래스인 std::string 으로 대체해도 충분하며 오히려 char 배열 변수를 사용하는 이유가 무엇인지 물어보고 싶어질 정도이다. 헝가리안 표기법에서는 항상 변수를 만들 때 타입 이름을 무엇을 넣을까 생각하는 과정에서 이미 잘 알려진 타입(i, b, sz, f 등)을 쓰려는 경향이 있다. 따라서 적절한 클래스를 만들어 넣어야겠다는 생각을 하기 어렵고 C native 타입들을 사용하게 되기 마련이다. 기본 타입 강박증은 코드 라인 수가 상당히 길어지고 헤더가 비대해지며 응집도가 낮은 코드를 만드는 경향이 있다. 또 제네릭한 코드와 객체 지향 코드와는 상당히 맞지 않는다.


일곱번째 이유는 변수 이름을 대충 짓는 습관이 생기기 좋다는 것이다. 단지 타입을 변수 이름에 집어넣는 것으로 iPlayer, szPlayer 같은 변수 이름이 얼마나 많이 보이는지 생각해보자. playerIndex, playerName 으로 바꾸면 얼마나 보고 이해하기 좋은가?


여덟전째 이유는 헝가리안 표기법을 썼던 MS 조차도 이제는 쓰지 않는다는 것이다. 헝가리안 표기법을 쓰는 사람 중 일부는 예전 Windows API 스타일을 보고 이 똑똑한 사람들이 만든 법칙에는 분명 무언가 중요한 이유가 있을 것이라는 것을 느끼고 따라한다. 그러나 MS가 만든 현대적인 언어인 C#을 다뤄본 사람은 알겠지만, 헝가리안 표기법은 MS 내에서 더 이상 사용되지 않으며 실제로는 사용이 금지되었다. 

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

위 링크는 MS의 프레임워크 디자인 가이드 중 명명법(Naming) 항목이다. 여기에 가면 다음과 같은 문장이 있다:

DO NOT use Hungarian notation. (헝가리안 표기법을 사용하지 말 것)

이 정도면 말 다 했다고 생각한다.




정리하면,

  • 좋은 코드의 핵심은 코드를 알아보기 쉽게 하고 가독성을 높이는 것에 있다. 그러나, 헝가리안 표기법은 가독성에 큰 도움을 주지 못하며 오히려 해친다. 
  • 읽는 사람에게 잘못된 정보를 전달하여 버그를 만들 수 있다. 
  • 코드를 작성하는 사람에게는 비 객체 지향적인 코드를 작성하게 만든다. 또 변수 이름에 타입을 넣음으로써 어느 정도 정보를 전달했다고 믿게 만들고 변수명을 대충 짓게 만든다.
  • 타입 검사는 컴파일러에게 맡길 것. Visual Studio 2010부터는 컴파일 없이도 타입 체크가 되어 빨간 색으로 밑줄을 그어주니까 훨씬 편하다.
  • 만약 타입을 반드시 알아야 한다면 클래스 등으로 캡슐화한다거나 해서 추상화 수준을 올려보는 것이 좋다고 생각한다. 


---

2010년에 원고를 썼는데 7년이 지난 이제서야 퇴고하고 올린다.

반응형

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


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




나는 사람이 하루에 쓸 수 있는 집중의 시간은 정해져 있다고 생각한다. 마라톤 선수라고 해도 하루에 마라톤을 두 번 이상 할 수는 없는 법이다. 난 사실 마라톤을 어떻게 교육하는지는 모르겠지만, 아마도 마라토너 코치가 선수에게 하루에 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시간 걸렸으므로 오늘은 여기까지!

반응형

+ Recent posts