Swing! Archflow!

억제한다. 강압한다. 억누른다. 복종을 강요한다.
이런 모든 요소들이 사람들의 의욕을 짓밟는다. 그런데 이를 행하는것의 근간은 결과물이 안나오기 때문이라 한다. 그런데 재밌는것은 이와 같은 강요, 강압, 압박등이 오히려 더 결과물이 잘 안나오게 한다는것을 모른다는것이다.

이와 같은 결과물 중시의 관리는 생산직 혹은 건설직에서는 가능할법하다. 일단 지어놓고 무너지건 말건, 금이 가건 말건 내버려두는게 가능하다. 물론 최근에는 이런 경우 A/S나 심한경우 리콜까지 가는 경우가 종종 벌어지지만, IT라는 분야는 그리 녹녹하지 않다.


사실 까놓고 이야기 해서 기간에 맞춰 하려 한다면 얼마든지 할 수 있다. 적당히 검색해서 찾은 다른 소스 가져다 붙히거나, 다른 게임 텍스쳐 붙이거나, 다른 게임 베껴서 기획서라고 공략집 늘어 놓는등 얼마든지 가능하다.

여기서 핵심적으로 말하고자 하는건, 강압과 강요를 하면 안된다는게 아니다. 보다 효과적인 방법을 연구해서 찾지 않으면서 사람들에게 손쉽게 결과물을 종용하는 경우에는 결국 그에 따른 결과가 나온다는것이다. 이른바 전래동화에 흔히 나오는 인과응보인 셈이다.


본래 문제를 파악하기 보다는 덮어두려는게 인간의 본성이다. 문제가 두드러지는 경우 그 사람의 단점이 보이고, 실패라는게 인지되는게 싫기 때문이다. 하지만 화장실에 냄새 난다고 그냥 덮어 두는것이 과연 제대로된 방법일까?

물론 이것 또한 상황에 따라 달라질순 있다. 푸세식 화장실이라면 제대로 덮어주는것 외엔 달리 방법이 없을것이다. 하지만 집안의 화장실이라면? 또는 공항의 화장실이라면? ?

가장 근본적인 해결책은 문제를 파악해서 냄새를 없애고 청결하게 하는게 중요하다.
해충이 나오는 이유를 파악한뒤 그 원인을 제거하면 더 이상 해충이 끓지 않음에도 불구하고 그것에대한 이유나 원인은 찾지 않고 그저 약만 주구장창 뿌린다면 해충은 유유자적 이웃집으로 피서를 떠났다 다시 돌아와 같은 문제를 야기한다.


그렇다면 원론으로 들어와서 현재 팀에 어느 문제가 있는가를 확인해봐야 한다.
그리고 그것에 대한 해결책은 무엇이 있는가를 살펴본다. 그리고 그것에 대한 노력을 한다.

보통의 사람에 대한 평가는 그 사람이 업무시간에 얼마나 집중해서 일을 하는가를 본다. 그리고 그런 면을 보통 성실성이라고 평가한다. 그렇다면 관리의 성실성은 무엇일까? 사람들을 파악하고, 문제를 파악하고, 문제를 해결하려 노력하는게 성실성이 아닐까?

관리자는 선장이다.
선장이 노를 젓거나 관측을 하진 않는다. 추상적인 목표에 대한 비전 제시와 그 목표를 향해서 가기 위한 방법을 이야기 한다. 나머지 부분은 각기 사람들이 해야할 몫이다. 그런데 선장실안에 들어가 주구장창 술만 퍼먹으며 '가다보면 보물이 나올것이다.' 라고 이야기 한다면 과연 그것을 믿고 따를 수 있을것인가?

방목에도 울타리는 쳐져 있듯이 어떤 방식으로 어떻게 하는가를 확실하게 인지시키고, 그것을 따라오게 하는게 정상이다. 누군가에게 일을 시켰는데 비밀리에 작업하며 안보여준다면 신뢰할 수 있을까? 이는 관리자도 마찬가지이다. 어떻게 일을 하는가를 알리고, 사람들에게서 신뢰를 얻기 위해 노력해야 한다.

좋은 의도든 나쁜 의도든 팀과 팀사이를 갈라놓을수 있는 말을 해선 안된다.
그것은 잠재적으로 편견을 가지게 만들고, 훗날 자신도 모르게 수백배 커진 감정의 골을 만들수 있다.

말이야 말로 카오스이론에 가장 적합한 형태가 아닐까 싶다. (본인에게는 농담이지만 팀내에서는 태풍이 불수도..)
발없는 말이 천리를 가듯 몇사람에게 전달 되었을뿐인데 눈덩이처럼 불어난다.

