애자일 소프트웨어 개발은 90년대 후반에 시작되었다. 이 당시에는 Kent Beck이 소프트웨어 플래닝, 코딩, 디자인, 테스팅의 가치와 원리와 방법론을 통해 Extreme Programming (XP)을 선보였던 때이다. (Extreme Programming: A gentle introduction 참조)

모든 애자일 소프트웨어 개발 방식에는 여러 가치들이 있다:

• 잦은 검사와 적용
• 주기적인 배포
• 협업과 긴밀한 커뮤니케이션
• 반응적 향상
• (점증적인) 요구 사항, 기술, 팀 기능의 탄생
• 권한 부여와 자가 구성
• 인도물이 아닌 현재의 것 다루기
• 용기와 존경

오늘날 다양한 애자일 방식들은 각기 다른 방법들을 강조하고 있다.

2001년 2월, Agile Manifesto가 만들어지면서, 개인과 프로세스와 툴을 통한 인터랙션, 포괄적인 문서를 통한 소프트웨어 작동, 계약 협상을 통한 고객 협업, 플랜을 따르는 것 이상으로 변화에 대응하는 것 등에 가치가 매겨졌다. 이는 오늘날 사용되는 모든 애자일 방식의 토대가 된다.

먼저, 가장 일반적으로 사용되는 애자일 방식을 설명하고자 한다. 이들 중 많은 것들이 SOA 개발에도 유용하다. SOA는 소프트웨어 개발 그 이상이라는 것은 우리도 알고 있다. SOA는 비즈니스와 IT 아키텍처에 관한 것이기도 하다. 따라서 소프트웨어 개발 방식을 생각할 때면 언제나 이것이 SOA에 적합한지를 평가해야 한다. 적합성 평가에 대해서는 다음 시리즈에서 다루도록 하겠다.

Scrum

Scrum은 단순해 보이지만 작업에 영향을 주고 핵심적인 애자일 특징을 지닌 방식을 갖추고 있다. Scrum의 특징은 스스로 방향을 설정한 팀, 매일 매일의 팀 평가, 규정된 프로세스 지양이라는 특징이 있다. 다음은 Scrum의 기본적인 특징이다.

• 스스로 방향을 설정하고 구성한 팀
• 특별한 문제(무엇을 했는가, 무엇을 할 것인가, 문제가 무엇인가) 들을 주제로 한 매일 매일의 미팅
• 30일 주기 반복
• 매번 반복을 시작할 때 고객 위주의 적응성 플래닝
• (각 반복의 끝에) 스테이크홀더에 기능을 선보임

엔터프라이즈의 경우, 프로젝트 간 의존성을 이해하고 관리하는 것이 중요하다. 이것은 Scrum에서 "글로벌 백로그(global backlog)"를 통해 잘 관리되고 있다. 이는 사용자가 가치를 두고 있는 기능적 요구 사항과 비기능적 요구 사항을 엔터프라이즈 관점에서 본 것이다. 글로벌 백로그에서는 전체적인 우선순위가 정해진다. 각 프로젝트는 글로벌 백로그에서 자신들에게 가장 중요한 부분들을 취한다. 프로젝트 간 동기화 역시 Scrum of Scrums"에서 다루고 있다. 팀들간 동기화를 위해서 각 팀의 대표들과 이틀에 한번 또는 매주 미팅을 갖는다.

XP

