1. 들어가며
우선, 인사부터 드리겠습니다. 대마왕J 입니다.
3일과 18일이라는 영광스러운 자리에 배정해 주셔서 감사합니다 포프 스승님.

일명 '대충 살아가는 게임개발자' 라고 불리기도 하지요. 원래 그래픽 디자이너 출신이었고, 게임쪽으로는 20년이 조금 안되는 경력을 가지고 있습니다. (쓸 데 없이 길기만 하군요)

지금 하고 있는 일은 N문 사에서 그래픽이지만 프로그래밍이기도 한... 테크니컬 아트 디렉터(Technical Art Director) 를 맡고 있고 그 중에서도 shader/Lighting 쪽을 맡아서 일하고 있습니다. 저는 hlsl 언어로 직접 쉐이더를 짜고 있지요.

이 팀블로그에 계신 포프님이나 하이브리드님, 오즈라엘님이나 티스님 같은 다른 모든 분들에 비해서는 턱없이 부족한 실력이라 이거 뭘 쓸 게 있나... 싶었긴 했습니다만,

다른 분들과는 다르게 그래픽 디자이너로 시작한데다가 기초도 없이 맨땅에 해딩하면서 배워왔던 지식이라, 다른 분들보다는 그래픽 디자이너 입장을 쉽게 알 수 있다고 생각해서 ' 엄청나게 무식하고 쉽게' 라는 모토로 기초적인 shader 실습 / 이론을 진행해 볼까 생각해 보았습니다.

마치 '만화로 쉽게 배우는 푸리에 해석' 같은 느낌일까요 -_-; 뭐, 만화는 나오지 않습니다만...

무려 성안당..

가장 중요한 질문을 넘어갈 뻔 했군요.
포프 스승님이 강의에서 말씀하시길, 쉐이더란

"쉐이더란 화면에 출력할 픽셀의 위치와 색상을 계산하는 함수입니다. "

라고 하셨습니다.
음... 감이 오시는지? 저는 이걸 그래픽 디자이너 마인드로 다시 설명해 보겠습니다.

"쉐이더는 '재질' 입니다. 일명 '때깔' 이라고도 하지요."

... 이것이 그래픽 디자이너가 이해하는 쉐이더입니다.

스승님이랑 싸우자는게 아니고, 위의 두 가지 표현이 포프님의 강의와 제 강의의 차이라고 할 수 있겠습니다. 포프님의 강의가 '교과서' 라면, 저는 '그림동화' 입니다 ㅎㅎ

당연하게도 내용은 재미위주고, 깊이는 훨씬 얄팍합니다.

자 여기 그림들이 있습니다.
http://izismile.com/2010/06/30/how_games_change_the_rock_21_pics.html

'게임에서 돌이 어떻게 바뀌나' 라는 재미있는 그림인데, 다소 과장이 섞여 있는 말그대로 재미를 위한 글입니다. 그렇지만, 의외로 쉐이더란 무엇인가라는 대답을 주고 있기도 합니다.

자, 이 중 몇 개만 비교해 보죠.

차이가 보이시는지? 같은 돌임에도 불구하고, 게임마다 뭔가 다르게 느껴지고 있다는 것을 알 수 있습니다. 사실 이 결과물은 단순히 색을 조작해서 게임의 분위기를 풍자하고 있는 글이지만, 조금만 생각해 보면 진짜로 게임마다 저런 '뭔가 독특한 질감' 을 가지고 있었다는 것을 아실 수 있습니다.

또 아래 그림을 보시죠.

같은 모델링인데, 분명히 '질감' 이 다릅니다. '때깔' 이 다르지요. ^[각주:1]

4. 그래픽 디자이너가 shader 를 배워서 어디에 쓸 수 있나요?

요즘엔 shader를 사용 안하는 프로젝트가 전무하다고 할 정도로 게임 그래픽에서 매우 중요한 한 축을 담당하고 있습니다. 그래서 싫다고 해도 어쩔 수 없이 그래픽 디자이너가 shader의 많은 옵션들을 조절하기도 해야 하고, 마스킹 텍스쳐도 적절하게 제작해야만 하며, 필요하다면 원하는 느낌을 내기 위해서 그래픽 프로그래머에게 '어떠어떠한 느낌으로 만들어줘' 라고 요구해야만 하지요. (저희 회사에선 제가 맘대로 합니다만 ㅎㅎ)
이럴때 이론적 지식은 큰 도움이 되게 됩니다. 아무래도 프로그래머가 만든 언어라 그래픽 디자이너와는 용어도 다르고, 원하는 느낌을 최고로 내면서 효율적으로 만들기 위해서 필요한 기술을 그래픽 디자이너가 익히려면 기본적인 지식 정도는 가지고 있어 주어야 하거든요.