불만과 불평이 있다면 믿을만한 사람에게 이야기 하거나, 아니면 친구를 붙잡고 이야기 하거나, 정 뭐하면 고백성사라도 받아보는것이 좋을것이다.

그러나 절대로 해서 안되는것중의 하나가 타인.
타팀에 대해 허물을 탓하거나, 비방을 하거나, 욕을 하는 행동을 해서는 안된다.

그것이 나중에 팀웍불화에 의한 개발지연이란 형태로 되돌아 오는것을 막고 싶다면 말이다.

게임을 통해 과연 유저는 무엇을 얻어가는가?
흥미? 재미? 시간죽이기? 목적달성?

게임을 즐기는것의 최종이 게임의 목적이 아니다. 그 시간을 즐기는것이며, 그 즐기는 개념은 마술과 흡사하다.

예를 들면 비둘기 마술에서 비둘기가 사라졌다 나타나는것이 유저들에게 중요한 목적이라면, 기획에서의 제일 중요시 하는 목적은 관객들의 시선을 어디로 쏠리게 하고, 그로 인한 트릭을 눈치 채지 못하게 하는것에 있다.



게임을 플레이 하는데에는 기능, 능력, 스토리등이 중요한것은 아니다.
그것은 표면적인것. 겉으로 들어나는것. 외부적인것이다.

게임의 흐름이란 자연스럽게 그러면서도 능동적으로 변화해야 한다. 그리고 플레이어는 '재밌다. 없다.'를 판별하기 전에 먼저 흐름에 몸을 맡긴다.

플로우는 사람을 끌고가는 역할이다.
총을 쏘면서 몬스터를 죽이면서 살인자의 쾌감을 만끽한다. 등도 충분히 플로우가 될 수 있으며, 시장역할이 되어 도시를 꾸밀수도, 가족일원이 되어 집을 꾸밀수도, 우연찮게 마법을 얻어 모험을 할수도, 던전에서 마왕이 부활하여 파티를 만들어 쳐 들어갈수도 있다.

이런 게임을 통해서 이어가는것의 기본 바탕이 되는것.
게임을 통해서 얻어가는것을 플로우로 지칭한다.



단기간의 전투를 반복하며 들락날락 거려도 게임에 큰 해가 끼치지 않는 요소 하나만으로도 캐주얼 게임에서 차별화를 꾀할수 있듯이 해당 게임의 가장 큰 정체성을 플로우에 심어놓는것이 중요하며, 그 밑 바탕에 게임에 대한 컨셉이 녹아 숨쉬어야 한다.

게임은 목적을 수단하는 행위이다. 그리고 그 목적은 단계별로 작게 세분화 되어 강물이나 바다 혹은 절벽같이 끊어진 구간을 제공한다.
플로우는 그 중간을 이어주는 다리 역할을 한다. 그리고 그 다리 자체가 하나의 관광지와 비슷한 역할을 하여 목적은 다리를 건너 다음 목적을 향하는것이지만 다리 자체에서 볼 구경을 제공하는 것과 같다.

손쉽게 접근하고 마스터하기 힘든것.
그리고 목적을 향해 매진하지만 해당 플레이 자체를 즐기는것.

* 개발팀 구성 정책

1) TFT 제안.
게임 제안서. -> 검토 -> 승인.

2) 프로토 타입팀 구성.
제작 -> 평가 -> 검토 -> 승인.

3) 사내 분사형태.
TFT 인원을 통한 고정인원 약 10~20여명

4) 기타 인력 충원 요소는 외주 처리 (본사등에서의 사내 외주팀등)
분사된 팀 또는 스튜디오를 서포트.
회사 내부에 공용화된 작업구분별 팀이 필요. (그래픽, 클라이언트, 서버등)


* 공용화 정책.
1) 개발팀내 관리 부서 -> 각 직업파트별 매니저 필요. (해당 직무 담당자 위주)
2) 라이브 단계에선 2단계로 구성.
-> 패치팀 - 업그레이드 담당.
-> 유지보수팀 - 버그및 이벤트등 담당.


* 라이브단계의 게임은 성장한다.
-> 라이브 단계는 길러논 아이가 사회에 진출하는 상황.
-> 주변 영향을 받고 변화한다.
-> 돈을 벌어오는 아이가 될지, 돈을 꼴아박는 아이가 될 지는 모른다.


* 게임 기획에 대한 오류
-> 게임 기획으로 사업을 판단내릴순 없다.
-> 반드시 재밌다고 성공하진 않는다.
-> 퀄리티가 게임을 말하진 않는다.
->

게임에 투입되는 인력에 앞서 먼저 필요한 건 무엇을 만드는가 입니다.

