좋은 디자인이란 무엇인가?

저는 그래픽 디자인 작업을 할때 좋은 디자인이란 무엇인가?라는 질문을 늘상 받고있습니다.
좋지않은 디자인이란 것은 한눈에 알아 볼 수있지만 좋은 디자인이라는것은 눈에띄지 않고, 거슬리지 않으며 자연스러운 디자인일 경우가 많기에
어떠한 것이 좋은 디자인인지에 대해서 설명하는것은 꽤나 힘든 일이라고 생각합니다.
하지만, 좋은 디자인을 하려면 어떻게 해야하는 것에 대해서는 비교적 설명하기가 쉽습니다.
우선 좋은 디자인을 하기위해서는 게슈탈트 심리학이라고 하는 것을 이해할 필요가 있습니다.
디자인이론에서 가장 기초가 되는, 한국어로 따지면 한글과도 같은 역할을 하는 심리학 이론입니다.

그렇다면, 게슈탈트 심리학이라고 하는 것은 무엇일까요?

게슈탈트 지각이론이라는 이름으로도 널리 알려져 있는 게슈탈트 심리학은 폭넓은 심리학적 현상, 프로세스, 그리고 응용분야의 틀을 제공하는 일반이론입니다.
일반적으로 형태이론,또는 형태 심리학이라고 불리는 이 게슈탈트 지각이론은 형(形)을 의미하는 독일어언 게슈탈트에서 비롯된 것으로
물리적 환경과 지각된 환경이 다르다는 것을 강조하고 인간이 물리적 환경을 어떻게 지각하는 가에 대해서 연구하는 심리학입니다.
(게슈탈트 심리학에 대해 더 자세히 알고 싶다면 M.베르트하이머(*주0)의 가현운동에서 부터 시작된 W.퀄터의 심리물리 동형론이나 K.코프카의 도형 잔효연구, K.레빈의 심리학적 장이론에 대해서 알아보시면 될 것 같습니다.)

————————————————————————–

*주0 맥스 베르트하이머(Max Wertheimer)
-게슈탈트 심리학의 창시자.(1880~1943)
프라하에서 테어나 프라하대학에서 심리학과 철학등을 공부했다. 운동시의 시각효과(가현현상)에 관한 논문을 발표했으며, 구성주의에 반대하는 입장을 취했다. 게슈탈트 심리학의 창시자이며 게슈탈트 심리학은 동료인 퀄터와 코프카, 레빈에의해 계승되었다.

————————————————————————–

게슈탈트 심리학을 이해하기 위해서는 우선 이 게슈탈트 심리학이라는 것이 어떠한 전제(가정)를 두고 진행되는지에 대해서 이해할 필요가 있습니다.

게슈탈트 심리학에서의 가정은 아래와 같이 분류됩니다.

1.지각은 실제와는 다르다
-전체는 전체를 구성하는 요소(부분)의 합이 아니며, 지각한 전체가 부분을 결정한다.(*주1)

-어떠한 형태(실루엣)을 인식할때 전체적인 지각으로 새로운 형태를 인식한다.(*주2)

-심리현상은 요소의 총화로는 설명할 수 없는 전체성을 갖는 동시에 구조화되어 있다.(*주3)

2.유기체는 경험을 조직하는데 물리적 환경에 내재되어 있지 않다.
-파이현상 : 시각적 자극을 빨리 연속적으로 제시할 때 생기는 일종의 운동착시로써, 자극요소로 의식을 환원할 수 있다고 한 생각이
잘못되었다는 의미를 함축하고 있다. 운동의 주관적 경험은 관찰자와 자극간의 역동적 상호작용이라는것이 게슈탈트학파의 주이론이다.
(짤방의 만화 참고.)

3.인간은 물리적 환경을 나름대로 조직하여 지각한 것에 반응한다. 동일한 사건, 현상도 어떻게 지각하여 해석하는가에 따라 수반되는 감정과 반응이 달라진다.

이상의 내용이 게슈탈트 심리학의 일반적인 내용입니다.

————————————————————————–

*주1 색채학이론에서도 나오는 병치혼합이나 면적대비,색상대비등이 게슈탈트 심리학에 기초하고 있음

*주2 짤방에 붙여놓은 만화의 에피소드 게슈탈트 심리학에서 말하는 형의 유사성으로 인해 검은 비닐봉지를 검은 고양이로 착각.

*주3 http://www2.donga.com/docs/magazine/shin/2008/08/01/200808010500006/image/200808010500006_3.jpg

사람의 검은 옆모습으로 인식할 것인가, 하얀 컵으로 인식할 것인가.

————————————————————————–

이러한 인간행동양식의 일반론에 입각한 지각심리학에 기초하고 있는 게슈탈트 이론은 특히나 예술계통에서 많이 받아들여지고 널리 사용되고 있는데, 게슈탈트 지각이론에 대해 W.퀄러는 이렇게 이야기 합니다.

“전체는 독립적으로 존재하는 부분의 합이 아니고, 각 부분에 전체와 관련하여 정의될 수 있는 특정한 기능, 또는 속성을 부여하는 전체가 있다.”

이러한 게슈탈트 심리학자들의 이론을 가장먼저 정립하기 시작한 M.베르트하이머의 가장 주요한 이론이 바로 “그룹핑사고”입니다.
예술계통에서 게슈탈트 심리학을 가장 많이 이용할때 사용되는 이 그룹핑사고는 다음과 같이 정리할 수 있습니다.

1.근접성
-구성요소는 구성요소 사이가 가까울 수록 함께 묶이려는 경향이 있다.

2.유사성
-몇몇 면에서 유사한 항목들은 함께 묶이려는 경향이 있다.

3.폐쇄성
-구성요소들이 일부 개체를 완성하려는 경향이 있으면 항목들은 함께 묶여진다.(*주4 중요. 폐쇄성의 법칙)

4.단순성
-항목들은 대칭성, 규칙성, 그리고 평활성(smoothness)에 따라서 단순한 형태로 조직될 것이다.

즉 게슈탈트 심리학은 인간이 어떠한 부분적 속성들을 지각을 할때 어떻게 지각을 함으로써 전체를 구성하여 의미를 받아들이는가에 대한 프로세스를 정립하고 있는 이론이기 때문에 게임이나 UI,웹사이트디자인등등 사용자의 피드백을 중요시하는 컨텐츠개발에 있어서 기초적 사용자 행동원리를 규정할 수 있는 기초디자인 이론으로써도 매우 중요한 이론입니다.

그렇다면, 게슈탈트 심리학이 인간의 지각이 어떠한 속성을 가지고 행해지는가에 대해서 이해해야 합니다.

게슈탈트 심리학에서의 지각의 속성은

1. 사람은 대상을 볼 때 그것의 전체, 즉 게슈탈트(形)를 보려고 하며, 이 전체는 총체적 성격을 가진다.(*주5)

