내가 추구하는, 비효율적이고 불합리한 게임개발.

처음 프로그래밍을 공부했을때 나의 관심사는 "빠른 렌더링" 혹은 "최적화된 알고리즘" 이였다. 군더더기 없고 빠른 알고리즘이야말로 프로그래머가 추구해야할 가치라고 생각했다. 하지만 실무에서 게임을 개발하면서 "궁극의 최적화된 테크닉" 은 실제로 쓸일이 별로 없었다. 오히려 변화에 대응하기 쉽고, 유지보수가 쉬운 코딩테크닉이 더 실용적이였다.

 그래서 나는 나의 가치관을 바꾸었다. "고성능의 코드" 보다는 "유지보수가 쉽고, 컨텐츠변경이 쉬운" 여러가지 프로그래밍 기법에 대해서 관심을 가졌다. 모듈화,디자인패턴,스크립트, 데이트드라이븐, 컴포넌트설계 와 같은것들이다. 어떻게 하면 "빠르고,합리적이고,효율적이고,유지보수가쉬운" 형태로 게임을 개발할수 있을지 고민했다. 물론, 나만 그런것은 아니다. 대다수 프로그래머가 여러가지 방법론을 연구하면서, 어떻게하면 게임개발을 합리적이고 효율적으로 할수 있을지 방법을 찾았다.

 그렇게 3~4년의 시간이 흘렀다. 나는 또다시 생각이 변했다. 이제 내가 추구하는것은 "고성능의 알고리즘" 도 아니고, "유지보수가 쉽고, 합리적인" 프로그래밍 기법도 아니다. 내가 추구하는것은 "불합리하고, 비효율적이고, 낭비가 심한, 그야말로 형편없는 프로그래밍 방법" 이다. 내가 생각을 바꾼데에는 "효율" 이라는 단어의 정의(#define) 가 사람마다 천차만별이라는것을 인지하고나서 부터이다.

진실은 단지 관점의 문제일 뿐이다. -프라이스 대위, 모던 워페어3-

프라이스 대위의 명언을 바꾸어보면 다음과 같다.

효율은 단지 관점의 문제일 뿐이다.

1, 어떤 이상한 회사의 어처구니 없는 그래픽작업

 2008년쯤의 일이다. 그래픽디자이너와 이야기를 하게 되었는데, 자신이 근무했었던 회사 체계가 그야말로 개판이라면서 이런저런 욕을 하는게 아닌가? 고생하는 입장에서 좋은소리가 나올리 없는것이 게임회사이고, 불평은 어느 누구나 가질만 한것이지만, 하도 독특한 사례라서 내 기억에서 지워지지 않는 사례이다.

 우리회사 체계가 정말로 개판이다. 원래 디자인 컨셉이 확실하게 나오고, 그 다음에 원화작업이 들어가고 나서, 게임방향을 결정한 다음에, 모델링으로 작업이 넘어와야 하는거 아닌가? 그런데 이건, 뭐 아무것도 없이 그냥 막 작업하라는거야, 기획서고 뭐고 암것도 없이, 그냥 막 작업을 하면 기획서가 나중에 나오는데, 기획에 안맞는 작업물은 그냥 다 버리는거야, 나참 어이가 없어서, 기획서 작업을 하고, 모델링을 하는게 아니라, 이건뭐 모델링을 먼저하고, 기획을 나중에 하고 있어, 그러니까 백날 작업해봐야 맨날 엎고 다시만들고 엉망 진창이지.



 일단 오해를 줄이기 위해서 결과를 미리 당겨서 말해주자면, 이 회사는 "매우 합리적인 판단" 을 했다는점을 미리 알려주고 싶다. 뭐 어쨋든 그건 나중에 변명할일이고, 지금 당장의 관점에서 보면, 아티스트 입장에서 얼마나 화가날 일인가? 구체적인 디자인 컨셉도 없고, 암것도 없이 작업은 던지고, 아티스트들이 대규모로 작업하면 기획서가 나중에 나오는데, 또다시 기획서에 맞추어서 고치거나, 고치기 힘든 리소스들은 그냥 버려야 한다. 얼마나 힘들고 화가나는 상황인가?

 즉, 이런 어처구니 없는 상황을 막기 위해서는 기획단계에서 확실하게 디자인 컨셉을 잡고, 아티스트에게 작업요청이 가야 한다, 그말이 정답이다. 그리고 그것이 "진리" 라고 할수 있다. 하지만 그게 정말로 사실일까?


2, 정석대로 기획을 하면 어떨까?

 나는 "정석적인" 기획을 하는 기획자와 이야기를 해볼 기회가 있었다. "매우 정석적이고, 훌륭하게" 기획을 하기 때문에 칭찬이 나와야 하지만, 현실은 암담하다. 기획자의 불평은 다음과 같다.

게임개발 진행은 못하고, 회의만 하고 있어, 진짜 미칠것 같아, 캐릭터를 카툰풍 귀여운걸로 할지, 리얼계통으로 할지, 반추상화풍으로 할지 힙합스타일로할지, 결정해야 하는데, 실제작업은 안하고, 하루종일 회의만 하는데, 결론은 없고, 미치겠다. 캐릭터 스타일을 이등신으로 할지, 삼등신으로 할지, 8등신 실사풍으로 할지, 카툰풍으로 할지, 실사로 할지 직접 샘플작업해서, 눈으로 보면 바로 결정나는데, 그걸 못해가지고, 몇달동안 정치싸움만 하고 있으니, 아주 제대로 배가 산으로 가고 있다.

 그냥 좀 작업하면 될것을 가지고, 몇달째 정치싸움질이다.

 캐릭터 컨셉을 이등신으로 할지, 삼등신으로 할지, 8등신 실사풍으로 할지, 그리고 렌더링방식은 카툰풍으로 할지, 실사풍으로 할지, 전체적인 분위기는 어떻게 할지, 이리저리 자기주장이 맞다고 정치싸움만 하고 있다. 이런 정치싸움은 빠르게 끝낼수 있는 방법은 "실제로 작업을 끝내서 '눈'으로 보는것이다."여러가지 스타일의 캐릭터를 모델링까지 끝내서, 결과물을 '눈' 으로 보면 확실하고 깔끔하게 논쟁이 끝난다. 결국 이런 "비효율적인 정치" 를 끝내기 위해서는 "디자인 컨셉" 이 결정되기 이전에 반드시 "모델링작업이 끝나야 하는것이다" 어라.... 뭔가 이상하다... 그런데 이 방식은 내가 언급했던 첫번째 사례에서 써먹는 방법이 아닌가?


3, 효율이라는 단어의 모순.

 여기서 모순이 발생한다. 기획자와 아티스트 2개 파트의 서로 모순된 주장이다.


기획자 : 비주얼을 보면 디자인컨셉에 대해서 금방 판단할수 있는데, 그거 작업을 못해서, 몇달동안 정치싸움만 하고 있다.
(그래픽팀장에게 모델링작업 몇개 해달라고 했더니, 디자인컨셉 확실하게 잡기 전까지는 못한다고 쐐기를 박음).

아티스트 : 원래 기획팀에서 디자인컨셉이 확실하게 결정되고, 원화가 나오고, 모델링작업 하는것이다. 디자인 컨셉도 안잡아졌는데 무슨 모델링이냐?


기획자의 입장에서 생각해보자, 캐릭터 디자인 컨셉을 그저 "서류" 만 가지고 작업하는건 매우 힘들다, 중간중간 그래픽디자이너의 결과물이 있고, 이런 결과물을 토대로 기획컨셉을 잡아나간다면 기획자는 아주 "빠르고 효율적" 으로 작업할수 있다. 하지만 여기서 모순이 발생한다. 그래픽디자이너는 불확실한 기획컨셉을 토대로 수많은 캐릭터를 제작하고, 그중 1~2개만 선택받고 나머지는 버려진다. 애초에 기획컨셉이 처음부터 확실하게 나왔다면 이런 "불필요하고 낭비스러운 작업" 은 없었을것이다.

 그렇다면 기획자가 확실하게 기획컨셉을 잡고나서, 아티스트가 작업을 하면 아티스트가 "작업을 낭비" 하는 요소는 없다. 하지만 비주얼작업 없이 오로지 서류작업과 자료조사만으로 기획자는 비주얼컨셉을 잡아야 하는 상황에 직면한다. 그래픽디자이너의 작업 결과물을 쳐다보고 판단하면 그저 1시간 회의하면 끝날것을, 서류와 의견 그리고 자료조사만을 가지고, 판단을 해야 하니 3개월이 넘게 정치싸움을 해도 결과는 안나온다. 물론 이런식으로 하면, 아티스트는 매우 효율적으로 작업할수 있다. 하지만 기획자는 비효율적으로 작업하게 된다.


4, 효율이라는 단어의 진실.

 나는 지금까지 "효율" 이라고 하면 절대적인 "진리" 정도로 생각해왔다. 하지만 지금은 다르다, "효율" 은 그저 상대적인 개념이고, 그저 관점의 문제일뿐이다. 누군가에게 매우 효율적인 방법이 어느 누군가에게는 매우 비효율적인 방법이 될수 있는것이다. 일단 효율을 원초적인 개념으로 생각해보자, 그러면 다음과 같은 공식이 나온다.

효율 = 산출량 / 투입량

최소비용을 투입해서, 최대한의 결과물을 뽑을때, 우리는 이러한 행동을 보고 "효율적" 이라고 한다. 그렇다, 우리는 효율적인 개발을 해야한다. 하지만 이건 어떨까?



 게임개발이 탄탄한 고속도로를 달리는것이라면 얼마나 좋겠는가? 하지만 현실은 그렇지 않다, 오히려 게임개발의 현실은 시궁창인 미로속을 헤매는 시행착오의 연속이다. 여기서 딜레마가 발생한다. 이러한 "시행착오" 는 근본적으로 "비효율덩어리" 라는점이다. 여러가지 가능성을 일일이 시험해보고 그중에서 가장 좋은결과값을 취하게 되는데, 이때, 산출량/투입량으로 계산되는 효율을 따진다면 그야말로 "최악" 밖에 안된다.

 이런 상황에서, 이러한 "시행착오"를 기획팀에서 맡게 된다면, 기획팀의 효율성은 바닥으로 떨어진다. 그래픽팀에서 맡게 된다면 그래픽팀의 효율성은 바닥으로 떨어진다. 프로그래밍팀에서 맡게 된다면 프로그래밍팀의 효율성은 바닥으로 떨어진다.

 효율은 능력의 문제가 아니다, 체계의 문제도 아니다. 단지 "시행착오" 를 누가 수행할지에 대한 문제일 뿐이다. 어느 누군가가 빠르고 효율적이고 깔끔하게 개발을 하고 싶다면, 어느 누군가는 그 사람에게 "모든시행착오를 거쳐서 완벽하게 검증된 결과물" 을 넘겨주어야 한다. 하지만 그렇게 하기 위해서 얼마나 큰 비효율이 발생하겠는가? 어느 누군가가 효율적으로 개발하기 위해서, 어느 누군가는 비효율적으로 개발해야 한다.


5, 이상한회사에서는 왜 요상한 방법으로 기획을 했을까?



 이제 글의 처음부분에서 언급했던, "이상한 회사의 요상한 그래픽작업흐름" 에 대해서 말할 차례이다. 왜 이런 어처구니 없는 방법을 선택하게 되었을까? 일단 경영진의 입장에서의 상황을 정리하면 다음과 같다.

1, 회사에 자금이 넉넉하다. (어느정도는 낭비를 해도 될정도로)
2, 하지만 게임개발 "시간" 은 부족하다.
3, 자금투입을 늘려서 "시간" 을 단축시킬수 있다면 기꺼이 해야한다.
4, 프로그래밍팀의 인력을 늘린다. -> 시간단축 안된다. -> 실패
5, 기획팀 인력을 늘린다. -> 정치싸움만 더 늘어난다. -> 실패.
6, 그래픽팀 인력을 늘린다. -> 그래픽작업은 Man/Month 분할이 쉽다. -> 성공.

 회사에 자금은 넉넉하지만, 시간은 없는 상황이다. 빨리 디자인 컨셉을 잡아야 하는데, 기획자를 더 뽑는다고 해서, 작업이 빨라질 기미가 보이지 않는다, 하지만 아티스트 인력을 대규모로 충원해서, 그래픽작업을 우선작업 하면 디자인컨셉잡는 작업을 빠르게 진행할수 있다. 그래서 "상식을 깨는 어처구니 없는 바보짓" 을 하는것이다.

 보통 모델러들이 입버릇처럼 하는말이 있다.

"원래, 기획쪽에서 디자인 컨셉이 끝나고, 원화작업 하고 나서 모델링을 하는것이다"

하지만 게임개발에 있어서 "원래" 는 없다. "원래" 라는건 "강원래" 가 만들어서 "원래" 인가? 대한민국 헌법에 게임개발은 이런식으로 하라고 적혀 있는가? 전혀 아니다. 물론 기획컨셉을 확실하게 정하고, 깔끔하게 한방에 그래픽작업이 끝나면 좋다는걸 누가 모르는가? 문제는 그런 "효율적인방법" 을 위해서 어느 누군가는 "극도로 비효율적인" 작업을 해야한다는 점이다.


6, 밸런싱을 하면서 발생한 일.



 밸런싱을 하면 기획자와 프로그래머사이에 늘상 발생하는 일이 있다. 기획자는 매번 밸런스가 안맞는다면서, 컨텐츠 프로그래머에게 달려와서 "이렇게 고쳐주세요", "저렇게 고쳐주세요" 라고 말한다. 나의 경험으로는 대략 4~5번은 고쳐야 밸런스가 제대로 잡힌다. 프로그래머 입장에서는 정말로 짜증나는 일이다.

 위의 그림을 보면, 4번의 시행착오를 거쳐서, 밸런싱에 성공했다. 사실 프로그래머의 입장에서는 애초에 밸런싱 계획을 잘 잡아서 처음부터 "밸런싱 계획4"를 프로그래머에게 가져왔다면 쓸데없는 삽질은 안했을것이다. 기획자가 밸런싱계획을 4번이나 바꾼덕분에 프로그래머는 "비효율적이고, 불합리하게" 게임개발한것이다.

 하지만 반대로 생각해보자, 기획자의 입장에서는 서류상에서 밸런싱계획을 잡고, 엑셀로 시뮬레이션을 하기는 하지만, 결국 "게임상에서 직접 검증"을 해야한다, 엑셀에서 밸런스 검증하는거랑 직접 게임을 해보는거랑 하늘과 땅 차이이다. "전체유저의 80%" 정도가 만족하는 밸런싱을 목표로 한다고 할대, 서류작업만으로 그정도 수준까지 가는건 정말로 힘들다, 아니, 어쩌면 불가능할수 있다. 결국 "100% 서류작업만으로 밸런싱 수준을 끌어올리는것은 극도로 비효율적인 작업이다."

 하지만 여기서 모순이 발생한다. 프로그래머와 기획자가 서로 생각하는 "효율적인 방법" 이 다른것이다.

프로그래머 : 밸런싱 계획을 확실하게 잡아놓고 나서 컨텐츠 코드를 고쳐달라고 해라.
기획자 : 실제 게임플레이 없이 서류작업만 가지고 밸런싱 작업하는건 매우 '비효율적인' 작업이다.

 사실 나도 "효율적인 방법" 에 대해서는 잘 안다, 낭비없이 한방에 깔끔하게 가면 그게 최고의 효율이고, 최고의 선이다. 그걸 누가 모르는가? 하지만 어느 누군가가 궁극의 효율을 내기 위해서는 어느 누군가는 극도로 비효율적인 환경에서 비참하게 작업해야 한다. 프로그래머가 삽질을 하면, 기획자의 시행착오가 줄어든다, 그 반대도 마찬가지이다. 효율이란 그런것이다. 어떤 절대적인 존재가 아니라, 단지 관점의 문제일뿐이다.


7, 효율은 단지 관점의 문제일 뿐이다.

 내가 생각하는 하느님과 당신이 생각하는 하느님은 같다, 내가 생각하는 예수님과 당신이 생각하는 예수님은 같다, 내가 생각하는 독도와 당신이 생각하는 독도는 같다.(주1) 하지만 내가 생각하는 '효율' 과 당신이 생각하는 '효율' 은 다르다. 왜냐하면 '효율' 이라고 하면 관점에 따라서 달라지기 때문이다. 내가 효율적으로 일하면 당신이 비효율적으로 일해야 한다, 반대 역시 마찬가지이다.

 한때, 빠르고 합리적이고 효율적인 게임개발에 대해서 고민한적이 있었지만, 이제 더이상 게임개발에 있어서 효율을 따지지 않는다, 오히려 "불합리하고, 비효율적이고, 낭비가 심하고, 형편없는" 게임개발을 어떻게 할것인지에 대해서만 생각한다. 지금 시점에서, 나는 오히려 "비효율적인 프로그래머" 라고 선언하고 싶다.

진실은 단지 관점의 문제일 뿐이다. -프라이스 대위, 모던 워페어3-

효율은 단지 관점의 문제일 뿐이다.

댓글

이 블로그의 인기 게시물

iOS 아이폰용 앱 개발을 위한 디자인시, 디자이너가 참고 해볼만한 사항들

스냅드래곤 기반 크롬북, ‘트로그도어’ 개발 중

[펌] '악마는 프라다를 입는다'의 진짜 명대사