[게임DB] 2화. 만일 게임에 DB가 없다면?

지난 1화에서 DB와 DBMS가 무엇인지, 그리고 게임에서 DBMS가 얼마나 중요한지 간단하게 알아봤습니다.

이번에는 중요한 역할을 하는 ‘DBMS가 없이 게임을 만든다면 어떤 일이 일어날까?’하는 가정 아래 DB의 역할을 풀어보겠습니다. (사실, 개인적으로는 이런 끔직한 상상을 하고 싶지 않습니다. 절대로!)

‘게임에 DB가 없다면?’이라는 상황을 정확하게 전달 하기 위해서, 우선 DB가 원래 어떤 일들을 하고 있었는지 살펴보겠습니다. 보다 정확한 답이 나올 것 같네요.

지난 회에서 말한 것처럼 DBMS를 간단히 DB라고 습관적(?)으로 줄여서 부르고 있는데요, DBMS는 데이터베이스(Database)를 관리하는 플랫폼입니다.

게임엔진이 클라이언트에 필요한 그래픽, 사운드, 물리엔진 등의 기능에 초점이 맞춰져 있는 것처럼, DBMS는 데이터 관리를 위한 기능에 초점이 맞춰져 있는 엔진입니다.

DBMS의 기본적인 기능이 바로 데이터의 단위(보통 테이블이라고 부름)를 설정하고 그 데이터의 단위를 관리하기 위한 기본적인 기능인 입력, 수정, 검색, 삭제 연산을 쉽고 빠르게 할 수 있도록 하는 것 입니다. 이런 일련의 데이터베이스 조작을 줄여서 ‘CRUD’라고 합니다.

이런 기본적인 기능 외에도 저장된 데이터의 관리를 위한 수많은 기능들이 제공되고 있습니다. 수많은 기능들 중에서도 게임(특히 다수의 사용자가 동시에 플레이 하는 MMORPG의 경우)을 위해서 가장 중요한 기능이 바로 ‘트랜잭션’의 처리입니다.

트랜잭션은 데이터베이스의 완정성(혹은 무결성)을 보장하는 기능으로, 일련의 여러 작업을 하나의 단위로 처리할 수 있게 해주는 기능을 말합니다. 다른 말로는 ‘논리적 작업단위’(LUW, Logical Units of Work)라고도 합니다. 이런 단일 트랜잭션은 데이터베이스 내에 읽거나 쓰는(CRUD) 하나 이상의 단위 작업들로 구성됩니다.

(삽화: onesound)

트랜잭션 처리의 4대 특성 - ACID Atomic, Consistency, Isolation, Durability

데이터베이스 시스템은 사용자가 데이터베이스의 완전성 유지를 확신하도록 만들기 위해서 트랜잭션 기능을 제공합니다.

데이터베이스 시스템은 트랜잭션 기능을 제공함에 있어서 각각의 트랜잭션에 대해 원자성(Atomic), 일관성(Consistency), 고립성(Isolation), 영구성(Durability)을 보장해야 합니다. 이 4가지 원칙을 트랜잭션의 4대 특성집합이라고 부르고, 간단히 ACID라고 표현합니다.

트랜잭션에 대한 내용이 무척 어려운 이야기입니다만, 실제로 예를 들어 설명을 하면 누구나 당연히 지켜져야 하는 특성이라는 것을 이해할 수 있을 것입니다.

보통 ACID를 설명하기 위해서 은행 계좌이체를 예로 많이 듭니다. 이해하기도 쉽죠. 하지만, 우리는 게이머이니까 게임 내에서 이루어지는 행동을 통해서 이 4대 특성을 이해해 보도록 하겠습니다.

원자성 - 트랜잭션 관련 작업들이 모두 수행 되었는지, 아니면 모두 실행이 안 되었는지를 보장하는 특성입니다. 온라인게임에서 게이머간 거래를 할 경우를 생각해 보겠습니다.

캐릭터 ‘카제란’은 자신이 가진 최고가의 아이템 ‘멋쟁이 샤프롱’을 지크프리트에게 개인 거래로 팔려고 합니다. 우선 지크프리트에게 거래신청을 하고, 샤프롱을 거래창에 올려놓습니다.

