사실 게임 프로그래머 리더십에 대한 이야기

고주영과 최적화 3

이제 아저씨의 세 번째 말을 들을 차례다.

“아저씨 아까 하실 말이 세 가지라고 하지 않으셨나요? 첫째는 성능 측정 시 프레임 당 소비 시간을 기준으로 측정하라는 것이고, 두 번째는 최적화하려면 프로파일 하라는 것이었고, 세 번째는 뭔가요??”

“허허허 진수 씨 보채지 마세요. 고기 안 먹고 계속 말만 시키니까 고기가 타잖아요.”

나는 열심히 고기를 뒤집었다. 그리고 다 익은 고기는 불판 위에 상추를 깔고 그 위로 옮겼다. 그리고 고기도 열심히 먹었다.

“아~ 이제 배가 좀 부르네요. 아까 저희라고 하는 것 보니까 최적화를 누군가랑 같이하는 것 같던데 맞나요?”

“네. 고주영 님이라고 옆팀에서 온 사람 있어요. 그 사람이랑 둘이서 해요.”

“고주영 님은 몇 년 차에요?”

“이제 1년 된 신입이에요.”

“허허허 진수 씨 첫 부사수인가요?”

“딱히 사수 부사수 관계는 아니지만···”

“진수 씨랑 수습 때 같이 청소하던 게 엊그제 같은데, 세월 참 빠르네요.”

“흐흐··· 그렇네요.”

“제가 할 세 번째 말은, 그 고주영이란 친구랑 잘 지내라는 거에요. 싸워서 이기려 들지 말고요. 말싸움에서 이기는 건 아무 의미가 없어요.”

“네? 저 주영 님이랑 친해요.”

“허허허 그렇네요. 진수 씨는 요즘 사람 답지 않게 순수하게 사람을 좋아할 줄 아니까... 제가 괜한 걱정을 했네요.”

다음 날 출근하자마자 주영 님을 불렀다.

“주영 님. 우리 완전 바보였어요.”

“저도요? 저는 바보 아닌데···”

“그냥 말이 그렇다는거에요. 아무튼 우리가 해야 할 것은 최적화 작업이 아니라 프로파일이었어요!”

“프로파일요? 들어보긴 했어요.”

프로파일이란, 우리가 만든 프로그램의 어느 코드가 실행될 때 CPU나 메모리, 하드디스크 등 어떤 자원을 얼마나 많이 쓰고 있는지 측정해보는 것을 말한다.

즉, 프로그램의 성능을 분석하는 것이다.

우리는 윤희티 게임 엔진의 프로파일 방법에 대해서 검색해보고 연구했다. 프로파일을 하려면 개발자용 빌드를 만들어서 스마트폰에 설치해야 한다. 그래야 프로파일 데이터를 볼 수 있다.

개발자용 빌드는 여러 개발에 필요한 정보가 추가로 들어가기 때문에 설치 파일의 용량도 크고 실행 속도도 느리다고 한다.

또한, 이 개발자용 빌드를 구분하기 위해 개발자용 빌드로 설치를 하게 되면 화면 하단에 development build라는 워터마크가 생긴다고 한다.

“어라? 저 워터마크 몇 번 봤는데···”

나는 주영 님의 핸드폰에 설치된 우리 게임을 실행시켜봤다.

그곳에는 작지만, 선명하게 development build라고 적혀있었다.

“헐···설마···?”

나는 사내 테스트를 했던 게임 설치 파일을 다운받아 다시 설치해봤다.

이번에도 역시 development build 워터마크가 보였다.

“주영 님··· 우리 바보인가 봐요.”

“왜요? 저는 바보 아닌데···”

“이거 보세요. 우리 개발자용 빌드로 사내 테스트를 했나 봐요. 그러니까 당연히 느리지!”

나는 주영 님에게 설치된 게임 화면 속에 있는 development build 워터마크를 보여줬다.

“엥? 이게 뭐죠?”

“뭐긴요? 개발자용 빌드라는 증거죠··· 개발자가 이런저런 게임 정보를 수집하기 위한 빌드요. 개발자용 빌드가 유저용 빌드보다 30~50% 정도 더 느리거든요.”

“진짜네요. 그럼 개발자용 빌드 옵션 끄고 성능 테스트 다시 해볼까요?”

우리는 개발자용 옵션을 끄고 릴리즈 빌드 즉, 개발자용이 아닌 유저용 빌드로 설치 파일을 다시 만들었다.

그리고 fps를 확인했다.