2. 대상의 전체는 부분들의 총합 이상의 특성을 가진다.(*주6)

3. 좋은 형태는 사용자에게 잘 전달될 수 있다(*주7 중요. 프래그낸즈 법칙이 바로 이 내용입니다.)

4. 의미가 없거나, 추상적인 게슈탈트(形)의 시각영역에서는 관찰자가 지각되는 형태를 왜곡하려는 경향이 있다.(*주3 참고)

5. 관찰자는 형태를 식별하거나, 기술하거나, 구별하는 경우에 자신이 필요로 하는 사항들만을 보고 해석하며, 그밖의 사항은 무시하려는 경향이 있다.(*주8)

위와 같이 분류됩니다.

즉 게슈탈트 심리학을 이해한다는 것은 사람들의 행동원리나 사용자경험(UX)를 이해하기 위해 기초적으로 알아야만하는 기초 심리학이기도 하며,
좋은 디자인을 하기위해 필수적으로 반드시 이해하고 있어야하는 기초 이론이기도 합니다.
스타크래프트가 발매된지 10년이 지난 지금까지도 인기가 있고, 어째서 애플의 디자인이 인기가 있는지를 이해하기 위해서는 우선 게슈탈트 심리학이라는 것이 어떤 것인지에 대해 인지하고 있어야만 그들의 디자인 아이덴티티나 디자인 이론이 어떻게 전개되고 있는지를 이해할 수 있습니다.
한국어를 배우기위해서 우선 가장먼저 한글을 익히는 것과도 같은 의미인 것입니다.

동북아시아의 반도국가에서 10년전 국가기반산업 전체를 뜯어고칠정도로 커다란 영향력을 주었던 스타크래프트를 게슈탈트 심리학적으로 분석해보자면 많은 특징들을 발견할 수있습니다.

우선 유사성.

-동급의 유닛들은 서로 비슷한 크기를 가진다.
저글링, 마린, 질럿은 화면상에서 서로 비슷한 크기를 지니고 있습니다.
마찬가지로 히드라, 드라군, 시즈탱크. 레이스,스카우트,뮤탈리스크, 베틀크루저, 케리어, 가디언은 서로 동급의 유닛들끼리 비슷한 크기를 가지고있지요. 실제 설정상의 크기와는 상관없이 말입니다.
이러한 크기의 유사성은 각 유닛들간의 강함이나 약함, 그리고 전체 전장에서 군세가 구성되어있을때 얼마나 강해보이는지에 대해서 빠르게 인지시키기 때문에 실제 설정된 크기대로 만들었던 CnC나 다른 전략시뮬게임들과 차별화되어 밀리언셀러를 기록하게한 원동력이 되었습니다.
이 법칙은 후속작인 WarCraft3에도 적용이 되었으며 실제 설정에 근거해 제작이된 World of Warcraft에서 Undead종족의 메인홀인 블랙시타델(낙스라마스)가 WoW에서 구현되어있는 크기와 War3에 구현되어있는 크기가 얼마나 차이가 나는지를 생각해본다면 이해하기 쉬울듯 합니다.

-같은 종족은 베이스가 되는 각각의 컬러톤에의해 구분된다.
테란은 회색. 프로토스는 노란색, 저그는 갈색의 메인테마컬러가 있습니다. 이러한 동일종족간의 컬러톤으로 유사성을 만들어 화면에서 유닛들을 빠르게 구분할 수 있습니다.

단순성
-실제 컨트롤을 하여 움직일수 있는 오브젝트그래픽과 맵으로 구성되어있는 맵그래픽의 입체감의 차이.즉 규칙성과 평활성이 화면상에서 오브젝트와 맵을 구분할 수 있는 기준이 됩니다.

그리고 게슈탈트 지각이론에서의 1번항목인 형(形)인지에 대해서도 마찬가지로, 각 유닛들간에 실루엣이 같거나, 비슷한 오브젝트, 유닛 그래픽은 단 한가지도 없습니다. 모든 유닛과 오브젝트는 실루엣만으로도 그것이 무엇인지를 인지할 수 있습니다.

이와같이 하나의 재대로 만들어진 소프트웨어에 게슈탈트 심리학이 얼마나 크게 작용하는지에 대해서 이해한다면 이 게슈탈트 심리학이 단순한 심리학이 아닌, 그래픽 디자인이나 소프트웨어 디자인에서 얼마나 큰 영향력을 끼치고 있는지에 대해서 납득할 수 있을 것입니다.

정리하자면, 사람들이 위화감없이 자연스럽게 받아들이고, 원하는 대로 기능을 하는 좋은 디자인을 하기 위해서는 받아들이는 사람들이 어떻게 행동을 하는지에 대해서를 이해할 필요가 있을 것입니다.
그리고 그렇게 원하는 대로 정상적인 기능을 하는 자연스러운 디자인이야 말로 좋은 디자인 아닐까요?
좋은 디자인을 하기 위해서는 사람들이 어떤 디자인을 좋은 디자인이라고 인지하가에 대해서 알아야 할 필요가 있습니다.
한국어를 잘 하기 위해서는 우선 한글을 먼저 익혀야 하는 것 처럼 말이지요.
게슈탈트 심리학에 대해서 대략적인 설명으로 그쳤습니다만, 이 글로 게슈탈트 심리학이라는 것에 대해서 관심을 가지게 된다면 베르트하이머의 가현운동에서 부터 알아보시기 바랍니다. 의외로 우리의 일상생활에서 숱하게 보고 있는 일상화된 지각심리학의 기초입니다.

————————————————————————–
*주4 폐쇄성의 법칙
-폐쇄성의 법칙은 끊어지거나 불연속적인 윤곽선으로 된 형이 전체적인 형(원,사각형, 삼각형)으로 지각되는 것을 말한다.
타이포그라피나 그래픽 디자인에서 말하는 ‘레이아웃’이 바로 이 폐쇄성의 법칙에 기인하고 있다.

*주5 전체 실루엣이 왜곡되거나 바르지 않은(정돈되지 않은) 일러스트레이션을 볼때 사람들이 위화감을 느끼는 이유이기도 합니다.

*주6 눈이 아름다운 사람, 코가 잘 생긴사람, 입술이 매력적인 사람의 각 부분을 모아서 합성을 하면 오히려 이상한 얼굴이 나오는 것이 이 때문입니다. 그 사람의 눈이나 코가 예쁘다고 느끼는 것은 그 사람의 전체적 인상에서 부분의 특성이 구분되는 것이기 때문이지, 부분이 전체를 규정지을 수는 없으며 전체와 부분의 상호작용속에서 그 관계를 어떻게 지각하는가에 따라 각 부분이 합해진 전체는 때로 부분부분의 총합보다 더 큰 의미를 가질 수 있다는 의미이기도 합니다.