상대방은 카제란이 거래창에 올려놓은 아이템이 ‘멋쟁이 샤프롱’이 맞는지 확인한 뒤에 대금인 5천만 머니를 거래창에 올려놓습니다. 카제란은 지크프리트가 올려놓은 금액을 확인하고, 거래확인 버튼을 누릅니다.

지크프리트는 ‘멋쟁이 샤프롱’을 다시 한번 확인하고 확인 버튼을 누릅니다. 이제 거래가 완료됐습니다.

자, 여기서 우리는 한 번의 거래를 했으니까 단순하게 생각할 수도 있습니다만, 실제로 보이는 것과는 다르게 게임 서버에서는 4번의 데이터베이스 연산이 일어나고, 이런 일련의 연산들이 하나의 트랜잭션으로 처리가 됩니다.

교환 트랜잭션 시작 (begin transaction ‘TRADE’)   ① 카제란의 인벤토리에서 ‘샤프롱’을 지운다. ② 지크프리트의 인벤토리에 ‘샤프롱’을 넣는다. ③ 지크프리트의 인벤토리에서 5천만 머니를 지운다. ④ 카제란의 인벤토리에 5천만 머니를 넣는다.   교환 트랜잭션 완료 (commit transaction ‘TRADE’)

즉, 처음부터 거래가 되지 않은 것과 같은 상태로 되돌립니다. 이것이 보장되지 않는다면 일어날 수 있는 일들은 너무 많겠죠? 잘 모르겠다고요?

자, 그럼 한번 생각을 해보죠. 지크프리트의 인벤토리에 샤프롱을 넣는 조작을 하려고 하는데, 지크프리트의 인벤토리가 이미 꽉 차서 넣을 수가 없어 실패를 했음에도 불구하고, 3번, 4번의 과정을 실행해 버리면, 지크프리트는 샤프롱을 받지 못하고 5천만 머니를 날리게 됩니다.

하지만 카제란에게도 샤프롱은 이미 없습니다. 되돌릴 수가 없죠. 지크프리트만 큰 손해를 봤습니다. 반대로 카제란의 소지금액이 한계치만큼 꽉 차 있다면(그럴 리가 없겠지만, 한번 그래 보고 싶습니다. +_+), 지크프리트는 샤프롱을 받았고 5천만 머니도 지불했지만, 카제란은 5천만 머니를 받지 못하게 됩니다. 카제란은 억울합니다.

이 정도는 뭐 특별한 문제가 아닐 수도 있다거나(그럴리가;;), 아직도 왜 이것이 중요한지 모르겠다는 분을 위해서 실제 서비스를 했던 온라인게임에서 이 원자성 원칙이 깨지면서 발생했던 돈 복사 사건을 예를 들어 보겠습니다.

서비스 중이던 모 게임에서 일어났던 일로, 창고의 역할을 하는 은행에 돈을 보관하는 과정에서 트랜잭션의 원자성이 지켜지지 않아 은행에 돈은 보관이 됐지만, 인벤토리에 있던 돈은 줄지 않던 버그가 발생했습니다.

이런 예상치 못했던 ‘돈 복사 버그’가 며칠 동안 발생하면서 게임 내에 엄청난 인플레이션 현상이 일어났던 적이 있습니다.

결국 은행에 돈을 보관하는 일련의 과정 중 은행에 돈을 넣는 데이터베이스 연산은 정상적으로 이루어졌지만, 인벤토리 내의 캐릭터 소지 금액에서 차감하는 데이터베이스 연산이 정상적으로 이루어지지 않아서 발생한 문제였습니다. 두 개의 작업을 하나의 트랜잭션으로 처리하지 않았기 때문에 원자성이 지켜지지 않아서 생겼던 문제로 파악이 되었죠.

일관성 – 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미합니다.

원자성을 설명하면서 예로 들었던 카제란의 소지금액이 최대치에 달했다거나, 인벤토리에 여유공간이 없다는 것과 같은 제약조건이 있다면 해당 트랜잭션은 전체적으로 중단되어야 한다는 것을 의미합니다.

