퀘이크워즈 온라인, 개발팀이 말하는 버그 잡는 노하우

이렇게 해서 두 번째 개발일기를 아주 자발적으로 다시 쓰게 되었다. 사실 우리 팀에 다수 존재하고 있는 모델(?)급 여 개발자의 글을 보는 게 유저분들 입장에서는 더 좋겠지만 어쩌랴. 이미 때는 늦으리. 오키나와가 날 기다리고 있다.

서론

소프트웨어가 하는 일은 그 소프트웨어를 사용하는 유저 또는 고객에게 의도한 기능과 편의를 제공하고 유저는 그 소프트웨어를 통하여 유형/무형의 원하는 목적을 이루게 하는 것이다. 게임도 하나의 소프트웨어로서 유저에게 가상 놀이공간을 제공하는 것이 목적이지만 게임이라는 결과의 특성 상 여러 가지 복합적인 부분, 그래픽, 사운드, 시스템, 네트웍 등 여러 분야의 기술이 종합적으로 상호작용을 하여 즐길 수 있는 무언가를 창조하는 것인데, 문제는 이 모든 것이 사람이 하는 것이다 보니 작업과정에서 의도하지 않은 결과를 내거나 치명적 오류가 발생하기 마련이며 이를 전문용어로 ‘버그’라고 부른다. 이번에는 이 ‘버그’라는 넘에 대해서 일장 설을 풀어볼까 한다. 당장 내가 몸담고 있는 퀘이크워즈에 대한 직접적인 언급이 아니겠지만 이 글을 통해서 좀 더 개발과정에서 일어나는 재미있는 일들에 대한 설명이 되지 않을까 한다.

왜 버그는 항상 오픈 직전에 생기는가?

본인처럼 게임을 개발하고 있거나 다른 소프트웨어를 개발하는 사람이라면 항상 이 버그라는 놈과의 진흙탕 싸움을 해 본 경험이 있을 것이다. 출시되는 게임이 궤도에 오르려면 먼저 이 버그와의 싸움에서 승리해야 하며 이 승리가 안정적 서비스를 담보해주고 이 다음에 유저가 재미를 느끼던 말던 할 것이다.

버그의 일반적 해결 과정은 다음과 같다.

1.  버그의 발생을 인지
2.  버그 발생 지점을 추적
3.  발생 지점을 찾아 원인 분석
4.  버그의 원인을 제거

하지만 발생되는 버그는 여러 가지 유형이 있고 그 심각성과 난이도가 제 각각이다. 회사에서 다년간 ‘버그제조기’로 통하던 본인은 그 발생되는 버그의 유형을 나름대로 분류하기에 이르렀다.

1.  발생 지점에 대한 추적이 용이한가?
2.  특정 조건만 만족하면 규칙적으로 발생되어 재현이 용이한가?
3.  게임에 심각한 영향을 끼치는가? (클라이언트 다운, 퍼포먼스 저하, 밸런스 파괴)

발생 지점에 대한 추적이 용이하면 발생지점을 금방 찾을 수 있고 규칙적으로 발생하면 그 원인을 금방 찾을 수 있으며 게임에 미치는 심각성에 따라 버그 수정의 우선 순위를 빠르게 선정할 수 있다. 게임의 규모가 커지면 커질수록 버그는 발생하게 마련이며 그 버그를 빠르게 찾아서 수정해야 만 원활한 서비스가 보장 받을 수 있다. 분명히 같은 루틴인데도 버그가 나왔다 안나왔다 하고 그 빈도도 굉장히 확률이 낮아 버그 발생 위치 추적이 매우 힘들며 게임에 심각한 영향을 끼치는 버그를 악성버그로 분류하는데 문제는 왜 추적도 안되고 랜덤하게 낮은 확률로 발생하면서 게임에 심각한 영향을 미치는 버그가 꼭 오픈 직전에 나오냔 말이다..

이건 어떤 법칙처럼 본인의 개발 인생에 따라다니던 상황이었고 많은 개발자 분들도 경험했을 거라고 믿는다. 분명히 테스트 기간 동안에는 아무런 문제를 일으키지 않던 부분이 꼭 서비스 직전에 문제가 생기는 것을 많이 경험하게 된다. 그래서 본인은 어느 순간부터 ‘버그에는 생명이 있다.’ 라는 신념이 자리잡기 시작했는데 내가 만든 내 일부분 이지만 이놈은 자기의 의지가 있고 생명이 있으며 곤란할 때 나타난다. 마치 johnson처럼.

처리하기 곤란한 악성 버그가 터졌을 때 그 시점이 오픈기간 이라면 신비로운 체험을 하게 되는데 그 버그를 찾는 프로그래머는 마치 ‘달리고현금’에서 돈을 빌리고 6개월 동안 안 갚은 채무자 신세가 되며 작업자 자리 뒤에 두 세명이 모니터를 보며 팔짱을 낀 채로 눈에 불을 켜고 서있게 된다. 전화통에는 불이 나며 이 상황쯤 되면 작업자의 정신 세계는 여긴 어디 나는 누구의 황홀한 무아지경의 놀라운 경험을 하게 되며 갑자기 옆에 있는 스킨 로션을 마시거나 실없이 웃는 등 현실 도피적인 행동을 하고 게시판이 유저의 항의글로 도배가 될쯤 작업자는 안드로메다 행 특급열차에 몸을 싣고 머나먼 여행을 준비하게 된다. 전문용어로 ‘코마상태’라고 한다.

