존카맥의 멀티코어 프로그래밍에 대한 의견

아래에서 퍼옴
http://includes.egloos.com/1482083


이쪽 3D 세계에서 가장 가장 영향력 있는 사람은 역시나 카멕 형님^^;; 이시다.
형님께서 한마디 하셨는데, 역시나 좋은 이야기고, 한번쯤 생각해볼 수 있는 이야기인 듯 하다.
번역도 이정도면 매우 훌륭하니.. 번역하신 분의 글을 그대로 올려본다.
(루리웹의 Newbie님께서 번역한 것을 매니안 닷컴에서 퍼왔습니다.)

------------------------------------------------------
따라서 콘솔은 앞으로 우리 id에게 좀더 중요한 플랫폼이 될 것입니다. xbox360, PS3,PC 플랫폼을 거의 공통된 코드베이스로 공통된 개발전략 하에서 만들 계획이고, 여기서 처음 발표하는 것이지만 id software 역사상 최초로 자체에서 콘솔용 게임을 PC와 동시에 개발하고, 그리고 가능하다면 모두 동시에 출시할 예정입니다.

최근 몇주동안 저는 실제로 xbox 360 에서 개발작업을 착수했습니다. 앞으로 개발될 게임의 그래픽 작업도 일단은 360 에서 시작될 것입니다. 여기에는 분명히 이유가 있습니다. 분명히 이야기한다면 PC 버전이 콘솔 버전에 비해 늦게 나오지는 않겠지만 이렇게 360 에서 개발을 시작한 이유는 (전체 멀티플랫폼에서의) 개발 과정이 순조롭게 진행되도록 하기 위한 것입니다.

엑박용 둠 3 은 물론 훌륭한 게임이었긴 하지만 - 여기에 대해서는 매우 만족하고 있고 상업적으로도 성공적이었습니다 - PC 버전이 완성된 다음 포팅하는 과정에서 매우 어려움을 겪었습니다. 우리는 이런 과정을 좀 바꿔서 전체 개발과정을 좀 더 무리없이 진행하려고 합니다.

우리 id는 오랫동안 콘솔 게임 개발에 간헐적으로 참여해 왔습니다. 제가 콘솔 개발을 한 것은 오리지널 슈패부터였고 지금까지 몇 개의 콘솔 게임 작업을 해 왔었습니다. 물론 PC의 유연성과 매우 빠른 발전속도, 그리고 콘솔의 하드웨어를 최대한 활용할 수 있는 것에는 모두 일장일단이 있습니다.

여기서 잠깐 PC와 콘솔의 발전과정을 살펴보기로 하죠.

초창기의 우리 게임, 즉 오리지널 둠을 개발할 때는 우리는 대부분의 PC 비디오 카드를 레지스터 레벨에서 직접 다루어서 게임을 작성했습니다. 즉 그래픽 카드의 추가적인 기능을 사용하기 위해서 특별한 그래픽 모드를 만든다든지 식으로 게임을 만들었죠.

이후에 우리가 윈도우용 게임을 만들게 되었을때, 즉 퀘이크 이후의 개발에서는 보다 추상적인 게임개발 과정으로 변했습니다. 즉 그래픽 API나 시스템 소프트웨어 인터페이스를 이용해서 게임을 만들었고, 이렇게 함으로써 게임은 다양한 하드웨어에서 별 무리없이 도는데 보탬이 되었습니다. 아마 오리지널 둠 시대에는 프로 오디오 스펙트럼이니 애드립이니 하는 각각의 사운드 카드 드라이버가 게임에 들어 있었지만 그 이후에는 그럴 필요가 없었다는 것을 기억하는 분도 있을 겁니다.

