[Misc.] 게임 데이터 분석가를 위한 도메인

Background
게임 회사에 갓 취업한, 게임을 재밌어하기만하지 공부해본 적 없는 비개발 직군 모두에게 도움되는 내용이다.
크게 게임 서버, 개발, 로그(WIP)에 대해 다룬다.
앱, 웹 위의 어떤 프로그램에서 사용자가 취한 액션은 로그로 찍힌다. 이걸 낚아서 적재하고, 유의미한 형태로 가공한 뒤, 비즈니스 의사 결정에 사용하여 수익 창출을 기대해볼 수도 있다. 분석가로서 나의 미션은 가공, 인사이트에 집중되어 있지만, 인사이트를 뽑아내려면 결국 도메인을 잘 알고 있어야 한다.
게임 서버, 개발을 공부한 것은 아니고, 잘 정리된 글을 바탕으로 사내 개발자들이 작성해놓은 가이드 문서를 종합해 나름의 핵심만 간추렸다. (가장 큰 도움을 얻은 글은 12년 2월에 배현직이란 분이 작성하신 [게임서버에 대해 말해주마]라는 컬럼이다.)

온라인 게임 구조

온라인 게임의 구조는 크게 서버와 클라이언트(이하 클라)로 나눌 수 있다. 두 개 모두 컴퓨터인데, 클라이언트는 유저가 사용하는 것, 서버는 회사에서 보유한 컴퓨터라고 생각하면 된다. 유저가 키보드로 배그 캐릭터를 움직이고, 마우스로 총을 쏘는 등의 ‘입력’은 클라이언트에서 받아와 적절한 처리 후 서버에게 몇몇 응답을 요청한다. 예를 들어 내가 쏜 총이 상대 캐릭터에게 먼저 맞았는지, 아니면 상대가 쏜 총에 내가 먼저 맞았는지 판정을 서버에서 응답해달라는 요청이 있을 수 있다. 이런 서버를 통칭 dedicated 서버(이하 서버)라고 한다.

물론 유저가 서버를 직접 조달할 수도 있는데 이런 경우는 보통 호스트 게임 서버라고 한다. 회사가 관리하는 서버에 비해 성능이 낮을테니 그만큼 많은 요청을 감당하기 힘들고, 이는 곧 많은 동시접속자수를 감당할 수 없다는 것을 의미한다. 회사에서 직접 띄운 서버를 여러 최신 서버 효율화 기술의 집합체다. 당연히 더 많은 요청을 처리할 수 있고, 따라서 더 많은 동시접속자 수를 감당할 수 있다는 장점이 있다.

다시 돌아가서, 서버에서 해당 판정을 내리기 위한 연산 작업을 마치고, 결과를 다시 클라에 보내면 클라는 이 결과를 토대로 유저에게 죽는 모션과 내가 죽였다는 멋진 이펙트를 보여준다. 보여지게끔 하는 과정을 렌더링이라고 한다.

정리하면 클라에서는 아래와 같은 입력, (일부) 로직 연산, 렌더링 역할을 하고 서버에서는 (일부) 로직 연산 역할을 한다.

게임 서버

게임 서버는 상호 작용 중재 외에 로그인, 인벤토리 관리, 랭킹 시스템 등의 역할도 수행한다. 각 목적에 따라별도의 서버를 두는 것이 일반적이다. 또한 데이터와 관련된 역할(게임 플레이어의 정보, 보안, 관리)도 담당한다.

게임 서버는 안정성을 가장 중요하게 여긴다. 여러 작업이 동시에 병렬적으로 실행되게 하면서, 정보의 순서가 뒤틀리거나 망가지지 않게 하는 것을 의미한다. 때문에 서버 개발자는 기획서를 토대로 게임 로직을 구현하며 동시접속자가 많아도 서버가 안정적으로 돌아갈 수 있도록 설계하는 것을 가장 중요하게 생각한다. 서버에 뭐 로그 개발해달라고 요청하면 일단 서버 안정성 이슈를 고려안할 수 없다. 이미 펍지처럼 로그 개발 프로세스(포스트 후반에 언급)가 잡혀있다면 문제 없지만, 그렇지 못한 환경일 경우 개발자와 긴밀하게 논의해서 로그 개발 프로세스 만이라도 잡아놓는게 중요하다.

