내맘대로..... 게임 이야기

비효율적인 면을 제거하면 된다. 


이런 경우도 아니고.. ㅡㅡ;;






















덧붙여서, 비효율적인 면은 어떻게 알아낼까? 20:80 법칙은 문제를 단순화 시키는데 유용하다. 게임 개발에서 가장 많은 비효율은 의사소통과 업무 선후관계에서 발생한다. 잘못된 의사소통은 서로간의 오해를 낳게 되고, 결국은 품질 저하와 재작업이 발생되는 원인이 된다.

의사소통은 단순히 개인의 문제가 아니라 시스템의 문제라고 봐야 옳다. 단순히 개인의 마음가짐이 바뀐다고 좋아지는 것이 아니라 시스템 적으로 (개인 차원에서, 팀 차원에서, 본부 차원에서, 또는 전사적 차원에서) 지속적인 개선 노력이 필요하다. 파티션을 없애거나 워룸을 만들거나, 데일리 미팅을 하거나 등등 의사소통을 개선시키는 방법이 있다. 무엇보다 의사소통 개선의 가장 기본은 바로 face2face 이다. 협업을 해야하는 두 직원이 서로 다른 층에 있거나 다른 건물에 있거나 또는 다른 지역에 있거나 할 경우 (다른 파티션에 속해있거나..) 의사소통 개선에 아무리 노력해도 한계가 있다는 점은 분명하다.

업무 선후관계에 따른 작업 지연 문제는 쉽게 풀 수 없는 문제이지만, 효율적인 스케쥴링과 편리하고 안정적인 제작도구로 극복해 나가야 한다.

효율적인 스케쥴링은 쉽게 달성할 수도 없고, 그로 인해 수많은 방법론들이 난무하고 있는 실정이다. 나는 가장 중요한 것은 지속적인 개선 의지와 자기발전적인 조직 구성이라고 생각한다. 조직은 문제제기 - 변화시도 - 카오스 - 발전 의 사이클을 반복함으로 발전해나가게 된다. 문제는 문제제기 - 변화시도 - 카오스로 넘어가기 위해서는 특별한 노력이 필요하고 더 나아가서는 이것이 자연스러운 조직문화로 정착되어야 한다. 문제제기는 상하관계가 확실한 수직적인 조직에서는 일어나기 힘들다. 수평적인 조직 구조와 문제제기가 단순히 건의함에 건의사항을 넣고 잊혀지지는 수준이 아니라 문제 공감과 해결을 위한 노력, 그에 따른 결과가 분명히 문제제기한 당사자에게 피드백되어야 한다. 그렇지 않을 경우 처음 한두번 문제제기를 했다 하더라도 그게 반영되지 않거나 조직내 공감을 얻지 못할 경우 의기소침해지고 더이상 문제제기를 하지 않게 된다. 따라서 문제제기가 가능하도록 시스템으로 지원하여야 하고 문제를 수집하고 그것의 해결을 전담하는 문제해결 직책이 필요하다.
문제제기가 원활히 된다면 변화시도까지는 자연스럽게 이어진다. 하지만, 변화시도에는 카오스가 수반되고 이때 혼란이 발생하며 기존 시스템보다 변화한 새 시스템이 더 비효율적으로 느껴지고, 다시 예전으로 돌아가려는 욕구가 생겨난다. 이때를 잘 극복하지 않으면 더이상 변화시도조차 없어져 버릴 수 있기 때문에 카오스 단계를 어떻게 극복하는가가 가장 중요하다. 카오스 단계에서 가장 중요한 것은 변화가 조직의 성격과 부합하느냐 하는 것이다. 조직의 성격과 부합되지 않는 변화는 아무리 좋은 변화라 하더라도 변화하지 않는게 좋다. 따라서, 무조건 바꿔야 한다는 식이 아닌 취사선택하는 융통성이 필요한 단계이다. 나 개인적으로는 문제제기 - 변화시도 - 카오스까지가 자주 발생하고 아무런 방해요소가 없다면, 시도한 변화가 적용되고 되지 않고는 중요하지 않다고 생각한다. 중요한 것은 지속적인 변화시도이다. 이때는 TDD 에서 얻은 교훈이 유용하게 적용될 수 있다. 즉, 쉽게 달성할 수 있는 작은 변화들을 지속적으로 시도하여서 성공하는 케이스를 만들어감으로써 자신감과 변화에 대한 공감대를 형성시키고 점차점차 지속적인 변화 사이클을 만들어 가야 한다는 것이다.
두번째로 작업 지연은 편리하고 안정적인 제작도구로 극복할 수 있다. 특히 게임 제작은 여러 직군의 개발자들이 협업해야 하는 상황이 빈번히 발생한다. 이때 작업지연이 발생하게 된다. 기획이 있어야 개발이 되고, 원화가 있어야 모델링이 되고 등의 작업간의 선후관계가 존재하기 때문에 앞 단계가 끝나지 않으면 뒷 단계가 시작되지 않는다. 이때는 우선 할 수 있는 것을 해야 하고, 선작업이 없어도 할 수 있는 범위가 클 수록 좋다. 애자일 책에서 흔한 예시로 한 조직이 개발팀을 꾸렸는데, 3개월이 넘어가도록 예산편성이 되지 않아서 서버도 없고 DB 도 없고 해서 3개월간 개발팀이 허송세월을 보내고 있었는데, 우선 할 수 있는 것부터 하면서 결과물을 차차 보여줬더니 예산도 빨리 편성되고 잘 풀리더라 하는 예시를 하곤 한다.
OOP 에서 객체는 응집성이 높아야 하고 결합도가 낮아야 한다고 하는데, 마찬가지로 직군간 업무는 종속성이 낮을 수록 좋고, 이 종속성을 낮게 해주는 장치가 바로 개발 도구이다.
만약 새로운 기획 요소를 적용하는데 코드 수정이 필수적이라고 한다면, 기획자가 기획을 하면 프로그래머가 코딩을 해서 구현을 끝날때까지 기획자는 결과를 알수가 없고 대기하게 된다. 다시 기획자를 결과를 봤지만 자신의 예상과 다르거나 문제점이 있을 경우 다시 구현을 해야 한다.
하지만, 기획자에게 스크립트라는 툴이 있다면 개발자의 구현 과정이 필요없고 자신의 기획한 요소를 바로바로 적용하면서 고칠 수 있을 것이다.

