여기에서 말하는 prototype은 말 그대로 실제 제품이 아닌, 뒤엎을 것을 생각하고 만드는 제품을 말합니다. 즉, 점진적인 개발과 반대로 개발하는 방식을 말하는데, 저는 이런 방식의 개발에 대해 부정적입니다. 예외적으로, coding이 필요없는 prototype이라면 괜찮을 것 같습니다.
기획자가 만족하는 게임에 대한 느낌만을 얻어내려고 해도, 기본적인 뼈대가 갖춰지지 않고서는 그것조차 전달하기 어렵습니다. 기본적인 뼈대(화면 출력, 입력 처리, 그리고 기본 game logic 등)를 빠른 시간에 만든다는 건 만만치 않습니다. 그리고 'prototype인데 code는 생각하지 말고 대강 만들자'라고 생각하고 prototype을 만들게 되면, 엉망이 돼 가는 code로 인해 prototype조차도 만들기 힘듭니다.
기획자는 단순한 수준의 prototype으로는 만족하지 않습니다. 간단한 동작만 가능한 version을 제공해도 graphic designer에겐 많은 도움이 되지만, 기획자는 그것만으로는 기획 작업에 그다지 도움을 받을 수 없기 때문에 실제로 play해 볼 수 있는 version을 요구하고, 그건 game을 거의 완성하라는 것과 마찬가지가 돼 버립니다. 그렇게 되면 급조한 code로 추가 작업을 하게 되고, 그 code는 어차피 못 쓰고 도움을 받지도 못하므로 개발 기간은 더 길어집니다. 기획적으로는 시간 단축이 일어날지 모르겠지만, programming은 시간이 더 오래 걸리게 되는 것입니다. 실제로 game 개발에 있어서 가장 병목이 심한 부분은 programming인데, 그 부분이 더 길어지면 기획적인 부분에서 시간이 단축된다해도 전체 개발은 길어져 버립니다.
또 prototype을 만들게 되면 그걸 다른 부서에서는 개발이 거의 완료된 것으로 착각하기 때문에, 개발시에 일정의 압박이 있게 됩니다. '전에 그만큼 보여줬는데, 왜 아직도 그대로인가'라고 생각하면서 새 version을 수시로 요구합니다. Programmer로써는 참 고통스러운 일입니다.
저는 그런 면에서 점진적이고 반복적인 개발 방법이 자연스러우며 효과적이라고 생각합니다. 자연스럽게 만들어가는 과정 속에서 할 수 있는 데까지만 시험을 해 나가면, 급조한 후 버리는 code나 data도 줄어들고 기획자도 지속적으로 feedback을 얻을 수 있으므로 좋습니다. 최근의 Extreme Programming같은 Agile 방법론도 그런 경험에서 우러나온 방법론 같습니다.
댓글을 달아 주세요
개발 상황에 따라서 프로토타입식으로 가는 것도 좋고, 때로는 점진적인 개발이 더 좋을 수 있다고 생각합니다.
어느쪽을 선택할 건가는 개발팀의 상황에 따라서 선택하는 것이 제일 좋다고 생각합니다.
점진적인 개발을 할 때는 일단 어떤 게임이 될 것인지 핵심은 무엇인지 확실히 정해진 상태에서 한다면 좋겠지만 그렇지 않다면 점진적인 개발이라는 명분하에서 목표 없이 이리저리 헤매면서 시간을 다 보낼 위험이 있다고 생각합니다.
프로토타입의 경우는 핵심이 뭔지 불명확 할 때는 그것을 빨리 판단하기 위해서는 좋은 방법이 될 수 있지만 이야기 하셨던 문제점에 의해서 개발에 지대한 영향을 영향을 줄수도 있다고 생각합니다.
제가 아는분의 경우는 프로토타입에 의한 개발을 한다는 것을 위에서 확실하게 인지하고 있고, TDD를 병행하여 개발하고 있어 이후 실제 게임 제작으로 포팅을 할 때 빠르게 포팅이 가능할 듯 하더군요.
네... 목표가 불명확할 때엔 prototype 방식도 좋을 듯하네요. 그런데 제 경우엔 당연히 목표가 세워져야 제작을 할 수 있다고 생각했기 때문에, 목표가 명확하지 않은 경우는 생각하지 못했네요.
그런데 prototype은 최대한 빨리 핵심 목표를 확인하는 게 목적이라서, 거기에 쓰인 code는 버린다는 생각으로 가는 게 더 좋지 않나 생각합니다.
대체로 프로토타입은 투자처에 대한 용처로 인해 생겨나는 경우가 비일비재한것을 감안하면 ㅜㅜ
음... 투자 받을 때엔 속은 비었지만 겉보기엔 뭔가 된 듯한 느낌을 주는 prototype 방식이 낫겠네요. 기능 추가보다 완성도를 중시하며 점진적으로 기능을 추가하는 방식은, software 개발에 대해 모르는 투자자에겐 아무래도 통하기 어려울 테니까요.
저도 prototype의 코드는 일단 버린다고 생각한다는게 정석이다고 봅니다. 다만 TDD를 병행하면 prototype 코드 중 쓸만한 것은 리팩토링 후 테스트를 할 수 있기 때문에 쓸 수 있지 않을까 생각합니다.
그리고 목표를 명확하게 세운 후 게임 개발을 만드는게 정말 당연한 이치인데 그렇지 못한 경우가 많은 것 같더군요. 특히 장기 프로젝트의 경우 대부분의 이유가 목표가 명확하지 않은 것인것 같더군요.
제 생각엔 prototype은 실제 제품 개발과 완전히 다른 방식으로 개발해야 좋은 것 같습니다. Test도 건너 뛰고 (즉 되도록이면 TDD도 건너 뛰고), 복사와 붙여넣기의 날림 code로 개발하는 것이지요. 즉, 결과를 위해 과정을 희생하는 것입니다. 그래서 prototype의 code는 버리는 것을 목표로 개발해야 좋다고 봅니다.
그리고... 목표가 명확하지 않은 project도 많을 것 같습니다. 그런데 그쪽은 잘 모르겠네요 ^^