2008년 06월 03일
The Smartest programmers(1)
하드웨어가 발달하게 되면서 이전에는 제약 때문에 개발이 힘들었던 점들도 하드웨어 스펙의 향상에 힘입어 개발
이 단순해진다면 좋겠지만 실상은 더욱 복잡해진 것이 현실입니다. 예를 들어 그래픽 하드웨어가 발달하면서 더욱더 실제와 같은 렌더링을 원하게 되었는데 이렇게 요구되는 렌더링 연산을 위해서는 더욱 많은 수의 데이터와 이에 대한 처리가 필요해졌습니다. 처리해야 할 일들의 종류도 많아졌고 더욱 복잡해졌다는 말입니다. 처리해야 할 데이터가 더욱 많아졌다는 사실은 이를 위해 요구되는 개발자의 수도 더욱 많아 졌다는 것을 의미하며 이것은 다시 개발비의 상승으로 연결 됩니다. 이렇게 보면 오히려 하드웨어의 발달이 프로덕션 파이프라인(Production Pipeline)을 더욱 복잡하게 만들고 있다는 것을 알 수 있습니다. 그래서 과거 어느 때보다도 효율적인 개발을 위한 툴의 중요성이 부각되는 때인것 같습니다.
이러한 의미에서 조금 오래된 글이긴 하지만 Tom Forsyth님의 블로그에 포스팅된 글인 'Smart coder priorities'의 전문을 번역해서 올립니다.(의역한 곳도 많으니 이점 참고해서 읽어 주세요. 원문이 직접 링크되지 않으므로 원문을 읽으실 분은 블로그에서 직접 찾으셔야 합니다.'tool'로 검색하면 쉽게 찾을 수 있습니다.) 그리고 Tom Forsyth님의 포스트에서 언급한 툴의 중요성에 대해서 살펴 본 다음에는 실제로 툴을 개발할 때 도움이 될 만한 몇 가지도 소개 하겠습니다.
이 단순해진다면 좋겠지만 실상은 더욱 복잡해진 것이 현실입니다. 예를 들어 그래픽 하드웨어가 발달하면서 더욱더 실제와 같은 렌더링을 원하게 되었는데 이렇게 요구되는 렌더링 연산을 위해서는 더욱 많은 수의 데이터와 이에 대한 처리가 필요해졌습니다. 처리해야 할 일들의 종류도 많아졌고 더욱 복잡해졌다는 말입니다. 처리해야 할 데이터가 더욱 많아졌다는 사실은 이를 위해 요구되는 개발자의 수도 더욱 많아 졌다는 것을 의미하며 이것은 다시 개발비의 상승으로 연결 됩니다. 이렇게 보면 오히려 하드웨어의 발달이 프로덕션 파이프라인(Production Pipeline)을 더욱 복잡하게 만들고 있다는 것을 알 수 있습니다. 그래서 과거 어느 때보다도 효율적인 개발을 위한 툴의 중요성이 부각되는 때인것 같습니다.이러한 의미에서 조금 오래된 글이긴 하지만 Tom Forsyth님의 블로그에 포스팅된 글인 'Smart coder priorities'의 전문을 번역해서 올립니다.(의역한 곳도 많으니 이점 참고해서 읽어 주세요. 원문이 직접 링크되지 않으므로 원문을 읽으실 분은 블로그에서 직접 찾으셔야 합니다.'tool'로 검색하면 쉽게 찾을 수 있습니다.) 그리고 Tom Forsyth님의 포스트에서 언급한 툴의 중요성에 대해서 살펴 본 다음에는 실제로 툴을 개발할 때 도움이 될 만한 몇 가지도 소개 하겠습니다.
| 현명한 프로그래머의 우선순위(Smart Coder Priorities) 제가 개발자들과 하기 꺼려하는 이야기중에는 다음과 같은 것들이 있습니다. "이봐 밥, UberGameSoft사 일은 잘 되어 가는가?" "이봐 톰, 잘 되고 말고. 나는 멋진 HDR 시스템을 구현하고 있는 중이고, 짐(Jim)은 굉장한 물리 엔진을 구현하고 있고, 프랭크는 놀라운 포스트-프로세싱 효과를 구현했지." "훌륭하군, 그럼 자네들은 이제 게임을 구현할 차례겠군." "그렇긴 한데 말야, 아직도 전체 익스포트 파이프라인에 문제가 있어, 리소스들을 게임 내로 삽입하는데 애를 먹고 있다네." 이 시점에서 보통 저는 그들을 향해 낄낄거리며 다음 블로그를 포스팅할 준비를 합니다. 그런데 말입니다... 우리 같은 엔지니어가 가지고 놀기 좋아하는 멋지거나 혹은 괴짜스러울 만큼 훌륭한 것들이 많이 있습니다. 또 이런 것들 중 몇몇은 GDC에서도 돋보이는 훌륭한 발표거리가 되기도 합니다. 그러나 이 모든 것들이 이제 이야기할 것에 비하면 전혀 중요하지 않습니다. 이것은 바로 게임을 출시하는데 필요한 것들입니다. 이제는 팀 크기는 50~150명에 이르고 개발 기간은 2년에서 4년이 소요되고 있습니다. 이것은 큰 예산입니다. 우리가 진행하는 프로젝트에는 모두가 효율적으로 일할 수 있다는 것을 확신하게 할 만한 현명한 프로그래머가 필요합니다. 이 현명한 프로그래머란 바로 툴 프로그래머입니다. 네, '툴' 말입니다. 무슨 지저분한 소리를 하는 것 처럼 저를 쳐다보지 마십시오. 문제는 우리 중 대다수가 여전히 베드룸 해커(게으른 프로그래머라는 뜻인듯)라는 것입니다. 숨길 필요는 없습니다 - 솔직한 것이 좋잖아요. 하지만 그만큼 두려운 단어를 떠올릴 수 있어야 합니다. 바로 '관리'라는 단어 말입니다. 하지만 우리는 평균 이상으로 똑똑하다고 자부할 수 있기 때문에 PHB 관리 말고도 훌륭한 관리 방법을 사용할 수 있습니다. 그리고 그것은 데이터에 대한 관리가 아닐 뿐만 아니라 사람에 대한 관리도 아닙니다. 자신이 하는 일을 좋아하고 또 자신과 함께 일하는 사람들을 좋아하는 사람들의 경우 그들 자신도 스스로 잘 관리하는 것이 일반적입니다. 문제는 그들 사이에 데이터가 끼어 들어 그들이 같은 데이터에 연관되는 일이 만들어지는 것입니다. 이제 명백하게도 그것은 증거가 충분하지 않습니다. 그런데 사람들은 의존 관계가 명확한 것만을 다룰 수 있다는 것입니다. 마치 여러분이 캐릭터가 리깅(rigging)이 제대로 되어 있어야지 애니메이션을 할 수 있는 것 처럼 말입니다. 문제는 바로 의존관계가 명확하지 않다는 것입니다. 프로그래머인 우리는 그 시스템을 작성한 사람들이기 때문에 우리에게는 그 문제가 명확합니다. 안타까운 것은, 시스템을 만드는 가장 쉬운 방법이라는 것이 필요한 모든 데이타를 한 번에 다 준비한 다음에 전부 다 후처리 작업(post-processing)용 큰 깔때기에 쑤셔 넣고 거기에서 DVD를 떠서 시장에 내 놓는 것입니다. 물론 이런 짓을 했다가는 망하는 것은 불보듯 뻔한 일일 것입니다. 이렇게 하는 대신에 우리는 의존 고리들에 대해서 심사숙고 해 보아야 합니다. 그리고 어떻게 한 작업자가 변경한 것이 다른 사람의 작업에 영향을 끼치지 않도록 할 것인지와 관련된 것들을 동시에 작업하더라도 (서로) 망치지 않도록 함으로써 사람들이 동시에 작업할 수 있는 방법에 대해서 심사 숙고해 보아야 합니다. 이것은 프로그래머가 안고 있는 또 다른 큰 고민거리인 병렬 처리(parallel processing)와 거의 흡사한 문제입니다. 우리 모두는 병렬 처리가 매우 그리고 굉장히 어렵다는 것을 잘 알고 있습니다. 그래서 우리가 가장 현명한 프로그래머를 그 문제의 해결에 투입하는 것 처럼 툴도 마찬가지입니다. 심지어는 이것은 더욱 큰 병렬 처리에 대한 도전입니다. 게다가 이 문제의 경우에는 다른 병렬 처리의 주제-예를 들어 '물리 연산을 더 빠르게 하는 것'-처럼 잘 정의되어 있지도 않습니다. 왜냐하면 게임을 시작한 후 절반이 지나서도 실제로 (프로젝트가)어디로 가고 있는지가 분명하지 않기 때문입니다. 그래서 저는 이 문제들에 대한 것들이 머리 속에 정리되면 더 많은 포스팅을 할 생각입니다. 그러나 제가 가장 지적하고 싶은 것은 예전 처럼 그래픽스 기술을 가진 천재 프로그래머가 모든 문제를 해결하던 시대는 갔다는 것입니다. 쉐이더는 그렇게 작성하기 어려운 기술이 아닙니다. HDR은 자세하게 설명된 책이 있으면 충분히 해결할 수 있는 문제이고 그림자는 다소 고통스러울지 모르겠지만 그렇다고 근본적으로 게임을 만들거나 혹은 게임 자체가 만들어지는 것을 방해할만큼 큰 문제는 아닙니다. 하지만 훌륭한 리소스 관리의 문제는 다른 한편으로 출시와 파산의 차이점을 의미할 수도 있습니다. 그것은 새로운 형태의 천재 프로그래머가 관심을 집중해야 할 필요가 있는 것입니다. |
위의 글은 이제는 컨텐츠 양의 증가와 더불어 개발이 더욱 복잡해졌기 때문에 필요한 개발자의 수도 늘어났고 개발자의 수가 증가하면 당연히 이에 대한 관리도 힘들어 지지만 이보다 더 큰 문제는 개발자와 개발자 사이의 처리 프로세스가 복잡해지기 때문에 필연적으로 개발이 지연될 수 밖에 없는데 이를 해결하기 위한 가장 중요한 방법이 툴이므로 툴의 중요성이 그 어느 때보다 두드러지는 때다라는 정도로 요약할 수 있겠습니다.
그런데 대개의 경우 툴 작업을 시키면 얼굴에서 미소가 사라지는 것이 보통인 것 같습니다 - 툴 이야기 꺼내면 툴툴 거리죠. ^^ 그리고 경력이 많을 수록 이런 현상은 더욱 두드러지는 것이 보통입니다. Tom이 자신의 포스트에서도 툴 이야기를 할 때 dirty word라고 언급한 것으로 보아 그쪽도 우리와 거의 차이가 없어 보이는 것은 매한가지인듯 합니다. 하지만 툴의 중요성을 실감하고 또 작업에 있어 효율적인 방법을 찾는다면 현명한 프로그래머와 성공적인 - 동시에 즐거운 - 게임 개발이라는 두 마리 토끼를 동시에 잡을 수도 있습니다. 그래서 툴 프로그래밍을 할 때 참고할 만한 몇 가지에 대해서 시간이 나는대로 지면에 옮겨 볼까 합니다.
(계속)
# by | 2008/06/03 19:02 | Development | 트랙백 | 핑백(3) | 덧글(3)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
... 가 만든 객체 중에서도 장면 렌더링에 사용되는 객체들이 위치하게 됩니다. (참고로 최상위 루트에 있는 NOH 객체는 '/'입니다)- 그러니까 다시 한번 강조하지만, 가장 스마트한 프로그래머는 툴 프로그래머라는 이야기입니다 ^^ ... more
... 법인데 이런 내용을 알 수 있으면 좋을텐데 말입니다. (MMO 이야기는 그렇게 궁금해 하면서 말입니다) 세 번째 세션의 내용은 올라온 트랙백도 보니 이전에 포스팅한 The Smartest Programmer의 내용과 유사해 보입니다. 세션의 내용은 툴링의 필요성과 이를 위한 언어로 C#의 효용성, 장점에 대해서 설명하신 듯 보입니다. 이 부분에 대한 서적으로는 ... more
... 흔치 않은 전문적인 라이브러리라는 점과 툴 개발과 관련된 내용을 프레임워크로 만들었다는 점에서 주의깊게 살펴 볼만한 가치를 지닌 프로젝트입니다. 이전 포스트인 "The Smartest Programmers"를 생각한다면 코드베이스로 사용해도 손색이 없어 보입니다. 역시 기술의 인썸니악...이로군요. ... more