일반적인 소프트웨어 개발이나 프로젝트 관리 서적들은 다들 잘 아실테니, 게임 제작(Game Production)만을 중점적으로 다루는 전문 서적들을 소개하고자 합니다:


1. The Game Producer's Handbook (Dan Irish, 2005)

제가 본 책들 중에서 최고입니다. 게임 제작 전분야를 체계적으로 잘 다루고 있습니다. (참고로 Gamasutra에서 별 5개를 받았습니다.)



2. 게임 제작 최전선 (Erik Bethke, 2005)



순진한 초짜의 쌈지돈을 우려는 듯한 유치한 표지와는 달리 내용은 알짜입니다. 표지가 망쳐논 책들 중 아까운 하나입니다. (마치 슈왈제네거의 우람한 체격에 천진난감한 어린애의 얼굴을 붙여놓은 격이랄까요...OTL)

한글로 된 책으로는 유일합니다. 원서는 Game Development and Production로 2003년에 출간되었습니다.



3. Game Production Handbook (Heather Chandler, 2006)


읽어본 적은 없습니다만, 저자가 해외 게임 비즈니스 가이드(중 3장)과 The Game Localization Handbook의 저자인지라 약간 기대해봅니다. (누구 읽어보신 분 답글 좀 부탁드립니다.)


혹시나 위 원서들의 번역/출간 소식이 들리면 답글 좀 달아주십시요.

