Field's Nest

생산성 = 툴 이 아니다.

앞선 글에서 생산성으로 시작해 툴에 대한 이야기를 했고 또 툴 계획을 짜라고 시키긴 했지만..... 미안하다. 내가 살짝 사기친거다 :-p

진짜로 아무 개념 없이 툴 계획부터 세우는 것 보다 사실 먼저 해결해야 할 더 중요한 문제가 있다.

도대체 생산성이 뭔가?

(항상 말하지만  ~ 성, ~ 감 같은 말은 스스로 객관화 하기 전까지는 남발할 말이 되지 못한다.)

어쨌든 말을 봐서는 많이/빨리 만들 수 있도록 보조하는 것으로 보이는데, 도대체 어떻게 해야 생산성이 늘어날까? 생산성에 대해 언급할 때 다들 툴에 대한 이야기를 먼저 하는데, 툴만 있으면 되는건가? 그것도 WYSIWYG(What You Seeing Is What You Getting : 보이는대로 얻게 된다)의 원칙에 입각해 우아한 UI까지 뽑아내면 좋은 생산성을 갖춘 것일까?



언제 생산성의 문제를 겪게 되는가

당연한 이야기지만 인력이 애초에 부족하다면 당연히 생산이 불가능하다. 아아, 중국에다가 외주 주면 된다고? 외주의 단어 정의를 잘못알고 있나 본데, 여기 위키피디아에 걸어놔도 부끄럽지 않을 용어 풀이를 하나 해 주겠다.

외주
원하는 기한에 원하는 품질대로 물건이 납품될 수 없는 행위.
기한이나 품질 둘 중 하나를 포기하면 당연히 나머지는 얻을 수 있다. :-p

처음 만드는 프로젝트라면 죽어도 외주 줄 생각을 말도록. 관리가 어려운 나머지 스스로 그 물량을 다 채워 넣는게 더 빠르고 품질도 좋은 경우도 많다. 망할.

어쨌든 외주도 인력인 건 확실한데, 왜 인력이 있는데도 생산성이 낮은 경우가 있을까?



해결책은 관리다?

외주일 경우도 마찬가지지만, 보통은 게임 만들 때 각각의 개발자들에 대해 관리자(각각의 팀장이라고 보자)라는 사람들이 있다. 가능한한 원하는 시간 내에 원하는 품질의 물건을 얻기 위해 들어가는 사람들인데 당연히 필요한 사람들이며 이들의 가치를 의심할 필요는 없다. 원래대로라면 가장 중요한 내용들을 결정해 주는 사람들이니까.

그런데 자세히 보면 진짜로 중요한 것만 결정하는 관리자는 드물다. 주변 사람들이 보기에는 워커홀릭이나 각종 디테일한 것들에 대해서 까지 신경쓰는 관리자나, 아예 아무것도 결정하지 않는 관리자도 있다. 전자는 반감을 얻거나 스스로 일에 치여 죽을지경에 이르게 되고 개발 파이프라인을 동결시킨다. 후자는 관리자 기능을 제대로 하지 못한다.

일단 관리자 기능을 못하는측의 문제를 차치해 두고 전자쪽의 문제를 살펴보자. 확실히 후자쪽이 어쨌든 전자쪽 보다는 문제가 적다. 품질은 저하되어도 생산성을 직접 저하시키지는 않으니까.

그런데..... 개발 파이프라인을 동결시킨다고? 그럼 생산성이 저하 되잖아. :-(

더군다나 특정 작업이 다른 작업에 대해 시너지를 발생시키는 경우가 발생하면 사태는 더 심각해진다. 그래픽 작업이 완료되지 않으면 게임상에 띄우고 테스트를 못해본다던지, 무기를 하나 고쳤더니 스킬 체계를 다 뜯어고쳐야 한다던지 하는 사태 말이다. 생산성이 낮은 수준이 아니라 병목으로 인해 책임감이 강한 관리자는 노이로제에 걸리기 쉬워진다. 알아 누워버리면 저절로 해결될 것도 아니고......

(물론 개중에는 가장 올바른 관리자의 모습 - 애초에 원하는 품질을 명확히 제시하고 대부분 실무자에게 맡겼다가 돌아온 품목이 자신이 제시한 형태에 맞으면 무조건 OK 하는 것 - 을 갖추는 경우도 있지만, 세상이 다 그렇듯 좋은 사람은 정말 없다.)



원래 인간은 믿을 수 없다! 개발 시스템만이 해결책이다?

음. 그럼 그 개발시스템을 어떻게 만들어야 되는지 나에게 설명해 주면 참 좋겠다. :)

