[스크랩] 시스템기획 : 추상화를 못하면 망한다.

 

 

출처 : http://www.imagian.net/board_essay/detail.asp?serial=260 (추상화랑 관련이 있는지도 없는지도 모르겠다.)

 

 

시스템기획 관련한 이야기가 나오면 바늘과 실처럼 연동되는 이야기가 있다. 바로 "추상화" 이다. 사실 나는 기획자가 아니기 때문에, "시스템기획" 에 대해서 잘 모른다, 그리고 "추상화" 에 대해서도 잘 모른다. 내가 알고있는 부분은 프로그래머의 입장에서 기획에서 요구하는 각종 기능들이 제대로 "추상화" 가 안되어서 개발기간에 딜레이를 걸어서 망한사례 정도이다.

 

시스템기획과 추상화에 대해서 알고 싶다면 다음 자료를 읽어보기 바란다.

 

http://gamedevforever.com/30

http://sstorm.egloos.com/5590409

 

추상화 관련해서 이야기를 하면 "재정의" "다형성" "인터페이스" 이런저런 이야기가 나오지만, 시스템기획에 대한 강좌를 구구절절 하는것보다 차라리 "실패사례" 를 언급해서, "이런식으로 시스템기획 하면 망한다" 를 보여주는것이 훨씬더 좋을것이라고 생각된다.

 

1, NPC 대사창에 사운드 기능 넣기

경고 : 이런식으로 작업하지 말것 (프로젝트 망하기 딱 좋음)

 

기획자 : 이번에 들어가는 NPC 대사가 있는데, NPC 대사 중간에 "따르릉" 하는 소리가 출력되는 기능이 있었으면 하는데?

프로그래머 : 그러면 "따르릉" 소리가 나오는 기능을 추가하면 되겠군.

 

기획자 : NPC 대사를 바꾸었는데, "따르릉" 소리가 안어울려서, "꼬끼오~" 소리가 출력되는 기능이 있었으면 하는데?

프로그래머 : 조금만 기다려, 기능좀 추가해보고.

 

기획자 : 사운드는 괜찮은데, 유저 캐릭터 성별에 따라서 다른 사운드가 출력하는 기능도 있었으면 하는데,

프로그래머 : 그러면 또 기능추가 해야 하겠군..

 

기획자 : 유저 캐릭터 레벨별로 NPC 랑 대화할때 다른 사운드가 나와야 하는데

프로그래머 : 또 기능추가 해야하겠군....

 

- 이런식으로 무한반복, 맨날 코드를 뜯어 고치지만 한도 끝도 없다 -

 

시스템기획과 추상화에 대해서 잘 아는사람은 무엇이 잘못되었는지 쉽게 파악할것이다. 애초에 "어떤기능" 을 요구할때, 즉흥적으로 기능을 툭툭 집어넣은것이 실수이다. 기획자가 NPC 대화와 사운드 출력에 대해서 이런저런 요구를 해왔지만 공통점을 요약하면 다음과 같다.

 

1, 유저 캐릭터의 신상정보를 확인할수 있는 기능이 있어야 한다.

2, 다양한 사운드 출력이 가능해야 한다.

 

제대로된 기획자와 프로그래머의 대화를 다시 작성해 보겠다.

경고 : 이런식으로 작업할것(다만 기획자가 Lua 스크립트가 가능해야함).

기획자 : NPC 랑 대화하는 기능은 있는데, 하필 사운드를 출력하는 기능이 없어서말인데, "GameData\NpcSound" 경로에 사운드를 저장하고, NPC 대화에 쓸수 있도록 하고, NPC 대사가 뜰때마다 유저 캐릭터 정보를 Lua 스크립트로 넘겨서, Lua 스크립트에서 조건검사해서, 원하는 사운드를 출력하도록 하는 기능을 추가했으면 하는데, 어떻게 작업하면 좋을까?

 

프로그래머 : 그러면 Lua 스크립트로 onNPC_Talk() 메소드 추가로 만들고, 첫번째 파라미터를 캐릭터 구조체로 넣어줄께.

 

기획자 : 좋았어~

 

- 그 이후 프로그래머는, 컨텐츠 코드에 손을 대지 않았지만, 알아서 컨텐츠가 잘 나왔다. -

 