*주7 프래그낸즈의 법칙
-좋은 형태란 가장 단순하고 안정적인 구조를 말한다.
-형은 최소한의 에너지, 다른 형이나 바탕으로부터 구분될 수 있는 색이나 명암을 말한다.
-형 우수성(figure goodness)의 요소는 단순성, 규칙성, 대칭성, 기억의 용이성이다.
-좋은 형태란 단순, 기억하기 쉬운, 익숙한, 대칭적인, 균형있는, 비례적인 등이 포함된다.

*주8 스타크래프트의 UI.
-언제나 화면아래에 붙어있지만 플레이어는 필요한 때가 아니면 UI를 잘 인식하지 못한다. 그것은 실제 게임에서 사용되는 이미지와 UI의 이미지가 분리되어 있기 때문이며(형태가 다름) 플레이를 할때 화면의 영역을 구별해서 인식하기 때문에 플레이 화면을 인식할때는 UI가 지각영역에서 무시되며 UI를 보고 있을때에는 플레이 화면이 지각영역에서 무시된다.

————————————————————————–

아타리쇼크

1977년 미국에서 발매된 가정용 게임기 아타리 비디오 컴퓨터 시스템은 게임기에 내장되어 있던 게임 소프트의 프로그램 롬을 카트리지에서 제거하고 외부로부터 공급할 수 있도록 하여 폭발적인 인기를 얻었다. 또 아타리는 비디오 컴퓨터 시스템의 프로그램 사양을 공개하여 누구라도 자유롭게 게임을 개발, 판매할 수 있게 하였다.

그러나 게임 시장의 급격한 확대에 이끌려 많은 개발자가 참가한 게임 시장에는 질 낮은 게임이 넘쳐나 소비자들은 흥미를 잃어 갔다. 이에 따른 게임 개발사의 도산과 헐값 처분된 게임들이 시장에 흘러들어가 정가 라인이 붕괴되고 있었다. 이렇게 맞이한 1982년 크리스마스 판매 경쟁에서는 30억 달러의 시장 규모를 예측해서 유통하지만 아타리 비디오 컴퓨터 시스템 시장은 완전히 붕괴된 후였다. 당시 실제의 시장은 1억 달러 미만으로 끝나고 말았다.

이 결과 상당수의 재고를 떠안고 도산하는 소매점도 속출했다. 이후 미국판 패밀리 컴퓨터, NES가 발매될 때까지 미국 게임 시장은 침체기에 들어선다.

이것이 오늘날 말해지고 있는 아타리 쇼크의 개요이다. 덧붙여서 아타리 쇼크는 닉슨 쇼크에서 유래됐다고 한다.

출처 : Wikipedia.org

Mass Engine 설계의 기초(1)

Crytek의 CryEngine이나 EPIC의 Unreal엔진 등이 국내 유수의 게임회사들과의
계약을 체결하던 2002년 즈음, 많은 게임회사들이 자체 개발하던 3D엔진의 성능과,
엔진 구현에 들어간 비용을 유명 엔진과 비교하기 시작했다.

예전에는 3D엔진 하나로 코스닥에 상장이 가능하던 시절이 있었다.
이때에는 3D엔진이라는 것 자체가, 귀할 뿐 아니라, 상용으로 발매하기 보다는
회사의 기술력으로 사내에 보유되길 원했었기 때문이다.

하지만 게임브리오로 대변되는 염가 3D엔진 시장이 출현하면서, 3D엔진은 비싸다는
생각도 많이 개선되었을 뿐 아니라, 자본력이 풍부한 대기업들은 성능까지 출중한
해외의 유명한 엔진을 구입할 수 있게 되었기 때문에, 굳이 완벽하게 완성될지,
안될지도 모르는 위험부담이 큰 게임 엔진을 스스로 개발하기를 포기하기에 이르렀고
-실제로 게임 엔진 하나를 “완성”하는데는 4년 이상의 시간이 걸린다.-
현재 국내에는 아주 예전부터 여러 개의 엔진을 개발해봤던 베테랑 엔진 개발자를
보유한 회사에서나 혹은, 엔진을 구입할 만한 여력이 없는 일부 중소기업에서 캐쥬얼 게임을 만드는 정도로 사용할 목적 정도로만 엔진을 직접 개발하고 있다.

나는 KIST에서의 CAVE엔진, (주)사이오넥스의 스토리아엔진, (주)타프시스템의
가이아엔진, (주)엔틱스소프트의 be엔진 개발에 참여했고, 메인 엔진 디자인을
맡았던 경험을 가지고 있고, 현재 회사에서도 KKS엔진이라고 하는 쉐이더기반의
차세대 엔진을 5여년에 걸쳐 개발중이다.

이 컬럼에서는 Mass Engine을 디자인하는 업무에 종사중인 사람들이, 필수적으로
고민하게되는 이슈와, 망망대해와 같은 Mass Engine의 구현 범위에 대해 갈피를
잡지 못하는 엔진 디자이너들에게 일부나마 도움이 될만한 내용을 포함하려고 한다.

먼저 Mass Engine의 정의를 내리고 그 범위를 한정하는 일로부터 엔진 디자인을
시작한다. Mass Engine은 Renderer가 2D인지, 3D인지를 중심으로 엔진의 범위를
나누는 기존의 엔진 분류를 다시금 정렬하는 개념적 작업이 필요하다.

보통 Mass Engine을 개발하다보면, 그것이 2D기반의 엔진이든 3D기반의 엔진이든
어떤 공통의 모듈이 필요함을 발견하게 된다. 어쩌면 엔진을 거의 다 구현했을 때,
렌더러를 제외하면 추상화된 레이어에서는 두 엔진이 거의 동일한 형태로 디자인 되는
상황에 다다를 수도 있다.
이것은 엔진이라면 기본적으로 가져야 할 여러 동작들이 렌더링 하드웨어에는 상관없이
공통적으로 존재하기 때문이다. 이 컬럼에서도 렌더러를 제외한 엔진의 공통 분모를
찾아 이를 재 정리하는 과정을 보여주는 것을 목표로 하고 있다.

Mass Engine은 대부분 System call을 사용할 정도로 OS Layer에 깊숙히 관여하도록
구현하기 보다는 왠만하면 상위의 Standard Library들을 사용해서 구현하고,
표준라이브러리에 존재하지 않는 함수거나, 어떤 플랫폼에 특화된 기능을 사용하는
경우에는 특정한 기능을 Call 하는 함수를 한번 Wrapping해서 사용하게 된다.
이는 엔진의 Portabilility를 확보하는 장점이 있을 뿐 아니라, 디버깅 정보를 로깅할 때도
유용하게 사용된다. 여튼 Mass Engine의 이슈는 기능 함수 하나하나를 얼마나
얼마나 동작성을 좋게 할 것인지를 목표로 구현하는가가 아니라, 그 위에서 추상화된 기능을 얼마나 우아하게 모듈화하고, 사용이 편리하게 만드는가를 중심으로 구현해야한다.

