0043.txt

데이터 중심 디자인(Data Oriented Design, DOD)의 개념은 아시는 분들은 아실 거예요. 지금까지 저희가 쓰던 개체 지향 프로그래밍(Object Oriented Progamming, OOP)에서는 개체가 함수와 데이터를 모두 포함하고 있고, 그 안에서 일어나는 일은 개체가 알아서 해결한다는 개념이기 때문에 메모리에서 데이터를 봤을 때 포인터가 다른 메모리를 가리킬 수 있고, 데이터가 일률적으로 저장이 되어있지 않아요. 

이 개체 지향 프로그래밍이 문제가 되었던 게 플레이스테이션 3에 SPU라고 하는 포인터 연산이 거의 안 되는 칩셋이 있었거든요? 그래서 저희가 멀티스레딩 시작할 2005, 2006년에는 그냥 포인터 참조로 연산하는 방법도 있었고, 아니면 멀티스레딩으로 실행할 데이터만 일률적인 데이터로만 구성된 구조체로 만들어서 멀티스레딩으로 돌린다던가, 아니면은 처음부터 구조 자체를 다 뜯어고쳐서 포인터 같은 걸 제외하고 메모리에 데이터를 순차적으로 들어가게 하는 방법들도 있었어요. 이게 데이터 중심 디자인의 기본 개념이에요. 이전에 C에서는 절차적 프로그래밍이었기 때문에 당연히 이렇게 사용했고요. ps3가 나오면서 조금씩 다시 각광을 받기 시작했던 거죠.

근데 요즘 들어서 생각하는 것은 개체 지향 프로그래밍이 멀티 스레딩에 적합하지 않았기 때문에, 특히 ps3의 SPU에서 곧바로 포인트 참조가 안 되니깐 그걸 해결하려고 했던 게 큰 건데, 과연 데이터 중심 디자인이 좋은 방법인가? 생각이 들어요. 개인적으로는 저는 아직도 렌더링 엔진 쪽에는 이걸 사용하고 있어요. 왜냐하면 렌더링 엔진 쪽은 게임 로직이 어떻게 바뀌든 간에 내부 구조 자체가 상당히 정형화되어 있어요. 그래서 구조체를 따로 만들어서 데이터를 집어넣더라도 바꿀 일도 많지 않고 그 구조체를 건드릴 사람도 많지가 않아요. 근데 만약에 엔지니어가 많이 필요한 게임 로직 쪽에서 이게 사용되면 문제가 되는 게, 게임을 재미있게 하려면 여러 번 수정을 거처 야하고 게임 기획도 바뀔 수밖에 없는데, 아무래도 프로그램 내부도 바뀔 때마다 수많은 프로그래머가 구조체를 건드리게 된다면 데이터 중심 디자인이 망가지기가 쉬워요. 포인터 참조를 안 하게 해야 한다는 제약 때문에요.

제가 이렇게 느꼈던 건 MLB Front Office Manager 만들 때 저장/불러오기를 담당하는 프런트엔드 팀이 있었어요. 저장/불러오기 파일은 데이터 중심 디자인처럼 구조체에 집어넣고 한 번에 저장하는 방식이었어요. 제가 게임 출시를 한 달 반 앞두고 커리어 모드를 했어요. 보통 게임 QA 하시는 분들은 그걸 빨리 넘겨서 하루 만에 테스트하고 버그 수정을 하는데, 저는 그냥 며칠에 걸려서 게임을 한 거죠. 근데 마지막 챔피언쉽 하기 전에 언제나 게임이 뻑이 나요. 그래서 프런트 팀에 왜 이러냐고 문의하니깐 하는 얘기가 저장하고 게임을 불러올 때 구조체 안에 포인터가 하나 들어가 있다는 거예요. 그러니까 누군가 실수로 구조체 안에 포인터를 저장해 놓은 거예요. 이걸 그대로 하드에 쓴 뒤에 나중에 읽어올 때 문제가 생긴 거더라고요. 이런 문제가 생길 때마다 생각보다 쉽게 안 잡히는 경우도 있어요. 왜냐하면 엉뚱한 곳에 메모리 참조를 해서 덮어쓰면 그것 때문에 다른 곳에서 크래시가 나는 경우도 있거든요. 물론 이걸 잘 찾아낼 수 있는 쉬운 방법은 있겠지만 과연 게임 플레이에서까지 데이터 중심 디자인을 기본적으로 쓸 정도로 가치가 있나 싶기도 하고, 제약도 심해지고 사용하기 복잡해지는 게 있어요.

그리고 차세대 콘솔(PS4, XBOX ONE)은 그냥 일반적인 CPU 아키텍처라서 지금까지 쓰던 CPU 아키텍처 포인터 역참조가 가능해요. 그래서 제가 생각하기는 독립적인 작업으로 나올 수도 있고, 게임과는 상관없이 잘 바뀌지 않는 내부 구조(렌더링, 오디오 필터링)에는 데이터 중심 디자인이 들어가는 건 나쁘지 않다고 봐요. 아무래도 멀티스레딩에서 최대 성능을 낼 수 있고, 코드 베이스를 만지는 사람들 수도 굉장히 제한적일 테니까요. 그렇지만 데이터 중심 디자인을 범용적으로 사용하려고 하는 것은 조금 무모하지 않나... 오히려 그것 때문에 낭비하는 시간이 많지 않을까 그런 생각을 해요. 그리고 너무 게임이 느려지면 그 부분에 대해 최적화하는 방법이 있기는 할 텐데 데이터 지향 설계 자체가 이제 너무 섣부른 최적화 일 수 있기 때문에, 저 개인적인 입장에서는 엔진 쪽에서는 좀 쓸 수도 있겠지만, 게임 플레이 쪽에는 정말 필요하지 않은 이상 피하는 게 좋다는 게 현재 제 생각이에요. 

2005년도 학교에서 한 번 프로젝트 제출할 때 당시 나왔던 컴포넌트 기반 게임 오브젝트를 실험적으로 만들었었는데, 컴포넌트 단위로 들어가기 때문에 어쩔 수 없이 데이터 지향 설계로 만들었던 적이 있었거든요. 그때 이후로는 제가 게임 플레이 쪽에 데이터 중심 디자인을 해 본 적이 없어서 그다지 도움이 안 될 거라는 생각밖에 없어요.