가방에서 시작된 기나긴 점검의 시작 (Q:이게 이렇게까지 될 일이었나요? / A:그럴 수도 있는 일이었습니다.)

이슈로 관심을 끌어모으거나 어디 노출되는 글을 쓰는 취미는 없습니다만, 여러 커뮤니티에서 나오는 불만 동향을 보면 마음이 아파서 잠시 키보드를 두드려봅니다.

관심이나 보상을 바랐다면 저는 포*타입이나 브*치에 글을 투고했을 것입니다.

 

자세히 말씀드리기 어려우나, 저는 관련 업계에서 일을 하고 있기에 일반 유저들이 답답해하거나 궁금해하는 부분을 제가 이해한 대로 풀어서 이야기하는 정도는 할 수 있다고 생각합니다. (마치 마시멜 작가님의 웹툰 '게임회사 여직원들'처럼요.)

저에 대해 자세히 밝히지 않는 이유는 그냥 제 정보가 외부에 드러나는 걸 싫어해서 그렇습니다.

 

물론 저는 절대로 넥슨 직원이나 데브캣 직원이 아닙니다. 연관자는 당연히 아니고, 그곳에서 일을 한 적도 없어요. 만약 제가 연관이 있는 사람이라면, 이 글을 쓰는 저는 기밀유지 서약 위배로 회사에 고소당해야 합니다. (농담 아님)

다만, 외부인이면서 동시에 비슷한 업계에 있다고 주장하는 사람이 타사의 개인 사정을 멋대로 추측하고 상세하게 이야기하려 드는 일은 예의에 어긋난 행동일 수 있습니다. 분명 불쾌한 일이며, 주제넘은 짓이기 때문에 자세하고 깊게 이야기할 생각은 없습니다. 잘잘못을 따질 생각도 없고요. 오히려 저는 솔직히... 격려의 말을 많이 보내고 싶은 마음이네요. 그렇다고는 하지만 만약 이 글이 영혼의 실드로 보인다면, 그건 아닙니다.

 

 

어그로 끄는 건 정말 싫어하지만 이 글을 쓰는 이유는 단 3가지입니다.

 

1) 동병상련 : 비슷한 일을 하는 입장으로서 보는 제가 마음이 아픕니다...

2) 가방 하나로 이렇게까지 될 일이었는지 의아해하는 사람들이 많아서 설명 용도

3) 그냥 최근에 꽤 재밌게 하던 게임이 욕을 꽤 먹고 있어서 좀 마음이 아픔

 

1과 3의 이유로 반쯤 대신 해명(?)한다는 느낌과 동시에 2의 이유와 목적을 충족시키기 위함으로 정리할 수 있겠습니다.

 

 

참고로 저 또한 이번 이슈로 가방을 날려먹은 사람입니다.

물론 그다지 비싼 물건을 날린 건 아니지만, 마비노기를 처음 시작할 때 선물 받았던 의장이 날아가서 마음이 썩 편하지 않았습니다. 그걸 하필이면 그 가방에 넣어가지고 아이고아이고

 

(좌) 7월 29일 12시 16분 / (우) 7월 29일 18시 10분

 

---

이 글은 크게

1. 7월 29일 ~ 7월 30일 이틀 사이에 무슨 일이 있었는가?
2. 업데이트 ~ 점검까지 무엇을 하길래 이런 버그를 못 찾았을까?
3. 가방 순서 고치는 일이 그렇게 큰 작업인가?
4. 아이템 복구가 그렇게까지 긴 시간을 들여 힘들게 해야 하는 작업이었나?
5. 17년 된 자체 엔진, 정말 바꿀 수 없는 것인가?

에 관한 이야기를 넥슨과 1도 관계없는 사람이(진짜 관계없어요... 키트 값으로 넥슨 회사에 벽돌 한두 개 정도는 세웠다는 관계는 있을지도 모르겠습니다.) 무슨 일이었을까 생각하며 중얼거리는 글입니다.

 

 

우리 점검 얼마나 한 거야?

정규 서버 패치 (업데이트)

