NDC Replay

<마비노기 듀얼> 라이브 서비스 사건사고기록
이승재
넥슨
현재 <마비노기 듀얼> 프로젝트에서 근무하고 있음. 과거 <카바티나 스토리>, <데스크탑 히어로즈>, <마비노기 2: 아레나> 개발에 참여하였음.
마비노기 듀얼에서는 라이브 서비스 중 발생한 사건사고를 자세히 기록하고 공유하는 문화가 정착되어 있습니다. 이 발표에서는 마비노기 듀얼 개발팀에서 사건사고기록을 어떤 형식으로 쓰고 있는지 살펴보고, 마비노기 듀얼 서비스 중 있었던 사건사고 중 프로그래머가 관심있을 만한 것 몇 가지를 추려서 리뷰할 것입니다. 마지막으로 사건사고기록을 왜 쓰고 있는지, 왜 이런 형식으로 쓰고 있는지를 자세히 설명하고, 실패 사례를 공유하는 문화에 대해서 함께 생각해 봅니다.
[새 창에서 슬라이드 보기]
안녕하세요. 이승재입니다. 발표 시작하겠습니다.

이승재고요. 작년 넥슨 공채 모델이었습니다. 프로그래머고요. 마비노기 듀얼에서 1년 8개월째 일을 하고 있습니다. 최근 한 반 년 동안은 코딩보다는 PM 일을 더 많이 했던 것 같고요.

마비노기 듀얼은 그 뒤에는 듀얼에 국한된 얘기가 별로 나오지도 않지만 그래도 설명은 드려야 될 것 같아서, 듀얼을 정통 TCG입니다. Magic the Gathering하고 같은 장르라고 보시면 되는데 드로우가 없어가지고 운이 승패를 가르는 경우가 드물고요. 라이브 서비스 시작한지 10개월쯤 됐고 지지난 주에 PC 버전도 나왔습니다.

오늘 할 이야기인데요. 세상에는 성공한 사례에 대한 이야기가 되게 많습니다. NDC를 보면 이렇게 하니깐 좋았다. 이렇게 하니까 안 좋았다. 이렇게 하니까 실패했다. 이런 얘기보다는 이렇게 해서 크든 작든 성공을 이뤄냈다는 얘기가 훨씬 많죠? 실패한 얘기를 하는 거는 부끄럽습니다. 크게 실패할 수록 더 부끄럽죠. 성공한 얘기를 자랑하고 싶지 저도 실패한 얘기를 남들 앞에 서서 하고 싶진 않습니다. 그런데 저는 실패 사례를 통해서 배울 수 있는 게 훨씬 많다고 생각하고요. 최소한 같은 종류의 실패를 미리 피해 갈 수 있을 테니까요. 오늘은 실패를 공유하는 문화를 팀에 정착시킨 이야기를 해보려고 합니다.

먼저 사건사고기록 형식을 소개하고요. 듀얼 라이브 도중에 있었던 재미있는, 재미있는 사건사고 사례를 몇 개 공유하겠습니다. 그리고 왜 쓰는지 왜 이렇게 쓰는지를 이야기하겠습니다.

저희 팀에서는 사건사고기록이라는 폴더에 문서를 계속 쌓고 있어요. 이 스크린샷은 데스크캣이라는 저희 문서 관리 도구고요. 대략 첫 클베를 시작하기 한 3주쯤 전부터 시작해서 최근까지 한 94건이 쌓여있습니다. 대략 일주일에 하나씩은 꾸준히 쓰고 있는 셈이고요.

사건사고는 러프하게 이렇게 정의를 하고 있습니다. 의도하지 않았던 일이면서 다시 발생하지 않기를 바라는 일. 사건과 사고를 엄밀하게 구분해서 부르고 있지는 않은데요. 사고가 사건보다 조금 더 싫은 나쁜 뉘앙스를 갖고 있기는 합니다.

근데 개발하다가 혹은 서비스에서 사건 사고 즉, 의도하지 않은 나쁜 일이 발생하면 기록을 남깁니다. 특정한 형식에 맞춰서.

그 형식은 이렇게 네 가지 항목으로 구성이 돼 있고요. 사고기록, 원인, 단기 대책, 장기 대책. 이렇게 네 가지 섹션입니다. 제가 썼던 탬플릿 내용을 그대로 가져와서 한 번 그대로 읽어 볼게요. 

1번 사고 기록. 일어난 일을 건조하게 기록한다. 해석을 덧붙이는 경우에는 관측한 내용과 분명히 구분되게 할 것. 사고 기록은 보통 긴급 대응을 마무리하고 나서 작성하기 때문에 기억을 되살려서 쓰기가 쉽지 않은데 작업 기록을 토크에 남겨두면 나중에 편하다. 토크는 저희가 쓰는 업무용 채팅 프로그램이에요. 토크 내용을 복붙해서 편집해도 된다. 

2번 원인. 근본 원인을 추적해서 쓴다. 원인을 모르겠으면 모르겠다고 쓰면 된다.

3, 단기 대책. 이것을 쓰는 시점에서는 이미 단기 대책을 적용했을 것이다. 적용한 대로 쓰면 된다.

4, 장기 대책. 같은 문제가 재발하지 않도록 근본 원인을 해결하기 위한 처방을 쓴다. 장기 대책이 적용되어서 더 이상 기록을 추적할 필요가 없어지면, 작업을 완료 처리하면 된다. 대책만 써놓고 실행 안 하면 안 되니까, 누가 장기 대책 실행을 추적할지를 함께 적는다. 템플릿을 이렇게 왜 구성한 데는 의도가 있어요. 그런데 우선 이 형식대로 작성한 사건사고 사례를 몇 개 보고 그다음에 의도에 대해서 얘기해 보도록 하겠습니다. 사건사고 사례는 좀 크고 무서운 것보다 귀엽고 재밌는 것부터 시작을 해볼게요.

첫 번째는 가장 최근 건데요.

먼저 PC판 출시 일주일 전에 PC판 사운드가 나오지 않는다는 제보를 받았습니다.