어떤 리소스로 어떻게 만들어서 어떤 느낌을 받는가? 곧 무엇을 만들 것인가? 를 첫 번째 중요한 요소로 꼽습니다. 그리고 두 번째로 어떻게 만드는가? 세 번째로 얼마나 효율적으로 만들 것인가?

 

기획팀이 효율적으로 움직이기 위해선 게임기획 자체가 구조적인 형태를 취해야 합니다. 게임의 컨셉에서 분포화되어 각각의 모듈별 작업이 구성되고 각 모듈별 작업량이 판별되었을 경우에 한해서 각 작업자가 배분되어야 하죠.

 

가장 일반적인 작업방식이 단 방향 기획인데, 이 방법의 장점은 빠른 작업과 더불어 문서의 전체 내용을 손쉽게 파악할 수 있습니다. 반면 단점으로는 세부적인 작업 내용만 간추리기 힘들며, 수정과 변환이 힘듭니다.

개발이 지속되며 점차 잦은 수정과 연계, 이후의 패치계획 및 확장의 기록을 남기기 힘들며 그러다 보니 작업이 고정화 되는 큰 문제가 존재합니다.

 

 

 

규모가 큰 게임에서는 반드시 필요한 요소가 먼저 나와 있어야 하며, 그 내용이 전면에 있는 경우 먼저 처리해야 할 압박에 시달립니다.

모듈화 기획의 장점은 전체의 양을 가늠하면서도 현재 작업하는 시점에서 반드시 필요한 부분과 현재에서 고려하지 않아도 되는 부분을 적절하게 자르고 취합할 수 있습니다.

이 작업을 카테고리로 묶거나 작업자별로 묶거나 어떤 방식으로도 손쉽게 관리할 수 있습니다.

 

간단한 예로 테마중시의 게임과 시스템 중시의 게임에 따라 각각에 배분되는 인력이 달라지고, 업무의 양도 변화합니다.

테마의 깊이나 양이 확실하게 정해졌을 경우 테마에 영향을 받는 세계관, 배경설정, 퀘스트, 시나리오 등을 어떻게 분류해서 각각의 할당량이 얼마인가에 대한 최소 인력과 최대 인력이 먼저 설정되어야 하며, 작업의 리소스를 어떤 카테고리에 묶어서 정리할 것인가? 어느 스펙의 인력이 주당 얼마만큼의 작업량을 소화할 것인가? 를 결정하고 나뉘어서 정리해야 합니다.

 

각각의 상황에 따라 해당 작업에 맞는 적성과 능력을 가진 사람에 따라서 두세 가지의 작업량을 한 카테고리에 묶을 수 있으며, 각각의 작업당 한 사람씩 묶을 수도 있겠지요.

 

 

 

인력의 양은 단 방향 기획에서 매우 중요하게 작용하지만 모듈화로 작업한 경우 인력의 질이 더 우선시 됩니다. 얼마나 깊게 생각하고, 미리 준비하며, 확장성 있게 구성하는가?

스탠드 얼론 게임이 아니기 때문에 온라인 게임은 지속적으로 변화합니다. 고정화해서 한방에 끝끝으 개발하는 것은 말이 될 수 없죠. 만약 프로그래머가 그렇게 말한다면 콘솔게임이나 개발하라고 하십시요. 물론 주먹다짐까진 책임 못집니다. ;;

 

온라인 게임은 끊임없이 자생하고 성장하고 쇠퇴하는 하나의 아이와 마찬가지입니다. 하나의 생명과도 같습니다. 그리고 유저들의 그 아이의 성장을 좌우하죠. 게임 기획은 그런 아이의 유전자적 소질입니다. 대충 한다면 유전자가 돌연변이가 되어 기형아가 되겠지요.

 

먼저 행해야 하는 것은 현재 상황을 파악하는 것입니다. 이는 기획팀을 구성하는 측면에서 보자면 일단 회사 내부적인 상황과 외부적인 상황(곧 예산이나 개발기간 등에 맞추거나 내부 개발자의 능력에 맞추는등)에 맞추어 작업을 쪼개야 합니다.

 

작업이 적절히 쪼개진다면 기획부분에서의 아웃소싱도 충분히 가능합니다. 예를 들어 아이템의 기본 개념(컨셉)과 스탯, 영향, 종류등이 정해졌다면 이후의 가짓수를 늘리는 건 얼마든지 외부에도 손쉽게 의뢰할 수 있는 부분이겠죠.

 

핵심요소가 확실하면 이후의 작업인 세부 분화 -> 피드백 -> 수정 -> 검토의 단계는 각 작업의 진행과정으로 처리 가능해지고 완료된 부분을 적용함으로써 각 작업의 일정 단계별로 끊어 처리가 가능합니다.

 

 

 

