주말 내내 시청으로 레이드 뛰었습니다. 파티원(와이프)과 함께 키우는 펫(33개월된 우리 아들)도 같이 갔습니다. ^^; 2시 좀 넘은 시간에 시청 앞 광장에 모여서 아이템(피켓 등)도 챙기고 포션(생수)도 점검하고 을지로를 거쳐 한바퀴 돌았습니다.

해가 지고 나서는 준비해 온 초를 켰습니다. 새벽까지 남아 광화문 앞에서 공성전을 하지는 못했지만 그래도 아주 작은 목소리나마 보태어 봅니다. 세종로에서 촛불 들고 서 있다가 아들 녀석이 칭얼 대길래 아래 쪽 청계천으로 내려 갔습니다. 100여 미터도 떨어지지 않은 곳에서는 집회가 한창인데 이곳은 조용히 흐르는 물가에 연인들, 가족들이 걸터 앉아 건너편에서 들려오는 통기타 노래 소리를 들으며 조곤조곤 이야기를 나누는 정겨운 모습이 가득합니다. (그런데 장소가 청계천인 것이 참 아이러니합니다)

2008년의 대한민국은 이런 모습이 어울립니다. 2009년의 대한민국도, 그 다음 해, 다음 다음 해의 대한 민국이 원하는 것도 이러한 평화로운 모습일 것입니다. 대화를 통해 소통이 되는 그날까지, 대한민국 화이팅입니다~

지난 금요일에는 CATIA 로 유명한 Dassault Systems 의 한국지사를 방문했었습니다. Dassault에서 게임 사업에 진출하기 위해서 개발한 3D 엔진을 보기 위해서였는데요, 왼쪽 사진의 히데요 사토씨의 프리젠테이션도 보고 궁금한 것들에 대한 질문을 할 수 있는 시간도 가졌습니다. EA등에서도 사용하고 있는 프로토타이핑 툴로 잘 알려진 Virtools 도 최근에 Dassault에서 인수했다고 합니다. 아마도 게임 사업을 위한 포석으로 해석이 되어 지는데요, Virtools의 경우 학습이 용이한 점을 이용해서 다양한 곳에 사용이 되고 있는데 금요일에 보니 PSP와 Wii의 개발도 가능하더군요. 사토씨가 그의 개인 노트북으로 보여준 Virtools을 이용한 PSP 게임 개발에 대한 동영상은 꽤 인상적이었습니다.

사토상의 명함을 보면 'Application Engineer'로 나와 있습니다만 추측컨데 풀타임 R&D 팀에 소속되어 개발만을 전담하고 있는 것 같지는 않았습니다. 원래는 대학을 졸업하고 인공위성을 통해 전달되는 데이터를 분석하는 작업 등을 하다가 현재는 Virtools 관련 일을 하고 있다고 하는데요, 전 세계를 돌아다니면서 사용자들에게 새로운 기술이나 기능을 이야기해주고 그들로부터 피드백을 받아 본사(프랑스)의 R&D 팀에게 전달하고 또 신제품에 대한 기능이나 기술을 고개들에게 전달하는 것이 주요한 업무라고 합니다. 덕분에 아직 결혼을 못한 것일지도 모르겠습니다만(^^) 대개의 한국의 게임 개발자들이 회사에서 게임을 개발하는 일, 특히나 프로그래머의 경우 프로그래밍(-이라고 쓰고 코딩이이라고 읽습니다) 외에는 다른 일은 생각을 할 수 없는 환경[1] 때문에 나이가 들면서 타 직종보다 직업의 장래에 대해 더욱 불안해 하는 것을 많이 보았습니다. 우리도 본인의 노력 여하에 따라 선택할 수 있는 다양한 환경이 빨리 만들어졌으면 하는 바램입니다.

- 일본인으로 보이지 않는 유창한 영어 솜씨와 소주 주량. 소주를 잘 마셔서 꽤 놀랐습니다. ㅋ

[1] 본인들이 극구 그것만 고집하는 경우도 꽤 있는 것이 사실입니다.

멀티 코어란 무엇인가?

멀티 코어(multi-core)는 멀티 코어 CPU를 이야기하는 것인데 이것은 두 개 이상의 독립 코어를 단일 집적회로로 이루어진 하나의 패키지로 통합한 것으로 듀얼 코어(dual-core) 프로세서는 두 개의 코어를 포함하고 있으며, 쿼드 코어(quad-core)는 네 개의 코어를 포함하고 있다.

현재 칩 제조사에서 출시하는 신형 CPU들은 이렇게 두 개 이상의 CPU를 내장한 멀티 코어 CPU가 주종을 이루고 있다. 이는 단일 코어에서 더 이상 코어 클럭을 이용해서 성능을 올리는 방법으로는 한계에 도달했기 때문이다. 그런데 이러한 하드웨어 환경에서 게임의 성능을 최대한 끌어 올리도록 만들기 위해서는 하드웨어에서 제공하는 여러 개의 코어들을 이용해서 병렬 처리(parallel processing)가 가능한 구조로 게임을 구성을 해야 한다. 왜냐하면 단일 쓰레드를 사용하도록 제작된 프로그램은 여러 개의 코어를 가진 프로그램 내에서 실행이 되더라도 속도가 빨라지지 않기 때문이다. 멀티 코어가 주는 성능을 최대한 이용하기 위해서는 응용 프로그램이 멀티 코어를 지원하도록 작성해야 하는데 문제는 이것이 쉽지 않다는 것이다.

