개발자의 유형

독불장군 The Marverick
독불장군은 모든 사람들이 믿고 의지하는 재능있는 사람이다.
만약 중요하고 민감한 일을 해야 한다면 독불장군이 제격이다. 높은 수준의 기술과 넓은 지식을 함께 갖는 독불장군은 리더로서의 자리를 잘 해낸다. 물론 문제가 생기기 전까지는..
독불장군은 자기가 짠 코드에 완전한 소유권을 쥐고 누구도 다가오는 것을 허락하지 않으려고 한다. 독불장군이 보기에는, 그의 코드를 건드리게 할만큼 미더운 사람이 아무도 없다. 다른 누구도 기술이나 지식이 부족하기 때문에 코드의 순수함을 더럽힐 뿐이러서, 못 건드리게 하는 것이 최선이라 여긴다. 그가 유별나게 경쟁심이 강하거나 자만심이 강하지 않는 이상, 팀원들에게 이런 행동은 용납되곤 한다. 대부분 코드는 다른 사람들은 거의 해독 불가능하다. 이런 방식의 장벽을 전문 용어로 '직업 비밀'이라고 부른다.
하지만, 무언가 잘못되고 있을 때는 어떻게 되는가? 아무도 코드 내용을 모르기 때문에 식은땀을 흘리고 앉아서 독불장군이 문제를 해결하는 것을 기다리고 있어야 한다. 팀 전체가 한 사람 때문에 기다려야 한다는 이야기가 된다. 이것은 리스크이며 별로 좋은 상태도 아니다. 독불장군이 실패한다면, 팀 전체가 그를 따라 실패하는 것이다.
그리고 방대한 량의 이해하기도 힘든 소스 코드를 남긴 채로 독불장군이 그만둔다면 남은 팀원이 할 수 있는 유일한 방법은 독불장군이 남긴 코드를 이해하기 위해 '리버스 엔제니어링'하는 것 뿐이다. 다른 방법도 있긴 하지만, 불쾌하고 불합리한 것 뿐이다. 불행하게도 이 방식을 쓸 수 없을 수도 있는데, 독불장군은 어떤 분야에 중대한 책임을 지고 있는 경우가 많기 때문이다. 기능을 뺄 수 없거나 뺴서는 안되는 경우에는 그 기능 구현에 매달려서 독불장군이 떠나간 덕분에 생긴 지연을 감수할 수 밖에 없다.

프리마돈나 The Prima Donna
그는 최고다.
이 사람은 자기가 최고라고 알고 있기 때문에 그를 트집잡으려면 그의 분노를 견딜 수 있어야 한다. 모든 사람이 프리마돈나를 알아야만 한다. 그는 거대하지만 깨지기 쉬운 자아를 가진 존재다. 그의 의견은 언제나 최고이며, 그의 코드는 언제나 완벽하다. 독불장군과 마찬가지로 프리마돈나는 비평을 받아들이는 법을 모른다.
프리마돈나는 보통 매우 머리 좋고 기술적으로 능숙하다. 그러나 미숙한 대인 관계와 남에게 나쁜 쪽으로 영향을 미치는 기술이 그의 특기이기도 하다. 그는 세상을 두 부류로 나누는데, 그보다 머리가 나쁜자, 그리고 자기에게 위협이 되는 자가 그것이다. 그는 주로 프로젝트 리더가 되는데, 그의 댜양한 재능을 가장 잘 발휘할 위치로 보이기 때문이다. 불행하게도 이 위치야말로 팀에게 가장 큰 피해를 입힐 수 있는 곳이다.
프리마돈나는 지력과 기술로 자신에게 위협이 되리라고 여기는 모든 사람을 공격할 것이다. 그의 능력에 미치지 못하는 다른 사람은 무능한 자로 여길 것이다. 모든 사람(특히 내성적이지 않은)이 팀 내부에 불편한 움직임을 만드는 그런 공격을 견딜 수 있는 것은 아니다. 프리마돈나는 팀에게 있어 가장 거대한 위험요소다. 프리마돈나의 괴상한 행동 때문에 팀이 파괴된다면, 최고의 동료 2~3명은 잃게 될 것이다.
프리마돈나는 기본적으로 타인의 능력을 의심하며 그들의 작업을 깔보는 지배 도착자다.

