truwater.net

게임 테크 컨퍼런스 2012에서 들은 몇가지 세션에서의 주 내용은 좋은 게임을 어떻게 만들 것인가 보다는 어떻게 매출이 많이 나는 게임을 만들 것인가에 초점이 맞추어져 있는 것 같다. 엔진의 장점과 사용법을 소개하여 엔진을 프로모션 하는 하나의 줄기와 성공한 게임을 소개하고 어떻게 매출을 끌어올렸는지에 대한 또 하나의 줄기로 컨퍼런스의 성격을 규정해 볼 수 있겠다. 8만 8천원이라는 비싼 입장료 때문에 참석자가 많지 않으리라 생각했는데 예상을 훨씬 상회하는 청중에 의아함을 느꼈다. 사비를 들여 올 만큼 퀄리티가 있을 것인지는 의문이었기 때문이다.
컨퍼런스에 참석해서 얻은 성과는 컨퍼런스 내용 보다는 열정을 가진 사람들이 많이 있다는 사실을 알았다는데 있다. 에너지가 고갈 된 나로써는 어느정도 약이 될 수도 있는 행사였지만 이 일로 예전의 열정이 생겨날런지는 미지수이다.
행사 중 기조 연설을 한 퍼거슨님의 발표가 내용적으로는 가장 도움이 되었던 것 같다. 너무 이른 아침이라 약간 졸면서 듣긴 했지만 선명하게 기억나는 세 가지가 있다. 첫번째는 지프와 에일리언 호버를 예로 들면서 설명해 준 앵커, 즉 게이머의 기대는 익숙함에서 부터 시작하고 호버 보다는 지프가 익숙하며 사람들이 알고 있는 지프보다 성능이 좋으면 만족한다는 사실. 두 번째는 브랜딩 로고. 기어즈 오브 워의 로고는 사람들이 문신을 할 만큼 좋아할 요소를 가지고 있고 로고만 봐도 게임이 생각이 나게 된다는 것. 세 번째는 레이더즈를 예로 들어 설명 해 준 비주얼 아이덴터티. 레이더즈의 포스터는 영화를 설명하는 모든 요소를 다 가지고 있었다는 것. 그 설명을 듣고 포스터를 보니 정말 포스터 하나가 영화의 모든 것을 함축적으로 설명해 주고 있다는 것을 깨닫고 놀랐다는 점. 기어즈 오브 워도 많이 노력했지만 레이더즈의 포스터는 비주얼 아이덴터티의 교과서를 보는 것 같았다.
초대해 주신 게임베이스 박 실장님께 눈도장도 찍었고 오랜만에 옛 친구들을 만날 수 있었던, 기대를 많이 안하고 가서 그런지 몰라도 보람찼던 행사였던 것 같다.

내면의 동기와 자율성과 자신감을 확보하자. 그리고 다른 사람에게도 이를 확보하게끔 해 주자. 통제하려는 인상을 주지 않게 칭찬할 때도 주의하자.

여기서 자리는 사실 실제 자리가 아닌 피그말리온 현상에서 말하는 환경에 더 가깝지만…
사무실에서 관리자의 책상 위치는 관리에 엄청난 영향을 미친다. 비공식적인 정보 채널이 형식적인 정보 채널을 보완해 주기 때문이며 때로는 더 중요할 수도 있기 때문이다. 지금 회사에서 나의 자리는 두 군데 있다. 개발팀 가운데와 경영진 가운데이다. 어느 곳에 주로 있는가가 회사를 바라보는 관점에 엄청나게 영향을 끼친다.
경영진 측에 있다 보면 개발과 멀어져 개발이 블랙박스에 가까워 진다. 그러다보면 개발에 신경을 덜 쓰게 되고 개발 자체가 지연된다. 개발진 측에 있으면 개발 자체가 화이트박스가 되어 잘 이끌 수 있지만 전체적으로 돌아가는 상황을 보지 못하게 되어 전체 일 처리 자체에 답답함을 느끼게 된다.
네오액트의 개발 프로세스는 정치 역학에 묶여 한단계 발전을 요구하는 시점에 그것을 뛰어넘지 못하고 있다. 안 그럴것 같은 사람도 어느 정도 권력욕에 따라 행동하는 경향이 있으므로…
비전과 공감을 침투시켜야 한다. 인셉션처럼…