논외로, 개발 초기에 서버는 동시접속자가 많은 상황을 미리 실험해보기 어렵다. 그래서 공개적인 임상 실험인 클로즈 베타 테스트(CBT)를 한다. 이후 오픈 베타 서비스를 준비한다. 이후 오픈 베타도 안정적으로 돌아간다면, 상용화 공표를 하게 된다. 상용화 이후 개발팀은 라이브팀 체제로 편성되어 서비스 중인 게임 프로젝트에 지속적으로 다양한 콘텐츠를 추가하는 역할을 수행하게 된다. 펍지처럼 상용화된 게임도 콘텐츠 업데이트 시 여전히 베타 테스트를 진행할 필요가 있기 때문에 테스트 서버라는 것을 운영한다. (스팀에서 무료로 테스트 서버 다운로드가 가능하다)

서버와 관련되어 자주 접하게될 것들 중 하나는 크래시인데, 쉽게 말해 코드가 오동작해서 프로그램이 멈추는 현상이다. 게임 서버도 일종의 코드 집합이고 버그가 발생할 수 있다. (매우 많을 수도 있고…) 코드 에러와 같은 크래시를 최소화하려면 코드를 누구나 쉽게 이해할 수 있도록 만들되, 서버 성능을 최대한 높일 수 있어야 한다. 단순한 코드와 고성능의 게임 서버 간 트레이드 오프를 잘 컨트롤하는 것이 주된 고민이지 않을까.

비슷하게 랙이란 것도 많이 들어봤을 것이다. Latency에서 유래된 단어로 두 컴퓨터 간 주고 받는 데이터의 전송 시간을 의미한다. 랙이 발생하는 원인은 다양한데, 일차적으로 서버에 과부하가 걸려서 발생한다. 그 외 서버 하드웨워, 인터넷 환경 등 여러 요인이 있기 때문에 어떻게 보면 크래시보다 렉이 더 해결하기 힘든 경우도 있다.

게임 개발 흐름

게임 개발 방법이 아닌 프로세스에 대해서만 간략하게 다루려고 한다. 개발 프로세스 중 로그 개발 및 프로덕트 분석에 있기 때문에 분석가도 전체적인 흐름을 인지하고 있어야 다른 실무자와 원만히 협업 할 수 있다. 전체 흐름 중 어떤 작업 진행 중이고, 관련 용어만 알면 문제 없다. 더 나아가면 백엔드나 프론트엔트 개발자가 현재 이런 업무를 진행하니 이 정도로 바쁠 것임을 감 잡고 업무 요청하면 좀 더 원만한 커뮤니케이션이 가능할수도 있다.

대부분의 온라인 게임은 클라이언트, 서버에 배포하는 프로그램으로 일종의 코드 집합이라 볼 수 있다. 이미 초기 개발은 완료되었으니 라이브팀에서 지속적으로 인게임, 아웃게임 콘텐츠를 업데이트하고 있는데 그 과정 역시 코드에 기반하고 있다. 이러한 방식을 Infrastructure as Code(IaC)라고 하며, 시스템을 수동으로 관리하는 대신 스크립트를 사용하여 컴퓨팅 인프라를 구성한다. 결국, 모든 개발은 코드를 기반으로 협업하기 때문에 git과 같은 version control system을 사용하고 있다.

대부분의 소프트웨어 개발 프로세스의 흐름은 아래와 같은 형태라고 할 수 있다. 각 단계에 대해 간략하게만 설명하면

Pre-Production Phase: 컨셉 기획하고 EPD, OPD 컨펌
Production Phase: UI, UX, 백엔드, 프론트엔드 등 실질적인 개발 작업
Dev QA Phase: 개발한 피쳐에 대해 QA 환경에서 테스트해보고 버그를 고치는 작업
Release QA Phase: 개발한 피쳐 뿐만 아니라, 릴리즈하는 다른 모든 피쳐를 모아놓고 QA 및 버그 픽스
Release Phase: 테스트, 라이브 서버에 배포하고 이후 분석 및 포스트모템