왜 멀티 코어 프로그래밍이 어려운가?

우선 언어적 특성에 기인한 원인이 있다. 일반적으로 게임에 사용하는 C와 C++은 본질적으로 순차적 언어이기 때문에 병렬 처리가 당연한 문제의 경우에도 구현이 쉽지 않는 경우가 많다.

그런데 이런 언어 상의 문제점만 있는 것이 아니라 게임이라는 애플리케이션의 특징에 기인한 문제점도 있는데 이것은 더욱 복잡하고 까다롭다. 첫 번째로 다른 응용 프로그램과 비교할 때 게임은 인공지능, 물리 시뮬레이션, 네트워킹, 애니메이션, 렌더링 시스템 등과 같은 다양한 서브 시스템으로 구성이 되어 있는 것이 보통이다. 그런데 이들 서브 시스템은 서로 결합되어 작동되는 것이 보통이므로 단순한 서브 시스템의 조합으로 구성된 응용 프로그램과 비교할 때 훨씬 더 복잡한 구조를 가지고 있다. 즉, 서브 시스템 간의 의존도가 높기 때문에 병렬 처리하는 것이 어렵다. 두 번째는 게임이 이벤트 중심의 애플리케이션이라는 점이다. 게임은 사용자의 입력이나 네트워크를 통해 전송되는 패킷, 게임 내에 정의된 시나리오, 물리 시뮬레이션 등에 의해서 수시로 변경되며 서로 상호작용해서 작동되는 것이 보통이다. 그리고 이런 이벤트들을 전체 시스템의 관점에서 보면 정해진 규칙은 있지만 순서는 없다. 이러한 이벤트들은 여러 개의 서브 시스템에서 처리하여 그 결과를 이용하게 되는데 게임에서는 이렇게 각 서브 시스템간에 데이터 정보를 공유해야 하므로 서브 시스템들을 독립적으로 병렬 처리하는 것이 어렵다.

그리고 세 번째로는 게임의 실시간성에 따른 프레임에 관한 문제이다. 게임은 실시간으로 작동되어야 하기 때문에 게임은 매 프레임을 순차적으로 처리해서 렌더링 하게 되는데 현재의 프레임은 이전 프레임에 의존적이기 때문에 프레임들을 병렬 처리할 수가 없다. 이것도 게임을 병렬 처리 하기 어려운 이유 중의 하나이다.

그러면 멀티 코어 프로그래밍은 어떻게 접근해야 할까?

멀티 코어 시스템은 여러 개의 프로세서를 처리하므로 프로세서 간 통신을 위한 효율적이고 유연한 소프트웨어 아키텍쳐를 필요로 한다. 이 소프트웨어 아키텍쳐란 각 서브 시스템 간의 교환되는 데이터의 동기화가 용이한 모델에 초점을 맞춘 것을 말하는 것으로 데이터의 동기화 뿐만 아니라 코어의 개수가 서로 다른 환경에서도 안정적으로 작동될 수 있어야 한다. 이러한 병렬 처리 데이터 동기화의 모델 중에서 게임에 적합한 모델로는 비동기화 함수 병렬 모델(Asynchronous parallel model)이라는 것이 있다. 게임에서는 보통 게임 로직, 물리 연산, 렌더링의 순서로 작업이 행해 것이 보통인데 비동기화 함수 병렬 모델에서는 이 세 가지를 각각의 코어로 실행하고 이들 코어간의 동기화는 최신 결과를 기다리지 않고 이전 결과를 가지고 작업을 수행하는 것이다. 예를 들어 렌더링에서는 이번 프레임에서의 물리 연산의 결과를 기다려서 렌더링 작업을 수행하는 것이 아니라 이전 물리 연산 결과를 이용하여 렌더링하게 된다. 이것은 게임이라는 응용 프로그램이 적당한 응답성만을 보장하면 되는 특성에 기인한 것으로 이 방법을 사용하면 각 서브 시스템간의 분리 뿐만 아니라 병렬 처리도 용이해 진다는 장점이 있다.

디버깅에서도 차이가 있다. 일반적으로 멀티코어 시스템의 디버깅은 단일 시스템의 디버깅보다 더 복잡하고 어플리케이션에 영향을 미칠 수 있다. 하나의 코어 또는 코어의 하위 집합만이 정지되는 경우에는 다른 코어가 정지된 코어로 데이터를 전송하거나 수신할 수 있기 때문에 단일 쓰레드에서의 디버깅과는 다를 수 있다.

