이렇게 접근하면 테이블 4에서만 계산할 때에 비해 판독 과정을 상당 부분 단축할 수 있음을 알 수 있습니다.

새로운 장부 항목을 저장한 후 새롭게 계산한 데이터만 보관하면 된다고 생각할 수도 있습니다. 이는 언뜻 보기에는 좋을지 몰라도, 데이터 불일치 및 성능 저하가 발생할 가능성이 있는 방식입니다. 성능 저하의 사례를 들자면, 데이터를 읽은 후 작성해야 하는 경우가 많아서 데이터 재계산 및 저장 과정이 시스템의 많은 부분을 차지할 수 있습니다. 모든 플레이어가 적합한 성능으로 게임을 즐길 수 있어야 하므로 계산 과정의 균형을 맞출 필요가 있습니다.

데이터 불일치의 사례를 들자면, 게임 종료 후 계산에서 문제가 발생할 수 있습니다. 저희의 서버 인프라와 플랫폼은 메시지 지연 도착 방식을 지원합니다. 예를 들어, A와 B 두 개의 데이터 센터에서 일시적인 문제가 발생한다고 가정합시다. 플레이어에게 미니 경험치를 제공하는 메시지가 A에서 전송되었지만 아직 B에는 도착하지 못했습니다. 시나리오는 이런 식이 되겠죠. 여러분은 자정 직전에 게임을 플레이하고 있습니다. 경기에서 이긴 시간이 수요일 11시 59분이고요. 롤업 프로세서는 당일의 모든 데이터에 대해 매일 시행되도록 설정되어 있습니다. 따라서 수요일 자정부터 목요일 자정까지의 경험치 합산 수치를 계산할 것입니다. 이 데이터는 두 번째 테이블에 저장되며, 경험치에 대한 새로운 판독은 마지막으로 저장된 수치를 찾아서 목요일 자정 이후의 모든 값을 합산합니다. 그런데 메시지 지연 도착이 발생할 경우, 해당 메시지를 수신하면서도 게임이 수요일 오후 11시 59분에 완료되었다는 것을 확인해서 해당 시간으로 경험치 항목을 작성하게 됩니다. 이때 롤업 테이블에는 해당 항목이 포함되지 않으며, 따라서 이후 데이터 쿼리 결과에도 해당 항목이 나타나지 않을 것입니다. 이렇듯 불완전한 데이터는 문제가 될 수 있습니다. 그렇다면 데이터가 날짜 단위로 늦는다면 어떻게 될까요? 저희는 모니터링 및 경고 기능을 이용하고 있으므로 거의 항상 새로운 정보가 다음 롤업에 맞춰 처리될 것입니다.

미니 레벨 계산

총합 경험치 테이블을 돌이켜보면 레벨 계산이 존재하지 않음을 알 수 있습니다. 그곳에는 오로지 획득한 경험치 총합만 존재합니다. 게임 디자이너가 설정한 레벨 관련 정적 테이블은 별개로 존재하는데, 구성은 대략 다음과 같습니다. 미니는 레벨 1로 시작해서 경험치를 1 획득하면 레벨 2가 됩니다. 그리고 경험치 3을 더 획득하면 레벨 3이 되는 방식입니다.

경험치 테이블과 레벨 테이블을 결합하면 수치의 누적 합계를 산출해서 프로그램 실행 중 미니의 실제 레벨을 계산할 수 있습니다. 그 최종 데이터 세트는 다음과 같습니다.

게임 디자이너들은 레벨을 올리기 위해 필요한 경험치에 관해 유연한 시각을 갖고 있습니다. 낮은 레벨에서 레벨을 올리는 게 너무 힘들다고 판단하면 다음 레벨 필요 경험치를 줄일 수도 있겠죠. 이때 데이터베이스에 저장된 플레이어 데이터를 변경하지 않고도 미니들의 레벨이 기존에 비해 다소 오를 것이고, 또 다음 레벨에 도달하는 데 필요한 경험치가 감소할 것입니다. 이는 반대 방향으로도 작동합니다. 레벨이 너무 빨리 올라서 필요 수치를 늘려야겠다고 게임 디자이너들이 판단할 경우, 미니가 보유한 경험치를 변경하지 않으면서도 미니의 레벨은 변경 이전으로 복원할 수 있게 됩니다. 물론 미니에게 경험치를 부여해서 고통을 덜어주는 방식을 사용할 수 없다는 뜻은 아닙니다.