처음 시작은 7월 29일 목요일 오전 6시 ~ 11시였습니다.

이 중에서 6시 ~ 8시까지는 넥슨 자체의 정기점검이므로, 마비노기 자체의 업데이트 작업은 8시 ~ 11시까지 총 3시간이 됩니다.

 

 

라이브 게임 업데이트 점검 시간에 하는 일은 크게 아래와 같습니다. 회바회 팀바팀이긴 하겠지만 크게 다르진 않을 것이라 생각해요.

1. 정식 서버에서 신규 추가된 콘텐츠의 QA
2. 점검 중 확인된 이슈 수정사항 적용 및 기타 수정내역 적용
3. 전체 기능 테스트

QA는 Question&Answer가 아닙니다. Quality Assurance입니다.

 

이상적으로 점검 및 업데이트가 진행된다면 보통 점검 시간 동안에는 신규 추가된 내용의 검수를 마치고 남은 시간 동안 기본 기능에서 이상하게 작동하는 것은 없는지, 예상치 못한 예외사항은 없었는지 추가적으로 확인합니다. 

 

점검은 말 그대로 '점검'이기 때문에 업데이트 사항을 모두 적용하고 그걸 라이브 환경에서 확인하는 시간입니다.

물론 당연하게도 실제 라이브 서버─즉, 류트/하프/울프/만돌린 등의 실제 유저 서버─에서 진행하지는 않을 겁니다. 진행을 하더라도 서버가 열리기 전에 테스트 진행했던 데이터는 모두 삭제하고 서버가 열립니다. 반드시 그래야만 합니다. 안 그랬다가 걸리면 유저들이 회사를 상대로 소비자 보호원을 통해 고발할 명목을 갖게 될 수도 있거든요.

 

Q. 만약에 점검 테스트 담당자가 라이브 서버에서 악용하면 어떻게 되나요?

A. 회사에서 잘리고 고소당합니다. 그리고 이후 취업 시 불이익을 받을 수 있습니다. 그러니 걱정마세요.

 

비슷한 사례 사건사고

https://www.inven.co.kr/webzine/news/?news=193476 

넷마블 자회사 IGS, 대항해시대 아이템 조작 및 판매 논란

 

http://www.inews24.com/view/1298494

'던파' 내부 직원이 부정행위…"민·형사상 법적 대응"

 

그렇게 정식 점검 시간이 종료되고, 11시에 서버가 열렸습니다.

그리고...

 

1차 임시 점검 (12:30 ~ 17:30)

일부 유저에게 문제가 발생하였습니다.

• 일부 가방이 가방 순서 정렬 리스트에 표시되지 않음
• 일부 가방이 인벤토리를 오픈할 때마다 닫힘
• 일부 가방의 아이템 복사(실제로 복사되지 않으나, 아이콘이 복사됨)
• 일부 아이템 소실

그리고 이걸 해결하기 위해 점검에 들어갑니다.

 

14:30 완료 예정이었던 점검은 16:30으로 연장되고, 17:30까지 연장을 마지막으로 종료되었습니다.

가방 순서 정렬 기능은 롤백되었고, 겸사겸사 폭스롯의 스킬이 수정되었습니다. (tmi)

 

하지만 이후로도 가방 내의 아이템이 분실되는 이슈가 계속 발생합니다. 가방 줄이 이상해지는 이슈도요.

저 또한 이 타이밍에 아이템을 분실하였습니다.

 

저는 정식 업데이트 점검 이후 가방 순서를 모두 바꾸었고, 가방에 악보 스크롤(1000)이 있었으며, 이 스크롤을 17시 30분 점검 이후 바닥에 떨어트려 다른 유저에게 주었습니다.

고객센터 문의 내용 중 일부

 

 

얘들아 이거 실화니?

 

2차 임시 점검 (2021-07-30 02:00 ~ 03:00)

1차 임시 점검 후 어느 정도 잠잠해지는 듯 보였으나, 아이템이 사라지는 이슈는 명백히 라이브에 잔존한 상태였습니다. 아마 이슈의 원인이 되는 사전 조건에 해당하는 유저 대부분이 이미 아이템 분실을 겪었기 때문에 추가 발생은 하지 않는 상황이었을 겁니다.

 