3D 시대가 됨에 따라서 API에 관한 논쟁이 있었는데, 즉 최소한 20종 이상의 그래픽 칩이 난립했었고, 어떤 API 를 이용해야 이런 그래픽 카드들을 문제없이 다룰 수 있는가가 매우 복잡한 문제였죠. 지금은 결국 ATI와 NVidia의 딱 2개 회사로 좁혀졌다는 것은 좋은 일인데, 두 회사 모두 3D 그래픽계에서 제대로 일을 해 왔으니까요.

특히 가장 최근의 게임개발 과정 (둠3) 에서, 몇 가지의 진보된 그래픽카드의 기능을 다루게 되었을 때 드라이버 문제 때문에 꽤 많이 고생했습니다. 게임에 넣고 싶은 새로운 기능, 새로운 하드웨어, 새로운 기술들을 넣기 위해서 드라이버 수준에서 상당히 많은 일이 필요했었습니다. 즉 프레임 버퍼 오브젝트라든지 몇가지의 픽셀 버퍼 렌더링 등을 처리하는 데 있어서 몇가지 드라이버들은 안정성에서 상당한 문제가 있었습니다.

따라서 상당히 골치아픈 경우가 많았는데, 드라이버가 개선되서 제대로 기능이 작동하게 되면 이것 때문에 게임 자체가 느려진다든지 하는 일도 있었고, 따라서 기능과 속도 쪽을 서로 왔다갔다하면서 일하는데 꽤 어려움이 있었습니다. 즉, 우리는 이전처럼 하드웨어를 직접 다루는 것이 아니라 (API 나 드라이버를 거쳐서) 하드웨어와 상당히 거리를 두고 게임을 만들기 때문에 PC쪽에서 그래픽 성능을 제대로 뽑아내는데 꽤 어려움을 겪었습니다.

요즘의 그래픽 API의 인터페이스는 특정한 기능을 호출하면 특정한 하드웨어에 이걸 어떻게 그리는 식으로 1대 1로 매칭되는 방식으로 움직이는 것이 아닙니다. 즉 현재 그래픽 카드 드라이버 내에서는 프로그래머가 지시한 그대로 움직이기 보다는 드라이버 자체내에서 (게임 개발자의 의도와는 상관없이) 알아서 처리하는 부분들이 상당히 많이 있습니다. 따라서 최근의 게임 개발에서는 (문제가 생겼을 때) 이것이 내가 프로그램 작성에서 실수한 것인지, 드라이버의 문제인지, 아니면 하드웨어의 문제인지 판단하는데 상당히 어려움이 있었습니다.

따라서 xbox 360 플랫폼에서 개발을 시작했을때 매우 마음에 들었던 것이라면, 360 에서는 매우 얇은 API 레이어를 통해서 하드웨어를 직접적으로 다룰 수 있다는 것입니다. 즉 "메모리 레이아웃을 이렇게 지정한다", 내지는 "이 함수를 호출하면 커멘드 버퍼에 이런 명령어를 넣어준다" 식으로 직접 하드웨어를 다룰 수 있다는 것입니다. 따라서 저는 Xbox360 을 주 개발 플랫폼으로 앞으로 6개월 동안 작업을 할 예정입니다. Xbox 360 에서는 프로그래머인 저와 하드웨어 사이에 놓여있는 인터페이스가 최소한이기 때문에 정확히 내가 원하는 그래픽 기술을 시험해 볼 수 있고, 내가 원한 만큼의 성능을 뽑아낼 수 있고, 여기서 어느 정도 작업을 한 다음 이것을 바탕으로 PC 관련 업체들에게 적어도 콘솔 플랫폼에서 할 수 있는 것만큼의 드라이버를 만들어 달라고 요구할 수 있기 때문입니다.

우리는 PS3 개발키트도 가지고 있고, 모든 플랫폼에서 조금씩 기본적인 작업을 하고 있습니다.

