'민주'에 해당되는 글 1건
[글강, 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
|
