무중단 점검이 필요한가

라이브 중인 게임 서비스들은 오랜 세월에 걸쳐 한 주 중 정해진 어느 하루에 점검하곤 했습니다. 점검 시간 동안에는 서비스를 중단했는데 이 사이에 새 바이너리를 배포하고 서버를 업데이트하고 인프라를 업데이트하고 또 필요에 따라 데이터베이스를 마이그레이션 하곤 했습니다. 각 작업은 서로 다른 부서에서 진행하고 상황에 따라서는 다른 회사에서 진행하기 때문에 점검 시간 동안 점검에 관여하는 모든 사람들은 서로 촉각을 곤두세우고 다른 부서나 다른 회사의 작업 진행 상황을 확인해 가며 자기 차례를 기다렸습니다. 모든 점검 과정이 완료된 다음에는 소위 라이브 테스트라고 해서 외부 고객의 로그인만 막아 둔 채로 얼라우리스트 기반으로 우리들만 로그인 해 실제 환경에서 핵심 기능들을 테스트 해 무결성을 확인했는데 만약 이 과정에서 문제를 발견하면 그 날 새벽 업무는 밤까지 무한정 늘어나기도 했는데 고객들의 원성은 덤입니다.

한편 게임 서비스 점검 때마다 처음부터 점검 시간을 넉넉하게 잡아 두면 점검이 끝나는 시각에 맞춰 게임을 시작하려던 고객들로부터 욕을 먹지 않아도 될텐데 왜 점검 시간을 항상 부족하게 잡아 점검을 연장하는지 궁금한 분들이 계실 겁니다. 이 궁금함에 대한 답은 우리도 그렇게 오래 걸릴 줄 몰랐기 때문입니다. 회사 입장에서는 항상 점검 시간을 최소화 할 때 가장 큰 이익을 낼 수 있기 때문에 점검 시간이 길어지는 상황을 원하지 않을 겁니다. 그래서 큰 업데이트 전에는 점검 시간 동안 수행할 모든 작업을 계획하고 각 작업 절차를 주의 깊게 설계하며 각 작업마다 예상 소요시간, 위험 요소 따위를 고려해 업데이트 시간표를 작성해 공유합니다. 대 고객 서비스 담당자가 이 시간표에 기반해 점검 공지를 작성하고 점검 시간을 고객들에게 안내하는데 정작 이 담당자는 점검 과정에 직접 관여하지는 않기 때문에 만약 점검 과정에 문제가 생길 경우 고객들에게 안내할 말이 없을 수 있습니다. 사실 점검 과정에 생긴 문제를 고객들에게 정확히 안내할 이유가 없기도 합니다.

점검 과정에 돌발 상황은 예상하지 않은 곳에서 생기기 마련입니다. 개발팀에서 나가는 모든 데이터는 사람이 모든 수정사항 하나하나를 패치노트 및 지라 태스크와 일대일 비교해 모든 수정사항이 예정된 것일 때만 이 수정사항의 반영을 허용합니다. 만약 패치노트나 지라 태스크에 대응되지 않는 변경사항을 발견하면 개발팀에서 이를 확인해 이에 대응하는 근거가 되는 지라 태스크를 생성해 연결하거나 이 변경사항을 취소해야 합니다. 또 빌드는 새 데이터와 합쳐 개발팀에서, QA부서에서, 퍼블리셔의 QA부서에서, 마지막으로 라이브 환경에서 같은 테스트를 반복해 결함을 줄이고 있습니다. 또 데이터베이스 마이그레이션이 필요하다면 미리 데이터베이스를 복제해 라이브 환경이 아닌 곳에서 마이그레이션을 수행해 보고 시간이 얼마나 걸리는지, 또 다른 문제는 없는지 미리 파악해 둡니다. 하지만 별 문제가 일어날 가능성이 없는 곳에서 문제가 발생하면 이 모든 준비에도 불구하고 점검 연장을 해야 하는데 아무도 상상하지 못한 문제, 이를테면 테스트 환경에서 잘 되던 마이그레이션이 실제 환경에서 영원히 완료되지 않거나 서버 중 몇 대의 윈도우 업데이트가 끝나지 않는 등의 즉시 원인을 규명할 수 없는 딜레이가 발생하면 점검은 연장될 수밖에 없습니다.