부끄럼쟁이 The Shy Guy
부끄럼쟁이는 전형적인 매니아다.
부끄럼쟁이는 대단히 소극적이며, 하루에 한 두 번은 의사소통장애를 일으킨다. 부끄럼쟁이도 비평해주기 어렵다. 사실은 칭찬하는 것도 어렵다. 이것이 아이디어에 관해 서로 이야기하는 기본적인 것임에도 불구하고... 이런 사람들은 자기 컴퓨터 압에서만 편안해 하는 것 같으므로 전자 우편을 보내는 것이 최상의 의사소통 수단일지도 모른다.
부끄럼쟁이가 직접적인 위협을 가해서 팀을 일부러 파괴하는 경우는 없지만, 그가 팀에 미치는 위혐은 상당히 명확하다. 그들은 절대 함께하지 않는다는 것이 문제다. 의사소통의 부재가 가져오는 가장 큰 문제는 프로젝트의 가시성을 극단적으로 똘어뜨리며, 이거은 거대한 프로젝트에서는 매우 큰 문제가 된다.

복병 The Sleeper
복병은 정상적인 팀 동료로 보인다. 적어도 표면적으로는 그렇다. 그러나 깊이 들여다보면 그들은 그렇게 도움이 되지 않으며, 다른 팀 동료들을 조종해서 분란의 씨앗을 뿌린다.
이에는 여러가지 이유가 있다. 가장 일반적인 이유는 순수한 반골인 경우다. 복병은 단순히 권력을 인정하지 못하며 무의식적으로 어떤식으로든 권력을 부정하려고 한다. 다른 이유로는 팀 동료를 선동해서 독립적인 팀을 만들려고 한다던가, 혹은 대우가 불충분하다고 생각해서 다른 팀 동료들도 똑같이 생각하기를 바란다던가 하는 것이 있다.
복병은 알아채기 어렵기 때문에 매우 위험하다. 복병은 관리자들에게 존재를 알리지 않으며 자신의 불만은 숨긴 채 자주 믿음직스러운 사람으로 인식되곤 한다. 익명보고창구를 만들어 두면 이런 문제 있는 개발자를 찾아낼 수도 있다.

팔방미인 The Jack
팔방미인은 모든 것을 다 할 수 있지만, 어떤 것에도 최고는 아닌 사람이다.
그는 여러 '부정적인' 유형 중에는 가장 쓸모있는 편이고, 어떤 경우에는 바람직하다고 여겨지기도 한다. 팔방미인은 문제 유형 중에서 유일하게 남겨둘 가치가 있는데, 자신의 단점을 극복하도록 가르치기만 한다면 유용한 팀원이 될 수 있기 때문이다.
팔방미인의 중요한 단점은 자신의 능력을 노무나 확신하고 있어서 가끔은 그것이 지나친 자신감이 되기도 한다는 것이다.
그의 능력에 대한 믿음이 실제 능력과 만나는 타이밍은 너무 멀어서 그의 신용이 회복 불가능한 타격을 이고 나서야 발견되곤 한다. 이런 일이 생기는 이유는 자신이 감당할 수 없는 능력을 요하는 위치를 차지하기 위해 자신을 꾸며야 하기 때문이다.(팔방미인이 잘 하는 일이기도 하다.) 실패를 인정할 수 없기 때문에, 그는 허풍을 떨기도 하고 부족한 코드를 만들기도 하고 그보다 능력이 떨어지는 팀원들에게는 기술적인 변명을 하기도 한다.

모든 사람들은 완전함을 갖출 수는 없다. 위의 5가지 예시는 개발자를 기준으로 서술된 내용이지만 모든 프로젝트 업무에도 동일하게 적용이 가능하다. 자신이 과연 어떠한 유형에 속하는지 생각해 보고 서로간의 단점을 보완할 수 있는 시간을가질 수 있었으면 한다.

기획문서 이용하기

이전에 기획 및 테스팅 관련 책을 읽던 도중 다음과 같은 내용을 본 적이 있었다.

- 게임 기획서는 프로그래머들이 꼭 읽어야 한다.
- 프로그래머들은 게임 기획서를 읽지 않을 것이다.