그러고 그걸 일단 급해서 묵혀놨다가 잠깐 시간이 나서 “아, 이거 혹시 이 문제 아닐까?”하고 패치 중에 음악이 안 나오는 완전 다른 현상을 해결했어요. 전혀 무관한 다른 현상이었고 제보자님한테 가서 “아, 이거 해결했습니다.”라고 알려드렸는데 그 증상이 아니라고 하시더라고요. 그래서 버그 잡은 건 좋았는데 어쨌든 문제가 해결된 건 아니니까 그 분 자리에 가서 재현을 해봤습니다. 재현을 해봤더니 “아, 이게 원인이구나”라고 파악했고 고치지 않는 걸로 마무리했어요. 

원인은 블루투스 헤드폰 때문인데 제보하신 분 자리로 가서 재현을 다시 하시는 과정을 고대로 봤어요. 일단 클라이언트를 켜시고 클라이언트가 로딩이 되는 도중에 헤드폰을 서랍에서 꺼내가지고 전원을 켜고 쓰시더라고요. 이 시작 표시 쪽 오른쪽에 스피커 아이콘을 우 클릭하면 팝업메뉴가 나오는데 거기서 재생장치를 눌러보면 여기 오른쪽에 나오는 것 같은 그런 그림이 나오거든요. 그런데 스피커로 소리가 나가고 있는 거예요. 오른쪽에 저 바가 보이시죠? 저 바가 꿈틀꿈틀하고 있는, 그런데 스피커 잭에는 거기가 사무실이니까 실제로 스피커가 연결이 안 돼 있었고요. 동영상에서 소리가 나왔던 이유는 동영상은 좀 뒤에 틀기 때문에 동영상 틀 때 NDIVIA SDK가 재생장치를 다시 잡았기 때문인 것 같고 동영상이 틀어질 때는 그때는 이미 블루투스 헤드폰이 켜지고 페어링이 다 돼서 기본 장치가 되어 있던 상태였던 거죠.

단기 대책은 네, 뭐 이거 이거 해주는 윈도우 프로그램 얼마나 되겠냐 싶어서 그냥 고치지 않고 내버려 두기로 했고요. 

장기 대책은 버그 재현할 때 자리에 가서 보면 좋다. 이게 장기 대책 쓸 말이 없어서 이렇게 썼는데요. 곰곰이 생각해보니 되게 좋은 말인 것 같아요. 정말. 버그 재현할 때 자리에 가서 보면 좋다.

그다음 두 번째, 인증 실패로 게임 서버가 장애 난 사례입니다.

12월이네요. 마비노기 서버가 하나둘씩 응답을 안 하기 시작했어요. 점점 죽어가기 시작하고 이제 모니터링 페이지에는 서버의 스레드들이 하나씩 빨간색으로 바뀌어 가고

그런데 1분이 지나서 저희가 메일을 받았어요. 인증 서버가 장애가 났데요. 저희가 할 수 있는 일이 아무것도 없었어요. 인증 서버가 장애 났으니까.

그런데 15분쯤 지나서 인증 서버가 살아났는데 듀얼 서버는 안 살아났어요.

그래서 듀얼 서버를 강제 재시작을 시키고 기다리다가 강제 재시작을 하고

이제 하나씩 하나씩 강제 킬을 하고 다시 띄워서 서비스 정상화가 금방 됐습니다.

원인은 “인증 서버는 왜 죽었을까?”에요.

이런데 다른 인기 게임이 인증서버를 DDos를 때려서 죽여버렸어요.

너무 인기 있는 게임이라

그러면 로그인만 안 돼야지 왜 듀얼 서버 전체가 먹통이 되는가? 그다음에 인증 서버가 살아나면 그 뒤에 듀얼 서버도 알아서 잘 복구가 돼야 되는 거 아닌가? 이런 의문을 당연히 던질 수 있고요.

듀얼 서버에도 문제가 있었어요. 특정한 경우에 설정했던 타임아웃을 무시하고 그냥 무한히 블록 돼있는 걸로 저희가 코드 리뷰를 겁나했는데 이걸 코드를 보고 확진을 하진 못했고요. 그런데 정황을 보면 저런 걸로 보여서 저거를 믿을 수가 없어가지고 

일단 그런 걸로 보고 있고요 단기 대책은 보셨듯이 강제 종료하고 재시작한 거

장기 대책은 또 인증서버가 죽더라도 듀얼 서버가 같이 죽지 않도록 그다음에 인증서버가 죽었다가 살아나면 저희 듀얼 서버도 자연스럽게 살아나도록 인증서버랑 통신하는 코드를 다 갈아엎고 새로 짰습니다. 커맨드 라인 curl을 썼고요. lua socket을 쓰지 않고 별도 스레드에서 별도 프로세스를 호출하는 걸로 재구현 했고 별도 프로세스기 때문에 타임아웃이 걸렸다 하면 curl 내부 구현이 어떻게 돼 있든 프로세스를 죽여버리면 끝이잖아요. 그렇게 안전하게 다시 짰고 그다음에 인증서버의 응답을 기다리는 동안에 스레드가 블록 돼서 점유되어 있지 않도록 코루틴 처리를 전반적으로 적용해서 해결했습니다. 해피하게 정리가 됐죠. 

그다음 사례, 여기부터 좀, 여긴 좀 무서웠어요. 

이건 출시 2주 전이네요. 1주 전인가? 1주 전인 것 같아요. 1.5주? 개발 DB 테이블 변경 중에 특정 컬럼을 PKEY로 설정하는 작업이 있었거든요. 근데 그게 실패했어요. 뭘로 실패했냐면 

Duplicated Value로 실패했는데 이게 절대로 로직 상에 중복된 값이 들어갈 수 없는 곳이기 때문에 완전 멘붕 했어요. 이 ID 발급하는 곳에 버그가 있다라고 하면 이거는 진짜 심각한 문제고 이게 여러 날에 걸쳐서 여러 번에 걸쳐서 안정된 시스템을 만들었다고 생각했는데 이런 데이터가 남아있으니 “이게 도대체 어떻게 된 건가?”하고 코드를 열심히 봤는데 문제는 못 찾았고요. 

그리고 며칠이 지났습니다. 원인을 못 찾은 채로 며칠이 지났어요. 그러면 iOS 검수를 보내놨었는데 검수 전용으로 세팅 해놨던 서버에서 로그인 오류가 발생했습니다. 한 2주쯤 전에 검수를 보내놨었는데 2주 지나서 애플에서 드디어 접속을 하신 거예요. 그런데 로그인을 못하고 튕겼다고 에러 메일이 날아왔어요. 그리고 조금 있다가는 애플에서 “너네 접속 안 돼” 하고 “검수 리젝이야” 하고 메일이 날아오고 에러 내용을 잘 보니까 어제 그전 날에 개발 DB를 업데이트 했거든요. 버전 업을 했는데 그것 때문에 발생하는 걸로 보이는데 iOS 검수용 서버는 자기만의 DB를 사용하고 있는데 왜 그런 건가? 그랬고 얼마 지나지 않아서 원인을 파악하고 문제를 해결을 했고요.

