게임 개발에서의 Agile에 대한 고찰

목차

1. Agile이란 무엇인가?

2. Agile의 방법론

3. Agile 게임 개발의 어려움

4. Agile 게임개발 방법

서론

최근 개발 부분에서 화두로 떠오르는 단어가 Agile 방법론이다. 이러한 상황에서 Agile 방법론이 무엇인지 알아보고, 어떻게 게임 개발에 적용시킬 수 있을지에 대해 알아보도록 하겠다.

 

Agile이란 무엇인가?

Agile한 개발은 무엇일까? Agile 방법론에서는 소프트웨어 개발을 하는 데에 있어서 기존에 중요하게 여겨지는 것과는 다른 4개의 기준을 제시한다.

Agile Manifesto

1.     공정과 도구보다 개인의 상호작용을.

2.     포괄적인 문서보다 작동하는 소프트웨어를

3.     계약 협상보다 고객과의 협력을

4.     계획을 따르기 보다 변화에 대응하기를

전체적으로 기존의 Waterfall 방식과 달리 애초에 변화하는 상황을 가정하고 있고, 변화하는 상황에 적절히 대응하기 위한 방법에 대한 내용을 담고 있다.

 

또한 대부분의 Agile 방법론에서는 이러한 기준에 맞추어 다음의 행동 양식을 제공한다.

1.     고객을 만족시켜라 : 가치 있는 소프트웨어를 초기부터 계속 제공해서 고객을 만족시켜라

2.     변화를 즐겨라 : 변화를 즉각적으로 수용하고 경쟁력을 늘려라

3.     자주 배포하라 : 2주~2달 이하의 짧은 주기로 소프트웨어를 배포하라

4.     매일 협력하라 : 비즈니스 담당자와 개발자는 전체기간동안 매일 함께 일해야 한다.

5.     동기 부여된 팀원들로 구성하라 : 프로젝트를 동기 부여된 팀원들로 구성하고, 그들에게 필요한 환경조성, 지원하라. 그리고 그 팀을 믿어라.

6.     얼굴보고 대화하라 : 개발팀에 정보를 전하는 가장 효율적이고 효과적인 방법은 대면 대화이다.

7.     동작되는 소프트웨어로 진도를 측정하라 : 작동하는 소프트웨어만을 진척도 생각하라.

8.     지속가능한 개발속도를 유지하라 : 일정한 속도를 유지하여 개발을 지속가능 하게 하라.

9.     좋은 기술과 설계에 관심을 가져라 : 우수한 기술과 디자인에 대한 지속적 관심은 민첩성(agility)를 향상시킨다.

10.  단순화하라 : 단순성(수행하지 않은 일을 최대화하는 기술)은 필수적이다

11.  자기조직화 팀을 구성하라 : 스스로 구성된 팀에서 의사결정이 더 원활하며, 이러한 팀에서 최고의 아키텍쳐, 요구사항 및 디자인이 나온다.

12.  정기적으로 효율성을 제고하라 : 더 효과적인 방법이 어떤 것이 있을지 생각하고 자주 적용하라.

Agile의 방법론

 Agile이 변화하는 상황과, 그에 대처하기 위한 방법이라면, 어떻게 이걸 실현할 수 있을까? 이에 대한 노력은 Agile 개발방법론이 나오기 이전부터 있었다.

1.     Extreme programming

Extreme Programming Process

XP의 12가지 실천사항:

·         Fine scale feedback

o    Pair Programming: 하나의 작업을 2명의 프로그래머가 코딩·리뷰 공동 수행

o    Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획 수행

o    Test Driven Development: 선 단위 테스트후 실제 코드 작성

o    Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주

·         Continuous process

o    Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지

o    Design Improvement: 코드 개선 작업 수행(가시성, 성능 등), 불필요한 기능 제거 및 리팩토링

o    Small Releases: 짧고 잦은 릴리즈로 고객이 변경사항을 볼 수 있게 함 → 잦은 피드백

·         Shared understanding

o    Coding Standards: 표준화된 관례에 따라 코드 작성

o    Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 가능

o    Simple Design: 가능한 가장 간결한 디자인 상태 유지

o    System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 조망

·         Programmer welfare

o    Sustainable Pace: 오버타임 지양

출처 : http://wiki.c2.com/?ExtremeProgrammingCorePractices

-다른 Agile 방법론과 다른 점

익스트림 프로그래밍은 켄트 백 등이 제안한 소프트웨어 개발방법으로, 다른 애자일 방법론과 구분되는 부분으로는 테스팅이 있다. 코딩을 할때부터 테스트코드를 작성하게 함으로써 테스트기반으로 프로그래밍을 하게 한다.

