배포 후 환경 유지보수

패키징을 마치고 게임을 출시했다고 일이 끝나는 것은 아닙니다. 게임은 출시한 순간 완성되는 제품이라기보다, 출시한 뒤의 관리가 성패를 좌우하는 서비스에 가깝습니다. 출시하고 나면 개발 중에는 보지 못한 장치와 플레이 방식에서 버그가 드러나고, 플레이어의 의견이 쌓이며, 새 콘텐츠도 계속 필요해집니다.

이 글에서는 배포한 뒤의 유지보수가 왜 필요한지 정리하고, 패치와 업데이트를 관리하는 방법, 크래시 보고와 원격 측정, 로그로 게임의 상태를 지켜보는 방법, 플레이어 커뮤니티의 피드백을 받는 방법을 차례로 살펴봅니다. 마지막으로 무엇을 먼저 고칠지를 수치로 판단하는 운영 지표를 계산 예와 함께 다룹니다. 이 기반이 갖춰져야 플레이어가 떠나는 것을 줄이고 오래 운영할 수 있습니다.

---

배포한 뒤에도 유지보수가 필요한 이유

출시한 뒤에도 예상하지 못한 버그나 크래시가 생길 수 있으므로, 빨리 고쳐 플레이어 경험과 게임의 안정성을 지켜야 합니다. 새로운 보안 취약점이 발견되거나 악용되면 바로 패치해 게임 데이터와 플레이어의 정보를 보호해야 합니다.

플레이어의 의견은 게임을 개선할 귀중한 정보이므로 적극적으로 받아 플레이 경험을 높입니다. 새 레벨과 캐릭터, 아이템 같은 콘텐츠를 꾸준히 더하면 플레이어의 흥미가 유지되고 다시 찾아오게 됩니다. 이런 꾸준한 유지보수는 게임의 수명을 늘리고 활발한 커뮤니티를 만듭니다. 또 개발하는 동안 쌓인 임시방편의 코드나 비효율적인 로직, 즉 기술 부채(technical debt)도 이 기간에 조금씩 갚아 나갑니다.

---

패치와 업데이트

출시한 뒤 가장 흔한 유지보수 활동은 패치(patch)와 업데이트(update)입니다. 둘 다 이미 설치된 게임을 새 버전으로 바꾸는 일이지만, 목적과 규모가 달라 준비하는 방법도 다릅니다. 패치는 문제를 빨리 고치기 위해 바꾸는 범위를 작게 잡고, 업데이트는 새 콘텐츠를 계획한 주기에 맞춰 크게 내보냅니다. 아래에서는 두 가지를 나눠 본 뒤, 어느 쪽이든 공통으로 거치는 진행 순서를 정리합니다.

패치

패치는 치명적인 버그 수정, 보안 취약점의 보완, 긴급한 밸런스 조정처럼 게임의 안정성과 공정성을 지키기 위한 작은 규모의 갱신입니다. 빨리 배포하는 것이 중요하고 바꾸는 범위를 작게 유지하려 하지만, 실제로 내려받는 크기는 바뀐 패키지와 배포 방식에 따라 달라집니다.

언리얼 엔진에서는 몇 가지 방식으로 접근합니다. 핫픽스(hotfix)는 Online Hotfix 플러그인의 UOnlineHotfixManager로 INI나 PAK, 번역 파일(locres) 같은 실행 파일이 아닌 파일을 내려받아 적용하는 방식입니다. 서비스와의 연결과 데이터마다 반영하는 로직이 필요하고, 바꾼 내용에 따라 맵을 다시 불러오거나 앱을 다시 시작해야 할 수도 있습니다. 실행 코드를 바꾸는 것과는 다른 방식입니다.

청크 패치는 .pak 파일이 여러 청크로 나뉘어 있을 때 바뀐 콘텐츠만 나눠 전달하는 방식입니다. 다만 pak 기반 패치의 변경 단위는 에셋 패키지라서, 에셋 안의 아주 작은 수정도 그 패키지 전체를 담을 수 있습니다. 바뀐 부분의 차이(diff)만 보내 패치 용량을 크게 줄이는 방식은, 엔진 자체 기능보다는 Steamworks SDK나 Epic Games Store의 배포 시스템 같은 외부 패치 시스템과 연동해 만듭니다.

업데이트