원인은 iOS 검증 서버가 자기 DB에 접속을 안 하고 개발 DB에 접속을 하고 있었어요. 접속할 DB 주소가 일부는 설정 파일에 적혀있고 일부는 DB에 들어가 있는데 iOS 검수용 서버를 새로 설치를 하면서 설정 파일은 갱신을 했는데 DB에 들어가는 걸 까먹고 갱신을 안 한 거예요. 

그러면 왜 ID가 중복될 수 있었나? ID 발급을 두 서버 군에서 독립적으로 받아가지고 하나의 DB에 넣었기 때문에 ID가 중복 발생했던 거고요. 

그다음에 iOS 검수용 서버에서 로그인 처리할 때 에러가 났던 거는 얘가 스키마가 바뀌지 않아야 했던 iOS 검수 DB를 바라보고 있어야 했는데 얘기 스키마가 계속 바뀌는 개발 DB를 바라보고 있었기 때문에 접속을 못 하고 에러가 난 거죠.

단기 대책은 검수 서버 설정 변경하고 재시작 했고요.

장기 대책, 서버 군, 이런 종류의 Configuration 실수가 나도 바로 알 수 있도록 두 가지를 했는데 서버 군 경계를 넘어가서 접속할 수 없도록 망 설정을 변경했고요. 그러니까 iOS 검수 서버에서 개발 서버를 볼 수 없는 거죠. 그리고 모니터링 페이지에서 DB 접속이 어떻게 설정되어 있는지 이런 거를 보여주도록 변경했습니다.

자, 네 번째. PvP 플레이에 지연이 발생한 사례에요.

가을이네요. 일부 사용자가 PvP 플레이가 원활하지 않음을 호소하기 시작했습니다. 이거를 제보하신 분이 저한테 이제 큐를 돌려가지고 사람을 만나면 가끔 가다가 되게 엄청 생각할 타이밍이 아닌데 늦게 수를 두는 경우가 있다. 이런 얘기를 하셨어요. “아니 뭐지? 이 자식 게임 하기 싫은가?” 이거를 후반에 가면 자기가 질 것 같으면 트롤링을 하는 사람이 있긴 하거든요? 그니까 타이머가 다 될 때까지 기다려가지고 마지막까지 상대편을 괴롭히는 그런 게 있는데 시작하자마자 그러는 건 되게 이상하잖아요. 그런 사람이 나타나기 시작했다는 걸 개발팀 중 한 분이 호소를 하셨는데 그때 되게 바빴어요. 

바빠서 2주쯤 지나가지고 재현을 시도했는데 실패했어요. 저게 제가 재현할 때의 기록이고요. 재현하려고 PvP 아레나에 들어가가지고 막 해봤는데 그러다가 3연승하고 와 PvP 아레나에서 3연승한 게 저 때 밖에 없었어요. 그 이전에도 그 이후에도 없고요. 되게 기분 좋았는데 재현이 안 됐고요.

그런데 그거랑 “어쨌든 그럼 코드 리뷰를 해서 보자”하고 서버 코드의 최근 한 달 간 변경 사항을 다 리뷰하고 의심되는 데를 확진이 된 건 아닌데 그래도 수정해서 패치 했으나 변화는 없었고 그러니까 그거를 여전히 보고하는 사람이 있었고 그리고 시간이 좀 더 지나서 되게 뜬끔 없이 개발자들끼리 PvP 대전을 하다가 이게 100% 재현이 된 디바이스를 발견했어요. 정확히 그전에 그 문제를 보고했던 분이 보고했던 거랑 완전 똑같은 문제. 그 원인을 찾아서 그날 해결을 했고요.

이 원인이 뭐였냐면 이게 좀 복잡해요. 듀얼, 마비노기 듀얼 클라이언트는 구조상 최소 3개의 HTTP 요청을 동시에 보내 놓을 수 있어야 되거든요? 롱폴링이라는 걸 쓰기 때문에 그런데 일반 요청 1개를 쓰고 PvP 할 때 한 개를 쓰고 그다음에 일반적인 OT를 받을 때 이렇게 3개를 쓰는데 

앱을 초기화할 때 HTTP 클라이언트를 돌리는 쓰레드풀의 개수를 그 처음 보고가 일어난 전전날에 어떤 분이 이거 작업하신 분이 Runtime.availableProcessors()라는 API를 호출해서 설정을 하셨어요. 

그런데 저게 안드로이드 4.2 미만에서는 실제 코어가 아닌 현재 켜져 있는 코어의 개수를 반환하고 전력 관리 목적으로 OS가 코어를 꺼버릴 수 있고 그러면 충전 중이 아니면 배터리가 얼마 없고 충전 중이 아닐 때는 멀티 코어 기기여도 현재 availableProcessor가 그냥 1로 나와서 쓰레트풀 크기가 1이 됐던 거예요. 이렇게 되면 다른 롱폴링 요청이 기다리고 있는 상태에서는 그게 끝나서 돌아오기 전까지는 내가 뭔가 카드를 놔도 뭘 하든 그게 서버로 전달이 안 되고 계속 큐에 기다리고 있는 거죠. 앞에 롱폴링이 끝나고 나면 그다음 게 전달이 됐던 거고요.

그렇고요. 단기 대책으로는 저기 CPU 개수랑 상관없이 쓰레드풀의 개수를 4 이상으로 보장하게 수정했습니다.

그리고 네, 이거 별로 할 게 없었고요.

이제 여기부터 좀 힘들어지는데요. 정말 정말 힘들었어요. 이 개인적으로 제일 힘들었던 사고고요. 이게 서비스에 미친 영향은 그렇게까지 심각하진 않았던 것 같은데요. 이게 프로젝트에 뒤늦게 제가 합류를 하고 그때 서버가 다 갈아엎고 새로 짜기를 결정하고 되게 스트레스가 심한 상태에서 개발을 계속하다가 출시를 하고 그 주, 첫 주에 일어났던 일이라 위태위태하던 제 멘탈이 이때 완전히 박살이 났어요. 이게 멘탈이라고 표현하는 게 맞는지 모르겠는데 이게 지나고 나서 확고한 Burn out 상태가 되고 그다음에 일주일 정도 어떻게 어떻게 버티다가 도저히 회사를 못 가겠어서 그냥 재충전 휴가를 쓰고 쉬어버렸어요.

