산타캅의 샌드박스

상황 설명

2023년 04월 22일부터 교차로에서 우회전 시 일시정지를 하지 않으면 과태료나 범칙금을 물게 바뀌었다. 정확히는 2023년 01월 22일부터 도로교통법 시행규칙이 변경되었으나 3개월 간 계도 기간을 둬 단속을 하더라도 패널티가 없었다가, 이제부터 패널티를 받도록 한 것이다.

변경된 시행규칙

도로교통법 시행규칙이 무엇인지 검색해보았다. 여기서 확인할 수 있다: https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EB%8F%84%EB%A1%9C%EA%B5%90%ED%86%B5%EB%B2%95%EC%8B%9C%ED%96%89%EA%B7%9C%EC%B9%99

사실 글을 쓰는 시점에서 이 시행규칙을 확인할 수는 없었다. 아직 업데이트를 안 했나?

문제 의식

왜 이런 법이 생겼는가? 법은 국회에서 만든다. 그리고 국회는 우리가 투표로 결정한 국회위원이 입법을 하는 곳이다. 국회의원은 어떤 이유에선가 우회전 시 일시정지를 하지 않으면 처벌을 해야 한다고 결론을 내린 것이다. 왜 그런 판단을 내렸는지 조사해보았다.

입법 근거

https://www.discoverynews.kr/news/articleView.html?idxno=946124 

위 기사에 따르면,

최근 3년간(2019~2021년) 우회전 차량에 의한 교통사고는 총 56,730건이었으며, 이로 인해 406명의 사망자가 발생했다.

라고 한다. 우회전 차량에 의한 교통사고는 하루 평균 약 51건이 발생하고, 사망자는 약 3일마다 1명씩 생기는 셈이다. 우회전하는 차량과 충돌하여 가족을 잃은 사람이 3일마다 한 명씩 생기고 있다고 볼 수 있다.

누리꾼의 반응

내가 정말 이해하기 힘든 반응이지만, 반대로 너무나도 뻔하게 예상했던 반응은 이것이다. 우회전 하는 차가 밀려서 교통체증이 심해지니 나쁜 법이라는 뉴스 댓글이다.

모든 사람은 보행자이다. 그리고 운전자는 그 보행자 중 일부이다. 모든 보행자에게 이득이 되는 법을 만들었지만, 자동차를 소유한 사람은 반발한다. 마치 자기는 횡단보도를 걷지 않을 것처럼.

물론 반응은 커뮤니티마다 조금씩 차이가 있다. 어떤 곳에서는 당연한 법이라는 말이 높은 추천수를 받았다. 하지만 내가 본 수많은 의견들은 대부분 이런 의견이 많았다.

• 무단횡단도 처벌해라
• 보행자가 다 건너갈때까지 언제 다 기다리냐
• 우회전 줄이 더 길어진다, 교통체증이 더 심해진다
• 횡단보도를 더 교차로 바깥쪽으로 밀어야 한다
• 너무 복잡해서 잘 모르겠다
• 세금이 모자라서 이렇게 하는가
• 앞에서 서있지 말고 보행자 없으면 좀 가자
• 일시정지 했더니 뒤에서 빵빵거린다
• 우회전 신호등 설치하라

나의 의견

사람이 죽어야 겨우 바뀌는 게 법이라지만, 법이 바뀌고 나서도 반발하는 반응이 너무도 많다. 그 이유를 생각해보았다.

타자화 및 감정이입 - 나는 운전하니까 보행자가 아니야

운수업 종사자가 아닌 이상 자동차를 운전하는 시간은 하루에 몇 시간 되지 않는다. 하지만 자동차를 소유했다면 본인을 "비보행자"라는, 말도 안 되는 단어로 인식할 가능성이 있다. 운전을 하는 입장에서 우회전 시 나타나는 보행자는 내가 배려해야 될 대상이 아니라 나를 방해하는 사람으로 인식하는 것이다.

피해자 없는 불법은 괜찮아 - 사고를 내는 것도 아닌데 뭐가 문제야

내 차와 보행자가 닿은 것도 아닌데 무슨 상관이냐는 생각이다. 보행자는 나에게 다가오는 차가 나를 본 것인지 아닌지 판단하기 어려울 때가 많다. 특히 틴팅, 썬팅이 많아 운전자와 눈을 마주치기 어려운 한국의 환경에서는 특히 그러하다. 내가 상대방에게 주먹을 내질렀지만 안 맞았으니까 무죄라는 것과 같다.

호의와 권리의 착각 - 원래 차도는 차만 다니는 곳이지, 어딜 보행자가 다녀

