제가 게임개발 교육기관에서 시스템 기획 강의를 할 때, 학생들이 가장 이해하기 힘들어 하던 부분은 바로 추상화(abstraction)였습니다. 물론 초급 경력자들 중에도 추상화를 개념적으로만 이해하지 실무적으로 제대로 활용하는 사람은 그리 많지 않을 것입니다. 아무래도 직접 코드를 짜면서 만들어보지 않고서는 정확하게 이해하기가 어려운 개념이기도 하고, 또 개념적으로는 이해하더라도 실전에서 잘 활용하려면 그만큼 훈련과 경험이 필요한 것이 바로 추상화일 것입니다.
보통 객체지향을 설명하는 책에서는 추상화를 이렇게 설명합니다. 닭이 최하위 개념이면, 그보다 추상화된 상위 개념으로 조류, 그 윗단계로 동물, 그 다음은 생물... 혹은 한국인 -> 동양인 -> 인간... 뭐 이런식이죠. 이런 설명을 들으면, "아, 추상화란 것은 뭔가 구체적인 개념에서 추상적인(포괄적인) 범주로 올라가는 거로구나..."라고 개념적으로는 이해할 수 있습니다. 하지만 프로그래머로서 공부를 더 깊이 있게 하고 코드를 실습하지 않는 한, 대개는 거기까지만 이해하고 끝납니다. 쉽게 말하면, 뭔가 알아 먹긴 했는데 써먹지는 못하는 그런 상태에서 그치는 거죠.
그래서 이런 기획자에게 무기 아이템을 기획하라고 하면 보통은 이렇게 됩니다:
"무기에는 한손 무기, 양손 무기가 있고, 한손 무기 중에는 단검, 도검, 한손 도끼, 망치... 양손 무기에는 양손 검, 양손 도끼... 어? 활이나 석궁은 어디에 분류하지? 근접무기, 원거리 무기로 나누어야 하나? 어 이거 어떻게 하지? 안돼~에! 사람 불러야 돼~!!!"
대부분의 경우, 프로그래밍을 모르는 기획자에게 객체지향에 대해서 가르치면, 클래스, 인스턴스, 상속 같은 주요 개념들은 이해를 합니다. 하지만 실전에서 그것을 써먹지 못하는 이유는 (제가 판단하기에) '가상함수와 다형성'을 모르기 때문이라고 생각합니다. 이거야 말로 직접 코드를 만져보지 않으면 제대로 이해하기 어려운 개념이지요.
이글이 프로그래머를 위한 아니기 때문에 아주 쉽게 설명하자면, 가상함수란, 어떤 명령을 내리는데 구체적으로 뭘 할지는 명령을 받는 놈에 따라서 다르게 들어가는 것입니다.
일단 예를 들어봅시다. 스타크래프트에서 각 유닛들은 이동방식이 다릅니다. 질럿이나 마린 같이 지면에서 걸어다니는 유닛이 있는 반면에, 레이쓰나 캐리어 같이 공중에서 날아다니는 비행유닛도 있습니다. 하지만 플레이어들이 이 유닛들에게 너는 걸어서 이동하고 너는 날아서 이동해라! 라고 유닛별로 다른 이동명령을 내리지는 않죠? 플레이어는 단지 Move 나 Patrol 같은 명령만 내릴 뿐이고, 각각 어떤 방식으로 이동할지는 유닛이 알아서 합니다.
이런 것이 가능한 이유는 객체지향 프로그래밍 언어에서는 상위 클래스에서 가상함수로 선언한 (추상화된) 기능을 그 하위 클래스들마다 다르게 재정의(Override)해서 받아들일 수 있기 때문입니다. 그렇기 때문에 Move라는 동일한 명령을 내려도 어떤 놈은 걸어서 가고 어떤 놈은 날아서 갈 수 있는 것이죠.
이와 같이, 추상화를 제대로 이해하려면 가상함수와 재정의를 이용한 객체지향의 특성인 다형성(Polymorphism)을 이해해야 합니다. 대부분의 경우 추상화란 각각의 최하위 객체(인스턴스)들이 갖게될 요소들 중에서 공통적인 부분을 찾아내서 그것을 상위 클래스로 올리는 작업인데, 다형성을 이해하지 못하고서 '공통성'을 제대로 찾아낼 수 없기 때문입니다.
객체지향을 설명하는 책을 보면, 객체지향적으로 설계된 프로그램에서는 객체와 객체 사이에 메세지를 주고받으며 동작한다고 말합니다. 위에서 예를 든 바대로 설명하자면 Player 객체가 Unit 객체에게 Move라는 메세지를 주면 Unit이 이동하는 것이죠. 그리고 다형성이란, 각각의 Unit들의 속성에 각자 고유한 이동방식이 설정되어 있어서, Player가 Move라는 가상함수 메세지를 각 Unit들에게 보내면, 각 Unit들은 자신이 가진 이동방식에 따라 Walking 방식으로 이동하기도 하고 Flying으로 이동하기도 하는 것입니다. - 만약 확장팩이 나와서 잠수항행이라든지, 물위에서 떠다니는 호버크래프팅 같은 새로운 이동방식이 추가된다 하더라도 Player는 단지 Move라는 명령만 내리면 됩니다. 한 마디로 유연성, 확장성을 갖는 프로그램이 되는 것이죠.
블로그 포스팅에서 무한정 설명을 할 수는 없는 노릇이니, 더 자세한 부분은 객체지향의 개념을 잘 설명한 책이나 문헌을 참고하시기 바랍니다. 다음에 이어질 포스팅에서는 실제 시스템 기획에서 제대로 된 추상화를 하기 위한 보다 실무적이고 구체적인 예시를 써볼까 합니다.
to be continued...
[주의] 본 필자는 전문 프로그래머가 아니므로 포스팅 내용 중에 사소한(!) 오류가 있을 가능성을 부인하지 않습니다.
반응형
'기획' 카테고리의 다른 글
온라인게임 퀘스트 보여주기 (10) | 2012.01.13 |
---|---|
적절한 시스템 기획을 위한 추상화 이야기 (2) (22) | 2012.01.03 |
게임 플레이 플로우 테스트 (12) | 2011.12.30 |
기획서는 어떻게 써야 할 까? (34) | 2011.12.26 |
온라인 게임 개발 "무어의 법칙" (24) | 2011.12.22 |