사용자 스토리   by writely (2007/01/10)

왜 사용자 스토리? by writely (2007/02/12)

1. 기술이 너무 빨리 발전한다. (맞아!)
2. 개발자들은 언제나 최선을 다하고 싶어한다. (당연하지!)
3. 배급사들이 마음을 자주 바꾼다. (씨바!)
   

2. 개발자들은 언제나 최선을 다하고 싶어한다. 팀들은 언제나 최선을 다하고 싶어한다: 최고의 모델 제작, 최적화된 코드, 양질의 텍스처 제작 등. 이런 완벽에 대한 욕구는 동기부여의 매우 중요한 요소로 작용한다. 팀에게 최선의 실력을 발휘하도록 요구하지 않는 것은, 프로젝트를 망치는 지름길이라고 볼 수 있다.

결국 개발자들은 “개발이 완전히 완료된 후(only when it's done)”에 게임을 출시하는 것을 꿈꾼다. [다시 말해서] 자신들이 게임의 세세한 부분들 하나하나에 모두 자신감이 있을 때 말이다. 그러나 이런 완벽에 대한 집착은 일정을 지연시킬 수 있다. 내부 자금이 풍부한 곳[1]이 아닌 이상, 이런 엄격한 완벽주의를 갈망하며 지연된 일정을 감당할 수 있는 팀은 없다.

3. 배급사들은 마음을 자주 바꾼다. 새로운 기술에 당황하는 것은 개발자들만이 아니다; 배급사 역시 같은 경험을 한다. 제작자들은 새로운 그래픽 카드의 가능성들을, 보고 개발팀에게 이런 것들의 이점을 이용하라고 요구한다. 또한 배급사들은 콘솔 제조업체들에게 독점 출시권을 협상한다. 한편, 콘솔 제조업체들은 개발사들을 인수하여, 자신들의 하드웨어에 맞는 게임만을 만들도록 한다. 이러한 요소들은 게임 엔진 개발에 치명적인 악영향을 주며, 결국 일정 지연의 원인이 된다.

배급사들이 마음을 바꾸는데는 또 다른 이유가 있다. 게임이 대중 시장 제품(mass market products) 이므로 마케팅 부서가 (당연히) 배급사의 정책에 대해 영향력이 있다. 만약 경쟁사의 최근 타이틀이 성공을 거두었다면, 제작자에게 해당 게임의 핵심적인 특징들을 게임에 삽입하라고 요구할 수 있다.

출처: http://biz.gamedaily.com/industry/interview/bizarticles.asp?id=11418

작성: James Brightman

번역: 김기웅(Kay Kim)

일시: 2005년 12월 20일

[아직도] 많은 개발자들이 전통적인 게임 개발 방식에 갇혀있는 것으로 보인다. 그러나 개발비가 점점 더 상승하고, 게임이 복잡해짐에 따라, 새로운 대안이 필요한 것 같다. 최근 High Moon Studios를 비롯한 몇몇 개발사들은 Scrum이라고 불리는 새로운 접근법이 게임 개발에 적합하다는 사실을 발견했다. 이에 우리는 High Moon Studios의 기술 이사(Chief Technical Officer)인 Clinton Keith와 Scrum에 대해서 이야기를 나누어 보았다.

GameDAILY BIZ(이하 BIZ): 아마도 우리 독자들 대부분이 Agile Methodology이나 Scrum이라는 개념들과 친숙하지 않을 겁니다. 그것들의 유래는 무엇이고, 제품 개발에 있어서 이러한 접근법의 핵심이 무엇인지, 또 왜 그것이 특히 게임 개발에 적합하다고 생각하시는지 설명해주시겠습니까?

Clinton Keith(이하 CK): Agile Methodology는, 전형적인 개발 방법론과 다릅니다. 대량의 문서를 만들고, 기능들(features)을 추가하고, 개발 막바지에 가서야 그것들을 한데 엮는 방식 말이죠. 이러한 기존 방법론의 문제점은 프로젝트가 끝날 때까지 게임이 어떤 형태가 될지 알 수 없다는 것입니다. 반면 Agile Methodology는 다음에 해야 할 것을 끊임없이 계획함으로써, 게임을 반복적으로 개발하고, 결과(예를 들면, [사전에 예상치 못한] 실제 게임 플레이에서 새로 생겨난 [재미] 요소)에 대응할 수 있습니다.

BIZ: 저는 High Moon이 Darkwatch의 개발에 이 방법론을 처음으로 적용했다고 알고 있습니다. 사전에 계획된 것이었나요, 아니면 개발하는 중에 새로운 접근법이 필요하다고 결정하신 건가요?

CK: 저희는 Darkwatch를 개발하던 도중에 Scrum을 도입했습니다. 제가 High Moon에서 CTO의 역할을 맡은 직후였죠. 저는 Scrum과 또 다른 Agile 기법들 중의 하나인 XP로 프로그래밍 팀의 구조를 개편하려는 프로그래머들과 일했습니다. 저희 팀의 대부분은 앞서 말한 두 방법론들을 들어본 적이 있었고, 약간의 조사를 거친 끝에, Scrum이라면 손쉽게 적용할 수 있을 거라고 판단했습니다. 그 후에, 저희는 기획자들과 아티스트들을 이러한 절차에 끌어들일 체계(framework)를 개발했죠. Scrum은 Darkwatch의 일정을 관리하는데 도움을 주었지만, 우리가 Agile의 실천 사항(practices)을 사용해서 바닥에서부터 새로운 아이디어를 구축하기 시작하고 나서야, 비로소 Agile의 모든 혜택들을 누릴 수 있었습니다.

XP는 그 후에 도입했습니다. XP의 핵심은, 우리가 게임의 가치를 발견함에 따라서, [개발 도중에도] 소프트웨어를 변경할 수 있게 해주는 실천 사항들에 따라 소프트웨어를 개발하는 것입니다. 과거에 우리는 최종 코드(the final code)를 생성하기 위해서, 초반에 엄청나게 많은 기술 문서들이 필요했었죠. 불행히도 그런 문서들은 그다지 정확하지 않기 때문에, [나중에] 코드를 수정해야 합니다. 만약 XP의 실천 사항에 따라 쓰여지지 않았다면 정말 많은 문제를 일으킬 수도 있죠.

BIZ: Scrum은 주로 병목 현상과 불필요한 수고를 줄이는데 주요 초점을 맞추고 있는 것 같습니다. 개발비가 계속적으로 상승함에 따라, 효율성 향상이 게임 회사들에게 중대한 문제일지도 모르겠습니다. 차세대 [게임] 개발에 있어서 Scrum이 어떤 영향을 미치리라 생각하십니까?

CK: 맞는 이야기니다. Scrum은 [게임의 요소들을] 가시적으로 만들기 때문에, [그에 따라] 상식적인 결정을 내릴 수 있습니다. [또한] Scrum은 장애 요소들을 제거하고, 가치(value)를 일찍 생산하도록 해줍니다. 차세대 [게임] 개발비가 급상승함에 따라, 더 이상 우리는 될 대로 되라는 식(the hit or miss business model)으로 사업을 꾸려나갈 수 없습니다. 게임이 재미있는지 없는지 알기 위해서, 프로젝트가 막바지에 다다를 때까지 기다릴 수 없습니다. 엄청난 돈을 써버리고 난 뒤에는, 중요한 변화를 주기에는 너무 늦은 거죠.

BIZ: 일각에서는 올해 초 뉴스에 자주 등장한 삶의 질 문제(the quality of life issues)가 조악한 제작 관리 실천 사항(poor production practices)으로부터 비롯되었다고 지적합니다. 만약 Scrum을 사용하면 그 공포의 주당 100 시간(혹은 그 이상) 근무가 과거의 일이 될까요?

CK: Scrum은 매일의 실제 업무 능률이 어느 정도인가를 보여주는 경험적인 시스템입니다. Darkwatch 후반부에 우리는 철야 상태(crunch mode)에 돌입했고(과거의 버릇은 쉽게 사라지지 않죠.), 격렬했던 몇 주가 지나자, 작업 속도(velocity)[2]는 실제로 그 이전 수준으로 떨어져버렸습니다. 저희들은 야근(extended hours)이 몇 주나 지속되면 거의 쓸모가 없다는 걸 분명히 깨달았습니다.[3]

요즘도 때때로 한 팀이 자신들의 목표를 한 주기(iteration), 즉 Sprint의 시작에 맞추기 위해서 몇 시간씩 연장 근무를 하는 경우가 있습니다. 그러나 만약 그들이 너무 지나치게 오래 일하기 시작하면, 저희는 일부 업무를 다음 주기로 이전시킵니다. 그것은 Sprint가 제품 가치의 증가를 위한 것이지, 완료된 과업의 숫자를 말하는 게 아니기 때문입니다.

BIZ: Scrum은 팀 내의 의사 소통과 협력에 중점을 두고 있기 때문에, 품질 관리 부서(QA)의 부하가 무척 줄어들 거라고 생각합니다. 따라서 Scrum은 개발자들에게 유리할 뿐만 아니라, 고품질의 게임이라는 점에서 소비자들도 혜택이 돌아간다고 생각하는데, 맞습니까?

CK: 물론입니다. 저희는 실제로 하루 단위로 오류가 수정되도록 QA 테스터들을 개발팀에 통합시켰습니다. 오류 수정이 연기되면, 컨텐츠 생산도 지연되기 때문입니다. 다시 말해서, 아티스트들과 기획자들의 작업 능률이 떨어지면, 그들이 생산하는 컨텐츠의 양도 줄어들고, 그것은 결과적으로 최종 제품의 품질을 떨어뜨리는 거나 마찬가지죠.

-

BIZ: 잠재적인 혜택들을 고려해볼 때, 다른 게임 회사들도 Scrum을 채택할 거라고 생각하십니까?

CK: 작년 게임 개발자 컨퍼런스 [2004]에서 저희의 제작 현황(production track)을 강연한 이후로, 이미 많은 개발사들이 채택했습니다. 제가 강연에서 언급한 전통적인 개발 방법론의 문제들은 거의 어디서나 발생하고 있었고, Scrum은 대단히 상식적인 실천 사항들로 이루어져 있고, 기존 문제들의 해결을 위해 적용하는 것도 어렵지 않습니다. 저는 요즘 Agile을 도입하려는 개발자들을 위해서 메일링 리스트를 운영하고 있습니다.

BIZ: Scrum을 도입할 때, 주의해야만 하는 중요한 단점 같은 게 있을까요?

CK: [Scrum을 적용하는데] 가장 어려운 부분은, 명령하고 통제하는 관리 문화로부터, 팀의 주인 정신을 강조하는 주기적인 문화로 전환시키는 것입니다. 저와 같은 자리에 있는 사람들은, 팀원들에게 한 번에 30일 동안 스스로 자신들의 목표와 과업에 대한 통제권을 부여하는 걸 배우는데 어려움을 겪을 수 있습니다. 한편 팀원들은 Scrum이 요구하는 헌신과 주인 정신의 수준과 관련해서 책임감을 갖는다는 게 처음에는 어려울 수 있습니다. 하지만 팀원들이 한 번 거기에 익숙해지고 혜택을 누리기 시작하면, 순식간에 업무에 착수할 것입니다.

BIZ: 전통적인 개발 방법과 달리, Scrum은 관리자가 각 개인들에게 업무를 할당하는 것이 아니라, 팀원들에게 스스로 업무를 계획하도록 장려합니다. 하지만 이와 같은 부드러운 [즉, 꽉 막히고 딱딱하지 않는] 관리 방식이 오히려 역효과를 낼 수도 있지 않을까요?

CK: 물론, 그럴 수도 있습니다. 그래서 제 역할을 할 고객(customer)과 제품주(product owners)가 반드시 필요합니다. 매 주기(Sprint)마다, 팀원들은 비전과 게임의 창발된(emerging) 가치들을 정말로 이해하고, 다음 주기(Sprint)에서 가능한 최고의 가치를 생산하도록 목표들을 수립할 필요가 있습니다. 팀원들이 자신의 고객이 되었을 경우, 한 가지 문제가 있는데, 팀원들이 프로젝트 전체로 봤을 때에는, 최선이 아닌 방향으로 나아가기 시작한다는 것입니다. 이것이 저희가 컨설턴트들(예를 들면, Agile 코치들)을 때때로 초빙한 이유이며, 저희에게는 매우 중요한 사항이었습니다. 그들은 진짜 고객, 즉 스튜디오 관리자나 게임 배급사들을 교육시킬 뿐 아니라, 팀원들이 바른 길을 가도록 도와주었습니다.

BIZ: 당신은 일종의 Scrum 전도사가 되신 것 같은데, 맞습니까? 어떤 방법으로 개발자 사회에 Scrum을 전파하고 계십니까?

CK: 예, 저는 게임 산업 전체가 기로(crossroads)에 서있다고 굳게 믿고 있습니다. 우리는 시장을 더 나은 제품들로 채울 수 있고, 그 제품들을 성공시켜서 증가하는 개발비를 충당할 수 있을 겁니다. 그렇지 않으면, 우리는 계속해서 기존의 될 대로 되라는 식으로 사업을 운영하고, 이미 ‘증명된’ 제품들에서 파생된 게임들이나 특징들(features)에 의존하게 될 것입니다. Agile은 비밀이 아니며, [이미] 컴퓨터 소프트웨어와 소비자 전자산업과 같은 연구개발 중심의 산업들은 Agile을 통해서, 더 적은 시간과 더 적은 비용으로 더 나은 제품을 개발하고, 시장에 출시해왔습니다.

지난 몇 년 동안, 저는 Agile과 Scrum에 대한 강연을 해왔으며, GDC 2006에서 “게임 개발에서의 Agile 방법론: 3년째”라는 또 다른 강연을 할 예정입니다. 또한 www.agilegamedevelopment.com라는 제 웹사이트에서 메일링 리스트나 블로그를 운영하고 있습니다.

BIZ: 끝내기 전에, 마지막으로 하고 싶은 말씀이 있다면?

CK: 없습니다. 정말 멋진 인터뷰였네요!

BIZ: 감사합니다.