한번은 PC 게임을 서비스 하며 회사 전체의 공통 점검 시간인 목요일 새벽에 규모가 큰 업데이트를 진행했는데 데이터베이스 마이그레이션에 문제가 생겼고 점검 완료 시각인 오전 아홉시까지 점검을 끝내지 못했습니다. 점검을 끝내기는 커녕 마이그레이션 문제를 수정하고 마이그레이션을 다시 수행하는데 시간이 얼마나 걸릴 지 예상할 수도 없었습니다. 평소에 사소한 문제에는 점검을 30분 씩 연장하곤 했지만 이 때는 점검을 두 시간 씩 연장했는데 한 번에 늘어나는 점검시간을 본 고객들의 엄청난 원성을 들어야만 했습니다. 점검 시간은 계속해서 늘어나 점심 먹고 돌아와 한 판 할 계획이던 회사원 분들의 분노를 유발했고 방과 후 학원 가기 전 잠깐 한 판 하려던 학생분들의 분노를 일으켰습니다. 하지만 여전히 문제의 원인을 규명하지 못했고 문제를 찾는 사이에 진행하던 플랜 A 마이그레이션은 완료 예정 시각이 계속해서 늘어납니다. 사무실 분위기는 우울했고 아무도 집에 갈 수 없었습니다.

이윽고 오늘의 업데이트를 취소하고 이전 상태로 되돌리기로 결정합니다. 이 사실을 대 고객 부서에 알려야 했는데 당시 개발팀과 대 고객 부서는 서로 꽤 떨어져 있어 전화로 의사소통 해야 했습니다. 전화를 들고 내선 번호를 누른 다음 ‘오늘 점검을 통해 적용하려던 업데이트를 취소하고 작업 이전 상태로 되돌려야 하는 상황이며 이를 위해 점검을 연장해야 하지만 그럼에도 불구하고 신규 업데이트는 다음 주에 실행해야 한다’는 이야기를 했는데 그 때 제 표정은 아마도 거의 울 것 같은 표정이었을 겁니다. 소식을 들은 운영 부서에서 이 상황을 안내하는 공지사항을 작성하기 시작했고 저녁밥을 먹고 한참 시간이 흘렀을 무렵 공지사항을 작성해 이를 올릴지 마지막으로 개발팀에 확인 연락이 왔을 때 기적적으로 마이그레이션이 완료되어 점검의 가장 큰 부분이 지나가고 나머지 점검 작업을 이어서 진행할 수 있었습니다.

물론 작업을 되돌리든 되돌리지 않든 점검을 연장해야 한다는 사실은 변하지 않아 다시 전화로 아까 이야기한 그 계획은 취소되었고 예정 대로 진행한다는 이야기를 해야만 했습니다. 이윽고 새벽부터 거의 스무 시간 동안 진행한 점검이 마무리 되었는데 점검 준비부터 시작해 오랜 시간 퇴근하지 못해 고객들의 로그인을 허용하고 한동안 게임을 플레이 하면서 멍한 상태로 고객들에게 맞아 죽고 같은 팀 다른 고객들에게 욕을 먹기를 반복했습니다. 그리고도 문제가 없어 보이자 얼굴에 검은 그림자가 드리운 사람들이 하나 둘 사무실을 떠나기 시작합니다. 완전한 해피엔딩입니다.