그러니까 비유하자면, 에볼라 바이러스가 퍼졌는데 보균자들은 진작 증상이 발현되어서 죽을 사람 다 죽고 감염 안 된 사람만 살아 있는 상황이 되었습니다. (여기선 사람이 아닌 가방이 그 대상)

밤늦게까지 열심히 원인을 찾고, 디버깅해서... 어느 순간 원인 파악을 했고 수정 패치 파일이 만들어진 겁니다.

 

이 상황은 매우 Critical 한 이슈(유저의 재화에 직접적인 피해를 끼치는 이슈)이므로 시간 상관없이 급하게 점검 공지를 띄웠을 상황이 상상되어 슬픕니다. 3시까지 점검을 마친 뒤 30분 ~ 1시간가량 모니터링을 하고 4시가 다 되어 잠을 잤겠죠. 그리고 6시~7시 사이에 일어나 8시부터 복구하는 작업을 하기 시작했을 겁니다. (눈물이 앞을 가리네요.)

 

어쨌든 이제 이 시점에서 아이템이 분실되는 이슈는 (아마도) 수정되었습니다.

 

 

긴급 점검 (08:00 ~ 14:00)

사라진 아이템을 복구하기 위한 개발실/운영실의 고군분투가 시작되었습니다.

12시로 예정되어있던 긴급 점검은 2시간 연장하여 14시에 종료되었습니다.

 

여전히 복사가 됐다거나 복구가 안 됐다거나 이런저런 문제는 많지만 어쨌든 어느 정도 복구는 되었어요.

이런 일이 오늘 낮까지 있었습니다.

 

 

이런 일이 일어날 줄 몰랐을까?

알 수도 있고 모를 수도 있습니다.

 

개발단에서는 어떤 일이 일어날지 모릅니다. 정확히는 알 수도 있고 아닐 수도 있습니다.

연관된 영역을 따져가며 사이드 이펙트가 발생할 수 있는 영역을 유추해낼 수는 있습니다. 이는 담당자의 숙련도와 동일 프로젝트를 얼마나 오래 하여 히스토리를 얼마나 상세히 알고 있느냐에 따라 갈립니다. 17년이나 된 게임에서는 작업자의 역량의 문제를 조금(... 많이) 벗어난 영역일 수도 있습니다.

 

NDC에서 발표하신 기획자분께서 '부르짖다 죽을 그 이름 히스토리'라는 말씀을 하셨던 게 괜히 그런 것이 아닙니다.

물론 기획단의 히스토리는 조금 다른 느낌이지만 아무튼 어느 부서나 히스토리는 중요합니다.

 

 

게임 개발은 개발 초기단계에서부터 많은 피드백과 테스트를 진행합니다. 초기 기획 단계에서부터 어떤 부분이 어디에 영향을 줄 것이다, 어떤 방식으로 개발할 것이다, UI는 어떻게 할 것이다 등등의 논의가 이루어지고 일정을 산정하고 리소스를 투자했을 것입니다.

 

 

분명 개발 환경에서는 이런 이슈가 발견되지 않았기 때문에 업데이트를 진행했을 것입니다.

그러나 모든 인간이 만든 프로그램, 모든 제품은 반드시 결함이 있습니다. 단지 발견되지 않을 뿐입니다. 아무리 섬세하게 예외사항을 걸러내고 디버깅을 해도 1+1=2 같은 단순한 연산이 아닌 이상 결함은 반드시 있습니다. 개발 및 소프트웨어 테스팅의 기본에서 다루는 내용이기도 할 만큼 매우 당연하고 중요한 사실입니다.

 

특히나 마비노기는 17년이나 된 장수 게임입니다. 기네스북에 올라간 같은 회사 게임 '바람의 나라'가 참고로 25년 됐습니다. (그만큼 온라인 게임 중에서는 오래되었다는 뜻)