Mass Engine의 모듈들을 구현하다 보면, 각 구현이 서로 동일한 레이어 상에 존재하는 것이 아니라, 각 구현된 모듈도 서로 상 하위의 계층구조를 가질 수 밖에 없음을 깨닫게
되는데, 그러므로 모듈을 설계할 때, 어떤 모듈이 가장 하위 구조에 속할 것인가를 먼저
생각해야 한다. 엔진의 범위를 설명할 때에도 이 계층 순서를 기준으로 설명을 하면
보다 이해가 쉬울 것이다.

Mass Engine이 반드시 가져야 할 첫번째 모듈은 기본자료구조(DS)이다. 세상에는 생각보다 많은 플랫폼과 하드웨어가 존재하며, 진정한 OSMU를 위해서는 겉보기등급의
이식 우월성이 아니라, 거의 원클릭으로 각 플랫폼에 필요한 바이너리 패키지들이
빌드 될 수 있어야 한다. 이렇게 하기 위해서는 STL 등의 표준 자료 구조 패키지를
너무 믿어서는 안된다. 일례로 한국에서 아주 유명한 WIPI-C라는 무선통신표준화플랫폼에서는 STL을 사용할 수 없다. (뿐만 아니라 통신망사업자에 따라, sprintf와 같은 표준 C함수 조차 지원하지 않는다.) 그러므로, 엔진을 디자인할 때 이 엔진을 구현하면서 어떤 자료 구조형을 중점적으로 사용하면서 디자인할 것인지,-예를 들어, vector인지, list인지…- 먼저 결정하고(이때에는 HW의 퍼포먼스 등이 영향을 끼친다.)
그 이후에 각각의 자료구조형들을 먼저 디자인한다. (세상에 존재하는 모든 자료구조형을 구현해야 하는 것이 아님에 유의, 욕심을 버릴 것) 이 자료구조형은 아주 밑바닥에
해당하는 레이어이므로, C++과 같은 객체지향 형태의 언어로 작성하기 보다는
C와 같은 Procedural한 언어로 작성한 후 그 위를 C++과 같은 OOP언어로 wrapping
하는 것이, 엔진 레이어의 랜덤한 위치에서 자유로이 이 자료구조형을 사용하기에 유리하다.

Mass Engine의 기본자료형이 완성되었다면, 다음은 메모리관리 모듈을 만들 차례이다.
모든 디바이스에서 같은 비트의 메모리 얼로케이션이 일어나지 않을 뿐 아니라,
메모리를 Static으로 잡아놓고, 혹은 런타임에 Dynamic Allocation을 하지 않는다면
성능이 떨어지는 많은 OS에서 메모리 단편화 현상을 직접 제어할 수 있다. 또,
점유된 메모리 Segment에 디버깅을 위한 특정 정보를 포함하게 하여 디버깅이 용이
해질 수도 있다. 메모리 메니져를 만들 때에는 대부분 그렇듯 First-fit, Best-fit 아니면
Worst-fit을 사용하겠지만, 어떤 알고리즘이 됐든 메모리정보를 가지는 노드의 크기가
너무 커지지 않게 주의 해야 한다는 점과, 정작 Dynamic Allcation을 통제하기 위해서
메모리 관리자를 만들면서 메모리 관리자 내부에서는 Dynamic Allocation이 일어나는
일이 생겨서는 안된다는 점이다. 일반적으로는 Node Pool을 만들어 메모리관리자
내부에서도 동적할당이 일어나지 않도록 만든다. 그리고 마지막으로 주의해야 할 점은
현재 점유한 메모리의 할당 해제 혹은 새로운 메모리 블럭의 할당을 위해서는
노드 검색이 필요한데, 이 노드 검색에 너무 많은 부하가 걸리도록 알고리즘을
구성해서는 안된다는 것이다.
메모리 얼로케이션은 엔진 내부 및 전체 어플리케이션에 걸쳐 생각보다 많은 빈도로
발생하기 때문에 한번의 검색이 빠르게 이루어지지만, 할당된 구조를 유지하는데
많은 부하가 걸리게 작성하기 보다는, 한번의 검색은 빠르지 않더라도 할당된 구조를
단순하게 관리하도록 하는 편이 유리하다. 예를 들어, 할당된 메모리 블럭들의 정보를
유지하기 위해서 트리구조 등을 사용하는 것 보다는, 싱글 링크드 리스트를 이용하는
쪽이 좋다.

- 작성중 -

by HKP

WWBD – What would blizzard do?

<왜 게임회사들은 후진 게임들을 만들까?>

이 질문은 나를 오랫동안 당혹스럽게 만들었고 늦은 밤까지 잠들지 못하게했다. 나는 이 일을 하면서 이걸 게임이라고 출시했다는 걸 도저히 믿을 수 없는 게임들을 보며 오랜 시간동안 생각했다. 나를 순진하다고 해도 좋지만, 정말 어떻게 이런 일이 생기는지는 모르겠다. 그리고 나는 어딘가에 왜 다음과 같은 글이 올라오지를 않는지도 궁금하다.

게임개발자 1 : 우리가 도대체 여기서 뭘 하는지를 모르겠어. 우리가 만든 이 게임을 플레이 하느니 차라리 내가 토한걸 먹겠네.

게임개발자 2 : 웃기지마. 우리 게임을 하느니 차라리 내가 너 토한걸 먹겠어. 우린 정말 족같아.

게임개발자 1 : 우리 그냥 이 쓰레기 같은 게임을 취소하고 이런 족 같은 게임을 만들려고 했던것에 대해서 공개적으로 사과를 하자구.

게임개발자 2 : 그래, 그러면 차라리 회사를 접자. 우리 게임 같은 것으로는 도저히 사람들한테 돈 받고 판다는 생각을 하는 거 자체가 잘못된거야.

많은 복잡 다양한 이유가 있다는 것을 안다. 게임을 만드는게 어렵다는 것도 안다. 하지만 일부 회사들은 계속해서 잘 해나가고 있다 – 번지나 바이오웨어, 불프로그 또는 아주 최고의 경우지만 블리저드를 볼 때에도. 따라서 불가능하기만 한 것은 아니다.

음, 아직 마지막 수표도 받지 못했거니와, 프로답지도 않게 여기서 블리저드를 신격화 하려고 하는 것은 아니다. 하지만 최근 3개의 게임들(워크래프트2, 디아블로, 스타크래프트로 이어지는 의심의 여지가 없는 명작들)은 명백하게 뭔가 제대로 되었고, 이번호의 커버스토리인 디아블로2를 보면 이번에도 그들은 뭔가 또 한 건을 한 걸로 보인다.

