Field's Nest

생산성은 중요하다.

생산성이라는 화두가 던져지기 시작한 시기가 짧다는 것은 꽤나 부끄러운 일이다.

물론 싱글 플레이 게임을 만든다면, 완제품을 그냥 닥치고 만들어버려 완성하는데에 소요되는 비용이 툴을 만들고 그에 상응하는 길이만큼 만드는 비용 보다 쌀 가능성이 있으며, 그렇다면 별 생각없이 만드는게 정답이다. (폭포식의 개발방식을 확실하게 규정하고 계획 수정이 없도록 해야 하지만)

근데 메이져한 변화 없이 후속작을 만들려고 생각한다면? 또는 온라인 게임이라면?

우리나라는 온라인을 기반으로 하고 있다보니 오히려 다른 나라들 보다 '툴'의 사용 시간이 더 길며, 실질적으로 패치의 서비스를 고려하지 않고 게임을 만드는 건 미친짓이 된다.

게임 다 만들었다고 땡 치고 파티 열고 난리 부르스를 떠는게 아니라 오픈베타하면 서버가 터질까 조마조마하는 경험이 더 많은 나라이니만큼 하나의 완제품 보다는 서비스 진행 중인 상황에 더 신경써야 하며 그만큼 유지보수와 컨텐츠 추가를 무지 중요시 해야 했을 건데.......

GPG에 가 보면 프로그래머가 툴을 만들고 툴을 사용한다는 소리가 나온다.
프로그래머가 스크립트를 도입시키고 프로그래머가 스크립트를 사용한다는 소리도 나온다.

이 뭐임미?!

아니, 툴 계획을 세우고 스크립트 사용 계획을 세운 사람들은 어쩌고?

....... 아니 잘 읽어보면 뭔가 이야기의 앞뒤가 맞는 것 같다. '쉽고 편하게 만들지 않으면......' 이라는 전제가 붙는다. 그렇구나. 쉽고 편하게 만들지 않은 툴은 결국 프로그래머만 쓸 수 있는게 되는 구나. 당연하지.

잠깐. 도대체 왜 프로그래머가 계획을 세우는 거지?!!!!!



툴이나 스크립트의 중요성은 상당히 당연한 것이다.

블리자드가 강력한 컨텐츠를 다른 MMO들 보다 훨씬 빠른 속도로 제공하는 건 그놈의 생산성이라는 걸 보장했기 때문이며 그 사실은 그들 스스로도 자랑스러운 부분이라 밝힌 내용이다.

자. 60명의 컨텐츠 기획자가 있다고 해보자.

모두 모여서 퀘스트를 만드세요 하고 내버려두면 뭐가 나올까?