서로 유기적으로 연결된 영역이 많고, 그것들이 어디서 어떤 예외사항을 발생시킬지 모든 경우의 수를 알기란 정말 어렵습니다. 굵직한 콘텐츠로만 분류해도 제 손가락과 발가락이 모자라니까요.

 

 

개발 환경에서는 분명 열심히 디버깅을 하고, 개발을 하고, 테스트를 하고 나서 이대로 패치 내용을 런칭해도 괜찮다!라는 결론을 내렸을 거라고 생각해요.

 

 

왜 라이브 적용 전에 발견하지 못했을까?

할 말은 많습니다만, 어떻게 전달하는 것이 좋을지 모르겠습니다. (일단 제가 마비노기 경력이 짧고요ㅋㅋ ㅠ)

 

마비노기는 지난 17년간 너무 많은 데이터와 코드를 누적해왔습니다. 점검 때까지 개발실 기준으로 정상이라 판단하였으나, 커버리지 외의 영역에서 이슈가 발생한 것이라고 생각합니다. 유저로서는 알 수 없는, 복잡한 개발실만의 사정들이 있었겠지요.

 

마비노기에서는 유저 입장에선 도무지 엥? 스러운 현상은 사실 기존부터 있어왔습니다.

• 화살, 볼트를 장착하면 비정상적인 악보로 취급되어 프리스타일 잼에 참여가 불가하다.
• 악보는 어떤 악보 건 펫, 은행 등에 보관할 수 없다. (서버에 아주 큰 부하가 간다고 합니다.)
• 요리할 때 아이템을 스택 상태로 재료로 넣는 경우 스택을 1개의 아이템 취급하여 1회에 모두 소모한다.

크게 지금 당장 생각나는 것만 3개를 적어보자면 이런 것들이 떠오르네요.

 

이는 초기 개발에서 (아마도) 고려되지 않은 사항들이 훗날 예상치 못한 범위에서 발견되는 것으로 생각하고 있습니다.

 

문제는 이겁니다. 먼 과거에 개발된 내용 중 미래를 고려하지 않은 코드가 많다는 거죠. 너무 먼 옛날이고 그때는 미래에 어떤 내용을 넣게 될지 아무도 몰랐을 겁니다. 게다가 마비노기는 다들 알다시피 자체 개발 엔진을 사용합니다. 미래에 어떤 엔진 기능이 필요하게 될 지도 완벽히 알기 어려웠을 거예요.

 

그리고 다수의 인원이 참여하는 프로젝트라는 것은... 당장은 멀쩡하게 작동하는 것도 이게 엄청 단순해 보였지만 사실은 하드코딩 작업이었을 수도 있고 최악의 경우 어떤 코드에 의해 동작하는지 모를 수도 있는 무시무시한 상황을 낳기도 합니다. (근데 진짜 이 정도까진 아닐 거예요. 이건 정말 최악 of 최악의 가정이지요.)

 

그런데 그것이 실제로 (이하생략) (feat.핀볼)

 

그래도 컴파일 에러가 나는 경우에는 어떤 구문에서 에러를 띄우는지 보여주고, 컴파일이 멀쩡히 되었지만 의도대로 동작하지 않는다면 클라-서버 간 어떤 패킷을 주고받는 중인가를 모두 모니터링할 수 있기 때문에 이상한 부분이 있다면 해당 구간을 모니터링하거나 추적할 수 있게끔 로그를 심어서 확인이 가능합니다. 그리고 어디가 문제인지 파악이 된다면 수정 자체는 꽤 빠르게 이루어질 수 있습니다. 사전에 이슈가 '발견되었다'면 말이에요.

 

 

개발 환경은 의외로 라이브보다 제한적인 환경입니다. 일단 라이브만큼의 방대한 데이터를 가진 캐릭터가 (아마도) 없습니다. 때문에 라이브 환경이 아니라면 발견되지 않는 이슈가 많습니다. 이번에 제가 겪은 아이템 소실 이슈의 경우도 악보 스크롤을 버린 밀레시안에게 발생한 이슈였으니까요. 설마 악보 스크롤이라는 특정 아이템이 이런 거대한 이슈를 일으킬 줄은 생각도 못했겠죠! 심지어 악보 스크롤 때문에 아이템이 소실되는 이슈는 사전 조건이