XP (http://www.extremeprogramming.org와 http://www.xprogramming.com)는 협업, 빠른 소프트웨어 구현, 매우 기술적인 개발 방식을 강조한다. 이것은 주요 관행들(함께 앉기, 전체 팀, 정보가 풍부한 작업 공간, 짝(pair) 프로그래밍, 주간 반복, 여유, 10분 구현, 연속 반복, 테스트 우선 프로그래밍, 점증적인 디자인)과 부차적인 관행들(실제 고객 개입, 점증적인 전개, 뿌리 원인 분석, 공유 코드, 싱글 코드 기반, 협상된 범위 계약, 사용에 따른 비용 지불)로 구성된다.

Crystal

Crystal은 주기적인 인도(delivery), 긴밀한 통신, 반응적인 향상을 강조하는 방법론이다. Crystal의 특징은 다음과 같다:

• economic-cooperative game model
• 우선순위 선별
• 속성
• 원리
• 샘플 기술
• 프로젝트 예제

Crystal에서 우선순위는 프로젝트 결과의 안정성, 개발 효율성, 규율 지키기 등이다. 프로젝트 팀은 7 개의 특징을 지니고 있다. (첫 번째 세 개는 Crystal의 핵심이고, 다른 것들은 안정성을 위해 필요한 것들이다.):

• 잦은 검사와 적용
• 주기적인 배포
• 긴밀한 커뮤니케이션; 개인적인 안정성
• 포커스
• 전문 사용자들로의 쉬운 액세스
• 자동화된 테스팅을 갖춘 기술 환경
• 설정 관리
• 잦은 통합

Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM)는 시스템을 구현하고 관리하는 제어 프레임웍을 제공한다. 촉박한 시간 제약을 맞추고 반복적인 Rapid Application Development (RAD) 성공을 위한 방법을 제시한다. 이 방식은 개발자 관점의 RAD 뿐만 아니라 효과적인 시스템 개발에 관심이 있는 모든 사람들의 요구들을 포용한다. 아래 리스트는 DSDM의 관리 원리이다:

• 적극적인 사용자 개입이 필요하다.
• DSDM 팀은 결정을 내릴 수 있어야 한다.
• 목표는 제품의 주기적인 인도이다.
• 비즈니스 목적에 맞추는 것은 인도물의 필수 기준이다.
• 반복적이고 점증적인 개발은 정확한 비즈니스 솔루션으로 수렴되어야 한다.
• 개발 시 모든 변경 사항들은 원상으로 되돌릴 수 있어야 한다.
• 요구 사항들은 고급 레벨을 기반으로 우선순위가 정해져야 한다.
• 테스팅이 라이프 사이클에 통합된다.
• 모든 이해 관계자들간 협업이 필요하다.

출처: p. 24, Better Software (November, 2006)

작성: Clinton Keith

번역: 김기웅, Nikopole(교정), Khazad(교정)

SUPPORTING THE DISCIPLINES

서로 다른 분야들에 대한 지원

Agile을 적용하기 전에, 우리 프로젝트 팀들은 각각 일단의 프로그래머들, 기획자들, 아티스트들로 분리되어 있었다. 이것은 공통된 분야의 기술(shared disciplinary skills)을 갖고 있을 경우에는 훌륭한 방식이었으나, 게임이 정상적으로 돌아가도록 하는 간접 비용(the overhead)을 증가시켰다. 우리가 Agile을 적용했을 때, 이 점이 명확해졌고, 변화가 필요했다. 초반에 저항이 있었고, 이것이 결과적으로는 우리를 요소 제작팀들(feature teams)로 변화시켰다.

처음에 우리는 한 개의 특정 분야가 주도하는 여러 개의 “기능 제작팀들(functional teams)”을 구성했다. (예를 들어, AI 팀은 대부분 프로그래머로 이루어진다.) 몇 달 후, 문제들이 발생했다. AI 팀은 ‘진공 상태’[1]에서 자신들의 작업물을 만들었다. AI의 요구사항(requirements)이 실제 게임 내에서 개발되고 시험되기 보다는, AI를 사용하는 모든 팀들이 필요로 하는 아키텍처를 제공하는데 초점을 둔 프로그래머 위주의 팀에 의해 개발되었던 것이다. 따라서 매 주기가 끝날 때마다, 아키텍처는 진보했으나, 실제 게임에서의 활용도는 별로 증가하지는 않았다.

그 다음, 우리는 기능 제작팀들(functional teams)에서 “요소 제작팀들(feature teams)”로 변화해갔다. 요소 제작팀들(feature teams)은 사격이나 주행 메카닉과 같은 서로 다른 분야의 연계가 필요한 게임 플레이의 독립적인 한 부분(a vertical slice of game play)을 만드는데 초점을 맞추었다. 목표는, 게임 플레이의 독립적인 한 부분을 반복적으로 개발하는데 필요한, 개발의 모든 분야를 취급하는 자급자족적인 팀이다.