이러한 특징이 잘 드러나는 부분이 Pair programming과 Test-Driven Developement이다. Pair programming에서는 2명의 프로그래머가 코딩/테스트를 서로 진행한 뒤 역할을 바꿔서 서로의 코드를 리뷰하는 방법으로 진행한다. Test-Driven Programming에서는 테스트 테이스를 먼저 작성 후 자신이 할 일을 파악하고 개발한다.

‑특징

특이한 점으로는 XP(Extreme Programming의 약자)에서는 팀의 구성원에 아예 고객을 포함시키고 있다. 팀원과 소통하는 것을 중요시하는 XP를 생각해보면, 팀원과 의사소통하는 만큼 고객과도 소통하라는 이야기인 것 같다. 또한 Planning-Game과 Sustainable Pace에서 볼 수 있듯 개발과정 자체에서 프로그래머가 느낄 수 있는 생각까지도 고려하고있다.

 

2.    SCRUM

Scrum 진행과정

-스크럼 진행 과정

1. 제품 백로그(Product Backlog)작성 : 개발할 제품에 대한 요구사항 목록 작성

2. 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 백로그를 계획하는 회의

3. 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 회의

4. 스프린트(Sprint) : 반복 개발 주기

5. 일일 스크럼 회의(Daily Scrum Meeting) : 어제 한 일, 오늘 할 일, 이슈 등을 공유하는 회의

 

-스크럼 직책

- 제품 책임자(Product Owner, PO) : 제품 백로그 정의, 우선순위 설정, 스프린트 목표설정에 주로 관여

- 스크럼 마스터(Scrum Master) : 팀원 코칭 및 프로젝트 문제상황 해결하는 역할, 팀 의사 결정 및 팀을 위한 자원 획득, 팀원 격려등도 같이 맡는다.

 

-스크럼 특징

 스크럼의 특징은 데일리 스탠드업 미팅(Daily standup Meeting)이다. 매일 모여서 간단한 회의를 함으로써 그날과 다음 스크럼에 무엇을 해야 할지 명확하게 알 수 있게 된다. 이 과정은 Scrum Master에 의해 공유되고, 다음 스크럼에 반영된다.

 

3.    Kanban

Kanban

칸반은 각각의 작업을 카드로 표현하고, 할일/하고있는일/테스트할일/한일 등으로 구성되어있다. 사용 방법은 화이트보드에 포스트잇을 붙이는 것과 같다.

-칸반 특징

칸반에서는 각각의 열에 포함할 수 있는 최대 카드 수를 설정해두어서 너무 많은 양의 작업을 동시에 진행하지 못하도록 하고있다.

 

 

Agile 게임 개발의 어려움

 

그렇다면 Agile 개발 프로세스를 게임 개발에도 적용할 수 있을까? 결론부터 이야기 하자면 애자일 개발방법을 그대로 적용하기는 어렵다. 그러면 어떤 점 때문에 게임 개발에 Agile 프로세스를 적용하기 어려운지와 해결 방법에 대해 이야기해보겠다.

 

-       게임 서비스의 특징

게임 서비스는 그 특성상 서비스보다는 컨텐츠로써 소모되는 경우가 많고, 컨텐츠의 특성이 반영되는 경우가 많다. 따라서 게임 서비스는 아래와 같은 특징을 갖는다.

1.     모든 고객을 만족시키기 위해 존재하지 않는다.

게임은 장르별로 고정된 수요층이 있으며, 그들이 원하는 Feature는 거의 고정되어있는 편이다. 세부적으로 나뉘는 부분은 Feature의 구현 방법, 그 Feature를 어떻게 풀어냈는가, Feature에서 어떤 색다른 경험을 줄 수 있는가 정도이다.

2.     요구사항이 거의 변하지 않는다.

1번의 연장선상으로, 특정 고객을 만족시키기 위해 존재하므로, 애초에 개발이 엎어지지 않는 이상 요구사항이 변하는 경우는 많지 않다.

3.     출시 초기가 매우 중요하다.

게임은 여타 다른 컨텐츠와 같이, 입소문과 평점에 많은 영향을 받는다. 간단한 예로  No man’s sky가 있을 수 있다. 출시 이전 많은 기대와 관심을 받았지만 막상 출시되었을 때 기대한 내용과 다른 내용으로 인해 부정적인 평가를 많이 받았다. 지속적인 개선을 통해 현재는 좋은 평가를 받고 있지만, 출시 초기의 부정적 이미지는 완전히 해소되지 못했다.

4.     변화하는 시스템에 대해 부정적이다.

