최적화란 무엇인가?




만약, 지금 당신에게 사고 싶은 게임이 두 개가 있고 그 중 하나의 게임만을 구매할 기회가 있다고 가정해보자. 이 두 개의 게임은 비슷한 수준의 재미를 가지고 있으며, 당신이 이 두 게임에게 가진 흥미 또한 비슷하다면 이 두 개의 게임 중에 어떤 게임을 사야할지 깊은 고민에 빠지게 될 것이다.


그런데 깊은 고민에 빠진 당신이 두 게임의 평점을 살피던 중에 게임 B의 평가에서 "이 게임은 너무 용량을 많이 잡아먹는다", "이 게임은 메모리를 너무 많이 사용한다", "이 게임은 프레임 드랍이 너무 심하다"와 같은 평가를 발견하게 된다면 당신의 마음은 어느 쪽으로 기울겠는가? 당연히 마음은 게임 A를 구매하는 쪽으로 기울게 될 것이다. 게임 B의 구매를 완전히 포기하지는 않더라도 "다음에 세일할 때"라던가 "최적화 되었다는 소식이 들리면" 사야되겠다는 쪽으로 마음을 굳히게 될 것이다.



유저가 구매를 결정하는 단계라면 위의 이야기처럼 구매 의사를 접거나 후로 미루게 될 것이지만, 불안정한 최적화(이후에는 간단하게 "발적화"라고 부르도록 하자)에 대한 소식을 듣지 못했거나, 다른 누군가가 발적화에 대한 소식을 올리기도 전에 누구보다 빠르게 게임을 구매한 유저라면 게임사에 격렬하게 항의를 하거나 게임에 대해서 안좋은 평가를 내리게 되고 그 평가는 앞서 말한 구매를 결정하는 단계의 유저들의 발목을 잡게 된다.


위와 같은 순환을 거쳐서 최적화는 유저가 게임을 구매를 결정하는데 생각보다 많은 영향을 미친다(물론 아무리 최적화가 잘 되어있다고 해도 게임 자체가 재미가 없다면 아무런 의미가 없다).


그에 대한 좋은 예시가 바로 PC판 배트맨 : 아캄 나이트다. PS4판이나 XBox One판은 시리즈 전체에 비하면 낮지만 평범한 수준의 평가를 받았지만 PC 판은 심각한 수준의 발적화로 인해 초토화에 가까운 낮은 평가를 받아들어야만 했다.

이러한 최적화는 한마디로 표현하자면, "더 적은 자원으로 높은 효율을 보여주는 것"이다. 더 적은 리소스로 더 좋아보이게, 복잡해 보이는 처리를 더 빠르게 하는 것이 최적화다.


최적화는 개발자의 경험이 미치는 영향이 아주 커서 최적화를 많이 해본 개발자가 그렇지 못한 개발자보다 더 최적화를 잘 진행하는 편이다.


경험이 많지 않은 초보 개발자들의 경우에는 주로 뒤에서 돌아가는 것보다는 눈 앞에 보이는 것을 우선하는 경향과 일단 만들어보자 하는 면이 있기 때문에, 한 장면만 놓고 봤을 때는 와 그래픽이 좋다라는 평가가 나올 수 있지만, 실제로 게임을 작동했을 때는 메모리를 과다하게 잡아먹거나 프레임이 뚝뚝 떨어지는 현상을 쉽게 목격할 수 있는데, 초보 개발자는 여기서 혼란에 빠지게 된다. 지금 보이는 화면의 퀄리티가 떨어지는 것을 최대한 막으면서 성능을 나아지게 하려면 어느 부분을 덜어내고 어느 부분을 남겨놔야 할지, 어느 부분을 개선해야 최적화가 될지에 대한 감이 전혀없기 때문이다.





최적화 할 수 있는 부분들


최적화를 하는 부분은 대부분 정해져있다.


1. 비효율적인 알고리즘


최적화의 전제 조건은 효율적인 알고리즘이다. 비효율적인 알고리즘을 사용하는 상태에서는 어떤 최적화 기법을 사용한다고 해도 성능은 획기적으로 개선되지 못한다. 예를 들어 컨테이너 안에 든 자료들을 정렬하는 모든 작업에 버블 정렬을 사용한다고 가정해보자. 과연 그 프로그램이 다른 부분을 개선한다고 해서 얼마나 빨라질 수 있을까? 하지만 정렬 알고리즘을 버블 정렬보다 효율적인 알고리즘으로 교체하는 것만으로도 굉장한 성능 개선을 보일 수 있을 것이다.


2. 병목현상 제거


대부분의 프로그램은 모든 부분이 느리다기 보다는 어느 특정한 시점에서 굉장히 느려지는 등의 병목이 발생하는 경우가 많다. 병목 현상이란 특정한 시점에 계산이나 데이터 전송이 몰려서 처리하는 속도보다 요구가 쌓이는 속도가 더 빨라서 느려지는 것을 의미한다. 이러한 병목 현상을 제거해주는 것만으로도 상당한 성능 개선을 기대할 수 있다.


3. 레벨 디자인과 그래픽


게임을 제작할 때, 좋은 그래픽을 보여주기 위한 욕심으로 고화질의 텍스처, 많은 버텍스를 가진 모델, 레벨에 과다하게 배치된 사물들 역시 많은 성능을 잡아먹는 요소가 된다. 최적화를 위해서는 어쩔 수 없이 유저의 시선이 잘 닿지 않는 곳이나 먼 곳 등은, 텍스처의 해상도를 낮추거나 버텍스를 줄이고, 적절한 수의 사물을 배치하는 것 역시 좋은 최적화 요소가 된다.


4. 기획 덜어내기


기획자들은 항상 욕심이 많다. 기획자들은 하나의 게임 내에서 더 많은 것들과, 더 다양한 시스템들을 보여주고 싶어한다. 하지만 프로그래머가 최적화하는데도 한계가 있을 수 밖에 없기 때문에, 과도한 연산이 필요한 시스템이나 과도한 스케일의 기획은 덜어내는 수 밖에 없다. 일반적인 기획자들은 덧붙이기만 하지만 뛰어난 기획자들은 덜어낼 줄 안다.





최적화, 비용과 그 결과의 딜레마


최적화 과정 역시 프로그램 개발 과정의 일부로서 당연히 비용과 시간이 소모된다. 최적화 작업은 초기에는 들인 비용에 비해 개선되는 성능이 높은 편이지만, 과정이 진행되면 진행될 수록 개선되는 성능의 폭이 기하급수적으로 감소한다. 즉, 들인 시간과 비용에 비해서 성능 개선이 너무 적게되는 순간이 반드시 온다는 것이다.


분명 최적화는 하면 할 수록 낮은 사양의 유저들까지 수용할 수 있게 되지만, 그것도 어느 정도의 한계선은 분명히 존재하며, 최고의 성능 개선을 하는데 드는 비용과 시간은 굉장한 수준이다. 그렇기 때문에 최적화 작업에 들어갈 때는 항상 어느 정도 수준까지 개선할 것인지 목표를 잡되, 그 목표가 비현실적이어서는 안된다.

+ Recent posts

티스토리 툴바