이 중 분석가가 직접 참여하는 단계 & 할 일은 다음과 같다.

Production Phase: 로그 명세 및 분석 설계, 명세 리뷰
Dev QA Phase: 로그 QA
Release Phase: 테스트 서버 로그로 분석 및 대시보드 미리 작업 후 라이브 서버 배포 대응

이는 로그가 수집된다는 전제를 가지고 있기 때문에 주로 라이브에 올라간 게임을 지속적으로 개발 할 때의 과정이다. 만약 게임 개발 단계부터 분석이 필요하다면 보통 비슷한 다른 게임의 로그를 가져오거나, 서드파티 데이터를 수집해서 필요한 인사이트를 전달하긴 한다.

그 외 - 게임 플랫폼, 로그
게임 회사라면 자체 플랫폼이 있어 여기서 유저들이 게임을 구매, 다운로드 받거나 게임에 과금을 할 수 있는 경우가 있고, 반대로 서드파티 플랫폼에 자사 게임을 퍼블리싱하는 경우도 있다. 배그는 스팀이라는 플랫폼에서 유명한 게임이다. 7~8년이 지난 지금도 많은 사랑을 전세계에서 받고 있다.
트래픽이 많다는 의미는, 그 중 질이 안 좋은 유저도 유입된다는 것이다. 질이 안 좋다는 것은 사기를 쳐서 경제적 이익을 얻으려 한다거나, 핵을 써서 다른 유저의 플레이 경험을 망친다는 것 등이라고 할 수 있다. 그 중 내가 맡은 업무 중 이상 결제와 관련된 것이 있다. 이것도 기회가 되면 별도 포스트로 정리해보려고 한다.
게임 로그 부분도 추후에 내가 진행하고 있는 게임 로깅 사이드 프로젝트를 정리해서 포스팅하겠다.

아래는 컬럼에 대한 단순 요약이다.