이런 것들은 내가 블리저드에서 늦은 밤 차를 끌고 집으로 오면서 내가 만약 게임 회사를 차렸다면 모든 직원들에게 `WWBD?`라고 쓰여있는 팔찌를 채워야 겠다고 생각하게 했다.

“What Would Blizzard Do?(블리저드는 뭘 할까?)”

그리고 이것은 내게 이런 해답들을 생각하게 만들어 주었다.

게이머를 고용해라 : 게임을 만드는데에는 재능이 있는 개발자가 필요할 것이다. 그리고 “게임을 만들고 있다”라는 것이 어떤 것인지 이해하는 개발자도 필요하다. 이러한 조건을 가진 최적의 사람은 바로 게이머들이다. 모든 팀원들이 그들이 만들려고 하는 게임에 대해서 완벽하게 이해하고 있고, 왜 만들려고 하는지를 알아야 한다. 만약 그렇지 못한 사람이 있거나 신념을 갖지 못하거나 게임이 지루하다고 생각하는 사람이 있다면,

그 팀은 문제를 갖고 있는 것이다.

모든 팀원들은 너희가 만드는 게임의 가장 열광적인 팬이어야 하고 가장 냉정한 평론가가 되어야 한다.

자존심을 버려라 : 11시가 넘은 시각 블리저드 노스(Blizzard North)에서 나는 도대체 누가 디아블로2를 만들때 어떤 일을 했는지 알 수가 없었다. 왜냐하면 모든 사람들이 그 게임(디아블로2)의 모든 측면에 대해서 이야기 했으며, 누구도 어떤 것을 자신의 공(功)으로 돌리는 사람이 없었다.

그래픽 아티스트는 프로그램의 코드에 대해서 이야기하고, 프로그래머는 그래픽에 대해서 이야기했다.

누구도 자신이 잘났다고 하는 사람은 없었다. 나는 어떤 사람이 그 게임의 전체 코드를 짰거나, 모든 레벨을 디자인했거나, 모든 에니메이션을 그렸거나, 모든 스토리를 쓴 경우가 아니라면 그 사람의 이름이 타이틀 앞에 와서는 안된다고 생각한다. (역주: 제프 그린의 생각은 시드마이어 같은 개발자의 이름이 게임 타이틀의 앞에 붙는 것을 말하는 듯함) 게임은 영화처럼 집단이 노력해서 만들어낸 결과이다. 모든 사람에게 말 할 권한을 주지 않는다면 도움을 얻을 수 없을 뿐더러, 좋은 게임을 만들 수도 없다. 한 사람에게 지나치게 많은 권한을 준다면, 그 권한을 가진 사람에게 치여서 그만두게 될 것이다. (역주: 관리자나 기획 팀장 등 편중된 힘의 구조는 서로의 파워게임, 정치를 하게 되고 이 것에 의해서 밀려나게 될 것이라는 뜻, 원문은 ‘and you end up with DOMINION’.)

기술에 초점을 맞추지 마라 : 밥벌레 프로그래머(역자주:오직 코딩을 위해서 게임 개발을 선택한 개발자를 의미)나 디자이너에게 자주 듣는 말 중의 하나는 그들의 게임이 빗방울이 떨어지는 것을 구현했고 그림자가 렌더링 된다면서 자신들의 게임이 얼마나 훌륭한지에 대해서 이야기하는 것이다. 그때마다 나는 그들의 대가리를 바이스에 꽂고 2~3눈금을 돌린 다음 귀꾸녕에다가 이런 말을 해주고 싶다. “아무도 그런 거에 신경 안써!!” 디아블로2는 2D에 640×480의 해상 도로 만들어졌지만 최소한 주요 판매상과 웹사이트에서 올해의 게임의 후보가 될 것이다. 아니라면 내가 한달동안 오토바이를 타고 다니면서 세탁 배달일을 하겠다.

결국, 모든 것은 게임의 내용이다. 그걸로 끝이다.

비가 오는지에 신경을 쓰는 사람이라면 그건 네 엄마가 아니면 다른 프로그래머들일 것이다. 그 외에는 단지 좋은 게임을 바랄 뿐이다. (역주: 이 내용도 제프 그린의 유머인데, 비가 오면 걱정하는 사람, 어머니는 자식의 옷이 젖을까봐 비 오는 것에 신경을 쓴다는 뜻임)

다른 회사들의 게임을 해라 : 어찌 되었든 너희 게임이 정말 훌륭하다고 생각하든 누군가 다른 겜을 제작하고 있든 이미 출시했든 그런 것들은 문제가 되지 않는다.

모든 게임을 볼 필요가 있고
모든 게임을 플레이 해야하며 항상 오픈마인드를 유지해야 한다.

타이베리안 선을 기억하는가? 타이베리안 선은 Westwood의 직원들이 그 게임을 작업하는 동안 한번도 RTS 게임을 해본 적이 없는 것 처럼 보인다. 디아블로2는 그들이 게을렀다거나 무능력해서 게임이 연기되었던 것이 아니다. 이 것은 정확하게 상반된다. 블리저드 노스는 무엇이 좋은 것이고 그들의 게임이 더 나아지기 위해서는 무엇이 필요한 지를 알기 때문이다. 경쟁이란 것은 좋은 것이다.

크리스마스 따위는 잊어버려라 : 크리스마스에 맞추기 위해서 퀄리티를 희생해서 게임을 기한 내에 선적 했다면, 늬들은 멍청이다. 그래, 나도 12월이 되면 사람들이 게임을 많이 산다는 것 쯤은 안다. 하지만 많은 사람들이 일년 내내 게임을 사는 것도 사실이다. 디아블로 1편은 1996년의 크리스마스 시장을 타지 않았다. 더 이상 뭘 생각하는가? 디아블로는 3년이나 지났지만 `아직도` 베스트 셀러 리스트에 있다.

사람들은 `언제나` 좋은 게임을 원한다.

너희들은 오랜 기간동안 보장된 퀄리티와 명성을 짧은 기간의 욕심으로 포기하려고 하는가? 그렇다면, 대형마트 한켠의 덤핑 게임 바구니에서 보자.

——————————————————————————
원문 : Jeff Green (senior editor of CGW) 번역 : 김종득, 퇴고 : 채승철, 이상진, 박홍관

+–+

 

3DGED(David H. Eberly) Errata

3D Game Engine Design 에 있는, 쿼터니언->행렬 변환 공식은 아래와 같다.

1-2(y^2+z^2)
2(xy+wz)
2(xz-wy)

2(xy-wz)
1-2(x^2+z^2)
2(yz+wx)

2(xz+wy)
2(yz-wx)
1-2(x^2+y^2)

