MIGS 2004에서, Noel Llopis가 발표한 "애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In The Real World)의 한글 슬라이드 http://betterways.tistory.com/139 참조.

1. 애자일 게임 개발 : 현실 세계의 혼돈을 다루는 법 ( Agile Game Development: Dealing with Chaos in the Real World ) 강연 : Noel Llopis, Lead Technical Architect, Sammy Studios [email_address] http://www.gamesfromwithin.com 2004 년 11 월 03 일 번역 : 김기웅 ( [email_address] ) http://betterways.wo.to 2007 년 05 월 31 일

2. 오늘의 주제는 ? Agile development 를 게임 개발에 응용하기 . 왜 ? Agile development 은 게임 산업에서 사용되는 대부분의 방법론들에 대한 좋은 대안이기 때문임 . 목차 : 제 1 부 : 위험과 방법론 ( Risk and methodologies) 제 2 부 : Agile development 제 3 부 : Scrum 제 4 부 : Extreme programming

3. 제 1 부 위험과 방법론 ( Risk and Methodologies)

4. 방법론이란 무엇인가 ? 개발 방법론이란 , 기업이 프로젝트를 개발하기 위해서 인력과 자원을 어떻게 조직하는가를 말한다 .

5. 위험과 방법론 방법론은 프로젝트의 위험을 감소시키는 것을 목표로 한다 . 어디에나 적용 가능한 최적의 방법론이란 존재하지 않으며 , 프로젝트와 팀에 따라 달라진다 .

6. 게임 산업에서 우리가 두려워 하는 것은 ?

7. 게임 산업에서 우리가 두려워 하는 것은 ? 일정이 지연되었다 ( 이런 , 성탄절을 놓쳤잖아 . )

8. 게임 산업에서 우리가 두려워 하는 것은 ? 일정이 지연되었다 . ( 이런 , 성탄절을 놓쳤잖아 . ) 프로젝트가 중단되었다 . ( 지금 겪고 계시려나 ? ) 넌 해고야 (You’re Fired)!

9. 게임 산업에서 우리가 두려워 하는 것은 ? 일정이 지연되었다 . ( 이런 , 성탄절을 놓쳤잖아 . ) 프로젝트가 중단되었다 . ( 지금 겪고 계시려나 ? ) 게임이 재미가 없다 . ( 저조한 실적과 나쁜 평가들 . )

10. 게임 산업에서 우리가 두려워 하는 것은 ? 일정이 지연되었다 . ( 이런 , 성탄절을 놓쳤잖아 . ) 프로젝트가 중단되었다 . ( 지금 겪고 계시려나 ? ) 게임이 재미가 없다 . ( 저조한 실적과 나쁜 평가들 . ) 기술적인 결함이 있거나 , 채택한 기술이 한물갔다 . ( 저조한 판매 실적과 나쁜 평가들 . )

11. 게임 산업에서 우리가 두려워 하는 것은 ? 일정이 지연되었다 . ( 이런 , 성탄절을 놓쳤잖아 . ) 프로젝트가 중단되었다 . ( 지금 겪고 계시려나 ? ) 게임이 재미가 없다 . ( 저조한 실적과 나쁜 평가들 ) 기술적인 결함이 있거나 , 채택한 기술이 한물갔다 . ( 저조한 실적과 나쁜 평가들 ) 시장 상황이 바뀌었다 . ( 우리 게임이 한물가버렸군 .)

12. 게임 산업에서 우리가 두려워 하는 것은 ? 일정이 지연되었다 . ( 이런 , 성탄절을 놓쳤잖아 . ) 프로젝트가 중단되었다 . ( 지금 겪고 계시려나 ? ) 게임이 재미가 없다 . ( 저조한 실적과 나쁜 평가들 ) 기술적인 결함이 있거나 , 채택한 기술이 한물갔다 . ( 저조한 실적과 나쁜 평가들 ) 시장 상황이 바뀌었다 . ( 우리 게임이 한물가버렸군 .) 팀원이 그만두었다 . ( 출시는 더욱더 늦어진다 .)