많은 사람들은 저의 OpenGL과 D3D 에 대한 관점 때문에 저를 '반 MS파' 라고 생각하고 있는 게 사실입니다. 그렇지만 사실 MS가 콘솔 플랫폼에 대해서 한 일에 대해서는 매우 칭찬하고 싶군요. 현 세대의 엑박과 앞으로 나올 360 은 제가 콘솔에서 본 것중 가장 훌륭한 개발환경을 가지고 있습니다. 그동안 여러가지 서로 다른 콘솔 개발환경을 보아 왔지만 MS는 근본적으로 소프트웨어 회사이고, 소프트웨어 개발의 중요성을 잘 이해하고 있는 관계로 개발환경을 만드는 데 있어서 매우 잘해왔다고 생각합니다. 이런 상황은 닌텐도나 소니, 이전의 세가와 같이 주로 하드웨어 회사인 다른 회사들과는 꽤 상반된 모습입니다. 이런 차이는 '하드웨어 중심의 회사' 들은 개발자가 실제로 게임을 만드는데 무엇이 가장 중요한 것인지보다는 하드웨어적인 관점에서 어떻게 기계가 좋아 보이는가에 위주하여 의사결정을 내리는 것이 원인이라고 생각합니다.

콘솔 개발환경의 역사를 살펴보면 하드웨어를 저수준으로 억세스할 수 있는 기회를 주었다가, 다음 콘솔에서는 좋은 인터페이스와 좋은 툴을 준 다음 이런 저수준으로 제어할 수 있는 방법을 주지 않는 것처럼 이랬다 저랬다 하는 경우가 꽤 있었습니다.

아주 엣날의 사이드 스크롤 타일 기반의 콘솔(역주 : 슈패 및 그 이전)에서는 레지스터 레벨에서 하드웨어를 억세스할 수 있었습니다. 이때는 프로그래머가 모든 것을 알아서 해야 했으며, 하드웨어 자체는 매우 조잡했고, 하드웨어 업체에서 기대하는 특정한 종류의 게임에 맞추어서 하드웨어가 디자인되었습니다. 물론 이렇게 제한된 하드웨어에서 프로그래밍하는 것도 꽤 재미있습니다.

그렇지만 이 추세가 크게 변한 것은 오리지널 플스 1 이 나왔을 때인데, 플스 1 에서는 원래 가장 저수준의 그래픽 코드를 직접 억세스할 수 없는 개발환경이었습니다. 그렇지만 소니에서는 프로그램하기 쉬운 성능 좋은 하드웨어를 만들었으므로 즉 빠른 프로세서, 빠른 그래픽 가속기, 그리고 여기서 고급 언어를 이용해서 프로그램을 하면 되었으므로 문제가 없었습니다.

이것은 당시의 세가 세턴과는 큰 대조였는데, 여기서는 5개의 서로 다른 프로세서가 있었고, 완전히 뒤죽박죽이었습니다. 세가에서는 프로그래머를 위해서 로우 레벨 하드웨어 관련한 문서를 제공하긴 했지만 개발환경 자체가 별로 좋지 않았습니다.

그러나 재미있는 것은 그 다음 세대에서는 소니는PS2 에서 저수준의 하드웨어를 다룰 수 있는 그다지 깔끔하다고는 할 수 없는 다중 프로세서 기반의 하드웨어쪽으로 방향을 바꾸었다는 것입니다.

그 다음에 MS가 엑박을 내놓았고, 엑박은 그동안 우리가 콘솔에서 본 환경 중 가장 깔끔한 개발환경을 가지고 있었습니다. 그렇지만 엑박에서는 3D 시스템의 가장 로우 레벨까지 직접 억세스할 수 있지는 못했습니다. 여기에 대해서는 '이게 MS의 잘못이냐 Nvidia의 잘못이냐' 하는 여러가지 논쟁이 있었다는 것을 알고 있었습니다만, 엑박 자체는 여전히 개발자에게 있어서는 훨씬 이득을 많이 주었습니다. 만약 엑박과 PS2 에서 동시에 개발해 본 개발자에게 물어본다면 엑박 쪽이 훨씬 더 개발이 쉽다고 할 겁니다.