업데이트는 새 맵이나 캐릭터, 모드를 더하거나, 큰 시스템을 개선하거나, 그래픽 품질을 높이는 것처럼 게임에 큰 변화를 주는 갱신입니다. 계획한 주기로 배포하며 파일 크기가 클 수 있으므로, 플레이어에게 미리 알리고 기대를 모으는 것이 중요합니다. 언리얼 엔진에서는 새 기준 빌드를 만들고, 플랫폼의 패치나 전체 배포 방식에 맞춰 전달합니다. 사용자가 실제로 내려받는 크기는 배포 시스템이 정합니다. 버전은 Project Settings의 Description에 있는 Project Version을 갱신해 관리하며, 패치의 기준이 되는 릴리스를 만들어 보관하는 방법은 버전 관리 및 패치 적용에서 자세히 다룹니다.

패치와 업데이트의 흐름

패치와 업데이트는 다음 흐름으로 진행합니다. 먼저 버그 보고와 크래시 로그, 커뮤니티의 피드백으로 문제를 진단하고 업데이트 아이디어를 모읍니다. 그다음 프로젝트에서 문제를 고치거나 새 콘텐츠를 만들고, 고친 것이 다른 문제를 일으키지 않는지와 새 콘텐츠가 의도대로 동작하는지 내부에서 충분히 시험합니다.

시험을 마치면 Shipping 구성으로 패키징하고, 필요하다면 청크 패치나 차이 파일을 준비합니다. QA 팀이나 베타 시험자가 최종 빌드의 안정성과 품질을 확인한 뒤, Steam, Epic Games Store, Google Play, Apple App Store 같은 각 플랫폼의 스토어에 올려 배포합니다. 마지막으로 플레이어 커뮤니티에 패치의 내용과 고친 버그, 더한 콘텐츠를 자세히 알립니다.

---

게임의 상태 지켜보기

출시한 게임의 상태를 계속 파악하고 문제를 진단할 수 있는 체계를 갖춥니다. 출시한 뒤에는 개발할 때처럼 디버거를 붙이거나 화면을 직접 볼 수 없으므로, 플레이어의 컴퓨터에서 생긴 일을 데이터로 받아 와야 합니다. 이 체계는 출시 전에 패키지에 넣어 두어야 하며, 문제가 생긴 뒤에 더하면 이미 지나간 크래시와 기록은 되찾을 수 없습니다. 아래에서는 치명적인 오류를 모으는 크래시 보고, 플레이 데이터를 모으는 원격 측정과 분석, 실행 중의 상황을 남기는 로그를 차례로 봅니다.

충돌 보고

크래시 보고(crash reporting)는 게임 실행 중에 생긴 치명적인 오류, 즉 크래시(crash)의 정보를 자동으로 모읍니다. 제목처럼 충돌 보고라고도 부르지만, 이 교재의 다른 글에서 충돌은 주로 물체끼리 부딪히는 collision을 뜻하므로 본문에서는 크래시라고 씁니다. 언리얼 엔진에서는 패키지에 크래시 리포터 클라이언트(Crash Reporter Client)를 넣을지 정하고, 보고서를 받을 서버와 전송 방식을 구성합니다. 크래시 리포터는 기본적으로 패키지 게임에 들어가지 않으며, 넣었는지와 사용자 확인 없이 보내는 설정(unattended)에 따라 창이 뜨는지도 달라집니다.

모은 보고서는 직접 운영하는 서버나 연동한 서비스에서 빌드마다의 크래시 덤프와 호출 스택(call stack)으로 분석합니다. UE 5.4부터 Epic은 패키지 빌드의 크래시 보고서를 받지 않으므로, 개발자를 위해 자동으로 보고서를 모아 주는 사이트가 있다고 가정하지 않습니다. 이렇게 모은 정보로 가장 자주 생기는 크래시의 원인을 찾아, 우선순위가 높은 버그부터 고칩니다.

원격 측정과 분석

원격 측정(telemetry)과 분석(analytics)은 플레이 시간, 레벨의 완료율, 아이템의 사용 통계, FPS의 변화 같은 플레이 데이터를 모아 게임 디자인과 밸런스, 성능을 개선하는 데 씁니다. 언리얼 엔진은 기본적인 통계 수집 기능을 제공하며, Analytics Blueprint Library로 직접 정한 이벤트를 보낼 수 있습니다. 쓸 분석 서비스의 플러그인을 켜고, 그 서비스의 설정과 세션, 이벤트 전송을 만듭니다. 메뉴의 위치와 지원하는 서비스는 플러그인에 따라 다릅니다.

이렇게 모은 데이터로는 플레이어가 어느 구간에서 어려워하는지, 어떤 기능이 잘 쓰이지 않는지, 특정 하드웨어에서 성능이 떨어지는지, 게임의 경제가 의도대로 돌아가는지 같은 질문에 답할 수 있습니다.