인력 구성의 문제에서의 가장 큰 리스크는 기획자의 퇴사가 더욱 더 큰 손실이자 위협이라고 보겠습니다. 해당 작업 인력이 나갈 경우의 손해는 새로운 기획자 2~3명을 뽑는 것보다 더욱 큰 손실입니다.

이에 누가 무슨 작업을 어떻게 하는 것에 덧붙여 누가 작업을 하다가 나갔을 경우 어떻게 해당 작업을 이어서 가능하며, 그 손실이 없을 수 있는가 부분도 전체 작업에서의 손실을 가장 줄여주는 방법입니다.

 

게임기획이 제조나 생산, 노동이 아님에도 사람들이 간과하는 것이 그것을 노동에 간주해버린다는 것입니다. 물론 정신적 노동이란 비유도 존재하지만 오랜 시간 붙잡고 있다고 해서 질이 좋게 나오거나 많은 양이 빠르게 나오진 않습니다.  

 

마찬가지로 여러 명이 붙어서 생각하는데 에는 좋은 아이디어를 빠른 시간 안에 잡아내고자 함이자 결코 여러 명이 나누어서 분업화 하면 작업이 빠르게 나오는데 있는 것이 아니며, 곧 작업의 양 측면에서의 접근이 아닌 작업의 질 적인 측면에서의 접근이 필수적입니다.

 

이전에도 썼지만 해당 작업자에겐 전문적인 분야가 존재합니다.

2차 세계대전에 해박한 사람에게선 2차 세계대전을 소재로 한 게임에서의 아직 시도해보지 않은 소재나, 환경 등을 뽑아낼 수 있을 것이며, 자료적인 부분에도 해박하겠죠.

SF에 해박한 사람에게선 SF자료등의 손쉬운 접근이나 국내에서도 받아들일만한 캐주얼한 SF를 찾아내는데 어려움이 없을 것입니다.

 

게임에 적합한 전문가를 기용하는 것이 비 전문가를 교육해서 끌고 가는 것보다 작업적 속도 면에서 확연하게 차이가 있고, 사람이 많으면 다양한 의견을 들을 수 있겠지만 사공이 많으면 배가 산으로 간다는 말처럼 적절한 인력배분이 필요한 것은 피할 수 없습니다.

 

이에 가장 적절한 인력은 게임 규모에 따라 다르겠지만 일반적인 MMO의 경우라면 1명의 팀 리더(팀장의 관리 개념이 아닌 기획을 끌고 가는 사람)와 2명의 각 전문가(로직적인 부분과 아트웍적인 부분)로 시작하며, 전문가들이 각각의 모듈에 적합한 0~3명 정도가 가장 최적이라 봅니다.

 

최소 1인에서 최대 7명 정도. 그 이상의 인력은 오히려 임시 계약직 알바등이 훨씬 적절하며, 또한 그렇게 많은 작업이 필요하진 않습니다.  

 

만약 에버퀘스트처럼 지속적이며 많은 퀘스트가 필요하다면 퀘스트에 관련한 플랫폼을 설계한 뒤 임시직을 고용해서 해당 시놉시스 형태로 뽑아내는 것을 요구하면 됩니다.

이런 방대한 양의 작업을 모두 내부에서 처리한다면 당연히 업무 처리가 과다 배분되겠죠.

 

 

 

결국 결론은 먼저 회사에서 예산이란 측면에서의 방향성과 기간, 목적을 세팅해주어야 하고, 그에 맞는 개발방법과 개발인력이 세팅되어야 하며, 개발 인력에 맞추어 같은 형태의 게임이라도 개발을 어떻게 구성할 것인가가 나와야 합니다.

 

게임 기획은 기획팀 혼자서 하는 것이 아니라 팀 전체가 기획을 하는 것이고, 기획팀은 그것을 리드하고 추적하고 기록합니다. 곧 고정화된 자원으로서의 역할이 아니라 업무의 방향과 목적에 맞는 인력. 해당 작업에 전문적인 지식을 가지고 있는 명확한 역할이 지정된 것이 먼저이겠습니다.

최초의 시도.
신장르 개척.
이런 형태의 게임은 당연히 위험부담이 높아진다.

위험부담대문에 소규모 회사에서 함부로 도전하기 힘들지만 그런면 때문에 오히려 소규모 회사가 더 도전하기 좋은 조건도 가지고 있다. 위험부담이 큰 만큼 성공시의 이익도 크기 때문이다. 하지만 이런 하이리스크 하이리턴형 게임의 도전은 1000개의 회사가 도전해서 1~2개의 회사가 성공할 확률이라고 하겠다.