자동차는 인간 사회에서 아주 최근에 나타난 물건이다. 역사가 오래된 유럽에서는, 보행자가 자동차의 원활한 통행을 위해 아스팔트를 깔고 횡단보도로 밀려난 것을 이해하고 있기 때문에, 당연히 보행자가 도로를 우선 점유하고 자동차는 보행자를 최대한 방해하지 않으면서 이동하려 한다.

반면 자동차 산업을 중요시하는 미국과 한국에서는 원래 차도는 차가 다니는 곳인데 어딜 감히 보행자가 차를 방해하냐는 논리가 강하다.

계층 의식 - 운전자는 무섭지만, 보행자는 무시해도 된다

차에 타고 있는 사람이 뒤에서 경적을 울리면 엄청 신경쓴다. 왜냐? 다른 차에 대해서는 나랑 동급이니까. 하지만 횡단보도를 건너려는 보행자에게는 되려 경적을 울리며 꺼지라고 경고를 날린다. 차에 타고 있는 나 먼저 횡단함으로써 자기가 더 우월한 존재로 인식하는 것이다. 생각해보면 앞에 있는 보행자나 뒤에 있는 운전자나 그냥 똑같은 사람임에도 이런 생각을 한다. 그래서 댓글에 "뒤에 있는 운전자가 빵빵거리니 앞에 있는 너 보행자가 양보해라"라는 댓글이 나오는 것이다.

이런 계층 의식을 느낄 수 있는 것 중 하나가 인도 주차이다. 보행자가 다녀야 할 인도에 떡 하니 차가 올라와 보행자와 장애인을 방해하며 주차하는 것이다. 왜냐? 차도에 주차하면 차한테 욕먹어서 무섭지만, 인도에 주차하면서 보행자에게 먹는 욕은 무시하기 때문이다.

개선 방안

한국의 교통 문화는 태어나자마자 발생하는 보행자의 권리보다, 돈으로 사는 자동차의 권리가 우선하는 미국 법의 영향을 강하게 받았다. 이제는 보행자가 먼저인 문화로 바뀌어야 한다.

생애 첫 충격은 해외 출장

한 번은 룩셈부르크에 출장을 간 적이 있었다. 신호등이 없는 횡단보도에서, 같이 출장을 갔던 동료들은, 차가 멈춰야만 보행자가 건널 수 있다는 생각을 가지고 있어 저기 멀리서 오는 자동차를 발견하고도 하염없이 기다리고 있었다. 그 때, 다가오던 차가 횡단보도 앞에 멈춰섰다. 우리는 저 차가 고장나서 멈춘게 아닌가 하는 생각을 잠깐 했다. 하지만 그 차는 보행자를 보고, "보행자가 먼저 건너기 전 까지는 운전자가 건너지 않는다"라는 원칙을 실천하고 있던 것이다. 그리고 더 놀랐던 것은, 반대편 차도에 있던 운전자도 모두 멈췄다는 것이다. 다시 말해, 룩셈부르크의 운전자는 횡단보도를 볼 때 마다 양쪽의 보행자를 모두 방해하려고 하지 않았던 것이다.

한국은 어떻게 해야 되나요

제발 보행자가 건널려고 하면 잠깐 서고, 고개를 돌리고, 그 뒤에 움직였으면 좋겠다. 정말로 어려운 일이 아닌데, 시행규칙을 수정해서까지 바꾸려고 한다면 정말 문제가 있는 것이 아닐까?

서론

원래 JavaScript는 별로 배우고 싶지 않았다

그 이유는

1. 가끔 프로그래머 유머 같은 곳에 보면 자바스크립트의 이상한 규칙이 올라온다.

2. 게임 제작 커리어를 가지고 있다보니 C/C++ 위주의 정적이고 컴파일러를 사용하는 언어에 더 익숙했으며, 동적이거나 인터프리터를 사용하는 언어에는 익숙하지 않았다. 다시 말해, 문화적 거부감 또는 "외국어"를 배우는 듯한 느낌이랄까?

3. 내 직관과 어긋났다. 사실 자바스크립트는 2005년 대학교에서 처음 다뤄보긴 했다. 거기서 DOM을 사용했었는데, 어렴풋한 기억으로 메모장에 document.write("Hello World!"); 뭐 이런걸 썼던 것 같다. 2번과는 조금 다른 맥락에서 이질적으로 느꼈는데, 원래 나는 C++을 잘 못 쓰고 C를 먼저 배웠기 때문에 절차 지향 프로그래밍에만 익숙했고 객체 지향 프로그래밍은 잘 몰랐던 상황이었다. 여기서 document.write 라는게, 지금이야 웹 페이지라는 객체에다 출력한다는걸 알 수 있었지만, 그 당시에는 printf("") 보다 더 나에겐 이상하게 보였다. 사실 지금 따져보면 printf도 stdout이라는 객체에다 출력하는 거라고 볼 수 있지만. 그게 C++에서는 std::cout 이었던 것이고.

