NDC Replay

<던전 앤 파이터> 클라이언트 로딩 속도 최적화
하재승
네오플
현재 7년차 개발자로 네오플 던파에서 최적화 및 기능 개선 등의 업무를 담당하고 있다. NCSOFT에서 각종 라이브러리와 도구들을 만들었으며 (2011년 NDC 서버 버너 발표) 그 이전에는 빅샷과 메틴2의 개발에 참여하였다.
<던전 앤 파이터>의 로딩 속도를 개선하기 위해 적용한 여러 방법들에 대해 소개합니다. 프로파일링을 통한 일반적인 속도 개선과 함께, (다른 게임에도 응용할 수 있는) 분할 압축 기법과 시리얼라이즈 비용이 큰 자료구조를 최적화하기 위한 dumpable 라이브러리를 이용하여 기반 시스템의 성능을 극적으로 개선하는 과정을 소개합니다.
[새 창에서 슬라이드 보기]
안녕하세요. 저는 이번에 던전앤파이터에 적용한 클라이언트 로딩 최적화를 발표하게 된 하재승이라고 합니다. 간략하게 저에 대해서 소개를 드리자면 이전에 메틴2와 빅샷 개발 참여했었고, NC 소프트에서는 게임보다는 툴과 라이브러리 쪽에 개발에서 2012년에 서버 스트레스 테스트를 관련하여 발표를 진행하였습니다. 현재는 네오플에서 던전앤파이터 최적화와 코드 개선 등을 담당하고 있습니다. 먼저 이번에 발표할 내용에 대해서 간략히 소개를 드리자면 이번 5월 15일과 그 이전에 종종 패치 된 던파에 들어간 최적화 패치에서 사용되었던 아이디어랑 그때 얻었던 경험에 대해서 공유하는 시간을 가지도록 하겠습니다. 그 외에 일반적인 최적화에 관련된 지식들은 이전에 2008년에 송창규님의 “최적화와 프로파일링”이나 2013년 김이선님의 “사례를 통해 살펴보는 프로파일링과 최적화” 등에서 최적화의 일반적인 개념들은 더 자세히 배울 수 있을 거라 생각합니다. 그래서 저는 이번에 던파에서 제일 중요하다고 생각하는 것인 유저가 편하게 게임을 즐길 수 있는 그런 게임 플레이를 만드는 과정을 달성하기 위해서 노력을 했었습니다. 하지만 현실은 이제 던파가 현재 오픈 된지 8년차이고요. 그래서 8년간의 라이브 개발을 통해서 흔히 얘기 되는 깨진 창문. 이런 것도 셀 수 없이 많고, 이전에 유저들이 이야기 하는 통통배 위에 항공모함을 올렸다. 아니면 이제 저 같은 경우는 제가 들어가서 입사 이후에 받은 느낌은 보통 처음 개발하다 보면 기술부채 얘기를 하잖아요? 그런데 기술 부채가 너무 지나쳐서 이제는 기술 파산의 레벨까지 간 게 아니냐? 그런데 이제 그 상황 위에서 계속 적으로 유저들을 만족 시키기 위해서 잦은 업데이트가 이루어지고 있는 상황입니다. 그래서 다른 트위터에서 어떤 한 유저의 글을 잠깐 인용해봤는데, 모든 인력을 쏟아 부어도 안 될 거고 새로 짜는 것밖에 방법이 없지 않느냐? 이런 식의 유저들이 이미 그렇게 인식하고 있는 상황이었고요. 이제 수치를 가지고 와서 상황을 얘기해보자면 이지미랑 사운드를 제외한 데이터 파일이 54만개가 있고요. 이게 용량이 300MB를 먹고 있었습니다. 그리고 이미지가 한 장, 한 장 개수를 셋을 때 1000만개 이상의 이미지가 존재를 하고 있습니다. 그리고 실제로 게임을 플레이 해보면 버벅이는 경우도 많이 생기고 조금 했다 하면 그냥 윈도우로 튕겨나가거나 크래쉬하는 경우가 많이 있었습니다. 그런데 이런 버벅이는 이유 중에 제일 큰 것 중에 하나가 데이터가 무엇이 언제 필요한지 몰라서 하드에서 매번 필요한 거를 하나하나 읽어보다 보니까 지속적으로 끊기고 튕기는 이런 게 자주 생겼고, 그래서 SSD를 사는 게 너무 당연하다. 나온지는 오래 됐지만 최신 컴퓨터 아니면 플레이할 수 없다. 이런 얘기들이 나오곤 했었습니다. 그리고 심지어 메모리 사용량이 2G가 넘어서 메모리 사용량 때문에 프로그램이 죽는 경우가 발생했었습니다. 그래서 이런 문제점을 해결하기 위해서 입사 이후에 TD님과 같이 얘기를 하면서 하드를 사용하니까 렉을 최소화해서 게임을 좀더 즐길 수 있는 상황을 만든 다음에 메모리 사용량도 줄이고, 이런 크래쉬 문제도 해결하고 그 외에도 다양한 코드가 오랜 기간 쌓이면서 복잡하게 된 것들을 해결해서 문제점을 좀 해결해 나가자. 이런 로드맵을 잡았었습니다. 하지만 역시 이번 발표에서는 그 중에 이거 밖에 안 했고요. 그래서 하드 사용할 때도 게임을 좀 빠르게 해보자. 랑 그 외에 잡다한 몇 가지들을 더 적용한 것들을 소개하고자 합니다. 그래서 최적화 전과 후에 대해서 비교를 동영상으로 보여드리려고 했는데 뭔가 문제가 발생해서 동영상이 플레이가 안 되요. 그래서 유튜브로 불쌍하게… 처음에 공지사항으로 올라갔던 동영상이고요. 처음에 게임을 뜰 때는 말도 안되게 느렸어요. 왼쪽이 최적화 전이고요. 최적화 이후에 로딩이 끝난 다음에 로딩이 시작되는 느낌이 들고요. 그래서 지금이게 47초가 19초로 감소를 했거든요? 그래서 이게 나눠보면 대충 2.5배라서 처음에 페이지 소개할 때 부제로 3배 빨라졌다고 거짓말을 쳤는데, 2.5배 빨라진 거에요. 로딩만. 그리고 하나가 스킬 렉 개선한 게 있는데, 동영상을 보시면 뭔가 이상한 게 있는데, 이걸 처음 보신 분 중에 한 분이 얘기를 한 게 이게 유튜브가 렉이 걸린 게 아닌가? 그게 아니거든요? 캐릭이 나와서 스킬을 쓰는데… 유튜브 렉이 아니에요. 이게. 이게 이렇게 바뀌었어요. 이게 1G의 XP머신. 이런 상황이었고요. 저렇게 뭔가 멋있는 스킬이었어요. 사실은. 그래서 이런 최적화를 진행했고요. 그러니까 최적화를 하지 않으면 안될 상황이었어요. 그런데 최적화의 결과가 일반적인 다른 게임 플레이하는 레벨이라는 문제가 좀 있었는데. 그래서 이 과정에서 대충 리스트를 뽑아보자면 대충 이런 최적화를 적용했습니다. 그래서 위에 세 개랑 밑에 한 줄 띄어놨는데, 위에 세 개는 다른 게임의 경우에도 적용할 수 있을 것 같아서 다른 사람들이 적용할 수 있는 것들에 대한 소개를 좀 했고, 밑에 것들은 간단하거나 여기서 사소한 실수 때문에 느려지고 있던 문제점들을 해결한 것들에 대한 리스트입니다. 그래서 이 순서대로 소개해드리도록 하겠습니다. 그래서 데이터 분할 압축을 소개하도록 할 거고, 데이터는 아까 말한 54만개 파일의 데이터가 있는데, 이것들을 그냥 말 그대로 쪼개서 압축을 하자. 그런 얘기에요 .그래서 사실 찾아보니까 2006년, 7년에도 다들 비슷하게 생각을 하던 거였는데, 던파에는 이게 적용이 되어 있지 않아서 이미지랑 사운드를 제외한 데이터 파일이 600MB 이상 있었고요. 여기서 재미있는 점은 제가 처음 입사했을 때 이 파일이 44만개였는데, 그게 1년만에 10만개가 늘었어요. 그래서 내용 자체는 XMBL과 비슷하게 텍스트 파일로 되어 있는데 태깅이 되어 있는. 그래서 뭐가 시작이 있고, 끝 태그가 있고. 이게 파일이 54만개가 되니까 파일 이름만 모아도 30MB가 되요. 그래서 이거를 XMBL 형태로 저장하면 용량이 크니까 태그 별로 숫자를 달아서 바이너리 XMBL 형태로 저장을 해서 각각 파일을 저장하는 정도로만 해서 300MB를 차지하고 있었고요. 사실 300MB 차지한다고 해서 별 문제가 되지는 않는데, 이 상태를 그대로 Memory Mapped file을 이용하고 있었어요. Memory Mapped file 같은 경우는 일반적으로 대용량 파일을 전체적인 내용을 읽으려고 하면 카피가 줄어들기 때문에 읽는 속도가 빨라지게 되는데, 이 경우에서는 파일이 54만개잖아요? 그래서 그 전체를 다 읽는 경우가 생기는 게 아니라 그 중에서 일부분을 조금씩 읽는 경우가 생기고, 그런 300MB가 메모리 공간을 차지하고 있게 되는 상황이 된 거에요. 그래서 2GB 전체에 대해서 300MB를 먹어버리면 사실상 쓸 수 있는 메모리가 굉장히 많이 줄어들 게 되고, 그리고 XP SP2 이전 버전에서 중간에 마치 와우의 대격변처럼 저 레벨 던전을 리뉴얼 한 일이 있었는데, 그 때 대규모로 패치를 하면서 이 파일의 용량이 커졌는데, 이 XP2 이전에서는 특정 크기 이상의 memory mapped file을 생성할 수 없는 문제가 있어서 그것 때문에 게임이 아예 실행이 안 되는 문제가 있었습니다. 그래서 이 수정된 내용을 그때 급하게 적용했던 일이 있었고요. 그 다음에 memory mapped file 사용한다고 해서 실제로 아무 지점에 랜덤하게 읽는 속도가 빨라지는 건 아니기 때문에 어느 시점에서 하드를 읽어 들이게 되면 결국 거기서 또 다 아까 봤던 하드 렉이 발생하게 되는 원인이 되었습니다. 그런데 이 642MB짜리 파일을 하나로 합친 다음에 ZIP이나 이런 거에 집어넣으면 22MB 밖에 안 되는 거였습니다. 그래서 뭔가 압축을 하면 좋을 것이다. 라는 결론을 얻었는데 무식하게 전체를 다 압축하게 되면 중간 데이터를 읽기 위해서 다 풀어야 되기 때문에 쪼개서 압축을 해보자는 생각을 가졌습니다. 일단을 얼마나 용량이 줄어드는지. 분할을 해서 하면 용량이 오히려 늘어나는 문제도 발생할 수 있으니까 그걸 확인해볼 필요가 있었고요. 그래서 이를 위해서 파이썬으로 간단하게 코드를 짜서 지금 네 줄 정도 있는데, 그 파일을 하나로 압축하지 않고 하나의 파일로 만든 다음에 블록 사이즈를 정해서, 지금 64kb로 정했고, 그래서 이걸 for 문을 돌면서 64kb씩 블록을 잘라가면서 압축을 한 거의 길이를 합해보았습니다. 그래서 테스트를 여러 가지 해봤는데, 64kb가 한 블록을 푸는 속도와 전체 용량의 트레이드 오프를 재봤을 때 제일 적절한 수준이었고, 용량이 커지면 압축을 푸는 시간이 길어지기 때문에 하나의 로딩이 길어지게 되고, 크기가 작으면 압축 효율이 떨어지게 됩니다. 그래서 실제로 이런 아이디어를 활용해서 데이터를 모아서 압축을 해보았고, 이제 확장자 별로 sort를 해서 비슷한 종류의 파일들을 같이 모았더니 용량이 20mb 더 줄었습니다. 그래서 35mb 정도가 전체 642mb의 데이터를 포함하는데 필요했고, 이 내용 전체를 아예 처음 기동 시점에서 메모리에 다 올리고 시작하고 필요한 부분을 풀어서 쓰는 식으로 구현했습니다. 그리고 54만개 파일 이름을 저장하는 것도 30mb 공간의 낭비가 있으니까 이 경우를 파일 위치 폴더와 파일 이름을 쪼개서 저장했더니 폴더 부분에 겹치는 부분이 많이 있어서 용량이 약 12mb 정도로 줄어들었습니다. 그리고 패치를 위해서 변경된 사항만 추가로 패킹하는 기능도 추가하였습니다. 이렇게 했더니 게임 입장 후에 사용하는 메모리 양이 약 100mb 이상 감소했고, 이렇게 바꾸더라도 어차피 데이터는 중간중간 읽었었기 때문에 처음에 뜨는 시간에서는 크게 영향을 받지 않았었습니다. 그리고 패치 용량도 300mb 파일에서 50mb, 60mb 정도 파일 사이즈로 줄었기 때문에 패치 용량도 크게 감소했고, 압축 해제하는 경우가, 아까 제가 테스트했던 xp 1G 머신에서도 64KB 블록인데 0.5ms 정도 이해가 들어서 사실상 이거는 ssd 급의 데이터 읽는 속도를 만들어낼 수 있었습니다. 실제로 하드 렉을 없게 만든 것에 가까웠고요. 그 다음에는 Dumpable 이라고 라이브러리를 하나 소개해드리도록 할 텐데, 혹시 C++ 이해를 하시는 분 손 좀 잠깐 들어주실래요? 감사합니다. 어떻게든 될 거에요. 그래서 던파 내에서 애니메이션 파일이 굉장히 많은 양을 차지하고 있는데, 이 애니메이션이 엄청난 건 아니고 2D 게임이니까 프레임 별 어떤 이미지고 어떤 순서로 나온다. 이런 거를 저장하고 있는 파일이 있습니다. 이게 아까 말한 54만개 파일의 50%를 차지하고 있고요. 그래서 화면에 출현하는 마을에 나무가 서있다든지, 스킬 사용하는 이펙트나, 그냥 옷이나 이런 점도 다 애니메이션으로 표현됩니다. 그런데 캐릭 하나가 결국 이런 것들로 이루어진 거다 보니까 캐릭 하나 로딩하려면 2000개 이상 생성이 되는 그런 문제가 있었습니다. 그리고 마을에서나 던전 입구에서 캐릭이 많이 모여있을 때 거기서 입장했을 때도 역시 렉이 걸리는 문제가 있어서 이걸 해결하고자 했었고, 그 때도 이런 애니메이션 객체가 굉장히 많이 생성되니까 이 부분을 빠르게 하면 속도가 빨라지지 않을까? 그런 생각을 하였습니다. 그래서 로딩을 제일 간단하게 생각하면 그냥 메모리 복사만 한 다음에 로딩 끝났다. 하면 제일 쉽잖아요? 그래서 예를 들어 int나 float나 이런 값들은 사실상 메모리 상에서 읽은 상태에서 주소만 가지고 있느면 다 똑 같은 값이 되는데, 그래서 그런 걸로 이루어진 struct 라든지, 그런 거 상관없는데 std::string이나 std::vector 같은 게 있는 경우는 결국 heap 상에 다시 string의 데이터가 들어가고, heap 상에 vector의 데이터가 들어가기 때문에 메모리 복사 만으로 값을 가져오기에 한계가 있습니다. 그래서 이런 거를 복사하는 게 있으면 좋지 않을까? 라는 아이디어가 있어서 뭔가 구현을 해봤고요. 혹시나 C++에 익숙하지 않은 분들을 위해서 간단히 설명을 하자면 JSON 같은 경우로 데이터를 통신용으로 많이 사용하는데, 그런 경우에서 실제로 JSON은 string 데이터고 어떤 규약에 대해서 정의된 방식이니까 이게 하드에 저장되어 있거나 네트워크로 받아오게 될 거고, 이걸 파이썬에서 사용하게 된 뒤에는 json.loads 같은 함수를 이용해서 디트나 리스트로 변환하게 되고, 거기서 우리가 쓰려면 내부 클래스로 뭔가 값을 넣어준다거나 이런 작업을 거치게 됩니다. 그런데 어떤 저장을 할 때에 이미 뭔가를 고려해서 저장해서 데이터를 한번 받아온 다음에 그냥 바로 .title만 써도 그 내용을 바로 읽을 수 있다. 하면 속도나 이런 점에서 향상을 얻을 수 있을 것입니다. 그래서 memcpy 이후에고 값이 재대로 들어가 있어야 되니까 중간에 아까 말한 string이나 vector는 여전히 있어야 되는데 그러면 어떻게 되지? 라고 생각하면 포인터형 데이터가 상대주소로서 뭔가 값을 표현해야 된다는 거를 알 수 있고요. 그 다음에 거기서 할당된 그런 값들을 역시나 전체 메모리 영역에서 가지고 있어야 된다는 것을 알 수 있습니다. 그리고 추가로 C++ 같은 경우의 단점 중에 하나가 reflection이라는 기능이 없어서 어떤 struct가 있을 때, 여기에 어떤 원소들이 포함되어 있는 지를 알 수 있는 방법이 존재하지 않습니다. 예를 들어 boost에 있는 시리얼라이즈를 사용하는 경우에도 이런 시리얼라이즈 함수를 정의해서 멤버 함수를 직접 하나하나 적어 줘야 하는 문제가 있었 고요. 그래서 일반적인 경우에서는 정의 파일을 따로 만들고, 그런 정의파일을 통해서 어떻게 읽고 어떻게 쓰는 지를 생성하게 됩니다. 예를 들어 프로토콜 버퍼 같은 거를 사용하는 경우도 정의 파일을 만든 다음에 C++용 읽기 쓰기 루틴과 파이썬용 읽기 루틴. 이렇게 여러 가지가 생성 돼서 쓰기도 하고요. 그런데 이왕이면 이런 작업도 없고 코드 생성도 없이 그냥 바로 쓸 수 있는 것이 나오면 좋겠다는 개인적인 요구사항도 있었습니다. 그래서 물건은 나왔고요. 오픈소스로 개발했기 때문에 github에 들어가 보시면 코드를 볼 수 있을 거에요. 그래서 일반적으로 우리가 struct로 만들었다고 치면 여기서 학생이 있고 교실이 있어서 학생은 이런 점수가 있고, 이런 식으로 간단한 걸 예로 들기 위해서 만들어 봤는데, 원래 일반적으로 wstring과 string과 vector를 사용하는 대신에 앞에 dumpable의 d를 붙여서 dwstring과 dstring, dvector 등의 타입을 사용하고 있습니다. 그래서 채워 넣는 것도 똑같이 일반적인 std string이나 std vector 썼던 것처럼 class_name과 students.emplace_back은 push back과 거의 똑같은데 객체를 생성하면서 넣는 함수고요. 그래서 1001이라고 class_name을 넣었고 Alice가 2점이고, Bob이 5점이고, 옆에 이거는 한글테스트하려고 한글이라고 쓴 건데… 어쨌든 그렇고요. 그렇게 데이터를 채워 넣은 다음에 stringstream에다가 dumpable::write를 호출해 주면 이 내용을 하나의 메모리 영역으로 만들어 준 것을 ostringstream에다가 적어주게 됩니다. 그래서 이 값을 하드에 저장한다거나 네트워크에 전송해서 사용할 수 있게 합니다. buffer라는 것을 받았다고 치면 이 값을 위에 건 무시하시고 그냥 아예 casting만 해도 C++에서는 바로 사용할 수 있습니다. casting만 한다는 거는 사실상 그 안에서 연산이 아무것도 일어나지 않는다는 거잖아요? 그래서 읽기 연산의 시간이 0이 됩니다. 0으로 데이터를 사용할 수 있습니다. 그래서 장점은 시리얼라이즈 코드 없이 사용할 수 있고요. Memcpy로 struct 말고 dumpable::wirte에서 나온 string buffer 전체를 복사하기만 하면 전체를 다 사용할 수 있고, Header-only library라서 따로 설정이나 이런 귀찮은 게 줄어들고요. 그 다음에 런타임을 사용하는 변수라던지 이런 경우는 제외하는 기능도 같이 가지고 있습니다. 그래서 구현에 대한 소개를 잠깐 하자면 내부에 상대 주소를 저장하는 거를 구현하기 위해서 dptr<T>라는 타입을 만들었고, 여기서 상대 주소를 저장한 다음에 shared pointer처럼 operator*이나 overloading에서 일반적인 포인터처럼 사용될 수 있게 구현되어 있습니다. 그리고 string과 vector가 이 포인터와 길이 또는 포인터 개수. 이런 식으로 정보를 저장하고 있습니다. 그래서 실제로 값이 써지게 되면 classroom이라는 변수가 있다고 치면 여기서 classroom에는 처음에 class_name이 dstring으로 존재하게 되는데 그러면 dstring은 class_name을 맨 처음에 저장하게 되고 그 class_name은 아까 예제에서 길이가 4인 string이었으니까 길이 4와 dptr 하나가 저장이 되는데 여기서 이게 classroom 다음 메모리 준 걸 가리키게 되고요. 거기서 값이 1001이라고 들어가게 됩니다. 그 다음에 student에 dvector가 있으니까, vector에서는 아까 원소 개수가 3개였으니까, 원소 개수 3개와 student의 vector 시작 위치를 가리키는 dtpr이 존재하게 됩니다. 그래서 read는 그냥 casting과 똑같기 때문에 write의 구현을 잠깐 소개를 하자면 아까 말한 그런 변수 dstring이나 dvector를 위한 메모리 할당을 위해서 pool이 존재하게 되고요. 그 다음에 이 pool과 변수를 통해서 데이터를 복사하는 과정이 있습니다. 그리고 pool에 있는 데이터와 실제 로컬 변수의 값을 합쳐서 string을 출력하는 것으로 write를 구현하게 됩니다. 코드는 이렇게 생겼는데요. 이거 중요한 거 다 지우면 pool에 설정하고, x는 데이터에서 값을 넣어주고, stream에 쓰는 과정이 일어나게 됩니다. 그래서 아까 말한 로컬변수와 pool을 이용해서 데이터를 복사한다는 것이 데이터가 생긴 것을 생각해보면 안에 string도 있고, vector안에 wstring있고. 어떤 재기적인 구조가 등장하게 되는데 이 코드 전체가 등호 하나로 그게 구현이 끝나게 되고요. 이 오퍼레이터 등호에서 현재 pool이 존재하는 경우에서는 pool에서 메모리를 할당하고, dptr이 할당된 가리키게 설정하고 다시 메모리 영역에서 대입 연산을 사용함으로써 내용을 복사를 해서 재기적으로 일어나게 만들어져 있습니다. 그래서 쓸 때는 메모리가 여기 저기서 할당하고, 포인터 주소를 얻어오고 이런 과정이기 때문에 쓰기 비용이 다른 일반적인 것보다 복사하는 비용이 좀더 크게 되지만 대신에 읽는 과정은 메모리 읽어온 다음에는 추가적인 연산이 필요 없게 되고요. 게임 구조체가 아무리 복잡하더라도 일단 한번 달성된 다음에는 바로 사용할 수 있게 됩니다. 그 다음에는 messagequeue에서 메시지를 전달하거나 이런 경우에도 메시지 복사를 그냥 memcpy를 통해서 바로 복제할 수 있기 때문에 장점이 있습니다. 던파에 적용함에 있어서는 그렇게 큰 효과를 못 봤는데요. 그래서 내부적으로 보안을 위해서 값을 rapping해서 사용하는 이런 게 있어서 그것들을 없앰으로 인해서 보안 문제가 있을 수 있는 문제도 있었고요. 그 다음에 적용한 다음에 성능 향상이 저사양 컴퓨터에서 약 1초 정도의 성능밖에 없어서 이 정도면 굳이 적용해서 사람들 헷갈리게 하는 것보다는 그냥 기존 코드는 놔두는 게 나을 것 같다는 판단을 했었습니다. 그래서 이유를 분석하자니까 원래 로딩 자체가 그렇게 많지 않았고, 오히려 데이터 자체의 개수가 많아서 느린 이유가 컸다고 생각이 되었습니다. 그래서 던파에서는 다른 부분에 활용할 예정이고 혹시나 C++ 쪽에 관심이 있으시면 한번 살펴보시는 일도 괜찮을 것 같습니다. 그리고 아까 보셨던 실질적인 스킬을 사용할 때의 렉을 줄이기 위한 미리 읽기 리스트를 만드는 거에 대한 소개를 하도록 하겠습니다. 던전 들어가서 스킬을 처음 사용하면 하드에서 관련된 이미지를 읽어오는데 시간이 엄청 걸려서 렉이 걸리게 되었습니다. 이게 어느 이미지를 언제 읽는 지를 모르는 게 제일 큰 문제였는데요. 그나마 다행인 게 이미지 말고 데이터 파일들 같은 경우는 이미 최적화에서 데이터 분할 압축을 하면서 꽤 빠른 속도로 읽어올 수 있게 되기 때문에 그 경우는 크게 문제 되지 않았습니다. 그래서 이미지만 해결하면 게임에서 렉이 없어질 것이다. 라는 기대를 가지고 있었습니다. 약간 이거에 대해서 핑계를 대자면 던파의 게임의 스킬이 생각보다 다양한 점들이 있는데, 여귀검사 캐릭터의 직업 중에 소드마스터라는 직업이 있는데 얘는 검을 속성강화를 할 수 있어요. 그러면 그 강화된 속성에 따라서 다른 스킬이 나갈 때 다른 색상의 스킬 이펙트가 날아가게 됩니다. 그래서 빛 속성으로 강화하는 경우에는 이런 노란색 이펙트가 나오고 어둠 속성으로 강화하면 이런 보라색으로 똑 같은 스킬인데 색상이 바뀌게 됩니다. 그리고 이 경우는 마도학자라는 캐릭인데, 플로레컬라이드 라는 스킬을 사용하면 테슬라콜 같은 건물을 소환해서 여기서 번개가 나와서 몬스터를 공격합니다. 이 정도면 평범한 스킬 같은데 이 상황에서 캐릭터가 옆에 있는 다람쥐 챗바퀴 같은 데 탑승한 다음에 공격 버튼을 누르면 번개가 더 빨리 쳐요. 그 다음에 유저들이 렉이 걸린다고 노래를 불렀던 스킬 중에 하나는 동영상으로 설명하도록 하겠습니다. 스킬 이름이 헬 마치인데, 사람들이 렉 마치라고 부르더라고요. 얘들이 나와서 뭔가 할 것 같은데 터져요 그냥. 그런데 이게 캐릭이 많이 나오는 것도 있고 여기서 사용하는 그림들이 여러 가지가 있어서 렉이 심하게 걸렸다고 애기를 했었습니다. 그래서 아까 보셔서 알겠지만 탑승해서 뭔가를 소환한다거나 아니면 그런 직업별 다양한 종류가 있는데, 그런 독특한 플레이스타일을 위해서 C++ 코드 상에서 하드 코딩으로 이루어진 코드가 꽤 많이 있었고요. 그 다음에 스크립트로 구현했다가 C++로 옮긴다든지 여러 가지 8년간의 역사적 흐름에 의해서 코드로만 남아있는 경우가 많이 있었습니다. 그리고 캐릭마다 구현하는 방식이 서로 다르게 구현되어 있었고 여러 가지 예외 사항이 많이 있었습니다. 그래서 어느 데이터를 언제 읽을 지 알 수 없으니까 기존에는 그냥 한 번 읽었으면 데이터를 아예 버리지 않는 방식으로 구현되어 있었습니다. 왜냐면 한번 읽었는데 이걸 다 버려버리면 매번 쓸 때마다 아까 처음 봤던 그런 렉이 생기는 거에요. 그래서 일단은 버리지 않는데, 이제 읽은 다음에 뭘 버려야 할지 알 수 없는 상황이었고요. 그래서 처음에 렉이 발생하고 게임을 계속 켜둔 상태에서는 메모리 부족 문제가 발생하는 그런 두 가지의 문제를 같이 가지고 있었고요. 그래서 이런 거를 해결하기 위해서 일단 리스트를 뽑아야겠다. 그런 생각을 해서 처음에는 소스 파일을 분석해서, C++를 분석해서 어떻게든 해보자. 일단은 데이터를 100%는 못하더라도 반 이상만 뽑아도 렉이 꽤 줄지 않을까? 이런 생각으로 시도를 해보았습니다. 그래서 스킬 이름으로 if문 있는 경우에 그 안에서 아까 애니메이션 파일은 확장자가 .ani 확장자를 가졌었는데, 여기서 파일 이름 나오거나 이런 거 같은 경우는 내부 문제로 다 수정된 이름이고요. 어쨌든 이런 식의 파일을 읽는 게 나오면 이 스킬에서는 이런 파일을 읽는다. 이런 거를 뽑아낼 수 있었고요. 그런데 이제 당연한 얘기지만 애니메이션을 읽는 함수도 여러 개가 있고, if문 안에서 함수를 호출하는데 그 함수가 다시 어떤 파일을 읽는다든지 아니면 다른 캐릭터의 이미지를 공유한다든가 그런 일로 인해서 같은 코드인데 이게 여러 스킬이 연결된다든지 이런 일들이 있어서 코드 분석하는데 문제점들이 있었습니다. 어쨌든 적당히 휴리스틱을 섞어서 한번 리스트를 뽑아봤는데 그 뽑은 리스트를 미리 읽은 다음에 게임을 플레이 해봤을 때 여전히 렉이 발생해서 이 방식으로는 한계가 있다는 결론을 내리고 만약 한다고 쳐도 AST 이용해서 분석한다면 좀 나아지지 않을까? 라는 생각을 하지만 적당히 버리고 다른 방식으로 넘어갔습니다. 그래서 유저가 실제로 게임을 플레이하면서 스킬을 사용한 것과 이미지를 읽은 것과 이런 거를 이용해서 데이터를 뽑아서 사용하는 것들을 생각해 보았고요. 그래서 게임을 플레이하는 와중에 이미지를 읽는데 이게 하드로부터 읽어 들이는 과정이 있으면 해당 이미지를 처음 읽을 때 던전과 읽은 이미지와 뭘 읽었는지 이런 것들을 같이 기록하게 하고 저 스킬을 사용했을 때 직업과 스킬 번호를 같이 기록을 남기게 했었습니다. 그래서 데이터를 테스트 서버에서 1주일 치를 모아봤는데, csv파일로 전달받았던 게 15GB였고요. 그래서 이미지를 읽은 게 7800만 건이 있었고 유저가 스킬을 140만건 이상 사용했었습니다. 그나마 다행이었던 게 모든 스킬이 포함되어 있어서 이걸 가지고 데이터를 뽑아도 충분하겠다는 결론을 냈었고, 만약 이게 불충분했었다면 본섭에 집어넣어서 여기 숫자가 아마 몇 억 이렇게 시작을 했겠죠. 그렇게 해서 사실 어떻게 뽑을까 고민을 했는데 별로 뾰족한 수가 떠오르지 않았거든요. 그래서 각 스킬을 사용한 시점은 알고 있으니까 그 시점으로부터 이미지를 각각 읽은 게 일정 시간 이내에 나온 게 여러 종류가 있을 텐데 그걸 20초 정도 모아서 잘랐어요. 그리고 거기서 나온 것들의 이미지 별로 스킬 사용한 시간을 기준으로 해서 이미지를 언제 읽었는지에 대한 시간의 평균과 분산을 구해봤습니다. 그래서 스킬 사용한 기준으로 1초에도 읽고, 2초에도 읽고, 3초에도 읽고, 4초에도 읽고 이런 이미지면 사실 스킬과 그다지 연관이 없는 이미지일 가능성이 높은 거고 반대로 관련이 있다면 거의 항상 일정한 시간에. 0.7초, 0.7초, 0.7초. 이렇게 읽지 않을까라는 기대가 있어서 분산이 일정한 값보다 작으면 이거는 스킬과 연관이 있는 데이터일 것이다. 이런 가정을 했었습니다. 추가로 2D 게임이다 보니까 옷들을 입힐 수 있잖아요? 옷을 입히면 이게 조각조각 나있게 되는데, 그 중에 머리 부분에 대한 거의 애니메이션이라든지, 몸 부분이라든지, 얼굴 부분이든지 이런 거 같은 게 나눠져 있는데 그 중에 뽑는 방식이다 보니까 이 중에 일부만 뽑히는 경우가 있어서 이것들을 같이 합치는 과정을 거쳤고요. 그리고 남아있는 데이터 중에서도 스킬에서 뽑히지 않았지만 아까 사용한 던전 인덱스도 모았기 때문에 어떤 던전에서 어떤 이미지를 읽더라도 같은 데이터를 같이 포함해서 이 세 가지 과정을 거친 다음에는 실질적으로 렉이 없는 아까와 같은 플레이를 할 수 있었습니다. 그걸 정리한 이미지고요. 당연히 뭔가 좋은 방법은 아니었던 게 던파라는 게임이 아까 처음 잠깐 보셔서 알겠지만 한 맵을 깨고 다음 맵으로 이동하는 작업을 반복하게 되는데, 이런 방식의 맵이다 보니까 A 맵에서 스킬을 사용한 다음에 B 맵으로 이동을 하고 다시 A 맵으로 돌아오는 경우에 이전에 사용했던 스킬의 애니메이션이 아직 플레이 중이라서 끝까지 이어서 플레이가 되더라고요. 그래서 어떤 스킬이 앞 부분은 3초 이내에 플레이가 되는데 뒷부분은 10초 있다가 플레이 된다거나 이런 일이 발생했었습니다. 그래서 일단은 자르던 최대 시간을 일정 시간 이하로 주어서 일단 어느 정도 비율은 줄였지만 여전히 남아있는 문제고요. 그 다음에 저 사양 컴퓨터에서 플레이하는 경우는 데이터가 심하게 왜곡되는 경우가 있었는데, 예를 들어 GrabBlastBlood.ani 라는 파일은 총 수집된 데이터가 322건이 있었는데, 여기서 95%가 0~1초 사이었는데 나머지 14개 데이터가 5초와 10초 사이에 분포하고 있었습니다. 그래서 평균은 0.7초가 나오는데 표준 편차는 2.59초가 나와서 제가 사용하는 heuristic으로는 관련 없는 데이터라고 분석을 하지만 실제로는 연관이 있는 데이터였습니다. 반대로 관련 없는데도 같은 데이터 나오는 경우도 있었고요. 그래서 이거를 어떻게 해결할 방법이 있을까? 라는 고민을 좀 해봤지만 아직 특별히 좋은 방법을 찾지는 못했습니다. 그리고 데이터 출력 자체가 랜덤한 경우가 있는데, 예를 들어 어떤 캐릭터 같은 경우는 포격 지원형 스킬이 있어서 평타로 공격하는 경우에 랜덤한 확률로 거기에 추가로 뭔가 이펙트가 나오면서 광역으로 데이지가 들어간다. 같은 스킬이 있어요. 그러면 아까 처음에 했던 가정에서 아예 벗어나있기 때문에 데이터를 뽑을 수가 없어서 이 경우는 손으로 노가다를 해서 뽑거나 아니면 많지 않을 거라고 가정하고 무시하는 식으로 작업을 했었습니다. 이제 이렇게 뽑은 데이터가 있으면 이제 새로 패치하면서 데이터가 추가가 되거나 그런 경우가 발생하게 되는데 그런 경우를 업데이트 하기 위한 전략을 고민했어야 됐고요. 현재 이 내용 자체가 5월 15일에 패치 되었기 때문에 실제로 아직은 업데이트가 한번도 이루어지지 않아서 아이디어만 정리했습니다. 그래서 1차적으로 데이터를 뽑는 방식이니까 누락된 파일이 있을 수 있는데 이런 경우는 합쳐야 되니까 기존에 있는 데이터에 새로 뽑은 데이터로부터 합치는 식으로 전략을 정했고, 그런데 예외적인 케이스가 던전에서 이벤트나 이런 걸로 인해서 일시적으로 데이터가 생겼다가 사라지는 이런 일들이 생길 수 있습니다. 그래서 그런 경우에 지금 이 방식의 파일을 읽은 걸 기준으로 해서 추가하는 시스템이다 보니까 한번 리스트에 넣어 버리면 읽든 읽지 않든 무조건 더 이상 로그에 나타나지 않게 되는 거라서 어떤 파일이 더 이상 읽지 않게 되는지 확인할 수 있는 방법이 존재하지 않았습니다. 그래서 매번 패치 때 마다 랜덤하게 일정 개수 이하의 파일들을 제거하는 식으로 하면 그 파일들은 분명히 읽게 되겠지만 많은 수가 아니니까 렉은 걸리지 않을 거고 만약 계속 사용하는 거면 다시 수집이 될 거고, 계속 사용하지 않는다면 제거가 될 테니까 이런 식으로 해결할 수 있지 않을까? 하면서 결론을 내렸습니다. 그래서 이 작업을 한 다음에는 결과적으로 처음에 던전 입장할 때 미리 읽기 리스트를 다 읽어야 했기 때문에 던전에 입장하는 시간은 증가했지만 게임 중에서 하는 렉이 감소했고요. 그런데 메모리 사용량이 생각보다 꽤 크게 증가해서 일단은 솔플에만 적용하고 있어서 아직 유저들은 재대로 파티플에도 빨리 해달라 같은 반응을 보이고 있습니다. 그리고 그 외에 잡다구레 한 것들을 소개하겠습니다. 던파에서 아까 이미지 데이터가 4GB 이상 있었는데 이미지가 1000만개 있는 게 당연히 파일 하나 존재하지 않고요. 그거를 묶어서 이미지 팩이라고 8만개 정도로 존재하고 있습니다. 그런데 8만개조차도 패치하고 이러기에는 너무 개수가 많으니까 이걸 2000개 정도로 다시 묶어서, 이름이 애매해서 이미지 팩팩이라고 부른다고 치면, 이 이미지 팩팩을 유저들에게 배포를 하고 있었습니다. 그런데 보통은 패킹을 하면 속도가 빨라지는 그런 경우가 많은데, 이 이미지 팩팩을 사용하는 경우 오히려 반대로 시간이 늘어나서 대체 왜그런가 분석을 해봤더니 처음 게임이 실행될 때 이미지 팩팩이 총 4기가쯤 되는 파일을 하나하나 열어보면서 거기서 어느 이미지 팩이 어느 위치에 있는 지를 하나하나 확인하고 있었습니다. 이 경우는 하드디스크를 읽는 시간이라서 유저 시간을 주로 참고하던 프로파일링에서도 잡히지 않아서 약간 디버깅하는데 어려움이 있었었는데, 이 경우는 파일 하나 만들어서 결과를 그냥 한 파일로 저장하게 했더니 파일을 2000개 읽던 거를 파일 하나로 읽는 걸로 바뀌어서 그냥 이것 만으로 처음 뜰 때 아까 봤던 시간의 대부분이 줄어들었습니다. 그리고 프로파일링을 좀 해봤는데 슬프게도 사람들이 기존에도 최적화작업을 해왔었기 때문에 말도 안되게 느린 경우는 존재하지 않았고 그냥 std::map을 boost::unordered_map으로 바꾸는 간단한 정도의 변화만 했었습니다. 참고로 하나 말씀 드리자면 visual studio2010의 경우는 내부 구현의 약간 안 좋은 점이 있어서 boost::unordered_map보다 visual studio의 unordered_map이 약 10배 정도 느릴 수도 있는 경우가 있어서 boost 있는 버전을 사용하는 게 좋습니다. 그 다음에 intel TBB thread building brog에 있는 scaleable_malloc을 적용했더니 이것 만으로도 속도가 10% 정도 개선이 됐었고요. 그 다음에 이거는 거의 버그에 가까운데, 던파나 일반적으로 서비스 된 게임들은 메모리 해킹을 방지하기 위해서 내부적으로 primitive type, int나 이런 것들 접근할 때 래핑하는 클래스도 하나 두게 되는데, 여기서 잘못 메모리 해킹 툴을 이용해서 값을 고치거나 같은 경우에 대한 로그를 남기게 됩니다. 그런데 아마도 실수인 것 같은데 재대로 된 접근인 경우에도 그와 관련된 로그를 남기는 기능이 켜져 있어서 그냥 이 기능을 빼기만 했는데도 약 20% 정도의 속도 향상이 있었습니다. 아까 봤듯이 패치도 계속 되고 이러니까 언제 어떤 실수가 있는 지를 알기가 굉장히 어렵고요. 그래서 중간에 던전에서 어떤 유저의 캐릭터를 복제해서 그 캐릭터의 스킬을 복사한 몬스터가 있는데 몬스터가 그 캐릭을 복제하는 시점에 약 2초 정도 렉이 걸리는 그런 문제가 있었는데 이 문제도 약 0. 수준으로 해결이 됐고요. 아까 중간에 dumpable 얘기할 때 나왔던 애니메이션 로딩이 느렸던 문제도 사실 이 문제였던 거였습니다. 그래서 5월 15일 관련 내용들이 패치가 됐고요. 그래서 유저 반응은 대충 이런데. 좋았다 와 나빴다가 섞여있는데 요약을 하자면 저사양 컴퓨터는 당연히 게임이, 아까 처음 동영상 보셔서 알겠지만 왼쪽 동영상이 원래 내 컴퓨터 보는 것 같아서 눈물이 났다는 유저도 있었고요. 그래서 빨라져서 좋다는 유저가 대부분인데, 반대로 고사양쪽에서 이미 SSD를 쓰다거나 이런 경우에는 사실상 오히려 로딩만 느려지고 아무 변화가 없었기 때문에 그렇게 좋지 않은 반응이 많이 있었습니다. 그리고 제일 큰 문제 중에 하나가 아까 이미지 전체 파일 2000개에 다한 어떤 새깅 파일을 만들었다고 했는데 던파가 게임이 오래되다 보니까 유저들이 인터페이스나 이런 거 같은 거를 수정해서 자체적인 이미지를 막 집어넣고 그렇게 사용하는 경우가 많이 있었습니다. 그런데 이런 거 같은 경우는 던파의 이미지를 고쳐서 사용하는 거다 보니까 실제 새깅 데이터는 고쳐지지 않는 데이터 기준이다 보니까 데이터가 서로 깨져서 메뉴가 안 나오고 인터페이스가 안 나오고, 게임 보는데 캐릭이 붕붕 떠있고. 이런 거 같은 일들이 생겼었습니다. 그런데 다행이 유저들이 6시간만에 뭔가 해법을 찾아내더라고요. 그래서 어떻게든 쓰고는 있던데 아마 내적으로 어떻게 액션을 취하지 않을까 싶습니다. 그리고 저는 분명히 솔로 플레잉를 할 때 개선되었고, 메모리 사용량은 오히려 늘 수도 있고… 이런 식의 내용을 소개를 했는데 유저들은 ‘왜 최적화했는데 더 튕기죠?’ ‘왜 파티플레이 하는데 렉이 더 걸리죠?’ 같은 식의 반응을 보여서 가슴이 아팠고요. 그리고 슬픈 얘기는 이거 패치하는 시점에 던전앤파이터 밸런스 패치가 같이 진행이 돼서 아무도 최적화에 관심이 없더라고요. 그래서 일단은 스킬 사용시 읽어야 할 데이터를 이제 알게 된 상태니까 던전 종료 시에 이것들을 버릴 수도 있게 된 거고, 그리고 마을에서 플레이 할 때 메모리를 왜 많이 먹나 같은 거의 문제도 분석을 하고 어느 정도 결과를 내서 아마 이 과정이 적용되면 유저가 많은 서버 같은 경우에 던전 플레이 할 때의 메모리 사용량이 약 500MB 이상 정도의 여유를 낼 수 있을 것 같습니다. 그래서 이런 식의 메모리 사용량을 최적화한 다음에 아까 얘기했던 파티 플레이 때의 로딩도 같이 적용을 하고, 그 다음에 이제 유저들이 맨날 팅기는 게 당연시 되는 던파가 좀더 게임 같은 게임이 되지 않을까? 라는 생각을 하고 있습니다. 여기까지가 제 발표입니다. Q&A 진행을 할 거고요.
“C++ 11에서 vector가 move semantics을 이용하는데 memcpy를 이용하지 않고 이걸 적용하는 건 어떨까요?”
라고 하셨는데, move semantics을 하더라도 결국 변수를 읽어오려면 move 과정이 발생하잖아요? 그러면 값에서 포인터라고 해도 값의 이동이 생기게 되고 재기적으로 복잡한 자료구조 같은 경우는, 예를 들어 아까 애니메이션 같은 경우에는 안에 키프레임이 들어 있고, 키프레임 안에는 다시 이미지에 대한 링크가 들어있고, 값들이 숫자도 막 들어있고 이렇게 되잖아요? 그러면 그런 값들이 move semantics이 적용 된다고 하더라도 실제로 옮겨야 될 양이 많이 존재하게 됩니다. 물론 move semantics 때문에 굉장히 성능이 개선된 건 맞지만 아무리 그래도 안 하는 것보다는 느릴 수 밖에 없거든요. 그래서 그런 장점이 있을 수 있고요.
“최적화 과정에서 코드는 더 산으로 갈 수도 있을 거라 예상되는데 실제로는 어떻습니까?”
다행이 산으로 가지는 않은 게, 왜냐면 제가 아까 처음에 얘기했던 게 기술 부채를 넘어서서 기술 파산으로 가고 있다고 했잖아요? 그래서 다행히… 그리고 사실 최적화 했다는 게 아까 얘기했던 것 중에 생략됐지만 한 거 보면 TBB malloc 이런 거 하고 있고, 프로파일링 했더니 맵을 unordered 맵으로 고치고 이런 게 대부분이고, 위에 것들은 사실상 새로 추가된 거지 흑마법을 부려서 코드를 꼬아서 빠르게 만들고 이런 게 아니라서 산으로 가지는 않았습니다.’
“dumpable 쓰면서 캐스팅 실수 하거나 해서 죽으면 난감할 거 같은데 디버깅은 어찌하셨나요?”
C++이 항상 그렇잖아요? 저는 보통 이렇게 표현하는데, C를 쓰면 자기 발등을 도끼로 찍는 게 많다. 이런 느낌이라고 치면 C++은 익숙하지 않은 상황에서 쓰면 산탄총을 자기 발에 들이대고 연사하는 느낌이잖아요? 결국 그런 거는 versioning 이나 이런 거 같은 기능이 현재 dumpable에 없는 상태인데, 그거를 지금 구현 상 넣을 수도 없을 것 같고 그래서 결국 안전한 방식을 원하는 거 같은 경우는 protobuf나 이런 좀더 웰메이드된 형태를 사용하는 게 맞고. 그러니까 C++의 장점은 위험한 대신에 너가 이걸 다 고려해서 쓴다면 더 안전하게 할 수 있다 에 가까운 거라고 생각합니다.
“2D 스프라이트 로딩 및 렌더링 최적화는 어떻게 진행하였는지 궁금합니다. 만약 캐릭터마다 다른 이미지 파일을 사용하고 있는데 마을에 100명이 한 화면에 모여있을 경우는?”
안 했습니다. 던파가 2D 이미지를 많이 그리는 게 사실 그렇게 문제가 되지 않은 게 요새 3D 그래픽 카드 성능 보면 말도 안되잖아요? 그래서 렌더링에서 뭔가 부하가 생기거나 이러지는 않는 것 같고, 캐릭이 많이 있으면 로딩이 느린 문제가 있는데 솔직히 여전히 느리고요. 그런데 일단 기본적으로 던파가 취하고 있는 전략은 맵에 로딩해야 될 시점이 있다. 예를 들어 던전 입구 같은 경우는 사람들이 많이 모여있게 되는데 그걸 해결하기 위해서 던전 입구의 맵을 두 개로 분산한다든지. 이런 경우로 해결하는 경우를 기본적으로 취하고 있는 것 같고요.
“다른 강연에서 한 프로그래머 분이 ‘하드 코딩은 미래를 팔아서 현재를 사는 일종의 돌려막기’ 라는 표현을 하였습니다. 지금 던파는 어느 정도 돌려막은 상태인가요?”
망했어요… 미래가 없어… 이거는 개인적인 생각이니까 중요하지 않고요. 하지만 그래도 계속 컨텐츠 추가되고 있거든요? 예를 들어 지금 3월에 남거너 2차 각성이 추가됐고, 4월에 드래곤 던전이 추가되고, 5월에 레이드 던전이 추가될 예정인 것 같고. 그래서 계속 컨텐츠 추가도 이루어지고 있고… 열심히 하고 있습니다.
스프라이트 압축은 적용할 예정은 있고요. 지금 상태로서는 데이터 자체를 압축한 정도로만 사용하고 있습니다. 그게 데이터 파일 같은 게 서비스가 오래 되다 보니까 중국에 진출했잖아요? 중국은 열성적인 유저가 많아서 이미 이미지 파일 포맷이 다 까져있는 레벨이라서 그냥 파일을 고르면 이미지를 열어서 이걸 편집하면 자동으로 저장해주는 툴이 이미 만들어져 있어요. 그래서 화면을 고쳐서 유저들이 스킬 이미지가 마음에 안 든다고 해서 아예 자기가 전용으로 이미지를 만들어서 스킬 이미지를 통짜로 다 바꾼 그런 거를 배포한다든지. 예를 들어 총에다가 어떤 버프를 거는 게 있는데 이걸 블리치에 나오는 새로 이미지를 합성해서 멋있게 만든다든지, 이런 일을 하고 있어서 간단한 수준밖에 안 되고 있습니다.
“최적화 하면서 생긴 버그는 없었나요? 있었다면 어떻게 해결했나요?”
훌륭한 프로그램으로 해결했습니다. 가 맞는 말일 것 같고요. 어디에 로켓펀치 인터뷰 보신 분은 아시겠지만 그냥 훌륭한 프로그램이 있으면 버그가 안나요.
“플레이하다 보면 시간이 지나면서 메모리 사용량이 계속 증가하는데, 이유랑 해결 방법은 생각하고 계시는 게 있나요?”
아까 얘기를 잠깐 했었는데, 실제로 메모리 추적 툴을 자체적으로 만든 것도 있고 여러 가지 적용해서 확인을 해보고 있는데, 이전에 여러 좋은 발표를 해주신 송창규 TD님께서 만들어주신 메모리 추적 툴 같은 것도 있고요. 그런 거를 이용해서 해봤는데 사실상 리깅이 있는 상태는 아니더라고요. 단지 뭔가 메모리를 들고 있는데 빨리 해제되지 않은 문제 같은 게 있어서 그런 걸 좀 해결해보자 하고 있고요. 그래서 아마 몇 달 안에 유저들이 이게 던파야? 라고 말하는 그런 결과가 나오지 않을 까라는 생각을 하고 있습니다.
“과거 CD 패키지 게임에 있었던 thick 최소화 기법으로도 로딩 속도를 많이 올릴 수 있을 것 같은데 어떻게 생각하세요?” 
죄송한데 CD 패키지에서 쓰던 thick 최소화 기법이 뭐죠? 그러니까 같이 사용 될 데이터를 모아서 속도를 빠르게 하자. 같은 식의 아이디어인 것 같은데, 실제로 WOW 같은 경우는 mpq 파일을 큰 패치 있을 때마다 매번 새로 정리하는 게 그런 관련 데이터를 모아서 하기 위해서 한다. 같은 얘기도 있고요. 그런데 아까 발표 내용 보셨으면 알겠지만 지금 어느 이미지를 언제 읽는지도 모르는 레벨이라서 아마 힘들 것 같고요. 실제로 하더라도 이게 데이터가 다른 던전에서 재활용 되거나 이런 데이터가 생각보다 꽤 많이 있어서… 던파가 이제 한계가 있잖아요? 데이터를 계속 찍어내는 게 한계가 있으니까 이런 데이터가 여기서 재활용 되고 이런 경우가 많이 있어서 어느 정도 한계는 있을 것 같은데… 적용한다면 좋을 것 같지만 제가 짜기가 귀찮아서 안 할 것 같아요.
“마이크로 소프트에서 STL 병렬화 프로젝트를 진행 중입니다. 차후에 최적화를 위해서 도입할 생각이 있으신가요?”
보통 병렬화나 이런 거 같은 게 할 수만 있다면 좋은데 항상 문제가 온라인 게임 서비스 같은 거 할 경우에 저사양 유저랑 고사양 유저가 같이 있다는 문제가 있는데, 어떤 패치는 저사양 유저를 위해서 했더니 고사양 유저가 로딩시간 느려진다고 싫어하고요. 고사양을 위해서 패치를 했더니 저사양은 적용이 안 되는 정도면 괜찮은데 저사양이 오히려 성능이 떨어지거나 이럴 수 있는데. 일단 사용할 수 있는 툴이면 적용해보고 양쪽에서 다 테스트해본 다음에 아마 진행하게 되지 않을까 싶습니다. 
“졸라 천제가 아니어도 최적화를 할 수 있나요?”
사실 게임을 만드는 팀에는 결국 처음 개발하는 과정에서부터 약간은 고려를 하지 않으면 나중에 결국 이것도 느리고 저것도 느리고 그것도 느리고. 같은 상황이 발생해요. 그런데 결국 투자한 시간 만큼의 뭔가 결과를 내는 것 중에 하나 이지 않을까 싶고요. 이제 하드웨어 구조나 이런 걸 자세히 알아야만 할 수 있는 그런 최적화 같은 경우는 제한이 있지 않을까 싶습니다. 그래서 누구나 할 수 있어요. 파이팅.
“이제 곧 던파도 레이드를 도입한다고 하는데 파티플에도 적용이 빨리 되어야 하는 상황이 아닌가 싶은데 지금은 솔로만 적용되는 것 같네요. 어느 시점부터 적용할 수 있을 것 같나요?”
기능을 빨리 넣을 수 있는데 이게 넣어서 메모리 문제가 해결이 안 되면 던전입장 하다가 죽는 거에요. 그러면 솔직히 욕 나오잖아요? 유저 입장에서는. 그래서 메모리 테스트를 좀더 빡세게 해봐야 되지 않을까? 같은 생각을 하고 있고요. 일정은 제가 정하는 게 아니라서… 물건은 아직 나오진 않았고요. 물건 자체는 아마 하면 1~2주 안에 나오긴 하겠죠. 파티플레이 관련된 거는.
“스킬 데이터가 하드코딩 되어 있으면 그걸 먼저 데이터로 빼는 게 앞으로를 위해서 좋지 않을까요?”
모두가 좋다고 생각하지만 그걸 하려면 코드가 몇 백 개 정도의 C++ 파일이 사라지게 되겠죠. 그거를 할 수 있는 사람이 있으면 아마 좋겠는데… 그걸 사람이 하기에 한계가 있을 것 같아서 불가능할 것 같습니다.
“전체 유저 로그 기반의 데이터를 실시간으로 개인 유저의 통계 값을 기준으로 비교하면 어떨까요? 개인별 스타일에 맞춰서 자주 쌓이는 리소스를 개인 별로 읽지 않을까요?”
아까 중간에 발표하는 과정에서 말은 하지 않았지만 사실 스킬트리가 테크트리 형태로 돼서 A를 찍어야 B를 찍을 수 있는 경우는 A를 찍어놓고 사용하지 않는 경우가 있는데, 이런 경우는 고려해야 할 필요는 있다고 생각하고 있고요. 그런데 일단은 지금 그것보다 더 큰 문제를 해결하자 쪽에 가까워서 당장은 신경 쓰고 있지 않습니다. 그런 방식을 적용하면 좀더 도움이 될 거라고 생각하고 있습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
