베타 마인드를 가지고 온라인 게임을 개발하지 말라!

오픈베타를 시작한 후 얼마 지나지 않았을 때 당시의 게임 상황은 상당히 불안정한 상태였다. 특히 서비스 안정화가 되지 않은 상태에서 하루에도 수차례 전체 게임 렐름이 다운되기도 하였고 부분적인 세션 장애로 인해 게임 서버중 몇개를 수시로 재가동하는게 다반사였을 정도였다.

보통 타게임의 경우 2주 가량이면 서비스는 안정화 상태로 넘어가게 되는데 아쉽게도 우린 그러지 못했으며 근 한달여간을 프로그램팀에서는 비상체제로 각종 버그와의 씨름을 해야만 했다. 오픈베타를 시작하기 까지 우리는 근 6개월간 3차에 걸친 클로즈베타 테스트를 해왔으며 나름대로 준비를 해왔다고 믿었었지만 역시 오픈베타의 스케일은 클로즈베타 테스트의 스케일과는 비교할 수 없는 수준이었다.

서버는 매일 포화 상태에 치닫게 되고 서비스 3일째되는 날 부랴부랴 제 2서버를 추가하게 되었다. 제2 서버를 추가하고 난 이후의 상태는 더더욱 좋지 못하였다. 같은 아이디 접속 현상에 따른 접속 장애와 접속자 집단 털림 현상(mass-Link Dead), 잦은 게임 서버 다운등 2주차까지 우리는 서비스 불안정과의 힘겨운 싸움을 지속하게 되었고, 한게임 마케팅팀에서는 이번 블리츠의 론칭과정에서 demarketing(마케팅을 하여 사람들을 모아 오히려 제품의 단점을 알리게 되는 좋지 못한 마케팅 케이스) 현상까지 걱정하기 시작했었다.

이때부터 우리 개발팀은 아주 민감해졌으며 상당히 공격적인 코드 접근을 시작하게 되었다.

"서비스 장애를 안정화할 수 있다면 모든 수를 다 써보자!"

우리는 우리가 예측할 수 있는 장애들과 다소 의심스러운 부분들에 대해 추측에 의한 코드수정을 하기 시작했으며 사내 테스트만 거친 후 바로 라이브 업데이트를 시도하는 등의 외줄타기를 시작했다.

결과는 참담했다. 오히려 패치 이전보다 더 안좋은 결과들이 발생할 때도 많았다. 이러한 side effect 로 인해 패치 -> 새로운 장애 -> 새로운 장애를 위한 버그 패치 -> 롤백 -> 2nd 패치 순으로 이루어지는 일련의 worst case를 맛보게 되었다.

우리에게 부족했던 것은 무엇이었는가 ?

그것은 서비스 마인드였다. 우리는 오픈베타를 테스트의 한 과정으로 착각했던 것이며 엄청난 마케팅 코스트의 낭비를 걱정한 나머지 방어적인 수정이 아닌 공격적인 수정으로 "자 우리의 게임은 상당히 불안해" 라는 것을 수많은 유저들에게 알려준 꼴이 되고 말았다.

약 두달이 지난 지금의 패치 과정은 사내테스트 -> 버그발견 및 수정 -> 사내테스트 -> 사내QA인증 -> 라이브테스트서버 패치 -> 버그발견 및 수정 -> 라이브테스트 -> 라이브테스트QA인증 -> 퍼블리셔 인증 -> 라이브 서버 패치 -> 문제발견시 롤백의 과정을 거쳐 진행이 되고 있다.

두 달전에 우리는 베타테스트 마인드를 가지고 사용자를 상대로 테스트를 하고 있었다.

그 이후로 우린 "추측에 의한 코드 수정은 금물"이라는 새로운 원칙을 세우게 되었고 '안정화','방어적이며 견고한 서버 유지'를 위해 모든 기획의 전면적인 재조정 및 세션의 안정성을 보장해주는 세션 모듈화 작업등 굵직굵직한 작업을 뒤늦게 진행해야만 했었다.

기능 향상보다 정작 중요한 것은 안정적인 서비스 제공이라는 것을 뒤늦게 깨달은 셈이었다.