13. 어디서 많이 들어본 이야기죠 ? 게임 기획이 완료되었다 . 배급사와의 계약이 성사되었다 . 연관 관계에 따른 상세한 일정표를 작성했다 . 상세한 기술 설계가 만들어졌다 . 처음 몇 번의 마일스톤은 일정대로 흘러갔다 . 그러고 나자 ...

14. 어디서 많이 들어본 이야기죠 ? 전체 일정을 되돌릴 만큼 치명적인 기술적인 난관에 봉착했다… 또는 , 핵심 개발자가 그만두었다… 또는 , 개발하고 있는 장르를 재정의할만한 끝내주는 게임 (GTA3) 이 나와버렸다 ... 또는 , 배급사가 변경을 요구했다… 또는 , < 당신이 현재 겪고 있는 상황 .>

15. 어디서 많이 들어본 이야기죠 ? 그 다음에는 어떤 일들이 벌어질까 ? 쓰레기가 된 일정 . 연이은 철야 . 압박감 . 여기저기서 발생하는 오류들 . 품질 저하 . 팀원들이 탈진해버린 후 , 떠나버림 . .... 반드시 없어져야 할 악순환 .

16. 방법론 : 임기응변 ( Ad-hoc) 이걸로 정말 문제가 해결되기나 할까 ? 낮은 공정 유지비 ( Low process overhead). 저비용 . 당장은 일이 진행되게 해줌 . 매우 독립적이거나 / 이질적인 성격을 가진 사람들끼리도 자신들이 원하는 방법으로 일을 할 수 있게 해준다 . ( Allows very independent/different personalities to &quot;work&quot; however they want.)

17. 방법론 : 폭포수 ( Waterfall) 프로젝트 후반의 변경 사항을 최소화함 . 원래 고객이 원했던 바 그대로 개발하려고 함 . 임계 경로들 ( critical paths) 을 파악하고 , 개발 완료일을 예측하고자 함 . 가시성과 이력 파악 ( tracking) 을 극대화함 . 광범위한 문서화와 서류 더미 . “ 효율성 ( efficiency)“ 을 극대화함 .

18. 방법론 : 반복 ( Iterative) RUP (Rational Unified Programming), Evo (Evolutionary development) 매 주기마다 전달 가능한 버전을 계속적으로 만듦으로써 , 제품을 출시하지 못할 위험을 최소화함 . 잘 정의된 아키텍처 . 게임 개발이랑 많이 비슷하게 들리지만 , 정말 그럴까 ?

19. 제 2 장 Agile Development

20. Agile 기법들 Agile 에는 다양한 기법들이 존재한다 : Crystal Adaptive software development Dynamic solution delivery model Feature-driven development 그리고 E xtreme Programming 과 S crum .

21. Agile development 의 기본 원리 아마도 다음 도표가 눈에 익을 것이다 : 변경에 소요되는 비용 요구사항 작성 분석 및 설계 코딩 대규모 테스트 생산 시간

22. Agile development 는 대신 이걸 제안한다 : Agile development 의 기본 원리 변경에 소요되는 비용 시간

23. Agile 기법의 기초는 ? ( 공정과 도구보다 ) 개인과 상호 소통 ( 포괄적인 문서화 ) 제대로 동작하는 소프트웨어 ( 계약 협상보다 ) 고객과의 협력 ( 계획을 따르는 것보다 ) 변화에 대응하는 것

24. Agile Development 개인과 상호 소통 제대로 동작하는 소프트웨어 고객과의 협력 변화에 대응하는 것 일정 지연 프로젝트 취소 재미없는 게임 기술적인 난관 시장 변화 팀원의 이탈 특징 개발상의 공포

25. 무엇이 다를까 ? 전통적인 방법론 : “ 앞으로 어떤 일이 있을지 모르기 때문에 , 가능한 모든 것을 조사하고 , 모든 경우에 대비해 계획을 세워야만 한다 .” Agile: “ 우리는 바로 앞에 있는 것에만 집중할 것이며 , 지금까지 배운 것을 바탕으로 진행하면서 계속적으로 결정을 내릴 것이다 .”