이런 경험을 하다 보면 회사 입장에서는 무중단 업데이트를 고민하지 않을 수 없는데 다른 업계는 어떨지 잘 모르겠지만 게임 업계에서는 장애 시간 당 손해를 정확하게 계산할 수 있기 때문에 장애 상황에 예민한 편입니다. 그래서 장애 상황에도 서비스를 최대한 유지한 채로 대응할 수 있도록 여러 가지 준비를 하는데 이는 모바일 게임으로 넘어오면서 난이도가 훨씬 높아져 이전에는 별 문제가 아니었던 상황이 큰 문제가 되기 시작합니다. 가령 바이너리를 업데이트 하려면 애플 앱스토어 기준 심사 과정을 거쳐야 합니다. 그래서 이전 시대에는 바이너리 업데이트를 비교적 편안하게 할 수 있었지만 이제는 게임의 아주 많은 부분을 데이터에 의해 동작하도록 만들어 바이너리 대신 데이터 수정 만으로 게임의 핵심 동작을 바꿀 수 있도록 개발하고 있습니다. 또 언리얼 엔진 기반 기준으로 심사 없이 업데이트 가능한 영역에는 인터페이스, 아트 에셋 뿐 아니라 이들에 포함된 블루프린트 로직이 포함되어 평소에는 사용이 상당히 제한되지만 급할 때는 이를 사용해 심사를 거치지 않고 결함을 수정하기도 합니다. 단지 바이너리 업데이트 없이 패치할 수 있는 환경만 갖춰도 현실적인 무중단을 달성할 수 있습니다.

얼마 전에 타임라인을 읽다가 서버 개발자분들로 추정되는 분들이 무중단 업데이트와 이를 위한 환경 구축에 대해 이야기하시는 모습을 봤습니다. 이 분들의 관점은 일부 회사들이 무중단 업데이트를 하고 있는데 이들 중 일부만이 현대적인 인프라에 기반해 무중단 업데이트를 제공하고 있을 뿐 나머지는 도대체 어떻게 무중단 업데이트를 제공하는지 모르겠으며 어쩌면 이들 중 상당수는 꽤 낙후된 기반 위에서 서비스를 제공하고 있을 지도 모른다는 내용이었습니다. 그런데 이런 기술적인 논의를 지켜보다가 무중단 업데이트를 하기 위해서는 기술적인 측면 뿐 아니라 게임의 운영과 게임디자인 측면에서도 고려할 점이 적지 않겠다는 생각을 해봤습니다.

무중단 서비스를 제공하는 대표적인 사례를 살펴보면 실시간으로 다른 고객과 상호작용 하지 않는 경우가 많습니다. 즉 고객들 사이에 클라이언트 버전이 달라도 이들이 직접 상호작용 하지 않기 때문에 무중단 업데이트를 할 수 있습니다. 앞에서 게임의 핵심 동작도 데이터 패치를 통해 바꿀 수 있다고 이야기했는데 패치는 앱스토어 제공자의 심사 과정을 거치지 않아도 되니 중단 없이 패치만 배포하면 클라이언트 동작을 바꿀 수 있습니다. 여기에는 동작 뿐 아니라 인터페이스 수정, 에셋 추가도 가능하므로 미리 잘 설계해 뒀다면 이전에 없던 성장요소나 이전에 없던 컨텐츠를 데이터만으로 추가할 수도 있습니다. 이렇게 하기 위해 가장 중요한 게임의 특징이 바로 플레이어들이 서로 직접, 그리고 실시간으로 상호작용 하지 않는 것입니다. 만약 클라이언트의 동작이 서로 다른 플레이어들이 직접 인게임에서 상호작용 하는 상황이 있다면 이런 방식으로 무중단 업데이트를 제공하기 어렵거나 위험합니다.

물론 그런 사례가 없지는 않은데 실시간으로 다른 플레이어와 상호작용 해야 하는 슈터 장르에서 무중단 업데이트를 하는 사례가 있습니다. 이들은 업데이트 된 바이너리를 배포하되 새 바이너리를 받은 고객과 아직 받지 않은 고객들이 서비스에 공존할 수 있습니다. 대신 새 업데이트를 받은 고객들 끼리 매치메이킹 하고 새 업데이트를 받지 않은 고객들 끼리 매치메이킹 해 클라이언트 재실행에 따라 새 업데이트를 받지만 클라이언트를 재실행 하지 않더라도 게임을 지속할 수 있게 하곤 합니다. 누군가가 만약 끝까지 클라이언트를 종료하지 않고 게임을 계속하더라도 게임을 할 수는 있지만 새 업데이트를 받은 고객이 늘어날 수록 점점 매치메이킹에 실패할 가능성이 높아져 나중에는 안내에 따라 클라이언트를 재실행 하면서 모든 클라이언트 전체 업데이트가 완료됩니다.