MS가 어느 정도의 성공을 거두긴 했지만 시장에서 먼저 나온 PS2 를 앞지르지 못했다는 것을 보는 것은 매우 흥미있는 일입니다.

이제 좀 더 개발자 위주로 만들어졌다고 개인적으로 생각하는 xbox360 이 먼저 출시되고, PS3 이 좀 뒤에 늦게 나오면 어떤 결과를 낳을 것인지 지켜보면 매우 흥미있을 겁니다.

하드웨어쪽의 측면에서 이번에도 콘솔의 성능에 관련해서 수많은 마케팅적인 이야기가 난무하고 있지만, 이런 것들의 대부분은 그냥 한 귀로 듣고 넘어가는 것이 좋습니다. 아마 여기 있는 분들 대부분은 PS2 발표시에 나왔던 이모션 엔진에 대한 이야기들, 그리고 이것이 게임의 모든 것을 어떻게 바꿀 것인지에 대한 이야기들을 잘 기억할 것이고, 실제로는 이런 이야기들이 이루어지지 못했다는 것도 알고 게실 것입니다. 사실 그 플랫폼에서는 프로세싱 파워 자체가 문제가 되었습니다.

앞으로 나올 차세대 콘솔들을 살펴보면, 여러가지 면에서 이 콘솔들은 여러가지 스펙 수치나 flops 수치에서 암시하는 것만큼 강력하지는 않습니다. 만약 펜티엄이나 애슬론 등의 x86 프로세서에서 돌아가도록 디자인된 코드를 두 콘솔의 PowerPC 프로세서에서 돌려보면 현재의 최고사양 PC의 약 절반 속도로 돌아갈 것입니다. 그 이유는 새로운 콘솔의 프로세서는 in-order 프로세서고, 펜티엄이나 애슬론과 같은 현대적인 PC 프로세서같은 out-of-order 프로세서가 아니기 때문입니다. 물론 이들 CPU의 클럭 자체는 겉보기에는 상당히 높아 보이지만, 이 클럭 자체는 사실 어느정도 구라클럭적인 면이 있습니다. (클럭수를 2로 나누면 대충 PC 프로세서의 성능과 비슷)

이런 것들을 보충하기 위해서 두 콘솔 모두 멀티프로세싱 어프로치를 선택했습니다. 이런 상황은 PC 쪽에서도 일어나고 있습니다.

사실 인텔, AMD, IBM 등 CPU 개발사들은 이제 싱글 쓰레드 시스템을 보다 빨리 돌릴 수 있는 싱글 프로세서를 만드는 데는 한계에 부딪힌 관계로 이런 상황은 필연적인 것입니다. 그러나 아직도 시장에서는 '무어의 법칙'을 따라서 좀 더 빠른 시스템을 원하고 있고, 모든 소비자들은 항상 이전보다 좀 더 빠른 시스템을 원합니다.

물론 아직까지는 CPU에 집적되는 트랜지스터 갯수는 계속 늘어날 것이고, 사실 무어의 법칙은 속도보다는 트랜지스터 집적도에 관련되어 있는 이야기인데도 사람들은 무어의 법칙이 속도에 관련된 것이라고 잘못 해석하고 있었습니다. 이전에는 트랜지스터 집적도가 늘어나면 당연히 속도가 늘어난다고 직접적으로 관련지을 수 있었지만 이제는 트랜지스터가 늘어나는 것과 속도의 증가가 직접적으로 비례하기는 힘들어졌습니다.

따라서 이제 병렬처리 쪽으로 가는 것은 대세일 수 밖에 없고, 지금까지 가장 성공적인 병렬처리의 예는 바로 그래픽 가속기입니다. 그래픽 가속기는 전산학의 역사상 가장 성공적인 병렬처리의 예라고 할 수 있습니다. 즉, 그래픽 가속기는 트랜지스터 집적도가 증가함에 따라서 그대로 성능이 증가되고, 따라서 소비자들에게 직접적인 이득(더 나은 그래픽)을 줍니다.