이는 개발과정 중 일어날 수 있는 최악의 상황이며 개발자나 회사의 입장으로서는 반드시 막아야만 하는 상황이다. 하지만 우리 퀘이크워즈 팀은 1차 클베, 게릴라 테스트, 2차 클베를 통하여 오히려 안정적 서비스를 제공하였고 우리 게임을 즐기신 많은 유저 분들의 호평을 받았다.

이는 우리가 고안한 획기적인 개발 솔루션이 있었기에 가능했으며 실제로 그 결과는 고무적이었다. 우리가 생각한 심플하고도 획기적인 방법은

아무것도 안 하는 거다.

그렇다 아무것도 안 하는 거다.

오픈 전 일정 기간 이전까지 모든 추가 구현 작업을 완료하고 그에 대한 작업 완전 중단한 채 실제 서비스 버전을 통한 테스트와 버그 수정작업을 집중적으로 실시 하는 것이다. 실제 테스트 기간이 길수록 그 안정성은 늘어나고 버그의 발생 확률은 내려간다. 누구나 생각하기 쉽고 간단한 방법이지만 이것이 실제로 실행되기 위해서는 팀원 각각의 인원이 자신의 작업을 스케줄에 맞게 칼 같이 맞추어야 한다는 전제가 깔려있다.

따라서 의외의 변수에도 대처할 수 있는 자신의 철저한 스케줄 관리가 필요하며 공동 작업일 경우 단단한 팀웍이 있어야만 지켜질 수 있는 방법이다.

왜 오픈 때 문제가 많이 발생하는가?

오픈이라 함은 유저에게 서비스를 한다는 것을 뜻한다. 그에 따라 클라이언트도 변화를 하게 되는데 개발 시에 사용했던 각종 디버그 모듈과 명령어 모듈을 떼어내야 하며 외부 업체의 모듈과 합쳐져야 한다. 접속하는 서버가 달라지며 내 외부적으로 많은 변화를 거치게 된다. 이 과정에서 테스트가 부족했다면 각 모듈이 합쳐지는 과정에서 오류가 발생할 가능성이 높아지며 클라이언트에 영향을 미치는 변수가 발생할 수 있으며 이는 위에서 설명했던 악성 버그로 이어질 가능성이 매우 높아진다. 또한 급하게 오픈 직전에 테스트가 부족한 상태에서 추가되는 코드 역시 버그의 위험성을 상당히 내포하고 있다. 따라서 안정적 서비스를 위해서라면 최대한 빠른 시간에 모든 기능의 구현이 이루어져야 하고 그 만큼 테스트를 할 수 있는 시간을 많이 확보하는 게 중요하다. 어떤 천재 개발자가 있어 버그를 전혀 만들지 않을 보장이 없다면 달리 왕도는 없는 것이다. 많은 테스트 케이스를 수집하고 버그를 수정하는 게 왕도인 것이다.

그런 의미에서 우리 팀은 아직까진 성공적으로 진행되고 있다. 팀에서 각각의 역할이 있지만 프로그래머는 기획자가 준 설계도와 디자이너가 준 재료를 가지고 최종적인 생명력을 부여하는 역할을 하고 있다. 구현만 하는 것이 아닌 빠르고 안정적인 구동의 보장도 해주어야 한다.

이 글을 쓰는 본인 역시 게임을 좋아하고 즐기는 한 명의 유저이고 회사에서는 그 게임을 만드는 개발자 이지만 프로그램이라는 세계는 꽤나 고리타분하고 냉정한 0과 1의 세계이다. 이 세계는 참과 거짓 밖에 존재하지 않으며 어중간 함이나 대충이라는 논리가 통용되지 않는다. 참이냐 거짓이냐의 냉정한 연산이 수 억번 연산되며 이 순간이 연속적으로 이어지면 그것이 하나의 게임 프레임이 되고 프레임이 이어지면 비로소 하나의 게임이 된다. 이러한 복잡한 연산과의 싸움이 끝나면 그 너머는 구현 이상의 재미를 프로그래머는 생각하게 된다. 그래서 우리는 구현은 빠르게 끝내고 테스트 기간을 확보하여 최종적인 재미를 다듬는 시간을 가지려고 하는 것이고 아직까진 우리는 성공적이다.

이렇게 다듬어진 재미를 유저가 느끼고 공감하며 우리가 만든 세계에 대해서 즐긴다면 게임을 만든 개발자의 입장에서 이 보다 더 이상의 희열이 있을까?

이것이 내가 아직 프로그램을 하고 있는 이유이다.

길고 지루한 글 끝까지 읽어주셔서 감사합니다.