4. 분명히 자바스크립트로 할 수 있는 어떤 기능은 다른 언어로도 할 수 있을 것이라고 생각했다. C++로만 할 수 있는 게 있을리가 없잖아? 같은 느낌. 그리고, 충격적이게도, 나는 틀렸다.

본론

그래도 배워야 하겠다는 생각이 들기 시작했다

처음 자바스크립트를 접한 뒤로 18년이나 흘렀다. 아직도 자바스크립트는 웹에서 지배적인 언어이다. 아니, "언어"라는 면에서는 대체품이 많지만, "기능"면에서 대체품이 없다. 이게 대체 어떻게 된 건지 이해가 안 되지만 그냥 그렇게 흘러왔다. C/C++로 소켓을 사용해 웹서버를 만들더라도, 결국엔 웹 브라우저로 접근하기 위해서는 어딘가에서 HTML을 출력해줘야 만 하듯이, 상호작용이 가능한 웹 페이지를 만들기 위해서는 자바스크립트를 쓸 수밖에 없다는 생각이 들기 시작했다. 아무리 더럽고 치사해도 써야만 하는 제품이 있기 마련이다.

마치 게임 클라이언트 제작에 C++ 외에 선택지가 거의 없는 것과 같다. 

결론

언어는 자체는 중요하지 않지만, 언어를 배우면서 얻는 경험치는 중요하다

프로그래머로서 짬(?)이 차다 보니깐, 언어란 단지 생각의 표현일 뿐이며, 언어를 잘 다루는 능력은 "(한국어 외에) 외국어를 유창하게 할 수 있는 사람"이 될 뿐이지만, 생각을 잘 하는 것은 "(어느 언어로든) 좋은 글을 쓸 수 있는 능력"에 해당한다는 것을 알게 되었다. C/C++이든, 파이썬이든, 자바든, 자바스크립트든, 생각보다 언어 자체는 크게 중요하지 않다... 라고 하고 싶지만, 사실은 이 또한 중요하다. 똑같은 한국어라도, "공구리 쳐라"와 "콘크리트를 타설해주세요"는 같은 말이긴 해도 현장에의 효율성은 상당히 다를 것이다.

다음 목표는 자바스크립트로 회사 주변 식당 정보를 보여주고, 오늘 먹고 싶은 음식을 찾아주는 웹 사이트를 만드는 것이다. node.js 사용해서 웹 서버 띄우는 것은 정말 쉽게 했다. 20년 전만 해도 APM이라고 해서 Apache, Php, MySql 깔아서 구현하고는 했는데 세상 참 좋아졌다.

서론

흔히 프로그래머는 논리적으로 생각하는 능력이 발달하여 종교가 없을 것이라 생각하는 경우가 있다.

본론

프로그래머야말로 가장 종교적인 직업이 아닌가 싶다. 특히 코드를 작성할 때 말이다.

여기서 말하는 종교의 정의

절대적 존재가 있음을 믿는다는 의미로써의 종교라면 프로그래머는 종교적이라고 말할 수 없다. 그러나, 자신이 믿는 것과 배치되는 이야기에 감정적으로 대응한다거나, 자신에게 익숙하고 주변에 많이 보이는 무엇인가를 지배적 종파로 인식한다거나(이 경우 조직을 옮기면 큰 충격을 받음), 새로운 개념을 접했을 때 유용하게 여기기보다는 비판하며 쉽게 받아들이지 못한다거나, 상대방의 고집을 꺾고 자신의 교리로 개종시키려는 점에서는 상당히 닮아있다.

예시

• 헝가리안 표기법 쓰냐 안 쓰냐

예: https://santacop.tistory.com/m/6

• 들여쓰기 탭이냐 스페이스냐

• 문법적으로 뭔가를 강제하는 언어에 대한 저항 (파이썬 입문 시)

• 클라이언트 프로그래머에게 서버 일을 맡아달라고 했을 때(혹은 그 반대) 상황에서의 심리적 거부감. 프론트엔드-백엔드와의 관계와도 비슷하다.

업무 중 사례

보통 사수 또는 시니어 프로그래머가 들어온지 얼마 안 되는 프로그래머에게 이래라 저래라 하는 것이 대표적인 모습이다. 좋게 이루어진다면 코딩 컨벤션을 알려주고 조직 문화를 동기화한다고 볼 수도 있겠다. 그러나 이것이 과하면 조직의 규율이 아닌 개인의 신념을 주입하게 된다. 본인만의 종교가 발달하지 못한 생 신입(무종교자)에게는 효과가 있을 수 있지만, 이미 경험이 쌓인 사람에게는 종교 전쟁을 거는 행위와도 같다.

