최적화는 두가지 부류로 나눌 수 있다.

한가지는 문제영역의 디자인과 밀접하게 연결되어 있는 최적화
다른 한가지는 하면 좋지만 안해도 치명적이지는 않은 최적화

전산학에서 말하는 '때이른 최적화는 만병의 근원이다' 에 해당하는 내용은 후자다.

게임쪽의 예를 들어 생각해보자.

네트워크의 성능에는 Latency와 Bandwidth 라는 두가지 주요 제약조건이 존재한다. 이 둘 중 어느쪽이 디자인과 밀접하게 연결된 최적화고, 어느쪽이 치명적이지 않은 최적화에 해당할까?

과거 56kbps 모뎀시절에는 답은 '둘 다' 였다. Bandwidth 를 확보하기 위해 패킷의 양을 줄이기 위해 비트하나까지 합쳐쓰는 최적화가 필수였다. 또한 Latency 문제를 해결하기 위해 Dead reckoning 같은 다양한 방법들이 필수였다.

하지만 지금 초고속 인터넷의 시대에서는 적어도 Bandwidth 는 디자인과 밀접하게 연결된 최적화와는 멀어지고 있다. 패킷에서 한비트씩 아끼는 것보다도 CDN 에 올릴 클라이언트의 ZIP 압축레벨을 최대로 세팅해주는게 더 회선비용 절감에 도움이 되더라는 얘기도 있을 정도다.

반면 Latency 문제는 여전히 해결이 불가능하고, Latency 최적화는 디자인의 일부여야만 한다. 참여 개체들의 정보를 분배해주는 과정에서 Dead Reckoning 은 디자인 자체의 주요 요소일 것이고, 향후 어떤 식으로 인프라가 바뀌더라도 디자인에 영향을 주지 않으면서 이 문제가 해결될 일은 당분간 없을 듯 하다.

따라서, Bandwidth 최적화는 디자인과 상관없으니, 개발단계에서는 패킷의 크기 마음껏 쓰고, 나중에 정 문제가 되면 그때부터 손대도 늦지 않다. 개발단계에는 좌표같은거 그냥 float 로 보내도 된다.


그래픽스 쪽은 어떨까?

예전에는 Vertex Count, Texture Count, Texture Resolution 등등이 다 제약조건이었지만, 지금은 대역폭이 점점 증가함으로 인해 모델 하나의 Vertex Count 는 예전만큼 중요한 요소가 아니다.

하지만 텍스춰를 비롯해서 재질을 변경하게 되면 그만큼 Batch 처리를 못 하게 되고 결국 DrawPrimitive Call 이 증가하게 되기 때문에 Texture Count 는 여전히 중요한 제약조건이다.

Texture Resolution 은 Design 에 의존성이 적으므로 쉽게 Resize 가 가능하고 Mega Texture (ID) 나 Virtual Texture (Crytek) 같은 방식으로 필요한만큼 해상도를 더 공급할 대안이 있다.

- 여기서 Network 와 Graphics 간의 최적화의 유사성이 느껴지지 않는가? 둘 다 Bandwidth 에서는 괄목할만한 성장을 이뤘지만, Latency 라는 측면에서는 발전이 더딘 편이다. -


결론 : 디자인에 영향을 주지 않을 최적화는 초반에는 하지 말자 (나중에도 하지 말라는 얘기는 아님)

imcgames 의 김학규입니다