그렇지만 CPU에서의 멀티프로세싱은 이것보다는 좀 더 어렵습니다. 이 분야는 지난 몇십년동안 활발하게 학계에서 연구된 분야입니다. 어떻게 프로그램을 병렬화할 것인지, 어떻게 병렬 컴퓨터를 만들지, 어떻게 병렬화 컴파일러를 만들어서 기존의 코드를 멀티코어 프로세서에 맞게 컴파일해서 수행속도를 늘릴지 등등 수많은 학술적인 연구결과가 나오긴 했지만 현실적으로 이루어진 성과는 별로 없습니다.

물론 이런 멀티프로세싱이 매우 잘 적용되는 응용분야도 있긴 합니다. 기술적인 용어로 이런 것들은 '놀랄 만큼 병렬화가 쉬운' 것이라고 일컬어지는데, 이런 것에는 레이트레이싱 렌더링이라든지, 벡터 프로세싱에 사용되는 수학 라이브러리 같은 것들이 있습니다.

그렇지만 게임 코드는 여기에 해당하지 않습니다. 게임 코드는 C 컴파일러인 GCC 와 비슷한 상황입니다. 즉, 루프, 분기, 포인터가 여기저기 널려 있는 뒤죽박죽스러운 코드이고, 병렬 환경은 고사하고 일반적인 경우에도 성능 향상을 꾀하기가 쉽지 않은 코드입니다.

따라서 멀티코어로 얻을 수 있는 이득은 게임 개발자나 유저들에게는 처음에는 실망스러울 것입니다. 하드웨어 개발사가 이런 이득을 쉽게 얻을 수 있는지, 어렵게 할 수 있는지는 하드웨어 개발사의 선택에 따라서 달라집니다.

360 에서는 근본적으로 3개의 프로세서가 있고, 이 프로세서들은 모두 같은 메모리 풀에서 돌아가고, 동기화되고, 캐시가 연계되고 있으므로 멀티프로세싱을 위해서는 다른 쓰레드를 하나 실행해서 작업을 하면 됩니다. 이런 상황이 사실 멀티코어 프로그래밍에서 최상의 케이스이긴 하지만, 이 경우에도 멀티프로세싱으로 보다 나은 성능을 얻거나 게임에서 더 많은 일을 하게 만드는 것은 쉽지 않습니다.

이런 하드웨어에서 취할 수 있는 멀티프로세싱 게임 구조라면 렌더러를 다른 쓰레드로 분리하는 것이 될 것입니다. 퀘이크 3 에서 우리는 이미 이런 식으로 듀얼 프로세서를 이용하는 것을 지원한 경험이 있습니다.

이때 실제로 꽤 성능 향상이 있었는데, 우리가 퀘이크 3 을 발표했을때, 적어도 저의 테스트 시스템에서는 듀얼 프로세서에서 일부 경우에서 40% 의 성능 향상이 있었습니다. 그러나 우리쪽에서 코드를 바꾸지도 않았는데도, 비디오 카드의 드라이버나 시스템의 변화, 혹은 OS 의 변화에 따라서 듀얼 프로세서 가속은 경우에 따라서 작동되기도 했고, 안되기도 했습니다.

듀얼 프로세서를 제대로 지원하도록 다시 작업해 봤지만 하나의 시스템에서만 작동하고 다른 시스템에서는 작동하지 않는 경우도 있었습니다. 사실 되는 시스템과 되지 않는 시스템 사이에 어떤 차이가 있는지는 확실히 알 수 없었습니다. 즉 OS 나 드라이버 관련 문제가 복잡하게 연관되어 있었고, 이런 문제는 콘솔에서는 덜 할 것이라고 생각합니다만 어쨌든 요점은 병렬처리를 이용해 게임 프로그래밍을 하는 것은 어렵다는 것입니다.