자, 아레나에 대해서 먼저 설명을 좀 간단하게 드릴게요. 아레나는 이거 저희 공식 홈페이지에 써있는 건데요. 다섯 가지 등급으로 나뉘어 있고 이제 유저들끼리 대전을 해서 내심 유저들끼리 덱끼리 대전을 해서 승점을 많이 획득할수록 높은 등급으로 올라갈 수 있고 등급이 높을 수록 더 좋은 상품이 지급되는 그런 컨텐츠고요. 저게 등급을 결정하고 승리를 확정해서 보상을 주는 게 3일에 한 번 씩이었어요. 지금은 바뀌었지만. 지금까지의 쌓인 점수에 따라 등급을 확정하고 등급에 따라 보상을 주는 걸 배치 절차로 만들어서 돌렸는데

인제 출시하고 나서 한 번도 그 배치가 안 돌다가 출시하고 나서 처음으로 6월 12일 날 정오에 아레나 보상이 나오게 되는 시점이었어요. 나와야 하는 그런 시점이었는데 

이 전날 이게 금요일이고요. 화요일날 출시를 했던가 그러고 수요일날 당일 뭐가 터지고 다음날 뭐가 터지고 그런데 그 전날 저녁은 되게 안전했어요. 아 드디어 안정화가 됐다. 이제 괜찮다. 뭐 사고 안 터지겠지. 되게 마음을 놓고 있는 상태에서 아레나 보상 처리하는 걸 이렇게 구경을 하고 있었는데 서버가 응답을 안 하는 거예요. 

자, 3분이 지났습니다. 이거 자동으로 살아나지 않는다고 판단을 하고 30분 점검으로 결정을 했습니다. 이게 점검을 설정하는 거 자체를 서버에 명령을 넣어야 되는데 게임 서버가 명령을 받아들이질 않아서 제어판이 뜨질 않으니깐 명령어를 넣을 수가 없잖아요. 그래서 Redis를 까가지고 거기에다가 “너 지금부터 점검이야”라고 설정을 하고요. 

자, 가설을 세웁니다. 가설, Redis 스크립트가 너무 오래 실행되었을 것이다. 이거 조금 있다 좀 더 자세하게 설명을 드릴게요. 가설을 세우고

“Redis 스크립트가 너무 오래 실행되었다”라는 가설을 공격하는 어택하는 태클하는 그런 패치를 만들기 시작했어요. 몇 시간이 걸려서 30분 점검했으니까 38분까지 점검을 해야 되죠? 그때까지 안 끝날 것 같아서 점검을 2시까지 연장하고 2시가 다가오니까 한번 더 3시까지 연장을 합니다. 자 그리고 저 가설을 토대로 패치를 만들어서 

2시 50분에 돌렸어요. 그런데 에러가 나요. 뭐지? 어떡하지? 모르겠고 일단 아레나 기능을 코드로 고쳐가지고 다 끄고 일단 서비스를 살려놨어요. 오픈한지 얼마 안 됐기 때문에 아레나가 그렇게 중요한 컨텐츠가 아니거든요. 게임에서. 스토리하고 미션하고 그러는 게 좀 더 중요하지. 그래서 살려놓고 4시 37분에 편의점 가서 라면을 먹고 왔어요. 이게 12시에 터진 거니까 점심 못 먹은 거예요. 점심도 못 먹고 멘탈 완전 나가가지고 엄청 네거티브한 상태가 돼서는 저런 기록도 남아 있네요.

6시 10분에 타임아웃 문제가 맨 처음 가설을 세웠던 그 문제가 아니었던 걸 확인을 했고요. 

그다음 8시에 그 사이에 버그를 수정하고 데이터, 그 망가져있는 데이터를 어떻게 복원할지를 계획을 수립하고 

그다음에 실행을 해서 아레나 기능이 9시 10분에 정상화가 됐습니다.

원래 세웠던 가설, 원래 세웠던 가설은 이거였어요. 너무 많은 유저의 보상을 Redis 스크립트로 한 번에 처리하려고 시도했는데 Redis는 싱글 스레드고 그러니까 보상을 처리해야 되는, 보상을 처리하기 위해서 Redis 스크립트를 돌리는 백그라운드 스레드가 Redis 인스턴스를 계속 잡고 있고 그런 상태에서 아레나를 건드리려고 시도하는 게임 스레드들이 전부 타임아웃 걸려서 먹통이 되는 게 아닌가? 그 가설이 현상을 정확하게 설명했기 때문에 처음에 보상 지급을 조금씩 나눠서 처리하도록 코드를 고쳤던 거고요. 

그런데 그게 근본 원인이 아니었어요. 그렇게 고쳐도 여전히 에러가 났거든요. 3시에 2시 50분에. 브론즈 티어 보상을 처리하는 코드에 버그가 있었던 게 진짜 문제였어요. 5개 티어 중에 4개 티어는 멀쩡하게 보상 지금을 다 하고 브론즈 티어의 첫 번째 유저를 처리하다가 Redis 스크립트에 에러를 내고 죽어버린 거예요. 그럼 백그라운드 스레드만 죽어야지 왜 게임 스레드까지 죽었을까? 보상 처리를 한 사이클을 다 돌고 다 돌지는 못 하죠. 왜냐하면 브론즈 처리를 못했으니까 최종적으로 스크립트 에러를 내기까지 몇 초의 시간이 걸리는데 이게 Redis 스크립트는 몇 밀리초 단위에서 작업을 보통 끝내야 되는데 몇 초의 시간이 걸린 거예요. 그거를 보상 처리를 다 못 끝내고 죽어버렸으니까 다른 백그라운드 스레드가 다시 진입해서 보상 처리를 시도하고 그렇게 Redis 인스턴스가 계속 부착돼 있었던 거예요. 백그라운드 스레드 바꿔가면서. 얘 5초, 얘 5초, 얘 5초, 얘 5초, 얘 5초 이렇게 계속 잡혀 있었고 그런데 아레나를 건드리려고 시도하지 않는, 그러니까 게임 스레드, 게임 서버 로직을 처리하는 스레드 중에서 아레나를 처리하려고 시도하지 않는 그냥 일반 요청들도 실행이 안 됐던 이유는 게임 스레드들이 다른 요청을 처리하다가도 아레나 관련 요청을 만나면 그냥 타임아웃 맥시멈 날 때가지 기다려야 됐던 거예요. 자, 모든 현상이 명쾌하게 설명이 됐어요. 그죠? 버그 잡았고 서비스 살렸고, 데이터도 고쳐놨고 이제 한 번에 너무 많은 실행을 하는 문제도 해결이 됐어. 이제 박수 치고 끝을 내면 될까요? 