그리고 프로그래머에게 이런 기술적 지식 없이 그래픽 디자이너의 언어로
"뽀샤시하지만 착 눌러앉은 색감으로 너무 딴딴하지 않은 질감이 나도록 만들어줘"
라고 요구한다면 프로그래머에게서는 이런 반응이 나오게 됩니다

또한 최근에는 언리얼처럼 노드 구조를 직접 그래픽 디자이너가 조합할 수 있도록 만드는 쉐이더 툴을 지원하는 엔진도 꽤 생겨나고 있는 편인데다가, 최신 3Dmax 에서는 아예 메터리얼 에니터를 이런 노드 구조로 만들기도 하였습니다.

즉, 좋은 그래픽을 위해 꼭 사용할 줄 알아야 하는 메터리얼 에디터가 될 것이라는 거지요.
 
5. 뭘 준비해야 하나요?
원래 이 분야는 프로그램적 마인드로 제대로 접근하자면, 렌더링 파이프라인부터 시작해야 정상입니다. 그치만, 그래픽 디자이너의 마인드는 프로그래머의 마인드와 한참이나 다른 데 부터 시작합니다.

기본적으로 그래픽 디자이너는 비싼 타블렛이나 마우스에 목숨걸고, 프로그래머는 비싼 키보드에 목숨걸잖아요. 인터페이스 조작부터 그래픽 디자이너들은 다르게 접근해야 합니다.

생각해 보세요. 그래픽 디자이너는 첨에 '뭣도 모르고 무작정 이쁘게 그리려다 보니까' 결국엔 더 이쁘게 그리기 위해 빛을 생각하게 되고, 선 그리는 법과 구도, 투시를 익히게 되지요.

그림에 관심도 없는 사람이 그림이론부터 차근차근 배우기 시작해서 나중에 보니까 그림을 잘 그리게 되었더라... 라는 케이스는 거의 없습니다.

멋진 프로그래머가 되기 위해서 그 지루한 기초 프로그래밍을 차근차근 밟아 가야 뭔가 기초적인 결과라도 볼 수 있는 프로그래머와는 달리, 그래픽 디자이너는 처음부터 연필을 잡고 아무생각 없이 휙휙 그려봤더니 뭔가 이쁘더라 ... 에서부터 시작하곤 하거든요.

여기서부터 프로그래머 마인드랑 정반대로 가는 거지요. 프로그래밍 책이 그래픽 디자이너에게 어려운 이유는 그것입니다.

'아놔 첨부터 좀 멋진 거 하게 해 달라고! 버퍼는 뭐고 시멘틱은 또 뭐야!!! 안해!!! '

이게 그래픽 디자이너 마인드지요 :)

그래서 , 복잡한 기본 이론 따위는 나중으로 미뤄 버리려 합니다.
가능한한 첨부터 그림이 나오게 합니다!
바로 제가 수없이 삽질하면서 공부했던 그 방법입니다!

그리고 중간중간 필요한 이론만 간략하게 설명하겠습니다. ^[각주:2]
그러다보니, 필요한게 있습니다. 3D max 입니다.

3D max 는 다소 간략하긴 하지만, 인터페이스가 꽤 괜찮은 실시간 렌더링 툴이기도 합니다. 즉 게임과 다를게 없지요. 3D max 만으로도 초급 shader는 배울 수 있습니다. 무엇보다 그래픽 디자이너들을 위해, 마우스로 대부분의 조작을 할 수 있다는 것과 익숙하다는 장점도 매우 큽니다.

3D max 실력은 높을 필요는 없습니다만, 기본적인 오브젝트 정도는 설치할 수 있는 실력이어야 합니다. (보통, 주전자 정도 만들고 텍스쳐 하나 입힐 수 있는 수준이면 충분해요)

여기에 하나 더, 쉐이더를 다루기 위해서 무료 플러그인이 필요합니다.
앞서 말씀드렸듯, '바로 처음부터 재미있는 실습을 하기 위해' 무언가 설치해야 합니다.

바로 Shader FX 라고 하는 플러그인이지요.

http://www.lumonix.net/shaderfx.html

다운로드는 위 홈페이지에서 받을 수 있습니다. 완전 무료입니다.
 
그리고 시간이 되시는 분은 이 사이트의 강좌 동영상을 훑어 보시면, 사실 제 강의가 필요 없을 정도로 쉽게 이 프로그램을 다루실 수 있습니다. 영어라서 문제지

이 프로그램을 설치해 두세요. 설치시의 유일한 주의사항은, 중간에 맥스의 버전을 잘 선택하시고, 설치 경로를 정할 때 반드시 3Dmax가 설치된 Root 폴더를 선택해 주셔야 한다는 겁니다.