결론 - 그래서 어떻게 해야되나?

신입에게는

신입에게는 조직 차원에서 합의되지 않은 의견을 말할 때 반드시 "이건 내 개인적인 생각인데, 반드시 따라야 하는 것은 아니지만 내 경험상 도움이 되었다" 라고 하면서 이야기해주자. 그렇게 하지 않으면 그 신입이 다른 프로그래머가 작성한 코드가 사수가 말한대로 작성되어 있지 않은 경우 혼란을 느끼게 된다.

동료와는

존중하는 자세로 이야기하라. 토론 도중 목소리를 높인다거나 표정 관리를 못 한다면 아예 이야기 자체를 꺼내지 읺는 것이 좋다. 특히나 내가 연차, 직급, 직책이 더 우월한 입장에서 "짬"으로 강요하는 행위는 절대 삼가야한다. 차라리 팀 회의 시간에 팀이 모두 지켜야 할 하나의 코딩 컨벤션(성경)을 만들자. 개인의 신념을 조직으로 이동시키는 것이다. 성경 또한 여러 번 합의를 거쳐 개정시키자. 모든 조직은 처해 있는 상황이 다르므로 다른 성경이 나오게 될 것이다.

마지막으로

본인의 교리가 너무 오랫동안 변하지 않는다면, 어쩌면 발전하고 있지 않은 것일 수 있다. 교리는 경험의 축적이다. 계속 같은 경험만 반복적으로 하고 있지 않은지 돌아보자. 나에겐  새로운 언어를 배워보는 게 가장 효과적이었다.

이런 글을 쓰는 이유는

최근 우리 팀에 상당히 이질적인 교리를 가진 분이 나타났다. 그 분의 코드를 살펴보니 이해하기 어려워 처음엔 불쾌한 느낌이 들었다. 시간이 지나고 보니, 그 코드 또한 문제를 잘 해결하고 있다는 느낌이 들었다. 양쪽의 유전자를 합치면 더 좋은 코드가 나올 것 같은 느낌이 들었다. 그 분에게도 너무 이질적인 코드를 일부러 작성하지는 말아달라고 부탁을 드렸다. 아마 평소 하던대로 했던거겠지만.

물건을 사려고 봤더니 소재는 안알랴줌

식탁보를 사고 싶어 네이버에 검색을 하며 알아봤다. 공산품을 구매할때는 네이버에서 검색 시 조금 더 저렴하게 표시됨을 경험적으로 알고 있기 때문이다. 이제는 많이 알려진 사실이지만 쇼핑몰은 접근 경로에 따라 다른 가격을 보여준다.

이 때 방수가 되는 인조 가죽 식탁보라는 것이 보였다. 얼핏 방수가 되면 국물을 쏟아도 젖지 않고 바로 닦아낼 수 있으니 위생적일 것 같다. 여기서 의문을 가졌다. 인조 가죽은 플라스틱으로 만든다. 일부 플라스틱은 인체에 해롭지 않지만, 다른 플라스틱은 해로울 수 있기 때문이다. 또 플라스틱은 열에 약한 성질을 가진 경우가 많다.

해당 제품은 상품 설명에서 소재를 "인조 가죽"으로만 표기하고 있을 뿐, 어떤 플라스틱을 썼는지는 표기하고 있지 않았다.  본인의 제품은 중금속이 검출되지 않아 인체에 안전하다는 광고를 하고 있었다. 정상적으로 만든 플라스틱엔 원래 중금속이 포함될 여지가 적다. 재활용한 플라스틱을 원료로 쓴 게 아니라면 말이다. 모종의 방법으로 소재를 알아내었다. PVC를 사용한 제품이었다.

PVC가 뭔데요?

PVC는 폴리염화 비닐(Polyvinyl chloride)의 약자이다. 비닐이라고 하니까 비닐 봉지나 음식을 담는 포장재와 비슷하여 괜찮지 않을까 하는 생각을 할 수 있으나 다르다. 우리가 흔히 쓰는 비닐 봉지는 폴리에틸렌(PE), 음식 포장재는 폴리에틸렌 또는 폴리프로필렌(PP)을 사용한다. 이것들은 인체에 무해하다. 그러면 PVC는 우리 몸에 유해할까 무해할까?

PVC 자체는 문제될 것이 적다. 문제는 가소재다. 가소재는 프탈레이트라고 한다. 이건 어떤 특정 성분을 말하는게 아니라 총칭이다. 마치 에탄올과 메탄올 모두 알코올이라고 하지만 하나는 먹으면 죽거나 실명할 수 있는 것과 같다. 프탈레이트의 일부는 환경호르몬이다. 가소재가 완전히 섞여 안정한 상태가 된다면 좋겠지만 실제로는 그렇지 않은 듯 하다.

