▲ 배현직 대표
인벤에서는 국내최초로 서버엔진을 개발하고 상용화한 '넷텐션'의 배현직 대표님을 모시고 서버 관련 칼럼을 기고받게 되었습니다.
넷텐션은 '프라우드넷(ProudNet)'이라는 이름의 서버 엔진을 개발해 현재 '마비노기영웅전', '마계촌온라인' 등 60개 이상의 개발 프로젝트에서 사용 중이며 미국, 한국, 독일 중국 등 9개국 이상에서 게임 서버로 운용 중입니다.
이번 시간에는 게임 서버 개발자가 게임 회사 안에서 겪게 되는 일을 주제로 이어집니다.
※ 넷텐션 공식홈페이지 바로가기
▶ [연재] 게임서버의 정의와 역사
▶ [연재] 게임서버의 작동원리, 섭다와 렉은 왜 생길까?
▶ [연재] 게임 서버 개발자가 게임 회사 안에서 겪게 되는 일
▶ [연재] '잘 되던 게임이 멈췄다', 서버 다운일까 랙일까?
▶ [연재] '해커와 개발자의 두뇌 싸움', 해킹 기술과 방어 원리에 대해
▶ [연재]프리서버와 봇의 탄생, 틈새를 파고드는 서버해킹
컴퓨터는 어려운 일을 자동으로 해주는 편리한 기계지만 컴퓨터 안에서 작동하는 것들은 한땀 한땀 사람들의 정성 어린 손길로 개발되어야 한다. 컴퓨터가 더욱 똑똑하려면 그 안에서 작동하는 것들을 더욱 정성스러운 손길로 사람이 만들어야 한다. 아무리 IT 첨단이네 뭐네 해도 결국 사람이 가장 중요하다. 이는 게임 개발에서도 마찬가지이다.
이번 회에서는 게임 개발이 진행되는 동안 게임 서버를 만드는 사람들에 대해서 집중해서 살펴보도록 하겠다.
게임 개발 프로젝트의 시작
게임 기획자는 퀘스트, 몬스터, 플레이어, 아이템 등을 나열하는 게임 컨텐츠 기획서를 작성한다. 뿐만 아니라 게임 시스템, 가령 로그온 절차, 길드 맺는 법, 파티 맺는 법, 쪽지 주고 받는 법 등 에 대한 기획서도 작성한다. 처음 개발을 시작할 때에는 십여 페이지밖에 안되는 기획서가 개발 후반에 가면 수백 페이지 이상으로 늘어난다.
소개서(포커스 노트라고도 부름)에서 시작할 수도 있다.
(그림 출처: http://doocub.egloos.com/4323388) ]
게임 서버 쪽이건 클라이언트 쪽이건, 프로그래머는 일단 게임 기획자가 작성하는 기획서를 숙지하는 것이 가장 먼저 해야 할 일이다. 기획서를 꼼꼼하게 읽으면서, 만들고자 하는 게임의 모양과 작동 방식을 머릿속으로 상상을 한다. 그리고 기획자에게 만들고자 하는 것이 무엇인지 자세한 설명을 들어가면서 제작 방법과 프로그램 구조를 다듬어 나간다. 가끔은 기획서에서 논리적 모순을 찾아내서 기획자와 함께 보완해 나가기도 한다.
게임 개발 초반에는 게임 클라이언트 프로그래머의 작업량이 무척 많다. 양만 많을 뿐만 아니라 수학 지식과 숙련된 프로그램 설계 능력이 총동원된다. 특히 지금처럼 걸출한 게임들이 경쟁하는 시기에는 클라이언트 프로그래머들이 공부해야 하는 수학과 기술은 끝도 없이 많다. 그들은 날이 갈수록 복잡해지는 자신들의 작업물과 씨름하면서, 많은 양의 프로그램을 개발하기 위해 야근을 밥 먹듯이 하게 된다.
게임 개발 초반에 서버 프로그래머들이 개발하는 프로그램의 양이나 복잡도는 클라이언트보다는 적은 편이다. 그들은 게임 시스템 기획서를 잘 읽어보고, 많은 동시접속자가 들이닥쳐도 원활하게 돌아갈 수 있도록 게임 서버를 조심스럽게 설계한다.
프로그램 개발에서 실험을 통한 검증은 필수이다. 절대로! '가정에 의한 개발'은 금물인 것이 프로그램 개발자들 사이에서의 룰이다.
게임 클라이언트는 그나마 테스트를 해볼 수 있는 환경이 많다. 다양한 하드웨어를 가져다 테스트해보면 된다. 하지만 게임 서버에서는 이를 미리 실험해 보기 어렵다. 동시접속자가 들이닥치는 상황을 진짜로 맞닥뜨려봐야 실험이라고 말할 수 있기 때문이다. 즉, 안정적으로 작동하는(그럴 것이라 믿는) 게임 서버를 개발해야 하는 안타까운 상황에 놓여 있다. 게다가, 게임 서버는 아주 사소한 실수로도 치명적인 장애를 유발할 수 있으며 게임 서버의 양이 점점 늘어날수록 실수를 찾는 것은 점점 어려워진다.
그렇다면 최선을 다 하는 수밖에 없다. 게임 서버 프로그래머들은 동시접속자가 많이 들어오는 상황을 유사하게라도 재현하기 위해 더미 클라이언트(dummy client)라는 것을 만들어 사전에 실험한다. 그들이 할 수 있는 모든 테스트 가짓수를 상상할 수 있는 대로 모두 끌어모아 테스트 프로그램을 만들어 작동시킨다.
더미 클라이언트는 일종의 오토 프로그램이다.
“오토…라면 해킹툴?”
맞다. 그 해킹툴이라고 불릴 수 있는 봇 프로그램을 게임 서버 개발자들이 직접 만든다. 더미 클라이언트는 게임 서버에 접속해서, 자동으로 캐릭터를 생성하거나 선택하고, 게임 월드 필드에 들어가서 여기저기 다니면서 몹 사냥과 루팅을 한다. 이것을 끝없이 반복하면서 서버의 상태나 테스트 로그 기록을 담아서 개발자에게 보고하는 역할을 한다.
더미 클라이언트는 개발자가 만든 대로만 작동한다. 즉 개발자가 의도하지 않은 형태로 작동하지 않음을 의미한다. 다시 말해 의도하지 않은 행동 양상에 대해서는 실험을 해줄 수 없음을 의미한다.
우수한 인공지능을 가진 스카이넷이 먼저 만들어져야 할지도. ]
더미 클라이언트 수천 수만 개를 테스트하더라도 의도한 대로만 작동하는 녀석이기 때문에 실제 사용자들의 ‘언제 어디로 튈지 모르는 기발한 행동’까지 스스로 만들어내지는 못한다. 그렇기 때문에 게임 개발사 전 직원이 달라붙어서 할 수 있는 모든 종류의 테스트를 한다.(물론 더미 클라이언트 수천개는 띄워놓고.) 이것도 모자라서, 게임 퍼블리셔나 테스트 대행 업체 직원까지 가담해서 게임을 마구잡이로 테스트한다.
게임 서버 프로그래머들은 이 와중에 쏟아져 나오는 문제를 제보 받아 계속 고쳐 나간다. 한편, 이 과정이 진행되는 동안, 게임 기획자들은 재미가 부족한 부분을 찾아 계속 밸런싱과 스크립트 수정 작업을 하고, 그래픽 디자이너들은 갑자기 필요해진 여러 가지 그래픽 작업물을 뿜어내고, 클라이언트 프로그래머들은 어디 어디 지역에서 느리게 작동한다는 제보를 받고 관련 부분을 수정한다. 물론, 사람이 할 수 있는 행동들이 계속 수집되면서, 개발자들은 더미 클라이언트가 할 수 있는 기상천외한 행동들을 점점 불려 나간다.
불행하게도, 프로그래머는 본능적으로 버그를 피하는 습관이 있다. 더미 클라이언트를 만들 때 생길 수 있는 한계이기도 하다. 진짜 사람들이 테스트를 해주면 버그를 더 찾아내고 많은 해결을 할 수 있지만, 게임 회사 내부 직원에, 퍼블리셔 사람들에, 심지어 테스트 용역 업체까지 동원을 해도 수백 명 이상 들어가기는 어렵다.
그렇다면 이 문제를 어떻게 해결할까? 방법은 딱 하나, 진짜 사람들을 공개적으로 모아놓고 그들을 상대로 “실험”을 하는 방법밖에 없다.
그 공개적인 ‘임상 실험’이 바로 ‘클로즈 베타 테스트’이다.
클로즈베타부터 상용화까지
클로즈베타 테스트를 하려면 공개적으로 실험체(?)를 불러모아야 한다. 게임 회사는 언론 노출과 홈페이지 공지를 올린다. 클로즈베타는 1차, 2차, 3, 4, 5… 형태로 반복적으로 수행한다. 1차 클로즈베타테스트는 이름 그대로, 처음으로 게임 사용자들을 데리고 하는 ‘임상실험’인 셈이다.
1차 클로즈베타 테스트 일정이 잡히면 게임 개발팀은 불철주야 뛰기 시작한다. 디데이를 맞추기 위해 모든 전열을 가다듬는다. 게임 서버 개발자들은 게임 서버에 문제가 없는지 프로그램 구석구석을 테스트하고, 만든 소스도 반복해서 리뷰하고, 프로그램 여기저기 부분의 성능을 테스트하면서 마지막 다듬기를 해 나간다.
이후의 이야기에 대해서는 “가상의 서버 개발자 이야기”를 통해 알아보도록 하자.
■ 가상의 서버 개발자 이야기
내 이름은 '오섭다'. 서버 개발팀에서 일하고 있다.
오늘은 무척 특별한 날이다. 2년 동안 만들던 게임을, 드디어 오늘! 1차 클로즈베타테트(이하 CBT)를 연다. 오늘을 위해 2개월간 연속된 야근을 했다. 이제 할 수 있는 모든 테스트를 마쳤다.
테스트하는 동안 여러 가지 새로운 기획도 들어갔다. 새로운 기획은 아직 테스트를 충분히 못 해서 불안하다. 시전하면 광역으로 독 데미지를 주는 법사 스킬은 어제 급하게 넣어서 더욱 걱정이다. 그렇다고 일정을 미룰 수는 없다. 이미 사업팀에서 클로즈베타 공고를 냈고 여기저기 웹진에 배너 광고를 올렸기 때문이다. 게다가 너무 오랫동안 야근하다 보니 지칠대로 지쳐서, 빨리 쫑을 보고 싶은 것이 지금의 심정이다.
CBT가 열리는 시간은 오후 2시로 공고가 나간 상태다. 점심을 서둘러 먹고 쉴 시간도 없이 바로 자리에 앉아, 각종 서버 상태를 몇 번이고 확인했다. 사내 접속만 허용한 채로 테스트를 해봤고, 아무 문제 없이 서버가 열리고 접속을 받을 수 있는 것도 확인했다. 이제 모든 것이 준비되었다.
1시 59분이다. 카운트 다운이 시작된다. 10,9,8,7,… 사람들이 뒤에서 따라 외친다. “오! 사! 삼! 이! 일!” 땡! 서버 프로그램 런칭 버튼을 눌렀다!
동시접속자수 0을 보여주던 서버 관리 프로그램이 보여주던 숫자가 파바박 올라가기 시작했다. 모니터 앞에 모여있던 사람들은 손에 땀을 쥐기 시작한다.
“와~ 잘 되는데?”
그 순간, 갑자기 0으로 추락해버린다. 0… 0… 0…
모니터를 바라보던 사장님과 PD의 얼굴이 새하얗게 변한다. 그리고 모두의 따가운 시선이 우리에게 꽂혔다. 서버 파트 동료는 어느 때도 본 적이 없는 번개 같은 손놀림으로 서버 프로그램 로그를 들추고 있다. 또 다른 동료는 키보드를 만지는 손이 덜덜 떨리고 있다. 다른 직원들은 급히 자기 자리로 돌아가서 직접 게임에 접속해본다. 나도 각 서버에 원격 모니터링을 켜서 각 서버의 실행 상태를 들춰보기 시작했다.
저쪽 운영팀 자리에서 웅성거리는 소리가 들린다. 게시판에 항의하는 글이 올라오고 있다고 한다. 대부분 짜증을 토로하는 글이고 일부는 욕설이지만, 일일이 응대하며 사과 댓글을 달아주고 있다. 그리고 몇몇 유저들은 게임 안에서 무엇을 하고 있었는지 친절하게 적어주셨다고 한다. 대부분이 비슷한 내용이다.
운영팀은 비슷한 것들을 취합해서 우리들에게 요약을 전달했다. 우리는 로그와 제보와 서버에 쌓인 오류 기록을 분석했다. 유저들의 제보에서 결정적인 원인을 짐작했다. 어이없게도, 서버 쪽 프로그램 한 줄에 부호가 잘못 들어간 것을 찾아낸다. PD에게 보고했고 금방 고칠 수 있다고 말해주었다.
그리고 PD가 크게 소리쳤다. “운영팀! 사과 공지하시고 서버 30분 뒤에 재시작 공지하세요! 서버팀! 15분안에 패치 완료하세요!”
자동화된 빌드 시스템과 서버 자동 패치 시스템을 구축해놓았으니 망정이지, 이나마도 안 해놨으면 십여 대가 넘는 서버 머신에 15분 안에 서버 패치를 하는 것은 불가능했을 것이다. 30분간의 점검을 끝내고 서버를 다시 띄웠다. 동시접속자는 동시접속자수는 다시 0부터 시작해, 아까와 마찬가지의 속도로 상승하기 시작했다.
“아! 이번에는 제발 잘 되기를!”
동시접속자가 늘어나고 있는데, 갑자기 동시접속자수에 변화가 없다. 숫자가 전혀 변하지 않는다. 사람들이 수군거린다. “뭐지? 이상한데?” 서버팀 프로그래머들은 잽싸게 자기 자리로 뛰어갔다. 서버가 작동은 하고 있는데 어디선가 막혀버렸다. 이른바 데드락(dead lock. 서버는 작동하고 있지만, 내부 로직이 교착에 걸려서 진행이 멈춰버린 상태) 현상 같다는 육감을 느꼈다. 우리는 즉시 여기저기 서버 모니터를 확인했다. 서버 처리량이 0%를 찍고 있는 곳을 찾았다.
“사실상 서버 다운입니다. 빨리 고칠게요.”
“얼마나 걸리나요?”
“이번에는 모르겠어요. 원인을 찾아야 말씀드릴 수 있습니다.”
운영팀은 30분 점검을 공지했다. 우리 서버 개발 파트는 평소 본 적이 없는 매서운 눈빛으로(그리고 창백한 얼굴로) 시커먼 창을 열었다 닫았다 한다. 30분이 지났지만 우리는 여전히 원인을 모른다.
“1시간 더 걸릴 것 같아요.”
점검이 1시간 연기되었다. 조금 있다가 드디어 저쪽에서 서버 프로그래머 한 명이 소리친다. “찾았습니다! 바로 고치죠!” 프로그램팀장이 소리친다.
“고친 서버 잘 작동하는지 내부 테스트 돌려봐요!”
아뿔싸. 사내 테스트 서버가 바로 다운되었다. 서버 프로그래머들은 수정한 것 어딘가에서 부작용을 일으킨 것으로 파악했다. 큰일이다. 안 고치면 서버가 얼어버리고 고치면 서버가 다운된다. 원인은 더욱 오리무중이다. 점검 시간을 더 늘릴 수는 없었다. 일단 지금 상태의 서버를 띄웠다. 곧 다시 다운되겠지만 어쩔 수 없다. 우리 서버파트는 미친 듯이 버그의 원인을 찾아다녔다. 백사장에서 바늘 찾는 기분이었다.
서버 시작과 다운이 반복되는 동안, 결국 4시간이 더 지나서야 원인을 찾아 해결할 수 있었다. 30분 점검 공지가 올라갔고, 조금 있다가 서버를 내렸다. 그리고 서버 패치를 부랴부랴 했다. 그리고 번개 같은 손놀림으로 서버를 다시 띄웠다. 양쪽 겨드랑이가 흥건하게 젖어 버렸다.
고맙게도, 기다려주던 열혈 유저들이 바로 접속을 해 주신다. 아까 동접자수도 거뜬히 넘겼다. 이제 좀 안정된 것 같다. 서버 관리 프로그램에서 보여주는 서버 상태 그래프는 아주 순탄했다. 사람들이 접속하면서 저레벨 필드에서 몹사냥을 시작했다. 여기저기서 재미있다는 감탄사가 들려왔다. 우리도 잠시 안도하면서 담배를 피우러 나갔다.
담배한대 물려는 순간, 저쪽에서 동료가 후다닥 뛰어온다. “1레벨 마을에서 랙이 심해요!” 우리는 담배를 후다닥 끄고 자리로 뛰어왔다. 게임을 테스트하던 동료의 화면을 봤다. 캐릭터가 사방팔방 워프를 하고 다니고 있었다. 서버 과부하 현상에서 나타나는 모양이다.
바로 내 자리로 돌아가서 1레벨 마을을 처리하는 서버 모니터를 켰다. 서버 CPU 사용량이 100%를 치고 있었다. 일반적으로 게임 서버는 50%대를 유지해야 안전한데 그 한계선을 넘어서 버린 것이다. 유저들이 모두 처음 게임을 하는지라, 모두가 1레벨 마을에 캐릭터가 등장(스폰)하기 마련인데, 그 바람에 1레벨 마을을 담당하는 서버에 과부하가 걸린 것이다.
PD가 와서 우리에게 해결책을 물었다. 응급조치로, 서버 채널 개수를 빨리 늘려야 한다고 제안했다. 운영팀은 15분 뒤 서버 점검을 공지하기로 하고, 점검 시간 30분 동안 서버 채널을 늘리기로 했다. 즉시 우리는 채널을 늘리기 위한 빈 서버를 세팅해달라고 퍼블리셔 측에 전화를 했다. 몇 분도 안 돼서, 퍼블리셔 측에서 준비가 다 됐으니 바로 쓰라는 연락이 왔다. 이러한 일을 예상하고 서버 장비들을 충분히 예비해 둔 퍼블리셔의 예지력에 감탄했다.
15분 뒤 점검이 시작된다는 공지 문구가 게임 화면 위를 지나가는 동안 전체 채팅창에는 유저들의 짜증 섞인 채팅들이 올라오기 시작했지만 그런 것에 마음 쓸 여유가 없었다. 머릿속에는 다른 아무 생각도 할 겨를도 없었다.
잠시 후 서버는 내려갔고, 우리는 신규 서버의 설정 변경을 거의 마쳐가고 있었다. 그 순간, 자기 자리에서 일하던 동료가 소리를 쳤다. “서버 안에서 다운되는 버그를 하나 찾았어요! 지속 힐 버프 있는 캐릭터에 광역 독 데미지 스킬을 쓰면 다운되는 경우가 있습니다. 패치가 필요합니다!”
맙소사. 점검은 앞으로 대략 10분 정도 안에 끝나야 하는데 서버 패치를 해야 한다고? “약속한 점검 시간은 지킵시다. 그냥 서버 올려요.” PD의 결정에 따랐다. 다시 서버를 올렸고, 유저들이 다시 쏟아져 들어왔다. 그 짧은 순간에 서버 채널을 늘리는 모습을 보고 칭찬하는 유저들도 있었다. 하지만 대부분의 유저들은 잦은 점검 때문에 이미 짜증이 날대로 나 있었다.
광역 독 데미지 관련 버그를 고치고 있는 동안 우리는 어느 누구도 그러한 짓을 하지 말기를 속으로 빌었다. 그리고 그 기대는 여지없이 깨져버렸다. 역시나! 누군가가 그 짓을 한 것이다. 일단 바로 서버를 띄우기로 했다. 자주 생기는 일은 아니니까.
“언제까지 고칠 수 있어요?” PD가 지친 목소리로 묻는다.
이번에는 빨리 고치기는 어려울 것 같다. 아무리 소스를 봐도 어디가 잘못된 것인지 알 수 없었다. 광역 독 데미지 같은 것은 서버에서 처리 방식이 복잡하다. 게다가 서버 부하도 많이 일으킬 수 있는 부분이다. 충분히 테스트해보고 넣었어야 했는데 막판에 급히 넣은 것을 후회하기 시작했다.
대답할 수 없었다. 그때, 인터넷에서 누군가가 한 말이 기억났다. 이럴 때는 일단 빼고 서버 올리라고.
[ ▲ 사실 필자가 한 말이다. ^^ ]
저쪽에서는 서버를 띄우고, 다운되는 현상이 일어나는 동안, 우리 서버 개발 파트는 새로 넣은 스킬을 막기 시작했다. 클라이언트파트도 새로 넣은 스킬을 쓰지 못하도록 하는 패치를 만들고 있었다. 새로 넣은 스킬을 완전히 막아버린 패치를 적용하기 위해, 30분 점검 공지를 올렸다. 그때까지 서버 다운과 재 시작이 여러 번 반복되었다고 한다. 유저 게시판은 안 봐도 뻔하다.
…
CBT를 시작한 지 3일이 지났다. 우리 개발팀은 다들 좀비가 되어 있었다. 집에 못 들어가고 잠도 몇 시간씩밖에 못 자면서 점검과 패치를 미친 듯이 했다. 1차 CBT에 서버를 24시간 틀어버리는 계획은 도대체 누구 머리에서 나온 것인지 모르겠다.
“오늘 점검만 10번째” “이따위 거지 같은 서비스로 무슨 클베를 하겠다고 ㅉㅉ“ “운영자님아 다들 집에서 놀고 계신감? ㅋㅋㅋ” 제발 집에서 놀고 싶다 이 사람들아… 운영팀도 다들 녹초가 됐다. 며칠째 집에 못 가고 과로로 생리 불순인 여성 직원도 생겼다고 한다.
…
드디어, 보름간의 지옥 같은 1차 CBT를 끝냈다. 간단하게 맥주 파티를 벌이고 다들 퇴근했다. 개발팀은 내일부터 2일간 휴가가 주어졌다. 하지만 집에서도 마음이 놓이지 않았다. 컴퓨터를 켜고 쌓여있는 유저 게시판을 들추어 봤다. 항의와 짜증과 격려가 뒤섞여 있었다. 이틀 뒤 출근했더니 운영팀에서 버그 제보를 모두 정리해서 우리에게 공유해 주었다. 5백여 가지의 제보 중 3백여 개는 2차 CBT 전에 서버 파트에서 모두 잡아야 한다.
퍼블리셔에서 연락이 왔다. 3개월 뒤에 2차 CBT를 해야 한다고. 이번에는 더 많은 사용자를 불러 모을 예정이란다. 일정은 고정되어 있으며, 연기 불가능하다고 한다.
기획팀에서는, 2차 CBT전에 중요 콘텐츠가 더 들어가야 한단다. 결정적으로, 이번 CBT를 통해 밸런스 문제가 심각하다는 것을 파악했고, 때문에 시스템 기획서를 대폭 수정할 것이라고 말한다.
다음 CBT가 끝날 때까지 매일 야근은 피할 수 없을 것 같다. 그래도 오픈베타테스트가 아니니 그나마 다행이다. 오픈베타테스트때 이렇게 서비스가 엉망이면 그때는 정말 답이 없었을 테니 말이다.
내 이름은 '오섭다'. 서버 개발팀에서 일하고 있다.
오늘은 무척 특별한 날이다. 2년 동안 만들던 게임을, 드디어 오늘! 1차 클로즈베타테트(이하 CBT)를 연다. 오늘을 위해 2개월간 연속된 야근을 했다. 이제 할 수 있는 모든 테스트를 마쳤다.
테스트하는 동안 여러 가지 새로운 기획도 들어갔다. 새로운 기획은 아직 테스트를 충분히 못 해서 불안하다. 시전하면 광역으로 독 데미지를 주는 법사 스킬은 어제 급하게 넣어서 더욱 걱정이다. 그렇다고 일정을 미룰 수는 없다. 이미 사업팀에서 클로즈베타 공고를 냈고 여기저기 웹진에 배너 광고를 올렸기 때문이다. 게다가 너무 오랫동안 야근하다 보니 지칠대로 지쳐서, 빨리 쫑을 보고 싶은 것이 지금의 심정이다.
CBT가 열리는 시간은 오후 2시로 공고가 나간 상태다. 점심을 서둘러 먹고 쉴 시간도 없이 바로 자리에 앉아, 각종 서버 상태를 몇 번이고 확인했다. 사내 접속만 허용한 채로 테스트를 해봤고, 아무 문제 없이 서버가 열리고 접속을 받을 수 있는 것도 확인했다. 이제 모든 것이 준비되었다.
1시 59분이다. 카운트 다운이 시작된다. 10,9,8,7,… 사람들이 뒤에서 따라 외친다. “오! 사! 삼! 이! 일!” 땡! 서버 프로그램 런칭 버튼을 눌렀다!
동시접속자수 0을 보여주던 서버 관리 프로그램이 보여주던 숫자가 파바박 올라가기 시작했다. 모니터 앞에 모여있던 사람들은 손에 땀을 쥐기 시작한다.
“와~ 잘 되는데?”
그 순간, 갑자기 0으로 추락해버린다. 0… 0… 0…
모니터를 바라보던 사장님과 PD의 얼굴이 새하얗게 변한다. 그리고 모두의 따가운 시선이 우리에게 꽂혔다. 서버 파트 동료는 어느 때도 본 적이 없는 번개 같은 손놀림으로 서버 프로그램 로그를 들추고 있다. 또 다른 동료는 키보드를 만지는 손이 덜덜 떨리고 있다. 다른 직원들은 급히 자기 자리로 돌아가서 직접 게임에 접속해본다. 나도 각 서버에 원격 모니터링을 켜서 각 서버의 실행 상태를 들춰보기 시작했다.
저쪽 운영팀 자리에서 웅성거리는 소리가 들린다. 게시판에 항의하는 글이 올라오고 있다고 한다. 대부분 짜증을 토로하는 글이고 일부는 욕설이지만, 일일이 응대하며 사과 댓글을 달아주고 있다. 그리고 몇몇 유저들은 게임 안에서 무엇을 하고 있었는지 친절하게 적어주셨다고 한다. 대부분이 비슷한 내용이다.
운영팀은 비슷한 것들을 취합해서 우리들에게 요약을 전달했다. 우리는 로그와 제보와 서버에 쌓인 오류 기록을 분석했다. 유저들의 제보에서 결정적인 원인을 짐작했다. 어이없게도, 서버 쪽 프로그램 한 줄에 부호가 잘못 들어간 것을 찾아낸다. PD에게 보고했고 금방 고칠 수 있다고 말해주었다.
그리고 PD가 크게 소리쳤다. “운영팀! 사과 공지하시고 서버 30분 뒤에 재시작 공지하세요! 서버팀! 15분안에 패치 완료하세요!”
자동화된 빌드 시스템과 서버 자동 패치 시스템을 구축해놓았으니 망정이지, 이나마도 안 해놨으면 십여 대가 넘는 서버 머신에 15분 안에 서버 패치를 하는 것은 불가능했을 것이다. 30분간의 점검을 끝내고 서버를 다시 띄웠다. 동시접속자는 동시접속자수는 다시 0부터 시작해, 아까와 마찬가지의 속도로 상승하기 시작했다.
“아! 이번에는 제발 잘 되기를!”
동시접속자가 늘어나고 있는데, 갑자기 동시접속자수에 변화가 없다. 숫자가 전혀 변하지 않는다. 사람들이 수군거린다. “뭐지? 이상한데?” 서버팀 프로그래머들은 잽싸게 자기 자리로 뛰어갔다. 서버가 작동은 하고 있는데 어디선가 막혀버렸다. 이른바 데드락(dead lock. 서버는 작동하고 있지만, 내부 로직이 교착에 걸려서 진행이 멈춰버린 상태) 현상 같다는 육감을 느꼈다. 우리는 즉시 여기저기 서버 모니터를 확인했다. 서버 처리량이 0%를 찍고 있는 곳을 찾았다.
“사실상 서버 다운입니다. 빨리 고칠게요.”
“얼마나 걸리나요?”
“이번에는 모르겠어요. 원인을 찾아야 말씀드릴 수 있습니다.”
운영팀은 30분 점검을 공지했다. 우리 서버 개발 파트는 평소 본 적이 없는 매서운 눈빛으로(그리고 창백한 얼굴로) 시커먼 창을 열었다 닫았다 한다. 30분이 지났지만 우리는 여전히 원인을 모른다.
“1시간 더 걸릴 것 같아요.”
점검이 1시간 연기되었다. 조금 있다가 드디어 저쪽에서 서버 프로그래머 한 명이 소리친다. “찾았습니다! 바로 고치죠!” 프로그램팀장이 소리친다.
“고친 서버 잘 작동하는지 내부 테스트 돌려봐요!”
아뿔싸. 사내 테스트 서버가 바로 다운되었다. 서버 프로그래머들은 수정한 것 어딘가에서 부작용을 일으킨 것으로 파악했다. 큰일이다. 안 고치면 서버가 얼어버리고 고치면 서버가 다운된다. 원인은 더욱 오리무중이다. 점검 시간을 더 늘릴 수는 없었다. 일단 지금 상태의 서버를 띄웠다. 곧 다시 다운되겠지만 어쩔 수 없다. 우리 서버파트는 미친 듯이 버그의 원인을 찾아다녔다. 백사장에서 바늘 찾는 기분이었다.
서버 시작과 다운이 반복되는 동안, 결국 4시간이 더 지나서야 원인을 찾아 해결할 수 있었다. 30분 점검 공지가 올라갔고, 조금 있다가 서버를 내렸다. 그리고 서버 패치를 부랴부랴 했다. 그리고 번개 같은 손놀림으로 서버를 다시 띄웠다. 양쪽 겨드랑이가 흥건하게 젖어 버렸다.
고맙게도, 기다려주던 열혈 유저들이 바로 접속을 해 주신다. 아까 동접자수도 거뜬히 넘겼다. 이제 좀 안정된 것 같다. 서버 관리 프로그램에서 보여주는 서버 상태 그래프는 아주 순탄했다. 사람들이 접속하면서 저레벨 필드에서 몹사냥을 시작했다. 여기저기서 재미있다는 감탄사가 들려왔다. 우리도 잠시 안도하면서 담배를 피우러 나갔다.
담배한대 물려는 순간, 저쪽에서 동료가 후다닥 뛰어온다. “1레벨 마을에서 랙이 심해요!” 우리는 담배를 후다닥 끄고 자리로 뛰어왔다. 게임을 테스트하던 동료의 화면을 봤다. 캐릭터가 사방팔방 워프를 하고 다니고 있었다. 서버 과부하 현상에서 나타나는 모양이다.
바로 내 자리로 돌아가서 1레벨 마을을 처리하는 서버 모니터를 켰다. 서버 CPU 사용량이 100%를 치고 있었다. 일반적으로 게임 서버는 50%대를 유지해야 안전한데 그 한계선을 넘어서 버린 것이다. 유저들이 모두 처음 게임을 하는지라, 모두가 1레벨 마을에 캐릭터가 등장(스폰)하기 마련인데, 그 바람에 1레벨 마을을 담당하는 서버에 과부하가 걸린 것이다.
PD가 와서 우리에게 해결책을 물었다. 응급조치로, 서버 채널 개수를 빨리 늘려야 한다고 제안했다. 운영팀은 15분 뒤 서버 점검을 공지하기로 하고, 점검 시간 30분 동안 서버 채널을 늘리기로 했다. 즉시 우리는 채널을 늘리기 위한 빈 서버를 세팅해달라고 퍼블리셔 측에 전화를 했다. 몇 분도 안 돼서, 퍼블리셔 측에서 준비가 다 됐으니 바로 쓰라는 연락이 왔다. 이러한 일을 예상하고 서버 장비들을 충분히 예비해 둔 퍼블리셔의 예지력에 감탄했다.
15분 뒤 점검이 시작된다는 공지 문구가 게임 화면 위를 지나가는 동안 전체 채팅창에는 유저들의 짜증 섞인 채팅들이 올라오기 시작했지만 그런 것에 마음 쓸 여유가 없었다. 머릿속에는 다른 아무 생각도 할 겨를도 없었다.
잠시 후 서버는 내려갔고, 우리는 신규 서버의 설정 변경을 거의 마쳐가고 있었다. 그 순간, 자기 자리에서 일하던 동료가 소리를 쳤다. “서버 안에서 다운되는 버그를 하나 찾았어요! 지속 힐 버프 있는 캐릭터에 광역 독 데미지 스킬을 쓰면 다운되는 경우가 있습니다. 패치가 필요합니다!”
맙소사. 점검은 앞으로 대략 10분 정도 안에 끝나야 하는데 서버 패치를 해야 한다고? “약속한 점검 시간은 지킵시다. 그냥 서버 올려요.” PD의 결정에 따랐다. 다시 서버를 올렸고, 유저들이 다시 쏟아져 들어왔다. 그 짧은 순간에 서버 채널을 늘리는 모습을 보고 칭찬하는 유저들도 있었다. 하지만 대부분의 유저들은 잦은 점검 때문에 이미 짜증이 날대로 나 있었다.
광역 독 데미지 관련 버그를 고치고 있는 동안 우리는 어느 누구도 그러한 짓을 하지 말기를 속으로 빌었다. 그리고 그 기대는 여지없이 깨져버렸다. 역시나! 누군가가 그 짓을 한 것이다. 일단 바로 서버를 띄우기로 했다. 자주 생기는 일은 아니니까.
“언제까지 고칠 수 있어요?” PD가 지친 목소리로 묻는다.
이번에는 빨리 고치기는 어려울 것 같다. 아무리 소스를 봐도 어디가 잘못된 것인지 알 수 없었다. 광역 독 데미지 같은 것은 서버에서 처리 방식이 복잡하다. 게다가 서버 부하도 많이 일으킬 수 있는 부분이다. 충분히 테스트해보고 넣었어야 했는데 막판에 급히 넣은 것을 후회하기 시작했다.
대답할 수 없었다. 그때, 인터넷에서 누군가가 한 말이 기억났다. 이럴 때는 일단 빼고 서버 올리라고.
저쪽에서는 서버를 띄우고, 다운되는 현상이 일어나는 동안, 우리 서버 개발 파트는 새로 넣은 스킬을 막기 시작했다. 클라이언트파트도 새로 넣은 스킬을 쓰지 못하도록 하는 패치를 만들고 있었다. 새로 넣은 스킬을 완전히 막아버린 패치를 적용하기 위해, 30분 점검 공지를 올렸다. 그때까지 서버 다운과 재 시작이 여러 번 반복되었다고 한다. 유저 게시판은 안 봐도 뻔하다.
…
CBT를 시작한 지 3일이 지났다. 우리 개발팀은 다들 좀비가 되어 있었다. 집에 못 들어가고 잠도 몇 시간씩밖에 못 자면서 점검과 패치를 미친 듯이 했다. 1차 CBT에 서버를 24시간 틀어버리는 계획은 도대체 누구 머리에서 나온 것인지 모르겠다.
“오늘 점검만 10번째” “이따위 거지 같은 서비스로 무슨 클베를 하겠다고 ㅉㅉ“ “운영자님아 다들 집에서 놀고 계신감? ㅋㅋㅋ” 제발 집에서 놀고 싶다 이 사람들아… 운영팀도 다들 녹초가 됐다. 며칠째 집에 못 가고 과로로 생리 불순인 여성 직원도 생겼다고 한다.
…
드디어, 보름간의 지옥 같은 1차 CBT를 끝냈다. 간단하게 맥주 파티를 벌이고 다들 퇴근했다. 개발팀은 내일부터 2일간 휴가가 주어졌다. 하지만 집에서도 마음이 놓이지 않았다. 컴퓨터를 켜고 쌓여있는 유저 게시판을 들추어 봤다. 항의와 짜증과 격려가 뒤섞여 있었다. 이틀 뒤 출근했더니 운영팀에서 버그 제보를 모두 정리해서 우리에게 공유해 주었다. 5백여 가지의 제보 중 3백여 개는 2차 CBT 전에 서버 파트에서 모두 잡아야 한다.
퍼블리셔에서 연락이 왔다. 3개월 뒤에 2차 CBT를 해야 한다고. 이번에는 더 많은 사용자를 불러 모을 예정이란다. 일정은 고정되어 있으며, 연기 불가능하다고 한다.
기획팀에서는, 2차 CBT전에 중요 콘텐츠가 더 들어가야 한단다. 결정적으로, 이번 CBT를 통해 밸런스 문제가 심각하다는 것을 파악했고, 때문에 시스템 기획서를 대폭 수정할 것이라고 말한다.
다음 CBT가 끝날 때까지 매일 야근은 피할 수 없을 것 같다. 그래도 오픈베타테스트가 아니니 그나마 다행이다. 오픈베타테스트때 이렇게 서비스가 엉망이면 그때는 정말 답이 없었을 테니 말이다.
상용화와 라이브팀
몇 차례의 클로즈베타테스트를 진행하는 동안 서버와 클라이언트는 충분한 안정성을 갖추어 나간다. 클로즈베타를 충분히 하고 나면, 오픈베타서비스를 준비하기 시작한다. 오픈베타는 상당히 많은 마케팅을 투입해 일정을 홍보한다. 그러다 보니, 요새 오픈베타는 사실상 공식적인 릴리즈에 가깝게 취급하기도 한다. 이 기간의 서비스 불안정은 악몽 중의 악몽이 될 수밖에 없다.
마지막 클로즈베타 이후 오픈베타 시작 전까지의 개발 기간은 안정화와 버그 패치, 성능 튜닝과 밸런싱 등 이른바 ‘마무리 작업’에 집중을 한다. 이 기간동안에는 새로운 기획 내용이 반영되는 등의 대폭의 변화를 가하지 않는다. 초기 클로즈베타때같이 불안정함을 다시 재발한다는 위험이 있기 때문이다. 그럼에도 불구하고 오픈 베타를 시작하자마자 서비스가 불안정한 상황이 가끔 발생한다. 클로즈베타때보다 훨씬 많은 사람들이 접속을 하기 때문이다.
클로즈베타때와 달리 오픈베타때는 아주 조금이라도 서버가 불안정하면 차원이 다른 악몽이 펼쳐진다. 서버 개발자들은 오픈베타 시작 후 몇일간 밤샘하는 것은 기본이다. 오픈베타가 충분히 안정성이 갖춰질 때까지 혼신을 다해 모두가 노력하고 나면 그토록 기다리던 상용화 공표를 하게 된다.(부분 유료화 게임에서는 조용히 상용화를 선언하기도 한다.) 상용화 이후 게임 개발팀은 라이브팀 체제로 편성된다. 라이브팀은 기존에 서비스 중인 게임 프로젝트에 지속적으로 다양한 콘텐츠를 추가하는 역할을 한다. 패키지 게임으로 치자면 확장팩 개발에 준하는 역할을 한다.
상용화된 게임이 오랫동안 유저들의 사랑을 받기 위해서는 꾸준히 새로운 콘텐츠가 들어가 줘야 한다. 라이브팀은 설날이나 크리스마스 이벤트 같이 작은 콘텐츠 업데이트뿐만 아니라 새로운 월드와 에피소드를 추가하는 대규모 업데이트를 하기도 한다.
금융 업계에서의 전산 시스템은 아직도 COBOL이라는 50년 넘은 프로그래밍 언어가 사용되고 있다. 은행처럼 사소한 버그 하나만 발생해도 대재앙이 발생하는 분야에서 이미 작동 중인 전산 시스템을 손대는 것에 신중에 신중을 기해야 하기 때문이다.
게임 서버와 클라이언트도 마찬가지다. 이미 상용화되어서 많은 유저들이 즐기는 게임 프로그램을 손대는 것도 무척 신중하게 해야 한다. 상용화를 하기 전에 토 나올 정도의 테스트와 검증을 이미 마친 상태에서 새로운 콘텐츠나 시스템이 추가되기 마련이다. 그러나 새로 추가된 것들도 실제 유저들을 대량으로 붙여서 테스트와 검증하지 못하고, 그러다 보니, 다시 한번 서비스의 혼란을 일으킬 수 있다.
불행히도, 이미 상용화된 상태에서 서비스가 불안정해지면 그 파장은 상상하기 힘들 정도다. 클로즈베타테스트야 이름 그대로 테스트기 때문에 사용자들이 뭐라 말하지 못하지만, 이미 상용화했고 사용료까지 지불하는 입장에서 서비스가 불안정해지는 것을 용납하지 않기 때문이다.
결국, 이러한 위험을 줄이기 위해 상용화된 게임이라 하더라도 콘텐츠 업데이트를 할 때 여전히 베타테스트를 해야 한다. 테스트 서버라는 것을 별도로 운영하는 이유가 여기에 있다.
게임 서버 개발자로서 게임 시스템에 변화를 가하는 업데이트는 부담이 크다.
특히 사용자 계정 정보의 구조(소유 캐릭터나 아이템 등)에 변화를 가해야 하는 업데이트가 있을 수 있는데, 이는 매우 신중하게 접근해야 한다. 잘못 접근하면 밸런스 때문에 욕을 먹는 것은 물론이고, 최악에는 계정 정보가 한꺼번에 훼손돼 돌이킬 수 없는 상황을 만들 수도 있다.
계정 정보의 구조를 바꿔야 할 때는 스탯 리셋 등을 해줘야 한다. 약간의 꼼수이긴 하지만, 구조 변경과 계정 정보 훼손이 불가피하면 약간의 전체 상향 패치를 대가로 하는 훼손을 해버리기도 한다.
이는 계정 정보 구조에 변화를 가하는 패치를 했기 때문이다. ]
한번 만들어진 게임 서버 프로그램은 손대기 어렵다. 계속해서 콘텐츠가 들어가다 보면 점점 구조가 배배 꼬이게 된다. 이른바 스파게티 코드 현상이 누적된다. 이를 한번에 싹 재구조화하고 싶을 때가 종종 있지만 고참 서버 프로그래머가 말린다. 그만큼 이미 만들어진 것을 손대는 것은 위험할 수 있기 때문이다.
상용 서비스를 시작한 온라인 게임들을 보면, 시즌 업데이트의 콘텐츠 추가는 많지만 정작 기반 시스템은 별 변화가 없는 것이 이러한 이유 때문이기도 하다.
※ 본 기획기사는 4부 '섭다, 랙, 백섭, 해킹, 프리섭에 대한 소개'를 주제로 이어집니다.
desk@inven.co.kr