'프로세스'에 해당되는 글 5건
[글강, 2009/02/06 00:06, Game]
아 영양가도 없고 쓰잘데기 없는 글이 넘 길었다. 8연작은 또 처음 해보네. 이제 좀 끝내자능.
게임 디자인이란 실로 모호한 일이다.
정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.
그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?
그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;
그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?
어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?
그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.
뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.
그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?
확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?
... 신념?
... 라고?
아니.
나는 바로 이 지점이 위험하다고 생각한다.
게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!
그 순간 기획자의 신념은 개발에 독이 된다.
이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.
아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?
아니.
그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.
그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?
아니.
게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.
그리하야 내가 내리는 결론은...
기획자는 프로세스를 먹고 살아야 한다는 것이다.
개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.
혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.
하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...
그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...
우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.
핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.
기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.
이 경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?
아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.
구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...
기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.
이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.
따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.
아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.
이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.
그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.
이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.
그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.
아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.
이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?
그렇기 때문에, 우리 팀이 현재 채택하고 있는...
...라는 프로세스가 나는 옳다고 생각한다.
프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.
이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?
아니.
이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.
드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.
아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.
최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.
무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.
마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.
그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.
남은 것은 '노예처럼 일하셈!!!' 뿐.
물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a
[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.
하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.
피식. 마지막은 또 용비어천가인가효.
뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-
언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?
'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'
... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.
쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/
게임 디자인이란 실로 모호한 일이다.
정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.
그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?
그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;
그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?
어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?
그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.
뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.
그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?
확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?
... 신념?
나는 내가 내린 판단을 믿어. 이것이 내 역량 내에서 내가 내린 최선의 판단이었다고 믿어. 이 디자인은 게임을 재미있게 만들어 줄거야. 믿자!
... 라고?
아니.
나는 바로 이 지점이 위험하다고 생각한다.
게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!
그 순간 기획자의 신념은 개발에 독이 된다.
이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.
아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?
아니.
그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.
그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?
아니.
게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.
그리하야 내가 내리는 결론은...
기획자는 프로세스를 먹고 살아야 한다는 것이다.
개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.
혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.
물론 말단 기획자 따위가 무슨 수로 개발 프로세스를 바꾸냐... 라고 하신다면 할 말 없음 ㄱ- 그래서 사실 이 부분은 디렉터 분들이 좀 신경 써주시면 감사하겠는데 말이졈 -ㅁ-
하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...
그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...
우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.
핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.
기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.
이 경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?
아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.
구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...
기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.
이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.
따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.
아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.
우리가 만드는 게임을 위하여 과연 무엇이 최선의 길이고 - 궁극적으로는 최상의 재미를 이끌어낼 수 있는 길인가?
이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.
그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.
이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.
그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.
아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.
이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?
그렇기 때문에, 우리 팀이 현재 채택하고 있는...
누구에게도 결정을 전담시키지 않고 논의를 통해 결정한다.
다양한 통로를 통하여 끊임없이 개발팀 내에서 공유하고 공유하며 또 공유한다.
다양한 통로를 통하여 끊임없이 개발팀 내에서 공유하고 공유하며 또 공유한다.
...라는 프로세스가 나는 옳다고 생각한다.
프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.
이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?
아니.
이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.
드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.
아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.
최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.
무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.
마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.
그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.
남은 것은 '노예처럼 일하셈!!!' 뿐.
물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a
[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.
하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.
피식. 마지막은 또 용비어천가인가효.
뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-
언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?
'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'
... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.
쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/
|
Trackback Address :: http://glekang.com/trackback/345
|
[글강, 2009/02/05 00:14, Game]
게임 기획자가 뭐하는 놈들인지에 대한 질문에서부터 시작하야... 이제는 무슨 프로세스 이야기를 하고 있나효. 삼천포도 이런 삼천포가 업ㅂ는... ㄱ-
하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)
그러므로 다시 전진~
NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.
물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...
추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.
뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.
혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.
그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?
그렇지는 않다고 생각한다.
이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.
1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.
2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.
3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.
4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.
5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.
... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...
글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a
그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.
1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.
2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?
3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)
4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?
에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;
또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;
... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;
그래도 이제 남은건 결론 뿐이다.
게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.
그럼 마지막 글에서 ( '')
하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)
그러므로 다시 전진~
NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.
집단 창작으로 게임은 만들어 지지 않는다.
게임은 민주적으로 만들어 지지 않는다.
게임은 민주적으로 만들어 지지 않는다.
물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...
추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.
뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.
혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.
그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?
그렇지는 않다고 생각한다.
이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.
1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.
이건 뭐 너무나도 당연한 이야기. 이게 흔들리면 배가 산으로, 하늘로, 안드로메다로 날아간다.
2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.
즉 결정을 위한 논의 과정에서는 디렉터조차도 결국 한 사람의 발언자 지위에 머물러야 하며, 권위에 의한 압박이 없어야만 한다. 더불어 서로에 대한 정치적 배려(?)를 기반으로 한 타협같은건 애초에 존재하지도 말아야 한다. 그리하야... 쪼까 과장을 섞어보자면 이런 양상이 만들어져야 한다.
...
... 어랏 적어놓고 보니 되게 소모적이네? ㄲㄲㄲ 하지만 나무를 보지 말고 숲을 보시라능.
저런 논의를 거치고 거치면서, 치열하게 치고 받으며 결정하되 절대 '타협'은 하지 않는다. 그렇다고 쓸데없는 고집을 피우지도 않으면서, 가장 합리적이고 최적화된 결론을 도출하기 위하여, 자칫 산으로 가버리는 배를 모두가 끌어내리면서 집중한다. 그리고 결국 최종 결정은 디렉터가 하며, 여기에 대해서는 이의를 제기하지 않는다.
다행히 지금까지 '절대 아니라고 생각하지만 디렉터가 까라고 하니까 깐다 내 참 더러워서'라는 상황은 발생하지 않았다. 모호하게 구부러지며 타협하는 상황 역시 발생하지 않았다. 그리고 이런 추세라면 앞으로도 발생하지 않을 듯 싶고... 애초에 나라는 인간부터가 까란다고 곱게 깔 생각이 없기 때문에 ( '')
디렉터 : 이런 아이디어 죽이지 않아?
개발자A : 당신 바보야?
개발자B : 당신 바보지?
디렉터 : 아놔 이러저러해서 끝내주잖아!
개발자A : 아놔 요로조로해서 말도 안되자늠!
개발자B : 아놔 이리저리하면 말은 되겠지만 역시 해괴한데?
디렉터 : 어 그럼 이리저리하면서 요로조로한 문제를 해결하면 의도에도 부합하게 되지 않나?
개발자A : 아니 그보다는 이러쿵 저러쿵한 쪽이 더 낫지 않아?
개발자B : 당신 바보야?
디렉터 : 당신 바보지?
개발자A : 당신 바보야?
개발자B : 당신 바보지?
디렉터 : 아놔 이러저러해서 끝내주잖아!
개발자A : 아놔 요로조로해서 말도 안되자늠!
개발자B : 아놔 이리저리하면 말은 되겠지만 역시 해괴한데?
디렉터 : 어 그럼 이리저리하면서 요로조로한 문제를 해결하면 의도에도 부합하게 되지 않나?
개발자A : 아니 그보다는 이러쿵 저러쿵한 쪽이 더 낫지 않아?
개발자B : 당신 바보야?
디렉터 : 당신 바보지?
...
... 어랏 적어놓고 보니 되게 소모적이네? ㄲㄲㄲ 하지만 나무를 보지 말고 숲을 보시라능.
저런 논의를 거치고 거치면서, 치열하게 치고 받으며 결정하되 절대 '타협'은 하지 않는다. 그렇다고 쓸데없는 고집을 피우지도 않으면서, 가장 합리적이고 최적화된 결론을 도출하기 위하여, 자칫 산으로 가버리는 배를 모두가 끌어내리면서 집중한다. 그리고 결국 최종 결정은 디렉터가 하며, 여기에 대해서는 이의를 제기하지 않는다.
... 넵. 대신 곱게 최종 결정을 내리도록 가만 놔두질 않는거졈 ( '')
다행히 지금까지 '절대 아니라고 생각하지만 디렉터가 까라고 하니까 깐다 내 참 더러워서'라는 상황은 발생하지 않았다. 모호하게 구부러지며 타협하는 상황 역시 발생하지 않았다. 그리고 이런 추세라면 앞으로도 발생하지 않을 듯 싶고... 애초에 나라는 인간부터가 까란다고 곱게 깔 생각이 없기 때문에 ( '')
3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.
이게 되게 중요하면서도 쉽지 않은 부분이기는 한데... 뭐랄까 다행히 우리 팀의 구성원들은 다들 사회 생활을 꽤 오래 경험한 고령자(-_-)들이 많은지라, 나름 프로페셔널하고 쿨하다.
더불어 대부분의 팀원들이 이미 예전 프로젝트부터 함께 일하던 이들인지라... 협업 경험이 보통 3~4년 이상씩은 훌쩍 넘어가는 팀. 서로를 어떻게 긁어대면 되는지를 잘 알고 있다 ㄲㄲㄲ
이건 사실 그냥 우리 팀이 가지고 있는 행운이 아닐까 싶기도.
더불어 대부분의 팀원들이 이미 예전 프로젝트부터 함께 일하던 이들인지라... 협업 경험이 보통 3~4년 이상씩은 훌쩍 넘어가는 팀. 서로를 어떻게 긁어대면 되는지를 잘 알고 있다 ㄲㄲㄲ
이건 사실 그냥 우리 팀이 가지고 있는 행운이 아닐까 싶기도.
4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.
즉 '우리'가 게임을 만들어 나간다는 비전에 모두가 공감대를 형성하고 있어야 한다. 그렇지 않으면 아무리 게임 디자인을 공유하고 오만 난리를 피워도... 애초에 응할 마음이 없는 사람에게는 하등 소용이 없기 때문.
다행히 우리 팀의 구성원들은 대부분 게임 바닥에서 꽤 오래 구른 분들인지라 (이제 개발 경력이 5년 정도 되는 내가 막내뻘), 그리고... 안타까운 일이지만 고생은 고생대로 하고서는 결국 게임을 말아먹은 경험을 함께 공유하고 계시는 분들인지라 ㄱ- 저 기조의 중요성을 뼈저리게 인지하고 있는 듯 싶다.
더불어 이는 2번에서의 논의가 자칫 소모적인 양상으로 빠지는 위험을 해소하는 데에도 도움을 준다. 다들 짬밥이 좀 되니까 -ㅅ- 말같잖은 뻘소리는 애초에 잘 나오지 않는다.
이것도 3번과 더불어 그냥 우리 팀이 가지고 있는 행운인 듯 싶다능.
다행히 우리 팀의 구성원들은 대부분 게임 바닥에서 꽤 오래 구른 분들인지라 (이제 개발 경력이 5년 정도 되는 내가 막내뻘), 그리고... 안타까운 일이지만 고생은 고생대로 하고서는 결국 게임을 말아먹은 경험을 함께 공유하고 계시는 분들인지라 ㄱ- 저 기조의 중요성을 뼈저리게 인지하고 있는 듯 싶다.
더불어 이는 2번에서의 논의가 자칫 소모적인 양상으로 빠지는 위험을 해소하는 데에도 도움을 준다. 다들 짬밥이 좀 되니까 -ㅅ- 말같잖은 뻘소리는 애초에 잘 나오지 않는다.
이것도 3번과 더불어 그냥 우리 팀이 가지고 있는 행운인 듯 싶다능.
5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.
'개발자가 자신이 만드는 게임에 대해 파악하는 것, 그리고 자신이 속한 개발팀의 현재 상황을 아는 것'은 당연히 필요한 일이고 매우 중요한 일이다... 라지만 이거이 생각처럼 쉽게 달성되는 것은 또 아니다.
'개발자라면 당연히 저런 자세를 가져야 하지 않아?'라고 말하기는 쉽겠지만, 애초에 개발팀 내에 이러한 리마인드를 지속적으로 해주는 프로세스가 갖추어져 있지 않으면서 그냥 강요만 한다면... 결국은 죽도 밥도 아니될 뿐.
따라서 개발 프로세스 내에 이를 위한 자원 혹은 일정을 정기적으로 마련해야 하고, 그 외에도 개발 현황판 등의 시각적 요소를 통한 리마인드 역시 필요하다.
주의할 점은... 현황판은 아날로그여야 한다는 점. 흔히 디지털 - 보통 웹을 통한 - 이 아무래도 더 깔끔하고 업데이트 및 공유, 관리하기에 편하다는 생각을 할 수 있는데... 그러나 디지털은 아날로그에 비해 접근성이 떨어진다. 웹을 통한 액세스가 모든 이에게 편리할 것이라는 생각은 편견임. (특히 고령자들에게... 어머나 내가 무슨 말을...)
그래서 우리 팀은... 뭐 정기적인 팀 회의를 일단 기본적인 공유의 시간으로 활용하고 있으며, 현황판은... 넵. 와보신 분들은 아시겠지만 우리 사무실 벽면을 온통 덕지덕지 뒤덮고 있지효 -ㅅ-
'개발자라면 당연히 저런 자세를 가져야 하지 않아?'라고 말하기는 쉽겠지만, 애초에 개발팀 내에 이러한 리마인드를 지속적으로 해주는 프로세스가 갖추어져 있지 않으면서 그냥 강요만 한다면... 결국은 죽도 밥도 아니될 뿐.
따라서 개발 프로세스 내에 이를 위한 자원 혹은 일정을 정기적으로 마련해야 하고, 그 외에도 개발 현황판 등의 시각적 요소를 통한 리마인드 역시 필요하다.
주의할 점은... 현황판은 아날로그여야 한다는 점. 흔히 디지털 - 보통 웹을 통한 - 이 아무래도 더 깔끔하고 업데이트 및 공유, 관리하기에 편하다는 생각을 할 수 있는데... 그러나 디지털은 아날로그에 비해 접근성이 떨어진다. 웹을 통한 액세스가 모든 이에게 편리할 것이라는 생각은 편견임. (특히 고령자들에게... 어머나 내가 무슨 말을...)
그래서 우리 팀은... 뭐 정기적인 팀 회의를 일단 기본적인 공유의 시간으로 활용하고 있으며, 현황판은... 넵. 와보신 분들은 아시겠지만 우리 사무실 벽면을 온통 덕지덕지 뒤덮고 있지효 -ㅅ-
... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...
글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a
그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.
1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.
... 프로토타이핑에만 1년 가까이 쓴거 같은데 말이졈. 그 과정에서 참... 오래오래 징하게도 싸웠다능.
그렇다고 지금 실개발 단계에서는 또 안싸우느냐, 그럴리가효.
즉 아무래도 논의 베이스이다 보니, 뭐 하나 결정하는 데에도 논의 - 논쟁 - 논의 - 논쟁 왔다갔다... 적잖은 시간을 소모한다.
뭐 하지만 아직은 이러한 시간 소모가 오히려 긍정적이라고 생각된다. 섣부른 개발보다는 이렇게 신중한 개발을 진행하는 것이 - 그리고 거기에 소요되는 시간은 정당하게 지출되는 비용이라 생각하는 것이 맞는 듯.
다만 추후에... 대중에게 게임을 공개하는 시점을 넘어서게 되면, 이제는 시간을 우리 마음대로 쓰지 못하는 상황이 '반드시' 닥쳐오게 될 것이다. 그 때엔 인해전술로 쏟아져 나올 다양한 이슈에 대하여 어떻게 기민한 대처를 할 수 있도록 프로세스를 재정립할 것인가...
이거이 우리에게 남아있는 숙제랄까.
그렇다고 지금 실개발 단계에서는 또 안싸우느냐, 그럴리가효.
즉 아무래도 논의 베이스이다 보니, 뭐 하나 결정하는 데에도 논의 - 논쟁 - 논의 - 논쟁 왔다갔다... 적잖은 시간을 소모한다.
뭐 하지만 아직은 이러한 시간 소모가 오히려 긍정적이라고 생각된다. 섣부른 개발보다는 이렇게 신중한 개발을 진행하는 것이 - 그리고 거기에 소요되는 시간은 정당하게 지출되는 비용이라 생각하는 것이 맞는 듯.
다만 추후에... 대중에게 게임을 공개하는 시점을 넘어서게 되면, 이제는 시간을 우리 마음대로 쓰지 못하는 상황이 '반드시' 닥쳐오게 될 것이다. 그 때엔 인해전술로 쏟아져 나올 다양한 이슈에 대하여 어떻게 기민한 대처를 할 수 있도록 프로세스를 재정립할 것인가...
이거이 우리에게 남아있는 숙제랄까.
2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?
100%라고 한다면 물론 거짓말. 팀 전체에게 공유되는 부분은 아무래도 각종 어셋들의 header 정도이다. 세부 항목까지 모두 공유했다가는... 공유하는 데에만 시간을 다 쓸테니 ㄱ- 사실 그렇게까지 필요하지는 않고.
(예를 들자면 나는 우리 게임에 림 라이트가 대충 어떻게 사용된다... 라는 정도까지만 알 뿐, 그래서 구체적인 세팅은 어떻게 하나효... 뭐 이런 부분에 대해서는 그냥 모른다 -ㅁ- 거기까지 내가 알아야 함? AD와 TD를 믿읍시다 -ㅁ- 다만 내 눈에 영 이상하게 보인다면 용감무식하게 '때깔이 이상하자늠?'이라는 의견은 손쉽게 낼 수 있어야 하는거고)
그리고 인간이란 망각의 동물인지라, 아무래도 자신의 직군과 직접 연계되지 않는 부분에 대해서는 공유받는다 할지라도 시간이 좀 지나면 쉽사리 까먹게 된다. 아니 이건 자연스러운 일이니 뭐라 할 수 없다.
그럼에도 불구하고 한 번이나마 이야기를 들었던 사안은, 추후 리마인드할 때 기억을 떠올리기가 상대적으로 수월하기 때문에... 이거이 딱히 문제가 된 적은 없다.
다만 잠재적인 리스크는, 나중에 게임 어셋의 수가 지금보다 훨씬 더 많아지고, 복잡성이 증대되었을 때에도 지금과 같은 긍정적인 상황을 유지할 수 있을 것인가... 으음... 잘 모르겠다.
(예를 들자면 나는 우리 게임에 림 라이트가 대충 어떻게 사용된다... 라는 정도까지만 알 뿐, 그래서 구체적인 세팅은 어떻게 하나효... 뭐 이런 부분에 대해서는 그냥 모른다 -ㅁ- 거기까지 내가 알아야 함? AD와 TD를 믿읍시다 -ㅁ- 다만 내 눈에 영 이상하게 보인다면 용감무식하게 '때깔이 이상하자늠?'이라는 의견은 손쉽게 낼 수 있어야 하는거고)
그리고 인간이란 망각의 동물인지라, 아무래도 자신의 직군과 직접 연계되지 않는 부분에 대해서는 공유받는다 할지라도 시간이 좀 지나면 쉽사리 까먹게 된다. 아니 이건 자연스러운 일이니 뭐라 할 수 없다.
그럼에도 불구하고 한 번이나마 이야기를 들었던 사안은, 추후 리마인드할 때 기억을 떠올리기가 상대적으로 수월하기 때문에... 이거이 딱히 문제가 된 적은 없다.
다만 잠재적인 리스크는, 나중에 게임 어셋의 수가 지금보다 훨씬 더 많아지고, 복잡성이 증대되었을 때에도 지금과 같은 긍정적인 상황을 유지할 수 있을 것인가... 으음... 잘 모르겠다.
3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)
... 즉 바꿔 말하자면 일단 신입은 살아남기 힘든 구조이다 -ㅅ- 프로세스가 개발자에게 '우리는 이런 게임을 만들거등. 너 이거 다 알아야 해. 하지만 자세한 설명은 생략한다. 대충 말해도 다 알아듣겠지?'라는 부분을 계속 강요(?)하는 구조이기 땜시...
더불어 누군가 일을 던져주는 수동적인 프로세스가 아니라, 능동적으로 개발의 흐름을 지속적으로 조망하며 자신의 일을 찾아서 해야 하는 구조이기 때문에... 팀원에게 요구되는 능동성의 수준이 높다. 양날의 검이랄까? 이 흐름에 맞추어 잘하면 당연히 좋지만, 잘 못하는 경우에는... 으음 이럴 땐 또 가차없죠 -ㅅ-
그나마 다들 닳고 닳은(?) 경력자들이고, 또 대부분 파트장급 이상 출신들이 많은지라 이런 프로세스를 돌릴 수 있는 것이 아닐까?
그리고 더불어... 사실 이건 난 잘 모르겠는 부분이긴 한데, 이러한 프로세스는 개발자로 하여금 끝없는 자기 성찰(?)을 요구하고, 그만큼 또 강한 스트레스를 유발시키는 듯 싶다.
... 나야 '내 역량이 모자른다 싶으면 자르시등가. 거기까지가 내 한계인갑지. 어쩔라미?'라는 뻔뻔한 배째라 정신으로 무장하고 있기 때문에 잘 모르겠는데 -ㅅ-;;;, 몇몇 이들은 일이 자신에게 요구하는 수준을 자신이 충족시키지 못하고 있다는 생각에 괴로워하는 모습을 보이곤 한다.
으음... 내가 보기엔 다들 잘하고 있는 것 같은데 -ㅁ- 일헌 자기 자신에게 지나치게 엄격한 살암들 같으니 ;;;
아무튼 그런 문제가 있는 것... 같다.
더불어 누군가 일을 던져주는 수동적인 프로세스가 아니라, 능동적으로 개발의 흐름을 지속적으로 조망하며 자신의 일을 찾아서 해야 하는 구조이기 때문에... 팀원에게 요구되는 능동성의 수준이 높다. 양날의 검이랄까? 이 흐름에 맞추어 잘하면 당연히 좋지만, 잘 못하는 경우에는... 으음 이럴 땐 또 가차없죠 -ㅅ-
그나마 다들 닳고 닳은(?) 경력자들이고, 또 대부분 파트장급 이상 출신들이 많은지라 이런 프로세스를 돌릴 수 있는 것이 아닐까?
그리고 더불어... 사실 이건 난 잘 모르겠는 부분이긴 한데, 이러한 프로세스는 개발자로 하여금 끝없는 자기 성찰(?)을 요구하고, 그만큼 또 강한 스트레스를 유발시키는 듯 싶다.
... 나야 '내 역량이 모자른다 싶으면 자르시등가. 거기까지가 내 한계인갑지. 어쩔라미?'라는 뻔뻔한 배째라 정신으로 무장하고 있기 때문에 잘 모르겠는데 -ㅅ-;;;, 몇몇 이들은 일이 자신에게 요구하는 수준을 자신이 충족시키지 못하고 있다는 생각에 괴로워하는 모습을 보이곤 한다.
으음... 내가 보기엔 다들 잘하고 있는 것 같은데 -ㅁ- 일헌 자기 자신에게 지나치게 엄격한 살암들 같으니 ;;;
아무튼 그런 문제가 있는 것... 같다.
실제로 이로 인해 뼈아픈 손실도 몇 번 있었고 크흑 ;ㅁ;
4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?
사실 이거이 가장 아리까리한 부분인데... 20여명 정도의 중규모 팀에서는 이러한 프로세스를 운영하는 데에 별반 문제가 발생하지 않는다.
하지만 개발 인원이 5~60명, 혹은 수백명인 경우에도... 과연 이런 프로세스를 적용하는 것이 가능할까?
사실 [5번 글]에서 언급한 3번째 프로세스의 문제가 발생한 원인 중의 하나는 인원이 통제하기 힘들 정도로 많았다는 점이 아니었을까 싶다.
당장 손쉽게 생각할 수 있는 것은 역시 공유 자체의 난점. 직접 공유는 힘들고 간접 공유 체제를 만들어야 하지 않을까... 그 경우에 과연 이만큼의 효과를 기대할 수 있을까...?
이 부분을 잘 모르겠다. 이 프로세스는 과연 범용적일까? 대규모 인원에 대해서는 무언가 다른 방도를 찾아야하지 않을까?
... 뭐 당장 우리 개발팀에게는 별반 문제가 되지 않는 부분이지만, 그럼에도 불구하고 프로세스 자체에 대한 탐구로써, 이 부분은 여전히 의문으로 남는다.
하지만 개발 인원이 5~60명, 혹은 수백명인 경우에도... 과연 이런 프로세스를 적용하는 것이 가능할까?
사실 [5번 글]에서 언급한 3번째 프로세스의 문제가 발생한 원인 중의 하나는 인원이 통제하기 힘들 정도로 많았다는 점이 아니었을까 싶다.
당장 손쉽게 생각할 수 있는 것은 역시 공유 자체의 난점. 직접 공유는 힘들고 간접 공유 체제를 만들어야 하지 않을까... 그 경우에 과연 이만큼의 효과를 기대할 수 있을까...?
이 부분을 잘 모르겠다. 이 프로세스는 과연 범용적일까? 대규모 인원에 대해서는 무언가 다른 방도를 찾아야하지 않을까?
... 뭐 당장 우리 개발팀에게는 별반 문제가 되지 않는 부분이지만, 그럼에도 불구하고 프로세스 자체에 대한 탐구로써, 이 부분은 여전히 의문으로 남는다.
그래서 난 대규모 팀에 속해 있으면서, 대규모에 걸맞는 프로세스가 어떻게 구축되고 운영되는지를 알려주는 산업 스파이가 필요하...
에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;
또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;
... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;
그래도 이제 남은건 결론 뿐이다.
게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.
그럼 마지막 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/344
|
[글강, 2009/02/04 00:18, Game]
이건 뭐 재미도 없고 감동도 없는 글이 쓰잘데기 없이 길기만 욜라리 길어서리 벌써 6번일세 ㄱ-
이 즈음 해서 잠시 정리 좀.
[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.
[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.
[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-
[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.
[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...
그래서 이제 6번부터는...
기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.
넵. 저는 그게 개발 프로세스라고 생각해효.
그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?
그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.
그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.
그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.
지금까지 내가 경험해 본 개발 프로세스는 총 4가지.
사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.
[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)
암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.
그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...
물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...
그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.
자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
우와... 이게 뭐야.
적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-
아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)
당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.
그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.
하지만 이미 스크롤 압뷁 ㄱ-
... 7번으로 넘어가야 겠네효.
이 즈음 해서 잠시 정리 좀.
[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.
[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.
[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-
[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.
[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...
그래서 이제 6번부터는...
기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.
넵. 저는 그게 개발 프로세스라고 생각해효.
그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?
... 와 이렇게까지 이야기하니 뭔가 좀 무서운데 -ㅁ-;
그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.
그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.
그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.
지금까지 내가 경험해 본 개발 프로세스는 총 4가지.
사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.
[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)
암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.
그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...
물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...
그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.
자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
일단 의도의 설정. 디렉터의 업무라고 정의한 바 있지만, 그렇다고 또 디렉터가 독고다이로 할 필요까지는 없는 일. 개발팀원들의 도움을 받을 수 있는 일이다. (물론 최종 결정은 디렉터가 함미다.)
그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.
아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...
여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.
여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.
그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.
이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.
대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.
물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/
... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.
그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.
여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?
세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.
그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.
여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.
... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.
그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.
아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...
여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.
여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.
그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.
이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.
대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.
물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/
... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.
그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.
여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?
세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.
그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.
여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.
... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자 고유 업무이긴 하지만, 이걸 나 혼자 하지는 않는다. 역시 또 '논의'라는 놈이 끼어드는데...
애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.
그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?
물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.
스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.
역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.
다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.
애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.
그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?
물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.
스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.
역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.
다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
기획자들이 흔히 내지르는 비명. '죽어라 문서를 만들어봤자 아무도 안읽어!'라는 것은... 사실 해결이 난해한 일이다.
당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)
그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?
어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.
공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.
기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.
당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)
그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?
어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.
공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.
... 물론 기획자가 특출난 문서 작성 능력을 발휘하야 가독성 높은 정리를 해주신다면 더욱 금상첨화이겠지만, 내가 그렇게 잘 하고 있는 것인지는 알 수 없으니 패스 ( --) 딱히 불만을 표출하시지는 않던데 말이졈 ㄷㄷㄷ
기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
3번과 똑같다. 물론 구현이 아니라 제작이니까, 양식이랄까 그런건 좀 달라지지만 기본적인 기조는 동일하다.
모든 것은 '우리'가 게임을 만들기 위하여.
모든 것은 '우리'가 게임을 만들기 위하여.
5. 어셋 구현 후에는... 리소스들의 조립.
이건 기획자가 독고다이로 하게 되는 일이지만, 어차피 이전 단계에서 충분한 논의가 전제되었다면 기획자가 독고다이로 한다 해서 딱히 문제될 것은 없다.
그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.
[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.
그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.
[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
역시 기획자 고유 업무. 하지만 이 단계에서도 수많은 논의가 끼어들게 된다.
밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.
만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.
기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.
즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.
밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.
만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.
기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.
즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
자 즐거운 테스트 시간이야. 물론 테스트 업무 자체의 주도는 QA와 기획자가 하게 마련이지만, 참여는 모든 팀원이 함께 한다.
그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.
뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.
그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.
뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.
우와... 이게 뭐야.
적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-
적는 내가 다 부끄러워서 손발이 오그라드네 ;;;
아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)
당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.
그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.
하지만 이미 스크롤 압뷁 ㄱ-
... 7번으로 넘어가야 겠네효.
|
Trackback Address :: http://glekang.com/trackback/343
|
[글강, 2009/02/03 00:25, Game]
이제 슬슬 삼천포야 ㄱ-
뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')
이번엔 다른 관점에서 한 번 접근해 보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?
개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.
이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.
이제는 좀 지겨운 ;;; 7단계 다시 시작.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!
이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.
즉, 재미 창출의 전문가처럼 보이게 되는 것이다.
더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.
사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...
그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.
그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?
과연?! 퍽이나?!
게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?
물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.
코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.
그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?
자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?
글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.
그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?
글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.
혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...
내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.
등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.
수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;
더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...
이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.
게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.
혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.
어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.
결론을 내려 보자면...
기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,
기획자가 아무리 열심히 일을 잘 한다 할지라도,
개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,
이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,
기계적으로 일을 하게끔 만들어,
필연적으로(!) 수많은 문제를 야기하게 되고,
그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,
최종적으로는 게임의 성공 가능성을 깎아먹게 된다.
... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;
... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.
'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'
기획자 무용론에 동참하셨군효 /박수
자아, 다시 처음으로 돌아가보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.
역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;
게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.
저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.
그럼에도 불구하고...
그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?
위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?
그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?
... 논리적으로만 보자면 그리 부당하지 않아 보이는데?
하아...? 잠깐만.
그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?
그럼 기획자라는걸 다 치워버리면 괜찮은건가?
하지만 기획자들을 다 치워버린 상황을 상정해 보자면...
[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.
그럼 무엇이 문제인가?
... 이미 충분히 길다. 다음 글로.
다음 글의 힌트.
저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?
뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')
이번엔 다른 관점에서 한 번 접근해 보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?
개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.
이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.
이제는 좀 지겨운 ;;; 7단계 다시 시작.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
여전히 의도는 디렉터가 설정하지만, 의도를 달성하기 위한 아이디어를 기획자'만' 내고, 기획자들끼리'만' 이 아이디어에 대해 논의한다. 뭐 디렉터가 여기 참여할 수는 있겠다만...
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자'만' 게임 디자인을 한다. 즉 다른 직군과의 소통 없이 기획자 독고다이로.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
기획자 혼자서 작성한 구현 스펙을 '일방적으로' 프로그래머에게 전달한다. 프로그래머 입장에서는 이 스펙은 뜬금없이 떨어진 일이 되고, 게임
어셋의 전후 맥락을 파악하지 못한 상황에서 '기계적으로' 구현만 하게 된다. 물론 상호 논의를 통해 스펙을 수정하는 가운데
일방성이 조금 완화될 수는 있지만, 프로그래머가 맥락에서 소외되어 있다는 점은 여전히 변하지 않는다.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
기획자 혼자서 작성한
리소스 제작 명세를 '일방적으로' 아티스트에게 전달한다. 아티스트 입장에서는 이 명세는 뜬금없이 떨어진 일이 되고, 게임 어셋의
전후 맥락을 파악하지 못한 상황에서 '기계적으로' 제작만 하게 된다. 물론 상호 논의를 통해 명세를 수정하는 가운데 일방성이
조금 완화될 수는 있지만, 아티스트가 맥락에서 소외되어 있다는 점은 여전히 변하지 않는다.
5. 어셋 구현 후에는... 리소스들의 조립.
게임 어셋의 조립을 기획자'만' 한다.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
밸런싱을 기획자'만' 한다.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
테스트 및 검증을 QA와 기획자'만' 한다. 뭐 사람이 부족하면 다른 팀원들을 테스트에 참여시킬 수는 있겠다만, 검증해야 할 지점의 설정이나 피드백은 오직 기획자'만'.
요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!
이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.
즉, 재미 창출의 전문가처럼 보이게 되는 것이다.
더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.
사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...
그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.
그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?
과연?! 퍽이나?!
게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?
물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.
코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.
그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?
자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?
글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.
그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?
글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.
혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...
내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.
기획자 : 고민에 고민을 거듭해서 디자인 문서를 완벽하게(?) 만들었는데 아무도 안읽어! 뭐 하나 구현하고 제작할 때마다 계속
사람들을 감독(!)해야 하다니 아놔! 게임 나 혼자 만드냐?! 왜 이렇게들 자신이 만드는 게임에 관심이 없어? 게임의 전체적인
상에 대해서 당연히 다들 파악하고 있어야 하는거 아냐?!
프로그래머 : 뭐 이런 해괴한 시스템이 다 있노? 아무래도 이건 일관성에 문제가 있는 것 같... 기는 한데, 뭐 다른 부분들과의 연계 때문에 어쩔 수 없이 이렇게 된 것일라나? 다른 시스템을 모르니 할 말이 없네...
그런데 나한테 갑자기 50페이지짜리 문서를 휙 던져주면서, 3중 4중으로 연결된 다른 문서들도 참고해가며 구현을 하라니 어이가 좀 상실된다능.
어 잠깐만, 이거 구현하려면 예전에 만들었던 알고리즘을 갈아엎어야 하잖아? 아니 지난번에 이거 구현할 때엔 나중에 이런게 나올거라는 이야기 안하더니만!!!
그런데 나한테 갑자기 50페이지짜리 문서를 휙 던져주면서, 3중 4중으로 연결된 다른 문서들도 참고해가며 구현을 하라니 어이가 좀 상실된다능.
어 잠깐만, 이거 구현하려면 예전에 만들었던 알고리즘을 갈아엎어야 하잖아? 아니 지난번에 이거 구현할 때엔 나중에 이런게 나올거라는 이야기 안하더니만!!!
아티스트 : 만들라고 하니까 만들기는 하겠지만, 대체 이것들이 우리 게임 어디에 들어가는거지? 어라 이렇게 만들면 비쥬얼
퀄리티가 확 떨어질텐데? 다른 부분에서 퍼포먼스를 잡아먹기 때문에 어쩔 수 없는건가? 다른 부분을 모르니 할 말이 없네...
그런데 뜬금없이 날아온 컨셉 문서가 50페이지 -_-a 다 읽다가 지친다.
어 잠깐만, 이렇게 제작하면 전반적인 비쥬얼 컨셉이랑 어긋나잖아? 음? 비쥬얼 컨셉보다는 기능성을 우선하기로 결정했다고? 언제? 난 몰랐는데? 그냥 까라면 까라는거냐!!!
그런데 뜬금없이 날아온 컨셉 문서가 50페이지 -_-a 다 읽다가 지친다.
어 잠깐만, 이렇게 제작하면 전반적인 비쥬얼 컨셉이랑 어긋나잖아? 음? 비쥬얼 컨셉보다는 기능성을 우선하기로 결정했다고? 언제? 난 몰랐는데? 그냥 까라면 까라는거냐!!!
등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.
수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;
더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...
이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.
게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.
혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.
어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.
결론을 내려 보자면...
기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,
기획자가 아무리 열심히 일을 잘 한다 할지라도,
개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,
이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,
기계적으로 일을 하게끔 만들어,
필연적으로(!) 수많은 문제를 야기하게 되고,
그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,
최종적으로는 게임의 성공 가능성을 깎아먹게 된다.
... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;
결국 기획자 잘못이니까 욕먹을 만 하다고? 글쎄.
... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.
'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'
결국 기획자 잘못이니까 그런 생각이 맞다고? 글쎄.
기획자 무용론에 동참하셨군효 /박수
자아, 다시 처음으로 돌아가보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.
역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;
게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.
글쎄. 나는 의문이 든다.
저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.
그럼에도 불구하고...
그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?
위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?
그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?
... 논리적으로만 보자면 그리 부당하지 않아 보이는데?
하아...? 잠깐만.
그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?
그럼 기획자라는걸 다 치워버리면 괜찮은건가?
하지만 기획자들을 다 치워버린 상황을 상정해 보자면...
[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.
그럼 무엇이 문제인가?
... 이미 충분히 길다. 다음 글로.
다음 글의 힌트.
저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?
|
Trackback Address :: http://glekang.com/trackback/342
|
[글강, 2008/12/29 22:25, Game]
아직은 공력도, 경력도 미천하야... 감히 이런 글을 싸질러놓는 것이 매우 조심스럽기 짝이 없으나...
미흡한 경험에서 우러나오는 주관, 혹은 편견으로 끄적끄적.
IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나 그래스 호핑(grass hopping)이 잦은 곳이다.
거기에 더하여, 역시나 IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나... 좁디 좁다 -ㅁ-; 어찌나 좁으신지 한 두 다리만 걸치면 모르는 사람이 없을 정도.
이러한 업계의 양상은 개발자로 하여금 어떠한 사고 방식을 가지도록 은연중에 강요하게 된다.
혹은,
등등등?
결국 일종의 업계 불문율이랄까, 혹은 약간 거시적인 프로세스같은 것이 발생하게 된다. 이 업계가 유지되는 방식이라고까지 이야기하자면 좀 거창하겠지만 -ㅁ-;
아무튼 나는 나름대로 저런 사고 방식을 가지고 사는 것이 맞다고 생각했다.
결국 그 덕에 업계가 원활하게 돌아가고, 프로젝트는 진행되고, 게임은 개발되어 나오는 것이니까.
팀원이 나가고 들어오는 것에 따라 프로젝트가 흔들린다면, 어디 게임 개발 할 수 있겠는가.
쿨하지? 쿨할까? 쿨할라나?
반대 급부라 할만한 경우를 목격한 적도 있다.
아직도 존속되고 있을는지는 모르겠지만, 소위 '패밀리'라 불릴만한 개발자 그룹(?)이 통째로 이직을 해가면서 단순 팀원의 그래스 호핑이 아닌, 팀 단위의 그래스 호핑을 하는 것을 본 적이 있는데...
따뜻하고 애틋한... 이라기 보다는 우와 뭔가 부정적인 것 같아. 이것도 일종의 뒷담화가 되려나 -ㅁ-;
아무튼 저런 경우를 본 적이 있는데... 글쎄, 결국 그 패밀리가 패밀리의 이름으로 성공적인 결과물을 낸다면 저것도 나름 괜찮지 않을까? 싶기도 하지만, 역시 그 때나 지금이나 난 저런 방식에 대해서는 부정적이다.
그렇기에 역시 개발자가 중심에 두어야 하는 것은 프로젝트의 완수. 사람을 중심에 두어서는 곤란하다... 라고 생각해 왔는데...
솔직히 요즘은 잘 모르겠다 ㄱ-
이 뭐 내가 차가운 도시 남자. 하지만 내 여자에게는 따뜻하겠지? ... 도 아니고 말야, 쿨! 쿨! 쿨! 외치다가 얼어죽겠구만 ㄱ-
그렇다고 동료를 동료 이상으로, 더욱 살갑고 따땃하게 대하면서 살면 세상은 좀 더 아름다와지지 않을까? ... 뭐 이런 이야기를 하려는 것도 아니다.
여전히 개발자에게 있어 프로젝트의 완수를 중심에 두는 것은 맞는 것이라 생각한다.
하지만 이를 위해 개발자가 자기 스스로를, 그리고 동료들을 톱니바퀴로 치부하는 것이 과연 맞을까?
요걸 잘 모르겠다. 그렇게 돌아가는 팀이 과연 좋은 팀일까?
동료에게 동료 이상을 기대하지 않는 조직은 거의 필연적으로 정체된다고 할까, 혹은 말라붙어 버리기가 쉽다.
게임 개발이라는 직업 내에 여러가지 직군이 존재하기는 하지만, 결국 이 직군들 중 어느 하나도 독립적으로 기능하는 것은 없으며, 모든 직군은 서로 얽히고 섥히게 마련이다.
그러나 자신과 타인을 톱니바퀴로 생각하는 팀원들에게 있어 이러한 얽히고 섥히기는... 쉬운 일이 아니다. 심지어 조직이 크든 작든 관계 없이 말이다.
물론 이 얽히는 것을 중간에서 잘 관리해주는 조율자가 있다면, 서로가 서로를 톱니바퀴로 인식하면서도 얼추얼추 프로젝트가 잘 진행되는 것처럼 보이기는 하지만... 글쎄, 내 경험상 이런 방식은 결국 그 조율자를 죽이고 만다 ㄱ-
그리고 조율자가... 죽지는 않고 ㄱ-;;; 혹여 퍼포먼스가 3~40%만 저하된다 하더라도 그 조직은 급속도로 말라붙는다.
혹시 조율자가 없더라도, 팀원들이 애초에 '공적인 피드백'을 자주 할 수 있는 프로세스를 만든다면 괜찮지 않을까...?
글쎄 -ㅁ- 이거이 참 이상적이긴 한데, 인간이라는게 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니라서리... 단적으로 말해 '모든 중요한 결정은 담배터에서 나온다'라는 말이 괜히 있는 것이 아니다.
즉 프로세스만으로는 부족하지 않나 싶다.
결국 조직이 말라붙어 버리게 되면... 직군 사이의 피드백이 사라지고, 누구도 게임의 어떠한 요소에 대하여 책임지지도 - 관심가지지도 않는 사태가 벌어지게 되는데...
뭐 그럼에도 불구하고 프로젝트가 완수될 수는 있다. 제대로 된 게임이 나올 가능성은 좀 많이 낮아지므로, 성공 가능성은 로또 비슷해져 버리지만 -ㅁ-;
그렇다고 공적인 동료가 사적인 영역을 마구마구 넘나드는 조직의 경우에는 반대로... 조직이 외부에 대하여 배타적이 될 가능성이 높고, 조직 내에서는 비효율적인 운영이 이루어질 가능성이 높다.
이러한 조직에서는 사람 하나의 가치가 지나치게 커지는 위험이 존재한다.
팀원의 이탈이 팀 전체의 사기에 악영향을 미칠 수 있고, 반대로 새로운 팀원의 진입은 그 조직이 배타적인만큼 쉽지가 않다.
출혈은 있을 수 있지만, 수혈은 어려운... 이게 뭔가효. 자살해가는 조직도 아니고 ㄱ-
더불어 조직 내에서 서로의 사적인 영역을 넘나들다 보면... 한국에서 특히 보기 쉬운 구도인 '형님 / 아우' 서열이 발생하기 쉽고, '형님에게 굽신굽신 / 아우니까 봐준다'와 같은... 곤란한 상황이 개발 효율을 저해하기가 쉽다.
팀원들 서로가 사적인 친분을 유지하되, 공적인 부분에 대해서는 최대한 드라이하게 접근한다면...?
위에서도 말했지만 인간이란 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니...
그럼 그러한 공적인 부분을 조율해 줄 관리자를 외부에 둔다면...?
배타적인 조직은 그런 관리자를... 죽인다 ㄱ- 혹은 조직이 빠져버리등가 ㄱ- 그래스 호핑~
그래서 결국 프로젝트의 완수보다는 조직의 안녕이 우선 가치로 정립되는 사태가 벌어지고 만다. 뭐 이런걸 소위 개발을 말아먹는 정치라고 불러도 되지 않을까나...
그러니까 결국 정도의 문제인데...
가장 좋은 것은 그 중간일까?
즉, 팀원들 사이에 사적인 친분이 어느 정도 존재하기에 이는 원활한 피드백의 원천이 되어주고...
그러나 이 친분이 공적인 영역을 넘어서지 않아, 일에 대해서는 최대한(!) 냉정하면서도 대등한 관계가 형성되며...
더불어 개발 프로세스는 각 직군들이 최대한 서로 얽히고 섥힐 수 있도록 기능해 주어야 한다.
쯥. 말은 쉽다만... ㄱ-
아직은 나도 이러한 이상적인(?) 구조를 어떻게 하면 형성하고, 유지할 수 있을는지를 잘 모르겠다.
이제야 겨우 '톱니바퀴로는 안되겠는데?'를 깨달은 정도이고...
그렇다고 동료한테 어느 정도까지의 선을 걷어내고, 어느 정도까지의 선을 허용해야 하는 것인지 역시 아직은 잘 모르겠는 모호한 상태이며... -ㅁ-
더구나 그럼에도 불구하고 발생할 수 밖에 없는 그래스 호핑에 대하여... 이런 조직이 어느 정도 가지게 되는 취약성 - 그러니까 결국 대미지를 어떻게 컨트롤해야 할는지도 잘 모르겠다.
... 이거 뭔가 사회 조직론 내지는 경영학(?)을 찾아보면, 이런 이야기가 좀 나와있지 않을까 싶기는 한데 ( --)
현재로서는 현재 내가 지금 몸담고 있는 팀이 나름 줄타기를 해나가는 모습을 관찰하고, 참여하면서 좀 더 생각을 진행하는 수밖에 없을 듯 싶다.
팀 내에서 호형호제가 이루어질 만큼의 사적인 친분이 있으면서, 이것이 공적인 영역을 침범하지는 않고, 잦은 피드백을 반 강제(?)로 보장하는 프로세스... 를 일단 어느 정도는 아슬아슬 줄타기하고 있는 우리 팀은...
이건 아무래도 더 시간을 두고, 조심스레 지켜봐야하지 않을까나 싶다.
아니 잠깐, 방관자로 지켜보겠다는 것이 아니라... 결국은 나 역시 한 명의 팀원으로서.
미흡한 경험에서 우러나오는 주관, 혹은 편견으로 끄적끄적.
IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나 그래스 호핑(grass hopping)이 잦은 곳이다.
오늘 함께 일하고 있는 동료가, 내일은 다른 개발사, 혹은 다른 팀으로 옮겨 가는 것은 매우 흔한 일. 너무나도 흔해서 언급할 꺼리조차 되지 않는다.
거기에 더하여, 역시나 IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나... 좁디 좁다 -ㅁ-; 어찌나 좁으신지 한 두 다리만 걸치면 모르는 사람이 없을 정도.
따라서 내일 다른 개발사, 혹은 다른 팀으로 옮겨 간 동료가, 내일 모레에는 다시 같은 개발사, 혹은 같은 팀으로 돌아오는 것 역시... 흔하다고 할 정도까지는 아니지만 희귀한 일 또한 아니다.
이러한 업계의 양상은 개발자로 하여금 어떠한 사고 방식을 가지도록 은연중에 강요하게 된다.
동료의 이직에 대하여 초연하라. 그 것은 그 사람의 권리이다. 물론 프로젝트의 상황에 따라 도의적인 차원의 문제가 있을 수는 있지만, 애초에 팀원의 이탈은 프로젝트 단위에서 발생할 수 있는 리스크 중의 하나로 관리되어야 한다.
즉, 동료를 동료 이상으로 너무 깊이 생각하지 마라. 너무 기대하고 신뢰하지 마라. 쿨하라.
즉, 동료를 동료 이상으로 너무 깊이 생각하지 마라. 너무 기대하고 신뢰하지 마라. 쿨하라.
혹은,
동료의 치부에 대하여 초연하라. 그 것은 그 사람의 치부일 뿐, 왈가왈부할 성질의 것이 못된다. 이 좁은 업계에는 비밀이라는 것이 없다. 뒷담화는 돌고 돌아 결국 자기 자신의 뒤통수를 치게 될 뿐이다.
즉, 동료에게 너무 큰 기대를 하지 말아야하는 만큼, 동시에 동료의 부정적인 측면에 대해서도 너무 관여하지 마라. 쿨하라.
즉, 동료에게 너무 큰 기대를 하지 말아야하는 만큼, 동시에 동료의 부정적인 측면에 대해서도 너무 관여하지 마라. 쿨하라.
등등등?
결국 일종의 업계 불문율이랄까, 혹은 약간 거시적인 프로세스같은 것이 발생하게 된다. 이 업계가 유지되는 방식이라고까지 이야기하자면 좀 거창하겠지만 -ㅁ-;
아무튼 나는 나름대로 저런 사고 방식을 가지고 사는 것이 맞다고 생각했다.
결국 그 덕에 업계가 원활하게 돌아가고, 프로젝트는 진행되고, 게임은 개발되어 나오는 것이니까.
팀원이 나가고 들어오는 것에 따라 프로젝트가 흔들린다면, 어디 게임 개발 할 수 있겠는가.
모든 것은 프로젝트의 완수를 위하여. 팀원은 결국 톱니바퀴 중의 하나. 아 물론 나 역시도 하나의 톱니바퀴일 뿐. 서로에게 그 이상을 기대하지 않는다면... 그래스 호핑이 아무리 잦다 하더라도, 프로젝트에는 최소한의 영향만을 줄 수 있다. 모든 것은 프로젝트의 완수를 위하여.
쿨하지? 쿨할까? 쿨할라나?
반대 급부라 할만한 경우를 목격한 적도 있다.
아직도 존속되고 있을는지는 모르겠지만, 소위 '패밀리'라 불릴만한 개발자 그룹(?)이 통째로 이직을 해가면서 단순 팀원의 그래스 호핑이 아닌, 팀 단위의 그래스 호핑을 하는 것을 본 적이 있는데...
모든 것은 패밀리의 안녕을 위하여. 프로젝트 완수는 패밀리의 가치를 드높이기 위하여. 물론 패밀리 내에서는 노골적인(?) 봐주기가 횡행하며, 패밀리 외부인에 대해서는 철저히 배타적으로. 만약 패밀리의 존재가 프로젝트 완수에 걸림돌이 된다면, 차라리 프로젝트를 포기하고 그래스 호핑~ 모든 것은 패밀리의 안녕을 위하여.
따뜻하고 애틋한... 이라기 보다는 우와 뭔가 부정적인 것 같아. 이것도 일종의 뒷담화가 되려나 -ㅁ-;
아무튼 저런 경우를 본 적이 있는데... 글쎄, 결국 그 패밀리가 패밀리의 이름으로 성공적인 결과물을 낸다면 저것도 나름 괜찮지 않을까? 싶기도 하지만, 역시 그 때나 지금이나 난 저런 방식에 대해서는 부정적이다.
그렇기에 역시 개발자가 중심에 두어야 하는 것은 프로젝트의 완수. 사람을 중심에 두어서는 곤란하다... 라고 생각해 왔는데...
솔직히 요즘은 잘 모르겠다 ㄱ-
이 뭐 내가 차가운 도시 남자. 하지만 내 여자에게는 따뜻하겠지? ... 도 아니고 말야, 쿨! 쿨! 쿨! 외치다가 얼어죽겠구만 ㄱ-
그렇다고 동료를 동료 이상으로, 더욱 살갑고 따땃하게 대하면서 살면 세상은 좀 더 아름다와지지 않을까? ... 뭐 이런 이야기를 하려는 것도 아니다.
여전히 개발자에게 있어 프로젝트의 완수를 중심에 두는 것은 맞는 것이라 생각한다.
아니 이건 개발자 이전에, 돈받고 일하는 프로라면 당연한 것이 아닌가 싶은데...
아니 프로 이전이라 해도, 애초에 직업이 자아 실현의 도구라면 또 당연하지 않나...
하지만 이를 위해 개발자가 자기 스스로를, 그리고 동료들을 톱니바퀴로 치부하는 것이 과연 맞을까?
요걸 잘 모르겠다. 그렇게 돌아가는 팀이 과연 좋은 팀일까?
동료에게 동료 이상을 기대하지 않는 조직은 거의 필연적으로 정체된다고 할까, 혹은 말라붙어 버리기가 쉽다.
게임 개발이라는 직업 내에 여러가지 직군이 존재하기는 하지만, 결국 이 직군들 중 어느 하나도 독립적으로 기능하는 것은 없으며, 모든 직군은 서로 얽히고 섥히게 마련이다.
그러나 자신과 타인을 톱니바퀴로 생각하는 팀원들에게 있어 이러한 얽히고 섥히기는... 쉬운 일이 아니다. 심지어 조직이 크든 작든 관계 없이 말이다.
물론 이 얽히는 것을 중간에서 잘 관리해주는 조율자가 있다면, 서로가 서로를 톱니바퀴로 인식하면서도 얼추얼추 프로젝트가 잘 진행되는 것처럼 보이기는 하지만... 글쎄, 내 경험상 이런 방식은 결국 그 조율자를 죽이고 만다 ㄱ-
그리고 조율자가... 죽지는 않고 ㄱ-;;; 혹여 퍼포먼스가 3~40%만 저하된다 하더라도 그 조직은 급속도로 말라붙는다.
혹시 조율자가 없더라도, 팀원들이 애초에 '공적인 피드백'을 자주 할 수 있는 프로세스를 만든다면 괜찮지 않을까...?
글쎄 -ㅁ- 이거이 참 이상적이긴 한데, 인간이라는게 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니라서리... 단적으로 말해 '모든 중요한 결정은 담배터에서 나온다'라는 말이 괜히 있는 것이 아니다.
즉 프로세스만으로는 부족하지 않나 싶다.
결국 조직이 말라붙어 버리게 되면... 직군 사이의 피드백이 사라지고, 누구도 게임의 어떠한 요소에 대하여 책임지지도 - 관심가지지도 않는 사태가 벌어지게 되는데...
뭐 그럼에도 불구하고 프로젝트가 완수될 수는 있다. 제대로 된 게임이 나올 가능성은 좀 많이 낮아지므로, 성공 가능성은 로또 비슷해져 버리지만 -ㅁ-;
그렇다고 공적인 동료가 사적인 영역을 마구마구 넘나드는 조직의 경우에는 반대로... 조직이 외부에 대하여 배타적이 될 가능성이 높고, 조직 내에서는 비효율적인 운영이 이루어질 가능성이 높다.
이러한 조직에서는 사람 하나의 가치가 지나치게 커지는 위험이 존재한다.
팀원의 이탈이 팀 전체의 사기에 악영향을 미칠 수 있고, 반대로 새로운 팀원의 진입은 그 조직이 배타적인만큼 쉽지가 않다.
출혈은 있을 수 있지만, 수혈은 어려운... 이게 뭔가효. 자살해가는 조직도 아니고 ㄱ-
더불어 조직 내에서 서로의 사적인 영역을 넘나들다 보면... 한국에서 특히 보기 쉬운 구도인 '형님 / 아우' 서열이 발생하기 쉽고, '형님에게 굽신굽신 / 아우니까 봐준다'와 같은... 곤란한 상황이 개발 효율을 저해하기가 쉽다.
팀원들 서로가 사적인 친분을 유지하되, 공적인 부분에 대해서는 최대한 드라이하게 접근한다면...?
위에서도 말했지만 인간이란 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니...
그럼 그러한 공적인 부분을 조율해 줄 관리자를 외부에 둔다면...?
배타적인 조직은 그런 관리자를... 죽인다 ㄱ- 혹은 조직이 빠져버리등가 ㄱ- 그래스 호핑~
그래서 결국 프로젝트의 완수보다는 조직의 안녕이 우선 가치로 정립되는 사태가 벌어지고 만다. 뭐 이런걸 소위 개발을 말아먹는 정치라고 불러도 되지 않을까나...
그러니까 결국 정도의 문제인데...
톱니바퀴는 위험하다.
패밀리도 위험하다.
가장 좋은 것은 그 중간일까?
즉, 팀원들 사이에 사적인 친분이 어느 정도 존재하기에 이는 원활한 피드백의 원천이 되어주고...
그러나 이 친분이 공적인 영역을 넘어서지 않아, 일에 대해서는 최대한(!) 냉정하면서도 대등한 관계가 형성되며...
더불어 개발 프로세스는 각 직군들이 최대한 서로 얽히고 섥힐 수 있도록 기능해 주어야 한다.
쯥. 말은 쉽다만... ㄱ-
아직은 나도 이러한 이상적인(?) 구조를 어떻게 하면 형성하고, 유지할 수 있을는지를 잘 모르겠다.
이제야 겨우 '톱니바퀴로는 안되겠는데?'를 깨달은 정도이고...
그렇다고 동료한테 어느 정도까지의 선을 걷어내고, 어느 정도까지의 선을 허용해야 하는 것인지 역시 아직은 잘 모르겠는 모호한 상태이며... -ㅁ-
더구나 그럼에도 불구하고 발생할 수 밖에 없는 그래스 호핑에 대하여... 이런 조직이 어느 정도 가지게 되는 취약성 - 그러니까 결국 대미지를 어떻게 컨트롤해야 할는지도 잘 모르겠다.
... 이거 뭔가 사회 조직론 내지는 경영학(?)을 찾아보면, 이런 이야기가 좀 나와있지 않을까 싶기는 한데 ( --)
현재로서는 현재 내가 지금 몸담고 있는 팀이 나름 줄타기를 해나가는 모습을 관찰하고, 참여하면서 좀 더 생각을 진행하는 수밖에 없을 듯 싶다.
팀 내에서 호형호제가 이루어질 만큼의 사적인 친분이 있으면서, 이것이 공적인 영역을 침범하지는 않고, 잦은 피드백을 반 강제(?)로 보장하는 프로세스... 를 일단 어느 정도는 아슬아슬 줄타기하고 있는 우리 팀은...
글쎄, 어느 정도 배타성을 가지고 있지는 않을까. 어느 정도 말라있는 것은 아닐까. 혹은 팀의 규모가 중소 정도이기 때문에 겨우 유지되는 것은 아닐까. 또는 이 모든 것이 결국 한 사람의 조율자를 죽이고 있는 것은 아닐까.
이건 아무래도 더 시간을 두고, 조심스레 지켜봐야하지 않을까나 싶다.
아니 잠깐, 방관자로 지켜보겠다는 것이 아니라... 결국은 나 역시 한 명의 팀원으로서.
|
Trackback Address :: http://glekang.com/trackback/328
|