PVC는 수도관에도 사용할 정도로 안전하나, 여기에 가소재가 들어가면 물렁물렁한 성질을 띄게 된다. 아마 이 인조 가죽은 PVC에 가소재를 첨가하여 만들었을 것이다. 가소재인 프탈레이트는 제품 표면에 조금씩 용출될 수 있고 만지거나 입에 들어가면 몸에 축적되어 해를 끼치게 될 것이다.

똑같은 천연 소재 옷이라도 면인지, 양모인지, 비단인지, 모시인지에 따라 입었을 때의 느낌, 방한 능력, 비에 대한 저항, 세탁 방법까지 크게 다르다. 합성 소재인 플라스틱도 마찬가지다. 누가 옷을 파는데 그냥 "천연 소재"만 썼다고 광고하고 그게 정확히 무엇인지 알려주지 않으면 내가 원하는 느낌도 안 나고 빨래도 못 할 것이다. 꼭 살펴야 한다.

잘 모르겠으면 PVC는 그냥 걸러라

결론을 내리면, "식품용" 인증을 확실히 받지 않았다면 PVC 소재는 반드시 피해야 한다는 것이다. 광고에는 무슨 중금속이, 무슨 화학 성분이 없어서 인체에 안전하다는 느낌으로 표시되어 있겠지만, 그건 높은 확률로 재료에 불순물이 없음을 표시한거지 인체에 안전하다는 보증서가 아니다. "물거나 빨거나 핥거나 입에 넣어도 안전하다"고 광고하지는 않고 있을 것이다. 또 화재가 발생했을 때 다이옥신 등 인체에 치명적인 가스가 발생한다. 테이블보는 열기나 화기(넘어진 촛불 등)에 노출될 가능성이 높으니 조심해야 할 것이다.

특히나 아기를 키우는 가정에서는 어린 시절부터 환경호르몬에 노출되지 않도록 물고 빠는 장난감이나, 기어다니고 열이 가해질 바닥 장판, 바닥 매트 등을 살 때 조심해야 할 것이다.

참고 링크

• https://www.k-health.com/news/articleView.html?idxno=8717 

• https://en.wikipedia.org/wiki/Polyvinyl_chloride#Health_and_safety - 영어가 된다면 읽어보자

몬스터헌터 월드 아이스본 스팀 PC판 기준이다.

2018년 8월 부근에서 더 이상 게임을 하지 않는 등 장시간 게임을 하지 않은 경우, 세이브 파일 포맷이 바뀌었는지 아이스본 DLC 구입 후 게임을 시작하면 "'Monster Hunter World: Iceborne'의 저장 데이터가 파손되어 데이터를 읽어 들이지 못했습니다. 저장 데이터를 초기화하시겠습니까?" 라는 메시지가 뜬다. 이 경우 절대로 "예"를 눌러서는 안되고 게임을 강제 종료해야 한다. 세이브 데이터가 날아가서 처음부터 다시 플레이해야 될 수도 있다.

아래 방법은 레딧에서 찾은 것인데, 구버전 클라이언트로 세이브 파일을 열고 다시 저장하는 방법이다:

1. 스팀에서 몬헌 월드 우클릭 -> 속성 -> DLC -> 전부 체크 해제

2. 스팀 콘솔 열기 steam://nav/console (시작-실행-"steam://nav/console" 따옴표 빼고 입력 또는 인터넷 브라우저 주소창에 입력)

3. 스팀 CONSOLE이 열리면 "download_depot 582010 582011 5080591846956782264" 따옴표 빼고 입력

4. 스팀이 구버전 클라이언트를 다 받을 때 까지 대기. 28GB 이므로 꽤 걸린다. 따로 진행 상황을 볼 수는 없다. 다운로드중인지는 스팀 아래 다운로드 항목에 들어가면 네트워크 사용량이 나오는데 이걸로 알 수 있다.

5. 다운로드가 끝나면 스팀이 파일이 다운로드 된 곳을 보여준다. CONSOLE 화면에 나온다. Depot download complete 뒤의 경로이다. 아마 C:\Program Files (x86)\Steam\steamapps\content\app_582010\depot_582011 요런 식으로 나올 것이다.

6. Steam\steamapps\common\Monster 폴더로 이동한다.

보통 C:\Program Files (x86)\Steam\steamapps\common\Monster Hunter World 여기에 있을 것이다. 모든 파일을 다른 곳에 이동시켜준다. 아까 다운로드 받은 파일을 여기로 모두 복사해준다.