또한, 완료된 트랜잭션이라면 앞서 설명한 제약조건에서 자유롭다는 것을 보장해야 한다는 것입니다. 제약조건에 위배되지 않았음에도 불구하고 실패를 하거나 제약조건에 위배됨에도 불구하고 트랜잭션이 성공하는 일은 있을 수 없다는 것을 데이터베이스 시스템이 항상 보장해 줘야 한다는 것이죠.

다시 한번 강조하지만, 트랜잭션은 작업의 단위이지 작업 내의 각각의 실행단위가 아닙니다. 교환은 트랜잭션이며, 교환 도중에 일어난 각각의 실행 단위는 데이터베이스 연산으로 트랜잭션을 구성하는 부품과 같은 요소들입니다.

독립성 - 트랜잭션을 수행할 때 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미합니다.

예를 든 교환 트랜잭션의 처리 중에 바닥에 있는 돈을 줍는다고 해서 이 트랜잭션이 교환 트랜잭션 작업 중간에 끼어들어서는 안 된다는 것입니다. 이 부분에서 게이머는 실제로 DB를 처리하는 단위를 느끼지 못할 가능성이 높습니다. 

교환 도중에 다른 행위를 클라이언트 단위에서 막을 수도 있고, 실제로 교환 트랜잭션을 처리하는 것은 교환 트랜잭션을 완료하고 나서 할 수도 있기 때문입니다.

하지만, 실제 데이터베이스 연산 작업을 수행함에 있어서 교환 트랜잭션을 처리하는 도중 다른 어떠한 트랜잭션도 중간에 끼어들지 않아야 합니다.

만약 카제란이 교환 도중 2만 머니를 주웠다고 하더라도, 교환 트랜잭션이 끝나기 전에 2만 머니에 대한 습득을 반영하게 되면 교환 트랜잭션에서는 그전에 갖고 있던 머니에 오천만 머니를 추가하는 트랜잭션을 처리해야 합니다. 그렇지 않다면, 카제란의 소유 금액에 차이가 발생할 수 있습니다.

사실 이 부분은 데이터베이스 시스템의 성능에 미치는 영향이 크다 보니 각 제품마다 어느 정도 유연하게 대처하고 있는 상황이고, 이 부분을 얼마나 효율적으로 구현하였는가와 사용자(개발자)가 얼마나 잘 사용하느냐에 따라 초당 처리 가능한 트랜잭션의 수(TPS : Transaction per second)가 결정됩니다. 온라인게임의 성능에 직결되는 중요한 요소라도 할 수 있죠.

지속성 - 성공적으로 수행된 트랜잭션은 영원히 반영이 되어야 함을 의미합니다.

이건 굳이 따로 설명할 필요가 없을 정도인데요, 교환 트랜잭션이 성공적으로 완료되고 난 후에 갑자기 교환이 취소되거나 해서는 안되고, 교환이 성사된 상태로 유지되어야 한다는 것입니다. 한 번 성공한 트랜잭션의 결과는 온전히 반영되고, 다른 어떠한 요소에 의해서 변질이 되어서는 안 된다는 것입니다.

여기까지 트랜잭션의 4대 특성이라고 불리는 ACID에 대해서 알아보았습니다. 사실 꽤 어려운 이야기라서 제대로 전달이 안 됐으면 어떻게 하나 걱정이 앞섭니다.

하지만 정말 중요한 것이 트랜잭션이고, 트랜잭션을 얘기하면서 ACID를 빼놓을 수 없어 약간은 무리하게 내용을 진행할 수 밖에 없었습니다.

최소한 게임 내에서 동시다발적으로 일어나는 사건들은 하나의 논리적인 데이터베이스 조작(연산)의 단위인 트랜잭션으로 처리되지 않으면, 반영된 데이터들이 정확하다고 보장할 수 없다는 것입니다.

온라인게임에서 모든 정보는 DB에 저장됩니다. 하지만 언제나 사고는 예고 없이 일어나죠. 불시의 사고와 재해로부터 정보를 지키기 위해 DB 운영자(관리자)는 몇 가지 안전장치를 하게 되는데, 그 중 기본이 되는 것이 바로 데이터의 ‘백업’입니다.