진짜로 프로그래머들은 게임 기획서를 읽지 않을 것이다.(최근에 경험해본 프로그래머들은 기획서를 읽는 경우가 대부분이었다. 물론 이전에는 읽어보지 않는 경우를 많이 경험했다.) 매우 중오하다고 말하거나 읽어달라고 애원하거나 심지어는 초상금을 건다고 해도 프로그래머들은 기획서를 읽지 않을 것이다.
프로그래머들은 나무를 보지만 숲을 보지 못하고 기획자들은 숲은 보지만 나무를 보지 못한다는 글을 본적이 있다. 이 글에 어느정도 수긍할 수 있다.(물론 가끔 잎사귀를 보느라고 나무를 보지 못하는 프로그래머들이라는 예외도 있지만...) 나무를 보는 자세함 때문에 좋은 프로그램을 짤 수도 있는 것이겠지만, 완성된 제품에 대한 대강의 모형을 머릿속에서 그릴 수 있게 해주는 게임기획서 같은 긴 문서를 읽거나 받아들이지 않는 이유도 여기에 있다.
프로그래머가 기획서를 봐야할 이유가 있을까? 완성된 제품에 대한 상상을 하는 것은 프로그래머의 일이 아니라 기획 그룹의 일이다. 그러나 프로그래머들은 몇가지 이유에서 기획문서들을 읽을 필요가 있다. 첫번째 이유는 목표도 모르고 일을 맡아서 하면 사기도 저하되고 능률이 오르지 않기 때문이다. 두번째 이유는 일을 진행하면서 질문이 생길 때마다 디자이너가 대답하기 위해 묶여 있는 것보다 이쪽이 더 효율적이기 때문이다. 세번째 경제적인 이유때문에 몇명 안되는 사람들이 기획서를 쓰기는 하지만 여전히 모든 사람들의 좋은 아이디어를 모아 발전시키는 것이 완벽을 기하기는 더 좋은 방법이기 때문이다. 마지막으로 프로젝트의 비전을 그룹에서 함께 나누는 것은 전체적인 단결력을 강화하고 사기를 올리는 결과를 가져오기 때문이다.

게임 기획문서..

게임 개발에 참여하게 되면 기본적으로 다음 두가지를 접할 수 있다.(현실적으로 한가지만 접하게 되는 경우가 대부분이다.)

- 게임 기획서
- 기획자 노트

게임 기획서
게임기획서는 게임에 대해 자세히 설명한 문서로, 잘 읽고 이해하기만 한다면 독자는 완성된 제품의 모든것을 누앞에 그려낼 수 있을 정도로 쓰여 있어야 한다. 초기에 이 기획서는 게임에 대한 초기 프로토타입일 수도 있고 1년 후에 만들어낼 게임에 대한 상세한 묘사를 담고 있을 수도 있다. 게임기획서는 개발하는 도중에 새로운 변화들이 추가됨으로써 역동적으로 발전하게 된다.
열심히 만든 게임기획서를 가지고 프로그래머에게 가서 완성되었다고 말하면 그들은 뭐라고 말할까? 혹시 "그게 어떻게 완성된거야? 거기에 초인/불뿜는 몬스터도 들어있지 않는데.."라고 하지 않을까?
이러한 생각은 사람들이 '완성'이라는 말에대해서 잘못 이해했기 때문에 일어난다. 게임 개발에 있어서 완성이라는 말은 도큐멘트나 코드 모둘이 변하지 않을 거라는 뜻이 아니고 하나의 단계에서의 완성을 의미한다. 완벽하지 않아도 그 문서는 실제 공정에서 쓰여지게 된다. 혹시 도큐멘트나 코드를 만들던 사람이 불의의 사고를 당해 더이상 작업하지 못한다 하더라도 그가 하던 일을 중단할 필요는 없다. 그것이 일정한 단계까지 완성되어있다면 다른 사람들이 이어서 쓸 수도 있고 필요한 만큼 고쳐 쓸 수도 있다.
어찌되었든 완성이란 '끝났다'는 것을 의미하지 않는다. 완성이란 진행하는 단계의 완성을 의미하는 것이고 모든 단계가 완성되면 그 게임은 출시된다. 작업이 '끝났다'는 것은 생각할 수 있는 모든 요소를 다 집어넣고 코드, 게임 진행, 인터페이스, 그 이외 다른 부분에 있어서도 모든 일이 다 완결되었음을 말한다.

