게임 개발에서 일회용 프로토타입 제작에 대한 생각

이 글에서 말하는 프로토타입은 뒤엎을 것을 생각하고 만드는 제품을 말하는데, 저는 이런 프로토타입에 대해 부정적으로 봅니다. 예외적으로, 코딩이 별로 필요없는 프로토타입이라면 괜찮을 것 같습니다.

게임에 대한 추상적인 느낌만을 얻어 내려고 해도 뼈대가 갖춰지지 않고서는 그것조차 얻기 어렵습니다. 뼈대엔 화면 출력, 입력 처리, 그리고 기본 게임플레이 로직 등이 포함되는데, 뼈대를 빠른 시간에 만든다는 건 만만치 않습니다. 또, ‘프로토타입인데 유지 보수는 생각하지 말고, 대강 만들자’라고 생각하고 프로토타입을 만들게 되면, 엉망이 돼 가는 작업물로 인해 프로토타입조차도 만들기 어렵습니다.

기획자는 단순한 수준의 프로토타입으로는 만족하지 않습니다. 간단한 동작만 가능한 버젼을 제공해도 그래픽 아티스트에겐 많은 도움이 되지만, 기획자는 그것만으로는 기획 작업에 그다지 도움을 받을 수 없습니다. 그래서 기획자는 실제로 플레이해 볼 수 있는 버젼을 요구하고, 그건 게임을 거의 완성하라는 것과 마찬가지가 돼 버립니다. 그러면 급조한 소스 코드로 추가 작업을 하게 되고, 실제 제품을 개발할 때 그 소스 코드에서는 도움을 별로 얻지 못하므로, 개발 기간은 더 길어집니다. 기획적으로는 시간 단축이 일어날지 모르겠지만, 프로그래밍은 시간이 더 오래 걸리게 되는 것입니다. 실제로 게임 개발에 있어서 병목이 제일 심한 부분은 프로그래밍인데, 그 부분이 더 길어지면 기획적인 부분에서 시간이 단축된다고 해도 전체 개발은 길어져 버립니다.

또, 프로토타입을 만들게 되면 다른 부서에서는 개발이 거의 완료된 것으로 착각하기 때문에, 개발 시에 일정의 압박이 있게 됩니다. 다른 부서는 ‘왜 아직도 그대로인가?’라고 생각하면서, 새 버젼을 수시로 요구합니다. 프로그래머로써는 참 고통스러운 일입니다.

저는 이런 점을 볼 때, 점진적이고 반복적인 개발 방법이 자연스러우며 효과적이라고 생각합니다. 자연스럽게 만들어 가는 과정 속에서 할 수 있는 데까지만 시험을 해 나가면 급조한 후 버리는 작업물도 줄어들고 기획자도 지속적으로 피드백을 얻을 수 있으므로 좋습니다. 익스트림 프로그래밍(Extreme Programming)과 스크럼(Scrum) 같은 애자일 방법론도 그런 경험에서 우러나온 방법론 같습니다.

그런데 소프트웨어 개발을 잘 모르는 사람에게 투자를 받을 때엔 속은 비었지만 겉보기엔 뭔가 된 듯한 느낌을 주는 프로토타입 방식이 나을 수도 있습니다. 기능 추가보다 완성도를 중시하며 점진적으로 기능을 추가하는 방식은 소프트웨어 개발에 대해 모르는 투자자에겐 아무래도 통하기 어려울 테니까요.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중