26. 어떻게 가능할까 ? 신속한 피드백 . 사후 분석 (Postmortem) 을 기다리지 말 것 . 다양한 수준에서 즉각적인 피드백을 받는다 . 단위 검사 ( 수회 / 1 분 ) 구축과 기능 검사 ( 수회 /1 시간 ) 작업 상황 파악 및 일일 회의 (1 회 /1 일 ) 길이가 고정된 주기 ( 1 주기 / 몇주 )

27. 이것은 자동차 여행을 계획하는 것과 같다 .

28. 제 3 장 Scrum

29. Scrum 이란 ? 이게 아니다 !

30. Scrum 이란 ? Scrum 은 , 반복적이고 점진적인 실천 방법들 ( iterative, incremental practices) 을 사용하여 소프트웨어와 제품 개발을 관리하고 통제하는 , 기민하고 가벼운 공정 (an agile, lightweight process) 이다 . 중요 : Scrum 은 프로젝트 관리적인 측면 의 접근법 (a management approach) 의 일종이다 . 다른 반복적인 접근법과 함께 사용 가능하다 .

31. Scrum 의 주기 ( A scrum iteration) Product backlog 30 일 주기 (S print) 각 목표들의 우선순위 설정 작업의 예측 자율적인 팀 매일 팀의 상태를 측정 한 주기가 끝날 때마다 검토

32. 게임 개발에 Scrum 을 사용하는 회사는 ? Sammy Studios 는 6 개월 전부터 Darkwatch (PS2/Xbox 액션 게임 ) 에 Scrum 을 사용 .