캐릭터가 숨만 쉬고 가만히 있는 상태에서 25fps 정도 나오던 개발자용 빌드와 다르게 30fps까지 성능이 향상됐다. 30fps라는 것은 최댓값이기 때문에 이제 CPU를 100% 사용하지 않는다는 뜻이고 이는 곧 CPU에 여유가 생겼다는 뜻이다.

“오오!! 대박!! 진수 님 우리가 코드 수십군데 수정한 것보다 효과가 훨씬 좋은데요?”

“당연하죠. 환경의 큰 변화를 준거니까요.”

“환경요?”

“네. 저희가 만든 코드 외에도 성능을 좌지우지하는 것이 많대요.”

“그런 건 누가 가르쳐줘요? 책에서 보신 거예요?”

“아저씨한테 배웠어요.”

“엥? 무슨 아저씨길래 코딩을 할 줄 안데요?”

“나중에 기회 되면 제가 소개 한번 시켜 드릴게요.”

“넵.”

“아무튼, 이제 우리 스킬도 한번 사용해볼까요?”

“넵. 베기 스킬 써볼게요!”

베기 스킬은 튜토리얼 던전에서 처음으로 사용하는 스킬로, 우리가 최적화를 하기 전인 사내 테스트 때는 베기 스킬 사용 시 fps가 1~3정도 나왔다. 이 정도면 화면이 멈춘 건가 싶을ont id='ul_4' color='green' class='ul' onclick='fShowHelp(4)'>싶을 정도로 느린 수준이다.

그 후 우리가 코드 레벨의 최적화를 진행했고, 그 후에는 fps가 4~6 정도로 올랐다. 어찌 보면 2배나 빨라졌지만, 어찌 보면 여전히 게임을 못 할 정도로 느린 것이다.

우리는 기대 반 설렘 반으로 베기 스킬을 썼다.

나와 고주영은 서로를 바라봤다.

“음??”

“주영 님 베기 스킬 다시 써봐요.”

우리 둘은 다시 작은 스마트폰 화면을 주시했다.

고주영 님은 개발자치고 많은 표정을 가지고 있다. 이번에는 경이로운 표정을 지으며 말했다.

“음?!?!”

“숫자··· 숫자! 지금 fps 몇 나왔었죠??”

“가장 낮았을 때가 15요···?”

“음··· 인터넷에서 본 글에는 성능이 30~50% 정도 좋아진다고 했는데, 기대 이상이네요.”

“이거 생각보다 성능이 너무 좋아졌는데요. 너무 좋으니까 더 찜찜해요. 왜 이렇게 많이 차이 날까요?”

나는 잠시 고민해봤다. 그리고 떠올랐다.

“주영 님 제가 코드 레벨 최적화할 때 했던 말 기억나세요? 문자열(string)을 조합하는 것은 느리다고?”

“네 기억나요.”

“그게 문제였던 것 같아요. 스킬을 사용하면, 데미지나 hp 정보 등 개발자들이 보기 위한 로그들을 엄청 많이 심어 놨어요. 그리고 그 로그들은 스트링 조합으로 만들고요. 이건 제가 스킬 담당이었기에 알아요. 스킬 한번 사용하면 로그가 백 줄 가까이 생성되거든요. 근데 유저들한테는 필요 없는 정보니까. 개발자 모드가 아니면 이 로그도 필요 없겠죠?”

“오~ 맞네요. 그거겠네요. 실제 코드의 성능은 30% 정도 좋아졌지만, 유저 모드로 빌드 함으로써 불필요한 로그를 생성하는 시간도 없어졌다는 거죠?”

“맞아요. 그래서 이렇게 극적으로 성능이 좋아진 것 같아요.”

주영 님은 신이 나서 말했다.

“fps가 6에서 15가 됐으면 성능이 2.5배 빨라 진 거죠?”

“잠시만요 계산을 좀 해볼게요. fps가 5면··· 프레임당 200ms가 소비된 거고··· fps가 15면 1000 나누기 15니까··· 67ms 정도 되겠네요.”

어제 아저씨가 내게 했던 말이 떠올랐다.

“주영 님. 우리 성능 향상 기준을 fps로 측정하면 안 될 것 같아요. 기준이 없기 때문에 몇 배 빨라졌냐를 따지면, 성능이 해석하기 나름이 될 것 같아요.”

“그럼 뭐로 봐요?”

“한 프레임을 재생시키는데 얼마의 시간이 들었느냐로 기준을 잡아야 할 것 같아요. fps 표시하는 곳 옆에 괄호로 프레임 당 소비 시간을 넣어 줄래요?”