음...... 모여서 업무 시간에 스타크래프트를 너무 한 나머지 프로게이머가 나올 수도 있고 혈맹을 만들어 리니지 군주라도 하나 나올 수 있겠지만......
아마 퀘스트는 안나올 것이다. :-(

여기에 등장할 것이 스크립트나 툴. 아니면 계획인데...... 아까 60명이라고 했으니 틀림없이 계획은 아니다.
60명의 기획자는 절대로 계획을 세울 수 없다. (싸움나거나, 같이 놀거나지.)

스크립트를 준다면 한 사십명이 일을 안한다.

슬프게도 이건 사실이다. 맙소사. 스크립트 언어를 구사할 줄 아는 기획자가 얼마나 없는지 gpg에서 스크립트 언어하나 다룰 줄 아는 기획자를 만나면 행운이라고 생각하라는 소리가 돌아다닌다.

툴이 준비된다면 그제서야 작업이 돌아갈 수 있다. 음....... 그럼 툴을 만들어야 겠군?



근데 왜 툴 계획은 없지?

근데 툴을 어떻게 만들지? 워 쓰리 툴이 짱 좋다고 들었으니 그냥 프로그래머 에게 던져주고 '베껴 주세요' 하고 말하면 되나? 근데 우리 게임은 액션 아니었어?

다시 gpg를 돌다 보면 프로그래머들이 툴의 사용 편의에 대해 고민하는 웃지 못할 모습들이 보인다.

세상에.

게임 내부의 실행 로직에 대해 고민하고 게임의 프레임과 네트웍 레이턴시를 걱정하며 실제 게임을 만들어가야 할 고급 인원들을 그들 스스로가 사용하지도 않을 - 근데 안타깝게도 그들이 직접 사용하고 있는! - 툴의 사용 편의 때문에 고민하게 만들다니. 이런 낭비가 있나.

고객을 개발에 끌어들인다는 XP의 방식은 전체가 허황된 것은 아니며, 꼭 진짜 사용자가 아니더라도 계획을 세울 수 있는 입장에 있는 사람이 필요하기에 성립되는 방식이다.

XP 전체를 할 필요도 없고, 그저 우리 스스로가 진짜로 고객인 상품을 만들어야 할 건데, 왜 그 계획을 프로그래머들이 만들어 줄 때 까지 병아리처럼 입을 벌리고 있는 건가?

기획자라는 건 게임이 완성된 상황을 상상하고. 그 편의에 대해 예측하여 과정을 설계해야 하는 건데,
아니 세상에, 외부 공개를 할 것도 아니고 자기 스스로가 사용할 툴의 청사진 조차 예측하지 못할 거라면......

자기가 할 것도 아니고, 남들이 할 게임은 도대체 어떻게들 계획한거지?!

믿어지진 않지만 낭비라고 생각하는 경우

"구조를 알고 있는 건 프로그래머니까, 내가 세우는 것 보다 프로그래머들이 세우는게 낫지 않겠어?"

구조를 가장 잘 알고 있는 건 프로그래머가 맞는데, 툴에서 설정해야 할 규칙은 기획자도 알고 있는게 당연하다. (그래픽 툴이야 물론 제외되겠지만) 게임의 골격을 이루고 조절해야 할 핸들을 모두 알고 있는 상황일텐데 프로그래머가 뭘 더 안다는 건가? 툴의 계획을 세울 때 D3D 레퍼런스 출력 구조에 대해 고심부터 해야 하는 건가?

"난 왠만큼 후진 툴도 잘 사용할 자신 있으니까 그냥 프로그래머들이 계획을 세워도 돼"

내부에서 사용되는 어플리케이션이 당연히 유저들이 쓸 것 처럼 쉽고, GUI에 의존해 구성될 필요따위는 없다.
(나중에 설명하겠지만, 계획을 세우더라도 이런 계획을 세우라는 것이 아니다.)

오히려 GOMS 분석 결과에 따라 각종 핫키들로만 채워진 계획을 세우는 것이 월등히 효율적이다. 심지어서는 있는 기능들이 따로 적혀있는 referrence.txt 파일을 한 부 동봉해도 문제될 건 없다. 어차피 툴 쓸 건 스스로 교육시켜야 할 다른 기획자 아닌가?

목표는 생산성이며, 가장 높은 생산성을 낼 방안을 마련할 수 있는 건 툴의 사용자지 가끔은 단순히 code넘버에 따라 핫키를 배치하는 프로그래머가 아니다. 키보드 자판이 qwer순으로 되어 있다는 걸 유심히 관찰하고 어느 키가 가장 빨리 눌릴 수 있을지 고민하던 기획자란 말이다. (잠깐, 거기 그거 하나 고민 안하던 기획자는 머리박고 50초 동안 반성해라.)

"중요성은 알고 있지만 난 다른 계획을 세워야지. 내가 계획을 세울 동안 프로그래머들이 세워줄거야."

솔직히 말해, 기획자의 시간보다는 프로그래머의 시간이 더 중요하다. 그리고 안정적인 툴 계획은 프로젝트의 완성 뿐만이 아니라 앞으로 확장될 컨텐츠의 미래까지도 책임질 수 있는 툴이라는 물건에 들이 붓는 시간은 결코 낭비가 될 수 없다.



"미안하게도 난 감이 안와요. 죄송해요 프로그래머님. 만들어 주세요:-("

이런 케이스라면, 다음의 내용을 잘 생각해 보길.

● 툴을 사용할 사람은 누구인가.
  - 전혀 감이 안온다면 처음부터 킹왕짱 범용 툴 따위를 생각하지 말고 사용자별로 나뉘어진 기능을 먼저 고려해라.
   도대체 누가 사용할 툴인가?
  - 깔끔하게 정리된 범용 툴이 오히려 그 무거움 때문에 생각지도 못하게 시간을 잡아먹을 수도 있다. 또 하나의 파일에 작업물을 몽땅 저장하려다가 나누어 작업할 때 방해가 될 수도 있다. 무리하게 통합 같은 걸 미리 고민하진 말기를.
  - 우선은 하나의 작고 견고한 데이터를 나누는 것 부터 시작하고 데이터 관리자 구분을 생각하면 어떤 툴과 어떤 툴을 쪼갤 수 있을지를 알아보기 쉬워진다.

● 그가 직접 조절할 '핸들'은 어디부터 어디까지인가.
  - 데이터가 아날로그적이며 직관에 의존해 넣는 편이 좋은 정보인가
  - 그렇지 않고 디지털 적이며 차라리 핫키로 선언 되거나 숫자를 넣는 편이 더 좋은 정보인가
  - 당연히 이걸 분류하려면 당연히 어떤 핸들이 툴에서 조절 되어야 할 것인지 구분해야 한다. 제발 부탁이니 이걸 미리 알아두지 못했다는 소리는 하지 말도록.
  - 만약 여기에 대해서 도저히 감이 안잡힌다면 생산성과 직교성의 원칙의 다음 글 쯤에 추가 설명을 좀 해보겠다.
  - 꼭 필요한 핸들을 누락시켰다면 뻗게 만들어도 된다. 이런 예외 처리 하나하나를 안할 때 마다 프로그래머들이 좀 더 편해진다. (뭐 해주면 좋고 :))

