1. 아이폰 게임 <팔라독>개발에 적용한 버그 트래킹
시스템 맨티스(Mantis) 를 적용 해보자!!
문기영
Fazecat
2. 강연자 소개
• 개발
– FazeCat
• 팔라독 아이패드
• DressUp Baby
• New Project!
– Hammer Game Studio
• Attack of the Pig
– EA Canada
• EURO, FIFA 08~12
• Referee decision engine, CPU AI, Practice Mode, User celebration
– SonoV
• Shaiya
– Namo Interactive
• Freelancer
– 그 외 다수의 회사들 하지만 적고 싶지 않음.
• 저자
– 비주얼 베이직6 게임 만들기
– 게임 개발 테크닉
– 게임 프로그래밍으로 배우는 C#
• 번역
– 언리얼 게임 엔진 UDK 3
– Ogre 3D 1.7 Application Development Cookbook
• 강연
– NDC12 (인디 개발자로써 iPhone게임을 만드는 방법 그리고 개발 및 북미 취업 이야기들)
• 컨퍼런스
– SXSW 부스 참가 업체(KBS1 뉴스에 나옴. 1.3초…)
3. 버그 트래킹 시스템이란?
• http://en.wikipedia.org/wiki/Bug_tracking_sys
tem
• 버그 트래킹 시스템은 소프트웨어의 품질
보증 및 프로그래머가 소프트웨어 버그를
트래킹할 수 있도록 도와주는 시스템이다.
버그 트래킹 시스템은 이슈 관리 시스템이
라고 말하기도 한다.
4. 버그를 왜 트래킹 하는가? (굳이 소프트웨어를 사용하는 이유)
• 버그 유실
– 보통 소규모 인원의 팀인 경우 버그 관리를 구두로 하는 경우가 많
으나 이럴 경우에 중요한 이슈들을 까먹거나 유실할 소지가 많다.
• 관리의 어려움.
– 종이 혹은 포스트잇과 같은 도구는 버그를 관리 및 공유하기가 어
렵다.
• 멀티미디어 소스를 첨부하여 공유할 수 있다.
– 가령 사진, 로그 기록, 동영상을 공유하고자 할 때.
• 스케쥴 관리
– 사람에 따라서 작은 단위로 업무를 쪼갠 태스크로 이슈/버그를 관
리하면 일 처리를 더 잘하는 경우가 많다.
5. 그… 아주 그… 유명한 버그 트래킹 시스템 솔루션
• http://devtrack.com/
– 제가 다녔었던 북미의 중소기업 회사의 경우 데브트랙(DevTrack)을 사용함.
• 중소기업이라는 표현은 루리웹 농담입니다.
– 편리성 : 좋음(웹버전, PC버전 모두 존재, 전세계 모든 스튜디오 연결 가능)
– 가격 : 1명당 60만원
• http://www.bugzilla.org/
– 한국의 몇몇 스튜디오는 버그질라(BugZilla) 사용.
– 편리성 : 좋지 않음
– 가격 : 공짜
• http://www.mantisbt.org/
– 많은 사람들이 사용.(한국의 게임개발 회사들도 많이 사용함)
– 편리성 : 쓸만함
– 가격 : 공짜
6. 그래서 FazeCat은 무엇을 사용하는가?
• Mantis를 사용하기로 하였음.
• 왜?
– 공짜!
– 사용하기가 편리함.
– 웹으로 관리
– 데이터베이스를 외부로 빼지 않고 회사 내부 서
버에 설치 가능.
8. Mantis를 설치하기 위해 필요한 것들
• VirtualBox
– 공짜
• Ubuntu Server 12.04.1
– 공짜
• MySQL 5.5.28
– 공짜
• Apache 2.2.22
– 외쳐 EE!
• PHP5 5.3.10
– 공짜
• 드디어 Mantis
– 공짜
• 이 모든 게 다 공짜…
9. 강연을 왜 했을까?
• 설치에서 시작해서 실제로 사용하는 것까지
모두 다룰 예정.
• 웬만한 프로그래머라면 대부분 구글신의 도
움으로 설치에서 사용까지 가능하지만 여러
분의 시간을 조금이라도 단축 시켜드리고자
강연 하기로 했음.
10. VirtualBox를 설치해보자.
• VirtualBox란 X86, AMD64/Intel64를 가상화
시키기 위해서 필요한 어플리케이션.
• 오라클에서 제공하고 있으며 공짜임!
• 다운로드
– https://www.virtualbox.org/wiki/Downloads
76. 아파치(Apache) 웹 서버 설치
• 아파치란 무엇인가요?
– Apache is the most commonly used Web Server
on Linux systems. Web Servers are used to serve
Web Pages requested by client computers. Clients
typically request and view Web Pages using Web
Browser applications such as Firefox, Opera,
orMozilla.
104. 포트 설정
• A컴퓨터가 아닌 다른 컴퓨터에서 리눅스 서
버에 설치된 맨티스에 접속하기 위해서는
다음과 같이
http://192.168.0.120/mantis/login_page.php
로 접근해야 한다. 이를 위해서는 버추얼 박
스에 포트를 포워딩 해주어야 한다.
122. 맨티스 Email설정
• 프로젝트에 새로운 인원이 들어오면 새로운
유저를 만들어야 하는데 이때 Verify하려면
email이 설정되어 있어야 함.
• 메일 서버는 gmail 계정을 이용하도록 예를
들어 설명.
123. 맨티스 Email설정
• Email을 설정하기 위해서 config_inc.php혹은
config_local.php파일을 수정해 주어야 한다.
• 파일 경로
– /usr/share/mantis/www/config_inc.php
– /usr/share/mantis/www/config_local.php
124.
125. 맨티스 Email설정
• 이 파일을 수정하기 위해서 관리자 권한이 필요.
• 다음 명령어를 이용해서 수정할 수 있다.
– sudo vi config_inc.php
158. 모든 길은 매니저로 통한다.
• 매니저(보통 프로듀서가 이 역할을 맡는다)
– 매니저가 이슈의 우선순위에 따라 이슈를 개발
자에게 할당한 후 일을 진행하거나 버그를 Fix한
다.
• 개발자는 매니저에게 받은 이슈를 최우선으로 고친다.
– 우선 순위에 밀린 버그들이 고쳐지지 않는 단점도 있지만…
– 사소한 문제 때문에 개발 스케줄이 밀리는 것이 더 큰 문제.
159. 아무튼 매니저가 이슈를 할당
• 테스트를 위해서 testaccount1가 개발자로
권한 설정을 바꿈.
171. 이봐… 그게 끝이 아니라구
• 매니저는 해결된 이슈를 진짜 해결되었는지 확
인 해야 함.
– 보통은… QA에게 다시 이 이슈를 줌.
• QA가 해결된 이슈로 확인이 되면 그때 이슈를 [닫음] 처리
가능함.
– 작은 회사들은 보통 매니저가 직접 하던가 개발자
가 직접 닫음 처리 함.
• 하지만 개발자가 [닫음]처리 하는 것은 비추천.
– (믿을 수… 있겠니…?)
172. 첨부 파일 추가
• BTS를 사용하는 최대 장점은 첨부 파일 추가
가능하다는 것. 그리고 까먹지 않는다는 것.
174. Mantis로 스케줄 관리도 가능!
• 보통은 버그를 관리하기 위해서 BTS를 사용
하지만 스케줄을 관리하는데 사용할 수도
있음.
• 태스크 단위로 일을 할당 받아서 일하는데
익숙한 사람들은 이런 형태로 일을 하는데
편하다는 것을 느낌.
– 성취감도 있음!
175. Mantis로 스케줄 관리
• 버그 발견 시 즉각적으로 처리할 수 있는 수
준이라 하더라도 기존에 개발자가 하던 일
이 있을 경우 인터럽트가 되면 시간 낭비가
생김.
• 이때 이슈를 보고해 매니저가 필요한 시기
에 이슈를 각 개발자에게 할당 하면 됨.
176. Mantis로 스케줄 관리
• 개발자는 이슈를 하나씩 수정할 때 마다 얼
만큼의 시간이 소요되는지 경험을 통해서
알 수 있게 되고 결과적으로 이후 프로젝트
를 진행하면 할 수록 시간을 더 정확하게 할
당해서 업무 처리가 가능.
177. Mantis로 스케줄 관리
• 강연자가 작업했던 축구 게임의 경우 막바지 작업을
할 때 버그 개수는 약 7천여 개 수준이며 이것을 주
어진 기간 내에 몇 명의 개발자가 몇 개씩 수정해 나
갔을 때 최종적으로 (7천여 개 모든 버그를 다 수정할 수는 없음) 릴리
즈를 해도 되겠다는 수치가 나옴.
• 이것을 이용해 이후 프로젝트 혹은 진행되는 프로젝
트에 적용해서 스케쥴을 미리 예측할 수 있음.
178. 팔라독은?
• 강연자의 예를 들면…
– 팔라독 아이패드의 경우 하루에 약 7개 정도 수
정을 했으며 보통 QA가 테스트 할 때 마다 20개
정도가 나옴.
– 물론 이때 매니저가 모든 이슈를 개발자에게 할
당하지 않고 중요도에 따라서 할당함으로써 언
제나 게임을 출시 할 수 있는 준비를 할 수 있음.
179. 팔라독은?
• 이것을 통해서 알 수 있는 것은 예를 들어 평소
7개씩 수정 가능한 개발자가 7개 이하를 수정
했을 때 매니저가 개발자에게 어떤 병목 사항
이 있었는지 알 수 있음.
• 그리고 그 병목사항을 알아내서 고치려는 노력
이 필요함. (예를 들어서 리소스가 늦게 나온다
던지 휴가가 있다던지, 아니면 LOL에 빠졌다던
지… 등등)
180.
181. • 팔라독 아이패드의 경
우 프로젝트 막바지에
총 179개의 버그가 있
었으며 모두 해결 하
였음.
• 강연자의 경우 하루에
보통 3~7개까지 버그
를 고칠 수 있었으며
계산해 보면 버그 고
치는 데만 평균 44일
걸렸다는 것을 알 수
있음.
182. 버그 트래킹 소프트웨어를 사용해서 얻는 장점?
• 유실의 가능성이 적어진다.
• 프로젝트가 어떻게 진행되는지 더 구체적으로 알 수 있다.
• 계산이 가능하다.
– 계산이 가능하기 때문에 예측이 가능하다.
183. 마지막으로 팁…
• 버그 트래킹 시스템을 사용할 때 무엇보다
중요한 것은 빌드 번호를 관리하는 것이다.
• 빌드 번호가 무엇인가?
184.
185. 빌드 번호를 표시하는 이유?
• 가령 현재 빌드 번호가 10번이라고 치자…
– 버그를 발견한 사람이 이슈를 보고할 때 어떤
빌드를 가지고 게임을 했을까?
– 빌드 번호를 표시하지 않을 경우에는 개발자 외
에는 이것을 알 수 있는 사람이 없다.
186. 빌드 번호를 표시하는 이유?
• 이슈 보고자가 실행했던 빌드의 번호가 9번
이었다면?
– 혹시 이 이슈는 이미 빌드번호 10번에서 해결된
이슈는 아닐까?
• 다른 예로…
187. 빌드 번호를 표시하는 이유?
• 예를 들어 개발자가 이슈번호 19번을 해결
했다. 그리고 메모에 다음과 같이 적는다.
– 이슈 19번 해결했습니다. 빌드번호 30번.
• 그리고 다시 QA가 게임을 실행했을 때…
– 이슈 19번이 해결된 것 같지가 않아!!
– 그러면 이슈를 다시 개발자에게 돌려 보내야할
까?
188. 빌드 번호를 표시하는 이유?
• NO
– QA는 이슈를 테스트할 때 빌드 번호를 먼저 체
크 해야 함. 왜냐하면 실행하고 있는 빌드 자체
가 옛날 버전일 수도 있기 때문.
189. 빌드 번호를 표시하는 이유?
• 멋있음
– 팔라독 아이폰의 경우 버전이 3.0이 넘고 있으
며 2년 이상 계속해서 업데이트하고 있음.
– 물론 유저들은 잘 모름.