아니에요. 이 버그는 이런 종류의 버그는 내부 테스트에서 잡혔어야 하는 버그에요. 이게 어떻게, 왜? 테스트에서 다 잡히지 않고 라이브까지 따라 나갈 수 있었는지를 찾아나가서 해결해야 되는 거예요.

이게 버그가 왜 생겼는지는 글로벌 CBT가 지나고 나서 보상 관련 규칙을 조금 바꿨거든요. 제가 코딩했던 것 같아요. 이때 버그가 들어갔어요 그런데 이걸 한 번도 테스트해 본 적이 없었어요. 왜냐하면 테스트하기가 어려운 이유가 TO를 결정한 규칙 때문에 그랬는데 참가자 수가 너무 적으면 브론즈 티어에 사람이 안 들어가거든요. 사람이 아무도 없기 때문에 브론즈 티어의 보상을 처리하는 코드가 돌지를 않고 한 번도 실행된 적이 없는데 라이브 서비스 나가서 첫 번째 아레나 보상을 처리할 때 처음으로 브론즈가 생겼고 그 때 테스트 된 적이 없는 코드가 실행이 돼서 쾅 터진 거죠.

단기 대책은 사고기록에서 보신 대로고요. 아레나 기능을 꺼서 서비스를 오픈했고 데이터 망가져 있는 거를 수동으로 수선했고 데이터가 왜 망가져 있었냐 하면 보상 처리를 브론즈는 하나도 안 됐는데 챔피언부터 실버까지는 그게 계속 돌 때마다 보상이 계속 누적돼서 처리가 되고 있었거든요. 그런 거 싹 지우고 그다음에 아레나 보상 성능 문제 잠재적으로 있었던 거 해결하기 위해서 점진적으로 처리하도록 수정하고 그다음에 버그 해결하고요. 

장기 대책은 브론즈 티어에 인위적으로 가상 계정이 들어가서 그 코드가 언제나 테스트가 되도록 그렇게 했어요. 지금 생각하면 좀 다른 방법이 떠오르는데 예를 들어서 참가자 수가 TO 개수 이상만 넘으면 모든 TO에 사람이 한 사람 이상 들어가도록 티어 배정 규칙을 수정했으면 됐을 것 같고요. 그거보다 좀 더 돌아가면 보상 지급하는 거를 백그라운드 스레드에서 배치 프로듀싱하는 게 아니라 그냥 유저가 요청할 때 “보상 주세요.”하고 요청할 때 했어도 됐을 것 같고요. 근데 뭐 이 시점에선 어쩔 수 없이 이게 최선이었던 것 같고요.

마지막입니다. 마지막 사례에요. 돈 복사입니다. 제일 무섭죠? 혹시 저 작년에 듀얼 관련해서 발표했던 분산 트랜잭션 세션 들어오신 분 계세요? 그거 들으셨던 분? 예, 그...보통 제가 업계 처음 들어왔을 때 GEP Study라는 데를 자주 다녔는데 거기서 아이템 복사, 돈 복사가 어떻게 일어나는지 이 패턴을 사람들이 업계 선배님들이죠. 그분들이 얘기하시는 걸 봤는데 복사가 대체로 유저 사이에 재화를 옮기는 데서 발생을 한다고 들었었거든요. 거래를 할 때 발생하거나 드랍 했다가 다시 집을 때 발생하거나 아니면 돈을 줬는데 이쪽에서 로그아웃을 시키고 이쪽에서 로그아웃을 안 시킨 상태로 서버를 터트리면 돈 복사가 된다거나 뭐 이런 사례들을 들어서 알고 있었고 시스템적으로 그런 게 절대로 발생하지 않도록, 로직에서 어떤 실수를 하더라도 뭔가 재화가 뿜뿜뿜뿜 불어나는 일은 절대 일어나지 않도록 분산 트랜잭션을 빡시게 만들었는데 실제로 게임을 만들고 서비스를 해보니까 돈 복사는 그런 거랑 상관없는 데서도 되게 어이없게 터지더라고요. 좀 자세히 풀어볼게요.

하..... 추석 연휴 토요일 밤이에요. 자정이 됐어요. 자정부터 일요일 요일 효과가 적용이 되기 시작합니다. 일요일 요일 효과가 뭐냐 하면 스태미너 소모량이 절반이 되고 부스터 구매 시에 보너스 골드를 주는 거예요. 원래는 조금 줍니다. 아주 조금. 그런데 이때부터 일요일 요일 효과가 적용이 잘 못 돼서 골드 부스터의 가격보다도 더 많은 골드를 돌려주기 시작합니다. 골드 부스터를 사면 살수록 내 돈이 늘어나는 거예요. 내가 1000원짜리를 사면 1300원 이렇게 돌아와요. 광클을 하겠죠 막. 

자, 10분이 지났어요. 운영팀이 문제를 파악하고 개발팀을 깨우기 시작해요. 저는 지금도 신기한 게 듀얼 운영팀이 진짜 대단하세요. 어떻게 뭔가 되게 치명적인 문제가 서비스에 생겼을 때 진짜 빨리 찾아내가지고 저희들한테 알려주시는데 어떻게 아시는지 도무지 모르겠는데 어쨌든 되게 잘 하세요. 

여튼 저는 그때 처갓집에 있었어요. 대전에 가 있었는데 그때 자고 있다가 밤 12시 19분에 실장님 전화를 받고 일어났던 기억이 납니다. 되게 생생하게 그날의 기억이 12시 19분부터 2시 한 반까지 기억이 나는데 골드 부스터를 더 살 수 없도록 일단 점검을 걸었고요. 

