적절한 시스템 기획을 위한 추상화 이야기 (2)

// 원래는 1월 12일에 포스팅해야 하는데 퐆프님께 허락받고 스케쥴보다 일찍 올립니다. 기획 카테고리엔 글이 너무 적어요 ;ㅅ;

전편에서는 스타크래프트 유닛의 이동을 예로 들면서 재정의(Override)를 이용한 다형성(Polymorphism)에 대해서 간단하게 설명해보았습니다. 하지만 아마도 C++, JAVA 등과 같은 객체지향적 프로그래밍 언어를 전혀 공부해본적이 없는 사람이라면 아직 뭐가 뭔지 제대로 이해하기는 어려울 겁니다. 하지만 너무 낙심할 필요는 없습니다. 현업 프로그래머라도 경험과 시행착오가 쌓이지 않으면 제대로 활용하지 못하는 것이 바로 이 개념이니까요.

그런데, 두 번째 포스팅을 이어가기 전에 한 가지 짚고 넘어갈 점이 있습니다. 기획자가 왜 프로그래머의 영역인 객체지향이나 추상화를 알아야 하는가하는 '논란'입니다.

흔히 기획자가 프로그래밍을 공부하는 경우의 단점으로 '창의성 저하'를 많이 언급합니다. 프로그래밍을 공부한 기획자는 어떤 아이디어를 떠올릴 때 구현여부를 먼저 고민하기 때문이라는 이유죠. 물론 그런 기획자도 있을 수 있겠지만, 어설프게 프로그래밍을 공부했다고 해서 어떤 아이디어가 기술적으로 구현할 수 있는지를 정확하게 판단하는 것 자체가 불가능한 일입니다. 그리고 게임 개발에 있어서 '이 아이디어는 구현할 수 없다'는 판정을 받는 경우는, 그것이 기술적으로 불가능하다기보다는 개발의 효율성이나 최적화의 관점에서 포기하는 경우가 대부분입니다. (또는 기획서가 무슨 말을 하는 건지 이해하기 어렵거나, 만들기 귀찮아서일 수도 있음)

즉 구현이 불가능한 것은 아니지만, 프로젝트의 목적에 부합하지 않거나, 혹은 개발기간이나 비용, 엔진성능 또는 유저 시스템 요구사양의 한계 때문에 포기하는 것이죠. 어떤 아이디어의 기술적인 구현여부나 방법을 최종적으로 결정하거나 판단하는 것은 기획자가 아니라 테크니컬 디렉터(TD) 정도의 실력과 짬밥이 쌓여야 가능한 일입니다.

이러라고 프로그래밍 공부하라는 소리는 아닙니다

그렇다면 게임 기획자, 그 중에서도 시스템 기획자는 왜 프로그래밍을 공부하고 객체지향이나 추상화의 개념을 알아야 할까요? 그것은 기획자가 어떤 아이디어의 구현 여부를 1차적으로 판단하기 위한 것이 아니라, 자신의 기획 아이디어를 프로그래머들에게 정확하게 전달하고 소통하기 위함입니다. 기획자 혼자서 게임을 완성시킬 수 있는 툴을 쓰지 않는 한, 여러분의 아이디어는 대부분 프로그래머를 통해 실체화됩니다. 그렇기 때문에 프로그래머가 이해하기 좋은 표현을 통해 아이디어를 전달하면 기획의도대로 더욱 정확하게 구현할 수 있고 더 효율적인 개발을 할 수 있게 됩니다.

그러면 이번에는 좀 더 실무적인 추상화의 예를 들어보겠습니다.

제가 게임기획 강의를 할 때, 수강생들에게 WoW 마법사의 스킬을 분류해보라고 하면 보통은 분류방법이 두 가지로 나뉩니다.

(1) 화염, 냉기, 비전

(2) 캐스팅(주문의 시전 시간이 필요한 스킬), 즉시시전, 광역마법...

1번 같은 분류는 일반적인 유저의 입장, 즉 그냥 게임에서 보여주는대로 분류하는 개념이죠. 콘텐츠 기획서라면 모를까 시스템 기획서에서는 적합하지 않은 분류입니다. 반면에 2번과 같은 분류는 1번보다는 조금 낫지만, 아직도 좀 부족하죠. 하지만 여전히 많은 시스템 기획자들이 2번 정도의 수준으로 기획을 합니다.

그런데 문제는 2번 같은식으로 스킬의 명세를 기획서로 써서 프로그래머에게 전달하면, 구현하는 것 자체는 가능하지만 확장성이나 유연성이 떨어지는 결과물이 나온다는 점이 문제입니다. (프로그래머의 입장에서는 코드의 중복, 유지보수성의 문제도 발생함)