게임 개발 과정을 보다 힘들게 하는 것은 어떤 것이든 별로 좋은 것은 아닙니다.

즉, "(병렬처리를 하기 위해서 투자하는) 추가적인 개발 시간을 들여서 과연 어느 정도의 성능 이득을 얻을 수 있는가" 를 잘 판단해야 된다는 것이죠.

물론 이런 쪽에 대해서 긍정적으로 생각하는 사람들도 있습니다. 물론 어느 정도 일리가 있는 이야기이고, 소니는 이런 식으로 말합니다. "물론 이렇게 게임을 만드는 것은 매우 어려운 일일 것이다. 그렇지만 능력있는 개발자라면 어쨌든 엄청 고생해서 게임을 만들어 낼 것이다"

물론 이 이야기도 분명히 일리는 있고, 엄청난 시간과 노력을 투자해서 멀티 코어 프로세서에서 좋은 성능을 끌어낼 개발자도 분명히 있을 것입니다. 그리고 CELL의 경우에는 다른 멀티 코어의 어프로치보다 좀 더 여러울 것입니다.

그렇지만 지금 의문을 갖고 있는 것이 있다면 그것은 다음 세대에서는 차라리 멀티코어 프로세서 시스템으로 가지 말고 (AMD나 인텔과 같은) out-of-order 프로세서를 쓰는 쪽이 나을 수도 있지 않을까 하는 점입니다.

물론 지금부터 멀티코어 어프로치에 익숙해지는 것은 게임 개발자에게 있어서 바람직한 일일 것입니다. 물론 차세대 콘솔의 1세대 게임은 콘솔의 멀티프로세서를 제대로 활용하기는 힘들겠지만 차차세대 콘솔이 나올 때쯤이면 게임 개발자들은 이런 멀티코어 프로세서를 사용하는 데 조금 더 익숙해져 있을 것이고 어느 정도는 이것을 활용할 수 있을 것이기 때문입니다.

그러나 근본적으로 멀티코어 프로그래밍을 쉽게 하는 방법 자체는 없을 겁니다. 즉 예상컨데 멀티코어 프로그래밍 자체는 여전히 어려울 것이고, 병렬 프로그래밍을 쉽게 해결할 수 있는 만능의 열쇠 같은 것은 나오기 힘듭니다. 이런 문제를 해결하기 위해서 엄청 똑똑한 사람들이 20년 이상 노력해 왔지만 앞으로도 무슨 뽀족한 수가 나올 것 같지는 않군요.

-------------------------

간단히 요약하자면,

개발자 입장
멀티코어 개발은 어렵다. 하지만 준비도 해야 한다.
이제 콘솔을 기준으로 개발이 가능하지 않겠는가?
정도가 개발자로서 읽었을 때 중요한 이슈 되겠다.

게임 유저 입장
XBOX 360 기준으로 개발하니 카멕 형님 다음 신작은 360을 사서 즐길 준비를 해야겠다.

참고 : in-order 프로세서 VS out-of-order 프로세서
컴퓨터 사이클의 활용에 관한 프로세서의 분류이다.
여러 경우 명령어가 데이터를 기다리는 동안 쉬게 되는 경우가 발생하는데,
그런 시간을 활용하는 내용을 부여한 프로세서이다.
자세한 내용은 "http://en.wikipedia.org/wiki/Out-of-order_execution"에서 보시면 되겠습니다.
결국 콘솔은 게임 여기저기에 많이 사용되는 if, swith 문 등이 CPU를 느리게 만드는 범죄를 더더욱 많이 저지를 수 있는 를 사용하는 셈이 된다 뭐 이런 이야기다.
따라서 카멕 형님께서는 콘솔의 CPU를 클럭 기준으로는 나누기 2를 하라 말씀하신 것이 되겠다.