팀 테스트는 계속됨미다 'ㅅ'

'아무리 생각해도 이게 핵심 문제인거 같은데 아리까리 거시기하네잉' 싶었던 부분이 역시나 핵심이었고, 물론 아직도 '으윽 이것도 핵심 문제같은데 이건 건드리기가 쵸큼 무섭'인 부분이 없지 않지만...

암튼 독립적이되 큼지막했던 문제들 좀 쳐냈으니 이제는 설레발을 칠 차례 'ㅅ'



이제 슬슬 보이기 시작하는 문제들은 단순한 버그나 리소스, 혹은 밸런싱의 범주를 벗어나기 시작한다.

즉 애초에 의도했던 '게임 플레이'가 예측대로 구성되지 못하는 문제... 흐억. 게임 디자인이 잘못됐어!!!


냅. 업ㅂ슴미다. 여기서 타협하면 망작 'ㅅ'



문제가 발생하고 있다는 현상은 명확하며, 해결하지 않는 이상 이 문제는 사라지지 않는다.

그런데 이 문제를 어떻게 해결해야 할는지... 그 최선의 방법은 명확히 보이지 않는다.

차선책이라 할만한 녀석은 보이는가?

뭐 최선이고 차선이고 아예 답이 안보인다면 이건 뭔가 애초에 근본적으로 잘못되었다는 것이 되므로 (...) 나도 모르겠다. 이런 경우에는 어떻게 해야 할까효 ㅋ

그르나 다행스럽게도 대부분의 경우... 최소한 차선책이라 할만한 녀석은 보이게 마련이다.



최선책이라고는 못하겠지만, 그래도 차선책 정도가 보인다면?


... 라고 생각할 시간에 그 차선책을 먼저 구현해보는 쪽이 낫다... 고 생각한다.

물론 그 차선책이라는 놈이 게임의 근간을 뒤흔들어 버린다든가 -_-a 구현하는 데에 무지막지한 코스트를 요구하는 놈이라면 쓸 수 업ㅂ는 방법임미다 냅.

하지만 완전히 막장으로 게임을 구성하지 않은 이상에야, 대부분의 경우 이미 구축된 기반 위에서의 수정 작업으로 커버가 되게 마련이고...

그러므로 '고민할 시간이 있다면 그 시간에 일단 그럴싸해 보이는 놈을 닥치고 구현해보는 쪽'이 어떻게든 더 낫지 않을까 싶다.



그 차선책을 구현해서 함 볼 수 있게 된다면...


이럴 수 있지 않을까 'ㅅ'



... 라지만 역시 시간이 모질라 흑흑

크런치는 끗나지 않는다 ㄱ-

[imays]님의 글 - [게임 개발의 암세포! FEATURE CREEP]에 덧붙이는 소견 'ㅅ'/



원문에서 기획자가 feature creep의 함정에 빠지는 사례로 소개된 내용을 발췌해 보자면 다음과 같다.


... 아놔 일단 눈물부터 좀 닦고 ㄱ-

이것이야말로 기획자라는 족속들이 참으로 쉽사리 빠져들곤 하는 [개발의 함정]이나니, 이 뭐... 망작으로 가는 지름길인거졈 ㅋ

그런데 여기에 한가지 더 덧붙이고 싶은 이야기가...

이 반대의 길에도 함정은 있슴미다 'ㅅ'



기획자가 게임에 이것 저것 오만 잡다한 feature들을 추가하는 이유는 '다른 게임에서 본 감동스런 피쳐들을 우리 게임에도 넣어서 엘레강스한 완성도를 만들기 위하여'인 경우도 있지만...

그 반대로 '이 게임이고 저 게임이고 더 이상 재미도 감동도 없다 보니, 우리 게임의 피쳐들도 너무 고만고만해 보이기만 해서'인 경우도 있다.

이건 특히나 겜덕 기획자들이 빠지기 쉬운 함정이 아닐까 싶기도 한데... 솔직히 말해 나 역시 이 함정에서 완전히 자유롭다고 장담하지는 못하겠다 ㄱ-



풀어서 설명해 보자면 다음과 같은 상황이라고나 할까.

현재 20대 후반 즈음에서부터 30대 초중반에 이르는 겜덕들은 소위 '전자 게임의 역사와 함께 자라온 세대'인 경우가 많다.

8비트 뿅뿅거리던 녀석들부터 게임 인생이 시작되어... 온갖 합법 / 불법(-_-)의 길로 다양다종한 게임들을 접하고 플레이해온... 좀 유명하다 싶은 게임이라면 '당연히 해봤졈' 소리가 나오는 니마들.

(... 이라고 적어놓고 보니 정작 나는 콘솔이랑은 별로 안친하고, 순혈 PC 외길 인생을 걸어왔지만, 그렇다 쳐도 왠만큼 유명한 콘솔 게임들은 또 어찌어찌 얼추 해본 듯 oTL)

그러다 보니... '하늘 아래 새로운게 대체 뭔가효?'라는 의문에 빠져버리기가 쉽고, 여기서 특히나 로직이라는 함정에 허리를 담그고 사는 시스템 기획자들은 한발짝 더 나아가...

때깔만 좀 다를 뿐이지 본질은 똑가타! 게임 피쳐라는게 다 거기서 거기지!

... 라는 성급한(?) 결론을 내려버리게 되어버리기가 참으로 쉬운 것이다.

그러다 보니 자기가 만들고 있는 게임에 들어가 있는 피쳐들도 뭔가...

식상해! 구태의연해! 아오오 ~_~ 이건 이 게임에 있던 거고, 저건 저 게임에 있던 거고! 뭔가 좀 더 새로운 피쳐는 없나효? 머리를 굴려보자 데굴데굴. 이런건 어떨까? 함 넣어볼까? 저런건 어떨까? 함 넣어볼까? 아오오 ~_~ 좀 더 창조적이고 창의적이며 새로운 경험을 창출해낼 수 있는 무언가! 무언가! 이걸까? 저걸까? 넣자! 우걱우걱!

... 요론 사태가 벌어져 버리는 것이다 -ㅅ-



아 냅. 물론 매우 바람직하지 않슴미다. Feature Creep이졈.

다른 게임에서 감명깊게 경험한 피쳐를 게임에 억지로 쑤셔넣는 거나... 결국 다 고만고만하다고 생각하야 그 고만고만함을 벗어나 보겠다고 우걱우걱 피쳐들을 억지로 쑤셔넣는 거나... 어느 쪽 극단으로 달려간다 할지라도 종착점은 똑같이 망작.



그러니까 결국은... 애매한 중용론만이 남게 되는데, 이건 뭐 어쩔 수 없는 듯 싶기도 하다. 게임 개발이 원래 그렇지 뭐 -ㅅ-

그나마 '지금 만들고 있는 게임에 가장 어울리는'이라고 엄연히 존재하는, 잘 보이지는 않으나 그래도 따라갈 수 있는 길이 있기는 하다는 정도가 위안일라나.



... 그르니까 결론은 잘난 척 하지 말자는거졈 'ㅅ'

... 그래도 빠심으로 눈이 흐려지는 것보다는 오만함으로 가려지는 쪽이 1mg 정도는 좀 더 낫다고 생각하긴 함미다 에헷 -ㅁ-

... 요런게 바로 잘난 척 oTL

알파 테스트 이전의 단계, 그러니까 걍 팀 내에서만 진행하는 구현 테스트... 같은 놈은 뭐라고 불러야 하나효?

에에... 그냥 팀 테스트? -_-a 모르겠다. 걍 팀 테스트 ㅋ



그러니까 드디어 팀 테스트를 시작했다능.

아아... 무슨 게임인지는 뭐 아직 공개가 아니된 녀석이니, 걍 수많은 개발사들이, 수없이 가지고 있으면서, 조용히 진행하다가, 혹은 조용히 접어버리기도 하는(쿠엑) 그냥저냥 개발 프로젝트인 셈인데.

암튼 기나긴 프로토타이핑의 산을 넘어, 이제야 비로소 실구현된 클라이언트의 첫 테스트.

... 당연히 개판 오분전임미다.

속출하는 버그들, 아직 제대로 붙지 못한 리소스들, 그리고 밸런싱이 뭔가효 먹는건가효?

... 게임이라 부르기도 애매한, 돌아가는게 다행인... 아니지 제대로 돌아가지도 않자나 ; 암튼 뭐 그런 상태.



당연히 수많은 문제들이 불궈져 나오고, 미처 예측하고 고려하지 못한 문제들도 수면을 박차고 튀어나오고 그러나니...

패닉에 빠지기가 참 쉽다능.




그러므로 결론은 설레발 금지.

일단은 다른 요소들과 실타래처럼 얽힌 녀석들에 손을 대는 것은 금물이다. 뭐 하나 건드리면 줄줄이 엮이는데, 건드린 녀석이 문제의 핵심이라는 보장은 '아직' 아무 데에도 없으니까.

개별 단위의 독립적인 문제들을 우선 손봐서 제대로 해놓고, 그 후에야 비로소 전체적인 그림을 다듬어가야 하나니...

뭐 이건 너무나도 당연한 일반론.

그러나 한발짝만 삐끗하면 패닉이나니, 정신줄을 잡읍시다 ㅋ



근데 그보다 더 곤란한 문제는... 쯥.

개발 외적인 이슈로 1개월을 허공으로 날려버렸는데, 그 1개월을 아무도 보상해주지 아니하나니 ㄱ-

히밤. 크런치로 극복이라니... 이게 뭔가효. 그나마 크런치를 이렇게 빡세게 하고 있는데도 그냥 대놓고 물리적 시간이 모질라.

장기적으로 보자면 이 부작용은 점점 누적될 가능성이 높은데 ㄱ- 이거이 개발 프로젝트에서 원래 발생하는 리스크인건지 에잉.

간만에 끄적여보는, 조금은 공격적인, 아는 사람만 알만한 이야기?



옛날하고도 한 옛날에 끄적였던 글에서 언급했던 바와 같이, 난 여전히 온라인 게임 개발에 있어 In-Game Play라 불리우는 영역과 Out-Game Play라 불리우는 영역이 가지는 중요성의 비율이 5:5는 된다고 생각한다.

다만 이 둘은 한 세트이기 때문에, '어느 한 쪽이 괜찮으면 다른 쪽은 좀 허접해도 된다는거냐?'라는 식의 반론은 사절.