맥스가 설치된 폴더를 정확히 지정해 주어야 합니다 자신의 Max 버전과 맞는 것을 선택하세요[각주:3] 이제 3Dmax를 실행시켜 봅니다. 튜터리얼 동영상 링크가 가득한 첫 화면이 뜨지요. 첫 화면에 이렇게 되면 완성입니다.



안녕하세요. 알콜코더 민군입니다.

현대 게임 개발의 가장 기본적인 모토는 데이터 주도 개발(DDD. Data Driven Development)입니다.

바로 순수한 게임 클라이언트 자체는 일종의 게임 엔진과 같은 역할을 하면서, 외부의 데이터를 기반으로 게임을 제작하는 아키텍쳐입니다.

즉, C++로 제작된 게임 클라이언트는 게임의 핵심 요소만을 구성하면서,  외부에서 사용할 수 있는 API를 제공하고,  게임 코어 외부에서는 루아와 같은 스크립트로 게임 로직을 제작하고,  XML같은 데이터 파일로 게임의 요소등을 정의합니다.

이러한 방식을 가장 잘 활용한 것이 바로 WOW입니다. 와우의 경우에는 UI면에서 이러한 루아 스크립트와 XML을 유저들에게 제공하여, 유저들에게 맞는 다양한 커스터마이징 UI와 애드인들을 제작할 수 있게 되어 있습니다. 그리고 이러한 방법이 크게 성공하여, 수많은 유저들이 만든 다양하고 유용한 애드인 역시 상당히 많습니다.

그래서 와우 이후에도 수많은 게임들이 스크립트를  개발에 다양하게 활용하고 있고, 유니티나 언리얼 같은 게임 엔진은 스크립트만으로도 게임을 제작할 수 있는 형태입니다.

 하지만 제가 이야기 하려는 것은 이런 외부 사용자나 엔진 사용자를 위한 스크립트가 아니라,  실제 게임 개발 내부에서 사용되는 스크립트의 사용에 대해서 이야기를 하려고 합니다.

게임 개발에서 스크립트는 필수 불가결한 요소라는 의견도 많고, 저 역시 그런 의견들에 상당히 동의합니다. 그런데 과연 대한민국의 게임 개발에서 스크립트란게 정말로 유용할까요? 결론부터 이야기하면, 제 개발 경험에 비춰 보았을 때  저는 그렇지만은 않다고 생각합니다.

스크립트는 누가 작성하는가?

원래 스크립트의 용도는 앞서 이야기했듯이, 게임 코어에서 제공하는 API들을 가지고, 게임의 로직을 개발하는 용도입니다.

즉, 일반적으로 게임 코어는 프로그래머가 제작을 하고, 레벨 디자이너나 퀘스트 디자이너 같은 기획자들이 스크립트를 가지고 게임을 제작하는 형태입니다. 실제로 해외 게임의 포스트모텀들을 보면 이런 형태로 스크립트가 사용되어서 개발되고 있습니다.

그러면 과연 대한민국에서도 그럴까요? 아닙니다. 대한 민국의 대부분의 게임 회사에서는  루아 스크립트는 바로 프로그래머가 개발하고 코딩합니다! 전 이것이 가장 큰 문제라고 생각합니다.

한국 게임 개발에서의 스크립트 사용은 간단히 말해서 아래처럼 이루어 집니다.

1.    프로그래머가 게임 코어에서 API를 제작한다

2.    프로그래머가 루아 편집기를 열어서, 자신이 뽑아낸 API를 사용하여 로직을 구현한다.

3.    프로그래머가 만들어진 루아 스크립트를 호출하는 코드를 게임내에 작성한다

4.    게임을 돌려서, 루아 코드를 테스트한다.

5.    부족한 기능이 있으면, 또다시 API를 제작하고, 빌드하고, 루아 코드를 수정한다.

사실 이럴거면, 굳이 기능들을 루아 스크립트로 뽑아낼 필요가 없습니다. 그냥 C++ 코어단에서 직접 로직을 만드는게 훨씬 편하고 간단합니다.

굳이 API로 뽑아내고, 익숙하지 않은 루아 코드로 로직들을 어렵게 구현하고, 그것을 게임에서 다시 호출한 코드를 만들 시간과 노력이 왜 필요하겠습니까? 더불어 루아는 브레이크 포인트도 없고, 디버깅도 어렵습니다.. =ㅅ=;

그냥 C++로 게임 내에서 작성하면 몇줄로 끝날 코드도, 굳이 루아 스크립트를 사용하기 위해서 코드를 작성하면 몇배의 코드와 몇배의 함수들이 생기는 경험은 다들 해보셨을 겁니다.