게임 서버는 크게 호스트 게임 서버, dedicated 게임 서버로 나눌 수 있다.
전자는 개인 컴퓨터가 게임 서버가 되어 다른 사람과 게임을 할 수 있게 해주는 프로그램이며, 패키지 게임에서 호스트 게임 서버를 발견할 수 있다.
후자는 게임 회사에서 직접 서버를 띄우는 형태라 더 많은 동시접속자를 감당할 수 있다.
패키지 게임의 프로그램은 입력 받기, 게임 로직 처리, 랜더링의 역할을 수행한다. 입력 받기는 사용자가 마우스, 키보드 등의 입력 장치를 이용해 컴퓨터에 값을 입력하는 것을 말하고, 게임 로직은 입력 받은 값을 시뮬레이션하는 작업이며, 랜더링은 이렇게 시뮬레이션된 값을 화면과 스피커로 뿌려주는 것을 의미한다. 예를 들어 오른쪽 방향키를 누르면(입력), 캐릭터가 오른쪽으로 뛰어가게 명령하는 과정(게임 로직 처리)이 있고, 뛰어가는 모션을 화면으로 띄워주는 것(랜더링)이 있다.
온라인 게임의 핵심 개념인 멀티 플레이를 하려면 인풋, 아웃풋은 사용자 컴퓨터에서 할지라도, 중간에 로직 처리를 한 곳에서 관리해야 하는데, 그 역할을 하는 것이 게임 서버다. 클라에서는 입력 받기와 랜더링을 전담하고, 게임 로직의 일부분을 게임 서버가 담당함
클라에서는 랜더링을 하는데, 상당히 정교하게 설계된 그래픽을 구현하려면 그만큼 사용자의 하드웨어 리소스를 많이 사용한다.
안정화된 게임 서버는 Daemon 이라고 불리는 상태로 작동함
게임 서버는 게임 로직 처리 역할을 하는데, 이 중엔 여러 플레이어 간 상호 작용을 중재하는 역할도 한다. (흔히 말하는 판정?) A 유저가 AK로 B 유저를 맞춰 데미지를 입히는 과정을 생각해보자. 클라에서는 ‘총을 쏴서 맞췄다’라는 요청을 서버에 보낸다. 서버는 API에 따라 해당 요청에 대한 적절한 응답을 처리하기 시작하고, A 유저의 탄창이 떨어지고, B 유저의 체력이 감소한다는 응답을 클라에 보낸다. 상호 작용 중재 외에 로그인, 인벤토리 관리, 랭킹 시스템 등의 역할도 수행함. 각 목적에 따라 별도의 서버를 두는 것이 일반적
게임 서버에서는 게임 플레이어의 정보, 보안, 관리 등을 담당함
게임 서버 개발자라고 해서 게임 프로그래밍을 몰라도 되는 것은 아님. 게임 기획에 대해 깊은 이해가 있어야 게임 로직 처리가 가능하기 때문
클라 개발자는 게임 연출, 그래픽 프로그래밍 관련해서 게임 기획에 집중하고, 서버 개발자는 게임 플레이 규칙, 커뮤니티, 밸런스 등에 대해 기획자아 수많은 논의를 한다. 눈에 보이는 것은 클라 개발자가 작업하고, 눈에 안 보이는 것은 서버 개발자가 작업한다.
클라에선 화려한 그래픽 연출 기법과 처리 성능을 중시하는 반면 서버에서는 안정성을 가장 중요하게 여김. 여러 작업이 동시에 병렬적으로 실행되게 하면서, 정보의 순서가 뒤틀리거나 망가지지 않게 하는 것을 의미.
운영자(GM)는 개발자과 게임 유저들 사이에서 창구 역할을 하는 사람들
게임 기획자가 게임 컨텐츠 기획서를 작성 (퀘스트, 몬스터, 플레이어 등). 클라, 서버 프로그래머 모두 이 기획서를 닳도록 읽으면서 게임의 모양, 작동 방식을 구조화시켜 코드로 구현해야 함
게임 개발 초반에는 클라 개발자의 작업량이 매우 많다. 반면 서버 개발자는 기획서를 토대로 게임 로직을 구현하며 동시접속자가 많아도 서버가 안정적으로 돌아갈 수 있도록 설계한다.
클라는 다양한 하드웨어를 가져다 테스트하면 되지만, 서버는 동시접속자가 많은 상황을 미리 실험해보기 어렵다. 차선책으로 dummy client를 사용하여 유사하게라도 상황을 재현함. 그럼에도 진짜 사람들이 테스트하는 것 미만잡이기 때문에 공개적인 임상 실험인 클로즈 베타 테스트(CBT)를 한다. CBT를 충분히 하고 나면, 서버와 클라는 상당한 안정성을 갖추어 나가고 이에 맞춰 오픈 베타 서비스를 준비한다. 이후 오픈 베타도 안정적으로 돌아간다면, 상용화 공표를 하게 된다. 상용화 이후 개발팀은 라이브팀 체제로 편성되어 서비스 중인 게임 프로젝트에 지속적으로 다양항 콘텐츠를 추가하는 역할을 수행하게 된다.
상용화된 게임이더라도 콘텐츠 업데이트 시 여전히 베타 테스트를 진행할 필요가 있기 때문에 테스트 서버라는 것을 운영한다.
계속해서 콘텐츠가 업데이트되다 보면 점점 서버 구조가 꼬이게 되는데, 이를 스파게티 코드 현상이라고 함
서버 다운은 서버가 멈춰 버리고, 수용 중이던 플레이어를 모두 추방하는 현상
대표적인 요인은 crash다. 오동작으로 프로그램이 멈추는 현상으로, 게임 서버라는 프로그램에 사용된 코드에서 버그가 발생한 경우가 해당된다.
크래시를 최소화하기 위해선 우선 누구든지 쉽게 이해라 수 있도록 최대한 알기 쉽게 만들어야 함. 그렇다고 너무 단순하게 만들면 서버 성능이 낮아져 더 많은 동시접속자를 수용하지 못하는 문제가 발생한다. 게임 서버의 성능과 프로그램의 단순함 간 트레이드 오프를 잘 판단해서 개발해야 함
랙은 latency에서 유래된 말인데, latency란 두 컴퓨터 간 주고 받는 데이터의 전송 시간을 의미한다.
cmd에서 ping www.google.com 이라고 입력해보면, 미국 서버까지 요청이 가고, 응답을 받는 시간을 알 수 있다. 왕복 0.14초 정도 걸린다고 뜬다.
같은 수준의 레이턴시라도 게임 특성에 따라 큰 랙이 될 수도 있다.
랙이 발생하는 원인은 다양한데, 일차적으로 서버에 과부하가 걸려서 발생함. 서버에 과부하가 걸리면 클라에서 오는 여러 요청을 제대로 처리하지 못하고 지연된다. 서버 프로그램에 과부하가 올 수도 있고, 서버 하드웨어나 네트워크 장비, 방화벽 장비에 과부하가 걸릴 수도 있다. 해킹을 막기 위해 게임 플레이 처리 판정을 서버에서 주도하려는 것도 과부하는 유발한다. 또는 인터넷 환경이 좋지 않아 발생할 수도 있다.
서버 롤백은 백섭이라고 부르는데, 플레이 중인 캐릭터 정보가 과거 상태로 바뀌는 현상이다. 패키지 게임에서는 세이브라는 기능이 있는데, 세이브를 하면 플레이 중인 게임 데이터가 하드 디스크에 저장된다. 온라인 게임도 데이터 발생 시 서버에서 매번 자동 저장을 한다. 일정한 주기로 서버 주도 하에 자동 저장을 하는데, 이 주기 사이에 서버 다운이 발생하고, 그 사이에 또 펜타킬을 해버렸다면 기록은 저장되지 못한 채 증발된다.
패키지 게임에서 캐릭터라는 데이터 덩어리는 RAM 어딘가에 저장되어 있다. RAM을 뒤져서 캐릭터 데이터를 찾아 조작할 수 있다면, 게임에서 신이 될 수 있다. 해커들은 여기서도 돈 냄새를 맡고 이런 해킹을 누구나 가능케하는 프로그램을 개발해서 판매했다. 대표적인 해킹 도구가 Gamw Wizard
RAM 해킹이 아니라 세이브 파일 자체를 해킹할 수도 있다.
RAM에 저장되는 정보 중 캐릭터 데이터를 계속 이동시키거나, 암호화시키기도 하고, 세이브 파일도 암호화해서 알아보지 못하게 만드는 대응 방안이 있다. 유능한 해커는 이것도 무력화(크래킹)를 한다.
게임 해킹의 가장 큰 목적은 불법 복제. 패키지 게임에 처리된 불법복제 감지 장치를 무력화해서 불법복제할 수 있다.
온라인 게임에서의 해킹: 해커는 클라에 있는 모든 것을 얻지만, 서버는 손을 댈 수 없음. 타격 결과에 대한 연산이 클라가 아닌 서버에서 이뤄지기 때문에 해킹이 불가능함. 클라의 데이터를 해킹해서 조작해봤자 나에게 랜더링 되는 것들만 달라질 뿐, 다른 클라에서는 여전히 서버에서 제공한 수치를 띄운다.
만약 클라의 메모리를 해킹하는게 아니라, 클라가 서버에 요청하는 내용 자체를 조작한다면? 즉 클라 프로그램이 작동하는 방식을 해킹할 수도 있다. 서버는 요청을 알아서 구분하여 해킹이라는 딱지를 붙일 수 없기 때문에 초당 10,000번을 때리는 요청도 응답의 대상일 뿐이다. 서버 개발자가 클라의 이런 조작을 파악한다면, 검산 과정을 하나 더 거치게 하여 10,000번 타격 요청에 대한 적절한 응답을 만들어내면 해킹을 막을 수 있다.
온라인 게임의 세이브 파일을 조작할 수도 있다. 세이브 파일은 내부 DB에 있어 쿼리를 조작해서 원하는 명령어를 수행시킬 수 있다. 쿼리 인젝션이라고 함
컨텐츠 조작의 경우, 그냥 캐릭터 옷을 벗겨서 내 클라에만 보이는 것은 다른 플레이어에게 영향을 주진 않지만, 제작자로선 상당히 불쾌한 일… 또 FPS 게임에서 벽이라는 컨텐츠를 해킹하는 경우, 상대 플레이어 위치를 파악할 수 이씩 때문에 승패에 영향을 준다. 컨텐츠를 해킹하는 것은 서버가 쉽게 감지할 수 있기도 하고, 클라 프로그램 자체에 검사 기능을 내포시키기도 한다.
패키지가 아닌 온라인 게임에서만 일어나는 해킹도 있음. 온라인 게임에 필수적인 서버를 통째로 불법 복제 해버리는 경우, 이렇게 복제된 사설 서버를 free server라고 한다. 해커의 공격이나 업무상 과실로 서버가 유출될 수 있는데, 이 때 프리서버와 같은 불법 복제 서버가 등장할 수 있다. 유츌된 적 없지만 서버가 복제되는 경우도 있는데, 클라와 서버 간 네트워크를 통해 주고받는 정보를 토대로, 프로그램 구조를 분석해서 게임 서버와 똑같이 작동하는 서버를 따라 만들 수 있따.
게임 서버와의 네트워크 통신 정보를 로그로 남기는 대표적인 도구로 Wireshark 가 있음
프리 서버는 애초에 많은 동시접속자를 염두에 두고 만든게 아니라, 간단하게 만들 수 있지만 그만큼 여러 명이 동시에 플레이하기 어렵다. 서버 연산을 조작해 게임에서 신 적인 존재가 된다 하더라고, 우물 안 개구리처럼 작은 공간에서의 신일 뿐이다. 만약 클라까지 해킹했다면 새로운 컨텐츠를 만들어낼 수도 있다.
다른 방법은 노가다 플레이를 대신 해주는 기계를 만들어 대신 플레이시키는 것인데, 이런 아이디어에서 매크로, 봇, 오토 같은 프로그램이 나오게 됨. 게임 클라를 띄우고 게임을 실행시킨 다음, 봇 프로그램을 같이 실행시키면, 봇 프로그램은 클라의 마우스와 키보드를 사람 대신 입력한다. 이걸 막기 위해 클라가 프로그램으로 조종되고 있는 검사하는 프로그램을 심기도 하고, 서버에서도 클라가 조종되고 있는지 검사하는 프로그램이 있다. 또는 봇 자체가 들어설 필요가 없게 게임 시작하자마자 만렙으로 전환시켜주는 비싼 유료 아이템을 팔면 된다.
아이템 복제 해킹은 서버의 결함을 이용한다. 예를 들어 유저가 접속하면, 클라는 분산 처리로 작동하는 게임 서버 중 하나를 선택해 접속한다. 이를 서버 1이라고 하자. 서버 1은 DB로부터 유저에 대한 정보를 가져온다. 유저가 플레이하다 접속을 끊으면 서버 1은 유저 정보를 DB에 저장한다. DB는 하드디스크나 SSD와 같은 물리적인 기록 장치이기 때문에 저장되기까지 약간의 시간이 필요하다. 이 유저가 접속을 끊고 다시 접속하려 할 때, 분산 처리로 작동하는 게임 서버 중 하나를 다시 선택하는데, 앞에 선택한 서버와 다를 수 있다. 이를 서버 2라고 하자. 만약 서버 1에서 접속 끊은 유저의 정보를 DB에 저장하기 위한 과정이 진행되고 있을 때, 유저가 서버 2에 새로 접속해서 자신의 정보를 DB에서 가져온다면, 유저는 아주 약간 과거 상태가 된다. 아직 DB가 업데이트되지 않은 상태이므로! 만약 서버1에서 아이템을 떨구고, 매우 빠르게 서버2로 접속하면, 내 가방에는 여전히 아이템이 있지만 게임 월드에선 동일한 아이템이 바닥에 떨어져 있게 된다.