운영팀을 제외하고, Eternal Dream 의 순수 개발팀은 초기 Pizworld 시절부터 회사가 문을 닫아 팀이 해체되기까지 거의 대부분의 기간 동안 4명으로 구성되었습니다. 그 구성을 보면 다음과 같습니다.
- 팀장. 클라이언트/서버 코드 어시스턴트 : ssbyon
- 클라이언트 리더. 게임 룰 및 컨텐츠 기획, 시나리오 전담 : iceemperor (저입니다)
- 서버 리더, 게임 인터페이스 기획 및 운영 기획 : oceank
- 아트 디렉터
- 2002.02 ~ 2003.05 - seolinsis
- 2003.05 ~ 2004.05 - climaxz
- 2004.05 ~ Final - tico
이외에 2003년 클로즈베타 1차 ~ 3차 시기까지 웹 사이트 구성 및 운영팀으로 두 분이 계셨고, 더불어 클라이언트 작업팀으로 한 분이 더 계셨었습니다. 원래 정상적인 진행이 되었다면, 제가 그 분께 클라이언트의 전 작업을 이전하고 기획에만 전념하게 되었을 것입니다만, 클로즈베타 3차 종료 후부터 회사 사정이 악화되기 시작하여, 대부분의 팀원이 정리되고 개발팀의 핵심만 남게 되었습니다.
팀의 각 구성원이 맡은 역할을 보시겠지만, 그래픽 팀을 제외한 3명이 모두 겸직을 하고 있음을 알 수 있습니다. 특히 저와 oceank 님의 경우는 아주 명확하게 2가지의 작업을 맡고 있었습니다. 바로 기획 작업이죠. 이렇게 기획이 분리되어 있지 않았던 만큼, 기획 부분에서 굉장한 인력 부족의 압박을 받고 있었습니다. 두 가지 작업을 동시에 시행해야 하는 만큼 두 작업에 대해서 균형있게 시간을 분배해 주어야만 하지만, 사실 그것은 결코 쉬운 일이 아닐 뿐더러, 프로그램에서 시시각각 터지는 복잡한 버그들은 자동적으로 프로그래밍 업무에 비중을 저절로 두게 되는 결과를 가지고 오게 되었습니다.
프로그래밍 업무에 비중을 둘 수밖에 없었던 것은 어떻게 보면 당연한 결과였습니다. 프로그램에서 쏟아져 나오는 버그는 당장 수정하지 않으면 문제가 되는 것들이고, 이를 뒤집어서 말하면 작업을 하는 만큼 바로 결과가 튀어나온다는 것이었습니다. 기획의 경우 프로그램처럼 명확한 해법을 찾기가 매우 어렵고, 설사 어떤 해법이 나왔다고 하더라도 그것이 정말로 효과를 발휘하는지에 대해서는 프로그래밍의 결과처럼 명확히 판단하기가 어렵습니다. 따라서 당연히 작업은 사용자들에게 쉽게 눈에 띌 수 있는 전자쪽으로 치우치게 되는 것이죠.
물론 이러한 두 가지 작업을 동시 수행하는 경우 적지 않은 상황에서 두 사람이 하는 것에 비해 한 사람당 효율이 증가되는 면이 있어서 실제로는 작업 부담이 2배가 되지는 않습니다. 원래 특정 작업에 대해서 2사람이 수행할 경우 1사람이 수행하는 것에 비해 200%의 능력이 발휘되어야 하지만 의사소통으로부터 나타나는 문제로 발생하는 코스트로 인해 실제 효율은 200%가 되지 못합니다. 이를 뒤집어 말하면 원래 두 사람이 해야 할 작업을 한 사람이 할 경우, 두 사람의 의사 소통으로 인해 발생하는 코스트를 소멸시켜 1사람 당으로 평가할 경우 작업 효율이 증대되는 결과를 가져올 수 있다는 것이 됩니다.
다만 이러한 효과는, 그 사람이 두 작업을 동시에 수행함으로써 두 작업 사이의 의사소통과정을 소멸시킬 수 있다는 가정 하에서 나타납니다. 만약 두 작업이 애당초 의사소통 과정이 없었거나, 동시에 수행한다고 하더라도 의사소통의 필요성이 줄어들지 않는다면 이러한 효율 증대 효과를 전혀 기대할 수 없게 됩니다. 문제는 Eternal Dream의 역할 분담이 바로 이런 구성을 가졌다는 것입니다.
자 그럼, Eternal Dream 의 팀 구성을 다시 살펴보도록 하죠.
제가 프로그램에서는 클라이언트 총책을 담당하고 있으며, 기획에서는 게임의 룰과 시나리오를 담당하고 있습니다.
oceank 님은 프로그램에서는 서버 총책을 담당하고 있으며, 기획에서는 인터페이스 (여기서는GUI 겠지요) 와 게임 운영시스템을 담당하고 있습니다.
게임 룰이 프로그래밍과 직결되는 것은 서버 프로그램입니다. 반대로 GUI 기획과 직결되는 것은 클라이언트 프로그램이죠. 그런데 지금 보시면 그 구성이 완전히 뒤집어진 것을 볼 수 있습니다. 따라서 결과적으로 이 구성은 한 사람이 두 작업을 동시에 할 때 가지는 메리트를 전혀 살리지 못한 형태이며, 이 떄문에 각 팀원은 개인당 2배의 작업을 고스란히 짊어지게 되었습니다.
이렇게 된 이유는 각 구성원의 프로그래밍 전문 분야가 판이하게 달랐기 때문입니다. 팀 구성 시 제가 경험이 있었던 분야는 이미지 처리와 시스템 UI 이벤트 처리였고, oceank 님은 DB에 전문적인 지식을 가지고 있었습니다. (당시 이 분은 MS와 SUN, ORACLE 의 각종 자격증은 다 가지고 있었습니다.) 만약 어느 정도 여유가 있었다면, 팀원 구성이 확정되었을 경우 서로 자신의 지식을 전달해 주면서 프로그래밍 역할을 바꿀 수도 있었겠습니다만, 아쉽게도 팀은 구성되자마자 바로 실무에 투입되었고, 그나마도 게임 제작 중에는 역할이 정해지지 않은 채로 무려 반년 이상동안 프로젝트를 진행했기 때문에, 이러한 구성이 인력 부족 상황에서 전혀 보탬이 되지 않는다는 것을 파악했을 때에는 이미 돌이키기에는 너무 비용이 많이 들게 되는 상황이었습니다.
의사소통 문제는 매우 중요합니다. 아무리 기획 문서를 정확하게 만들고 기록으로 남겨 놓아도 분명히 어딘가 설명이 빠진 곳이 존재하고, 당연히 그렇게 비는 공간은 그 문서를 읽는 사람의 경험을 바탕으로 재구성됩니다. 그것이 원래 기획 문서를 만든 사람의 의도와 동일하다면 좋겠지만, 대부분의 경우 차이가 나게 되며, 이를 파악하고 재조정을 하는 데에 시간과 비용이 소모됩니다. 더불어 작업을 하면서 애당초 기획 자체가 틀렸거나, 기획대로 구성할 수 없는 경우에 다시 기획자와 재조정작업을 거쳐야만 하는데 여기서도 다시 시간과 비용이 소모됩니다.
만약 이를 한 사람이 수행할 경우, 원래 기획과 결과물을 동일하게 작성할 수 있는 것은 물론이고, 기획의 오류를 파악하고 바로잡는 데에 시간차가 발생하지 않기 때문에 굉장히 빠른 속도로 기획을 재구성하고 프로그램을 재조정할 수 있습니다. 그래서 특히 경험이 없는 팀의 경우 오히려 한 사람이 두 작업을 수행하는 것이 더 빠른 경우도 있습니다. 만약 Eternal Dream 이 이런 구성을 가졌다고 한다면, 원래보다 훨씬 빠르게 작업을 진행할 수 있었을지도 모르겠습니다. 저의 경우 서버에 룰의 동작원리를 정확히 반영하고 한편으로 룰의 오류를 쉽게 잡아낼 수 있었을 것이고, oceank 님은 GUI 상의 불편함과 문제를 파악하는 즉시 수정할 수 있었겠지요.