업무의 소요 시간을 추정하는 공식으로, 게임 프로듀서 핸드북(The Game Producer's Handbook)에서 발췌했습니다.

업무에 필요해서 번역한 김에 올려둡니다.



이외에도 GDC 2007에서 Duane Webb(Bioware의 제작 이사)가 강연했던 Predicting the Future - Effective Project Scheduling Tools and Techniques에도 많은 기법들이 나오는데, 나중에 시간이 되면 번역해 올리겠습니다.

이 글은 Scrum Rising(Game Developer Magazine 2007년 02월)의 'Opening the Scrum Gate'를 자의적으로 날림 번역의역한 것입니다.


1. 작게 시작하라.

하룻밤에 스튜디오 전체를 바꾸려 하지 말라. 기꺼이 실험에 참가하고자 하는 8명 전후의 팀원들(10명을 초과해서는 안됨)을 고른다.


2. Scrum의 챔피언을 선발하라.

그는 Scrum의 리더나 프로듀서가 되어서 Scrum에 대한 모든 것을 배워야 한다. 일단 그에게 Ken Schwaber이 Scrum에 대해서 쓴 책 두 권을 읽게 하는 것부터 시작하라:

• Agile Project Management with Scrum, Ken Schwaber, 2004
  
• Agile Software Development with Scrum, Ken Schwaber, 2001

(유감스럽게도 아직 한글 번역본은 나오지 않았습니다. 혹시 출간 계획에 대해서 아시는 분은 답글을 부탁드립니다.)


3. 모든 실천 사항들(practices)을 그대로 시행하라

가장 중요한 (동시에 가장 논란이 되는) 조언은 "설사 그 가치를 이해할 수 없다고 하더라도, 책에서 언급한 모든 실천 사항(practices)를 그대로 시행하라."는 것이다.

Scrum의 실천 사항들은 매우 중요한 원칙들에 바탕을 두고 있다. 만약 이 점을 충분히 이해하지 못한 상태에서 변경을 가한다면, 대부분의 장점들을 누리지 못할 것이다. Schwaber는 다음과 같이 말한다. "나는 항상 Scrum의 기본 메카니즘이나 규칙들을 변경하려는 사람들을 만나는데, 그것은 그 메카니즘이나 규칙이 아무도 직시하고 싶어하지 않는 것들을 가시적으로 만들기 때문이다. 예를 들어서, '우리는 일일 Scrum이 필요하지 않으니 1주일에 한 번만 하자.'고 하는 사람들이 있다. 일일 Scrum은 그 팀이 자율적이지도 않고, 하나의 유기적인 조직이 아니라 그저 자기 일에만 신경쓰는 한 무리의 개인들(a group of individuals)에 지나지 않는다는 점을 들춰낸다. 즉, 아무도 신경쓰지 않기 때문에, 정보를 교환할 필요가 없다고 주장하는 것이다."

Scrum의 실천 사항들을 절대 바꾸어서는 안된다는 의미는 아니다. 단지 속도를 향상시킬 수 있는 경우에만 팀 스스로 바꾸어야 한다는 것이다. 또한 Scrum을 처음 도입하는 경우에는 Scrum Master 인증 과정을 수강하길 권한다. 2일 과정이며, 이곳 저곳에서 수시로 열린다. (물론 미국의 이야기이며, 한국에서는 애자일 컨설팅에서비슷한 과정-교육 및 코칭-을 제공하는 것으로 알고 있다.)


4. 고객(the customer)과 목표를 선정하라.

Scrum으로 들어가는 또 다른 중요한 단계는 그 팀의 고객(the customer)를 선별하고, 달성한 몇 개의 목표들과 그 우선 순위를 결정하는 것이다. 그 다음, 팀원들 중의 한 명을 선발해서 공인(Certified) Scrum Master으로 만든다. 초반에 그는 고객과 팀에게 개발의 모든 단계에 숨겨진 의미를 이해시킨다. (공인 Scrum Master가 되는 방법은, 3번 가장 마지막 문단에서 말하는 '인증 과정(혹은 연수)'를 통과하는 것이다. 인증 자격을 갖춘 기관이 한국에 있는지 누구 아시는 분?)

자, 이제 팀은 Sprint cycle로 들어갈 준비가 되었다!

GDC Korea 2007의 개최가 불투명하다는군요. 원래부터 무리수가 좀 많은 게 아닌가 싶었는데, 결국 이런 쪽으로 흘러가는군요. 안타깝네요.

GDC Korea 2007, 개최 불투명!

세계적 게임 박람회 중 하나인 게임 개발자 컨퍼런스(이하 GDC)의 한국 개최가 불투명하게 됐다. GDC 주관사인 ‘CMP 게임그룹(이하 CMP)’ 측과 공동주최를 하기로 한 부산광역시가 의견 조율에 실패해 공동 개최를 포기한 것. CMP 측과 부산광역시는 지난 3월 8일 GDC 개최를 위한 양해각서(MOU)를 맺은 바 있다.

부산광역시 측은 GDC 행사가 생각보다 많은 비용이 소모되고, 국내 중심이라기보다 해외 대형업체를 중심으로 이뤄지는 만큼, 애당초 지향했던 방향과는 많이 동 떨어진다고 판단해 이 같은 결정을 한 것으로 알려졌다.

CMP 측 역시 4월 초 정도까지 협의를 마무리 하고 실무를 진행 시켜야 하는데, 부산광역시 측과 조율 기간이 길어져 예정시기인 9월에 행사를 개최할 수 있는 시간적 여유를 잃었다고 밝혔다. 또한 GDC라는 전통적인 브랜드를 손상시키지 않는 범위 내에서 행사를 진행해야 하는데, 부산광역시 측과 협의 과정에서 마찰이 많았던 것이 사실이라고 덧붙였다.

이로 인해 CMP 측은 독자적으로 GDC를 진행하는 방향으로 가닥을 잡고 있으며, 일정상 올해 말이나 혹은 내년 상반기 개최도 고려하고 있는 것으로 알려졌다. 또한 부산광역시 역시 GDC라는 브랜드가 아닌 독자적인 게임 관련 컨퍼런스를 진행할 방침이다.

이에 대해 게임 전문가들은 “애당초 예정된 개최시기가 국내 최대 게임쇼인 G☆2007과 겹치는데다, 부스 비용도 1.5배나 비싸게 책정돼 국내 게임사들이 참가하는데 부담이 됐던 것이 사실”이라며, “한국에서 최초로 열리는 행사이니 만큼 미국이나 영국과는 차별화 된 무엇이 필요할 것” 이라고 지적했다.

봉성창 기자  wisdomtooth@kyunghyang.com  <2007년 05월 15일 19:05:49>

어쩐지 GDC 홈페이지에 GDC China만 있고, Korea가 안나오더라니.

실천가를 위한 실용주의 프로젝트 관리: 위대한 관리의 비밀을 남기룡 님의 포스팅을 보고 검색을 해보았는데, 꽤 괜찮은 책인 것 같습니다.

• 마인드맵으로 책보기 - 실천가를 위한 실용주의 프로젝트 관리(1장)

그냥 짐작컨데 최근에 읽은 프로젝트 관리 도서들 중에 The Art of Project Management급에 해당하는 월척이 아닐까 싶네요.

(물론 이 분야에 대한 제가 꼽는 최고는 단연 죽음의 행진입니다. 왜냐고요? 낙하산처럼 최악의 경우에 대비하게 해주니까요.)

위대한 관리자

개발자들은 관리자가 된다고 생각하면 미지의 거부감과 두려움에 쌓인다. 개발자들이 천성적으로 관리를 싫어하기 때문일 수도 있지만, 관리자로서 어떻게 하는지 제대로 배우지 못하고 관리자로서 임무만을 강요 받는데도 한가지 원인을 찾을 수 있다. 소프트웨어 개발 현장에서는 사수/부사수의 도제 형식으로 가르침을 받거나 각종 세미나, 교육 과정을 통해서 관리를 배울 수 있다. 하지만 어느 날 갑자기 관리자가 된 개발자는 그 순간부터 관리자로서 태어난다. 관리자가 되고 싶었던 개발자라도 관리자 교육을 받지 못하기 때문에, 넘어지고 깨지고 욕 먹고 혼자서 깨닫는 인고의 세월을 보내야만 한 명의 관리자로서 태어난다.

지난 회사생활을 돌이켜 보면 관리보다는 개발 업무가 더 많았다. 개발을 주로 했을 때는 관리하면 나와 상관없는 이야기로만 생각했다. 그러나 경력이 쌓이면서 어쩔 수 없이 관리 업무를 맡게 되었다. 일반인이 타고난 천성이 없는 경우 어떤 일에 익숙해지기까지는 많은 노력과 어려움이 따른다. 처음으로 맡은 프로젝트 관리 업무를 생각하면 지금도 웃음이 나온다. 참으로 많은 실수를 했기 때문이다. 그러나 관리업무에 익숙해지면서 처음과 달리 관리업무가 매력적임을 깨닫게 되었다. 결과와 일정만을 다루는 관리처럼 손쉬운 관리도 없다. 그러나 진정한 관리의 매력은 고객과 팀원과 섞여서 동료로서 대화하고 사람들이 가진 잠재능력을 이끌어 내어 좋은 결과로 마무리 될 때다. 결국 인간이란 천상천하유아독존이 아닌 이상 사람과 사람 사이에서 그 의미를 찾기 때문이다.

바로 이 책이 이러한 위대한 관리의 세계로 여러분을 안내할 것이다.

- 역자 서문

나는 애자일 게임 개발(Agile game development)이 (PC 및 콘솔을 포함한) 팩키지보다 온라인 게임에 더 없이 효과적이라고 생각한다.

그 이유는, 1) 수천, 수만이 접속해 있는 동안 무슨 일이 일어날지 모르기 때문에, '테스트'라는 명목으로 완성(혹은 가능성을 제거당하지 않은 채) 공개되며, 2) 사용자의 요구(혹은 개발자의 욕망)에 따라 끊임없이 변해가기 때문이다.