7. 자기 스팀 아이디를 알아낸다. https://steamidfinder.com/ 여기서 찾으면 되고 steamID3 항목이다.

8. 세이브 파일은 C:\Program Files (x86)\Steam\userdata\[아까찾은steamID3]\582010\remote 여기에 있다. 혹시 모르니 백업해둔다.

9. 게임을 업데이트하지 말고 실행한다. 게임이 정상적으로 실행되는 것을 확인한다.

10. 자기 캐릭터를 로드하고 다시 저장한다.

11. 게임을 종료한다. 6번에서 한 것과 반대로 구버전 클라이언트를 지우고 아까 백업해둔 클라이언트로 복구시킨다. 속성에 가서 아까 체크를 해제한 DLC 들을 체크해준다.

12. 이제 게임을 실행해서 잘 세이브 파일이 불러와지는지 확인한다.

참고 링크:

https://nomo.asia/448

https://www.reddit.com/r/MonsterHunter/comments/emvkwg/how_i_fixed_the_missing_iceborne_save_bug/

https://unity3d.com/kr/learn/tutorials/projects/2d-roguelike-tutorial/project-introduction?playlist=17150

내가 하고 싶었던 그 프로젝트

사실 유니티에 입문하자마자 가장 먼저 하고 싶었던 튜토리얼이었으나, 튜토리얼 진행에도 순서가 있다고 생각해서 지금까지 다른 튜토리얼들 - Roll a Ball, Space Shooter, Survival Shooter, Tanks! - 을 진행했던 것이었다.

개인적으론 2D 게임을 좋아하고 또 만드는 데 관심이 많다. 그리고 던전크롤, 스톤수프, Slay the spire 같은 로그라이크 장르도 좋아한다.

다시 내레이션 비디오

다시 워크샵 형식이 아니라 내레이션 방식이다. 처음엔 워크샵 형식이 싫었지만, 튜토리얼 비디오를 보다 정이 들었는지 그 분들이 다시 그리워진다.

Roll a Ball 또는 Space Shooter 를 진행했던 그 분의 목소리는 아니다. 아마 다른 사람인 듯.

시작부터 불길한 예감

유튜브 댓글을 보았더니, 예상과는 다르게 엄청나게 많은 혹평들이 있다. 특히 말로만 이것 저것 하라고 말하지 말고 - 심지어 틀리게 알려준다고 한다 - 직접 시연해서 보여달라는 요청이 많다. 아무래도 비디오만 봐서는 진행하기가 좀 어려웠던 모양이다.

드디어 끝이다!

약 2달 정도 걸렸다. 이제 다음은 2D 로크라이크 튜토리얼을 할 차례이다.

튜토리얼 동영상 마지막에 진행자가 드디어 끝났네요 하면서 만세를 하는데 박수가 터져나온다. 아무래도 아침부터 저녁까지 하루 종일 하는 것이다 보니 진행자나 학생들이나 모두 힘들었을 것이다. 드디어 퇴근이다! 하는 느낌.

지금까지 튜토리얼을 하면서 큰 문제가 있었던 적은 없었는데, 이번에 처음으로 뭔가 빠뜨린 것인지 제대로 동작하지 않는 부분이 있었다. 발사 시 화살표 크기가 0부터 시작해야 하는데, 이미 큰 상태에서 시작된 것이었다. 뭔가 상대적 Size 지정을 할 때 빠뜨린 부분이 있었던 듯 하다. 겨우 찾아서 수정했다.

유튜브 동영상 댓글에도 뭐가 안된다는 말이 많은데, 내가 알려줄 수 있는 부분은 댓글을 달아서 알려줬다.

게임 규칙의 문제점

튜토리얼이기 때문에 게임 규칙 자체는 하자가 좀 있다. 가장 큰 것은 발사 간의 쿨타임이 존재하지 않는다는 것이다. 따라서 조금이라도 상대방의 위치와 주포가 정렬되면 발사 키만 연타해서 상대를 빠르게 죽이거나 접근하지 못하게 하는 것이 가능하다. 두 번째로는 발사 방향과 이동 방향이 항상 일치한다는 것이다. 주포를 돌릴 수 없으므로 상대를 바라봐야만 피해를 줄 수 있는 가능성이 생기는데, 이러면 상대방을 바라본 상태에서 앞, 뒤로만 움직일 수 있게 된다. 상대방이 먼저 나를 조준했다면 날아오는 포탄을 피하는 것이 급선무이므로 방향을 틀어야만 하고, 나는 다시 피해를 줄 기회를 잃어버리게 되므로 게임 결과가 뻔해진다. 마지막으로 전진 시와 후진 시 좌, 우 입력의 방향이 반전되지 않는 문제가 있다. 무슨 말이냐면, 자동차로 치면 핸들을 왼쪽으로 꺾은 후 후진을 하면 꼬리 부분이 왼쪽으로 움직여야 하는데 이 게임은 왼쪽 입력을 하고 있으면 반드시 왼쪽으로 차체가 회전하게 되어 있으므로 반대로 후진 시 꼬리 부분이 오른쪽으로 움직인다. 물론 무한궤도 특성상 틀린 것은 아니지만 전진과 후진을 반복하다보면 원하지 않는 동작을 하기 쉽다.

