강연을 진행한 넥슨 김준엽 팀장은 "기존 흥행작에 라이브 개발자로서 참여하게 되는 것은 한편으로는 거대한 부와 명예를 가져다 주는 유산을 상속받는 듯한 느낌이지만, 다른 한편으로는 살 수도, 잘 수도, 비바람을 피할 수도 없는 파르테논 신전 같은 고대의 유물을 물려받는 느낌이 공존한다"고.
라이브 개발에 처음 몸담게 되는 개발자는 우선 절망을 하기 마련이다. 그런 절망을 딛고서 찬연히 불타올라 '자신의 힘으로 혁명을 이루겠다'는 거대한 이상을 꿈꾸게 된다고. 그러다 개발현실과 부딫히다 보면 자연스럽게 어느 적정 수준에서 타협하게 되고, 그렇게 타협으로 이룬 결과물을 두고서 스스로 자기 합리화하는 수순을 자연스럽게 밟게 된다 - 이렇게 말하자 좌중에서는 웃음이 터져 나왔다.
그렇게, 메이플스토리와 함께 하면서 겪었던 사례를 크게 네 가지로 묶어서 설명했다.
1. 낡아버린 시스템
메이플 스토리가 어느덧 서비스 8년차, 개발기간을 감안하면 가히 10년차 게임이라고 해도 좋을 정도로 고대의 시스템으로 무장되어 있다. 때문에 최근의 트렌드에 맞춰 업데이트를 진행하거나 패치를 진행할 때마다, 낡은 시스템에 의해 많은 비효율이 발생하기 마련이다.
때문에, 이러한 비효율이 발생하는 시스템을 한번에 갈아엎어 버리는 것이 최선이겠지만, 라이브 게임의 개발인 이상 그렇게는 절대로 할 수 없다. 때문에 기존의 시스템과 연동되는 시스템을 추가로 구축해야하며, 이 과정에서 항상 고민이 되는 부분이 "어떻게 하면 최대한 손을 덜 대고서 문제를 해결할 수 있을까"라고.
시작하자마자 I/O 라이브러리가 문제가 발생했다. 오래전에 유행했던 시스템으로 낡은 인터페이스에 함께 업무하는 기획자들의 불만또한 만만치 않았다고. 허나 이걸 모두 엎을 수는 없는 일. 기존의 라이브러리를 그대로 살려두고서, 더 편한 환경을 구축할 수 있도록 인터페이스를 다듬으면서, 군데군데 범용 프로그램의 도움으로 기획자들이 작업하기에 더욱 편한 환경을 구축하는 데 성공했다고.
개발자가 아닌 사람이 이해하기에는 상당히 전문적인 내용의 강연이었지만, 오래된 것과 새로운 요구 사이에서 절충안을 찾아내는 방법에의 요지는 충분히 이해할 수 있었다.
2. 묻어가기 전략
메이플스토리 최초의 장기 프로젝트는 '해적'이었는데, 약 1년간의 기간을 두고서 개발이 진행되었다. 문제는 게임이 이미 라이브 된 상황이기 때문에 해당 프로젝트 개발을 위해 라이브 중인 게임을 중단할 수는 없는 일. 개발 일정과는 별도로 계속해서 상용 업데이트가 반복되어, 해당 업데이트가 계속적으로 게임에 적용되는 동안에도 개발은 계속된다.
헌데, 해적 프로젝트의 경우 장기 계획을 잡아서 개발에 착수하고, 개발을 완료한 단계에서 다시 원래의 게임으로 다시 합류시키려고 하면 높은 확률로 문제를 만나게 된다. 장기간 본류에서 떠나 개발을 했던 내용과, 지속적으로 업데이트를 거듭한 내용이 충돌을 하기 마련. 그나마 코드는 나은 편이다. 업데이트를 통해서 달라진 데이터의 경우는 손을 댈 수 없을 정도. 때문에, 장기프로젝트의 개발에 있어 그 작업환경을 아예 본류(Trunk)로 바꾸는 전략이 더 효율적이라는 결론을 얻었다고.
단, 이런 경우 문제가 두가지 생긴다. 장기 개발내용이 라이브되는 게임에 함께 포함되어 있기 때문에 실제 게임에 영향을 미칠 수 있는 부분과, 클라이언트 배포시 해당 개발 내용까지 함께 포장(packing)되어 외부로 내용이 사전에 유출될 우려가 있다는 점.
이를 방지하기 위해 작업 중인 영역은 비활성화 시키는 조치가 필요하며, 상시 업데이트가 적용된 직후에 가급적 덩지가 큰 일, 다음 업데이트가 가까워지는 시점에서는 덩지가 작은 일을 배치하는 형태의 업무배분도 필요하다. 또한 클라이언트 배포시에 개발 중인 내용이 포함되지 않도록 점검하는 과정에서 실수가 생길 여지가 없게끔, 포장하는 과정에서 특정 영역에 존재하는 특정 데이터를 제외하게끔 장치를 삽입해 그러한 문제를 성공적으로 차단했다고 밝혔다.
3. 물량러시에 대처하는 자세
메이플스토리 빅뱅 업데이트 때 실제로 겪은 일.
대략 1500종의 몬스터에 포함된 26가지 가량의 속성을 모조리 바꿔야 하는 상황. 일일이 수작업으로 입력하자면 약 3만 9천건을 수정해야 하며, 그마저도 한 번만에 OK가 될 리 없다. 특정 데이터는 몇번이고 재수정해야할지 모르기에 작업량이 얼마가 나올지 짐작조차 안되는 상황. 이걸 수작업으로 진행하는 것은 말도 안되는 일. "어떻게 하면 이걸 깔끔하게 할 수 있을까?" 고민이 시작되었다.
해답의 키워드는 세가지. 일괄처리, 자동생성, Excel.
ㅇ 수치마다 일일이 수작업으로 수정하는 대신, 전체 데이터를 한꺼번에 불러와서 수정/저장할 수 있는 방법
ㅇ 사소한 수치값의 개성을 고려하는 대신, 특정 레벨에 맞춰서 필요한 속성값들을 자동으로 생성해주는 기능
ㅇ 기획자들에게 친숙한 Excel환경으로 버튼 클릭 한 번에 손쉽게 Data를 가져올 수 있도록 시스템을 고안했다고.
4. 외계문명 도입
해당 사례는 가장 최근 카오스 - 대난투 업데이트를 거치면서 겪은 일. 앞서 강연의 발표자와 대립되는 이야기라 그런지 좌중의 웃음이 짙어갔다.
개발자인 강연자 앞에 떨어진 난제는 바로 메이플스토리에서 PVP를 구현하는 것. 허나 이게 만만치 않은 일. 애초에 메이플스토리의 전투는 플레이어와 몬스터 사이만을 상정하고 만들어져 있다. 때문에 플레이어가 사용하는 스킬의 대상에 다른 플레이어는 전혀 고려되지 않은 상황.
게다가 메이플스토리는 전투 판정 자체가 클라이언트 내에서 이루어진다. 때문에 서버와 클라이언트간 패킷 교환이 그만큼 적게, 덜 이루어진다. 즉 다른 유저의 행동에 내가 피해를 받았을 때, 그 상호작용에 대해 서로 시간차가 발생할 수 밖에 없는 구조.
게다가, 메이플스토리에 포함된 모든 필드들마다 각각의 고유번호를 가지기 때문에, 일반적인 방파기 대전 게임처럼 임의로 공간을 만들어 여러사람이 한 곳에 모이고, 언제든지 해당 공간을 없앨 수 있는 그런 형태가 애초에 아니라는 것.
한 마디로 현재의 서버에서는 PVP를 구현하는 것은 불가능하다. 그런데 PVP를 구현하려면?
결론은 새로운 시스템을 만들자였다. 기존의 서버와는 완전히 다르게 동작하는 새로운 서버를 만들어, PVP에 관련된 처리만 해당 서버를 거치는 형태로 가닥을 잡았다.
기존의 스킬에 대해 편차를 넣는 시스템을 구현해 PVP용으로 별도로 적용하고, 기존의 처리방식과는 다르게 모든 데미지 판정을 서버에서 처리하도록 하였으며, 기존의 규칙과 다르게 하나의 템플릿에 여러개의 멀티 인스턴스 필드를 만드는 형태.
기존의 서버 내에서 포함된 필드 관리 시스템과 별도로 별도의 PVP 필드 관리 시스템을 구현, 기존과 시스템과 유사하나 다른 성격을 가지는 시스템을 같은 서버에 넣어 동시에 두가지 성격을 가지는 필드를 하나의 공간 내에 구현했다고.
메이플스토리의 라이브 개발을 통해 겪은 다양한 경험을 청중과 공유하면서, 그 경험을 통해 배운 경험을 두가지로 요약했다.
하나는 가진 것을 최대로 활용하는 것. 새로운 것은 물론 좋지만, 기존의 유산 중에서도 쓸만한 부분을 통해 더 나은 결과를 내놓는 것이 중요하다. 다른 하나는 시스템에 미치는 영향을 최소화하는 것. 혁명적인 시도가 좋아보일 진 몰라도, 변화가 많을 수록 부작용과 버그도 그만큼 많을 수 밖에 없다.
개발자들을 위한 조언임에도 인생의 묘리에 와닿는 말과 함께, Best 보다는 Better를 위해 노력하는 것이 라이브 개발자의 마인드가 아닐까 - 라는 말을 끝으로 강연은 박수 속에 마무리 되었다.
desk@inven.co.kr