그다음에 상점에서 골드 부스터를 못 사도록 골드 부스터랑 골드 회원권을 사는 그런 걸 빼는 서버 패치 긴급하게 하고 서비스를 살려놓고 다시 자러 갔어요. 물론 바로 잠을 들진 못했고요. 아드레날린이 넘치는 상태니까. 그리고 뒤척뒤척하다가 잠은 들었고요. 그다음에 날이 밝았습니다.

추석인데 고향에 안 가시고 집에 남아있던 분들이 모이셨어요. 다행히 이거 복구 작업을 하셔야 되는 서버 프로그래머 분들께서 많이 남아계셔서 할 수 있었던 것 같고요. 버그를 수정하고 그다음에 골드 부스터, 골드 회원권 복원해서 다시 상점에 갖다 놨고요. 그다음에 버그를 심각하게 악용한 사람들을 찾아내서 제재를 했어요. 부정하게 얻은 골드 다 회수하고 회수할 수 없는 사람들은 제재하고 그런데 저는 이때 대전에 있어서 못 갔고요. 이 날 오신 분들 정말 수고 많으셨습니다. 저기 계시네요.

원인은 되게 간단했어요. (A or B) and C 구문에서 괄호가 그냥 없던 거예요 이러면 B and C가 먼저 평가가 되고 그다음에 A랑 or를 하게 되죠. 이게 무슨 코드였냐 하면 이 부스터가, 일요일 요일 효과를 처음 체크하는 코드에서 “이 부스터가 보석을 주고 사는 건가? 골드를 주고 사는 건가?”를 판단하는 부분인데 999 골드 짜리 부스터를 사면서 마치 999 보석인 부스터를 사는 것처럼 계산해서 일요일 요일 효과 보너스를 주고 있었던 거예요. 그러니까 그 골드 부스터의 가격보다 더 많은 돈이 그냥 생산이 되는 거죠. 뿜뿜뿜뿜뿜. 네, 뭐 실수할 수 있습니다. 버그 낼 수 있죠. 프로그래머한테 버그를 내지 말라고 갈구는 게 세상에서 제일 멍청한 짓이고요. 실수를 하니깐 사람인 거잖아요. 진짜 문제는 진짜 문제는 

이 실수가 사람이 할 수 있는 실수가 겹겹이 쌓여있는 안전장치를 뚫고 라이브 서비스까지 나갔다는 거예요.

단기 대책, 네 뭐 아까 보신 대로 고요.

장기 대책을 세웠습니다. 이때 되게 라이브 기간 전체에서 보면 제일 심각했던 문제라서 그때 당시에 사람들이랑 인터뷰를 많이 했고요. 문제를 만들었던 사람, 그 주변에 그 코드를 봤던 사람, 문제를 해결했던 사람이랑 얘기를 다 해서 단서를 잡았고 이제 그 이번에는 사고 기록을 그냥 데스크캣에다가 문서로만 남기지 않고 PT를 만들어서 개발팀 대상으로 얘기를 했어요. 근본 원인, 버그가 라이브 서비스까지 흘러가는 과정을 추적하고 거기서 패턴을 찾았고요. 그 패턴은 A를 추가하면서 B를 건드린다는 패턴, 그다음에 리팩토링하면서 기능을 깨뜨린다는 패턴이었어요. 이 두 가지 패턴을 저희가 가지고 있던 QA 프로세스, 이제 라이브에 내보내는 그 프로세스가 커버하지 못하고 있던 상태였던 거고요. 이제 그런 종류의 같은 유형의 문제가 재발하지 않도록 대책을 세웠어요. 이미 들어있는 안전장치가 이런 케이스까지 다 커버를 하도록 그다음에 버그가, 개발할 때 발생할 수밖에 없는 그 버그가 라이브까지 세어 나가지 않도록.

자동 테스트가 누락되어 있었던 문제는 그 버그를 냈던 사람이 자기가 수정하고 있는 코드에 자동 테스트가 없다는 사실을 알았거든요. 알았지만 보고하지 않았어요. 왜냐하면 그걸 보고하면 자기가 상식적으로 생각할 때 자기가 자동 테스트를 만들어야 될 것 같은 상황이잖아요. 그러니까 보고를 안 해요. 그리고 그래서 이런 규칙을 만들었어요. 수정하는 코드에 자동 테스트가 없으면 당신이 만들 수 있으면 만들고 만들 수 없으면 상황을 팀에 공유할 것.

그리고 리뷰가 제대로 되지 않았거든요. 그래서 이때 “리뷰 내역을 패치 문서에 기록하자. 리뷰를 통과하지 못하면 투입하지 말자.”라는 규칙을 세웠는데 이거는 그렇게 잘 실행되지 않았어요. 스케줄이 빡빡하니까 잘 안 되겠죠?

그리고 QA가 되지 않은 거. 이거는 그 관련한 새로운 기능을 넣을 때는 문제가 안 생겼던 건데 그 뒤에 리팩토링을 하면서 문제가 생겼었던 거거든요. 리팩토링 하는 것도 기능 추가에 준하게 이 변화가 어떤 문제를 잠재적으로 일으킬 수 있는지 어떤 기능들을 동작을 바꿀 수 있는지 그런 거를 패치 문서에 적어가지고 QA 분께 발주하도록 그렇게 규칙을 세웠습니다. 네, 이렇게 정리가 됐고요.

그다음 왜 이렇게 쓰는지입니다.

개선하고 공유하기 위한 거고요.

개선은 같은 유형의 사고가 다시 일어나지 않게 하는 거예요. 당연히 이게 좋은 거죠.

공유는 문제를 내가 혹은 우리가 이걸 해결했고 상황을 통제하고 있는 걸 주변 사람들한테 광고하는 거예요. 주변 사람들이라고 하면 특히 상급자, 특히나 엔지니어가 아닌 상급자하고 스튜디오 내에 다른 분들한테도 포함이 되고요. 저 짤 제가 되게 좋아하는 말인데요. Situation is under control. 진짜 멋있는 말 아닌가요? 정말 저 말 진짜 좋아합니다. 그리고 다른 사람의 경험으로부터 도움을 받는 목적도 있어요. 이게 무슨 소리냐 하면 어떤 한 문제를 한 사람이 혼자서 처음부터 문제를 발견하고 그게 최종적으로 단기 대책, 장기 대책까지 다 세울 수 있는 경우도 많지만 그렇지 못한 경우가 있어요. 이게 뭐 문제를 봤는데 이게 문제라는 건 알겠는데 이게 원인이 뭔지를 잘 모르겠는 상태? 이제 그럴 때 이 포맷에 맞춰서 문서를 작성을 해 놓으면 다른 사람들이 보고 현재 상황과 지금까지 했던 대책들 이런 걸 빠르게 인식할 수 있는 거죠.