구체적인 예를 들어보죠. WoW를 접은지 꽤 오래되서 정확한 스킬 명칭은 기억나지 않지만, 흑마법사의 마법 중에는 처음엔 시전시간이 2.5초지만, 해당 스킬의 시전 시간을 줄여주는 특성을 찍으면 0.5초씩 시전 시간이 감소해서 5포인트의 특성을 투자하면, 즉시시전 스킬로 바뀌는 경우가 있습니다. 만약 2번과 같은식의 분류에 기초한 스킬 시스템 기획서를 그대로 구현했다면, 이와 같은 예외적인 스킬은 코드를 갈아 엎거나, 아니면 이런 예외적인 스킬을 구현하기 위한 별도의 코드를 새로 작성해야만 합니다.

게다가 시전시간이 필요하면서도 광역마법인 경우라든지, '화염구'와 같이 특정 대상을 향해 발사체를 시전하는 캐스팅 스킬이지만, 발사체가 대상에 명중한 후에 광역효과가 발생하는 스킬 같은 경우 등 기존의 설계와 다른 예외 상황이 조금만 발생해도 코드를 갈아엎거나 아예 별도로 작성해야 하는 엄청난 비효율이 발생할 것입니다. 게다가 이런 비효율만 발생하고 끝나는 것이 아니라, 계속된 예외상황의 추가에 따른 고질적인 버그도 함께 따라다닐 겁니다.

따라서 시스템 기획 단계에서부터 객체지향적 설계방식을 숙지하고 있는 기획자가 기획 아이디어를 1차적으로 추상화하거나 혹은 추상화의 단서를 제공하여 프로그래머와 함께 조율을 하는 것이 서로에게도 좋고 개발 프로세스 전체에 있어서도 바람직하다는 것이 필자가 이 포스팅을 통해 전하고 싶은 핵심입니다.

그러면 추상화는 대체 어떻게 해야 할까요? WoW의 스킬을 예로 들자면, 화염구, 얼음 회오리, 돌진, 방패막기, 각종 버프 등과 같은 각각의 스킬은 구체화된 객체(object)라고 할 수 있습니다. 객체지향 프로그래밍에서는 이렇게 구체화된 최종 결과물을 인스턴스(instance)라고 부르죠. 여러분들이 만약 스킬 시스템을 기획한다면, 초기 기획단계에서 구상한 스킬 목록을 바탕으로 공통점을 추려내서 비슷한 것끼리 분류하는 작업이 바로 추상화입니다.

그런데 문제는, 객체지향에서 말하는 추상화를 제대로 이해하지 못한 상태에서 공통점을 추려내면, 바로 위에서 말한 1번이나 2번과 같은 분류 정도 밖에는 할 수 없다는 사실입니다. 그렇다면 객체지향을 공부하고 C++ 같은 언어를 좀 만져봐야만 하느냐? 물론 공부를 하는 것이 좋습니다. 적어도 여러분이 시스템 기획자로 성장하기를 원한다면, 최소한 C++ 책 한 권 쯤은 독파하시기를 권합니다. 저는 오래 전에 객체지향적인 프로그래밍 언어를 공부하지 않은 상태에서 이론적으로만 객체지향을 공부한 적이 있었는데, 확실히 직접 코드를 만지면서 공부하는 것보다 훨씬 이해하기 힘들었습니다. 하지만 이런저런 이유로 아직 프로그래밍을 공부할 상황이 안 되거나 공부해도 잘 이해하기 어렵다면, 일단은 워크래프트3 에디터 같은 좋은 에디터 툴을 다뤄보면 아주 큰 도움이 됩니다.

워3 에디터의 경우, 툴의 오브젝트 에디터에 워3에서 기본적으로 제공하는 유닛과 스킬, 기타 오브젝트들에 대한 데이터를 볼 수 있습니다. 그런데 이것들을 잘 살펴보면, 그 다른 건 전혀 건드리지 않고 단지 데이터만 수정해서 새로운 유닛이 되거나 새로운 스킬이 만들어질 수 있습니다.

예를 들어 화염구와 같은 스킬은 이름을 냉기화살로, 데미지 속성값을 냉기타입으로, 발사체 모델링을 얼음덩어리로 수정하면 화염구가 아닌 냉기화살이 돼죠. 워터엘레멘탈 소환 스킬은 소환물 데이터를 드래곤으로 바꾸면 드래곤 소환스킬로 변합니다. 이런 일들이 가능한 이유는 처음 시스템을 설계할 때부터 확장성과 유연성을 가질 수 있도록 철저한 추상화를 거쳤기 때문입니다. 그리고 이와 같이 데이터(값)만 바꿔서 구현할 수 있는 것은 하나의 공통성을 가지고 있다고 할 수 있으며, '개발(구현)의 관점'에서 본다면 하나의 객체로 간주할 수 있습니다.

그럼 다음 포스팅에서는 추상화에 대해서 보다 깊이 있게 들어가 봅시다. 다음 포스팅이 올라올 때까지 여러분이 즐기는 게임에서 특정 시스템을 놓고 데이터만 다르고 나머지는 같은 공통성을 가진 객체들을 분류하는 연습을 한 번 해보시길 바랍니다.

to be continued...