어느 한 쪽만 괜찮아봤자 결국은 50%만 성공적인, 반쪽짜리 게임일 뿐이니 망합니다 뿌우 'ㅅ'

(예외 케이스가 아주 없는 것은 아니지만, 예외는 예외이므로 예외로 취급하야 예외적으로 예외 처리 해버림미다 -ㅁ-)



물론 중요도는 동일 비율이라 하지만... 소위 '게임 디자인'이라 지칭되는 영역은 아무래도 In-Game Play 쪽에 걸쳐 있는 경우가 많고, Out-Game Play 쪽은 '편의 기능'이나 온라인 게임이기에 가져야만 하는 일종의 '순환 구조'를 형성하는 디자인에 가깝다.

그러므로 일반적으로는 In-Game Play 쪽을 우선적으로 디자인하고, 그 쪽에서 성과가 어느 정도 보이고 나면... 그제서야 Out-Game Play 쪽의 디자인으로 접어들곤 하는데...

우리도 마찬가지.

In-Game Play를 좀 쓸만하다 싶도록 만들기 위하야... 프로토타이핑만 1년, 그리고 그 프로토타입을 기반으로 하야 다듬고 다듬으며 제대로 된 플레이어블 버전을 만드는 데에 또 1년 가까운 시간을 쓰는 중이다.

그리고 이제서야 얼추 쵸큼 Out-Game Play 쪽의 디자인으로 시선을 돌리는 중인데... 하아. 그니까 이 녀석도 결국 중요도는 50%인지라, 쓸만하게 만드려면 또 얼마나 머리를 쪼개고 쪼개며 고민해야 할는지 앞이 깜깜.

뭐 그렇다 쳐도... 요거이 개발의 정도랄까, 어차피 다들 하는 일이고, 나도 해야 하는 일이고... 앞은 깜깜해도 당연히 해야 하는 거니까리 어찌하리오. 해야제.



... 인데, 요즘 들어 사도의 길이 눈에 밟히나니 -ㅁ-

In-Game Play는 결국 결과물이 '게임'이라 불리우기 위한 성격을 결정짓는 부분이므로, 최대한 공들여 만든다 치더라도...

Out-Game Play는 앞서도 언급한 바와 같이 편의와 순환 구조의 이슈에 가까우므로... 이미 성공적으로 이러한 구조를 갖춘 다른 게임의 Out-Game Play를 그냥 통째로 들고 와버리면 되지 않카써???


... 물론 안됨미다. 그니까 둘은 한 세트라서, 남의 것을 그대로 들고 온다 해도 어차피 잘 붙게 하려면 조율을 해야 하기 때문에...

... 라지만 장르에 따라서는 그냥 그대로 붙여도 되는 경우가 없지 않다. (우린 그렇게 못한다 크흑)

그럼 장르에 따라서는 그냥 통째로 들고 와버리는게 개발 기간도 단축하고, 개발 인력도 적게 쓰고, 심지어 그러면서도 '성공적인' 녀석을 들고 와버린만치 퀄리티를 기대할 수도 있는... 캬악. 존내좋군?


... 아니 그러니까, 안된다니까.

... 그런데 그러더라니까.

대놓고 사도의 길을 표방하며 달려가고 있나니, 그걸 보고 있자면 실로 꽁기꽁기하다 -ㅅ-

(심지어 처음 그러는 것도 아니고 두번째야 ~_~; 확신범에 가깝다는 생각이 들기 시작하는데...)



물론 프로젝트라는 것은 성공을 목표로 하야 진행하는 것이고, 그 성공을 달성하기 위한 goal은 '빠르고, 싸게, 높은 퀄리티로'이니까리... 이거이 참 '좋은' 방법이라는 것은 알겠는데...





아니 '나는' 안괜찮은 것 같다능. 일단 난 누가 그러라고 하면 내 '프로 의식'에 액화 질소라도 붓기 전에는 그렇게 못할거 가터 -ㅁ-

그니까 난 울 게임의 Out-Game Play 디자인이나 해야... 아익 머리 아파 ㄱ-



ps. 물론 이거이 표절이나 무단 도용은 아님미다. 차라리 표절 or 무단 도용 = 불법이라면 이런 아햏스러운 기분은 안들겠징.

아 영양가도 없고 쓰잘데기 없는 글이 넘 길었다. 8연작은 또 처음 해보네. 이제 좀 끝내자능.


게임 디자인이란 실로 모호한 일이다.

정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.

그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?

그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;

그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?

어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?



그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.

뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.

그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?

확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?

... 신념?


... 라고?



아니.

나는 바로 이 지점이 위험하다고 생각한다.

게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!

그 순간 기획자의 신념은 개발에 독이 된다.

이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.

아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?

아니.

그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.



그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?

아니.

게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.



그리하야 내가 내리는 결론은...

기획자는 프로세스를 먹고 살아야 한다는 것이다.

개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.

혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.


하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...

그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...

우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.

핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.



기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.

이  경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?

아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.

구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...

기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.

이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.



따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.

아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.


이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.

그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.

이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.

그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.

아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.

이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?

그렇기 때문에, 우리 팀이 현재 채택하고 있는...


...라는 프로세스가 나는 옳다고 생각한다.

프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.



이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?

아니.

이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.

드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.

아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.

최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.

무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.

마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.

그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.

남은 것은 '노예처럼 일하셈!!!' 뿐.



물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a

[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.

하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.

피식. 마지막은 또 용비어천가인가효.

뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-



언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?

'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'

... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.

쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/

게임 기획자가 뭐하는 놈들인지에 대한 질문에서부터 시작하야... 이제는 무슨 프로세스 이야기를 하고 있나효. 삼천포도 이런 삼천포가 업ㅂ는... ㄱ-

하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)

그러므로 다시 전진~



NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.


물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...

추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.

뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.

혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.

그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?

그렇지는 않다고 생각한다.

이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.



1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.




2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.




3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.




4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.




5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.




... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...

글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a

그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.



1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.




2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?




3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)




4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?




에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;

또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;

... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;

그래도 이제 남은건 결론 뿐이다.

게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.

그럼 마지막 글에서 ( '')

이건 뭐 재미도 없고 감동도 없는 글이 쓰잘데기 없이 길기만 욜라리 길어서리 벌써 6번일세 ㄱ-

이 즈음 해서 잠시 정리 좀.