로그

로그(log)는 실행 중의 정보와 경고, 오류 메시지를 기록해 문제가 생겼을 때 원인을 찾게 돕습니다. 개발 중에는 C++의 UE_LOG나 블루프린트의 Print String을 씁니다. 다만 Print String은 개발용으로만 동작하므로, 출시한 게임의 로그 경로로 의존하지 않습니다.

Shipping 빌드에서 로그를 남기려면 빌드 설정을 따로 확인해야 합니다. Packaging의 Include Debug Files는 디버그 파일을 넣을지 정하는 설정일 뿐 로그를 켜는 옵션이 아니며, Shipping의 로그는 타겟의 bUseLoggingInShipping 같은 빌드 설정과 실제 로그 파일의 경로, 수집 방식을 따로 확인합니다. 이렇게 남긴 로그는 플레이어가 버그를 보고했을 때 로그 파일을 받아, 문제가 생긴 순간의 게임 상태를 파악하는 데 씁니다.

---

커뮤니티와 피드백

플레이어와 적극적으로 소통하는 것은 유지보수의 핵심입니다. 공식 포럼, Discord 서버, 소셜 미디어, 게임 안의 피드백 기능처럼 플레이어가 쉽게 의견을 남길 수 있는 창구를 마련합니다. 모은 피드백은 정기적으로 검토하고, 버그의 심각성과 플레이어에게 주는 영향, 개발 자원을 생각해 고치고 만들 순서를 정합니다.

패치 노트와 개발 일지로 게임의 현황과 앞으로의 계획을 투명하게 알리고, 플레이어의 의견을 듣고 반영하려는 노력을 보여 줍니다. 버그는 Jira, Trello, Asana 같은 버그 추적 시스템으로 체계적으로 관리하고 팀원에게 할당합니다. 피드백을 받는 방법은 사용자 피드백을 통한 환경 개선에서 자세히 다룹니다.

---

운영 지표로 먼저 고칠 것 정하기

운영 단계에서는 무엇을 먼저 고칠지를 수치로 판단해야 대응이 흔들리지 않습니다. 다음 수치는 팀이 정할 수 있는 예시일 뿐 엔진이나 업계가 보장하는 기준이 아니므로, 표본 기간과 세션 수, 장치군, 서비스의 목표에 맞춰 정합니다.

P95 프레임 시간은 프레임 시간을 짧은 것부터 늘어놓았을 때 95%에 해당하는 값으로, 평균보다 가끔 생기는 긴 프레임을 잘 드러냅니다.

충돌 없는 세션 비율 계산하기

한 빌드와 같은 장치군에서 하루 동안 지켜본 세션이 2,000개이고, 그 가운데 크래시가 한 번 이상 있었던 세션이 중복을 뺀 뒤 16개라고 해 봅시다. 크래시 없는 세션 비율은 (2,000 - 16) ÷ 2,000 × 100 = 99.2%입니다. 앞의 예시 경보값 99.5%보다 낮으므로, 크래시의 원인을 조사하고 패치의 우선순위를 높입니다.

여기서 주의할 것은 보고서의 수와 세션의 수가 다르다는 점입니다. 크래시 보고서가 16건이라는 값만으로는 같은 세션에서 여러 번 보고된 것인지 알 수 없으므로, 이 계산을 바로 적용할 수 없습니다. 크래시가 있었던 세션을 중복 없이 세어야 비율이 의미를 가집니다.

증상마다 먼저 할 일

특정 업데이트 이후 저사양 장치에서 프레임이 크게 떨어졌다면, 같은 장치와 장면에서 Game, Draw, GPU를 비교하고, GPU가 병목이라면 관련 렌더링 단계를 캡처해 큰 비용부터 나눕니다. 패치를 적용한 뒤 실행하자마자 크래시가 늘었다면, 크래시 보고의 상위 호출 스택 한두 개를 기준으로 되돌릴(rollback) 수 있는지 먼저 판단한 뒤 핫픽스용 브랜치를 나눕니다. 커뮤니티에서 같은 버그가 되풀이해 보고된다면, 재현할 수 있는 가장 작은 시나리오를 문서로 정리하고, 재현에 성공한 경우를 기준으로 고칠 범위를 정합니다.

장애를 기록하고 복구하는 기준

장애가 생기면 버전과 플랫폼, 콘텐츠 빌드, 재현 절차를 보고서와 지표에 함께 남깁니다. 진행이나 저장, 결제를 막는 문제는 보고한 사람이 적어도 긴급 후보로 분류합니다. 그리고 패치 전후의 같은 지표를 비교하며, 배포를 멈추거나 되돌릴 조건과 기존 세이브 파일과의 호환성을 확인합니다.