윈도우로 유니티에서 스크립트를 편집하면 보통 Visual Studio + C# 조합을 쓰게 된다. 그런데 최근 새로 유니티를 설치하여 개발하다보니 C# 자동완성이 되지 않는 것을 확인했다.

해결 방법은 다음과 같다:

* 비주얼 스튜디오와 유니티를 닫는다

* 시작-실행-appwiz.cpl 입력 (또는 '프로그램 추가/제거' 찾아서 실행)

* 'Microsoft Visual Studio Installer' 를 찾아서 마우스 오른쪽 클릭 - 변경

* Visual Studio '수정' 클릭

* 오른쪽에서 'Unity를 사용한 게임 개발' 항목을 확장하고 'Unity 2017.2 64비트 편집기' 체크

* (여기까지만 하고 '수정' 버튼을 눌러 나온 뒤 유니티와 VS를 다시 켜면 나의 경우 인텔리센스가 동작했다)

* 혹시 모르니 '개별 구성 요소' 탭 - 코드 도구 - 'NuGet 패키지 관리자' 체크가 안되어있으면 체크

* '수정' 버튼 누르고 체크한 것들이 추가로 설치될때까지 대기

* 이제 유니티, VS를 켜면 자동완성이 됨

정보 출처: https://developercommunity.visualstudio.com/content/problem/130597/unity-intellisense-not-working-after-creating-new-1.html

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

무슨 프로젝트일까

한 PC 에서 2명이 키보드를 가지고 탱크를 몰아 서로를 격파할 수 있는 게임인 것 같다. 즉, 온라인 멀티플레이어가 아니라 오프라인 멀티플레이어 게임이다. 튜토리얼 영상 초반에 완성된 게임의 영상을 보여주는데 꽤 흥미로워 보인다.

튜토리얼 진행 방식

저번 Survival Shooter 튜토리얼과 마찬가지로 자막은 한국어는 없고 영어는 지원한다. 재미있게도 일본어 자막은 있다. 일본인이 유니티에 관심을 많이 가지고 있는 것일까?

'UNITE 2015 BOSTON' 이라고 써있고 스케줄표에 점심 시간이 있는 것으로 보아 상당히 긴 시간동안 진행될 것 같다.

집에서 일하고 싶다

회사에서 일을 할 때는 뭔가 자기계발을 해야겠다고 생각하는 일이 많다. 그리고 집에 가면 취미로 이러이러한 프로젝트를 해봐야지, 이러한 게임을 만들어봐야지 하는 생각에 잠기기도 한다. 문제는, 집에 문을 열고 들어가면 이런 생각들이 모두 날아가버린다는 것이다.

요리사는 집에 가면 (요리 하는 것이 지겨워서) 요리를 하지 않는다는 말이 있다. 통계적으로 사실인지는 모르겠으나 들었을 때 뭔가 공감이 가는 면은 있다. 그리고 공감이 간다는 것의 의미는 나 또한 그러고 있기 때문이기도 하다.

추진력만 가졌던 어린 시절

어렸을 때는 게임을 만들고 싶었지만 방법을 몰라 공책에 어떤 게임을 만들지 써보고 도트를 찍으며 게임에 들어갈 아이템들의 아이콘들을 그리며 놀았다. 그리고 베이직과 C, C++ 를 배우면서 그 '방법'을 배우기 시작했다. 정말 간단한 비행 슈팅도 만들어보고 내가 어떻게 했는지 기억은 잘 나지 않지만 이펙트까지 만들어서 넣고 하이텔에 배포도 했던 기억이 난다. 그런데 중학교에 들어가면서 소위 말하는 입시 공부를 시작하게 되었고 - 내가 살던 곳은 고등학교도 수능처럼 시험을 쳐서 들어가야 했다 - 그 때부터 더 이상 취미로 게임을 만들지 않게 되었다. 물론 게임 하는 것은 매우 좋아했지만.

추진력만 있으면 되는 지금의 나