Gamasutra 와 같은 사이트에도 동일한 내용의 글을 발견할 수 있었다. 하지만, 실제로 계산해 보면 아래의 결과를 얻을 수 있다.

1-2(y^2+z^2)
2(xy-wz)
2(xz+wy)

2(xy+wz)
1-2(x^2+z^2)
2(yz-wx)

2(xz-wy)
2(yz+wx)
1-2(x^2+y^2)

이것은 LHS 와 RHS 의 문제로 볼 수 있는데, 3D Game Engine Design 이 RHS 를 가정하고 있다면, 서적의 오류로 생각할 수 있다. 엔진에서 사용되고 있는 방식은 위쪽으로, 엔진이 RHS 를 가정하고 있는 상황에서 보면, 잘못된 것임을 알 수 있다.

* 주의 사항
불행히도 3DS Max는 LHS 시스템임에도, 아래쪽의 공식을 따르는 관계로 export 시에 w에 -1을 곱해줘야 한다. DX 는 제대로 LHS Matrix를 계산해 준다.

OpenKODE에 대하여

1. KHRONOS Group이란?

여러분은 Khronos Group에 대해서 들어 본 적이 있습니까? Khronos Group은 2000년 1월에 3Dlabs, ATI, Intel, NVIDIA, SUN등의 회사들이 주축이 되어 만든 컨소시엄입니다. 2009년 현재에는 이름만 대면 누구나 알 수 있는 세계적인 기업들은 거의 대부분 참여하고 있습니다. 단말기 제조사(삼성, 노키아, 모토로라, 소니 에릭슨, LG 등)과 칩 제조사(Intel, AMD, ARM 등), 유명 통신사, 잘 나가는 IT기업(Apple, Google 등)까지 Mobile 시장에 조금이라도 관여하고 있는 기업들은 모조리 포함되어 있습니다.

크로노스의 창립 목표를 한줄로 요약하자면, ‘다양한 종류의 mobile기기에 최적화된 하나의 공개 표준 API를 만들어 높은 수준의 미디어 출력이 가능하게 해 주는 것’이라고 할 수 있습니다. 여기서의 공개 표준 API는 모두 무료(Royalty Free)로 제공된다는 점이 특징입니다. 따라서 어떠한 기업이나 개인도 마음껏 사용이 가능합니다.

크로노스는 이 표준 API를 사용하여 현재 모바일 시장 진입의 큰 문제점인 모바일 미디어의 단편화 현상(Mobile Media Fragmentation)을 극복하고자 합니다. 모바일 미디어의 단편화 현상이란, 각 단말기마다 다른 OS를 사용하기 때문에 생기는 문제입니다. 현재 ISV(Independent Software Vendor)들이 모바일 시장에 제품을 출시하기 위해서는 한 개의 타이틀을 수많은 OS에 맞게끔 porting하는 무의미한 작업을 반복해야 합니다. 이미 시장에 나와 있는 OS만 해도 심비안, Brew, 윈도우 모바일, MAC OS X, WIPI, Android, Limo, Java MIDP 등 엄청난 숫자입니다. 따라서 특정 플랫폼에 종속되지 않는 표준 API가 존재한다면 각 OS별로 같은 프로그램을 다시 만들 필요 없이, 디바이스에 구애받지 않고 손쉽게 프로그램을 작성할 수 있습니다.

또한 Handheld Device가 가지는 그래픽의 한계를 극복하고 더 높은 수준의 서비스를 제공하자는 목표도 가지고 있습니다. 지금까지의 휴대폰이 저수준의 그래픽 가속까지만 지원할 수 있었다면, 앞으로는 휴대폰에서도 PC와 같은 수준의 하드웨어 그래픽 가속을 가능하게 하겠다는 것입니다. 이는 특히 게임 분야에 많은 영향을 끼칠 것이고, Media contents, 웹 서비스 등에도 많은 변화가 있을 것입니다. 크로노스는 이 같은 일들이 가능하도록 휴대기기 하드웨어의 performance를 최대한으로 이끌어 낼 수 있는 API를 제작하고 있습니다.

따라서 크로노스가 기대하는 것은, 만일 이러한 표준 API가 성공적으로 정착된다면 ISV와 하드웨어 제조사 모두가 Win-Win할 수 있다는 점입니다. 크로노스에서는 이를 Media Ecosystem이라고 표현합니다. 소프트웨어 제작의 진입장벽이 낮아지면 소프트웨어 제조사가 이익이고, 사용자는 양질의 컨텐츠를 더 쉽게 제공받을 수 있으며, 양질의 컨텐츠가 늘어나면 이는 곧 하드웨어(모바일 단말기)의 판매를 증가시킬 것입니다. (모든 일들이 잘 풀린다는 가정 하에)

2. Khronos가 개발중인 API

크로노스의 Mobile API는 3D그래픽용 API인 OpenGL|ES, Vector 2D그래픽용 API인 OpenVG, Video같은 Streaming Media용 OpenMAX, 사운드를 담당하는 API인 OpenSL|ES의 총 4가지 API로 구성되어 있습니다. 여기에 이 4 종류의 API를 추상화시킨 인터페이스인 EGL이 있고, 이 모든 API는 OS Abstraction API인 OpenKODE로 Wrapping됩니다. 따라서 소프트웨어를 제작하는 입장에서는 OpenKODE로 다양한 Open계열의 미디어 API를 사용하여 프로그램을 작성할 경우, 각 OS의 이식성에 대해서는 신경쓰지 않고 만들 수 있습니다.

OpenKODE란 위에서 설명한 것처럼 2D그래픽, 3D그래픽, 사운드 라이브러리들을 Wrapping하여 OS에 독립적으로 추상화시킨 API입니다. OpenKODE의 가장 큰 특징은 C언어의 구조를 그대로 가져왔다는 점입니다. 흔히 ANSI-C에서 사용하는 문법을 그대로 쓸 수 있습니다만, C표준 라이브러리의 함수들을 그대로 사용할 수는 없습니다. (printf나 fopen같은) 대신에 OpenKODE는 기본형 데이터 타입과 C함수들을 KD라는 Prefix를 붙여서 바꿔 놓았습니다. 그래서 Thread함수, Math함수, Timer함수, Network함수, 입/출력 함수, String함수 등 많은 기존의 함수들 이름 앞에 KD만 붙이면 거의 같은 문법으로 사용이 가능합니다.

이와 같은 특징의 가장 큰 장점이라면, 역시 C라는 언어가 프로그래머들에게 상당히 친숙한 언어이기 때문에 진입 장벽이 그만큼 낮아진다는 점입니다. 또한 자바 같은 VM을 사용하는 언어에 비해 Native한 가속을 지원하기 때문에 속도가 훨씬 빠르고, PC에서 C로 만든 프로그램을 더 쉽게 모바일 환경으로 이식할 수 있다는 점도 장점입니다.

