핀란드 라이프

어찌하다 보니, 핀란드 회사에서 일한지 10개월이 되었고, 핀란드에 오게 된지는 6개월이 되었다.

1. 시간에 대해서 생각하는 방식이 바뀌었다.
예를 들어, 하루에 9.5시간씩 일하고 4일동안 37.5 시간을 채운 후, 금요일에 쉴수도 있다. 시간이 매우 유연해서, 같은 시간을 일하지만 중요하거나 필요한 일은 자연스럽게 할 수 있다.

2. 출퇴근 시간이 거의 없다.
얼마 전에 읽은 책에서, 현재 대도시 빈부 격차는, 회사에서 얼마나 떨어져서 사는 가로 나타나는 경우가 많다고 한다. 대부분 걷기 좋은 도심 한가운데에 위치한 회사이니 만큼, 근처 집값은 상당히 비싼 경우가 많다고.
다행스럽게도 현재 사는 곳은 시골이라서 그런지, 대부분 회사 근처에 당연하다는 듯이 집을 얻어 살고 있다. 500미터 정도 걸어서 출퇴근 중인데, 집이 가깝다는 건 매우 만족스럽고 좋다.

3. '1','2'번의 이유로 아기 보는 시간이 늘었다.
한국에서는 평일에는 아침에 1시간, 저녁에 1시간  정도 볼 수 있었는데, 지금은 대략 4시간 이상은 아이와 보내게 된다. 4시간은 생각보다 길어서, 지치긴 하지만, 즐겁고 보람찬 느낌이다.

육아와 일, 그리고 워크라이프 밸런스

작년 그러니 2016년 11월 13일, 귀여운 아기가 태어나 육아라이프를 시작! 대한민국 공통 코스인 조리원을 거쳐 아이 돌보미 이모님까지 하고나니, 이제 좀 알겠군 하며 시작했는데, 무엇보다도 남는 시간이 없었네요. 이후 1주일의 휴가를 조리원 시절에 사용하고 나니 더 이상 휴가가 없어 바로 업무로 복귀 하고 나니 불과 몇주만에 둘다 아마도 번아웃이라는 불리는 그것이 왔습니다.

와이프는 다시 강의 일을 시작했고, 저도 부랴부랴 회사와 얘기해서 육아기 단축근무를 시작했습니다. 팀에 감사합니다!! 무조건 되는거라고 해서 편하게 신청했는데, 생각해보면 한정된 TO 와 인원압박속에서 쉽지 않았을거라 생각합니다.

주 30시간 근무는 생각보다 많이 달랐습니다. 제법 에너지가 남아 있어서, 오전에 아기 보면서, 집안일을 하기도 하고, 밖에서 한탐 일하고 온 와이프도 생각보다 많이 충전되어 오후에 편하게 교대할 수 있었습니다. 10시간만 줄였을 뿐인데, 생각보다 너무 많이 달랐습니다. 4개월 후에 다시 40시간 근무(+출퇴근 총 2시간*5 = 10시간 소요) 를 시작하니, 아이보는 시간도 줄어들고, 집에 와서 지쳐서 누워있다가 와이프의 잔소리를 듣는 시간도 늘었습니다.

육아기 단축근무 하면서 느낌 점은,
1. 근무시간이 줄어들고, 집에 오래 있으면 아이와도 좀 친해지고, 집안일 할 에너지도 생기더라
2. 남들 출퇴근할 때만 피하면 출퇴근 피로가 반이상 줄어들더라, 서서 힘겹게 가던 버스시간이 즐거운 게임타임으로 ><
3. 아이하고 일정시간 보내지 않으면, 당연하지만 아이보는 스킬 + 집안 일 스킬이 줄더라.
4. 사실 시간 만큼 월급이 줄어드는 거라 회사에서 큰 손해는 없을 거라 생각했는데, 팀 차원에서는 한정된 TO 및 대체 인력 부족등의 이유로 쉽지만은 않더라~

회사 차원의 배려를 통해 남자들도 육아기 단축근무를 자연스럽게 할 수 있으면 좋겠습니다. 이런 걸 보면 요즘 유럽은 부부가 사용할 수 있는 육아휴직 기간이 있고, 남편이 보통 특정기간 동안 무조건 사용해야 된다고 합니다. 이 일정기간동안 많은 걸 배울 수 있을텐데, 이런 제도가 한국에도 있으면 좋겠습니다!

