먼저 이 XD 라는 것은 아직 정의된 개념이 아니며, 앞으로 기획팀에 적용하고, 그 사례를 정리할
계획을 가지고 있습니다. 근래 관심을 끌고 있는 XP 에 관하여 공부하다 XD 를 생각해 보게
되었음을 밝힙니다.
참고로 XP(extreme programming) 와 마찬가지로 XD 또한 기본적으로 성선설 즉 오픈 마인드로
함께 디자인을 하고, 또한 다른 팀원들과의 적극적인 의사 소통과 지속적인 수정을 통해 최적의
기획안을 만들어가자는 것입니다.
이 내용들은 KGDA 의 발대식에 발표했던 내용들이며, 좋은 반응을 얻었지만 어떤 비판적인 의견이
라도 함께 수용하고, 논의해 볼 마음을 가지고 있으니 언제든 부담없이 편지를 주시기 바랍니다.
- 정무식(master@kgda.or.kr)
XDI(Extreme Design Installed) 효율적이고, 효과적인 기획의 구성 오류를 최소화하고, 작업의 체계
및 순서 정립을 통해 명확한 작업의 진행을 가져가는 것. 대부분의 회사에서나 기획자들은 기획의
표준에 대해서 알고 싶어한다. 어떤 기획서가 최고의 기획서인가? 무엇이 정답인지를 고민하게
된다. 하지만 정답은 남이 써놓은 기획서를 보고 참조하는 것이 아니라 자신의 회사, 자신의 게임,
자신의 팀원에 맞는 기획서를 만들어가는 것에 있다. 그리고 그렇기에 어떻게 효율적이고 효과적인
기획서를 쓰는가의 방법은 정답과 정석으로 짜여진, 보기에 멋진 기획서라기 보다는 실제적으로
필요한 기획서를 만들어가는 과정이 훨씬 더 중요하다 하겠다. 이제는 자신의 팀에 맞는 가장 효율
적이고 효과적인 기획서를 만들기 위해 나아가 기획을 하기 위한 모델을 연구하고 적용시켜 나가야
할 때인 것이다.
가장 먼저 XD 를 떠오르게 해준 즉 영감을 준 XP에 대해서 알아보도록 하자. XP 는 얼마 전부터
프로그래머들에게 큰 이슈가 되고 있는 프로그래밍의 방법론이다.
1. XP 시작의 원칙: 무조건 따라 하라!
무술에서 학생은 처음에 형(形) 혹은 가타(가라데에서의 품세)를 선생이 가르치는 그대로 따라
하도록 배웁니다. 나중에, 훨씬 나중에야 규칙을 어길 수 있고, 더 나중에, 마침내는 자신의 상황에
맞게 규칙을 맘대로 조정할 수 있게 됩니다.
? XP 도입을 위한 실전 입문 중 ?
현재 게임 기획의 가장 큰 문제점은 기획의 표준이 없다는 것이며, 사실 기획의 표준 매뉴얼이 없다
는 것보다는 기획의 공정 즉 프로세스에 대한 명확한 정의가 내려지지 않았다는 것이다. 누구도
정답을 알고 있지 못하며, 정답을 이야기하기를 꺼려한다. 기획서의 공개는 자신의 모든 실력을
만천하에 공개하는 즉 발가벗는 행위에 비유되곤 한다. 때문에 현직 기획자들도 이런 정답에
대해서 공개를 꺼리며, 남의 공개된 것에 대해서는 늘 상 많은 말들을 하곤 한다. 무엇보다
아마추어 개발자들이 늘 상 맨땅에 헤딩하기로 처음부터 고생을 해야 한다는 점이 가장 아쉬운 점
이라 하겠다. 일단 XD 도 XP 와 마찬가지로 정해진 품세를 세우는 것을 목적으로 한다. 그리고
오랜 경험과 연구를 바탕으로 나온 이 XD 의 과정들을 아마추어 개발자들은 그대로 따라 하기를
권유한다. 기본이라는 것은 아주 오랜 경험을 통해서만이 정립이 가능한 부분이며, 그 경험의 산물
이기 때문이다. 어른의 말을 들으면 자다가도 떡이 생긴다 하지 않았던가? 선배의 조언도 마찬가지
이다. XD 또한 XP 와 마찬가지로 몇 가지 사전 권고 사항이 존재한다.
1. 한방에서 작업하라.
가능한 모든 작업을 한방에서 하도록 노력해야 한다. 한방에서 모두 함께 일하는 것은 대부분의 팀
에게 있어 따로 일하는 것보다 훨씬 더 효과적이기 때문이다.
2. 모든 기획은 검증 받아야 하며, 검토되어야 한다.
XP에서는 격주에 한번씩 실제로 돌아가는 소프트웨어를 고객에게 줄 수 있어야 한다고 한다. 그것
은 실제로 고객에게 지속적으로 소프트웨어를 테스트하도록 함으로써 소프트웨어에 대한 이해와
사전 기획과의 갭, 즉 차이를 줄이기 위한 노력이다. 고객에게 테스트를 적게 시킬수록 마찰과 문제
발생은 적어지겠지만 그것들은 눈가리고 아웅하는 형태로 보아야 할 것이다. 지속적인 테스트를 통
해 그들이 원하는 니드에 따라가고 있는지를 체크하고 방향을 수정해 나가야 한다. 그렇다며 XD 에
서의 고객은 누구인가? 바로 두 부류로 나뉜다. 실제로 게임에 대한 제작 결정권을 가지고 있는 경
영진 그리고 마케터, 또한 실제로 기획서를 보고 게임을 제작해야 할 개발 파트(프로그래머, 그래픽
디자이너)이다. 실제로 모든 기획은 적어도 2주단위로 고객에게 검토를 받아야 한다.
경영진의 경우 현재 그들이 이해하고 있는 게임으로 제작되고 있는가? 어떤 문제점들이 있는가? 즉
프로젝트의 상품성과 성공 가능성, 그리고 프로젝트 관리에서의 문제점을 숨기지 말고 그들이 직시
할 수 있도록 해주어야 한다. 중요한 것은 이런 검증과정의 경우 단순히 형식적인 상황보고를 위한
과정이 아닌 문제를 알리고, 그들이 대처할 수 있게끔 하는 과정이 되어야 한다는 점이다.
개발파트의 경우 그들이 기획 안에 대해서 어떤 이미지를 가지고 있는가? 작업에 대해서 파악을 하
고 있는가? 문서를 이해하고 있는가? 게임에 대한 공통적인 이미지를 가지고 있는가가 중요한 문제
이다. 대부분의 개발자들이 기획서를 읽지 않거나 실제로 완성된 기획서를 보고 불평을 하며 게임
개발을 진행하는 경우가 대부분이다. 게임 개발 기획서는 그들이 게임 개발의 방향 즉 지침서로 활
용하는 만큼 최대한 그들에 맞게 기술되어야 한다. 때문에 기획의 방향, 제작의 방향, 기획서의 포
맷 등을 지속적으로 검토하고 수정하여야 한다.
3. 검토된 것은 기록되어야 한다.
2주 단위의 검토 작업 시에 고객들로부터 명확히 결과를 받도록 하며, 결과를 받았다는 것에 대해
사인을 받도록 한다.
4. 짝 디자인
XP 에서는 Pair Programming 에 대해 강조하고 있다. 즉 짝(Pair)와 함께 작업을 하고, 짝을 자주
바꾸어 진행함으로써 더 좋은 코드를 얻고, 이해력을 높일 수 있으며, 더 나은 팀으로 만들어 갈 수
있다고 말한다. 그리고 이것은 XD 에도 그대로 도입된다. 사실 기획을 할 때나 프로그래밍을 할 때
한 사람이 작업 시에 멍하니 쳐다보는 것은 바보같이 보일 수도 있을 것이다. 하지만 분명 기억하여
야 한다. 문서작업을 할 때도 내가 문서를 치고 있을 때는 모르는 맞춤법의 실수를 옆에서 지켜보면
너무도 쉽게 찾아낼 수 있다는 점이다. 기획에서의 Pair Design 은 다음과 같은 목적을 가진다.
(드라이버와 파트너)
첫 번째 기획표준안의 정립. 즉 한 사람이 기획의 표준안을 정립하는 것이 아니라 함께 상의하여 더
나은 기획표준안을 정립할 수 있다는 점이다. 즉 게임에서 쓰이는 캐릭터 시트나 마법에서의 정의
등 모든 작업 시에 보다 합의된 결과를 도출할 수 있다는 점이다.
두번째 그와 함께 보다 체계적이고 실수가 없는 작업을 진행할 수 있다. 그것은 아까 말했듯 옆에서
지속적으로 오류 부분을 지적하고 의견을 줄 수 있기 때문이다. 또한 파트너는 단순히 작업을 지켜
보는 것이 아니고 수행하고 있는 모든 작업을 이해하고 있어야 한다. 그렇지 않다면 진행을 중단해
야 한다. 만약 드라이버가 제대로 진행하지 못한다면 지켜보던 파트너로 교체해야 한다. 서로 열린
마인드로 의견을 받아들이는 것이 필요하다. XP 에서 간결함, 대화, 반응, 용기, 이해 가 필요하듯
XD 에서도 마찬가지이다. 함께 일을 잘하는 역동적인 이인조는 세 명이 따로 일하는 것 만한 가치
가 있다.
그리고 이 Pair Design 의 발전형으로 Group Design 을 권한다. 즉 기획표준안 등을 정립할 때 모
두의 의견 조율과 합의를 거쳐 디자인을 완성하는 것이다.
5. 테스트 주도 개발
XP 에서는 작은 테스트하나를 만들고, 그걸 작동하도록 한 다음, 또 다른 테스트를 만드는 것을 원
칙으로 한다. 일단 완성하고 지속적으로 테스트해서 완성된 것을 붙여감으로써 명확한 테스트, 테
스트를 통해 진행하고 완성함으로써 스트레스를 줄일 수 있으며, 테스트를 자주 진행함으로써 프로
그램 변경이 두렵지 않다고 말하고 있다. XD 또한 마찬가지이다. 일단 XD 의 테스트의 가장 이상적
인 것은 프로토타입의 완성이며, 툴을 이용한 게임 개발이다. 배틀렐름의 엔진에 포함된 약 60종의
툴등 중 아이콘 편집 툴, 인공지능 툴, 심지어 메뉴 인터페이스 툴까지 있는 것은 그만큼 기획자들
이 프로그래머에게 의존하지 않고 게임을 개발할 수 있다는 것을 말한다. 그런 상황이 아니라면 기
획자는 프로그래머와 적극적으로 협의하며 기획 안을 만들어가야 한다. 하지만 대부분의 기획자들
은 프로그래머와 이야기하는 것을 싫어하며, 어려워하기 마련이다. 그것은 프로그래머들의 성향의
탓도 있겠지만 실제적으로 자신의 일이 늘어나고, 변경되는 것에 대해 스트레스를 받는 프로그래머
들의 상황이 더 큰 영향을 주는 문제일 것이다. 하지만 그런 상황이라고 검토를 미루는 행위는 더
바보 같은 짓이다. 현실을 직시하고, 지속적으로 프로그래머와의 협의를 통해 기획 안을 프로그래
머를 통해 테스트할 수 있어야 한다. 그리고 이것은 경영진의 사업에 관한 부분에 대한 검토 또한
마찬가지가 될 것이다.
6. 깨끗한 코드(기획 표준안)를 정리하라.
사실 프로그램도 마찬가지지만 기획서만큼 자주 변경되고 또 버전이 바뀌는 경우도 없을 것이다.
각각의 기획서 별로 계속 변화하고 진화한다. 그런 기획서와 디자인 문서의 경우 모든 게임 디자이
너가 따로따로 관리하기 마련이다. 그런 가운데 모든 문서들은 중구난방으로 제각각 쓰여지기 마련
이다. 중요한 것은 모두가 합의한 가장 깨끗한 문서 즉 문서의 표준안은 누구나 쉽게 볼 수 있어야
하고, 또 그 표준안이 정리가 되어가야 한다는 점이다. 그리고 그 표준안을 통해 계속 개별작업들이
통일성 있게 수정되어가야만 한다.
7. 문서의 관리와 수정
앞서 6번의 기획 표준안 정리와 연결되는 부분이다. 중요한 점은 그렇게 기획 표준안이 관리되기 위
해서는 모두가 함께 사용하는 공통 DB 가 있어야 한다는 것이며, 그 DB 는 버전업에 대한 부분들의
합의와 정의가 이뤄진 다음 관리되어야 한다는 점이다.
8. 팀 코드(기획 표준안)소유
XP 에서는 프로젝트에 관여한 모든 사람을 코드에 접근할 수 있도록 하며, 이것이 팀 노력의 성과
라는 것을 상기시키기 위해 노력한다. 즉 열린 마인드로 코드를 대하고 수정하고 의견을 제시할 수
있도록 노력하는 것이다. 그리고 이것은 XD 에도 그대로 적용이 된다. 기획 표준안은 누구나 접근
이 가능해야 하며, 모두의 결과물로 만들어가야 한다. 다만 로그 및 수정에 대한 기록이 남아야 하
며, 그것에 대한 모두의 합의를 통해 표준안을 제작해 나가야 한다는 점이다.
9. 코드(기획 표준안)는 지속적으로 적용시켜야 한다.
즉 기획 표준안에 의해 완성된 기획은 곧바로 실제 기획서에 적용을 시켜야 한다는 것이다. 표준안
만을 만들어두고 사용하지 않는 것처럼 바보 같은 일은 없을 것이기 때문이다.
10. 고객(작업 관계자)은 현장에 있어야 한다.
실제로 XP 에서 중요한 것은 고객을 프로그래머 옆에두고 모든 작업의 진행과정을 함께 하는 것이
다. 추측으로 코드를 만들지 않고, 요구사항을 바로 받아들여 코드에 반영할 수 있다. 그리고 그것
은 XD 에서도 마찬가지이다. 물론 작업자인 프로그래머를 늘 옆에 둘 수는 없겠지만 상시적으로 만
날 수 있고, 의사소통의 채널을 만들어 두어야 한다. 그리고 회의등을 참석시키거나 혹은 결과물 및
검토된 의견에 대해서 사인할 수 있도록 하여야 한다.
11. 초반에 너무 많은 양을 작업해서 고객(작업 관계자)과 접촉하지 마라. 또한 설계된 문서를 작업
자들이 실제로 활용하고 있는지 확인하라.
12. 변경을 두려워해서는 안된다.
기획을 하면서 요구사항을 확정짓지말라. 요구사항은 늘 변할 수 있다는 점을 깨달아야 한다. 처음
에 스토리 즉 작업의 체계를 잡는 일이나 우선 순위를 정하는 일들, 정해진 기획의 표준안들에 대해
서 의견을 무시하거나 변경을 두려워해서는 안된다. 기획팀원들의 의견, 실제 작업 관계자의 의견
들을 자유롭게 수용하라. 그리고 그로 인한 여러가지 변경들에 모두가 익숙하게 받아들일 수 있어
야만 한다.
13. 책임자를 선정하라.
기획안들의 제작에 있어서 책임자를 표기하고, 그 사람의 중심으로 관리가 진행되도록 한다. 다른
사람들은 참조하고 언제든 의견을 제시할 수 있다. 하지만 분명히 책임질 수 있는 사람은 정해져야
한다. 그와 함께 특정 작업만을 전문으로 하는 사람을 두지 않는 것이 좋다. 팀원들의 전체를 보는
시야를 키운다.
14. 기획은 변하지 않지만 기획서는 프로그래머(고객)의 요구에 따라 변할 수 있다.
15. 기획서 작성 표준 단어집을 DB 구축하라.
기획서를 쓰다보면 같은 내용을 서로 다르게 표시하고 점차 그것이 알아보기 어렵게 자신들만의 언
어로 쓰여지게 마련이다. 표준언어를 사용해 수정이 쉽고, 알아보기 쉽도록 해야한다. 또한 그 단어
는 고객(실제 작업자)들에게도 검증받아야만 한다.
16. 단순하게 설계하라.
기획서가 완성될 때마다 고객에게 검증받아라.
모든 기획자들의 아이디어를 반영하라.
중복된 문장이나 부분들을 삽입하지 말아라.
17. 프로젝트의 성공은 사람들에게 달려있다. 의사소통에 집중하고, 즐겁게 작업할 수 있도록 하라.
18. 진실을 이야기하라. 누구에게나 항상 주기적으로 상황을 이야기하고, 의견을 교환하라.
2. 역할 정의
(1) 고객의 역할
XP 팀은 ‘스토리’라는 개념을 통해 소프트웨어를 계획하고 구축한다. 스토리란 시스템이 어떻게 작
동해야 하는지에 대한 개별적인 기술이다. 각 스토리는 시스템이 해야하는 일 한가지를 설명한다.
프로그래머는 스토리를 통해 난이도를 추정할 수 있을 만큼 각 스토리를 충분히 이해하여야 한다.
또한 각 스토리는 테스트가 가능해야 한다.
? XP 도입을 위한 실전 입문 중 ?
XP 에서 이야기하는 스토리란 어떤 작업이 이뤄져야 하는지를 결정해 가는 개별 단위를 말한다. 작
업의 정의인 WBS 와도 비슷한 맥락으로 이해하면 될 것이다. 모든 기획작업을 하기 전에 과연 이
작업이 어느정도의 분량인지? 얼마나 어려운 일인지? 얼마에 끝내야 하는 것인지? 우선 순위와 기
술들은 무엇인지등에 대해 어느정도 결정을 내리고 파악한 뒤에 실제 작업을 수행해야 한다. 먼저
여기에서의 고객의 역할은 어느것이 중요한지 우선순위를 매기고, 무엇이 필요한지등의 요구를 말
하는 것이다. 즉 지금까지의 기획이 정한뒤에 프로그래머에게 가져가는 기획이었다면 XD 에서는
초기의 기획의 우선순위를 뽑고, 필요한 니드를 얻어내는 과정을 실제 개발진과 함께 진행하는 것
이다. 물론 A-Z 까지 모든 것을 다 논의할 수는 없을 것이다. 여러가지 양식을 바탕으로 논의하는
과정도 무리가 없다고 생각한다.
(2) 기획자의 역할
XP 에서의 프로그래머의 역할이 광범위한 테스트를 통해 신속한 피드백을 얻고, 극도로 명료하고
품질높은 코드를 지속적으로 유지보수하는 것이라면 XD 에서도 마찬가지로 기획자의 역할은 기획
문서를 다른 개발진에게 검토하고, 가장 최근의 버전으로 즉 완성률이 높은 기획폼의 양식으로 유
지보수 해가는데 있다. 그리고 그 통합된 상태를 유지하면서 모두에게 공개함으로써 모두의 기획서
의 수준을 상승시킬 수 있다.
(3) 관리자의 역할
훌륭한 관리자의 일은 처음부터 끝까지 작업을 하고 있는 사람들 앞에 놓인 장애물을 치우는 일이
다. 팀의 개발 속도를 지연시키는 것이 무엇인지 찾아서 관리자의 권한을 이용하여 없앤다.
? XP 도입을 위한 실전 입문 중 ?
실제로 XD 는 도입된 사례가 없으며, 현재 XP 를 바탕으로 가정할 수 있을 뿐이다. 시행을 위해서
는 관리자의 적극적인 지원이 필요하다. 또한 기획자와 다른 개발 파트간의 커뮤니케이션이 원할
하도록 지원하는 것이 가장 중요한 점이라 하겠다.
※ 스토리의 작업 단위 정의
① 작업의 스토리 및 WBS 를 분류해 두어야 한다.
② 과거 정리한 작업 단위별 기간 정리표가 있다면 참조한다.
(대부분 기록하지 않으며, 또한 솔직하지 못하다)
③ 작업 단위별로 스토리별 작업 기간을 정의한다. Ex) 1, 1,5, 2 등
④ 중요한 스토리를 몇단개 작업하고 나서 실제 걸린 기간을 파악한다. 이후 반복되는 작업 중에 스토리별 기간을 파악할 수 있을 것이다.
(한주에 작업 1 단위의 스토리를 5개 정도 처리할 수 있다 등등)
스토리의 우선 순위 결정 체계
① 기획자가 기획에서 구현할 스토리를 구성
② 필요한 조사를 수행
③ 고객(프로그래머)와 함께 궁금한 점에 대한 토의
(불가능한 것, 수정되어야 할 것, 우선 되어야 할 것)
④ 작업의 체계 즉 스토리별 순서를 정하고 그 순서대로 기획 작업을 시작
서울전문학교 에서 발췌한 내용입니다.