이상 언급한 것은 소프트웨어적인 측면인데 이런 소프트웨어적인 측면 뿐만 아니라 하드웨어적인 측면에서도 고려해야 하는 점이 있다. 예를 들어 메모리나 버스의 경우에도 사용 가능한 대역폭을 코어 간에 공유해야 한다는 점에 주의해야 한다. 소프트웨어 아키텍처가 아무리 잘 설계가 되어 있다고 하더라도 이러한 부분에서 병목 현상이 발생하게 되면 당연히 퍼포먼스에 영향을 미치게 되기 때문이다.

실제로는 이보다 더 많은 내용들이 있겠지만 여기까지만 살펴 보더라도 멀티 코어로의 패러다임의 전환은 그 어느때보다 소프트웨어 특히 병렬 처리와 관련한 소프트웨어를 잘 다룰 줄 아는 프로그래머의 역할이 중요해졌다는 것을 알 수 있다.

멀티 코어가 대세가 되는 시대에는 더 이상 하드웨어의 업그레이드 만으로는 프로그램의 빠른 실행을 기대할 수가 없게 되었다. 이제는 기술 진보의 의미가 클러 수의 증가로 하드웨어가 빨라 지는 것을 의미하는 것이 아니라 병렬 처리가 가능한 코어의 증가로 동시 처리의 증가를 의미하는 시대가 도래 되었다. 이것은 주어진 문제를 여러 개로 분리해서 가장 효율적으로 처리할 , 수 있는 방법이 중요한 이슈로 부상했다는 것을 의미한다.

참조

[1] 위키피디아 - 멀티코어, http://ko.wikipedia.org/

[2] Multithreaded Game Engine Architectures, Gamasutra,

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php?print=1

 오픈 소스 프로젝트를 하면서 얻는 또 다른 경험은 지구상의 매우 다양한 개발자들과 교류할 수 있다는 점입니다. 어제는 처음으로 세르비아인과 이야기를 했습니다. 유럽의 발칸 반도에 위치해 있고 코소보 전쟁으로 잘 알려져 있다는 정도 외에는 아는 것이 전혀 없는 나라입니다. 적어도 아시아권의 대부분(저를 포함한)은 그럴 것 같다고 생각이 듭니다. 제가 처음 만나는 외국인(비록 온라인 상이더라도)들에게 한국전쟁(6.25) 이야기를 하지 않듯이 그들의 전쟁 이야기는 하지 않는데 그 친구가 먼저 전쟁 이야기를 꺼내더군요. 코소보 전쟁은 영화 등(그것도 주로 첩보 영화 -_-)에서 본 것이 대부분이라 아는 것이 없어 대화를 다른 주제로 돌렸습니다. 자기 나라를 소개하는데 전쟁 이야기를 꺼내야 한다는 것이 그 친구가 그리 유쾌한 일은 아니겠지요. 저 역시 씁쓸한 느낌을 지울 수가 없네요.

그런데, COD4에서 스나이퍼 미션이 코소보 전쟁이 소재가 아니었던가요? 문득 비슷한 느낌이던 것 같았다는 생각이 듭니다.

리더는 염세주의여서는 안됩니다. 왜냐면 염세주의자는 현실 앞에 고개를 숙이고 있거나 자꾸만 뒤를 돌아 보려 하기에.

계속 걸어야 합니다. 때로는 틀린 길이라도 걸어 가면서 수정해야 할 때가 있습니다. 훌륭한 리더라고 해도 그가 이끄는 길이 항상 옳을 수 없을지도 모릅니다. 하지만 훌륭한 리더라면 길이 틀리다는 것을 안 순간 수정도 빠르겠지요. 시작에 있어야 끝이 있듯 움직이야 목표에 도달할 수 있습니다.

얼마 전에 해후 에서 그 친구가 북미에서와 한국에서의 개발의 차이점을 설명 하면서 이야기한 'Dynamic' 이라는 단어가 머리 속에서 계속 부유합니다. 현재 있는 회사에서의 개발은 Dynamic해서 좋답니다. 최근에 안팍으로 겪는 여러 일들이 이런 생각들을 더욱 잦아지게 하는 것 같습니다.

팀이 Dynamic 해지기 위해서는 리더의 Driving이 필요합니다. 장애물은 잘 피해가고 필요할 때 가속을 붙일 수 있는 드라이빙의 기술 말입니다. 리더는 핸들이어야 합니다. 바퀴가 혼자 굴러서 목적지까지 갈 수는 없지 않겠습니까. ^^

폴리곤 리덕션 툴의 하나인 Donya Simplygon 입니다.



기존의 유사 툴들과의 차이점이라면 이쪽은 SDK라는 것.

유사 제품군에는 회사에서는 Polygon Cruncher(아래 왼쪽)이란 놈을 사용하고 있는데 이 보다 저가인 Action 3D(아래 오른쪽)라는 저가의 제품도 있습니다. 


<Polygon Cruncher>

<Action 3D>

Polygon Cruncher의 경우에는 개인적으로 몇 가지 테스트를 해본 적이 있는데 (당연한 이야기겠지만!)프로그래머가 만족할 만한 최적화를 보여주지는 않습니다. ^^