플레이어는 게임 속 세상에 몰입하고, 즐거움을 얻는다. 하지만 이러한 몰입을 Feature의 변화로 깨트리게 된다면 플레이어는 부정적인 경험을 하게 될 것이다. 특히나 이런 현상은 보상 체계에서 많이 발생하는데, 특정 수준에 도달해야 얻을 수 있는 보상을 짧은 주기 단위로 변경하게 된다면 보상에 대한 동기가 사라지게 된다.

 

-      이로 인한 문제점

위와 같은 문제로 Agile한 개발에서 중요하게 여기는 민첩성(agility)이 발휘되기 어렵다. 변화한 Feature와 고객의 상호작용 변수로 인해 고객의 요구에 민첩하게 반응할수록 게임 전반에 걸친 문제(경제 문제, 밸런스 문제, 보상 체계 문제, 컨텐츠 소모 문제)가 발생할 수도 있다. 또한 직접 테스트를 해보기 어려운 부분에 대해서는 배포를 통해 데이터를 모아야 하는데, 이는 사실상 출시를 하는것과 다를 것이 없다는 문제가 있다.

 

 

Agile 게임 개발 방법

 그렇다면 게임 업계에서는 모든 프로세스를 Waterfall 방식으로 진행하고 있을까? 그렇지 않다. 위의 문제점을 해결하고, 절충안을 제시해서 실행한 사례를 예를들어 설명하겠다.

-Agile / Waterfall 하이브리드 개발방법

앞서 이야기 한 문제점들을 해결하기 위해 게임업계는 하이브리드 방식을 사용하기도 한다. 기본적인 틀은 Waterfall 방식으로 진행하되, 세부적인 사항에 대해서는 Agile 방식을 적용하는 식이다. 예를 들어 온라인 게임을 개발한다고 하면, 게임이 플레이가능한 수준까지 만들어질 때 까지는 Waterfall 방식으로 진행을 하고, 이후 컨텐츠 업데이트의 과정은 Agile으로 진행되는 식이다. 이러한 방식은 밸런스를 잡는데 사용하기 매우 좋다. 게임의 컨텐츠와는 별개로 밸런스는 실제 데이터와 플레이어 실력을 확인 후 조정해야 하는 부분이기 때문에 Feature 리메이크 등은 이런 방 introverts식으로 이루어진다.

 

 

Agile을 이용해 개발한 게임

League of Legends 개발사인 Riot Games

-       League of Legend

Riot Games 에서는 기존에 스크럼을 활용하던 기업이었다. 그러나 역할에 대한 이해 차이, 욕구에맞지않는 역할, 개별리더에 대한 의존성, 공동 소유권의식 저하 등의 이유로 새로운 Agile 방법이 필요했다. 이에 Riot Games는 새로운 용어인 Lead를 역할로 도입해서 개발을 진행했다. 다음은 Riot Games에서 제시한 새로운 역할이다.

-       Team Captain : 전반적 노력 주도

-       Product Lead : 관중(고객)과의 공명(소통), 제품 전략 주도

-       Delivery Lead : Delivery 와 실행을 주도

-       Craft Lead : 기술 지도와 특정 제작 분야 주도

특히 Riot Games 에서는 이러한 역할을 “Hat”이라고 명명하고, 한 개 이상의 모자를 착용할 수 있게 했다. 또한 역할과 책임을 분리하여 기술과 열정에 관계없이 책임을 지우는 것이 아니라 개개인의 능력이 다름을 인정하였다. 이를 통해 “성장 가능한 마인드셋을 가진” 직원과 책임을 협상하여 스스로를 확장하고 개발할 수 있는 장소와 기회를 제공했다. 이는 36가지의 일반적 책임목록을 작성하고, 11개는 특정 역할에 고정, 나머지 25개는 팀에게 맡김으로써 실행된다.

 이를 2015년도부터 2017년도까지 실행한 결과, 리더십 팀워크, 성장의 기회, 투명성 증가, 인식과 감사활성화 등의 결과를 가져왔다.

 또한 이런 역할 분배 분야 뿐만 아니라 캐릭터 추가에 관한 내용에서도 Scrum을 활용하여

스프린트 계획-> 스탠드업 미팅 -> 피드백 리뷰 (스프린트 검토/ 플레이테스트/ 평가 검토) -> Retros(추가 설명이 없어 확실하지 않지만 프로세스 개선을 위해 스프린트마다 실행됨)

의 형태로 진행한다.

출처:

https://www.riotgames.com/en/work-with-us/disciplines/dev-management/dont-go-chasing-waterfall-using-agile-methods-in-creative-development