1. 롤백 전 순서를 변경한 가방
2. 그 가방에 악보 스크롤을 갖고 있어야 함

이런 경우였으니까요. 이 부분에 한해서는 개발실도 조금 억울했을 것 같습니다. 롤백을 안 했다면 없을 문제였을 테니까요. 물론 그 기능 자체가 문제가 있었으니 Fail입니다만.

(가장 초기에 롤백 전에 발생한 일부 가방 안 보임, 창이 닫힘, 순서 변경에 안 보임 등의 이슈는 원인을 저도 모릅니다. 아마 복잡하게 엉킨 무언가의 문제가 있었겠지요.)

 

라이브 서버에서 캐릭터 데이터를 복사해오는 방법도 있으나, 유저 개개인의 프라이버시 문제는 둘째치고 DB의 양이 너무나도 많아서 그 라이브 데이터를 개발 환경으로 가져와 사용하는 것은 한계가 있습니다. 물리적으로 너무 오래 걸립니다. 과거에 서버 통합 때 점검 시간을 생각해보면 좋을 것 같습니다. 그리고 그렇게 라이브 서버에서 복사해온다 해도 이슈가 발생할 특정 조건에 해당하는 유저 데이터를 고를 확률이 과연 얼마나 될까요?

라이브 환경에서는 다수의 유저가 각자 자신의 캐릭터에 접속하여 짧은 시간 동안 많은 행동을 하지만, 개발실의 인력은 한정적입니다.

 

유저 수백 수천 명이 n분 동안 만들어내는 행동 로그와 테스트 케이스를 개발실 인력으로는 몇 날 며칠을 해도 따라갈 수 없었을 것입니다.

그래서 이번 이슈는 만약 개발실 내에서 라이브 환경을 복사한 뒤 그 서버에서 테스트를 했다고 하더라도 발견 못했을 가능성이 큽니다. 이는 개발실의 역량 문제라기보다는 정말 물리적인 한계입니다.

 

물론 테스트 서버에 선 적용 후 실서버 적용을 했다면 좋았겠다는 생각은 저도 하고 있습니다. 그렇지만 이건 제가 테스트 서버를 유저들에게 공개하여 유저들이 직접 확인 후 버그 리포팅하는 방식으로 해본 적이 없어서... 함부로 말을 얹을 영역이 아닌 것 같아요. 아무튼 저는 좋은 의견이라고 생각해요.

어쩌면 크롬 바스 처럼 큰 콘텐츠가 아니라 단순 편의성 개선이기 때문에 테스트 서버 도입을 고려하지 못했을 수 있을지도 모르지요. 물론 이건 추측성 발언이니 어디 가서 이런 얘기 하시면 안 됩니다.

 

 

가방 순서 건드린 일이 이렇게까지 될 일이었나?

 

잘은 모르겠지만, 그럴 만했다고 생각합니다.

저는 개인적으로 게임에서 가장 많은 콘텐츠와 엮여 있고 복잡하게 엉켜 있는 영역이 아이템, 상점, 가방이라고 생각합니다. 그래서 저는 모든 온라인 게임을 처음 시작할 때 제일 먼저 상점과 아이템 도감부터 둘러보고 어떤 컨텐츠가 있을 지, 과금 모델이 무엇일 지 훑어보고 시작하거든요. 그럼 대충 어떤 식으로 캐릭터가 성장하는 게임인 지, 뭘 해야 하는 지 감이 잡힙니다. (제 경험을 기반으로 이야기하는 것이라 여러분과 생각이 다를 수 있습니다.)

 

위에서 언급한 3가지는 그 어떤 항목이든 대부분의 모든 컨텐츠와 연결되어있습니다.

신규 입사자에게 2주일 동안 위의 항목을 유지보수하도록 시켜놓으면 담당 프로젝트에 있는 대부분의 콘텐츠를 중간 이상은 이해할 수 있는 훌륭한 신입사원이 됩니다. 그 정도입니다. (정말이에요.)

 