왜 이런 포맷으로 쓰는가? 여기에 의도는 문제 해결을 위한 생각의 틀을 제공하는 거예요. 사건사고는 본질적으로 예상하지 못한 일이에요.

그러다 보니까 라이브 서비스 특성상 이제 예상하지 못한 일이 갑자기 툭 튀어나오고 동시에 급하게 해결해야 되는 경우가 많아요. 근데 이거를 되게 허둥대기 쉽고요. 시간이 지나고 나면 그때는 뭐 잘 해결을 했는데 시간 지나고 나면 내가 어떻게 해결했는지도 잘 모르겠고 장기 대책 이런 거는 생각할 틈도 없고 

그래서 이거를 사고 기록, 어떤 일이 일어났는지. 그다음에 원인 분석, 왜 그런 일이 일어났는지. 단기 대책, 대미지 컨트롤하기 위해서 어떤 일을 했는지. 장기 대책, 궁극적으로 이게 재발하지 않기 위해서는 어떻게 해야 되는지를 구분해서 생각하도록 이 형식이 유도하고 있는 거예요.

그 형식 다시 한 번 볼게요. 일어난 일을 건조하게 기록한다. 해석을 덧붙이는 경우에는 관측한 내용과 분명히 구분되게 할 것. 

다른 사람이 기록을 읽을 때 기존의 그 문제를 풀던 사람의 관점이나 해석의 영향을 받지 않도록 하는 거예요.

원인, 근본 원인을 추적해서 쓴다. 원인을 모르겠으면 모르겠다고 쓰면 된다. 

표면적인 원인을 발견하고 거기에서 멈추지 않도록 요구를 하는 거고요. 

“모르겠으면 모르겠다고 써도 된다.”라고 분명히 허락을 해주는 이유는 원인을 찾지 못하는 경우에 “와 원인을 못 찾겠으니까 그냥 사고기록 쓰지 말아야지”하고 넘어가는 게 아니라 원인을 못 찾겠어도 그냥 기록을 남기도록 유도를 하는 거예요.

그다음 단기 대책, 이것을 쓰는 시점에서는 이미 단기 대책을 적용했을 것이다. 적용한 대로 쓰면 된다. 

아까 짧게 말씀드렸듯이 긴급 이슈는 보통 단기 대책이랑 장기 대책이 달라요. 단기 대책은 근본 원인을 해결하기보다는 피해를 최소화하는, 대미지 컨트롤하는데 집중하는 경향이 있고요. 그걸 정말 잘 표현한 움짤이 있어서 제가 가져와 봤습니다.

기차가 오고 있어요. 앞에 침목이 빠져가지고 왜 저렇게 되어있는지는 모르겠는데 일단 저렇게 걸려있죠? 저게 왜 저렇게 걸려있는지를 원인을 파악하는 게 우선일까요? 아니면 빼는 게 우선일까요? 아니면 제자리에 그냥 꽂아놓는 게 우선일까요? 네 이게 정답이죠. 기차가 오기 전에 빨리 빼야 돼요. 그리고 문제가 또 터집니다. 네 어떻게든 대미지 컨트롤을 해야 돼요. 이게 그 라이브 서비스의 특성을 나타낸 되게 좋은 짤이라고 생각하고요.

장기 대책, 같은 문제가 재발하지 않도록 근본 원인을 해결하기 위한 처방을 쓴다. 아까 보신 짤은 단기 대책이 장기 대책이랑 구분돼서 대미지 컨트롤을 어떻게 하느냐가 중요한 걸 설명하는 짤 이었다면 이제 그거랑 별개로 단기 대책도 중요한데 장기 대책을 따로 생각하는 것도 되게 중요해요. 

그 문제가 재발하지 않도록 근본 원인에 대한 대책을 수립하고 실행할 것을 요구하는 게 이 장기 대책 섹션이 따로 있는 이유고요.

자, 사건사고기록을 이렇게 열심히 작성함으로써 얻은 효과, 시간에 따라 사고 건수가 어떻게 변했는지 

이런 건 없어요. 이런 걸 정량적으로 볼 수 있으면 좋겠지만 이게 사건사고기록을 잘 써서 그런 건지 저희가 일을 잘 해서 그런 건지 몰라요. 그냥 모르죠. 변수가 너무 많아요. 그리고 지금 비교할만한 대상도 없어요. 저희 개발팀을 다 클론 해 가지고 사건사고기록을 쓰는 팀이랑 안 쓰는 팀이랑 나눠가지고 실험을 해봤으면 좋겠는데 그건 불가능하죠. 그래서 이런 정량적인 거는 별 의미가 없을 것 같고요. 그냥 정성적으로 제가 라이브 서비스를 하면서 느꼈던 거를 그냥 얘기를 해볼게요.

의도대로 된 거 제가 의도했고 그대로 된 거는 일단 신뢰를 얻었고요. 그다음에 팀은 근본 원인을 찾아서 해결하는 경향을 얻은 것 같고요. 근데 이것도 사실은 잘 모르겠어요. 사실은 이 저희 팀을 구성하고 있는 그분들이 원래 저런 걸 좋아하는 분들이라서 저런 걸 잘하고 있는 건지 사건사고기록을 스크립션을 했기 때문에 그걸 하고 계신지 잘 모르겠는데 어쨌든 저는 이렇게 생각할래요. 그리고 같은 타입의 사고가 다시는 일어나지 않는 경향도 있는 것 같습니다. 네 역시 비교 군은 없고요.

그다음에 의도대로 되지 않은 거는 장기 대책을 세운 그대로 실행이 되는 경우가 그렇게 많지는 않았어요. 실행이 안 되는 경우가 꽤 많았는데 저는 이게 정상적인 상황이라고 봐요. 그냥 대책을 세워 놨지만 라이브 업무의 우선순위에서 밀렸을 것이라고 보고 그럴 경우에는 장기 대책을 실행하는 게 그냥 실제로 중요한 게 아닌 거예요. 그 일이 재발 가능성이 되게 낮거나 세워 놨던 근본 대책이 비용이 되게 비싸거나 이런 등등등의 이유가 있을 것 같고요. 반대로 이런 효과 때문에 이런 상황이 반복될 때 무력감에 빠져서 장기 대책을 작성하는 걸 빼먹지 않도록 조심을 좀 해야 될 것 같긴 합니다.