[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.

[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.

[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-

[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.

[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...

그래서 이제 6번부터는...

기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.

넵. 저는 그게 개발 프로세스라고 생각해효.



그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?


그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.

그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.

그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.



지금까지 내가 경험해 본 개발 프로세스는 총 4가지.

사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.

[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)

암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.

그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...

물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...

그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.

자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.



1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.




2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.




3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.




4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.




5. 어셋 구현 후에는... 리소스들의 조립.




6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.




7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.




우와... 이게 뭐야.

적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-


아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)

당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.

그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.

하지만 이미 스크롤 압뷁 ㄱ-

... 7번으로 넘어가야 겠네효.

이제 슬슬 삼천포야 ㄱ-

뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')



이번엔 다른 관점에서 한 번 접근해 보자.

다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...

그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?

그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?



개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.

이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.

이제는 좀 지겨운 ;;; 7단계 다시 시작.



1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.




2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.




3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.




4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.




5. 어셋 구현 후에는... 리소스들의 조립.




6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.




7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.




요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!

이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.

즉, 재미 창출의 전문가처럼 보이게 되는 것이다.

더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.

사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...

그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.

그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?

과연?! 퍽이나?!



게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?

물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.

코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.

그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?

자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?

글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.

그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?

글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.



혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...

내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.




등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.

수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;

더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...

이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.

게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.

혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.

어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.



결론을 내려 보자면...

기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,

기획자가 아무리 열심히 일을 잘 한다 할지라도,

개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,

이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,

기계적으로 일을 하게끔 만들어,

필연적으로(!) 수많은 문제를 야기하게 되고,

그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,

최종적으로는 게임의 성공 가능성을 깎아먹게 된다.



... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;


... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.

'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'


기획자 무용론에 동참하셨군효 /박수



자아, 다시 처음으로 돌아가보자.

다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...

그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?

결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.

역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;

게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.




저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.

그럼에도 불구하고...

그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?

위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?

그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?

... 논리적으로만 보자면 그리 부당하지 않아 보이는데?

하아...? 잠깐만.

그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?

그럼 기획자라는걸 다 치워버리면 괜찮은건가?

하지만 기획자들을 다 치워버린 상황을 상정해 보자면...

[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.

그럼 무엇이 문제인가?



... 이미 충분히 길다. 다음 글로.

다음 글의 힌트.

저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?

쓰면 쓸수록 '내가 이 글을 왜 시작한거랍쇼'라는 생각이 들고 있기는 하지만 -_-a

뭐 그래도 솔직히 내 인생, 내 커리어의 지금 이 시점에서 내 생각은 이러하다.

... 라고 정리, 기록하는 의미 정도는 가질 수 있을테니 계속 용감무식무쌍하게 전진 -ㅁ-/



자 자, 개발 수순의 구간에서 기획자의 전문성이 드러나는 지점을 찾아보는 것은... 일단 2가지 정도 짚을 수는 있었지만, 그 2가지는 모호함의 경계가 너무나도 넓다는 정도로 결론 ㄱ-

그래서 결국 기획자가 대체 뭐하는 놈들인지에 대한 이야기는, 그나마 희뿌옇게 무언가 보이기는 하지만서도 그거이 뭔지는 모르겠는, 혹은 알지만 너무 넓어서 모르는 거나 마찬가지인 상황 ㄱ-

그러니 여전히 '이런 애매모호한 직군 따위 필요없어'에 대한 반박은 쉽지 않은 상황이다.

아놔 데꿀멍 함 하기 참 힘드네 (...)



그럼 이번에는 기획자를 함 없애보자.

기획자를 없애고도 개발이 매끄럽게 잘 진행된다고 예상된다면... 뭐 기획자 따위 별로 필요없는거졈 ㅋ

일단 기획이라는 일이 사라질 수는 없다. 기획 없는 개발이라는건... 설계도 안하고 건물을 냅다 짓겠다는 셈이니 말이 아니된다.

즉 기획자를 없앤다는 것은... 결국 기획 업무를 다른 직군이 맡는다는 뜻이 된다.

과연 어떤 일이 벌어질까요?

일단 개발은 여전히 7단계의 수순을 따라 진행된다고 가정해보자. [2번 글]에서도 언급한 바와 같이 저건 협업 체제 개발 수순으로도 얼마든지 치환할 수 있으니까.



1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.




2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.




3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.




4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.




5. 어셋 구현 후에는... 리소스들의 조립.




6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.




7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.




정리해 보자면... 우와... 기획자 없이도 어케어케 일이 되기는 하겠는데?

다만 크리티컬한 문제로 대두되는 부분은 '개발 효율'이 극도로 떨어질 가능성이 높다는 지점.

그럼 기획자는 개발 효율을 높이기 위해 존재하는 건가효...?

'잡부'라는 생각이 다시 고개를 들이밀기 시작하지만... -_-a

뭐 반장난스럽게 평가절하스러븐 단어를 사용한다 할지라도, 개발 효율이라는건 매우매우 무지무지 중요한 요소이므로, 기획자는 있는 편이 좋다! 라는 실로 알흠다운 결론이 나오는군요.

음헤헤. '나는 그냥 월급 도둑이란 말인가?'라는 존재론적인(?) 자학에 빠져 사표 쓸 필요는 없겠다 (...)



자 '기획자 따위 필요없어!'에 대한 대답은... 실로 대충 떼워막기로 해버린 듯 싶지만 암튼 어떻게 했다고 치자.

그런데 '기획자가 없다!'라고 가정을 해봤다면... 그 반대 급부에 대한 의문이 꼬리를 물고 나오는근염.

만약 기획자가 저 모든 걸 다 맡아서 해치운다면 과연 어떻게 될까?

호옹... 어떤 양상으로 흘러갈는지 벌써 감이 딱 오기는 하는데...

아마도 '기획자 따위 필요없어!'라는 주장을 아직 포기하고 싶지 않으신 분들이 기꺼워 할만한 내용으로 채워질...

다음 글에서 ( '')

[2번 글]에서 말한 바와 같이, 이번엔 개발 수순에서 기획자만의 고유한 전문성이 개입하는 구간을 함 고민해봅세.

기획자만의 전문성?!

... 그러니까 이게 뭔지를 알면 문제가 참 간단해지는 셈인데 -ㅅ- 가장 아리까리한 부분이기도 하다능.

기획자라는 타이틀을 달고 있는 주제에, 내 직업을 명확하게 정의조차 내리지 못하다니 참으로 쓸모업ㅂ는 놈이로다... 싶지만 ㄱ-

뭐 그래도 계속 함 가봅세.



1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.




2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.




3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.




4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.




5. 어셋 구현 후에는... 리소스들의 조립.




6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.




7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.




... 라고 한다면. 자 정리해보자.

1번부터 7번까지 중에서, 내가 보기에 기획자라는 직군의 성격을 규정짓는다고 할만한 작업은 게임 디자인과 밸런싱 2가지이다.

그러나 그래서 게임 디자인과 밸런싱에 있어 어떠한 전문성이 요구되는가... 라고 한다면 여전히 그 점에 있어서는 모호함이 나를 휘어 감싼다.

물론 필요한 스킬이 '없다'라고 할 수는 없다. 즉 일반인과 게임 기획자를 가르는 선은 분명히 존재한다.

'그 선은 이 지점이다'라고 명확히 할 수는 없겠지만, 사실 이런 식으로 분해해 가면서 접근한다면 어느 직군이든 그 선은 1차원적인 구분자로 존재하는 것이 아닌, 2차원적인 면으로서 존재할 것이다.

하지만 역시 기획자는 그 면이 너무 넓다 ㄱ-

일단 나열하기 시작하자면... 이 뭐 인문학 거의 전반, 혹은 이학이나 공학까지도 넘나들게 되어버리는 것이다. 그렇다고 또 어느 분야에 대해 Master가 될 필요까지는 없고, 이 분야 저 분야 모두 툭툭 건드림에 부족함이 없는 정도면 족하다.

(그러니 '게임 기획자가 되려면 어떻게 해야 하나효?'라는 질문에 대하여 우리가 해줄 수 있는 대답이라는게 '게임 하나 만들어 보세효' 정도 밖에 못되는 것이다. 기획자로 넘어오는 선이 너무 넓으니까 차라리 통째로 함 해보라는... 그것 참 이게 정답이라고 생각하기는 하지만, 이게 정답이라는 사실은 사실 참 슬픈 사실이 아닐 수 업ㅂ다 ㄱ-)

그리하야... 결국 '개발팀의 잡부'라는 결론이 다시 튀어나와 버리는 것이다 -ㅁ-;;;



... 뭐 잡부라는 단어를 조금 부정적인 뉘앙스로 써서 단순히 거부감이 드는 것일는지도 모르겠지만 ㄱ-;

또는 기획자는 원래 저 모호함의 넓은 면에서 헤엄치는 존재가 맞는 것인지도 모르겠지만...

혹은 애초에 내가 진행한 사고 전개가 완전히 틀려먹은 것일는지도 모르겠지만...

어찌되었든 현재로서는 내가 게임 기획자라는 직군에 대하여 설명할 수 있는 지점은 이 정도이다.

워킹 딕셔너리, 혹은 개발의 짐덩어리 사이에서 모호하게 존재하는 직군이랄까 ㄱ-;



... 이 시점에서 '역시 게임 기획자 따위는 필요없군'이라 읊조리며 고개를 끄덕이는 당신을 위한 이야기는 다음 글에서 ( '')

자 [1번 글]에서 던져진 질문은 '게임 기획자라는건 대체 뭐하는 놈들인데?'라는 거였는데... ㄱ-

이거이 쉽게 대답할 수 있는 거였다면, 그냥 지난 글에서 휙 정답을 던져 버리고 걍 끝냈겠지.

이렇게 넘버링까지 해가면서 글을 분리하지도 않았을 터...

그러니까 솔직히 결론부터 말하자면 나는 아직 기획자라는 직군을 한 문장, 혹은 한 단어로 명확히 정의하지는 못하겠다.

([예전 글]에서 언급한 바와 같이 '잡부'라는 한 단어로... 하려면 할 수야 있겠지만 -ㅁ- 설마 이런 대답을 원하는건 아닐테고;;;)

그러니까... 같이 함 고민해봅세.



4년 전 면접에서 '기획이란 무엇이라고 생각하시나요?'라는 질문을 받았을 때, 내가 했던 대답은 '룰의 정의'였는데...

아주 틀린 말이라고 생각하지는 않으나, 이건 어디까지나 시스템 디자인의 단편에서나 먹히는 이야기인 듯 싶어서리, 역시 좀 반쪽스럽다.

그럼 기획이 대체 뭔데?

나도 잘 모르겠으니까... 기획자가 하는 일을 한 번 죽 나열해보면, 좀 더 명확해지지 않을까?

기획자라는 직군은 개발팀 내에서 무슨 일을 하고 있는가?



뭐 어쩔 수 없이 일단 내 경험에 기반하여 썰을 함 풀어보자.

내가 해왔던, 그리고 지금도 하고 있는 일들을 조금 많이(!) 단순화하고, 순차적으로 나열해 보자면...


... 뭔가 다분히 시스템 디자인스러운데... -ㅁ- 그거야 내가 시스템 디자이너이니까 (...)

레벨 디자이너라면 좀 다를까?


... 비슷하네.

퀘스트 디자이너라면 좀 다를까?


물론 매우매우매우매우 단순화하고 추상화 해버렸기 때문에, 조금은 억지로 끼워맞춘 감이 없지는 않은데...

... 중간에 몇 단계가 빠지는 경우도 있고, 시스템의 성격에 따라 내가 참여하지 않는 단계도 존재하며, 특정 단계에서 몇바퀴를 돈 다음에야 다음으로 넘어가는 경우도 있는 등등 저 문장들의 뒷면이나 행간에 숨어있는 무수한 예외들이 존재한다.

뭐 대충 알아먹으시면 된다능ㅋ

(일정 조율이나 시장 파악 등등, 내가 했었던 다른 일들이 빠져있기는 하지만... PM이라는 직급의 업무나 마케터의 영역을 기획자의 업무로 간주해도 되는건지 잘 모르겠으니까 걍 패스 ~_~ 시나리오 라이터라면 또 다를 것 같지만... 아 잠깐. 우리나라에서야 라이터를 기획자로 뭉뚱그리지만, 엄밀히 말해 라이터를 기획으로 분류하는건 좀 아닌 것 같으니 또 패스 ~_~)

암튼 마구마구 단순화시킨 저 과정을, 개별 게임 어셋들의 수만큼 무한 루프 (...) 돌리는 것이 내 일이다.



에... 그런데 말이졈. 일이라고 적어놓은 걸 보고 있자니 갸우뚱해져 버린다.

저게 기획자의 일이라고?

저건 그냥 게임을 개발해 나아가는 수순을 나열해 놓은 거잖아?


기획자만 이렇게 일하나효? 프로그래머도, 아티스트도 용어만 조금 바꾸면 일하는 순서를 이와 비슷하게 끼워맞출 수 있다.

아니 직군을 따로 나누지 않는다 하더라도, 협업이 이루어지는 순서 역시 여기 끼워맞추는 데에는 그닥 무리가 없을 듯. 원래 개발은 이런 수순으로 진행된다.

그러니 이걸 '기획자라는 직군을 정의하는 일'이라고 보기는 아무래도 힘들다. 뭐 기획자가 일련의 과정들을 모두 매니징한다... 라고 한다면 저 흐름을 만들어내는 것 자체를 하나의 일로 구분할 수는 있겠지만서도, 그건 역시 PM의 일인 것 같으니 패스.



아익 경험에 의거하여 일단 생각나는대로 썰을 풀었더니만, 이건 '기획자의 일'이라기 보다는 그냥 '일' 혹은 '개발'이 튀어나와 버렸넹.

그럼 기획자는 대체 '구체적으로' 뭐하는 놈들인데?

흐음... 저 흐름에서 기획자가 '고유의 전문성'을 발휘할 수 있는 구간이 있는지를 한번 살펴본다면 좀 더 명확해지지 않을까?

그러나 그건 다음 글에서 ( --)

...

...

...

... 이제 겨우 2번인데도 내가 무슨 짓을 하고 있는거랍쇼 ㄱ- 라는 생각이 벌써 들기 시작하는데...

뭐 그래도 일단 칼을 뽑았으니 오늘은 무를 썰고 다음엔 뜨거운 감자를 썰어봅세.

... 이와 같은 이야기는 게임 관련 커뮤니티에서 벌써 몇년 째 울궈먹고 있음에도, 미끼만 던졌다 하면 여전히 파닥파닥 만선인... 레전드리 떡밥이다.

심지어 개발자들 중에도 저런 생각에 동조하는 사람이 있다 보니, '기획자 따위 필요없어!'를 표방하는 게임이 나온 적도 있고... 뭐 암튼 여타 등등.

이 쉰내나는 떡밥을 이제 와 다시 돌이켜 보는 이유는...

솔직히 좀 억울해서. 헤헤헤.

데꿀멍 데꿀멍 데꿀멍 ( '')



일단 저 위에 나온 이야기에서, 기획자라고 지칭되는건 과연 누구일까? 기획자란 대체 뭐하는 사람일까?

기획자들이 x같아서 재미있는 게임이 안나온다 했으니... 그럼 기획자들이 잘하면 재미있는 게임이 나온다는 거근염.




하지만 재미라는건 게임의 궁극적인 목표이고, 개발의 모든 방향성은 결국 '재미'라는 키워드로 집중되게 마련인데... 그러한 재미를 만들고, 보장하고, 책임지는 기획자란...?




... 하아. 이 즈음에서 개발자, 혹은 눈치가 빠른 유저라면 '어랍쇼 잠깐만?!'을 외치실 때가 되었는데...




... 우리는 이런 사람을 '기획자'라는 직군으로 분류하지 않는다.

... 이런 사람은 '디렉터'라는 직급으로 분류된다.



물론 기획자가 디렉터를 맡는 경우라면 결국 같은 이야기가 되어 버리겠지만, 그럼에도 불구하고 '정립하고, 결정하고, 보장하며, 책임지는 것'은 기획자의 일이 아니라, 디렉터의 일이다.

즉 디렉터가 기획자 출신이든, 프로그래머 출신이든, 아티스트 출신이든 관계 없이 저것은 디렉터에게 요구되는 역할이고, 권한이며, 책임인 것이다.



그러니까 일개 기획자 따위는 게임이 재미없어도 책임없어효. 그만 좀 까셈. 즐. ㅂㅂ2~

...

...

...

... 요기서 싹 입씻고 도망치고 싶은 마음은 굴뚝같지만 ㄲㄲㄲ

안타깝게도 새로운 의문이 꼬리를 잇게 된다.

그럼 게임 기획자라는건 대체 뭐하는 놈들인데?

오늘은 대충 운만 띄워보고, 그 이야기는 다음 글에서 ( '')



사족 1.
게임을 디렉터 혼자 만드냐? 기획자도 결국 개발팀의 일원인데 게임의 재미에 책임이 없다고???
... 예리하기도 하셔라 ( --) 이 이야기는 기회가 닿는다면 다른 글에서 ( --)

사족 2.
디렉터가 게임의 재미를 보장하고 책임진다고? '재미를 보장한다'라는게 정말 인간에게 가능한 능력인거임? 그리고 '책임'이라는 건 대체 어떻게 질 수 있는건데?
... 자, 잠깐만. 이것도 다음에 기회 닿으면... (이라 쓰고 도망)

아직은 공력도, 경력도 미천하야... 감히 이런 글을 싸질러놓는 것이 매우 조심스럽기 짝이 없으나...

미흡한 경험에서 우러나오는 주관, 혹은 편견으로 끄적끄적.



IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나 그래스 호핑(grass hopping)이 잦은 곳이다.


거기에 더하여, 역시나 IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나... 좁디 좁다 -ㅁ-; 어찌나 좁으신지 한 두 다리만 걸치면 모르는 사람이 없을 정도.




이러한 업계의 양상은 개발자로 하여금 어떠한 사고 방식을 가지도록 은연중에 강요하게 된다.


혹은,


등등등?



결국 일종의 업계 불문율이랄까, 혹은 약간 거시적인 프로세스같은 것이 발생하게 된다. 이 업계가 유지되는 방식이라고까지 이야기하자면 좀 거창하겠지만 -ㅁ-;

아무튼 나는 나름대로 저런 사고 방식을 가지고 사는 것이 맞다고 생각했다.

결국 그 덕에 업계가 원활하게 돌아가고, 프로젝트는 진행되고, 게임은 개발되어 나오는 것이니까.

팀원이 나가고 들어오는 것에 따라 프로젝트가 흔들린다면, 어디 게임 개발 할 수 있겠는가.


쿨하지? 쿨할까? 쿨할라나?



반대 급부라 할만한 경우를 목격한 적도 있다.

아직도 존속되고 있을는지는 모르겠지만, 소위 '패밀리'라 불릴만한 개발자 그룹(?)이 통째로 이직을 해가면서 단순 팀원의 그래스 호핑이 아닌, 팀 단위의 그래스 호핑을 하는 것을 본 적이 있는데...


따뜻하고 애틋한... 이라기 보다는 우와 뭔가 부정적인 것 같아. 이것도 일종의 뒷담화가 되려나 -ㅁ-;

아무튼 저런 경우를 본 적이 있는데... 글쎄, 결국 그 패밀리가 패밀리의 이름으로 성공적인 결과물을 낸다면 저것도 나름 괜찮지 않을까? 싶기도 하지만, 역시 그 때나 지금이나 난 저런 방식에 대해서는 부정적이다.



그렇기에 역시 개발자가 중심에 두어야 하는 것은 프로젝트의 완수. 사람을 중심에 두어서는 곤란하다... 라고 생각해 왔는데...

솔직히 요즘은 잘 모르겠다 ㄱ-

이 뭐 내가 차가운 도시 남자. 하지만 내 여자에게는 따뜻하겠지? ... 도 아니고 말야, 쿨! 쿨! 쿨! 외치다가 얼어죽겠구만 ㄱ-

그렇다고 동료를 동료 이상으로, 더욱 살갑고 따땃하게 대하면서 살면 세상은 좀 더 아름다와지지 않을까? ... 뭐 이런 이야기를 하려는 것도 아니다.

여전히 개발자에게 있어 프로젝트의 완수를 중심에 두는 것은 맞는 것이라 생각한다.



하지만 이를 위해 개발자가 자기 스스로를, 그리고 동료들을 톱니바퀴로 치부하는 것이 과연 맞을까?

요걸 잘 모르겠다. 그렇게 돌아가는 팀이 과연 좋은 팀일까?



동료에게 동료 이상을 기대하지 않는 조직은 거의 필연적으로 정체된다고 할까, 혹은 말라붙어 버리기가 쉽다.

게임 개발이라는 직업 내에 여러가지 직군이 존재하기는 하지만, 결국 이 직군들 중 어느 하나도 독립적으로 기능하는 것은 없으며, 모든 직군은 서로 얽히고 섥히게 마련이다.

그러나 자신과 타인을 톱니바퀴로 생각하는 팀원들에게 있어 이러한 얽히고 섥히기는... 쉬운 일이 아니다. 심지어 조직이 크든 작든 관계 없이 말이다.

물론 이 얽히는 것을 중간에서 잘 관리해주는 조율자가 있다면, 서로가 서로를 톱니바퀴로 인식하면서도 얼추얼추 프로젝트가 잘 진행되는 것처럼 보이기는 하지만... 글쎄, 내 경험상 이런 방식은 결국 그 조율자를 죽이고 만다 ㄱ-

그리고 조율자가... 죽지는 않고 ㄱ-;;; 혹여 퍼포먼스가 3~40%만 저하된다 하더라도 그 조직은 급속도로 말라붙는다.

혹시 조율자가 없더라도, 팀원들이 애초에 '공적인 피드백'을 자주 할 수 있는 프로세스를 만든다면 괜찮지 않을까...?

글쎄 -ㅁ- 이거이 참 이상적이긴 한데, 인간이라는게 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니라서리... 단적으로 말해 '모든 중요한 결정은 담배터에서 나온다'라는 말이 괜히 있는 것이 아니다.

즉 프로세스만으로는 부족하지 않나 싶다.

결국 조직이 말라붙어 버리게 되면... 직군 사이의 피드백이 사라지고, 누구도 게임의 어떠한 요소에 대하여 책임지지도 - 관심가지지도 않는 사태가 벌어지게 되는데...

뭐 그럼에도 불구하고 프로젝트가 완수될 수는 있다. 제대로 된 게임이 나올 가능성은 좀 많이 낮아지므로, 성공 가능성은 로또 비슷해져 버리지만 -ㅁ-;



그렇다고 공적인 동료가 사적인 영역을 마구마구 넘나드는 조직의 경우에는 반대로... 조직이 외부에 대하여 배타적이 될 가능성이 높고, 조직 내에서는 비효율적인 운영이 이루어질 가능성이 높다.

이러한 조직에서는 사람 하나의 가치가 지나치게 커지는 위험이 존재한다.

팀원의 이탈이 팀 전체의 사기에 악영향을 미칠 수 있고, 반대로 새로운 팀원의 진입은 그 조직이 배타적인만큼 쉽지가 않다.

출혈은 있을 수 있지만, 수혈은 어려운... 이게 뭔가효. 자살해가는 조직도 아니고 ㄱ-

더불어 조직 내에서 서로의 사적인 영역을 넘나들다 보면... 한국에서 특히 보기 쉬운 구도인 '형님 / 아우' 서열이 발생하기 쉽고, '형님에게 굽신굽신 / 아우니까 봐준다'와 같은... 곤란한 상황이 개발 효율을 저해하기가 쉽다.

팀원들 서로가 사적인 친분을 유지하되, 공적인 부분에 대해서는 최대한 드라이하게 접근한다면...?

위에서도 말했지만 인간이란 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니...

그럼 그러한 공적인 부분을 조율해 줄 관리자를 외부에 둔다면...?

배타적인 조직은 그런 관리자를... 죽인다 ㄱ- 혹은 조직이 빠져버리등가 ㄱ- 그래스 호핑~

그래서 결국 프로젝트의 완수보다는 조직의 안녕이 우선 가치로 정립되는 사태가 벌어지고 만다. 뭐 이런걸 소위 개발을 말아먹는 정치라고 불러도 되지 않을까나...



그러니까 결국 정도의 문제인데...



가장 좋은 것은 그 중간일까?

즉, 팀원들 사이에 사적인 친분이 어느 정도 존재하기에 이는 원활한 피드백의 원천이 되어주고...

그러나 이 친분이 공적인 영역을 넘어서지 않아, 일에 대해서는 최대한(!) 냉정하면서도 대등한 관계가 형성되며...

더불어 개발 프로세스는 각 직군들이 최대한 서로 얽히고 섥힐 수 있도록 기능해 주어야 한다.

쯥. 말은 쉽다만... ㄱ-



아직은 나도 이러한 이상적인(?) 구조를 어떻게 하면 형성하고, 유지할 수 있을는지를 잘 모르겠다.

이제야 겨우 '톱니바퀴로는 안되겠는데?'를 깨달은 정도이고...

그렇다고 동료한테 어느 정도까지의 선을 걷어내고, 어느 정도까지의 선을 허용해야 하는 것인지 역시 아직은 잘 모르겠는 모호한 상태이며... -ㅁ-

더구나 그럼에도 불구하고 발생할 수 밖에 없는 그래스 호핑에 대하여... 이런 조직이 어느 정도 가지게 되는 취약성 - 그러니까 결국 대미지를 어떻게 컨트롤해야 할는지도 잘 모르겠다.

... 이거 뭔가 사회 조직론 내지는 경영학(?)을 찾아보면, 이런 이야기가 좀 나와있지 않을까 싶기는 한데 ( --)

현재로서는 현재 내가 지금 몸담고 있는 팀이 나름 줄타기를 해나가는 모습을 관찰하고, 참여하면서 좀 더 생각을 진행하는 수밖에 없을 듯 싶다.



팀 내에서 호형호제가 이루어질 만큼의 사적인 친분이 있으면서, 이것이 공적인 영역을 침범하지는 않고, 잦은 피드백을 반 강제(?)로 보장하는 프로세스... 를 일단 어느 정도는 아슬아슬 줄타기하고 있는 우리 팀은...


이건 아무래도 더 시간을 두고, 조심스레 지켜봐야하지 않을까나 싶다.

아니 잠깐, 방관자로 지켜보겠다는 것이 아니라... 결국은 나 역시 한 명의 팀원으로서.

다들 여기저기서 하도 데인 덕분(?)인지... 그나마 요즘은 덜하지만...

그래도 여전히 종종 울려퍼지곤 하는 유명한 분노의 일갈.

"제발 좀 클베 수준으로 오베하지 말란 말이야~~~ 대체 왜? 어째서? 이렇게 내놓으면 망할거라는거 뻔히 알면서도~~~ 왜 오픈한거야??? 더 개발하고 오픈하란 말이야~~~!!!"

아 예. 저도 종종 그런 일갈에 동참하곤 했었슴미다 ㄳ 이 블록도 뒤져보면 저런 이야기 조낸 많아효 음하하

그런데 달리 생각해보면 실로 의아한 일이다.


4번에서 더 나아가지 못하면, 그냥 분노의 일갈 한번 싸지르고는 즐. 대답은 미궁 속으로~

아 예. 저도 저 이유를 모르겠어서 그냥 싸지르고 나서는 즐때리곤 했슴미다 음하하

하지만 이제는 어느정도 슬슬... 보이는 그 이유에 대한 이야기.

사실 산수만 한번 해보면 간단한 거였어!!!



게임을 왜 만드십니까? 돈벌려고효!

(졸라 훌륭한 게임을 만들어서 개발자의 성취감을 극대화하고, 유저들에게 인생의 새로운 길을 열어주는 경험을 선사하... 블라블라? KIN)

게임 만들어서 돈은 어떻게 법니까? 개발에 들이는 비용 < 수익이 되면 돈버는거죠!

아 그럼 당연하게도 -_- 지극히 당연하게도... 개발에 들이는 비용은 적을 수록 좋고, 수익은 많을 수록 좋은거네효? (이 뭐 장난치는 것도 아니고...)

그런데 수익이 많이 날 것인지... 이 게임이 정말 대박칠는지 여부는... 아무도 모름미다. 개발측이 컨트롤할 수 있는 부분이 아니졈.

(혹여나 이 시점에서... 재미있으면 대박친다! 개발측이 게임을 재미있게 만들면 되겠네! 라고 하실 분들은... 아 이걸 쓰기 시작하면 이게 본문이 되겠다. 걍 KIN)

그럼 결국 개발측에서 명확히 컨트롤할 수 있는 부분은 비용이근염. 그런데 비용은 어디에서 발생하는거죠?

물론... 사무실 임대료, 서버값, 회선값, 컴터값, 회식비 등등이 있지만 그런 듣보잡들은 걍 짜지고... 개발 비용의 가장 큰 부분을 차지하는 것은 인건비!!! 아 그 외에도 마케팅 비용이 있군효. 하지만 그건 개발이 완료되는 시점에서나 나가는 비용이니... 큰 부분이지만 일단 여기서는 홀드. 뒤에서 다시 나옴미다.

결국 사람값이다. 사람값을 줄이면 개발 비용이 줄어든다.

... 여기서 우리는 왜 그렇게 수많은 싸장니마들이 "뮤는 3명이서 만들었다는데?"를 외치는지 알 수 있슴미다. 하지만 요즘 세상에 3명이 만든 게임으로는... oTL

블록 버스터의 세상이 되어버려서리 일정수 이상의 인원은 어떻게든 필요함미다. 그럼 사람값을 어찌 줄이죠?

... 잘 아시면서. 연봉을 깎아버리면 되는거졈. 사람 수는 줄이고! 연봉은 깎고! 일은 많이 시킨다! 정답인거졈. ㅅㅂ



"개발자 착취를 하면 비용을 적게 들이면서 게임을 만들 수 있으니, 충분히 개발한 다음에 시장에 내놓을 수 있는거자나?! 그런데도 왜 만들다가 만 녀석을 오베하는건데?"

... 라는 반문. 그럴싸한데?

그 이유를 추적하기 위하여, 우리는 역지사지의 정신을 발휘하여 개발 비용을 대는 사람. 즉 싸장님하의 입장이 되어 볼 필요가 있다.

다음과 같은 개발 프로젝트를 가정해보자.


12개월의 기간 내내 20명이 필요할 리는 없다. 개발 초기 단계에는 기반 작업을 할 수 있는 5명 만으로 충분하다. 5명으로 시작해서... 3개월마다 5명씩 충원을 한다고 쳐보자.

이 경우 12개월 동안 소모되는 인건비는...


12월이 된 시점에서... 지금까지 3억원을 부었고! 한달에 인건비만 4천만원씩 꼬박꼬박 나가고 있다! 더구나 이제 런칭을 하게 되면 마케팅 비용으로 한 1억원 또 나가야 한다! 과연 이 프로젝트는 총 비용 4억원으로 종결될 수 있을 것인가!

그런데...

"저기요 싸장님하 아직 개발이 완료되지 않았거등효... 지금 런칭하면 망할 것 같아효. 한 반년만 더 연장을..."

6개월 더 개발 진행?!


다음해 6월이면 누적된 총 비용이 5억 4천만원! 6개월동안 더 붓는 돈이 2억 4천만원! 이런 ㅆㅂ 지난 해에는 6개월에 9천만원을 부었는데, 이제는 6개월 동안 들어가는 인건비가 2억 4천만원이라고효?!

그래도 마케팅 1억원 더해서 6억 4천만원으로 어떻게든 총 비용 종결이 되려는 순간...

"근데효 싸장님하... 아무래도 런칭 할 수준은 아니예효. 오베는 한 12월 정도에... 그리고 개발자가 한 10명 정도 더 필요할 것 같거등효?"

...


헥헥... 6개월 더 연장했더니, 그 사이에 3억 6천만원이 또 나갔네효. 지금까지의 누적은 9억원! 그나마 다행으로 12월에 오베 런칭할 수 있다면... 마케팅비 1억원. 총 비용은 10억원~ ㄳ

...

...

...

불쌍한 우리 싸장님 ㅠㅠ

만약 이 프로젝트가 첫해 12월에 성공적으로 런칭했다면 마케팅 합쳐서 총 비용은 4억원이었을 텐데... 1년을 연장 했더니만 런칭까지의 총 비용이 10억원! 기간은 2배인데 드는 돈은 2.5배야!!!

만약 당신이 '음하하하 더러운 개발자 색휘들한테 생흡 빨대 꽂아서 착취하면 1년에 넉넉잡아 5억으로 게임 하나 만들 수 있겠군하~ 여유자금도 1억이나 되니 충분하겠지! 우왕ㅋ굳ㅋ'이라고 생각했던 싸장님이라면...

개발 기간의 6개월 연장을 요청받는 시점에서... 예상되는 총 비용 6억 4천만원으로, 원래 가진 돈 5억원에서 1억 4천만원 오버합니다.


1번을 선택하셨슴미다만... 6개월 더 필요하데효. 개발자도 더 늘려달라는 군효. 예상 총 비용은 10억원으로... 5억원 다 썼고, 빚이 1억 4천만원인데... 이제 3억 6천만원의 빚을 더 져야만 가능하겠군효?


1번을 선택하시는 훌륭한 분들도 계시겠지만... 정신줄 놓지 않은 이상 상식적으로는 2번이 맞을 것 같다. 어라? 잠깐? 2번이라고?

게임이 오베 수준의 완성도를 갖추지 못했음에도 불구하고 런칭을 선택한다고?!

... 네 그렇슴미다 ㄳ



즉 정리하자면 다음과 같다.


어찌하리오. 감당이 안되면 죽이 되든 밥이 되든 런칭할 수밖에 없어효. 망하는 결과가 같더라도 최소한 신체포기각서는 안써도 되니까 ㄱ-

자금이 충분하다면?! 싸장님하가 처음부터 한 100억 들고 시작했다면?

... 그 경우에는 신체포기각서를 쓸 일은 없겠지만서도, 개발 기간을 1년 연장하는 것으로 애초에 예정되었던 개발 비용 4억원에 추가적으로 6억원이 더해져 총 개발 비용은 10억원이 되어버린다. 개발 기간 1년 연장이 과연 6억원을 초과하는 수익을 보장해 줄 수 있을 것인가?!

보장 못 해준다면... 적자임미다. 어라 잠깐! 우리 돈 벌려고 게임 만드는 건데 적자라고?!



이 뭐... 개발이 뒤로 가면 갈 수록 이러지도 저러지도 못하는 상황이 벌어지는 것이다. 게임이 성공한다는 확신만 있다면야, 적자를 보지 않을 수 있다는 확신만 있다면야 거리낌없이 돈을 붓겠지만... 글쎄 세상에 그거 확신할 수 있는 사람은 아무도 없다니까효.

...이미 쏟아부은 돈은 한가득.
...... 게임이 수익을 내기 전에는 회수할 가능성 없음.
......... 하지만 수익을 내려면 런칭을 해야하고, 런칭을 하려면 앞으로 점점 더 많은 비용을 지출해야 함.
............ 런칭하면 반드시 수익을 낼 수 있을 것인가? 그런 보장은 없음.

ㅎㄷㄷ... 이거 어디선가 많이 본 듯한 상황이지 않은가?




물론 이 외에도 수많은 요인이 존재하지만서도... 외부인도 손쉽게 계산해볼 수 있는 산수의 결과만 가지고도 이 정도이다. 그래서 결국 우리는 종종... 분노의 일갈을 지르게 되는 것. 하지만 어찌하리오? 저 쪽도 바보라서 그러는 것은 아닌 것이다.

그래서? 우리는 계속 분노의 일갈을 지를 수밖에 없는 것인가?! 아니면 싸장니마의 불쌍한 사정을 알았으니 걍 닥치고 있으면 되는 건가효?

그래서는 곤란하다. 문제는 해결되지 않는다.

그래서 이것을 해결하기 위한 다양한 방법들이 제시되고 있으니...

1. 개발자들을 더욱 착취한다.

2. 개발자들의 생산성을 극대화할 수 있는 방안을 모색한다.

3. 개발 프로세스를 정비하여, 개발 기간 1년 연장과 같은 재앙을 막는다.

4. 비용이 적게 드는 개발 초기 단계 - 프리 프로덕션 단계의 기간을 늘리고, 그만큼 그 기간에 게임의 프로토타이핑을 철저히 시행하여 검증한다.

5. 일본을 공격한다.



아직은... 요만큼 밖에 보이지 않는다. 아는 사람이 보기엔 이뭐병 수준의 분석일 듯 ㅋㅋㅋ

더구나 다음과 같은 문제들에 대해서는 아직 답을 모르겠다.

"될 성 싶은 나무와 안될 성 싶은 나무는 어떻게 구별하나효? 그 기준을 과연 세울 수 있을까효?"

"그래서 새싹을 자르면 그 개발자들은? 같이 자르는 건가효? 아무리 게임계가 그나마 그래스호핑이 자유로운 곳이라고는 해도... 글쎄효. 한국 사회에서는 좀 안맞을 텐데효?"

뭐 시간이 지나면 더 보이고, 대답이 명확해질 것 같기는 한데...

하지만 역시 말이졈 -_- 말단 개발자에게 이런 경영스러븐(?) 고민을 하게 만드는 사회는 뭔가 잘못되어 있는 것 같지 않나효?!

삼성, LG 등의 쟁쟁한 대기업들이 꽉 틀어쥐고 있는 백색 가전 시장에 진출을 꿈꾸는 한 중소 기업이 있다고 치자. 헌데 이 중소 기업이 제품을 개발하고 출시하는 마인드가 좀 해괴하다.


자... 이 중소 기업의 미래는 어떻게 될까요?

'그래도 운이 좋으면 살아남아 대박치지 않을까?'라는 미칠듯이 긍정적인 자세로 얄팍한 희망을 피력하는 분... 네 좋습니다. 이번주에 꼭 로또를 긁으세효.

까놓고 말해 저건 누가 보더라도 미친 짓이다. 한번 거하게 망해 보려고 억지 발버둥을 치지 않는 이상, 저런 마인드를 가지기도 힘들 것이다.

뭐 이 쯤 되면 '니마 미쳤3?'이나 '니마 그러다가 망해효'같은 이야기를 하는 것도 과분하다. 그냥 엄지를 곧추세우며 외쳐보자.

"대인배시군요! -_-)=b"



하지만 슬프게도... 저기서 백색 가전을 MMORPG로 바꾸고 나면, 저런 대인배가 무려... 졸라 많지효.

수도 없이 고꾸라진다 할지라도, 대인배의 시체를 넘고 넘어 오늘도 대인배는 전진... 아니 제자리 걸음을 계속하지효.

대인배들은 소를 수백억 단위로 잃는다 해도 절대 외양간을 고치지 않아효.

사람들이 빅3에서 배운 점이 하나도 없다는 것이 참 기기묘묘하근염.

님드라, 님들이 상대해야 하는 것은 개발 및 서비스 기간이 10년 가까이, 혹은 넘도록 누적된 리니지, WoW거등효. 그 게임들하고 정면 격돌해야 하거든효.

그 사실 알고 계신건가요? 진짜? 정말로?

얼마 전에 워해머 온라인WarHammer Online이 출시를 2008년 상반기로 미룬다는 뉴스가 발표된 바 있다.

히밤. 레이드 게임이 되어버린 WoW를 외면한지 어언 2년이 가까우니, 그저 워함마만 아기다리 고기다리던 나로서는 '금년은 또 뭐로 떼우라고!'라는 비명을 올리기 딱 좋은 뉴스였는데 ㄱ-

(그래서 결국 다시 WoW에 손을 대버렸음 -_-a 1년 반만에 다시 하려니 진짜 적응 안되네)

저 뉴스를 처음 접했을 때 내가 생각했던 바는 다음과 같다.


그러나 이러한 내 생각에 대한 반론이 하나.


어머나?

돌이켜 생각해보니, 1년의 연기에 대해서 나는 철저히 국내식(?)으로만 추측하고 있었다.

실제로 나는 무려 OBT 직전까지 신규 시스템을 구축하고 있었고, OBT 이후에도 기반 시스템의 개발을 계속했었기 때문에... 1년의 연장은 당연히 개발의 연장이라 생각해버린 것이다.

거기에 손쉽게 빠지기 쉬운 EA 음모론까지 덧붙여서는 자위하며 납득. 쯥. 이런걸 두고 생각이 짧다고 한다 ㅋㅋㅋ

물론 내부적인 사정까지 알 수는 없는 노릇이기에, 정말 내 예상이 맞은 것일 수도 있고, 정말 QA를 1년 정도 더 하려는 것일 수도 있다.

하지만 공식 사이트에 올라온 공지로 미루어 보건데, 아무래도 QA 쪽이 맞는 듯.

... 이라고 할 때, 다시금 떠오른 의문은 다음과 같다.


최소한 내가 아는 한도 내에서는 암울.




... 라는 고전적인 화두에 대하여 여러 성현들이 남긴 가르침은 다음과 같나니,


한줄 요약.


물론 이것은 막연한 동경일 수도 있다. EA Human Story같은 것을 보고 있자면... 그 동네나 우리 동네나 마찬가지로 막장일지도.

하지만 아무리 막장이라 할지라도 외국과 국내의 개발 프로세스에는 크나큰 차이가 존재하나니... QA의 위상이 바로 그것이다.




... 여기까지는 만국 공통.


... 국내에서는 예외가 생길 수도 있지만 -_-a 그건 말장난일 뿐이고, 기획자 없는 개발 프로세스는 없다. 즉 공통.


... 이게 가장 큰 차이이다. 국내에서는? QA 없이 게임을 만드려 드는 개발사가 조낸 많다.

외국에서는 아주 당연한 필수 요소로 인식되고 있는 QA가 유독 한국에서는, '없어도 되는거'라는 인식을 받고 있는 것이다.


... 라는 반론이 당연하다는 듯이 제기되곤 하지만, 다시 생각해 보면 그 반론의 밑바탕에도 'QA는 없어도 되는거'라는 인식이 깔려 있다.

디버깅 없이 프로그램을 출시하는 개발사는 존재하지 않는다. 즉 디버깅 버퍼는 개발 일정에 당연하다는 듯이 포함된다. 디버깅을 '없어도 되는거'라고 생각하는 경우가 과연 있을까?

하지만 게임 자체에 대한 디버깅은...? 그것이 바로 QA일진데... 해괴망칙하게도 국내에서는 자금과 일정이 압박하면 QA 기간을 날려버리고 바로 출시를 해버리곤 한다. '없어도 되는거'가 아닌 이상에야, 필수 요소라면 과연 이렇게 쉽게 날려버릴 수 있을까?

... 묵념.

어째서 애초에 개발 일정에 QA를 포함시키지 않은 것인가?

개발 초기에 6개월을 산정한다고 할 때, 그 6개월 내에 왜 QA 기간을 포함시키지 않은 것인가?

WoW는 5년의 개발 기간에서, 3년을 개발에 투자하고 2년을 QA 및 각종 수정에 투자했다. 즉 전체 개발 일정의 40%가 QA에 할당된 것이다. 하지만 어째서 우리는 기껏 할당해봐야 1%, 그나마도 그걸 0%로 못만들어 안달인 것인가?

여기에서 국내와 국외의 가장 큰 차이가 벌어진다고 생각한다. 만드는건 똑같이 잘 만들어 놓고는... 마지막에 다듬는 기간 - 그 기간이 2/5에 육박하니 '마지막'이라 하기엔 좀 애매하지만 - 을 넣고 안넣는 것에서 최종 결과물의 퀄리티 수준이 달라지게 되어버리는 것이다.


... 라는 생각이 머리 속을 스치신다면. 그럼 프로젝트 런칭하지 마시길.

QA 없이 성공하는 게임도 물론 있다. 세상에는 예외가 있게 마련이니. 하지만 절대 다수의 게임들은 패망하는 법이고, 피튀기는 블러드 오션 속에서 앞으로는 점점 더 힘들어져 가게 된다. QA없는 성공은 로또가 된다.

수십명이 수년간 동원되어 로또에 기대느니... 차라리 처음부터 프로젝트를 런칭하지 않는 쪽이 더 낫다고 생각한다. 이 쪽이 수십억을 퍼붓는 입장으로서도 생 돈 날리지 않게 되는 길이지 않을까?


... 라고 하신다면, 우리 솔직해 보아효. 우리나라에 CBT가 어디있나효?

우리나라의 CBT는 사실상 OBT다. OBT는? 무료 서비스. 그리고 상용화가 바로 유료 서비스.

CBT가 실종되어 버렸다는 것은 누구나 알고 있는 사실이지 않은가? 즉 CBT 후의 QA라는건 OBT 후에 QA 하겠다는 것과 마찬가지이다. 그 결과는? 당연히 로또.



외국 게임을 플레이 하면서 종종 Credit을 보곤 한다. 그 때마다 '어엄 부러워라'라는 생각이 드는 것은 QA의 이름을 달고 수페이지의 이름들이 주르륵 올라갈 때... 국내의 개발력과 국외의 개발력 차이는 바로 이 한 끗 차이에서 비롯되는 것이 아닐까.

혹은 이 역시도 막연한 동경일지도...?

어디 이 동경을 무참히 깨주실 해외 개발사에 재직중이신 분 없으신가효 ;ㅁ;

어찌되었든... 결론은 워함마 온라인이 내년에 나온다능거. 흑흑.

그린스킨이냐 카오스냐! 고민의 시간도 길어지겠군하. 아 제국이나 드워프 따위는 애초에 고려도 아니하고 있으니 즐. ㄲㄲㄲ

로직과 스키마라는 분류를 통해 우리는 여러가지를 설명해 볼 수 있다.

전반적인 개발 프로세스에서부터, 단일 스펙의 설계에 이르기까지. MMORPG에서부터 단순한 슈팅 게임에 이르기까지. 로직과 스키마의 문제는 규모와 장르에 구애받지 않고 개발 전반부에 걸쳐있기 때문이다.

(물론 그렇다고 해서 모든 것이 설명되지는 않는다 -_-a 세상이 그리 단순한 것이 아니라서리... 쯥 ; 예를 들어 틱택톡같은 퍼즐 게임의 경우... 이건 뭐 스키마가 가지는 비중은 거의 없다시피 하고 -.-; 로직만으로 모든 생각을 진행하게 된다)

아무튼 설명이 되는 것 중에서... 로직과 스키마 연작 포스트의 마지막으로, 간단한 기획 프로세스를 한번 들여다 보도록 하자.



이전 포스트 말미에서 언급한 바와 같이, 인간은 로직보다는 스키마에 먼저 꽂히는 동물이다.

새로운 게임이 출시되었을 때, 그 게임의 스펙이나 시스템을 먼저 보게 되는가? 아니면 스크린샷이나 플레이 영상을 먼저 보게 되는가?

나는 스펙이나 시스템을 먼저 보는데... 라고 한다면 이런 게임 오탁후 저리갓 쉭쉭! (이라 해놓고는 나도 스펙을 먼저 보지만 흠흠)

일반적으로는 스크린샷을 먼저 보게 마련이다. 즉 스키마에 먼저 꽂힌다.

새로운 게임을 기획할 때에는...?

머리 속으로 로직을 먼저 구상할까? 완전히 추상적인 차원에서 A와 B가 머리 속을 휭휭 날아다니며 게임의 규칙을 형성한다...? 퍼즐을 만드는게 아닌 이상에야 -_-a 이런 경우는 매우매우 드물 것으로 예상한다.

인간이란 원래 그런 식으로 생각하게끔 되어 있는 생물이 아닐 터.

최소한 나는 그런 식으로 생각하지 않는다. 나 역시 스키마에 먼저 꽂힌다.

새로운 게임을 기획할 때에도, 그 게임의 로직을 먼저 떠올리는 것이 아니라 스키마에 먼저 로망을 불태우나니...

거기에서부터 시작하여 스키마 -> 로직 -> 스키마를 순환하는, 다음과 같은 게임 기획 프로세스가 정립된다.

(뭐 이게 정답은 아니라는 점에는 다시금 유의를...)



*** 이 예시는... 2004년 성게님의 [마린블루스]를 둘러보다가 문득 떠오른 착상을 기반으로 하여, 한 30분 만에 뚝딱 대충 구상해봤던 게임이다.
구체적인 게임 기획이 이루어진 것은 아니고, 내 안에서 스키마 -> 로직 -> 스키마가 어떻게 순환하며 하나의 게임이 상을 갖추어 나가게 되었는지에 대한 예시일 뿐이니까리 '졸라 재미없겠는데?' 뭐 이런 태클은 정중히 사양 ( '') ***



1. 스키마에 꽂히다

게임 기획자는 일과 생활을 분리하기가 참 애매한 직업이다. 일상 속에서 게임을 플레이하든, 영화를 보든, 만화를 보든, 음악을 듣든... 그 모든 것을 게임 기획으로 연결하여 생각하게 되는 것이 기획자라는 생물. 그러기 싫어도 자연스럽게 그렇게 된다 ;ㅁ; (그래서 개발자가 되면 더 이상 순수하게 게임을 즐길 수 없게 된다는 이야기가 나오는 것이다 흑흑)

게임이 게임 기획으로 연결되는 부분에 대해서는 예전에 찌질거려 놓은 글을 참고할 수 있을테고, 그 외에도 영화를 보다 보면 '우오 3만마리의 오크떼와 돌격하는 기병들! 저 로망을 게임으로 만든다면... 블라블라'같은 생각이, 만화를 보다 보면 '역시 우주를 가로짓는 로망은 총알보다는 무수한 빔이라니까! 이걸 게임으로 만든다면... 블라블라', 혹은 음악? '둥둥둥~ 그래 이런 음악을 BGM으로 깔고 고딕 양식의 웅장한 성들이 좌악 펼쳐지는 공성전이... 블라블라'

뭐 대충 이런 식이랄까?

새로운 게임을 만들어내는 착상은, 로직보다는 스키마에서 먼저 시작되는 것이 일반적이다. 다른 어떤 문화 매체를 통해서든 자극을 받았을 때, 그 자극을 그대로 계승하는 게임의 상이 번뜩 떠오르게 되는 것이다.

그리고 내가 2004년에 꽂혔던 스키마는 다음의 만화에서 비롯되었다.


이 만화를 봤을 때 내 머리 속에 꽂힌 스키마는 다음과 같다.


물론 이것은 나의 경우이다. 저 만화를 보고 아무런 꽂힘이 없을 수도 있고, 나와는 다른 스키마가 떠오를 수도 있다.

이전 포스트에서도 언급했던 바와 같이, 스키마에는 정답이 없고 철저하게 주관적인 것이니까. 아무튼 나는 저런 스키마가 꽂혔고, 거기에서 착상을 얻었다.

새로운 게임의 기획이 스키마에서부터 시작되었다.



2. 기본 규칙의 선택

그럼 이제 '도시를 파괴하는 개구리 괴수'라는 스키마를 풀어낼 수 있는 게임의 기본적인 규칙을 선택해 볼 단계이다.

기본 규칙의... '선택'이라는 점에 유의. 아직은 로직이 끼어들 단계가 아니고, 스키마를 발현시킬 수 있는 다양한 병렬적 방법론 중에서 가장 효과적인 표현이 가능할 수 있을 것이라 생각되는 규칙을 '주관적으로' 선택하는 것이다.

따라서 스키마에 정답이 없듯, 이 선택에도 정답은 없다. 소위 꼴리는 대로... 랄까.

그래서 내가 선택했던 기본 규칙은 다음과 같았다.


기본 규칙을 선택하는 단계에서는 아직 스키마가 끼어들 여지가 충분히 존재한다. 게임의 기본 규칙이란 결국 머리 속에 꽂혀 있는 스키마의 상을 게임이라는 형태로 풀어놓는 것이기 때문이다.

하지만 이러한 기본 규칙까지 정립한 후에는... 이제 스키마를 버려야 하는 단계가 온다.



3. 로직의 구축

개구리 괴수에 꽂히는 것으로부터 시작하여, 그 상을 게임으로 풀어낸 기본 규칙을 정립하였으니, 이제는 구체적으로 게임의 로직을 고민할 때이다.

이 단계에서는 개구리 괴수의 상을 철저하게 배제하고, 최대한 머리 속을 dry하게 만들어야만 한다. 로직 구축의 단계에서 스키마가 끼어들면 어떤 대환란이 벌어지는지는 이전 포스트를 참고하시압. 즉 개구리 괴수의 상은 훠어이 훠어이 내다 버리고, 기본 규칙의 위에서만 로직을 구축해야 한다.

빌딩숲은 '판'으로 추상화한다. 개구리 괴수는 'PC'로 추상화한다. 그럼 결국... 다수의 늘어선 판 위를 1칸씩 이동하는 PC, 이 PC가 한번 올라선 판은 사라지며, 최종적으로 남은 판 위에 선 PC가 승리한다는 기본 규칙이 성립된다.

이 기본 위에 온라인 게임으로서 재미를 더하기 위한 온갖 로직을 더해보도록 하자. 다만 유의할 점은 덧붙이는 로직이 기본 규칙을 침해하면 안된다는 점.


... 기타 등등. 뭐 애초에 본격적으로 기획을 한 것은 아니고, 브레인스토밍을 가볍게 해 본 정도의 수준이었기 때문에 여기까지만. 예시는 예시일 뿐이다 ( '') 만약 실제로 게임을 만들게 된다면, 필요한 로직은 여기에 언급된 내용보다 100배 정도는 더 많이 필요하게 될 것이다.

주목해야 하는 것은 그런 점이 아니라... 추상화의 차원에서 로직이 구축된다는 부분. 각종 요소들을 최대한 dry하게 추상화하고, 이 상태에서 객체와 객체 사이의 관계에만 집중해야 한다는 것이 요점이다.

만약 여기에 엄하게 스키마를 끼워 넣어서 '개구리 괴수라면 빌딩에서 떨어질 때 혀를 쭈욱~ 내밀어 빌딩에 매달릴 수도 있지 않을까?' 뭐 이런 생각을 하면서 삼천포로 빠지기 시작하면... 끝이 나질 않게 되어 버린다. 대환란에 대한 언급은 따로 더 하지 않겠심.

자~ 스키마의 유혹(?)에서 벗어나 로직의 구축에 성공하였다면...?

그럼 이제 다시 스키마의 품으로 돌아갈 수 있게 된다.



4. 스키마로의 복귀

잊혀졌던 개구리 괴수가 다시 부활할 시간이 왔도다!!!

로직을 모두 구축하였다면, 이제야 비로소 그 위에 스키마의 외피를 입힐 수 있게 된다.


뭔가 삼천포로 많이 빠져버렸는데... 아무튼 구축된 로직에 스키마의 외피를 입혀보도록 하자.


... 기타 등등. 뭐 스키마는 아무래도 좋으니 내키는 대로... 라고는 하지만서도, 위에서 언급한 함정에는 유의할 것 ( '')

처음에 꽂힌 스키마가, 기본 규칙을 통해 게임화되고, 로직을 그 뼈대로 삼아, 이제 비로소 최종적인 스키마를 입고 하나의 게임이 기획되었다. (물론 제대로 기획하려면 여기 100배 정도는 추가 분량이...)

이것이 바로 '이런 게임이 있다면 재미있을텐데...'라고 대충 쉽게 망상하는 것과, 개발자가 게임을 구상하는 것의 차이. 뭐 되게 거만해 보일는지도 모르겠지만... 생각의 방법론이라 할 수 있다.

...

...

...

하지만 정작 만들어 놓고 보니... 으 눈치채셨슴미까? 어디서 되게 많이 본 듯한 게임이 나와버렸군효 ㄱ-

<무슨 게임일까효? 펼쳐보아효>

뭐 이건 내가 내츄럴 본 표절 기획자라서 그런거니까 ( --) 대충 그러려니... ( --)



로직과 스키마 연작의 예고편 포스트를 기억하시는지? 프라모델의 제작에 대한 비유를 마지막으로 한번 더 해보자면 다음과 같다.




물론 이러한 스키마 -> 로직 -> 스키마의 순환 구조는 '내 방법론'이다. 이게 정답은 아닐거라는 점, 이보다 나은 방법론은 얼마든지 있을 수 있다는 점에 무조건 유의.

하지만 그래도 로직과 스키마를 고민하는 개발자에게 참고 정도는 되어줄 수 있을 거라고 생각한다.

여기까지... 로 해서리 되도 않는 뻘소리로 점철된 3연작 끗.

...

...

...

하지만 end가 아닌 and로?

이미 이전 포스트에서 댓글로 여러가지 이야기가 오간 것에서 알 수 있듯이... 이 개념은 완벽하지 않다.

더 많은 개발자들이, 더 치열한 고민을 통해, 더 세밀한 세분화를 통해 개념을 확장해 나아가고 발전시킬 수 있기를 :)

한 손에는 로직을, 한 손에는 스키마를 들고 게임에 어떻게 접근할 것인가?

하지만 얼핏 보기에는 게임을 굳이 이렇게 2가지 개념으로 쪼개는 것이 쓰잘데기 없는 개똥 철학처럼 보이기도 한다. 특히나 유저 입장에서는 하등 쓸모가 없는 분류랄까?

당연한 일이다. 유저가 접하는 것은 이미 로직과 스키마가 결합된 최종 단계의 결과물이니까, 이 녀석을 애써 거꾸로 다시 분리해서 생각하려 드는 것은 오히려 더 힘들 뿐이다.

하지만... 아직 결과물이 나오지 않은 개발 단계에서, 개발자에게는 이러한 개념의 분리가 매우매우매우매우매우매우 중요하다. (특히 기획자라면 이걸 잘 쪼개서 역기획서를 작성할 수도 있어야 한다)



개발을 진행 중인 상태에서 이 둘을 분리하지 못하는 경우... 다음과 같은 대환란이 벌어지게 되나니...


OK! 거기까지! 이 싸움은 결코 끝나지 않는다. 왜? 정답이 없으니까.

이 상황에서 개발자A의 생각에 동조해서 '그래 좀 이상하지'라고 생각하고 있다거나, 개발자B의 생각에 동조해서 '뭐 어떻게든 네크로맨서 힐러를 만들 수도 있을거 같은데?'라고 생각하는 사람이 있다면... 낚이셨슴미다 파닥파닥.

예문에 나와 있는 개발자들의 대화는 완전히 잘못되어 있는 것이기 때문이다.

로직과 스키마가 혼용되어, 로직의 문제에 스키마가 끼어들고, 반론의 근거로 사용되고 있다. 즉 애초에 제기된 이슈는 로직적으로 결론을 내야 하는 부분인데, 정작 논의는 스키마의 차원에서 진행되고 있으니... 애초에 핀트가 어긋나 있는 것이다.

더구나 스키마에는 정답이 없다. 이것을 가지고 '옳다'와 '그르다'를 가리려 들면... 끝이 없다. 네크로맨서가 힐링을 하면 이상하다고 생각하는가? 나는 그렇지 않다고 생각한다. 내 생각에 동조하는가? 나는 이상하다고 생각한다. 정답? 일관성? 그딴건 스키마의 세계에서는 없다.

그러므로... 밑줄 쫙. 개발자는 로직을 먼저 생각하고, 스키마를 나중에 덧씌운다.

파티 플레이 패턴을 구성하기 위하여 8개 클래스 내에 다양한 역할을 분배하는 것은 전적으로 로직의 문제이다.

만약 8개 클래스를 A, B, C, D, E, F, G, H라고 추상화 해버린다면, A ~ G에 역할 분배를 마치고 마지막으로 남겨진 역할인 힐러를 H 클래스에게 할당하는 데에 아무런 문제가 없다. 즉 로직의 차원에서 정답은 이미 나와 있는 상태이다.

'하지만 남겨진 H 클래스가 네크로맨서인데...?' 라고 의문을 제기하면 다시 대환란으로 돌아갈 뿐. 애초에 개별 클래스에 역할을 분배하지도 않고, 즉 로직적인 체계를 정립해놓지도 않은 상태에서 클래스에 네크로맨서라는 구체적인 스키마를 덧씌운 것 자체가 문제인 것이다.

개발자는 로직을 먼저 생각하고, 스키마를 나중에 덧씌운다.

로직은 추상적 차원에서 이루어지는 논리의 문제이므로, 여기에서는 스키마를 완전히 배제하고 생각해야 한다. 즉 이 때 클래스 8개는 A, B, C, D, E, F, G, H여야 하는 것이다. 여기에 어줍잖게 'A는 전사이지 않을까...?' 뭐 이런 생각을 하는 순간, 수만의 정의와 수만의 편견과 수만의 로망에 의해 모든게 망가진다.

A, B, C, D, E, F, G, H로 놓고 모든 역할 분배를 마쳤다면, 즉 로직적 체계를 다 세웠다면... 스키마는 그 때부터 덧씌우는 것이다. H 클래스에 힐러 역할이 주어졌는가? 그럼 H 클래스에 프리스트Priest라는 스키마를 씌우면 적절할 것이다. 아 F 클래스에게는 디버퍼Debuffer와 도터DOTer의 역할이 주어졌는가? 그 녀석이 네크로맨서를 하면 적절하겠구나.

아 프리스트가 힐링을 하고, 네크로맨서가 디버퍼를 하는게 마음에 들지 않는다고? 이미 로직은 결정되어 있으니 스키마는 아무래도 좋다. A, B, C, D, E, F, G, H에 마음껏 적절한 클래스를 배분하시압.

(물론 세상일이 이렇게 간단하지는 아니하야 로직과 스키마가 깔끔하게 분리되지 않는 경우도 발생할 수 있으며, 실제로 혼용될 수밖에 없는 경우도 생기지만... 그건 예외적 상황. 여기에서 이야기하는 분리는 기초의 문제이다. Basic~ Basic~)



정리해 보자면 다음과 같다.

개발자는 반드시 로직과 스키마를 분리하여 생각할 줄 알아야 한다. 즉 추상적 차원에서의 문제와 현실적 차원에서의 문제를 분리하고, 생각을 이원화할 수 있어야 한다. 그리고 일단 분리된 개념은 서로의 영역을 침범하지 말아야 한다.

개발은 반드시 로직이 선행, 스키마가 후행되는 형태로 이루어져야 한다. 로직에는 정답이 있지만, 스키마에는 정답이 없다. 정답이 없는 것을 미리 결정해 놓은 후에, 거기에 규칙을 거꾸로 짜맞추는 것은 어불성설. 반드시 정답을 미리 정한 후에, 그 정답을 어떻게 하면 예쁘게 꾸밀 수 있을 것인지를 고민해야 한다.

즉...

프레임을 먼저 구상하고 외부 장갑을 덧씌워야 한다. 만약 외부 장갑을 먼저 만들고, 거기에 프레임을 맞춘다면...? 겉으로 보기에는 삐까번쩍한 외양이 나올 수도 있다. 하지만 가동성은 포기해야 할 것이다.

문제는 우리가 가만히 세워 놓고 감상하기 위한 주석 피규어를 원하는 것이 아니라는 점이다. 가동성과 외양이라는 두마리 토끼를 모두 잡을 수 있는... 동전줍기 자세같은 것을 잡아놓고 낄낄댈 수 있는... 사용자와의 interaction이 가능한 프라모델을 만들어야 - 게임을 개발해야 할 것이 아닌가?



그럼에도 불구하고 -_-a

인간이란 로직보다는 스키마에 먼저 꽂히는 동물인지라... 모든 것을 추상의 차원에서만 생각해야 한다는 것은 생각만큼 쉬운 일은 아니다.

무엇보다도 로망은? 내 로망은 어떻게 되는거야?!

...라는 외침에 대한 대답은 다음 기회에~

게임을 바라보는 수많은 관점 중에는 로직(logic)과 스키마(schema)를 통해 접근하는 방법이 있다.

로직? 스키마? 일단은 이 두 단어의 정의부터 하고 보자.



정리하자면... 로직은 게임의 내적 규칙, 스키마는 그 내적 규칙에 덧씌우는 외피라 할 수 있다.

다른 용어가 더 적절할는지도 모르겠는데... 우리 팀에서는 '로직과 스키마'라고 부르고 있으니, 그걸 그대로 써보자 ( '')



로직은 말 그대로 게임의 규칙을 구성한다.

하지만 게임의 모든 내적 규칙을 로직이라고 정의할 수는 없다.

예를 들어 '우리 게임은 파티 플레이 중심으로 패턴이 구성되게끔 한다'와 같은 규칙은 로직의 부류로 들어가지 않는다.

어째서? 저것 역시 게임의 규칙임에도 불구하고?

그 이유는 저 규칙이 파티 플레이와 솔로 플레이의 병렬적 관계 위에서 선택된 것이기 때문이다.

반드시 파티 플레이 중심어야 할 필요가 있는가? 솔로 플레이 중심이어서는 안될 이유가 있는가? 파티 플레이와 솔로 플레이 중 어느 쪽