(추상화를 제대로 하면 하나의 기능으로 모든 컨텐츠를 제압한다.)

 

 사실 "추상화" 라고 말은 어려운 말을 붙여놨지만, 실질적으로는 "기능의 일반화" 가 더 쉽고 적절한 표현이다. 쉽게 생각해서 프로그래머가 "따르릉" 하는 사운드를 출력하는 기능을 넣어주면 그 기능은 그저 "따르릉" 하는 소리밖에 내지 못하지만, 기획자가 "파일이름" 을 입력하게 해주면 마음에 드는 사운드를 맘대로 쓸수 있다.

 

 극명한 사례를 들어서 말하자면, 유저 캐릭터가 남자 캐릭터일때, 이런 사운드를 출력하도록 하는 기능을 넣었다고 하자, 기능을 넣은것까지는 상관없다. 하지만 갑작스럽게 "궁수남자캐릭터" 일때 이런사운드를 출력하게 해달라고 하면 또다시 컨텐츠코드를 고쳐야 한다. 백번 양보해서 프로그래머가 기능 추가해줬다고 한들, "여자힐러캐릭터" 가 대화할때는 이런대사 넣어달라고 하면 말짱 꽝이다. 하지만 Lua 스크립트로 빼놓은다음에, 캐릭터정보를 모두 넘겨주면 기획자가 알아서 지지고 볶고 맘대로 할수 있다.

 

 시스템기획이 무엇인지, "추상화" 가 무엇인지가 중요한게 아니다. 가장 중요한건, 프로그래머와 기획자의 의사소통을 최대한 억제하면서 최대한의 컨텐츠를 만들어 내는것이다. 최소기능으로 최대한의 컨텐츠를 만들기 위해서는 개별 기능이 최대한 "범용성" 을 가지고 있어야 하는데, 그렇게 하기 위해서는 기획자가 구상한 이런저런 기능들이 최대한 "추상화" 가 되어 있어야 한다.

 

 

2, NPC 대사 연출 스크립트 사례.

경고 : 이런식으로 작업하지 말것.

 

기획자 : NPC 대사창에 "페이드인" 기능이 있었으면 하는데?

프로그래머 : 그러면 넣어줄께.

- 1시간뒤 -

기획자 : "페이드아웃" 기능이 없어서 그런데, "페이드 아웃" 도 넣어줘

프로그래머 : 추가해줄께.

 

기획자 : 화면이 깜박깜박 하는 기능도 있으면 하는데?

프로그래머 : 추가해줄께.

 

기획자 : 화면이 회색톤으로 3~4초간 지속했으면 하는 기능이 있었으면 하는데?

프로그래머 : 추가해줄께.

 

기획자 : 만화책에서 특정부분 강조하는 효과같은게 있었으면 하는데?

프로그래머 : 추가해줄께.

 

여기서 무엇이 잘못되었을까? 사실 잘 생각해보자, "페이드 아웃" 이니 "페이드인" 이니 "회색화면으로 덮기" 이니 "특정부분강조" 이니 결국 공통점은 "그림파일을 화면에 덮는다는 점이다." 그리고 "시간에 따른 알파값" 조절 정도이다. "페이드인" 의 경우 하얀색그림으로 화면을 덮은뒤에, 알파값을 낮추는 개념이고, "페이드아웃" 의 경우 반대로 시간이 지날수록 알파값을 높이는 개념이다. "화면을 깜박깜박" 역시 짧은시간에 하얀그림의 알파값을 0 으로 했다 1로 했다를 반복하는 개념이다.

 

 그렇다면 기획자와 프로그래머의 제대로된 대화는 어떤식일까? 제대로된 대화는 다음과 같다.

 

기획자 : NPC 대사 테이블에 그림파일을 지정해서 출력하는 기능이랑, 시간에 따라서 알파값을 조정하는 기능이 있었으면 하는데

 

프로그래머 : 엑셀테이블에 SHOW_PNG 넣고 그 다음셀에 파일이름 넣고, 그 다음셀에는 (시간:알파값),(시간:알파값),(시간:알파값) 이런식으로 넣으면 되.

 

기획자 : 좋았어~

 

- 기획자는 페이드인, 페이드아웃, 블링크, 등등 수많은 효과를 알아서 넣었다 -

 

두가지 사례만 봐도, "시스템기획" 에서 말하는 "추상화" 가 뭘 의미하는지 알수 있을것이다. "추상화" 는 사실 "기능의 일반화" 이며 또한 "기능의 범용화" 이다. 프로그래머의 손을 빌리지 않고도 최대한의 컨텐츠를 뽑아내도록 범용성을 확보하는 작업이라고 할수 있다.

 

 똑같은 기능을 추가하는데, 어떤 개발팀은 허구헌날 프로그래밍팀과 기능회의 하고 일정조율하고, 이리저리 뜯어고치고, 버그에 시달리고 난리가 나는데 어떤 개발팀은 그저 기획팀에서 알아서 만지작 거리더니, 컨텐츠가 뚝딱뚝딱 하고 나온다. 무슨 차이일까? 바로 "추상화" 의 차이이다. "추상화" 는 별거 아닌것처럼 보이지만, "게임회사에서 월급이 밀리냐? 마느냐? 를 결정하는 핵심 요인중 하나이다."

 

 