그리고 의도와 다르게 잘 된 게 있어요. 사고 친 사람을 덜 미워하게 됩니다. 덜 미워하게 돼요. 안 미워하게 되는 것 같진 않고요. 그럴 수가 없잖아요. 왜냐하면 나는 저 사람 때문에 저 사람 때문에 나는 처갓집에 갔다가 밤 12시에 자다가 전화를 받았는데 저 사람이 안 미울 수가 있어요? 그건 불가능하고요. 어쨌든 줄어듭니다. 줄어들어요. 그게 보통 그 사고의 직접적인 표면적인 원인을 만든 사람이 그 기록을 작성하기 때문인데요. 그 기록이 그 기록을 쓰므로 인해서 “내가 이런 행동을 해서 이런 문제가 발생했다는 걸 알고 있다.”라고 하는 메세지를 팀 내에 전파하는 그런 역할을 합니다. 그래서 다른 사람들이 그 문서들을 보면서 사고를 낸 사람을 “아, 그래 저 사람은 자기가 뭘 잘못했는지를 알고 있지.” 그러니까 서로 이해를 더 많이 하게 되고 덜 미워하게 되고 더 신뢰하게 되고 이런 거 같아요. 증거는 없습니다.

보급하는 방법, 이런 제도를 어떻게 도입하면 되는가?

일찍부터 씁니다. 동료들이 이걸 그냥 당연한 것처럼 받아들이도록 일찍부터 쓰고요.

그다음 별것 아닌 것도 그냥 막 써요. 첫 번째 사건사고 기록은 개발서버가 장애였어요. 전혀 쓸 이유가 없었어요. 뭐 이건 되게 특이한 문제였고 이런 문제가 재발할까? 잘 모르겠어요. 그런데 일단 썼어요.

그리고 나부터 쓴다. 이게 뭐 사람들이 왜 사건사고기록을 안 쓰지? 이런 거 고민 안 하고 제가 필요하다고 생각되는 기록들을 막 썼어요. 그랬더니 사람들이 어느새 쓰고 있더라고요. 제가 세어 보니까 처음 열 번째 처음 열 개의 사건사고 기록 중에 절반도 제거고 첫 스무 개의 사건사고기록 중에 절반도 제건데 그 뒤부터는 제가 썼던 거의 비율이 좀 떨어지는 것 같아요.

운영하는 요령, 이거 진짜 중요한데요. 사건사고기록 작성이 벌이 돼서는 안 돼요. 절대로. 절대로 벌이 돼서는 안 돼요.

왜냐하면 벌이 되면 쓰기가 싫어지고 문제를 숨기고 싶어져요. 가리고 싶어져요. 이게 미묘한 지점을 잘 찾아야 돼요. 왜냐하면 그걸 쓰는 개인이 내가 스스로 잘못을 저질러서 벌을 받는 상황이라고 생각하면 안 되는데 왜냐하면 벌이 되면 쓰기가 싫어지니까 문제를 숨기고 싶어지니까 그런데 이제 다른 면을 보면 내가 이런 행동을 해서 이런 문제가 발생했다는 걸 알고 있다는 걸 다른 팀 동료들이 이걸 알아야 되거든요? 그니까 쓰기는 써야 돼요. 그래서 비유하자면 이게 글 씀으로써 속죄하는 역할을 해야 되는데 벌은 아니어야 되는 거예요. 이게 좀 그 중간을 맞추는 게 쉽지가 않을 것 같긴 하고요.

그러기 위해서 “죄송합니다.” 같은 말을 쓰지 않도록 사건사고기록 올라오는 걸 계속 보고 있는데 지금까지는 “죄송합니다.” 이런 말을 쓰는 사람은 없었네요. 자연스럽게 그렇게 됐던 것 같고요.

만약에 저 이거는 저희 팀에서 있었던 일은 아니고 저희 스튜디오에 되게 오래된 옛날 팀에 초창기에 이런 제도를 운용했는데 그 제도가 어떻게 변질되었는지에 대한 얘기를 듣고서 생각을 한 거고요. 이걸 쓰는 게 벌처럼 느끼는 경향이 보이면 리더가 나서서 물타기를 해야 됩니다. 자기가 나서서 되게 사소한 것들로 이제 사건사고 사례를 막 써서 이게 내가 벌을 받는 상황이 아니라 그냥 우리 모두를 위해서 이걸 하는 게 더 좋은 거고 옳은 일이고 그런 물타기를 하면 좋습니다. 

그리고 사건사고 기록 그 문서가 담고 있는 뉘앙스가 “아이고, 잘못했습니다. 죄송합니다. 다시는 그러지 않겠습니다.” 그런 게 아니라 “사고가 일어났지만 이렇게 해결했지.”하고 자랑하는 뉘앙스를 담는 편이 훨씬 낫다고 생각합니다.

자 이제 끝이고요. 

사건사고기록은 조그마한 실패 사례들의 모음집이라고 생각하고요.

그걸 서로 간에 공유하는 문화를 에너지를 크게 들이지 않고 아까 말씀드렸었죠? 제가 뭐 “좀 써라” 이렇게 얘기를 드리지 않고 “아이고 왜 사람들이 쓰지 않지?” 이렇게 고민하지도 않고 그냥 제가 필요하다고 생각되는 문서를 씀으로써 만드는데 성공했고요. 이제 이런 것처럼 실패 사례를 이렇게 저희한테 작은 실패 사례를 공유하는 문화를 작은 조직에 적용한 사례를 얘기했는데 이런 걸 더 크게 키워서 실패 사례를 공유하는 문화가 정착이 되었으면 좋겠습니다. 실패한 좀 크게 터진 프로젝트에 대해서 NDC 같은데 나와서 “우리는 이래서 망했죠.”하고 공유하는 문화가 쉽지는 않겠지만 정착이 되었으면 좋겠고요. 그걸로 인해서 우리들이 똑같은 실수를 계속하는 그런 지옥에서는 좀 벗어났으면 좋겠습니다.

이상입니다. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