기획자 노트
기획자 노트는 기획서를 구상하는 동안 머리에서 굴러다닌 많은 생각들에 대해서 써내려간 문서이다. 만약에 새벽 2시에 봉투 뒷면에 끄적여 놓은 낙서가 마음에 든다면 그것을 노트에 붙인 후 설명을 붙이면 된다.
기획자 노트는 몇가지 이유에서 쓸모가 있다. 첫번째로 제작팀에게는 모든 문서들은 가치가 있다. 디자이너가 다음 게임에 대해서 공상하다가 의자에서 떨어져 다쳤다 해도 디자이너가 쓴 여러가지 문서들이 남아있는 한 프로젝트는 망하거나 내던져지지 않을 것이다. 두번째로 프로그래밍 코드에 대한 도큐멘트 비슷한 방식으로 유용하게 쓰인다. 게임 기획서의 한 문장은('두 유니트간의 화력비고'라든가 코인을 모으면 무엇으로 보상을 받는가?'등의 간단한 결정) 많은 시간동안의 심사숙고의 결과물이다. 그러나 누중에 '무엇이다'라는 것은 기억 할 수 있어도 '왜' 라는 것은 기억하지 못하게 된다.

'게임'이란

자신의 아이디어가 오락용 소프트웨어의 새로운장을 열만큼 엄청난 것이 아니라고 한다면 다음으로 가장 신경을 써야 할 부분은 그 게임을 '잘' 만드는 일일 것이다.

좋은 게임이라는 것은 플레이어가 무언가 새로운 것을 고안하고 그것을 잘 운용하였을 때 승리할 수 있어야 한다. 이것은 게임플레이라는 것의 본질에 매우 가까운 정의이다. 이 정의를 바꾸어 말하자면 "게임플레이는 플레이어로 하여금 전략을 짜도록 한다."이다. 이 말은 세상 모든 게임이(게임 장르로서의) 전략 시뮬레이션 게임이라는 뜻이 아니다. 이 말은 단지 테트리스에서 시작하여 최신게임에 이르기까지 그 게임을 잘 하기 위해서는 플레이어가 나름대로의 전략을 짜 내야 한다는 것을 의미한다.판매 혹은 서비스 되고 있는 게임들을 관찰해 보면, 게임이란 다음 중 한가지 이상의 목표를 달성하는 것을 목적으로 하고 있다는 것을 알 수 있다.

- 무언가를 모은다.(점수, 아이템)
- 영토를 확보한다.(바둑, 땅따먹기)
- 목적지에 먼저 도착한다.(레이싱)
- 발견(탐험, 추론)
- 다른 플레이어와의 대결

레이싱 게임이나, 대결, 영토뺏기 게임은 목표가 게임 내에서 확실히 보인다. 게임 중 누가 이기고 있는지를 언제나 금방 알 수 있기 때문이다. 이에 반하여 모으기 식 게임은 목표가 눈에 잘 보이지 않는 경우가 많은데, 이런 이유로 이러한 게임들은 대부분 플레이어가 모은 무언가의 양(점수, 아이템)에 따라 게임 내에서 보상을 해 주도록 디자인되어 있다.

- 대부분의 RPG에서 경험치를 모으면 캐릭터의 스킬이나 능력치를 향상시키는데 사용할 수 있다.
- 전략 게임에서 자원을 모으면 새로운 유닛을 생산하거나 기존의 유니트를 업그레이드 할 수 있다.
- 어드벤처 게임에서 아이템을 얻으면 새로운 퍼즐을 풀 수 있게 된다.

거의 모든 게임들은 2가지 이상의 목표를 가지고 있다는 점에 주목하자. 스타크래프트를 예로 들면 일단 경주형 게임의 요서를 가지고 있다. 플레이어들은 자원을 채굴할 수 있는 장소에 먼저 도착하기 위해 경주한다. 또한, 더욱 풍부한 자원을 모으기 위해 노력한다. 궁극적으로는 다른 플레이어를 쳐부순다는 목적이 있다.
게임 내에서 복수개의 목표를 설계할 때에는 이들을 서로 연동시키는 것이 중요하다. 만약 목표들 사이의 연동이 없으면 실질적으로는 아무런 상관도 없는 미니 게임들을 설계하고 있는 것이나 마찬가지이며 이들 미니 게임들은 절대 하나로 묶이지 않을 것이다.

당신이 가진 기본 아이디어를 게임에 반영하고자 하는 경우에는 우선 스스로에게 다음과 같은 질문을 해 보자.

- 게임의 목적은 무엇인가?
- 플레이어들은 그 목적을 어떠한 방법을 통해 이루는가?
- 게임은 실제로 어떠한 형태를 뛰게 될 것인가?
- 게임플레이를 위한 규칙은 무엇이 있는가?