birdkr's home

게임을 개발하는 과정도 이런 도전의 연속이다. 기획은 수시로 바뀌고 대부분은 실제로 구현해봐야 재미있는지 알 수 있으며, 수많은 기술적 난관과도 싸워야 한다. 애자일 방법론은 이렇게 프로젝트를 개발하는 동안 끊임없이 닥치는 요구와 도전들에 빠르게 반응하고 해결하고자 기존의 전통적인 계획 기반 방법론의 대안으로 나타나게 되었다.

애자일 방법론은 어느 특정한 방법을 말하는 것이 아니다. ‘애자일(Agile, 기민한)’, 즉 좋은 것을 빠르고 낭비 없이 개발할 수 있게 해주는 다양한 방법론을 일컫는 말이다. 애자일을 이해하려면 우선 애자일을 주창하고 실천해온 선구자들이 모여서 작성한 ‘애자일 선언문(http://agilemanifesto.org)’을 보는 것이 좋을 것이다. 애자일 선언문의 내용은 다음과 같다.

“우리는 직접 개발하면서 혹은 남이 개발하는 일을 도와주면서 소프트웨어 개발에 있어서 더 나은 방법을 발견하고 있다. 이 과정을 통해 우리는 다음의 것들을 가치 있게 여기게 되었다. ▲‘ 프로세스와 도구’보다는 ‘개인과 상호작용’을 ▲‘포괄적인 문서화’보다는 ‘동작하는 소프트웨어’를 ▲‘계약 협상’보다는 ‘고객과의 협력’을 ▲‘계획을 따르는 것’보다는 ‘변화에 대응’를. 이 말은 왼쪽에 있는 것들에도 가치가 있긴 하지만, 우리는 오른쪽에 있는 것들에 더 많은 가치를 둔다는 것이다.”

선언문은 기존의 가치도 중요하지만 그것에 집착하기 보다는 더 중요한 ‘사람’ ‘동작하는 소프트웨어’ ‘협력’ ‘변화에 대응’ 등 새로운 가치에 집중하기를 강조한다.

프로세스와 도구는 개인간의 의사 소통을 원활하게 하기 위해 사용되어야 하고, 문서만 만들다가 실제로 동작하는 게임의 완성도를 떨어뜨리면 안된다. 퍼블리셔와 계약 협상을 신경 쓰다가 유저의 목소리에 귀를 기울이지는 않는지, 프로젝트를 진행하다 예상치 못한 문제나 변화가 생겼을 때 얼마나 가치있게 적절히 대응하는지 등 프로젝트를 진행하는 과정 내내 지속적으로 앞서 말한 가치를 신경써야 한다.

애자일 방법론에는 ‘익스트림 프로그래밍’ ‘스크럼’ ‘크리스탈 클리어’ 등 여러 가지 개발 방법이 있고 또 각각의 방법마다 특징이나 실천 방법이 다르지만, 여기서는 여러 방법 중에 여러분의 팀에서 바로 차용하여 사용해볼 수 있는 몇가지 실천 방법들을 소개해 본다.

◇ 짧은 이터레이션

소프트웨어 개발 방식 중에 빅뱅(Big Bang) 방식이라는 것이 있다. 프로젝트가 시작되면 개발자들이 뚝딱뚝딱 뭔가 많은 작업을 해 한참 시간이 흐른 후 뭔가 크고 복잡한 게 ‘펑!’ 하면서 한번에 나오는 걸 말한다. 이런 빅뱅 방식으로 게임을 개발하게 되면 프로젝트 또는 마일스톤이 끝날 때까지 어떤 결과물이 나올지 예측할 수 없고, 만약 안좋은 결과가 나왔을 때에는 이미 너무 늦게 깨닫게 된다. 또 이렇게 개발하다 보면 보통 통합이나 테스트가 뒤로 미뤄져 막바지에 수없이 튀어나오는 버그와 싸우며 밤을 지새우기도 한다.

▲ 온전한 개발프로세스의 무한 반복

애자일은 반복적이고 점진적으로 개발하는 프로세스다. 게임의 기능을 몇 개의 작은 단위로 나눠 반복적으로 개발해 나간다. 반복적으로 개발하는 이런 단계를 ‘이터레이션(iteration)’이라 부르는데 한 이터레이션 안에는 다양한 개발 작업, 즉 요구사항, 설계, 코딩, 통합, 테스트, 피드백 구하기 등의 과정이 온전히 모두 들어있어야 한다.

그래서 이터레이션의 마지막에는 테스트까지 끝나 실제 동작이 가능한 모습의 게임을 볼 수 있게 된다. 매번 이터레이션이 끝날 때마다 개발한 것이 기획자나 디렉터의 요구사항에 맞는지 체크하기 때문에 디렉터가 원하는 재미있는 게임이 만들어질 확률이 높아진다. 이터레이션은 원하는 게임을 제대로 만들고 있는지 자주 점검하는 것과 같아서 항상 어떻게 일이 진행되는지 알 수 있다.

▲ 기간은 짧지도 길지도 않게

이터레이션의 길이는 해당 프로젝트에 적절한 기간이어야 한다. 보통 1주에서 4주 정도로 설정하는데 처음에 시도할때는 한달 정도로 기간을 잡아서 프로젝트를 진행해보고 각 팀에 맞게 더 길거나 짧게 수정해서 결정하면 된다. 만약 이터레이션을 진행하면서 처음에 계획한 목표에서 자주 벗어나게 된다면 이터레이션을 더 짧게 잡는 것이 좋다.

그러나 너무 짧으면 이터레이션의 끝을 준비하는데 많은 시간을 쓰게 되므로 이터레이션 길이를 결정할 때에는 이런 요소를 고려해야 한다. 참고로 필자의 팀의 경우에는 이터레이션을 2주로 잡고 진행하고 있다.

▲ 가시화된 목표로 추진력 ‘배가’

짧은 이터레이션은 목표가 명확하게 가시적으로 보여지기 때문에 개발자가 계속 집중하는데도 도움이 된다. 프로젝트 완료까지 1년이 남았다는 말을 들으면 마음속으로는 먼 훗날의 일로 생각한다. 그렇게 목표가 멀리 떨어져 있으면 집중할 때 필요한 추진력을 갖기 어렵다.

짧은 이터레이션을 설정해 개발과정이 아주 집중적이고 생산적으로 진행돼야 한다. 확실하고 잘 정의된 목표가 보이고, 그 목표에 도달해야 한다. 마감이 확실하면 결정이 확고해지므로 어떤 쟁점이든지 해결하지 못하거나 결정하지 못한 상태로 오래 놔두지 않게 된다.

◇ 스탠드 업 미팅

프로젝트의 성공은 팀원들이 얼마나 효율적으로 상호 협력하며 함께 일하는지, 팀원이 자신의 일을 어떻게 관리하는지에 달려 있다. 모든 팀원의 행동은 프로젝트의 정황과 관련되어야 하고 반대로 각 개인의 행동은 프로젝트 상황에 영향을 준다. 효과적인 협력은 게임 개발의 초석이며, 스탠드 업 미팅은 팀을 모으고 모든 사람에게 정보를 제공하는 효과적인 방법이다.

▲ 집중도 높이는 데 최적

스탠드 업 미팅은 이름이 말해주듯이 앉지 않고 함께 모여 일어서서 하는 회의이다. 앉으면 너무나 편안하기 때문에 중간중간 주제와 상관없는 다른 이야기로 빠지기도 하지만 일어서서 회의를 하면 결과적으로 필요한 이야기만 짧게 해 집중도가 높아진다.

스탠드 업 미팅은 보통 매일 아침 일찍 열리며 모든 사람은 다음 세 가지 질문에 간단하게 대답한다. ‘첫째, 어제 내가 한 일은 무엇인가? 둘째, 오늘 내가 할 일은 무엇인가? 셋째, 작업에 문제나 어려움은 없는가?’ 참석자마다 돌아가면서 주어진 세 질문에 짧게 말하고 무언가 더 상세하게 논의할 것이 있다면 스탠드 업 미팅 이후에 적당한 사람과 모여 따로 회의한다.

▲ 불필요한 회의 시간 줄이기

스탠드 업 미팅은 많은 이익을 제공한다. 하루를 업무에 집중하면서 시작하게 하고, 참석자 모두가 프로젝트를 충분히 이해하게 해 불필요한 회의를 줄여주며 참석자중 어려움이 있을 경우 다른 사람이 해결책을 제시해 주거나 불필요한 작업을 하지 않도록 막아준다. 또 다른 사람이 진행 상황을 보고하는 것을 봄으로써 함께 일을 하도록 동기를 부여하여 서로서로 앞으로 나아가게 북돋아준다. 이 모든 것이 하루 15분 회의를 통해 얻을 수 있는 성과이다.

◇ 정보 방열판

애자일에서 스탠드 업 미팅은 주로 정보 방열판 앞에서 갖는다. 정보 방열판이란 프로젝트의 현재 상태와 작업의 진척 상황을 알려주는 현황판이다. 보통은 화이트보드나 벽에 포스터 같은 것을 붙여 만들게 되는데, 지나가는 사람은 이것을 보고 쉽게 프로젝트의 정보를 얻을 수 있다. 게시판이나 위키, RSS피드 등으로도 만들 수 있지만 보통은 만들기도 쉽고 수정하기도 용이한 아날로그적인 것을 더 선호한다.

정보 방열판을 보면 전체 프로젝트의 진척율은 얼마나 되고 또 현재 대기중인 작업은 무엇이고 진행중인 작업은 무엇이며 완료된 것은 무엇인지를 한눈에 알 수 있다. 다른 사람들의 작업 진행 상황을 보면서 내 일을 조정할 수도 있고 가장 일이 밀려있는 사람이 누구인지도 확연히 보이기 때문에 만약 여유가 있다면 그 사람을 도와줄 수도 있을 것이다.

◇ 테스트 주도 개발(Test-Driven Development)

▲ 유연성 높은 코드 작성

테스트 주도 개발은 테스트 코드를 먼저 작성하면서 테스트 주도로 개발을 진행해 나가는 기법이다. 코딩을 할 때 해당 모듈에 대해 결과를 체크하는 단위 테스트 코드를 먼저 작성한 후에 메인 코드를 작성하는 방식으로 테스트가 코딩의 방향을 주도한다.

단위 테스트 코드 작성, 메인 코드 작성, 리팩토링을 순서대로 반복적으로 수행하면서 개발하는데 이렇게 진행하면 테스트를 위한 설계를 하게 되어 자연스럽게 결합도가 낮은 유연한 코드를 작성하게 되고, 테스트 실패를 성공으로 만듦으로써 개발하고 있는 기능에만 집중할 수 있도록 해준다.

또 만들어진 테스트가 그대로 남아 차후 기획에 새로운 변화가 있어 여러가지 코드를 고쳐야 할 일이 생기거나 리팩토링을 할 때 그 변경으로 인해 다른 부분에서 예상치 못한 문제가 발생하는 것을 쉽게 알아차릴 수 있는 안전망의 역할도 하게 된다.

▲ 새로운 기획 적용도 ‘거뜬’

예전에 친하게 지내는 기획자가 애로사항을 토로한 적이 있었는데 그 고민은 서버 프로그램 팀장이 뭔가 새로 바뀐 기획서만 들고오면 수정하기 어렵다고 기획서를 읽어보지도 않고 거절을 한다는 것이었다.

안정성을 추구하는 게임 서버의 특성상 뭔가를 고치게 되면 예상치 못한 어떤 버그가 생길 수 있어 변경 요청을 두려워 하는 것은 이해하지만 이렇게 경직되게 개발을 진행하게 되면 절대 재미있는 게임은 나올 수 없다. 만약 테스트 코드가 잘 작성되어 있었다면 변경 요청이 들어왔을 때 두려움 없이 쉽게 변경 작업을 할 수 있었을 것이다.

◇ 빠른 피드백

애자일에서는 작고 많은 변경을 지속적으로 조정하기 위해서 항상 피드백을 추구한다. 코드를 작성하면서 테스트 성공 여부에서 지속적으로 피드백을 얻고, 하루에도 여러번 자동화된 시스템을 통해 빌드를 작성하고 테스트하여 프로젝트의 진행 상태를 확인한다.

이터레이션 동안 프로젝트의 진척 상황을 정보방열판을 통해 모든 사람들에게 보여줘 잘못된 방향으로 가고 있는지 확인하고, 이터레이션이 끝나면 진행된 이터레이션을 회고하는 회의를 열어 그 이터레이션 과정에서 얻은 경험들을 최대한 반영해 프로세스나 팀의 구조를 개선하도록 노력하기도 한다. 필자의 팀같은 경우에는 매일 퇴근하기 직전에 함께 모여 그날 있었던 일들을 이야기하고 작업에 병목이 없었는지 여부 등을 간단하게 회고하기도 한다.

◇ 마치며

여기에서 설명한 몇 가지 실천 방법으로 애자일의 모든 것을 설명할 수는 없다. 애자일에는 수많은 실천 방법이 있지만 실천 방법을 하나하나 따르는 것보다 더 중요한 것은 애자일에서 중요하게 여기는 가치인 ‘의사소통’ ‘잘 동작하는 소프트웨어’ ‘단순함’ ‘피드백’ 등을 추구하는 것이다.

한마디로 여러 사람과 협력해 지속적인 조정을 위해 피드백을 끊임없이 받으면서 잘 동작하는 소프트웨어를 만드는 것이 애자일의 목표이다. 그렇기 때문에 애자일에서는 프로세스 자체보다는 참여하는 사람의 자세와 팀의 문화나 가치관이 매우 중요한 역할을 한다.

유저들에게 사랑받는 재미있는 게임을 항상 성공적으로 만들 수 있도록 보장해주는 프로세스는 존재하지 않는다. 하지만 애자일이 그 성공률을 높여줄 수는 있다. 만약 이 글을 읽는 독자들의 프로젝트 개발 프로세스에서 뭔가 부족함을 느낀다면 애자일이 그 부족함을 채워줄 힌트가 되어줄 수 있을 것이다.

게임에서 가장 중요한 가치는 ‘재미’다. 애자일의 가치를 생각하며 여러 실천 방법 중에서 자신의 프로젝트에 맞는 부분을 선택하고 조합한다면, 틀림없이 성공적으로 재미있는 게임을 만들 수 있을 것이다. 마지막으로 애자일에 좀 더 관심이 간다면, 프로그래머는 얼마 전에 번역서가 나온 ‘Head First Software Development’를, 비 프로그래머라면 ‘스크럼’ 관련 서적을 추천한다.