3, 추상화랑 밸런싱이랑 뭔 상관인데?

 

 시스템기획과 "추상화"  와 "밸런싱" 과 밀접한 연관이 있다면 사실 몇몇 기획자는 고개를 갸우뚱 할것이다. "밸런싱" 하고 "추상화" 가 뭔 상관인가? 할것이다. 하지만 나의 대답은 다음과 같다.

 

"추상화" 와 "밸런싱" 은 밀접한 관계가 있다. 더 나아가 월급이 밀리느냐? 마느냐? 역시 "추상화" 와 밀접한 연관이 있다.

 

 내 주변 프로그래머와 대화를 하던중 서로 말이 안통하던적이 있었다. 사례는 다음과 같다.

 

프로그래머1 : 이번에 기획자가 밸런싱 다시 한답시고, 힘,민첩,활력,행운 이런 스탯이랑, 패시브 스킬이랑, 아이템스펙 공식을 몽땅 고쳤는데, 아주 미칠것 같아, 그것때문에 맨날 야근하고, 디버깅하고 죽겠다.

 

프로그래머2 : 음.. 기획내용을 고치는데, 왜 늬가 야근인데? 기획자가 야근해야지.

 

프로그래머1 : 기획이 몽땅 바뀌어서, 코드를 고치는데 어떻게 야근을 안하나?

 

프로그래머2 : 이상하네, 그거 엑셀이랑 스크립트로 되는거 아닌가?

 

프로그래머들끼리 서로 왜 대화가 엇갈렸을까? 바로 "추상화" 때문이다. 프로그래머1 은 컨텐츠 구현이 "추상화" 가 잘못된 상황에서 일을 하는 중이고, 프로그래머2 는 "추상화" 가 잘된 상황에서 일을하는 중이다. "추상화" 가 잘 되어 있을경우 기획자가 컨텐츠를 이리저리 지지고 볶던 프로그래머가 개입할일이 없다. 하지만 "추상화" 가 엉망일경우, 기획사항이 변경될때마다, 이랬다 저랬다 맨날 컨텐츠 코드를 이리저리 바꿔줘야 한다.

 

(추상화를 못해서 밸런싱 망하고, 월급이 밀리는 루트)

 

(추상화를 잘해서, 밸런싱도 흥하고, 월급도 안밀리는 루트)

 

 

 "추상화" 와 밸런싱이 밀접한 관련이 있는이유가 바로 이런 특성때문이다. "밸런싱" 을 제대로 하려면 하루에도 수십번씩 이리저리 숫자도 바꿔보고 공식도 바꿔보고, 동작특성도 바꿔보고 그래야 하는데, 그럴때마다 컨텐츠 프로그래머가 맨날 컨텐츠 코드를 고쳐줘야 한다면? 밸런싱은 고사하고 프로그래머 화병나서 쓰러진다. "밸런싱" 을 하기 이전에 "적절한 추상화" 가 필수인 이유이다.

 

 "밸런싱" 이 제대로 안되면 월급이 밀리는건 시간문제이다. 따라서, "추상화" 는 "월급이 밀리는" 문제와도 깊은 연관이 있다고 할수 있다. 즉, 월급밀리는 사태가 보기 싫다면, "추상화" 에 대해서 신경쓰도록 하자.

 

 

4, 추상화는 어려운 개념이 아니다.

 

 시스템기획에서 말하는 "추상화" 는 어려운 개념이 아니다. 사실 나는 "시스템기획" 도 모르고, "추상화" 도 잘 모르지만, 훌륭하게 "시스템기획" 을 하고, 프로그래머가 봐도 "놀라운" 수준으로 "추상화" 를 하는 기획자를 많이 봤다. 왜 그런것일까? 프로그래머에게 이런저런 기능을 요청하기 이전에, 확장성을 생각해서, "이런기능도 필요하지 않을까?" 라고 염두해두고, 이런저런 기능을 묶어서 하나로 통합하여 프로그래머에게 "이런기능 만들어 주세요" 라고 하는것이다.

 

 비록 "추상화" 에 대해서 모르지만, 훌륭하게 "추상화" 를 하는 경우이다. 시스템기획이나 "추상화" 에 대해서 막연하게 공부하기 이전에 "왜" 추상화를 해야하는지? 그리고 추상화를 잘못하면 어떤불상사가 발생하는지 생각해보자, 그러면 "추상화" 에 대한 이해가 쉬워진다.

 

 이렇게 설명했는데도 시스템기획에서 말하는 추상화가 뭔지 모른다면 다음 한마디면 쉽게 설명된다.

 

"추상화 잘 못하면, 월급이 밀린다."

 

농담이 아니다, 진실이다.

 

 

(출처 : http://iaanart.com/blog/view/blogNo/1/logNo/3932?PHPSESSID=242e9d59866c28b0579b71bd46b23db4)

 

출처 : 나의 게임개발 회고록

글쓴이 : shg 원글보기

메모 :