시스템의 장애부터 게임서버 프로그램의 오류로 인한 서버 장애까지 재난에 따른 최소한의 안전장치가 바로 DBMS의 ‘백업’입니다.

서비스 중인 온라인게임의 서버는 정기점검 시간을 제외하고 365일 24시간 운영되는 것이 보통입니다. 이를 위해 몇 가지 기본적인 안전장치를 하게 되고, 이런 안전장치는 크게 ‘가용성 측면’과 ‘재해 대책 측면’의 두 가지를 염두에 두고 준비 됩니다.

가용성은 사용자 폭주나 일시적인 네트워크 장애부터 시스템 장애까지 실제 서비스를 원활하게 하는데 초점을 두고 준비됩니다.

반면에 재해 대책은 시스템 장애 등으로 서비스 자체가 불가능 해졌을 경우 빠른 복구와 서비스 재개를 위한 체계적인 방법입니다. 백업을 기본으로 복제 서버 등 다양한 방법이 존재하죠.

하지만 어떠한 재해 대책에서도 전제가 되는 것은 데이터베이스의 백업입니다. 특히 전체 데이터의 백업은 정기점검 시간에 이뤄지는 가장 기본적인 절차이고, 시스템 관리자의 가장 중요한 임무 중 하나입니다.

데이터베이스의 백업은 크게 물리적 백업과 논리적 백업으로 나눠집니다.

물리적 백업은 우리가 파일을 복사해 놓듯이 데이터베이스의 필수 파일들을 다른 저장매체에 시스템적으로 복사하는 것입니다. 논리적 백업은 물리적 백업과는 달리 데이터베이스 시스템에서 제공하는 기능으로 데이터베이스의 내용을 내려 받아 다른 파일로 저장하는 것을 말합니다.

논리적 백업은 바로 데이터베이스의 운영 측면에서 성능을 나타나게 됩니다. 얼마나 빠르게, 그리고 효율적으로 백업을 할 수 있는가와 그리고 백업된 데이터로부터 빠르게 데이터베이스를 복구 할 수 있는가에 따라 점검시간과 장애시간이 줄어 들게 됩니다.

지금까지 데이터베이스 시스템이 제공하는 핵심적인 기능들에 대해서 알아보았습니다. 이런 기능들을 제공하는 데이터베이스 시스템이 없이 게임이 만들어진 다면 어떤 문제가 발생할까요? 이제부터 끔찍한(?) 상상의 나래를 펼쳐보도록 하겠습니다.

게임을 제작할 때 개발사는 여러 가지 선택을 하게 됩니다. 게임의 엔진을 직접 개발할 것인가, 아니면 상용 엔진을 사용할 것인가, 어떤 데이터베이스 시스템을 사용할 것인가 등등 기술적으로 가장 큰 고민거리 일 것입니다.

클라이언트 개발자의 경우 보통 어떤 상용 게임 엔진을 사용하느냐에 따라 적게는 1년 많게는 2년 이상의 시간을 절약할 수 있습니다. 반면 서버 개발자의 입장에서는 어떤 운영체제에 어떤 데이터베이스 시스템을 사용할 것인가가 매우 큰 고민이 될 수 있습니다.

물론 이미 익숙한 개발 환경과 경험이 있다면 아무래도 해왔던 그대로 편한 길로 가고 싶은 것이 사람의 마음입니다만, 여러 가지 대안을 가지고 고민을 할 수도 있는 것입니다.

사실 예전에 데이터베이스의 부하보다 네트워크의 부하가 더 큰 걸림돌이었을 당시, 실제로 데이터베이스가 견디지 못 할 부하가 발생할 만큼의 사용자를 하나의 서버에 받아들이지 조차 못했으므로, 그리 큰 고민이 아니었습니다.

하지만 네트워크 문제를 해결하기 위한 노력은 끊임 없이 이루어져 왔고, 그 결과 요즘에는 네트워크의 한계가 상당부분 극복이 되었습니다.

MS Windows의 IOCP기술과, 리눅스의 epoll, BSD의 Kqueue, Solaris의 Dev-poll 등이 나오면서 서버 개발자의 네트워크 고민은 어느 정도 해결이 되었고, 결과적으로 하나의 게임 서버에서 수용할 수 있는 동시접속자의 수가 비약적으로 늘었습니다.