예를 들어보면  유니크 아이템을 얻기 위해 드래곤과 맞짱뜨러 가는데 사망확률 0.1%의 내구력 1짜리 아이템 하나만 딸랑 쥐어지는 상황이랄까? 또한 그 퀘에서 사망시 뭐 캐릭터 삭제 내지는 계정 삭제등이라면? 단순히 오락실에서 게임오버 문구만 뜨고 끝나는것이라면 상관없겠지만 자칫 인생이 게임오버 당할수도 있다.
물론 이런걸 계속 이어갈수 있는건 돈이다. 계속 컨티뉴메세지가 뜨고 시간은 흘러간다.



보통의 경우 최초의 포지션이 아닌 최고의 포지션을 노리는 상대적으로 안정적인 기회를 노린다. 기존에 참신한 시도로 도전했지만 상업적으로 실패한 게임을 보완하는 방법.
이는 그 문제점만 잘 찾아 해결하면 새로운 게임의 시도에서의 미지의 변수를 줄일수 있다는점에서 위험부담을 최소로 줄일수 있다.

그러나 여기서의 복병은 "다른게임도 망했는데 그건 더더욱 가망없지..."라는 냉소적인 분위기이다. 일반적으로 망한 게임을 보완하는 것의 성공확율은 50%정도라 하겠다. 반반의 경우의 수이지만 최소 0.1%보다는 그나마 안정적이다. 물론 이 경우엔 경영진을 설득할순 없다.



경영진이 납득하며 진행할 수 밖에 없는것이 바로 기존 게임형태를 쫓아가는것이다.
대부분 게임을 (모르고, 관심도 없고, 애들이 돈 갖다 바친다하고, 야근시키면 3달안에 게임 나오는줄 알고, 기획자는 없어도 프로그래머만 있으면 게임 나온다 여기며, 제조만 하면 아무렇게나 팔수 있다고 생각하는 경영자들의 머릿속에선 이미 포화지경의 시장에 들어가도 어느정도 푼돈은 벌수 있겠지...라는)  안이한 생각으로 덤벼들지만 수익이란 측면에서 보자면 (돈을 벌어야 같이 산다라던가..) 어느정도 타협점을 찾을 수 있고, 국내 개발사 형편상 어쩔수 없이 할 수밖에 없는 구조이기도 하다.

1위포지션이 아닌 2위 또는 3위 포지션의 수익구조를 노리는것이다.
예를 들어 10억의 최초의 장르선점게임이 있다면, 2위포지션에서의 1억수익, 3위 포지션에서의 5천수익형태이다.




기존 게임을 흉내내는것이 결코 나쁘다고만 볼 순 없다.
개발기간을 줄이며, 미리 검증된 문제점을 해결하고, 빠른 결과를 볼 수 있다는 점에서 매우 합당하겠다. 하지만 이 경우 문제시 되는것은 표절과 모방의 차이점이다.

다른게임의 모티브만을 가져온다면 얼마든지 변형과 재 창조가 가능하지만 그저 무턱대고 외형만 쫓아가면 말 그대로 껍데기만 흉내낸 도둑질인셈이다.

이런 형태의 고질적인 문제점은 베낀 게임이 수익을 내고, 수익을 낸 게임을 만들어본 이들이 시장의 우두머리에서서 기존의 개발했던 게임의 울궈먹기로 남고, 그 결과 색다른 게임을 시장에 내놓기 힘들어진다.



기존의 콘솔 또는 PC게임등의 예를 들면서 해외도 표절한다고 말하지만 이는 표절과 모방의 외형적인 부분만 보기 때문이다. 내부적인것을 보면 가장 큰 차이가 자신만의 정체성(identity)이 있는가 하는 점이다. 물론 간혹 정체성이 없는 게임도 종종 있다. (해외라고 모두 정직하고 표절없이 개발하는건 아니다.)

겉으로 보기엔 미묘한 차이점 정도인데, 똑같은 형태의 RPG이나 프론트뷰로 전투를 하는가와 사이드뷰로 전투를 하는가 정도의 차이라던가, SF테마 시나리오 중시의 FPS와 현대전테마에 멀티 위주의 FPS정도이다.

겉으로 보기엔 외형적인 미묘한 변화이다. 하지만 그 안에 그들이 넣고자 하는 철학 혹은 주제등은 다르다. 그리고 그것이 존재하는가에 따라 그 게임이 어느정도 변화를 꾀했는가? 꾀하지 않았는가 정도로 구분지을수 있다.




새롭다라는건 완전히 새로울수도 있고, 거의 변화하지 않을채 묘하게 바꾼 형태일 수도 있다. 유저가 게임을 통해서 무얼 느끼고, 어디서 재미를 찾으며, 시간을 가치있게 썼다라고 생각하게 하게 하는 점. 곧 타겟을 확고히 다지며 해당 타겟으로부터 충분한 칭찬을 받는것이 가장 중요하다.