따라서 도구는 매우 중요하고, 착수단계에서부터 도구에 대한 작업을 하지 않으면 나중에 많은 고생을 하게 된다. 처음에 도구가 없이 무작정 시작했다가 나중에 비효율이 너무 커져서 도구를 적용하려고 급하게 도구를 만들다보면 오히려 도구가 비효율을 더 키울 수 있기 때문이다.
도구 제작에 중요한 점이 몇가지 있는데, 편리함, 생산성, 유지보수 이다. 도구는 여러 직군이 사용하기 때문에 편리해야 한다. 흔히 도구는 프로그래머 혼자 별다른 고민없이 급하게 만들다보니 UI 가 형편없는 경우가 많고 이것은 비효율을 증가시키는 요인이 된다. 따라서 도구 제작은 전문 UI 디자이너(그래픽적인 면을 말하는 것이 아니다)가 필요하고 처음부터 협업하며 만들어야 한다. 두번째로 생산성이다. 도구가 빨리 만들어질 수록 게임 개발이 본격 궤도에 오르는 기간이 빨라진다. 따라서 도구의 생산성은 비용과 직결되어 있다고 볼 수 있다. 마지막으로 유지보수이다. 흔히 도구 개발자는 도구 개발이 끝나면 더이상 도구 개발을 담당하지 않고 게임 개발로 투입되는 경우가 대부분이다. 이렇다 보니 버그나 불편한 요소가 있다 하더라도 바로바로 고치지 못하고 계속 남아서 비효율을 증가시키게 된다. 따라서 나는 도구 유지보수를 전담하는 직책이 꼭 필요하다고 생각한다.