하여튼 정말 게임이라는 프로젝트에서 아이템, 재화란 그런 정도의 것입니다. 아이템 하나하나는 별 것 아닌 데이터 쪼가리일지 몰라도 이 모든 아이템을 하나의 테이블로 모으면 한 마디로 DB지옥이며, 폭탄이고, 기획자의 눈물과 서버 담당자의 땀으로 이루어져 클라이언트 담당자의 외마디 비명을 통해 완성된 정수입니다.(거기에 UX파트와 아트팀의 피땀 눈물도 함께)

어느 정도냐면... 엑셀 파일의 용량이 기가바이트 단위로 넘어가는 걸 보신 적 있나요? 저는 봤습니다. 복잡한 함수나 VBA 없이 오로지 데이터만으로요!

 

화이팅

 

 

그래서 아이템 복구를 하는 데에 6시간씩이나 걸릴 일인가?

 

자, 아이템이 있습니다.

아이템을 구분하기 위한 고유의 Id가 있겠죠. 그럼 Item.xls이라는 데이터 테이블은 이렇게 구성됩니다.

※ 실제 마비노기의 데이터가 아니라 인게임 데이터를 참고하여 임의로 작성한 예시 이미지입니다.

 

왜 바펠이냐면 제가 들고 있어서요

생각해보니, 포션 종류와 장비 아이템은 구분해야 할 것 같아요. 그리고 어느 재능의 장비인지도 구분해줘야겠네요. 내구도 정보도 넣어야 해요. 능력치 정보도 당연히 있어야죠.

 

이러다가 이제 방대한 데이터에 후다닥 다른 엑셀 파일을 참조하고 또 참조하는 무지막지한 문어발식 엑셀이 탄생합니다.

이런 식으로 줄줄 늘어납니다.

단순히 생각하면 저 ItemId를 기반으로 해당 식별자의 아이템을 지급하면 되지 않을까?! 싶은데, 마비노기는 그렇게 만만하지 않습니다.

 

 

그럼 이제 복구 시 검토해야 하는 내용은 기본적으로 무엇이 있을지 알아봅시다.

1. 아이템 종류 (ItemId 정보)
2. 기본 옵션 (민댐/맥댐/방어/보호/마방/마보)
3. 그 아이템의 현재 내구도/최대 내구도
4. 부가 옵션 (크리티컬, 피어싱, 속성 등)
5. 인챈트 정보 (접미/접두)
6. 개조 (일반 개조/보석 개조/장인 개조/특수 개조)
7. 세공
8. 정령
9. 에르그
10. 염색
11. 전용 해제 횟수
12. 기타 강화 효과 (인챈트 보호 포션, 수리 보호 포션)
13. 넴작 정보
14. 보헤미안, 크레시다, 헤보나 등의 장비의 경우 강화 레벨
15. 그 외에 이것저것 어쩌고 저쩌고...

 

마비노기는 대부분이 일정 범위 내에서 랜덤으로 옵션 등이 정해지기 때문에... 이 정보는 유저가 갖고 있던 아이템의 로그를 토대로 일일이 대조하여 복구해야 했을 것입니다. 그 시점의 데이터를 가져와 일괄 지급해버리는 것이 아니라면요.

 

소실된 시점의 데이터를 일괄 복구하는 작업이었을지라도 그 캐릭터가 아이템을 소실했던 시점을 찾아서 대조하는 작업은 필요했을 것입니다. 왜냐하면 유저마다 아이템이 소실된 시점이 다 달랐거든요.

 

...화이팅...

 

 

17년 된 엔진, 정말 못 바꾸나?

 