3. 결론

현재 크로노스가 제작중인 대부분의 API들은 아직 완전히 릴리즈되지 않고 적합성 테스트(Conformance Test)를 거치는 중입니다. OpenKODE역시 아직 OpenGL|ES 2.0은 지원하지 않고 있습니다. (2008년 OpenKODE 백서를 참조했습니다. 2009년 2월에 1.0.2 버전이 나왔는데, 현재는 어떤지 잘 모르겠군요)

따라서 크로노스의 표준이 아직까지는 모두 확정되지 않았지만, 표준이 확정되고 크로노스에서 의도한 대로 모든 OS에서의 이식성이 확보된다면, 앞으로 근 몇 년 안에 Mobile시장에 큰 변화를 불러오리라고 생각합니다. 이는 곧 전 세계의 휴대기기 사용자들을 대상으로 한 어마어마한 새로운 시장이 열린다는 이야기와 같습니다. 우리 VisualShower는 항상 이러한 변화를 내다보고 한 발 앞서서 준비하여 큰 기회를 잡아야 할 것입니다.

이와타 사토시

닌텐도의 이와타 사토시 사장이 2004년도 이전 닌텐도DS등이 발매되면서
재기에 성공하기 직전에 했었던 강연이 있다.

그 강연에서 했던 이 이야기는, 현재의 게임 시장에도 너무나 잘 들어맞는 이야기다.
닌텐도는 이와 같이 선견지명이 있는 훌륭한 리더를 앞세워 세계 공략에
성공한 것 같다.

한국 닌텐도 사장님의 인터뷰 내용 중에,
“세계에서 게임 싫어하는 나라는 없습니다.”라는 말이 문득 떠오른다.

닌텐도의 이와타 사토시 사장 :

“게임이 막히고 있기 때문입니다.
그래픽을 진화시켜, 기능을 복잡하게 해 나가면 좋다고 하는 「성공의 황금 법칙」이 붕괴했습니다.최대의 문제는, 보다 복잡해 볼륨이 있는 게임을 요구하는 코어 유저와 게임 지식을 가지지 않는 라이트 유저의 양쪽 모두를 만족시키지 않으면 안 된다.크리에이터가 100배 고생하고 있어도, 100배 팔리기는 커녕, 현상 유지조차도 어렵다고 하는 상황으로, 시간과 에너지를 낭비하는 종래의 노선에서는, 게임의 미래는 없는 것은 분명합니다.닌텐도는 최근 「보수적」이라고「얌전하다」라고말해지고 있으므로, 새로운 놀이를 제안해 온 닌텐도의 존재 가치를 보여 주고 싶네요.”

존 카막 이야기

* 아래의 글은 인터넷 어딘가에 떠돌아 다니던 기사입니다.

John Romero와 John Carmack은 게임 산업이 만들어낸 난세의 영웅이자 수많은 광신도들을 배출한 게임의 신이기도 합니다. Carmack과 Romero 는 오픈소스 이야기에서도 잠깐 언급한적이 있었지요. 이름도 기억안난다던 그 친구가 John Romero입니다.

평범한 것 같지 않은 이 두사람의 이야기를 읽으면서 느낀 건 뜻밖에도 “에이… 나같은 평범한 놈이 바라보기엔 너무 높은 산이다”라는 위화감이 아니라 오히려 신바람이었습니다. 왠지 모를 삶의 의욕이랄까, 지금 주어진 일을 더 열심히 하고 싶은… 사그러들던 열정에 불을 지폈다고나 할까…

두 사람은 이런 공통점이 있지요. 자기가 좋아서 하는일… 어떤 어려움이 닥치더라도 해낸다는 단순 명제.

하지만 다른 점도 있습니다. John Romero가 자기가 좋아 하는 일이라 주어진 일을 당연히 잘하는 거라면, John Carmack은 천재성까지 타고났다는 거.

이전에도 밝혔지만 전 John Carmack을 참 좋아합니다. John Romero를 한마디로 fun-loving gamer라고 한다면 John Carmack은 tech God 라고 해야 할 겁니다. Carmack은 외부세계의 간섭을 언제든지 차단하고 자기만의 세계에서 코딩을 하는 어찌보면 자폐증이 아닐까 의심스러울 정도로 기이한 사람입니다.
한번은 동료 한명이 Carmack의 집중력을 테스트해보느라 음란 비디오를 하나 빌려와서 사무실에서 크게 틀었다고 합니다. 다른 동료들은 이상한 소리가 들리자마자 돌아보는데 Carmack은 여전히 모니터에 머리를 파묻고 있더라지요. 이번엔 “이래도 안쳐다볼래?”라는 오기로 볼륨을 최고로 높였더니, 귀가 찢어져라 터져나오는 신음소리에 살짝 머리를 돌린 Carmack이 한다는 말…

“mmm…”

다시 모니터로 머리를 돌리더랍니다. 저 “흐…음….”하는 건 이 친구 말버릇이라고 하는데요. 매 문장을 끝낼때마다 약간의 코맹맹이 소리로 “으…음….” 한다고 하네요. 책에도 이때문에 벌어지는 재미있는 에피소드가 꽤나 많이 나옵니다

Wolfenstein 3D, Doom, Doom II, Quake, Quake 2, Quake III Arena… 그리고 올해 하반기에 발표될 최고의 기대작 Doom III까지…

각 게임을 낼때마다 Carmack은 3차원 게임의 표준을 제시했습니다. 조물주가 그랬듯이, Carmack은 3차원 가상 공간이라는 누구도 상상치 못할 세계를 인류에 선물한 친구입니다. 모두가 Carmack이 다음번엔 어떤 마술을 보여줄까 기다리게 만듭니다. 그래픽카드 제조회사들은 Carmack의 인증을 받으려고 줄을 서야 하구요. 그가 만드는 3차원 가상 세계는 그렇게 점점 더 현실 세계와 닮아갑니다. Doom III 의 스크린샷을 보면, 이제 가상 이라는 말을 떼어내야하지 않을까라는 두려움마저 느끼게 합니다.

id Software는 게임 제작에 필요한 각 분야의 최고수들이 모여 만든 절대 경지의 게임 제작업체지요. 재밌는건 이 친구들이 돈 욕심이 별로 없다는 겁니다. 워낙 떼돈을 벌기 때문에 더 이상의 욕심은 진짜 욕심이라는 걸 알기 때문일지도 모릅니다. 그래서 IPO를 한다거나 하는 건 헛소리에 지나지 않지요. 수없이 많은 회사들이 (심지어 Bill Gates도) 군침을 흘리고 천문학적 숫자를 들이밀었지만, 콧방귀 뀌는 소리만 들었습니다.

Carmack의 지론은….