● 그 핸들은 각각 어떤 식으로 조절하는게 좋은가.
  - 그 망할 그래프나 마우스를 아무데나 쓰지 마라. 차라리 뉴메릭 키패드로 숫자를 입력할 수 있도록 만드는 것이 훨씬 빠를 수도 있다.
  - text를 입력해 이후 개변할 때 가독성을 유지해야 할 수도 있다. 주석이나 노트 기능은 정말로 유지할만한 가치가 있는 내용이다.
  - 아니, 사용자가 '유저'나 '그래픽 디자이너' 혹은 '사운드 디자이너'가 아니라면 그래프가 좋은 경우따위는 없다.
  - 사실은 '그래픽 디자이너'들 조차 그래프를 쓸 필요는 없다.
  - 진짜는 '유저'도 그래프 때문에 귀찮은 경우가 더 많다. :-p



지독한 완성도를 지닌 상용 툴을 만들어 달라고 할 필요는 없다. 기능이 너무 많아 보통 사람들은 도무지 알아먹지 못해도 상관 없다. 어차피 내부 레퍼런스 가이드를 써야 하는 건 우리가 할 일이며 신입의 교육도 우리 몫이다.

실수가 있어서 크게 뜯어 고칠 일이 발생하더라도 좋고 확장 과정에서 누더기가 되어도 좋으니 절대로 스스로가 사용할 툴의 기획을 프로그래머들에게 맡기지 말라. '저장할 데이터의 목록'을 미리 생각해 보지 않았다면 당연히 어쩔 수 없이 프로그래머들에게 맡기에 되기가 쉽지만 애초에 저장할 데이터의 목록을 모른 채 게임을 만들려는 생각은 좀 버려라.

기획적으로 반드시 필요한 저장 정보를 구분하는 법에 대해서는 따로 언급을 하겠지만.......

어쨌든 이 글을 보았는데도 여태 툴 제작 계획을 세우지 않았다면,

일단 툴 계획을 세우기 위해 노력해 보라. 툴에 필요한 것은 어차피 게임에도 필요한 것으로 자동으로 확장 된다!