안이한 하드코어 게이머(PC게임은다운받아플레이 하고, 온라인게임은 프리섭 만들고, 콘솔게임은 복사 쓰며, 다양한 게임을 수없이 많이 빨리 먹어치우는 먹깨비형 게이머)요구는 다채롭다. 게다가 그들을 배제할 순 없다. 나름 게임에 대한 애정과 애증이 반복 교차하며 게임에 대해 여러가지를 요구하기 때문이다. 이들의 요구를 100% 반영할순 없다. 또한 이들처럼 생각해서도 곤란하다.



개발자라면 적어도 현재 자신이 처한 현실. 팀이 처한 현실. 팀이 개발할수 있는 현실.
시장에서의 트렌드 흐름등 여러가지면을 고려해서 현실적으로 가능한 형태의 게임을 선택해서 개발해야 한다.

차이라면 그 개발기간 안에 최대한 노력해서 새롭게 보이게끔 노력하는가와 노력하지 않고 어차피 베낄거 그냥 대충하자라고 여기는가의 차이이다.

게임에서의 특이점은 마케팅 불변의 법칙이 깨지는 시장이다. 최초의 게임이 최고가 되는것이 아닌 최고의 게임이 최초의 지위까지 먹어치워 버린다.

유저의 성향은 빠르게 변화하며, 게임컨텐츠 소비또한 매우 빠른다. 그렇기 때문에 게임의 유통기한이 매우 짧으며 연구개발의 시간을 할애하기 힘들다.



새로운 게임이라고 반드시 성공하리란 보장이 없다.
시기적 흐름이나 상대적인 조건들이 맞아 떨어져야지만 성공하며, 그렇지 못한다면 우연찮게 빤짝상품으로 전락해버릴수 있다. 변화가 많고 다양하기 때문에 시도 그 자체에 매우 큰 위험부담이 생긴다.

가장 큰 화두는 현실적인 개발환경에서 얼마나 스스로 고민하여 그 안에 자신만이 제공할수 있는 재미를 부여해주는가 정도이다. 그래서 베낄수 밖에 없다면 모방은 하되 표절은 하지 않도록 노력하는점. 모방이라면 과연 그 안에 어떤 차별성을 두고, 어떤 정체성을 부여하는가가 중요하다.

게임에 어떤 정체성을 넣을것인가? 이 게임은 축약해서 무엇이다라고 말할수 있는가? 그리고 현재는 다른게임의 모습을 답습하고 있지만 그 다음버전, 그리고 그 다음버전에선 어떤 모습을 가져갈수 있는가를 확고히 한다면 지금 당장은 그다지 새롭진 않겠지만 이후로는 충분히 새로운 형태의 게임이 나올 토양이 갖춰질것이다.

개발이 동시 다발적으로 진행되는 상황에선 당연히 다른 파트가 놀수 밖에 없는 구조및 환경이 이뤄질것이다. 이를 미연에 방지하기 위해서는 게임 기획부분이 최소 3달 이상은 앞질러 가야 한다.

게임 기획은 가장 스타트지점이 된다. 곧 어떤 작업을 어떻게 배분해서 진행해야 하는가인데, 이런 부분에서 최소 1분기 이상 앞서 가지 못한다면 다른 파트는 최소 2분기 이상 늦어진다.

기획 초안 완성시 원화등의 일러스트 그림이 진행하고 그리고 캐릭터 글픽과 배경 글픽이 진행되고 모든게 일차적으로 완성된 시점에서 클라이언트와 서버가 진행하다면 일은 쉼 없이 막힘없이 술술 풀려갈것이다.

기획 (m3)
               원화 (m2)
                              그래픽 (M1)
                                                클-서 (M0)

이렇게 한다면 이후의 작업도 고려해볼수 있다.
작업 진행 도중 추가가 불가능하거나 현재 구현안해도 무방한 작업들은 뒤로 돌려서 차후에 작업할수도 있을것이며, 급하게 빨리 처리해서 테스트해봐야 하는 작업은 앞으로 순서를 당겨서 처리할수도 있다.

더불어서 각 작업을 1주, 1달, 1분기단위로 쪼갤수 있기에 일정이 밀렸을때 해당 작업을 수순대로 쪼개서 정확하게 밀린 일정을 예측할수도 있다.



이는 단순히 채찍질을 하는게 아니다. 느리지만 멈추지 않는 마라토너처럼 움직여야 한다는것이다. 기계도 작동하다 오랜시간 멈추면 고장나기 마련인데 하물며 사람이 일을 멈춘다면 그것도 다른 파트의 지연에 의해서 멈춘다면 당연히 고장나기 마련이다.