33. 영국에 위치한 Awesome Studios (http://www.awesome.uk.com/). 다른 곳이 있다면 Email 로 알려 주십시요 . 게임 개발에 Scrum 을 사용하는 회사는 ?

34. Scrum 과 게임 개발 일반적으로 팀들이 너무 크다 . Scrum 은 5~8 명일 때 , 가장 효과가 좋다 . 팀을 더 작은 하위의 팀들 ( subteams) 로 쪼갠다 . “ Scrum 들로 구성된 Scrum(a scrum of scrums) ” 을 유지한다 . Sammy Studios 에서는 “기능 제작팀들 (functional teams)” 로 구분 : 캐릭터 , 탈 것 , 멀티플레이어 , 맵 제작 , 도구 등등 . 프로그래머들로만 시작했으나 , 현재는 아티스트들과 기획자들도 합류 .

35. 고객 ( the customer) 의 역할은 누가 하는가 ? 프로젝트 전반 : 기획 팀장 ( Lead designer) 혹은 기획 감독 ( creative director). 각 subteam 을 위한 고객을 선별한다 . Sammy Studios 에는 심지어 다른 모든 팀들을 고객으로 하는 “주기 전문 ( iteration)” 팀이 존재한다 . Scrum 과 게임 개발

36. 오류들 ( bugs) 을 어떻게 처리할 것인가 ? Scrum 에서는 오류에 대한 언급이 없다 . backlog tasks 에 포함시키거나 , 장애물 ( impedimen t) 로 취급하여 즉시 제거할 수도 있다 . Scrum 과 게임 개발

37. “ 상황실 (The war room)”

39. 소멸 차트 (A burn-down chart) : 매일 기록

40. 우리가 얻은 교훈들 Scrum 은 현재 공정의 결점들을 즉시 드러낸다 . 순식간에 반복적인 개발을 하게 된다 . (You're iterating very quickly.) 개발 진척도를 추적하는데 매우 유용하다 . 팀의 “속도 ( speed)” 를 측정할 수 있다 . 소멸 차트는 현황을 파악하게 해주는 더 없이 귀중한 자료가 된다 . 작업들 (tasks) 을 완료하기 위해 필요한 잔여 시간을 추정하라 . (Estimate _remaining_ hours left in tasks.)

41. 장애물 ( impediment) 을 보고하는 것은 중요하지만 , 매우 어렵다 . 아무런 장애물도 보고되지 않는 경우를 조심하라 . 모든 사람이 장애물을 수면 위로 끌어올리도록 장려 ( 혹은 강제 ) 하라 . 장애물이 없다는 것은 아마도 팀이 그 부분이 아직 Agile 을 충분히 시행하고 있지 않다는 것을 의미한다 . (Lack of impediments probably means lack of buy-in in the part of the teams.) 우리가 경험한 전형적인 장애물들 : 간밤에 빌드가 다시 엉망이 되었고 , PC 가 계속 다운되고 , 어떤 맵은 작업을 하기에 너무 느리고 등등 . 우리가 얻은 교훈들

42. 우리가 얻은 교훈들 팀들간의 상호 의존을 피한다 . 때때로 쉽지 않지만 , 한 주기 (Sprint) 에서 팀들끼리 상호의존하는 것은 피하라 . 그렇지 않으면 , 해당 팀이 자기 작업의 우선 순위를 매기거나 , 어떻게 처리할 것인가를 결정하는 게 매우 어려워진다 . 예 : 멀티플레이어 팀이 Xbox Live 메뉴를 추가하기 위해 프론트 - 엔드 ( front-end) 팀에 의존하는 경우 .

43. 제 4 장 Extreme Programming

44. + != XP

45. Extreme Programming(XP) 이란 무엇인가 ? Extreme Programming 은 소프트웨어 개발의 한 규범 ( a discipline ) 이며 , 다음 4 가지 가치들에 기초하고 있다 : 단순함 ( Simplicity) 의사소통 ( Communication) 피드백 ( Feedback) 용기 ( Courage)

46. 핵심적인 실천사항들 ( Core practices) 포괄적인 팀 계획 게임 작고 빈번한 출시 고객에 의한 테스트 단순한 설계 짝 프로그래밍 테스트 - 주도 개발 (TDD) 설계 개선 지속적인 통합 코드 공동 소유 코딩 표준 메타포 안정적인 속도

47. 뭐가 그렇게 극단적 (extreme) 이길래 ? 뭔가 효과가 좋다면 , 그걸 극단적으로 시행한다 . 코드를 상호 검토하는 게 ( Code review) 좋아 ? 그러면 항상 짝 프로그래밍을 해야지 . 잦은 통합이라고 ? 지속적인 통합을 하자 ! 테스트는 ? 모든 것에 단위 검사를 작성하고 , 구축을 할 때마다 테스트한다 .

48. XP 의 실천 사항들 각각의 실천 사항들이 다른 실천 사항들을 보완해준다 . 리팩토링은 단위 검사를 필요로 하고 , 짝 프로그래밍은 코딩 표준을 필요로 하고 , 단순한 설계는 리팩토링을 필요로 하고 , 등등 ... 일부만 골라서 채택하지 않도록 주의할 것 . 실천 사항들이 서로 조화와 균형을 이루도록 해야만 한다 .

49. XP 와 게임 개발 가능하냐고 ? 당연 ! 게임 개발이라고 소프트웨어 개발과 크게 다르지 않다 . 차이점은 그래픽 소스의 양 ( amount of binary assets) 일 따름이다 . 코드 / 데이터간의 상호작용은 신속한 기능 검사와 지속적인 통합에 장애가 될 수 있다 .

50. 짝 프로그래밍은 언제나 논란거리이다 . 게임 산업에는 각양각색의 전문가들이 존재한다 . “ 홀로 작업하는 천재 프로그래머들 (Prima Donnas)” 은 짝 프로그래밍을 좋아하지 않는다 . 짝 프로그래밍이 두 명이 따로 작업하는 것과 같은 속도를 내는가 ? 사실 그렇지는 않지만 , 품질은 더 좋다 . XP 와 게임 개발

51. TDD 는 어떻게 이루어지는가 ? 커다란 한 기능 ( a larger feature) 를 구성하는 작은 작업 (task) 을 구현할 필요가 있다 . 먼저 그 기능 ( feature) 을 사용하는 가장 간단한 테스트를 작성한다 . 테스트는 분명 실패하거나 심지어는 컴파일조차 되지 않을 것이다 . 이제 그 테스트를 통과하는 가장 간단한 코드 ( the simplest possible code) 를 작성한다 . 테스트를 리팩토링한다 . 불필요한 것을 제거하고 반복한다 . (Rinse and repeat.)

52. TDD 의 장점 4 가지 주요 장점들 : 필요하면 언제든지 리팩토링할 수 있다는 자신감 ( Confidence). 단위 검사로 어떤 문제든 즉시 잡아낸다 . 테스트 자체가 유효 기간이 없는 문서 (a documentation that is never out of date) 역할을 한다 . 결과 지향적인 설계를 다른 어떤 것들보다 효과적이다 !

53. Codebase 의 품질은 그것을 얼마나 쉽게 리팩토링 (refactor) 할 수 있냐에 달려있다 . 어떤 일이 일어날지 몰라 감히 코드를 수정하길 두려워한다면 , 그 codebase 는 죽은거나 다름없다 . 광범위한 단위 검사는 불상사를 예방한다 . ( Extensive unit tests prevent that from ever happening.) TDD 의 장점

54. TDD 를 게임 개발에 적용하기 어떻게 테스트 - 주도 개발을 게임 개발에 적용할 수 있을까 ? 한 번에 하나씩 개발하고 테스트한다 . 이게 단위 검사라는 것을 명심할 것 . 그래픽과 전혀 관련 없는 것들 대부분을 테스트한다 . 고도로 모듈화된 라이브러리를 구축해서 , 오직 필요한 것만 가져다가 사용한다 .

55. TDD 를 실행하라 유니트 - 테스팅 프레임워크를 사용한다 . 새로운 테스트를 추가하기 정말 쉬워야 한다 . 코드가 컴파일되자 마자 테스트가 구축되고 실행되어야 한다 . 테스트는 매우 빨리 실행한다 . C++ 의 경우 , CppUnitLite 를 체크 아웃한다 . ( 또한 CppUnit 와 Boost Test Framework 를 펴볼 것 .)

56. 게임에 TDD 를 적용하자 작업 (Task) : HP 회복약 위로 걸어가기 . TEST (HealthPowerup, AddsHealth) { Player player; // Created at the origin HealthPowerup powerup; // same here int beforeHealth = player.GetHealth(); player.Update(); CHECK (player.GetHealth() > beforeHealth); }

57. 게임에 TDD 를 적용하자 TEST (HealthPowerup, AddsCorrectAmountOfHealth) { Player player; // Created at the origin HealthPowerup powerup; // same here int beforeHealth = player.GetHealth(); player.Update(); CHECK_INT_EQUALS (player.GetHealth() == beforeHealth + powerup.GetHealthAmount()); } 중복된 코드가 너무 많음 : 리팩토링할 것 !

58. 게임에 TDD 를 적용하자 SETUP (HealthPowerup) { Player player; // Created at the origin HealthPowerup powerup; // same here int beforeHealth = player.GetHealth(); player.Update(); } TEST (HealthPowerup, AddsHealth) { CHECK (player.GetHealth() > beforeHealth); } TEST (HealthPowerup, AddsCorrectAmountOfHealth) { CHECK_INT_EQUALS (player.GetHealth() == beforeHealth + powerup.GetHealthAmount()); } TEARDOWN (HealthPowerup) { }

59. 게임에 TDD 를 적용하자 최대값 이상의 HP 를 획득하지 않는지 확인한다 . HP 회복약이 사라지는지 확인한다 . PC 가 회복약 근처에 있을 경우에만 작동하는지 확인한다 . 등등 ...

60. 게임에 TDD 를 적용하자 그러면 그래픽은 ? 대부분의 개발자들은 pixel 수준의 것을 테스트할 필요가 없다 . 렌더러 계층과 하드웨어 사이의 통신을 테스트한다 .

61. 게임에 TDD 를 적용하자 AI 의 경우는 ? 이것은 단위 검사이지 , 기능 검사가 아님 . 예 : ‘ 캐릭터가 총에 맞아서 HP 가 매우 낮아지면 , 엄폐물을 찾는다 .’ 여러 가지 작업들이 관련되어 있지만 , 각각 따로 테스트한다 . 총에 맞았을 때 , HP 가 감소해야 한다 . HP 가 특정 수준 이하가 되면 , flag 들이 켜진다 . 총에 맞아서 , HP 가 낮아지면 , 엄폐물을 찾는다 . 엄폐 탐색 상태가 되면 , 엄폐물로 가는 적합한 경로 ( the right path nodes) 를 찾는다 .

62. TDD 요령 구축을 할 때마다 테스트가 시행되도록 한다 . 오류가 나타나면 , 먼저 그 오류를 검출할 테스트 (a test that fails because of the bug) 를 작성한 다음 , 오류를 고친다 . 단위 검사가 코드의 50~75% 를 차지하더라도 놀라지 마라 . 시간이나 코드의 낭비가 아니다 . 오히려 단위 검사가 잘 쓰여지고 리팩토링하기 쉬운 것이 중요하다 . 코드가 단위 검사를 많이 포함할수록 , 리팩토링하기가 더욱 쉬워진다 .

63. 지속적인 통합 하나의 작업이 완료될 때마다 몇 번씩 , 시스템을 통합하고 구축하라 . 그래픽 자원 (asset) 을 구축하는 것은 오랜 시간이 들기 때문에 , 데이터 주도형 (data-driven) 게임들에서는 조금 힘들 수 있다 . 코드를 제출하기 (commit) 전에 , 변경한 것들이 제대로 작동하는지 확인하고 싶어할 것이다 . 단위 검사는 시작에 불과하며 , 아마도 몇 번의 간단한 기능 검사도 필요할 것이다 . 이것은 추구할만한 가치가 있는 위대한 목표이다 . 단 , 여러 분기점들 (branches) 에서 동시 개발하는 경우에는 좀 괴로울 것이다 .

64. 정리 ( Wrap Up)

65. Agile development 를 시작하기 처음부터 Agile 을 입맛에 맞게 뜯어고치고 싶은 유혹을 떨쳐버려라 . 먼저 Scrum, XP 혹은 원하는 다른 기법부터 시작하고 , 그것을 그대로 따른다 . 실천 사항들 중 어떤 것이 효과가 있고 , 어떤 것이 효과가 없는지 확실해진 다음에 , 자신의 팀에 맞게 고친다 .

66. Agile development 를 시작하기 배급사를 합류시키는 것이 어려울 수도 있다 . 배급사를 이해시키고 , 그들을 고객으로 받아들인다 . 프로젝트에 대해서 여러 가지 의견을 갖고 있을 테고 , 그것은 어쨌든 프로젝트에 도움이 될 것이다 . 만약 이 모든 시도들이 실패한다면 , Agile development 를 이해하는 새로운 배급사를 물색한다 .

67. 참고 자료 필독서 : Agile and Iterative Development , Craig Larman Agile Software Development with Scrum , Ken Schwaber 익스트림 프로그래밍 , Kent Beck, 김창준 역 추천서 : Questioning Extreme Programming , Pete McBreen Refactoring , Martin Fowler, 윤성준 역 테스트 주도 개발 , Kent Beck, 김창준 역 소프트웨어 프로젝트에서의 리스크 관리 , Tom DeMarco, 김준식 역

68. 참고 자료 웹 사이트 : Control Chaos ( http://www.controlchaos.com ). Scrum 에 관한 웹 사이트 . Mountain Goat Software ( http://www.mountaingoatsoftware.com/scrum/index.php ). Scrum 에 대한 추가 정보 . Extreme Programming: A Gentle Introduction ( http://www.extremeprogramming.org ) Extreme Programming Resources ( http://www.xprogramming.com ) Agile development 와 게임 : Agile Methodology 와 Scrum 을 이용한 게임 개발 . Clinton Keith (Sammy Studios 의 기술 이사 ) 의 GDC 2005 강연 .

69. 질문 ? 이 슬라이드는 다음의 주소에서 찾을 수 있습니다 : http://www.gamesfromwithin.com 오역이나 수정에 대한 의견은 아래의 주소로 언제든지 연락주십시요 : [email_address]