언리얼 엔진 4 의 check 매크로 VS ensure 매크로

언리얼 엔진 4를 하다보면, 특별한 이유없이 엔진 내부 크래쉬로 툴이 죽을 때가 많습니다. 문제는 도대체 무슨 문제인지는 모르겠고, check('조건문') 만 있는 경우가 많습니다. 내부를 조금 더 살펴본 결과, 문제가 생기면 최대한 빨리 크래쉬를 내고, 리포트를 받는 게 목적이지 않을까 싶습니다. 그럼 엄청난 리포트가 쌓이고 순식간에 고쳐질 거 같지만, 에러는 계속되고 있으니,,, 일단 어떻게든 크래시를 건너 뛰어야 겠습니다.

1. Visual Studio 에서 F5를 실행한 경우(즉 debugger 가 붙어 있는 경우)
   - 간단하게는 실행 스텝을 앞으로 옮겨서 가능 합니다. 즉 check 조건문이 걸리면 일단 visual studio break point 가 걸리는데, 이 때 왼쪽의 노란 막대를 실제 툴을 끝내는 루틴 뒤로 넘겨주면 됩니다...

2. 그냥 실행한 경우
   - 사실 이 경우 어떻게 할 수는 없지만, 지속적으로 튕긴다면 다음 번 튕기는 부분은 '일단' 막을 수 있습니다. 방법은,
      check(false) 부분을 뺍니다...네 그냥 빼는 건 기분이 좋지 않으므로, ensure(보통 메시지가 있는 ensureMsgF) 로 바꿔줍니다. 이 경우 디버거가 붙어 있을 경우 여전히 break point 는 걸리지만, 없을 경우에 바로 튕기지 않습니다. 물론 이 실행 이후는 상황에 따라 undefined?...이겠지만요. 요즘 Widget 쪽에서 이유없이 튕기는 경우가 많아서 이렇게라도 해야 되지 않을까 싶습니다.

언리얼 엔진 블루프린트와 버전 컨트롤(Perforce)

블루프린트 특성상,
1. (게임) 데이터
2. (게임) 로직
의 정보가 모두 들어있는데,

기존 작업 방식을 생각해보면 게임 데이터는 엑셀이나 테이블 형태로, 게임로직은 스크립트나 C++로 모두 텍스트 또는 머지가 가능한 데이타기반이다.

하지만 블루프린트는 머지 기능이나 디프 기능을 일부 지원하지만 기본적으로 바이너리 데이타 형태이고, 현재까지 완벽한 머지나 디프가 되지 않는다.

디프는 언리얼 툴 내에서 프로퍼티와 핀 연결성을 통해서 보여 주긴 하지만, 머지는 아직까지 거의 불가능인 줄 알았는데, 언리얼 내부에서 블루프린트를 사용하고 있고, 머지 툴을 사용한다고 하네요.=_=

언리얼 엔진 4 - 블루프린트에 대한 단상

블루프린트에 대한 단상

장점

• 비프로그래머 직군이 이해하기 쉽다.(많은 로직 부분을 자연스럽게 직접 하시고 있더라!!!!)

스크립트언어에서 컴파일이 필요없다는 당연한 얘기인지도 모르겠지만, 비주얼 프로그래밍으로 가니 더 나아가서,,, 비프로그래머자리로 가서 고쳐 달라고 하면 거기서 슥슥 바로 고쳐주고, 고치는 과정을 눈으로 보고는 나중에 비슷한 문제는 직접 고치기 까지 함. 쉽게 배우고 이해가능한듯..(스크립트 언어와는 여기서 큰 차이가).

• 인풋,아웃풋 컨버팅이 자동으로 된다.

가끔 내가 짠 함수도 뭘 넣어야 될지 헷갈릴 때가 많은데, 블루프린트에서는 그럴 핀으로 연결되고 안되고가 바로 보여좋다. 연결 가능한 자동 컨버터 노드도 만들어주니. 행복

• 실행 중인 플로우를 바로 확인할 수 있다.

비주얼 스튜디오에서 실제 여기에 값이 들어오는 지 확인 하려면, 디버그로 켜고(사실 거의 디버그로 실행하겠지만) 브레이크 포인트 걸거나, 로그를 출력하거나 해서 확인하게 될텐데, 블루프린트에서는 왠만한 플로우를 바로 볼 수 있다.(큼지막한 화살표로 표시...해줌)