이렇게 되니 이제는 수많은 유저들이 동시에 발생시키는 데이터베이스의 부하를 걱정해야 하는 수준까지 왔습니다. 그래서 좀더 원활하게 게임을 즐길 수 있는 환경을 제공하기 위해 더 좋은 성능의 데이터베이스 시스템을 찾게 됩니다.

하지만 이런 데이터베이스 시스템이 없다면 어떻게 할까요? 결국 게임을 개발자는 자체 게임 엔진을 개발하듯 데이터베이스 엔진을 개발해야 합니다. 그렇지 않고서 게임을 정상적으로 개발 할 수 있는 방법이 없습니다.

이미 게임상의 재산(아이템)은 현실적인 가치로도 어느 정도 인정을 받을 정도로 게이머에게 미치는 영향은 막대합니다. 아이템이나 캐릭터가 안전하게 보장되지 않는다면 게이머에게는 게임을 해야 할 의미를 빼앗기는 것과 같습니다.

시장에는 자체 개발한 게임엔진으로 제작된 MMORPG들이 꽤 많습니다. 수많은 시행착오와 엄청난 노력을 들여서 일궈낸 값진 결과지요. 하지만 데이터베이스 엔진을 자체적으로 개발하여 서비스하고 있는 게임회사는 적어도 온라인게임에서는 없습니다.

왜일까요? 데이터베이스 엔진들이 원하는 기능을 100% 충족시켜주고, 만족스럽기 때문일까요? 절대 아닙니다. 항상 아쉬운 부분이 있지만, 결국 시간과 비용의 문제입니다. 데이터베이스 엔진이 담당하고 있는 부분은 게임의 초석을 이루고 있는 데이터입니다. 이런 데이터에 오류가 발생을 한다면 엄청난 혼란을 초래할 것입니다.

검증이 되지 않은 자체 데이터베이스 엔진을 사용해서 시행착오를 격어가면서 수정해도 될 만큼 중요하지 않은 부분이 절대 아니죠. 클라이언트가 오류를 일으켜도 데이터베이스만 정상적이라면 실질적으로 게이머가 잃는 것은 다시 게임을 실행하면서 걸리는 시간뿐입니다.

물론 ‘그 시간에 엄청난 아이템을 획득 했으면 어떻게 할거냐?’라고 반문하면 할 말은 없습니다. 하지만 데이터베이스 엔진이 문제가 생겨서 데이터를 복구할 수 없게 된다면 시간이 문제가 아닌, 게임 자체의 서비스를 할 수 없는 상황에 이르게 될 것입니다.

데이터베이스 엔진은 개발 하는 것보다 검증 하는 것이 더 어렵습니다. 데이터베이스 시스템을 처음부터 완전히 개발하는데 3년 정도가 걸린다면, 실제로 안정성을 검증 받는데 걸리는 시간도 3년입니다.

은행과 같은 안정성이 생명인 곳에서 가장 중요시 생각하는 원장의 관리는 아직도 옛날의 메인 프레임에서 구축된 검증된 시스템을 계속 사용하고 있고, 새버전의 데이터베이스 시스템이 나오더라도 그 버전이 충분히 검증되기 전까지 업그레이드도 하지 않는 경우도 많습니다.

결과적으로 게임에서 데이터베이스 시스템이 없다면 게임에서 필요로 하는 데이터베이스 엔진을 자체적으로 개발해야 할 것이고, 이 경우 게임 개발에 들어가는 시간이 지금보다 적어도 2~3년 정도는 더 길어질 것이라는 것입니다.

반면 데이터베이스 엔진을 개발하지 않고 게임에서 필요로 하는 최소한의 기능만을 제공할 수 있도록 간단하게 만들어서 게임을 제작했을 경우 시간을 아낄 수 있을지는 몰라도 나중에 게임의 존폐 여부를 결정지을 만큼의 큰 사고가 일어날 확률이 매우 높아집니다.