업무의 복잡성은 동시 다발로 진행할때 발생한다. 동시 다발로 일어난 일은 지속적으로 얽히고 섥혀서 꼬여버린 매듭처럼 실마리를 찾기 힘들다. 이런 경우의 해결책은 결국 매듭을 자르고 새로 묶는 방법외엔 없다.

문제는 이렇게 항시 매듭을 자르고 새로 묶기를 반복하면서 전체 일정이 늦어진다는데 있다. 일정이 앞서가는데에는 미래에 대한 방법및 제안을 하는것과 업무의 인수인계라는 부분에서 중요하다.



개발중 있어서는 않되지만 있을수도 있는 리스크의 경우가 천재지변에 의한 문제등이다. 일하던 이가 느닷없이 사망하는 최악의 상황에서도 개발은 멈추어서는 곤란하다.
다른 담당자가 들어와 최대 1~2주 안에 업무를 파악하고 진행할수 있는 구조가 되어야 한다.

개발을 미리 하고 테스트를 준비하는 형태라면 어떤 타이밍에서도 서비스를 시도할수 있다. 분기별 4단위로 짜른 작업을 이어 얼마만큼의 개발 범위를 공개할것인가는 사업파트에서 고려할 부분이겠다.



간단하게 보면 오픈이건 클로즈건 다 고려하지 말고 프로토타입이 지난 이후부터는 실제 서비스 게임의 지속적 업데이트 개념으로 봐주는것이다. 대단위 신개발이 아니라면 단위별 정기 업데이트가 가장 합당하다.

이를 정기적인 시즌 혹은 챕터 혹은 에피소드등으로 구분할수도 있다. 해당 작업단위별로 순차적으로 진행한다면 개발 자체도 무리가 없을뿐더러 플레이 하는 유저도 정기적으로 해당 버전을 기다릴수 있다.

버전1, 버전2, 버전3, 버전4를 개발했다고 보자. 이에 대한 서비스를 무조건 분기별로 하는게 아니라. 4개월에 한번 혹은 반년에 한번씩 업데이트 할 수도 있다.

중간 기간에 최대한 테스트를 거치며, 해당 테스트 결과를 축적하고 축적된 데이타를 반영한다. 또한 중간중간에 작업의 딜레이 상황에 맞춰서 진행할수 있기때문에 개발 작업 자체의 총 작업시간은 6개월 단위가 되더라도 각각의 파트에서의 작업 순서는 3~4개월에 한정될 수 있다.

일을 오래 하다보면 자신들이 무슨 작업을 얼마만큼 했으며 얼마나 작업이 남았고, 언제쯤 조금이나마 편하게 쉴수 있을까를 생각하게끔 작업하는형태. 곧 습관이 중요하다.

패치직전에 1~2주 밤새서 야근하는게 아니라 항시 작업을 체크하고, 해당 작업기간에 완료하는 마감에 대한 긴장감을 준다면 각각의 작업자들이 더욱 적절하게 작업을 완료할것이다.

일반적으로 개념없는 소규모 영세 회사의 경우 개발과 서비스를 동시상영 개념으로 착각하는 경우가 종종있다. 아무런 준비도 아무런 대책도 없이 완성되었다고 말을 하면 바로 서비스 하면 되는것으로 착각하는 이들.

개발의 완료라는것은 말 그대로 돌아가는 버전을 말한다.
곧 예상치 못한 문제들이 가득할것이란 소리이다.
이는 마치 치료제를 개발한뒤 임상실험도 없이 바로 병원에서 쓰는경우와 다를게 없다.
사람이야 죽어 나가거나 말거나, 부작용이 있거나 말거나 일단 내놓고 보는 정책.

온라인이라고 무조건 설익은 음식 내놓고, 돈 안내고 맛만 보라고 하면서 끊임없이 양념을 바꾸어가는 형태. 어쩌면 이런것들은 교육자체에서 습관처럼 인지하고 있는것일지도 모를일이다.
시험전날 바로 공부하는 자세. 발표당일날 자료 준비하는 자세. 개학 전날 숙제하는 자세.
하지만 이런 형태는 10년전이나 통할법한 일이다.

한국에서의 게임은 임상실험품만이 넘쳐 흐른다. 곧 자신들이 부작용을 일으킨뒤 그것을 고쳐주길 원하는 환자들과 한두번 투약해본뒤에 두번다시 쳐다보지 않는 사람들로 구분된다.
환경 자체가 그렇게 커왔고, 그렇게 구성되었기 때문에 이 현상을 당연하다고 여겨왔다.
이런 관행이 이제 2010년이 다가오는(무섭군..;;;)지금에도 여전히 이어져 오고 있다는것을 보면 아찔할 정도이다.