사실 게임을 만들고 있지는 않았지만 머릿속으로는 게임 제작에 대한 생각은 계속 하고 있었다. 많은 게임들을 머릿속으로 구상했다. 그런데 이상하게도 집에만 가면 하기 싫어지는 것이었다. 마치 누가 해줬으면 좋겠다 하는 느낌이랄까. 어쩌면 제대로 게임을 만든 경험이 없이 조금씩 끄적대다보니 스스로 해봤자 안된다는 생각을 하고 있던 것일지도 모르겠다. 혹은 바닥부터 만들 생각을 하니 엄두가 나지 않아 그랬을 수도 있다. 아니면 카운터 스트라이크와 울티마 온라인과 같은 재미있는 게임이 많이 나와서, 굳이 내가 만들지 않아도 됐기 때문이었을지도 모른다.

이제는 인터넷도 있어 질문할 곳도 많아졌고 모르는 것이 있으면 검색으로 금방 알아낼 수 있다. 언리얼, 유니티와 같은 편리한 게임 제작 도구들도 무료로 쉽게 구할 수 있다. 게임을 제작하기에는 더없이 최적의 조건이 되었다. 그런데도 여전히 나는 꿈쩍할 생각을 하지 않는다.

어떻게 나에게 일을 시킬 수 있을 것인가?

재미있게도 스스로에게 일을 시키는 것 만큼 어려운 것은 없을 것이다. '그냥 하면 되는데' 난 하지 않는다. 대부분의 사람들은 게으르다. 그래서 나는 내 뇌에서 원하는 것을 주기로 했다.

동기를 유발하는 요인은 크게 두 가지로 나눌 수 있다. 첫째는 보상이고, 둘째는 처벌이다. 어느 쪽이든 뇌를 움직이지만 매커니즘은 다르다고 볼 수 있다. 보상은 도파민이고, 처벌은 스트레스이다. 먼저 처벌을 하는 방법은 쓰지 않기로 했다. 고통을 피하기 위해 하는 행위는 불편하고 귀찮지만 어쩔 수 없이 하는 행위가 될 수밖에 없다. 그리고 보상을 준다면 '자발적'으로 움직일 가능성이 더 커진다고 판단했다. 게임을 개발하는 행위 자체가 즐거움이 되어야 한다.

보상을 하려면 내가 무엇을 했을 때 뇌에서 도파민이 분비되는지 알아야 한다. 그리고 내가 원하는 행위를 했을 때 그 보상을 줘야 한다. 

도파민 공급 수단의 결정

나는 그 수단을 '맥주'로 정했다. 예를 들어, 맥주가 마시고 싶다면 게임을 만드는 행위를 하면 된다. 그러면 나에게 맥주 한 잔을 마실 수 있는 권리가 생기는 것이다. 반대로 게임을 만드는 행위를 하지 않았을 때는 맥주를 어떤 경우에도 마실 수 없도록 했다. 

맥주를 선택한 이유는 여러가지가 있다. 먼저 나는 맥주를 아주 좋아한다. 그리고 보상에 필수적인 즉시성 - 원하는 행위가 발생되고 보상까지의 시간이 짧을 것 - 과 일관성 - 항상 동일한 품질의 보상을 줄 것 - 을 유지하기에도 좋다고 판단했다.

그래서 결과는?

생각보다 효과적이었다. 하루 한 잔의 맥주를 마시기 위해 나는 매일 게임 개발을 하는 행위를 했다. 시원한 한 잔이 생각날 때 컴퓨터 앞에 가 개발 도구를 켰다.

가장 힘든 부분은 게임 제작을 하지 않았을 때는 맥주를 마시는 행위를 하지 않는 것이었다. 손만 뻗으면 보상이 있는데도 불구하고 그걸 참아내는 것은 상당한 의지를 필요로 한다.

그 다음으로 힘든 점은 집중력이었다. 내 생각에 따르면 빠르게 보상을 얻기 위해서는 행위를 빠르게 끝내야 했다. 예를 들면, 예비군에 가서 빨리 움직이면 빨리 끝내준다는 말을 들었을 때 사람들이 달리기 시작하는 것과 같은 그런 것이었다. 그럼에도 불구하고 집중을 유지하기가 힘들었다. 그 말은 아직 게임 개발을 하는 행위 자체가 도파민을 발생시키지 않는다는 뜻이다. 도파민은 동기 부여와 집중력에 관여한다.

다만 이런 훈련이 좀 더 반복된다면 게임 개발 행위와 보상과의 관계를 뇌가 학습하여, 게임 개발 행위를 장려하기 위해 도파민을 분비시킬 가능성이 있으므로 조금 더 진행해봐야 할 듯 하다.

마지막으로, '보상'을 미리 받는 것은 전혀 도움이 되지 않았다. 맥주를 먼저 마셔버리면 게임 개발을 하지 않는 경우가 많았다. 반드시 끝나고 보상을 줘야 한다.