이는 게임 데이터베이스에서 가장 중요한 기능이 사실상 데이터베이스 엔진에서도 가장 복잡하고, 구현이 어려운 트랜잭션 처리와 온라인 백업, 복구 기능들이기 때문입니다. 이 기능들은 모두 실제 구현도 어려울 뿐만 아니라 충분한 검증이 필요한 기능들입니다.

위에서 가정한 데이터베이스 엔진 없이 가장 단순하게 필요한 기능을 어떻게든 만들어서 게임을 개발하고 서비스를 제공할 때 벌어질 수 있는 문제들을 한번 생각해 보겠습니다.

- 트랜잭션의 처리의 문제

국산 온라인게임들은 꽤 오랜 베타테스트 기간을 가지고 있습니다. FFT(Family & Friend Test), CBT(Close Beta Test ), OBT(Open Beta Test))를 거치면서 보통 6개월 이상, 길게는 1년까지 베타테스트가 이어지죠.

이렇게 충분한 기간을 가짐에도 불구하고 개인적으로 최근의 어떤 온라인게임도 오픈베타 시작일과 정식 서비스 시작일에서 시간 일정을 지키는 게임을 보지 못했습니다.

검증된 데이터베이스 시스템을 사용해서 개발한 게임인데도 이런데, 검증되지도 않은 자체 제작한 데이터베이스 엔진을 사용한다면, 이에 대한 테스트 부담이 더해지게 됩니다.

개발할 분량이 많아질 수록 오류의 존재 가능성도 정비례해서 높아지고, 결국 베타테스트 기간의 연장과 불안한 테스트가 되는 것은 정해진 수순일 것입니다. 실제로 <그라나도 에스파다>는 오픈베타를 시작했을 당시 며칠을 소진하면서 ‘MS SQL Server’의 설정 오류를 잡은 바 있습니다.

트랜잭션의 문제는 앞서 다룬 것과 같이 동시에 수많은 트랜잭션이 일어나게 되면 필수적으로 간섭 현상이 일어나고, 이것은 성능의 문제와 직결이 됩니다.

초당 트랜잭션이 10건일 때와 1,000건일 때의 검증은 엄연히 다르게 존재하고, CBT 당시에 정상적으로 동작했다고 해서 OBT 때 수많은 유저가 몰리면서 급증한 트랜잭션에서도 정상 동작한다는 보장이 없다는 것입니다.

그리고 OBT 때 다른 것도 아닌 트랜잭션에서 문제가 생긴다면 앞서 예를 들어 설명한 트랜잭션이 깨지면서 나타날 수 있는 거대한 재앙이 기다리고 있으며, 그 결과 게이머들의 이탈과 게임 흥행의 실패로 이어질 것입니다.

- 백업과 복구의 문제

앞서 데이터베이스 시스템의 백업과 복구 기능의 성능에 따라 점검시간과 장애시간이 결정된다는 얘기를 했습니다. 하지만 여기에서 한가지 더, 논리적 백업에서 제공하는 기능과 DBMS 자체적인 재해 대책에 따라서 복구 가능한 범위도 달라집니다.

또한 복구의 문제에는 트랜잭션의 지속성을 위한 문제도 있습니다. 몬스터를 잡고 떨어진 아이템을 줍지 못한 상태에서 갑작스런 서버 시스템 다운이 발생했다면 몰라도, 떨어진 아이템을 주운 상태에서 시스템 장애가 발생했음에도 불구하고, 주운 아이템이 인벤토리에 없다거나 아예 백섭이 될 수 있는 것은 데이터베이스의 복구 기능에 차이가 있기 때문입니다.

만약 이런 기능을 제공하는 DBMS가 없다면 갑작스런 서비스 장애부터 최소한의 안전장치가 조차 없는 그런 게임 서비스를 제공하는 것이고, 장애가 발생할 때 마다 복구의 문제와 게이머들의 원성을 사게 될 것입니다.

이상으로 ‘온라인게임에서 DB가 없다면?’이라는 조금은 황당한 가정으로 온라인게임 서비스에서 DB의 중요성과 그 역할에 대해서 알아 보았습니다.

다음에는 ‘게임 서비스에서 DB 점검과 일명 백섭’에 대한 내용으로 찾아 뵙겠습니다.