기술적으로 현대적인 무중단 점검의 기술적 기반을 사용하지 않더라도 이미 검증된 기술에 기반한 무중단 업데이트는 이런 식으로 이미 수행하고 있습니다. 먼저 위에서 소개한 소위 잠수함 패치 사례가 있습니다. 모바일 환경에서 클라이언트를 제어하기는 어렵지만 서버는 필요에 따라 교체할 수 있기 때문에 패치를 통해 클라이언트를 업데이트 하면 아무 말 없이 클라이언트가 재시작 될 때 조용히 점검 과정을 수행할 수 있습니다. 물론 이 사이 변화를 눈치 챈 고객들로부터 욕을 먹을 수는 있지만 명시적으로 서비스를 중단할 필요가 없어 현대적인 무중단의 기술적 기반 없이도 제한된 범위에서는 무중단 점검을 할 수 있습니다.

한편 무중단 점검은 이를 수행할 필요가 있는지 이익 관점에서 생각해봐야 할 수도 있습니다. 이론적으로 무중단이야말로 이익을 최대화 할 수 있는 기술적 방법이기는 합니다. 하지만 게임 서비스의 수명, 이미 구축된 점검 절차, 이를 수행하는데 숙련된 스탭들의 재교육 등을 감안하면 무중단을 통해 얻을 수 있는 수익에 비해 무중단 환경을 구축하는데 드는 비용이 더 클 가능성이 없지 않습니다. 또 앞에서 잠깐 설명했듯 게임의 상호작용 수준에 따라 무중간을 비교적 쉽게 달성할 수 있는 장르와 그렇지 않은 장르가 있어 기술적으로 무중단 점검을 수행할 수 있는 기반을 갖췄다 하더라도 이를 일률적으로 적용하는데는 어려움이 있을 수 있습니다. 또 비용을 생각하면 그냥 수요일 아침부터 목요일 점심까지 스탭들을 초과근무 시키는 비용이 무중단 환경을 구축해 이를 통해 얻는 수익보다 낮을 수 있기도 하고요. 이런 환경에서 무중단 환경 구축은 여기에 참여한 스탭들이 유명한 컨퍼런스에 나가 발표할 기회를 주기는 하겠지만 회사 입장에서 실질적인 수익으로 연결되지 않을 수도 있습니다.

결론. 지나가다가 서버 엔지니어들이 게임 서비스의 무중단 점검의 기술적 기반과 현실에 대해 이야기하는 모습을 보고 무중단 점검의 기술적 측면 외에 게임디자인이나 점검 절차에 고민해야 할 점들을 두서없이 생각해봤습니다. 기술적 기반이 갖춰졌다 하더라도 게임의 상호작용 수준, 게임이 서비스되는 플랫폼의 바이너리 업데이트 정책에 따라 기술적으로는 가능하더라도 실제로는 이를 적용할 수 없을 가능성이 있습니다. 무중단 업데이트는 이론적으로 회사의 수익을 극대화 할 수 있는 방법이지만 기술적인 측면을 생략하고서도 여기에 필요한 여러 가지 비용이 있으며 이를 감안하면 현재 체계를 유지하는 쪽이 더 나은 선택일 가능성도 있습니다. 기술적으로 가능하더라도 점검 과정을 수행하는 인력, 점검 시간에 따른 손해, 게임 장르에 따른 무중단 달성 가능 여부, 스탭들에 대한 재교육 비용 등을 고려할 때 무중단이 항상 이익이 아닐 수 있습니다.