• 오브젝트를 골라서 디버깅 가능

컴포넌트 방식의 최대 난관이 특정 액터에서만 디버깅하고 싶을 때 인데, 그냥 되더라….

단점

• 복잡한 수학식을 계산하거나, 뭔가 다양한 작업을 한곳에서 진행하면(물론 잘 나누면 이럴일이 적겠지만) 알아보기 힘듦..

• 가끔 C++에서 해야 할지, 블루프린트에서 해야 할지 몰라서 왔다갔다 할때가 있는데, 이부분은 노하우와 경험이 좀 필요한듯, 언리언은 에디트&컨티뉴가 잘 안되니, 왠만한 건 일단 블루프린트에서 작성하고 나중에 필요하면 옮기는 방식이 좀 더 편하더라

  

• 아직 상속이나 인스턴싱 기능이 완벽하지 않아서, 짜증 날때가 있음..(옛날 컴파일러 쓰는 느낌(!)인데, 차츰 좋아지는듯)

• 카피 & 페이스트의 죄책감이 적어져서…...음….

노드 기반(VIsual) 프로그래밍

언리얼 4 와 비주얼 프로그래밍 from Hakhyun(Harry) Kim

2001년쯤 처음 프로그래밍을 시작하고 게임 개발을 시작했는데, 이때 사용한 언어는 아직 'C' 였다. 사실 학교에서 배운 건 C++ 뿐이었는데,

절차적 프로그래밍이라고 부르는 것인데, 그냥 컴퓨터가 일을 할 수 있도록, 컴퓨터야 너 이거 하고, 그거 끝나면 이거 하고, 등등등 순차적으로 계속 일을 시키는 형태였다.

그러다가 2004년쯤 부터, 드디어, C++ 을 사용하게 되었다, 우와 객체다. 하지만 회사코드는 class1, class2, class3 같이 생긴 legacy 코드였다... 객체지향 프로그래밍은 아차하면 늙은? 코드들이.

객체지향은 게임에서는, 

캐릭터

   - 플레이어

   - 몬스터

         - 늑대 - 약함, 걸어다님

         - 용 - 쏌, 날아다님

같이 특정한 객체를 서술하는 형태로 진행되었는데,

나중에 기획자가, 늑대도 날게 해주세요...라고 하면 멘붕이 오는, 그런 시스템이었다.

그러다가, 2008년쯤 부터, 게임 업계에도 컴포넌트 프로그래밍이 유행하기 시작했는데,

늑대  - [걸아다님], [약함], [플레이어를 공격함]

용 - [쏌],[날아다님]

그러다가, 오 늑대도 날게 해주세요 라고 하면, 날아다님 컴포넌트만 붙여주면 됨(이상적으로는) 하며, 아래와 같이 되었다.

늑대  - [걸아다님], [약함], [플레이어를 공격함], [날아다님]

사실 이렇게 하고 나니, 디버깅이 어렵고, 뭔가 멀티스레드 환경 처럼 되어버리는 문제가 있어서, 점점 겍체와 컴포넌트를 적절히 섞어 쓰자라는 형태로 되어버렸고, 현재 언리얼 같은 엔진들도 꽤 그런 느낌?

이제 더 이상 새로운게 없겠지 했는데, 몇년 단위로 바뀌는 것인가?

이번에 언리얼이 블루프린트를 발표해버렸다.

눈으로 보면서 프로그래밍 하세요! 이제!

사살 Visual Programming 자체는 요즘 유행이긴 했다. 아래는 Scracth

LLVM 같은 오픈소스 컴파일러도 나오고 하면서, 직접 프로그래밍 언어를 만들기 쉬운 환경이 된 거 같기도 하고,

게임에서는 Visual Shader 등에서 한정적으로 이미 쓰이기도 했었고,

하지만 게임 로직은 어렵지 않겠어? 최적화가 중요한 데 했었는데,


하지만 이번에 언리얼 4에 들어간 블루프린트는 뭐랄까,

이걸로 다 할 수 있어요?(프로그래머 없이도...)

라지만, 사실 최적화 된, 또는 기획자나 디자이너가 쓰는 좋은? 노드들을 프로그래머가 제공하도록 되었다. 즉 위와 같은 툴에서 데이타를 넣고, 로직을 짤 수 있도록 최적화된 노드와 컴포넌트를 만들게 됨. 그리고 이것이 현재 내가 하는 일!