세상에 황금 열쇠는 없다.

병목이 발생하면 발생하는 거고, 몇 명의 관리자가 세부 결정까지 한다면 관리자가 수십명이 되어봤자 개발자 전체가 다 놀고 있는 사태가 발생할 수가 있다. 관리자들의 능력 신장이 발생해 중요사안이 아닌 모든 것을 무시하고, 무엇이 중요사항인지 판단할 근거가 명확히 공유하지 않는 한, 어떤 시스템도 생산성 문제를 해결해 주는 것이 되지 않는다.

자, 여기서 '중요사항이 무엇인지 판단할 근거 공유.' 우선 이게 중요하다. 철칙. 철칙을 정리한 바이블. 그러니까 기획서라는 이야기인가? 디테일이 너무 잘 정리되어서 완전한 기획서가 있으면 된다고?



게임은 개발 과정에서 끊임없이 변해간다.

아무리 잘난 기획자라도 프로젝트가 크면 진짜로 게임이 완료된 모습의 디테일 전체를 처음부터 상상하지는 못한다.
온라인 게임이면 사태가 더 심각하며 매일같이 버그픽스만 하는 것이 아니라 UI 개선이나 밸런스 패치, 신규 컨텐츠 업데이트 등등을 하게 된다. 그래서 그놈의 기획서는 결국 조금씩 고쳐지고 누구도 고쳐진 '문서' 따위에는 관심 없기 때문에 정확한 판단기준 없이 작업하게 되는 경우도 많다.

그러나 다시 생각해 보도록.

잘난 기획자는 프로젝트가 커도 대충의 그림을 끝까지 유지시킬 수가 있다.

여기서 대충의 그림이라는 건 가능한한 적은 금칙과 명확하되 앞으로 절대로 수정할 일이 없는 몇 가지 짧은 규칙(물론 외압(윗분)에 의해 변경 되는 경우가 많아서 돌아버리겠지만. 그건 뭐 둘째치고)을 의미한다. A4 용지 200장짜리 기획서는 어디서 누가 뭘 고쳤는지도 모르지만 A4 용지 5장 짜리 '중점 기획서'는 금방 외울수가 있다. 어쩌면 외주하는 사람도 외울 수 있을지도 모른다. :)

그리고 이 규정만 맞다면 나머지는 서로간에 전혀 신경쓸 필요가 없는 파트로 나뉘어져 다시 각각의 파트에 맞는 20장씩의 애드온만 붙이면 충돌 없이 개발하는게 가능한 해피한 상황을 만들 수도 있다. 관리자가 원하는대로 제때에 찍혀 나오는 물품을 상상해 보라. 생산성에 대해 말하자면 세상에 그보다 더 해피한게 어디있나. :)

그런데 도대체 어떻게 해야 '중점 기획서'를 A4용지 5장으로 축약해버릴 수가 있지? MMORPG인데? 그냥 '와우처럼 만들어요.'라고 써있는 문서 한장을 가져가면 된다는 소리인가? :-(



생산성 = 직교성

중점 기획서는 얇게. 부분 기획서(본인의 경우에는 이를 레퍼런스 가이드라 지칭한다.)는 두껍게.

이 묘기를 위해서 꼭 필요한 부분이 직교성의 유지다. 역시 ~성 의 단어이므로 단어풀이를 뒤에 더 해야겠지만 내가 하는 것 보다 더 좋은 것은 책이겠지.

프로그래밍 관련 책자를 읽는 취미가 있어 직교성이라는 단어에 대해 아는바가 있다면 이 말 뜻을 이해하기 쉬울 것이다. 특히 문법형 스크립트랑 관련 있다면, Code Complete(2판)라는 책자를 반드시 읽어보도록. 아니, 문법형 스크립트를 절대로 사용하지 않을 기획자도 좋다. 무조건 읽어라. 프로그래밍 언어 아무거나 하나 알고 읽으면 더 좋지만 몰라도 읽어라. 읽어서 익혀라. :)

그 중 생산성에 직결되는 부분만 추가로 풀어 설명하자면 다음처럼 축약 된다.

모든 생산성의 원칙이 시작되는 장소에는 직교성의 원칙이 있다. 그리고 직교성의 문제가 해결되면 생산성은 인력 수에 정비례하여 증가하게 된다.

(물론 이런 말이 직접 쓰여있지는 않다. :-p 그렇다고 내가 완전 쌩 개사기를 치는 건 아니니 꼭 읽도록. 아니 내가 사기치는 거면 어떤가. 책은 읽으면 무조건 도움이 되는데. 어쨌든 여기에 대한 해설은 직교성에 대한 언급과 함께 나중에)