---

정리

• 배포한 뒤의 유지보수는 버그와 보안 문제를 고치고, 피드백을 반영하고, 콘텐츠를 더하고, 기술 부채를 갚아 게임의 수명을 늘리는 일입니다.
• 패치는 작은 긴급 수정, 업데이트는 큰 변화이며, 핫픽스는 실행 파일이 아닌 데이터를 바꾸고, pak 기반 패치는 에셋 패키지 단위로 바뀝니다.
• 크래시 리포터는 기본으로 패키지에 들어가지 않으며, UE 5.4부터 Epic은 패키지 빌드의 보고서를 받지 않으므로 수신 서버를 직접 마련합니다.
• Shipping의 로그는 Include Debug Files가 아니라 bUseLoggingInShipping 같은 빌드 설정으로 정하며, Print String은 출시 빌드에서 동작하지 않습니다.
• 운영 지표의 기준은 팀이 정하는 예시이며, 크래시 없는 세션 비율은 크래시가 있었던 세션을 중복 없이 세어 계산합니다.
• 진행과 저장, 결제를 막는 문제는 지표와 상관없이 긴급 후보로 보고, 패치 전후의 같은 지표와 세이브 호환성을 확인합니다.

---

연습 문제

1. 경보를 통과했으니 괜찮을까

같은 정의로 지켜본 1,000개 세션 가운데 크래시가 난 세션이 4개입니다. 한편 저장한 데이터가 사라지는 버그가 사용자 한 명에게서 재현 가능하게 확인되었습니다. 크래시 없는 세션 비율은 얼마이고, 예시 경보값을 통과했다는 이유로 저장 손실 버그를 긴급 후보에서 빼도 될까요?

해설 보기

(1,000 - 4) ÷ 1,000 × 100 = 99.6%이므로 크래시에 대한 예시 경보값 99.5%는 통과합니다.

하지만 저장 손실은 크래시와는 별개의 치명적인 동작 실패이므로, 크래시 지표를 통과했다는 것이 이 버그를 뺄 이유가 되지 않습니다. 재현 조건과 영향을 받는 범위, 복구할 수 있는지를 확인하고 긴급 후보로 검토합니다. 또 한 장치군의 비율을 모든 장치로 넓혀 말하거나, 경보가 울리지 않았다는 사실을 결함이 없다는 뜻으로 읽지 않습니다.

2. 보고서 수로 비율을 계산하면

하루 동안 세션이 500개였고, 크래시 보고서는 10건이 들어왔습니다. 팀원이 (500 - 10) ÷ 500 × 100 = 98%라고 계산했습니다. 이 계산은 맞을까요?

해설 보기

맞다고 할 수 없습니다. 크래시 없는 세션 비율은 크래시가 있었던 세션의 수로 계산해야 하는데, 보고서 10건은 같은 세션에서 여러 번 보고된 것일 수 있기 때문입니다.

예를 들어 한 세션에서 크래시가 세 번 보고되었다면 그 세션은 한 번만 세야 합니다. 보고서를 세션 단위로 묶어 중복을 뺀 뒤, 크래시가 있었던 세션의 수로 다시 계산합니다.

3. Shipping에서 로그가 남지 않는다

출시한 Shipping 빌드에서 플레이어의 로그 파일을 받아 보려 했는데, 기대한 로그가 거의 남아 있지 않습니다. Packaging의 Include Debug Files는 켜 두었습니다. 무엇을 확인해야 할까요?

해설 보기

Include Debug Files는 디버그 파일을 패키지에 넣을지 정하는 설정이라, 로그를 켜는 옵션이 아닙니다. Shipping에서는 로그가 기본적으로 제한되므로, 타겟 설정의 bUseLoggingInShipping 같은 빌드 설정을 확인해야 합니다.

또 로그를 Print String으로 남겼다면 그 노드는 개발용으로만 동작하므로 Shipping에서는 출력되지 않습니다. 출시 빌드에 남길 로그는 Shipping에서도 동작하는 로그 방식으로 남기고, 실제 로그 파일의 경로와 수집 방식도 함께 확인합니다.

크래시 보고 설정은 Epic의 크래시 리포터 안내에서 확인할 수 있습니다.

다음 글 버전 관리 및 패치 적용에서는 출시한 빌드의 버전을 정하고 관리하는 방법과, 패치를 만들어 기존 사용자에게 적용하는 과정을 다룹니다.