“요소 제작팀들(feature teams)”로 전환한 결과, 핵심 기술의 개발 노력이 분산되었다. 예를 들어, 우리는 하나의 기능별 조직이 전체 프로젝트를 위한 하나의 AI를 만드는 대신, 각 요소 제작팀들(feature team)의 한두 명이 각각 AI를 만들도록 했다. 이 조치는 여러가지 문제들을 일으켰는데, 우선적으로는 기술 개발이 분열되는 양상을 초래했다. 이런 방식은 다양한 가능성을 탐색하는 초기(early exploration)에는 좋을지 몰라도, 전적으로 문제가 많았다. 우리는 마치 별개의 게임을 만드는 것처럼 행동하고 있었지만, 결과적으로 우리가 전체 게임을 위한 단 하나의 AI 시스템이 필요하게 될 것이라는 것을 알았다. 또한 우리는 요소 제작팀들(feature teams)이 자원을 놓고 서로 경쟁하는 것을 목격했다. 이 방식은 모든 팀들이 전체 프로젝트의 일부분이라는 인식을 심어주지 못했다.

해결책은 추가로 각 전문 분야마다 가상의 팀들(virtual teams)을 조직하는 것이었다. 프로그래머들은 자신들의 Scrum Master[2] 한 명과 팀을 이루고, 그들은 일주일에 최소 한 번 이상 만나서, 팀의 기술적인 발전 방향을 논의했다. 프로그래밍 분야의 Scrum Master는 다른 분야(아트 및 기획)의 Scrum Master들과 만나서 게임의 비전을 창출한다. 이것은 각각의 분리된 팀들이 보다 효과적으로 의사 소통하도록 해줄 뿐만 아니라, 그들 모두가 최종 제품의 한 부분이라는 점을 인식시켰다.

DEVELOPMENT PHASES

개발 단계

Agile 게임 개발법은 폭포수(waterfall) 모형에서 제시된 프로젝트 단계들을 인정한다. 예를 들어서, 컨셉 발전 단계(the concept-development phase)에서는 고객이 창조적인 목표들을 전반적으로 그려볼(visualize) 수 있도록, 게임의 창조적인 가능성들과 한계들을 실험해본다. 개발 도중에는 게임 프로젝트의 가능성을 충분히 탐색하기가 불가능하다. 고객은 게임을 위한 라이센스와 함께 마케팅적인 척도나 요구사항들을 갖고 있을 것이며, 이것은 사전-시각화(pre-visualization)[3]와 원화(concept art)를 필요로 한다.

CRUNCH TIME

야근

SUMMARY

요약

우리는 Agile을 어떻게 비디오 게임 개발에 응용할 것인지를 계속해서 탐색해 보고자 한다. 대가는 크다. 진보된 방법론은 게임 가격이 합리적이 되도록, 개발비를 줄여준다. 또한 극소수만이 창조적인 도전을 기꺼이 받아들이고, 나머지 대부분은 위험을 무릅쓰려 하지 않는 추세(the increasing risk-averse trend)에 편승하지 않도록 도와준다. 현재 영화나 스포츠 라이센스를 기반으로 한 게임들과 성공적인 전작의 후속작들이 시장의 많은 부분을 차지하고 있다. 새로운 지적 재산이나 참신한 아이디어를 이용한 타이틀들을 개발하는 데, 막대한 돈을 투자하는 것은 너무 무모해 보일지도 모른다. 그러나 엔터테인먼트 산업에서 소비자의 돈과 관객의 관심은 더없이 소중하다. 비디오 게임의 전반적인 가치와 재미를 감소시키는 추세는 시장을 축소시켜서, 게임 산업의 모두에게 피해를 줄 것이다. Agile은 새로운 경험을 실험하고, 참신한 아이디어를 반복적으로 개발하여, 게임 속에서 재미를 빨리 그리고 자주 찾을 수 있도록 해주며, 우리의 고객을 즐겁게 하는 동시에 증가시키는, 보다 나은 길을 열어주는 체계(framework)를 제공할 것이다. {끝}

해당 주제에 대한 보다 자세한 정보를 원한다면, www.StickyMinds.com/bettersoftware에 들러볼 것.

l  사전 제작: 재미의 요소들(Pre-production: elements of fun)