개발을 미리 완성한뒤 다음 개발을 하고 완성된 버전을 QA를 통해 1차, 2차, 3차로 준비하며 비즈니스 관점에서 한번 더 수정할지 아니면 해당 버전에서 출시할지를 결정한뒤  내놓는다면 유저들도 만족할것이다.

인스턴트 음식처럼 그냥 급하게 찍어내기 급급해서는 제대로된 음식을 만들수 없지 않은가? 플레이어는 트랜스 지방을 먹어치운 비만 아동처럼 넘쳐나는 정크게임속에서 허우적 대고, 결국 게임시장의 감소를 가져온다.

개발이 3템포 정도 앞서 간다면 서비스쪽에서는 적절한 포인트나 위치를 잡을수 있다. 더불어서 유저의 불만이 있는 경우에 이미 앞서간 서비스를 불만의 상승 곡선에서 뿌려서 그 불만을 해소시켜줄수도 있으며, 오히려 발 빠른 서비스라며 사람들의 욕구를 충분히 만족 시켜줄 수 있다.

멀리 보고 설계하기와 계획하며 움직이는 자세들이 필요하다. 준비된 시작은 변형과 수정이 쉽다. 처음부터 모두 잘못되었다고 하더라도 무에서 시작하기 보다는 유에서 무로 갔다가 다시 유로 작업하는것이 속도면이나 질적인 면에서 더 우위를 가져갈수밖에 없다.

그러니깐 사장님들아...  제발 개발완료라고 하면 "아! 앞으로 3~4달 테스트할 기간이 있어야 하는구나." 라는걸 알아 달란 말이다.

게임 개발은 최소 1년 길게는 2~3년 정도 걸린다.
이는 마치 1년째 끓이는 스튜같은것이다.
당장 밤세워서 완성할수 있는 그런종류의 것이 아니다.
문제는 한가지 요리만 주구장창 오래하게 되면 다른 맛은 기억하기 힘들어진다.

자신의 스튜만 집중하고 계속 맛을 보면 미각은 잃어 버리고, 무엇이 정상적인지 판단하기 힘들어 질 것이다. 그리고 자신의 스튜맛만을 기억할뿐 다른것을 신경 쓸수 있을까?

게임은 다양한 문화가 복합적으로 들어간 장르의 퓨전 미디어다.

그렇기 때문에 다양한 문화를 접하고 자신을 쉬면서 여러가지 음식과 어울리는 방법, 여러가지 맛을 봐야만 자신의 미각을 잃지 않고 객관적으로 평가 할수 있는 기회를 가진다.

자신의 것만 기억하고 매진하는것은 기본적으로 가져야할 자세이지만 이것이 너무 지나치게 되면 모든것을 터부시 하며, 오로지 자신의 것만이 최고라고 생각하는 아집이 생겨난다.

이렇듯이 한가지에만 집중하는 자세는 높이 사줄만 하지만 그것이 반드시 좋은것만은 아니다. 1년 넘게 끓이는 스튜에 집중하는것은 좋지만, 그것을 절대적으로 숭배하는 대상이 되어선 곤란하다.

그렇기 때문에 일을 할때 도움이 되는 취미를 최소 한 두가지 정도를 가져주는것이 좋다.
익스트림 스포츠를 즐기거나, 낚시를 하거나, 조각을 하거나, 사진을 찍거나, 음악을 듣거나, 영화를 보거나, 독서를 하는 모든 행위 하나하나가 차후에는 자신에게는 물론 게임에도 영향을 미친다.

다양한 문화를 접하면서 최신의 트렌드를 읽게 되고, 그 안에서 얼마나 벗어났는가를 터득해야 한다. 자신만의 세계에서 완성한 게임은 자신만이 재밌는 게임이 될 공산이 크다.

미각을 잃어 버린 요리사는 다음 기회를 가질수 없다.
그러나 한가지 외의 다양한것을 섭렵한 사람은 당장의 요리가 실패 한다 하더라도 다음 요리에선 성공할수 있다.

열정과 마음은 형식화 되어 있고, 도식화 되어 있는것이 아니다. 룰을 벗어나고자 하면서 자신만의 룰을 남에게 강요하는것은 자신만 맛있는 음식을 타인에게 강제로 먹이는 행위와 다를바 없다.

집중은 반드시 해야한다. 하지만 목적지까지 전력으로 가더라도 앞만 보고 갈 필요는 없다. 어차피 시간이 같다면 주변 풍경 구경을 하면서 두루두루 가보는것이 좋지 아니하겠는가?

게임 개발팀은 유리컵과 같아 깨트리기는 쉬우나 이어 붙히기는 힘들다.