'Learning' 에 대하여

오늘 교수님과 학습 과정에 대해 토론 할 일이 있었는데,(사실 토론이라기 보다는 수업에 가까웠지만) 일단 나의 주장은, 많이 알면 (무조건) 연구에 도움이 될 거 같다였다. 한 예로, 최근에 알고리즘에 관심이 생겨서, 다이내믹 프로그래밍에 대해서 좀 더 공부하고 싶었고, 좀 더 자세히 알면 뭔가(?) 도움이 될 거 같다였다.

교수님 얘기는 정말 의미가 있을까? 였다. 교수님은 보통 Why? 를 항상 얘기한다.
시간은 한정되어 있고, 좀 더 가치있게 쓰는 게 좋은데, 이미 언제 써야 하고 컨셉을 알고 있다면, 지금 별로 필요하지도 않은 타이밍에 그걸 공부하는 건 의미가 없을 거 같다였다.
그리고 더 중요한 건 '자세한 내용'은 보통 시간이 지나면 잊어먹고, 추후에 필요할 때 결국 다시 공부해야 된다였다.(특히 바로 써먹지 않으면)
갑자기 머리가 깨이는 느낌이 들었다. 교수님의 용어로 이런 걸(원래 있는 용어인지도 모르겠다) Lazy Learning 이라고 한단다. 배우는 거에도 Lazy 가 있는거구나!

그러고보니, 2년쯤 전에 NHN NEXT 학장님하고 얘기를 하고 있었는데, 학장님이 올린 공대얘기를 해주었는데, 핵심은 대학 공부를 시작 할 때, 필요한 과목을 바로 배우지 않고, 프로젝트(목표)를 정하고, 그거에 맞추어서 필요한 과목을 배운다는 점이었다. 사실 이렇게 해도 배우는 크게 차이가 없을 거 같기도 하지만, 동기와 새로운 문제를 해결할 때 공부하는 방법을 배운 다는 점에서 졸업후에, 연구할때 일할 때 크게 도움이 되지 않을까 싶다. 사실 그때는 사실 오 '좋겠구나' 정도였는데, 요즘은 저렇게 해야만 제대로 배울 수 있지 않을까? 하는 생각이 든다. 특히 어떻게 새로운 문제를 해결하고, 접근 하는 지에 대해 아는 것은 정말 중요하다.

한편으로는, 기존에 MOOC 에서 알고리즘을 공부할 때 마다 끝내지 못한 게 게을러서 그랬다고 생각했는데, 사실은 명확한 목표가 필요했던 게 아닐까 싶다. 물론 사실 컨셉도 모르는 알고리즘도 있어서 공부하긴 해야하지만, 이번에는 과제를 전부 해보는게 아니라, 알고리즘을 보고 어디에 어떻게 써먹을 수 있을지 고민해보는 형태면 좋을 거 같다.

또한 공부할 때 어떻게 해야 되는지에 대해서도 교수님과 많은 토론을 할 수 있었는데,
솔직히 학교 졸업 이후로 학습을 제대로 못하고 있다고 얘기드렸더니,
학교 다닐때 했던, 노트 필기나, 짧은 수업 시간에 집중해서 생각하는 것등, 여러가지로 학습을 하는 방법에 대해 얘기할 수 있었다.
교수님이 보내준 참고자료는, 어떻게 정보를 습득하고 인덱싱할 것인가에 대한 것과, 비판적으로 사고하기!
http://lifehacker.com/how-to-better-retain-information-from-books-articles-1674677444
http://lifehacker.com/enhance-your-critical-thinking-skills-with-these-socrat-1672909712

만학도로 박사 과정을 시작하고 나서, 제일 좋은 건 어떻게 생각하고, 어떻게 시간을 관리하고, 그리고 어떻게 공부하는 지, 학습하는 지, 특히 문제를 해결하는 법을 배운다는 점인 거 같다. 이런 걸 배우고 경험할 때 마다, 내가 꽤 논리적인 사람인지 알았는데, 학교에 오니, 비논리적인 용어와, 생각을 남발하는 한명의 학생이구나 싶다. 그래도 한걸음 한걸음 어제와 달라지는 걸 느낄 수 있는데, 역시 새로운 곳에서 새로운 마음으로 공부하는 것의 장점이랄까!