엔진, 엔진이란 무엇일까요? 사진, 그림 작업을 하는 분들께는 포토샵이나 클립 스튜디오 같은 프로그램이 됩니다. 이것저것 툴을 이용해 조합하고 올려서 유기적으로 게임을 동작하게 해 줘요. 물론 코딩을 미친 듯이 해서 할 수도 있지만, 엔진을 사용하면 많은 부분이 편해지고 퀄리티가 좋아집니다. 그러니까 엔진 개발자들이 이미 만들어놓은 도구를 사용해서 더 나은 결과물을 만드는 거예요. 물론 아예 코딩 작업이 없진 않습니다. 어쨌든 맨 땅에 온갖 수식과 코드를 쓰는 것보단 훨씬 나은 작업을 하도록 도와주는 도구죠.

 

그런데 일단 17년 전에 가져온 이 자체 엔진, 여러 문제가 많습니다. 당장 검색만 해도 나오는 고질적인 위치 렉과 연산 방식, CPU학대 등의 문제를 비롯해서 많은 문제가 있지요.

 

사용하는 사람 입장에서도 애로사항이 제법 있을 것입니다. 유니티, 언리얼 같은 유명한 게임 엔진은 전 세계적으로 널리 사용되는 엔진이므로 다양한 기능을 구글링을 통해 찾을 수 있고, 없는 기능을 만들고자 해도 비교적 쉽게 정보를 얻어 개선하고 개발할 수 있습니다. 이미 너무나도 잘 나온 애셋도 많고요. 그런데 자체 개발 엔진은 내부의 매뉴얼을 따르고 상급자의 인수인계에 의존하고 기능 개발이 필요하다면 자신이 그 엔진을 직접 공부하고 뜯어봐야 하는 상황입니다. 

 

그럼에도 불구하고 바꾸기 어렵다고 합니다.

 

 

왜 어렵냐면, 이 상황을 비유해보자면... 오픈 캔버스의 이벤트 파일을 클립 스튜디오에 불러와서 작업해달라는 의미이며, 메모장에 html로 만든 홈페이지를 아보카도 에디션을 이용하여 반응형 페이지로 만들어달라 하는 것과 비슷하다고 비유해볼 수 있겠습니다. 엔진이 너무 오래된 탓이라기보단(그 탓도 없잖아 있습니다만) 최근에 사용하는 엔진 기술과 다른 부분이 아마 많을 거예요.

 

그러다 보니

1. 기존에 사용했던 리소스가 잘 호환되는지 알 수 없다.
2. 요구 사양이 어떻게 바뀔지 알 수 없다.

크게 이 두 가지 문제가 생깁니다. 이 외에도 문제는 아주아주 많겠지만요. 최악의 경우 모든 리소스(이미지, 이펙트, 맵, 모델링)를 새로 작업해야 할 수도 있습니다. 그런데 17년간 축적된 데이터가...? 의장만 해도 nnn개...? 염색.. 조명... 어...?

 

또한 개발 방식에 따라 다르겠지만, 바꾼 엔진에서 기존 코드가 정상 동작하는지도 알기 어렵습니다. 똑같은 소스코드를 써도 언리얼 4.12에서와 언리얼 4.15에서의 동작이 달랐거든요.

아니 저도 왜 그런 건지 모르겠어요 근데 진짜 그렇다니까요 빡쳐진짜 아까 내가 했을 땐 됐다고요 교수님

 

 

하여튼 고려해야 할 사항도 들여야 하는 리소스도 적지 않을 것이라... 어려울 것 같고... 그렇네요.

사람으로 치면 내 몸을 새 걸로 바꾸고 싶으니 인체 연성을 새로 한 다음에 그 인체에 자신의 뇌와 주요 장기를 옮겨서 멀쩡하게 100% 내 몸뚱아리로 움직일 수 있게 해 달라! 와 비슷할 것 같습니다.

 

 

---

 

그냥 이번 일이 영향 범위도 크고 점검도 자주 했던 일이다보니, 부정적인 동향이 많이 보여 좀 안타까워서 써봤어요.

제가 이야기 할 영역이 아니라(막말로 남의 일에 너무 참견하는 모양새가 됩니다) 뭔가 얘기할 내용은 한정적이었지만, 그래서 두루뭉술하게 이야기했지만 여러모로 저였다면 많이 힘들었을 것 같은 사건사고였던지라 안타까움에 이런 글이나마 남겨봅니다.

 