규모가 작은 회사여야 한다. 프로그래밍은 나 혼자로도 된다. 각 분야에서 최고 역량을 가진 놈 하나씩만 있으면 된다. 그보다 더 많아지면 의사소통이나 대인 관계 등의 overhead만 생길 뿐이다.

저런걸 overhead (여기서는 쓸데없는 낭비라는 그림)라고 여길 정도라면 말다했지요. 거의 모든 직원이 Ferrari를 몰고 다닙니다. Carmack은 Ferrari가 4대였는데 그 중 한대는 Quake Deathmatch 컨테스트에서 1위를 차지했던 Thresh란 친구에게 줬다지요. 부상으로…

Carmack은 게임을 발표하면 그 게임에 사용된 엔진은 이미 구닥다리라고 생각할 정도로 속도가 빠른 사람입니다. 심지어 Ferrari도 개조를 해서 Turbo 엔진을 달고 다니는 또라이지요. 저도 차는 잘 모릅니다만… Ferarri는 튜닝을 할게 없는 차라고 하네요. 그만큼 최적화가 돼 나온 차라서… 미국에 거의 딱 한명 있을까 말까한 전문가에게 튜닝을 맡겨 항상 최고 속도의 두배~세배를 내도록 터보 엔진을 단다고 합니다.

——————————————————————————
존카막 이야기 중
“규모가 작은 회사여야 한다.” 라는 말은 우리 회사의 창립 정신이기도 합니다.
소수의 엘리트만을 위한 회사 Fully Optimized VisualShower.

LHS와 RHS
(Left-hand system, Right-hand system)

우선 LHS와 RHS는 Vector의 Cross Product가 어느쪽으로 정의되는가에 따라 결정된다.

RH 시스템에서의 매트릭스 누적은 다음과 같이 된다

V’ = Mc x Mb x Ma x V

RH시스템에서의 쿼터니언 누적 역시 다음과 같다

V’ = Qc x Qb x Qa x V

LHS의 경우는 다음과 같다

V’ = V x Ma x Mb x Mc

따라서 쿼터니언의 누적 *= 이 제대로 되기 위해서는 RH 시스템이지만
다음과 같이 꼬아주어야 한다.

Qa = Qa * Qb 가 아니라
Qa = Qb * Qa 다.

정하기 나름~!

라이브러리언에 대해서

내가 프로가 된 지 얼마 되지 않았을 즈음 ‘술형님(TM)’께서 해주신 말씀 중에 재미있는 것이 있어서, 소개해볼까 한다.

바로 EA에 있는 라이브러리언에 대한 내용이다.
라이브러리언이라고 하면, 한국어로 이야기 하자면 도서관 사서.. 정도로 번역될 수 있겠지만, 프로그래밍 특히, EA같은 게임 회사에 ‘사서’가 왠 말인가? (회사 도서관이 방대한가?)

사실 여기서 이야기 하는 ‘사서’라 함은 도서관에서의 그 뜻이 아니다.

프로그래밍을 해본 경험이 있는 사람들이라면 당연히 ‘Library’에 대해서 이해하고 있을 것이다. 바로 이 라이브러리로 부터 ‘Librarian’이라는 단어가 파생된 것이다.

좀 화제를 돌려서,

한국 프로그래밍 여건의 특징이라 함은 뭐..
두가지 뿐 아니겠는가.

‘일정’ 과 ‘압박’

일정과 압박이라는 단어와 반대되는 것도 있다. 바로 ‘설계’와 ‘테스트’ 이다.

일반적으로 한국에서의 SW는 ‘안정성’과 ‘완성도’로 평가 되는 것이 아니라,
‘돌아가는가?’ 와 ‘내일 있을 데모를 마칠수 있는가?’로 평가 된다.

아무도 소스코드의 품질이나, 내적인 완성도에 대해서(예를 들어 아름다운 노테이션이라던가)는 관심이 없다. 보통 사장님들은 내일 데모만을 원하고, 펀딩을 원하고, 한 몫 단단히 챙겨서 손 털기를 원할 뿐이다. 소스코드의 아름다움 따위야 그들의 관심사가 아니다.

그래서,
EA에서의 라이브러리언은 한국 같은 프로그래밍 여건에서는 정말 갖추어지기가 쉽지 않은 재미있는 Role이다.

일단, 라이브러리언이 있는 회사에서는
어떤 프로그램 코드를 작성하는 도중에 새로운 기능을 추가해야 하거나, 새로운 모듈을
개발해야 할 상황이 닥치게 되면(거의 매 순간 닥치지 않는가?) 프로그래머는 그냥 알아서 소스를 소스세이프나 CVS에서 꺼내 내키는 대로 코드를 써대는 게 아니라,

라이브러리언에게 멘트를 날린다.

“내가 지금 이런 기능을 구현하려는데, 이게 지금 회사의 라이브러리 풀에 있나요?” 라고…

그럼 라이브러리언은 Yes or No의 대답을 해주는데,

그냥 그 대답으로 끝나는게 아니라,
만일 대답이 Yes라면 해당 함수를 돌려주며,
만약 대답이 No 라면,
라이브러리언은 그 새로운 ‘모듈 혹은 기능’을 구현함에 있어서 그 함수가 갖추었으면 할
범용적인 틀을 제시한다. 그러면 프로그래머는 그 Frame을 받아서
(꼭 함수의 프로토타입을 의미하는 건 아니다.) 내부를 구현하고, 그 함수를 사용한다.

성공적으로 해당 함수가 사용되게 되면, 라이브러리언은 새롭게 구현된 그 함수를 수거하게 되는데 이렇게 수거된 함수는 다시 라이브러리언의 Source code purifing을 거쳐 깨끗한 노테이션의 상태로 회사의 라이브러리 풀에 적재 된다.

절대 불필요한 함수들이 여기 저기서 재 작성되는 낭비도 없고, 완성된 함수들이 말 그대로 “진정으로 완성..” 되지 않고, 적당히 동작만 하는 상태로 남아 있지도 않는다.

또, 라이브러리풀에 아무나 접근해서 그냥 단순하게 현재 쓰기 편한대로, 혹은 원하는 대로 코드를 헤집어놓을 수도 없다. 라이브러리 풀에 적재된 라이브러리는 완벽한 상태로 보존된다. (적어도 라이브러리언의 입장에서는 확실하다.)

내가 예전에 다녔던 직장에서는
하나의 3D엔진 속에 Matrix x Vector 연산이 4개가 존재했다.

내가 처음 이 이야기를 들은지 벌써 10년이 다 되어간다. EA는 이 10년간 라이브러리를
쌓았을테고(짧게 봐도), 내가 다녔던 그 직장은 10년간 만들었던 모든 엔진을 폐기처분하고, 언리얼엔진으로 갈아탔다.

by HKPark