“넵. 그게 낫겠네요. fps15으로 표시하던 걸 fps15(67ms) 로 표시하도록 수정할게요.”

어떻게 우리 팀은 개발자용 빌드로 사내 테스트를 하는 초보적인 실수를 할 수 있었을까?

개발자용 옵션 체크를 해제하는 것만으로도 우리 게임의 성능이 30%나 좋아졌다.

사내 테스트의 실패는 뼈아프지만, 이제부터 최적화 담당이 된 내게는 이보다 큰 행운이 없다.

“겨우 클릭 한 번으로 30% 이상 성능 향상이라니··· 주영 님 사실을 빨리 알려줘야겠죠?”

“왜요?”

“왜라니요? 당신들 실수가 있어서 성능이 안 좋게 나왔다고 알려줘야죠.”

“실수도 실력이죠. 그리고 이건 실수가 아닐걸요? 개발자용 옵션이 있는지 없는지 모르는 사람이라면요? 너무 쉽게 성능을 올리는 것 같아서 찝찝하시겠지만, 이건 그냥 우리 성과에요.”

듣고 보니 주영 님 말이 일리가 있다. 우선 최적화를 더 해보고 고민해보자.

“생각해보니 그렇네요.”

“네. 그런데 아직도 랙이 있어요. 이상하게 스킬을 처음 사용할 때 랙이 있어요. 같은 스킬을 두 번째 쓸 때는 괜찮은데···”

“그건 이제부터 찾아볼까요? 다시 개발자용 빌드를 준비해보죠.”

우리는 프로파일이 가능한 개발자용 빌드로 다시 빌드 후 프로파일을 해봤다. 프로파일을 해보니 결과는 바로 나왔다.

프로파일 데이터를 보던 주영 님이 말했다.

“진수 님. 이거 로딩인 거 같아요.”

“왜요?”

“스킬을 처음 사용할 때 메모리 사용량이 갑자기 올라가면서, 하드디스크를 읽어요. 뭔가 로딩하는 것 같아요.”

나도 프로파일 결과를 유심히 봤다.

“그렇네요··· 스킬을 두 번째 사용하면 어떻게 돼요?”

주영님은 스킬을 한 번 더 썼고, 다시 프로파일 데이터를 봤다. 그런데 이번에는 메모리나 하드디스크의 사용량이 처음 스킬을 썼을 때 비하면 현저히 적었다.

프로파일 데이터를 기반으로 유추해봤을 때, 이펙트나 이미지, 사운드 등을 처음 사용할 때 하드디스크에서 데이터를 읽어 들이는 행위가 느린 것 같았다. 그리고 두 번째 사용부터는 이미 메모리에 데이터가 올라가 있기 때문에 느리지 않았을 것이다.

주영 님이 말했다.

“처음 스킬 쓸 때 필요한 이펙트들을 미리 로딩해둬야 할 것 같아요. 로딩 구간에서 데이터를 미리 로드해두면 게임을 플레이할 때는 느리지 않을 거예요.”

나는 잘 찾아낸 주영 님을 진심으로 칭찬해줬다.

“맙소사! 그걸 어떻게 단번에 찾죠? 주영 님은 최적화에 재능이 있나 봐요.”

“흐흐흐··· 칭찬 정말 오랜만에 듣네요. 감사합니다. 칭찬해주셔서.”

대학생 시절 과탑을 할 정도로 우등생이었던 고주영은 좋은 성적과 큰 꿈을 가지고 미들소프트에 입사했다. 하지만 그가 미들소프트에 입사 후 1년 내내 들었던 것은 칭찬이 아닌 구박이었다.

고주영은 구박받을 때마다, 자신의 실력을 탓하며 더 열심히 일했다. 하지만 자신의 노력을 알아봐 주지 않는 동료들에게 실망을 느낀 고주영은 자신을 더 어필하기 위해 더욱더 직설적인 화법으로 말했다. 그리고 그 직설적인 말투로 인해 동료들에게 더 구박받게 되는 악순환의 반복이었다.

그 팀에서 신입인 고주영을 가르치려고만 하지 않고, 단 한 명이라도 그에게 진심 어린 칭찬을 해줄 수 있는 사람이 있었다면, 상황은 많이 달라졌을 것이다.

“주영 님 앞으로도 잘 부탁해요. 저는 주영 님이랑 같이 일하는 게 좋아요.”

주영 님은 부끄러운 듯 작은 목소리로 대답했다.

“네··· 저도 진수 님이랑 일하는 게 좋아요···”

[페일블루]

재미있어요!

[ki****]

항상 감사합니다!