대부분의 RDBMS에서는 레코드를 삽입 후 인덱스를 얻어 낼 수 있다. 그로 인해 여러 테이블에 관계가 있는 레코드들을 삽입 할 때 삽입 후 갱신 과정을 거쳐야 할 때가 많다. 예를 들어 직원 테이블과 장비 테이블에 레코드를 입력하는 경우를 살펴보자. 먼저 직원 테이블에 직원 레코드를 추가 하게 된다. 그 후 그 직원이 사용하게 될 장비를 장비 테이블에 추가 하게 되는데 이 때 서로 참조하는 기능을 구현하게 된다면 직원 테이블에 어떤 장비를 사용하게 되는지에 대한 인덱스를 가지게 되고 반대로 장비 레코드에는 직원 인덱스를 가지고 있게 된다. 그럼 직원 레코드를 추가 후 직원 인덱스를 알아오고 장비 레코드를 추가 하고 그 후 장비 레코드의 인덱스를 알아와서 다시 직원 레코드를 업데이트 해 주어야 한다. 비효율적이다.
레코드를 추가 하기 전에 인덱스를 알아 낼 수 있다면 이 비효율을 없앨 수 있을 것이다. 사실 DB 테이블에 레코드를 추가하는 작업은 메모리를 할당하고 초기화 하는 작업애 비유될 수 있다. 메모리를 할당 받은 후 초기화 작업을 하지 그 반대로 할 수는 없다. 이런 사실로 미루어 보아 테이블에 레코드를 추가 하는 작업도 추가될 레코드 공간을 할당 받은 후에 자료를 세팅하는 것이 자연스럽다고 할 수 있을 것이다.
일반적으로 사용하는 RDBMS는 이런 직관과는 틀리게 레코드 추가 후 인덱스를 알아올 수 있었다. 하지만 MongoDB는 다르다. 레코드를 할당 받아 자료를 세팅하는 것이다. 지극히 자연스럽다고 할 수 있다. MongoDB는 RDBMS가 아니지만, RDBMS인지의 여부는 프로그래밍을 하는 입장에서 중요하지 않다. DB에 접근하는 방법, 즉 인터페이스가 가장 중요하니까.
일반적인 상식에 더 근접한 MongoDB가 프로그래머인 인간에 더 적합한 접근 모델을 가지고 있다고 할 수 있겠다.

gksu rm /etc/fonts/conf.d/29-language-selector-ko-kr.conf

책내용 중 다음과 같은 문제가 나온다.
“두 대의 기차가 150마일 떨어져서 서로 마주보며 달려오고 있다. 첫번째 기차는 시간당 60마일의 속도로 달리고 있다. 두 번째 기차는 시간당 90마일의 속도로 달리고 있다. 첫번째 기차의 앞부분에 파리가 한 마리 있다. 이 파리는 두 번째 기차를 향해서 날아가서 두 번째 기차의 앞부분에 도착하면 방향을 바꿔서 다시 첫번째 기차로 날아가고, 또 다시 두 번째 기차로 날아가는 과정을 반복한다. 파리는 이와 같은 왕복운동을 두 기차가 충돌할 때 까지 반복한다. 만약 파리의 비행 속도가 시간당 120마일이었다면 파리가 운동한 거리는 전부 얼마일까?”
답은 책에 안 나와 있는데 기차가 충돌하기까지 1시간이 걸리고 파리가 시간당 120마일을 비행하니까 파리가 운동한 거리는 당연히 120마일일 것 같다. 그런데 책에서는 무한급수로 풀라고 한다. 무한급수로 풀면 120마일이 나올까? 수학의 정석을 뒤적거리면 풀 수 있을까? 이 수학 지식이 깡그리 사라진 느낌은 뭘까? 수학의 정석을 한 번 더 복습해야 하나 ㄷㄷㄷ
P.S. 책에서는 다른 사람의 소스를 많이 읽어보라고 한다. 그런데 난 타인의 소스을 읽으면 분노게이지가 차 오른다. 그리고 오류를 잡기보다 다시 만들게 된다. 이건 고쳐야 되는데… ㅠㅠ

창업을 해 본 사람이 보면 많이 공감할 수 있는 책 임에 틀림이 없지만 보고 있는 내내 뭔가 불편한 느낌을 지울 수 없다. 여기 있는 내용이 틀린 말은 아니지만 꼭 맞다고 할 수도 없고 알고 있다고 창업에 그닥 도움이 되지 않는다고도 생각이 든다.
창업을 해서 죽을 쑤고 있는 입장이라 돌파구를 찾아보려 읽긴 했지만 역시 내가 생각한 창업한 후 성공 스토리와는 너무 틀린 내용이라…
“굶으면서 제품과 서비스를 완성 -> 서비스 후 대박”은 물건너 간건가…
“최고근무환경->최고프로그래머들->최고소프트웨어->수익!!!”은 꿈의 성공 스토리인가 ㅠㅠ

문화와 마음까지도 진화로 설명할 수 있는 지금, 진화심리학은 대세가 됐다.
과거에 적응한 몸과 마음으로 현재를 살아갈 때 생기는 모순들을 진화론으로 잘 설명 해 준다.
진화한 본능은 우리에게 도움을 주기도 하지만 뒤늦게 생긴 이성(추론)은 아직 본능에 우선하지 못한다. 이성이 본능을 컨트롤하는 순간 니체가 말한 초인이 되는것일까? 아니면 우리는 초인으로 가는 중간 단계인 그냥 인간일 뿐일까?
범용 문제 추론기인 이성은 이제 막 세상에 모습을 드러냈으니 강력하진 않지만 언젠가 이성이 진화를 주도해 나갈 수 있으리라 본다. 나는 특이점주의자일수도 ^^