대안적 접근 방식 고려

현재 사용 중인 솔루션을 결정하기 전에, 획득한 경험치를 저장하고 미니의 레벨을 계산하는 방식에 대해 다양한 방식으로 접근해 봤습니다. 개중엔 점검 시간을 통해 플레이어 경험치를 변경하는 방식도 있었고, 플레이어의 진행 상황을 끊지 않으면서 경험치를 전하기에 적절한 방식도 있었죠.

'미니의 레벨과 경험치, 그리고 다음 레벨 필요 경험치를 항상 저장하기'

그냥 표준 SQL 패턴과 트랜젝셔널 업데이트 방식을 사용하는 것은 어땠을까요? 트랜젝셔널 업데이트를 사용하면 데이터를 집합 단위로 업데이트하거나, 아니면 아예 업데이트하지 않게 됩니다. 데이터 일부를 작성하지 못할 경우 모든 데이터가 기존 수치로 돌아가는 셈이죠. 원자성, 일관성, 고립성, 내구성을 갖추고 있다고 하여 각 단어의 첫 알파벳을 따서 A.C.I.D. 속성을 제공한다고 표현합니다.

이때 하나의 행이 각 미니의 경험치와 총 레벨 정보를 보유하므로 읽기 과정이 매우 가벼워집니다.

각 미니가 경험치를 획득할 때, 해당 미니가 보유한 경험치는 2점으로 변경되고 다음 레벨까지 8점이 남아있으며 레벨은 3입니다. 이러한 변경 방식은 데이터를 읽고 다시 계산한 후 데이터베이스에 작성하는 과정을 강제합니다. 아무래도 Cassandra 솔루션과 그 장점에 잘 어울린다고 보기는 힘든 패턴이죠. 게다가 다음 레벨 필요 경험치를 변경하려면 모든 플레이어의 모든 미니에 대해 데이터를 조정해야 하므로 게임을 오프라인 상태로 만들어야 한다는 단점 또한 존재합니다.

'백분율로 저장하기'

더불어, 다음 레벨까지 필요한 경험치를 백분율로 저장하는 방식도 고려했습니다.

한 번의 경기를 끝내고 나면 곧바로 계산이 이뤄집니다. 예를 들면, 놀 투사가 경험치를 +3 획득할 때 백분율은 10 대비 +3으로 다음 레벨까지 30% 경험치를 획득한 것이 됩니다.

이 방식을 채택하면 미니 레벨 곡선을 변경해도 미니의 레벨에는 변화가 없는 유연성을 확보할 수 있습니다. 또한 추가적인 계산 없이 막대의 30%를 채우기만 하면 되므로 게임 사용자 인터페이스에 시각적으로 표현하기가 더 쉬워집니다. 단, 이 패턴은 레벨이 높아질수록 비율이 급격히 감소하는 결과를 초래합니다. 미니가 경기당 경험치를 10 획득하며 다음 레벨 필요 경험치라 100,000일 경우, 해당 값은 0.01%로 표현됩니다. CPU가 부동 소수점을 처리할 능력을 지니긴 하지만, 부동 소수점 연산의 특성을 고려하지 않으면 정확성에서 오류가 발생할 수 있습니다.

다음 시간까지 안녕히...

이렇듯 데이터베이스 기술, 어떤 툴을 사용할지, 그리고 값을 저장하고 계산하는 방식에 관해 수많은 선택지를 고려했습니다. 개발 중인 콘텐츠가 다 그렇듯 더 좋은 방식을 발견하면 모든 내용이 바뀔 수 있습니다. 다만 이 게임 개발을 시작하기에 일단은 좋은 지점을 찾아낸 듯합니다.

이번 엔지니어링 업데이트를 함께 살펴봐 주셔서 감사합니다!

~ 앤디 림