새벽 3시에 전화벨이 울립니다. 운영팀에서 걸려온 긴급 연락이에요. "PM님, 큰일났습니다. 방금 업데이트한 패키지에서 골드가 무한 복사되는 버그가 발견됐습니다." 이 순간부터 지옥이 시작됩니다. 라이브 사고는 게임을 서비스하다 보면 피할 수 없는 일이에요. 24시간 돌아가는 서비스인데 문제가 안 생기는 게 오히려 이상하죠. 중요한 건 어떻게 대처하느냐입니다.
라이브 사고 시 일단 멈출지 말지부터 판단해라
라이브 사고가 터지면 제일 먼저 해야 할 일은 상황 파악입니다. 이게 어떤 버그인지, 누구에게 영향을 주는지 빠르게 알아내야 합니다. 단순 표기 오류인지, 게임 밸런스를 박살내는 치명적인 버그인지에 따라 대응이 완전히 달라지기 때문입니다. 전체 유저에게 영향을 주는 심각한 사고라면 망설이지 말고 서버부터 내려야 합니다. 골드 무한 복사, 아이템 중복 획득, 결제 오류 같은 건 1분 1초가 아까워요. 상황 파악이 완전히 안 됐어도 일단 서버 중지하고 공지 올린 다음 천천히 확인하는 게 맞습니다.
반대로 사소한 버그면 굳이 서버를 내릴 필요는 없습니다. UI 텍스트 오타나 특정 스킬 이펙트 깨짐 정도는 다음 정기 점검 때 고쳐도 됩니다. 서버 중지는 그 자체로 유저한테 큰 불편을 주니까 신중해야 합니다. 문제는 애매한 경우입니다. 특정 유저 그룹에만 영향을 주는 버그라면 판단이 어려워요. 예를 들어 50레벨 이상 유저가 특정 던전 입장하면 보상을 두 배로 받는다면? 당장 서버를 내릴 정도는 아니지만 방치하면 밸런스가 무너집니다. 이럴 땐 해당 던전만 긴급 폐쇄하고 수정 작업에 들어가는 게 현실적입니다.
피해 범위 파악이 보상을 결정한다
서버를 다시 열었다고 끝이 아닙니다. 이제 보상 문제가 남았습니다. 누구한테 얼마나 줄지 정하는 게 진짜 골치 아픕니다. 전체 유저가 피해를 봤다면 오히려 간단합니다. 모두에게 똑같이 보상 주면 되니까요. "긴급 점검 보상으로 골드 10만 개 드립니다" 하면 끝이에요. 유저들도 "뭐 어쩔 수 없지" 하고 넘어갑니다. 문제는 특정 유저만 피해를 본 경우입니다. A 유저는 버그 때문에 아이템을 못 받았는데, B 유저는 버그 덕분에 두 배로 받았다면? 보상을 누구한테 줘야 할까요? 피해 본 사람한테만 주면 되지 않냐고요? 그게 쉽지 않습니다.
반사 이익을 본 유저들 때문입니다. 버그로 아이템이 폭락했다면, 그걸 싸게 산 유저는 이득을 봤잖아요. 이 사람들한테도 뭔가 조치를 해야 할까요? 안 하면 피해 본 유저들이 "불공평하다"고 난리가 납니다. 반사 피해를 본 유저도 있습니다. 버그를 악용한 유저 때문에 거래소 물가가 폭등해서 간접적으로 손해를 본 사람들이요. 이런 사람들까지 추적해서 보상하는 건 사실상 불가능합니다. 결국 기준을 명확히 세워야 합니다. "이번 버그로 직접적인 피해를 입은 유저에게만 보상합니다"라고 못 박는 거죠. 간접 피해나 반사 이익은 무시해야 합니다. 모든 걸 완벽하게 보상하려다 보면 끝이 없습니다.
유저 소통이 사고 수습의 핵심이다
라이브 사고 대응에서 제일 중요한 건 유저와의 소통입니다. 버그 자체보다 게임사가 침묵하는 게 유저들을 더 화나게 만듭니다. 사고가 터지면 일단 공지부터 올려야 합니다. 상황 파악이 다 안 됐어도 "현재 ○○ 문제를 확인 중입니다. 파악되는 대로 추가 공지 드리겠습니다" 이 정도는 즉시 올려야 해요. 유저들은 게임사가 인지하고 있다는 것만 알아도 어느 정도 기다려줍니다. 업데이트를 자주 해야 합니다. 30분에 한 번씩이라도 "계속 확인 중입니다"라고 올리세요. 아무 소식이 없으면 유저들이 "게임사가 도망갔나?" 불안해합니다.
해결 과정을 투명하게 공개하는 것도 좋습니다. "원인 파악 완료 → 수정 작업 중 → 테스트 진행 중 → 서버 오픈 예정" 이런 식으로 진행 상황을 알려주면 유저들도 이해하기 쉬워요. 보상 내역도 명확히 설명해야 합니다. "왜 이 사람들한테만 보상을 주는가"에 대한 근거를 제시하세요. 애매하게 넘어가면 커뮤니티가 난장판이 됩니다. 사과도 제대로 해야 합니다. 형식적인 사과문은 오히려 역효과예요. "불편을 드려 죄송합니다" 이런 뻔한 말보다는 "이번 사고로 ○○한 피해를 드렸고, 재발 방지를 위해 △△ 시스템을 도입하겠습니다" 이렇게 구체적으로 말하는 게 낫습니다.
결론
사고가 수습됐다고 끝이 아닙니다. 같은 일이 반복되지 않게 만드는 게 진짜 PM의 역할입니다. 사고 원인을 철저히 분석해야 합니다. 개발 실수였는지, QA 과정에서 놓쳤는지, 데이터 입력 오류였는지 파악하세요. 원인을 알아야 대책을 세울 수 있습니다. 개발 프로세스를 개선해야 합니다. 같은 유형의 버그가 반복되면 프로세스에 문제가 있는 거예요. 코드 리뷰를 강화하거나, 자동화 테스트를 추가하거나, 체크리스트를 보강하는 식으로 시스템을 바꿔야 합니다. 비상 대응 매뉴얼도 만들어두세요. 어떤 버그가 터졌을 때 누가 무엇을 해야 하는지 미리 정해두면 다음번엔 더 빠르게 대응할 수 있어요. 새벽에 전화 받고 당황하지 않으려면 준비가 필요합니다. 라이브 사고는 정말 겪고 싶지 않지만 피할 수 없습니다. 중요한 건 사고가 터졌을 때 얼마나 빠르고 정확하게 대응하느냐예요. 상황 파악, 피해 범위 확인, 적절한 보상, 투명한 소통. 이 네 가지만 제대로 해도 사고를 기회로 바꿀 수 있습니다. 유저들은 완벽한 게임을 원하는 게 아니라 믿을 수 있는 게임사를 원하니까요.