...

애자일(Agile)이란, 영어로 '민첩한' '재빠른'이라는 뜻을 가진 단어이며, 인터넷 업계에서는 경영 환경의 변화에 신속하게 대처할 수 있는 유연한 인터넷 서비스의 효율적인 시스템이나 개발 프로세스를 뜻한다.

...(중략)...

따라서 웹 1.0 시대의 '오랜 시간을 들여 개발한 소프트웨어를 장기간에 걸쳐 업데이트한다'라는 개발 스타일이 아니라, '비즈니스의 변화에 맞춰 오랜 기간 (소프트웨어가 아니라)서비스를 진화시킨다.' 라는 개발 스타일이 된 것이다.

서비스의 완성이라는 목표점이 없어졌기 때문에 사용자는 자신이 사용하고 있는 서비스의 버전 번호를 알고 있을 필요가 없어졌으며 버전 번호를 표시할 필요도 없어졌다. 이것이 '영원한 베타 버전' 이라고 블리는 이유가 된 것이다.

- 일본 하테나의 개발 방식은 웹 2.0 개발 스타일인 애자일 개발 스타일을 채택하고 있다. 하테나의 콘도 준야 사장은 자신의 블로그에서 '50% 정도의 완성도로 서비스를 내놓는다'라는 기사에 다음과 같이 이야기 하고 있다.