물론 상황이 어렵고 안타까운 것과는 별개로 날아간 아이템이나 유저들에게 불편함을 준 부분은 아무리 예외사항의 연속으로 생긴 일이라 하여도 책임은 져야 하는 부분입니다. 이런 부정 동향을 내버려둬봐야 득이 될 건 없죠. 그리고 솔직히 유저 입장에서는 반복되는 연장 점검과 사라진 아이템 등... 지치고 신경쓰이고 짜증나는 것도 어쩔 수 없는 것 같아요. 상황을 이해하고 말고를 떠나서 어쨌든 그런다고 내 기분이 안 나쁜 건 아니잖아요.

 

단순히 인게임 재화를 잃어버린 유저부터 실제로 현금으로 산 재화를 잃어버린 밀레시안도 있습니다. 공공연히 현금거래가 일어난다고도 하고 경매장가를 현금으로 환산하면 얼마의 가치를 갖는다 같은 이야기도 하지만 이러한 계산은 제외하고 생각해도 유저가 피해를 입었다는 사실은 명백합니다. (게임 내에서 획득 가능한 아이템의 가치를 제외한 이유는 아이템 자체는 법적으론 게임회사의 재산이기 때문입니다. 유저 개인의 소유이지만 유저는 게임회사에서 제공하는 컨텐츠를 사용하는 것이기 때문입니다.)

내가 정당한 돈을 주고 산 아이템(캐시샵 아이템)이 사라졌다는 것은 치명적입니다. 어려운 사안이고 의도가 아닌 예상치 못한 사고였다고 해도 사고를 일으킨 회사 쪽에서 사과를 해야 할 일이 맞습니다. 그러나 이것은 사과를 요구하고 사과를 할 일일 지언정 그들을 폄하하고 거짓된 이야기로 선동하는 행동을 정당화할만한 일은 아닙니다. 저는 사과와 보상을 요구하되 그래도 화이팅이라는 응원의 메세지는 남기고 싶네요. 물론 용서는 해결이 되고나서 할 수 있겠지만요. 용서는 전적으로 피해를 입은 사람의 선택입니다.

 

화를 내지 말자는 이야기가 아닙니다. 화를 내긴 내더라도 이런 백스토리가 있다는 걸 알면 좀더 구체적인 부분에서 화를 낼 수도 있고(?) 어느 정도 셀프안정 정도는 취할 수 있을 것 같아 이야기해보는 것입니다.

 

보상, 보상도 문제가 되고 있습니다. 늦은 공지와 보상 안내... 사실 보상을 지급하는 것도 간단하게 결정내릴 수 없습니다. 보상 상자에 포함할 아이템의 재화 가치를 따져야 하고, 유저들에게 어느 정도의 가치를 갖는 보상을 지급해야 할지 내부에서 끊임없이 회의합니다. 공지를 올릴 때에도 최대한 정확하게, 곡해할 만한 표현이 없을지 검토하고 올려야 합니다. 여러 유관 부서에서 보상 혹은 대처 방안 자체에 대한 검증도 마치고 오케이 사인이 떨어지면 그제서야 공지를 하고 대응을 할 수 있습니다. 의도치 않았다고는 해도 설레발로 인해 유저를 기만하는 모양이 나와서는 안되니까요. 이슈가 확인되는 시점에 비해 공지가 올라오는 시간은 조금 지연되는 느낌이 없잖아 있습니다만, 그래도 많인 심혈을 기울이고 신경쓰고 있다고 생각합니다. 모쪼록 잘 복구되고 해결되었으면 좋겠네요.

 

 

심연에서 올라온 나락을 기어오는 비극은 크롬 바스도 궁극의 글라스 기브넨도 니알라토텝도 아닌 17년 된 엔진 속에 잠든 소스코드였던 모양입니다.

 

그냥저냥 여러모로 화이팅..! 이라는 말 외엔 제가 더 덧붙일 수 있는 말은 없는 것 같습니다.

 

화이팅...