이것만큼 잘못된 프로세스가 또 어디있을까요? 이건 마치 억지로 루아를 사용하기 위해서, 개발 프로세스를 끼워 맞추는 꼴입니다.

왜 프로그래머가 스크립트를 작성해야 하는가?

왜 위와 같이 잘못된 프로세스가 생겼을까요? 원래 루아를 사용할려는 것은 코어 개발자와 게임 로직/컨텐츠/UI 개발자를 구별하기 위한 것이 목적입니다.

즉, 기획자(디자이너)가 프로그래머가 제공된 기능들을 가지고, 기획 의도대로 마음껏 게임을 개발하고, 변경하고 테스트하기 위한 것이 목적이었던 것입니다.  그래서 프로그래머들은 그런 해외에서 성공한 프로세스들을 공부했고, 그것이 맞다고 배웠습니다.  그렇기 때문에 지금도 열심히 스크립트를 게임에 적용하고 있습니다.

하지만, 한국에서 정작 루아를 공부하는 기획자는 정말로  드뭅니다. 실제로 저도 10년 가까운 개발 경력동안 루아를 코딩할 줄 아는 기획자를 거의 못 봤습니다. 또한 공부하는 기획자 역시도 보지 못했습니다. 아…. 물론 루아를 공부하는 프로그래머라면 지겹게 봐왔죠. =ㅅ=;;

실제로 기획자들과 스크립트에 관련된 회의를 하면 아래 처럼 됩니다.

프로그래머 : 캐릭터 FSM을 루아로 빼줄 테니, 직접 작성해서 만드세요

기획자 : 예?? 내가 왜요? 내가 왜 코딩을 해야 합니까? 나 루아 할줄 몰라요. 그냥 테이블로 만들어 줄께요. 루아 하기 싫어요.

프로그래머: 네… 뭐..그럼 테이블로 만들어주세요. (해달라는데로 해줘야지.ㅅㅂ..)

(그리고 프로그래머는 FSM 관련 API를 만들고, 루아 스크립트로  FSM 코딩을 하고, 게임에 넣어서 개발한다)

이렇게 되면 처음 이야기한 것처럼, 굳이 필요없이 스크립트를 사용하는 프로세스가 됩니다. 다시한번 이야기하지만, 이럴 거면 걍 C++로 FSM 만드는게… 코드도 훨씬 간결해지고, 로직도 간단해 집니다. FSM을 루아로 빼기 위해선, 수많은 상태 체크와 관련 함수들을 전부 루아 API로 빼줘야 하기 때문입니다.

꼭 억지로 스크립트를 써야만 하는가?

위에 언급했듯이 스크립트의 단점은 개발 프로세스가 복잡해지는 것만은 아닙니다.

l  스크립트는 디버깅이 상당히 어렵다

l  스크립트는 VS처럼 전문 개발툴이 없다

l  스크립트는 로딩과 실행 속도가 C++에 비해 몇십배나 느리다.

위와 같은 다른 문제점들도 많습니다. 사실 그래서 꼭 스크립트 안 써도 됩니다. 물론 개발하는 게임의 규모가 상당히 커서 스크립트가 꼭 필요한 경우도 많지만, 사실 안 써도 되는 경우도 훨씬 많습니다. 그냥 스크립트가 있으면, 스크립트를 사용하면 더 좋다는 막연한 잘못된 환상으로 억지로 스크립트를 사용하기 위해서 잘못된 프로젝트 구조를 만드는 경우를 훨씬 더 많이 봐왔습니다.

물론, 가장 좋은 사용법은 앞에서 언급했듯이 코어 프로그래머와 로직을 구현하는 디자이너가 분리되어 자신의 역할을 잘할 때 가장 효율적으로 스크립트를 사용할 수 있습니다. 그렇지 않은 것이 현재 한국 개발의 현실인 것을 감안하면… 굳이 억지로 스크립트를 사용해야 한다는 환상을 가지고 개발 프로세스를 더욱 복잡하게 만들어 버리는 케이스가 더욱 많습니다.

이러한 경우라면 저는 억지로 스크립트를 사용하지 않아도 된다고 생각합니다. 왜 굳이 무엇을 위해서 어렵게 코드를 만들고, 디버깅할때 C++에서 루아를 따라가야 하며, 제대로 디버깅도 되지 않는 스크립트를 써야 할까요? (디버깅하다가 루아 호출 함수를 만나면, 노트패드에서 루아 코드를 꺼내 봐야 하죠. 그것도 브레이크 포인트도 안걸리는 코드를…)

지금 혹시… 여러분도 억지로 스크립트를 사용해야 하기 위해서, 스크립트를 게임 코드에 붙이고 있지는 않나요? ^^;