100% 에 도달하지 않은 시점에서 공개하는 편이 좋은 이유는 무엇인가? 첫 번째는 서비스는 가능한 한 빨리 출시하는 것이 유리하다는 점이 있다. 여러 사업자나 개인이 매일 같이 크리에이티브와 아이디어를 바탕으로 계속해서 새로운 서비스를 만들어내는 인터넷에서는 1개월, 2개월 늦어지는 것이 결정적인 실패 원인이 될 수도 있기 때문에 언제나 '출시가 빠르다는 것은 좋은 것이다.'라는 명제가 있다고 생각한다.

그러나 그것보다도 훨씬 중요한 것은 '만드는 사람의 상상력에는 한계가 있다'는 사실이다. 아무리 재미있는 장치를 생각해내고 다양한 사람의 입장에 서서 생각하는 작업을 잘 하는 사람이라 하더라도 한 서비스를 수십만 명이 이용할 때 그 안에서 어떤 일이 일어나고 어떤 기능이 필요해질지를 전부 예상할 수는 없는 일이다.

출처: 50%의 완성도로 서비스를 공개한다(일어 자동 번역), 강일석 PD의 기획 노트

City of Heroes와 City of Villans의 개발사인 Cryptic Studios가 자신들의 에니메이션 툴을 공개했습니다.

..
..

국내에서도 자료를 공개하는 회사들이 있었으면 좋겠네요.

안녕하세요, 동료 (게임) 개발자 여러분!


아래의 링크로 가셔서 "번역을 재청합니다."라는 내용의 글을 올려주시길 부탁드립니다:

• GITISS 지식 요청 게시판

애자일에 관한 좋은 자료들이 많으나, 저 혼자서 다 번역하기에는 무척 벅찹니다. 그런데 마침 GITISS에서 5월부터 Gamasutra와 Game Developer Magazone의 번역을 재개한다길래, 아래 글들을 번역을 요청했습니다:

• Scrum Rising(GDM 2007년 02월호)
• Embracing Fun: Why Extreme Programming is Great for Game Development
  
• Extreme Game Development: Right on Time, Every Time
  
• A Day in the Life: Noel Llopis, Senior Architect, Highmoon Studios (GDM의 Career Guide 2005)
  
• Paper Burns: Game Design With Agile Methodologies

(대신 저는 위의 글들을 제외한 다른 글들을 번역하려고 합니다.)


더불어 이 글을 여기저기에 뿌려주시거나, 링크를 보내주시는 방법으로 여기저기에 뿌려서 다른 분들도 동참하게 해주시면 정말 감사하겠습니다.

모두 힘을 모아서 좋은 자료를 얻어 BoA요! :)

프로젝트 매니져, 소프트웨어 엔지니어와 하드웨어 엔지니어가 요정을 만나면 과연 무슨 소원을 빌까?



ㅋㅋㅋ. 결국 프로젝트 매니져가 바라는 것은 프로젝트의 완수라는 사실!

*1: 세인트 토마스는 대서양과 카리브 해가 만나는 지점에 위치하는 미국령 버진 아일랜드의 섬들 중 하나로, 아주  카리브 해에서 가장 아름다운 곳 중 하나이다. 백문이 불여일견.

Firefox의 Blogger Web Comments라는 플러그인을 설치했다가 재미있는 글을 보고 추천해드립니다;

번역: 잔업과 그것이 출시에 미치는 영향
원문: Debt and the effects on releases

애자일 개임 개발의 p.27에서 언급된 "예측하지 못한 ‘완료되지 않은 작업들’이 누적될 수 있음. (Debt can sneak in.)"에 대한 훌륭한 주석이라고 될 거라는 생각이 듭니다.


P.S. Blogger Web Comments라는 게, (아마도 Google의 관련글 기능을 이용해서) 해당 페이지(혹은 사이트)에 대해서 블로거들이 무슨 이야기를 해놨는지 보여주는 건데, 의외로 재미가 쏠쏠하네요.