꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 알 수 없는 사용자
테크니컬 아티스트(Technical Artist)는 간단히 줄여서 TA라고 합니다. TA라는 명칭은 2009년정도만 해도 국내 게임 업계에서 생소한 명칭이였지만 이제는 업계에서 모르는 사람이 없는 단어가 되었고 TA를 하겠다고 지원하는 신입 개발자도 많아졌습니다.

그런데 TA에 대해 잘못 알고 있는 사람들도 종종 보게 되고 명함에 TA라고 써있으나 제대로 된 역할을 하고 있지 못하는 경우도 있어서 TA를 바라보는 개인적인 생각을 좀 적어보려고 합니다.

하지만 TA에 대해 애정남이 정해준 것도 아니고 브리태니커 백과사전에 써있는 것도 아니므로 저의 개인적인 주관이 반영된 내용입니다. 또한 게임 개발 업계는 가장 다이나믹하게 구조가 변화하는 곳들 중 하나이기 때문에 1년 뒤에는 상황이 달라져 있을 수도 있습니다. 그리고 늘 그렇듯이 직책이나 직급의 명칭은 회사마다 의미가 다르기 때문에 절대적인 것은 아닙니다.

저도 유행 따라 짤방 하나 투척...


TA는 프로그래머인가?

넥슨 컨퍼런스에서 TA에 관한 패널 토크에 패널로 참여를 준비하기 위해서 그래픽 아티스트들이 TA에 대해 어떻게 생각하는지 간단히 조사했던 적이 있었습니다. 당시 조사 자료는 회사 하드 어딘가에 있어서 지금은 기억나지 않지만 가장 인상적이였던 대답은 '프로그래머' 라는 대답이였습니다.

그런데 프로그래머에게 똑같은 질문을 하면 어떤 대답이 나올까요? 아직 설문 조사를 해보진 않았지만 정말 다양한 대답이 나올 것으로 예상됩니다. 하지만 '프로그래머다' 라는 대답은 나오기 힘들 것으로 생각됩니다.

여담이지만 프로그래머들 사이에서도 '프로그래머' 라는 호칭이 붙기 위한 기준이 참 다양하더군요. 경험상 프로그램을 잘 하는 사람일 수록 '프로그래머' 에 대한 기준이 엄격했던 기억이 납니다.

저는 TA가 아티스트라고 생각합니다. 단어에서 이미 답이 나와 있거든요. 테크니컬한 아티스트라는 뜻입니다. (Technical) Artist 라는거죠. 어쨋든 아티스트인데 테크니컬하다는 단어입니다.

비슷한 경우가 또 있는데요, 비주얼 프로그래머라는 역할이 있더군요. 이 사람은 프로그래머입니다. 시각적인 효과에 관련된 프로그래밍을 해서 비주얼 프로그래머라고 부르는 것으로 생각됩니다. 액션 영화에서 무술을 담당하는 무술 연기자는 무술가일까요 연기자일까요? 시작을 무술로 했더도 저는 연기자라고 생각합니다.

그런데 '문법상 TA는 아티스트다' 라는 말을 하려는건 아닙니다. TA가 하는 역할을 자세히 살펴보면 프로그래머는 아니라는 사실을 알 수 있습니다.

TA의 역할 분류
  • 엔지니어링(Engineering) - 뭔가를 만들어내는 작업
    • 쉐이더 개발에 참여
    • 맥스 스크립트 혹은 MEL 스크립트 등을 이용한 툴로 아티스트 생산성 향상
    • 최적화 되고 진보된 캐릭터 리깅을 제공함으로써 애니메이터 생산성 향상
    • 프로그램 팀에 샘플 데이터 신속히 제공
  • 문서화(Documentation) - 뭔가를 알려주는 작업
    • 엔진 분석 및 아티스트용 작업 지침서 제작
    • 아티스트용 개발 규약(Convention) 설정 및 배포
    • 새로운 툴 도입 및 전파 - 예를 들면 CAT이나 모션 빌더 등. 포토샵의 신기능 소개라던가.
  • 조율(Coordination) - 원활한 커뮤니케이션
    • 프로그래머의 작업 대비 시각적인 개선 효과를 아티스트 관점에서 판단하여 작업 우선 순위를 결정할 때 의견 제시
    • 오브젝트 배치 툴 등 인하우스 툴을 개발할 때 가장 적은 비용으로 효과적인 기능을 수행할 수 있도록 의견 제시하고 오버 엔지니어링이 되지 않도록 함
    • 각종 회의 상황에서 프로그래머와 아티스트간 동시 통역
이 중에서 프로그래머라고 볼 수 있는 항목은 쉐이더와 스크립트 툴 정도입니다. 전반적인 TA의 역할은 프로그래머 이외의 것들이 더 많죠.

하지만 쉐이더와 스크립트 역시 프로그래머라고 보기에는 무리가 있다는 생각입니다. 게임에서 쉐이더는 최적화라던가 게임의 그래픽 옵션 연동이라던가 저사양 그래픽카드 지원 등 꽤나 하드코어적인 이슈들이 많아서 프로그래밍만으로 오랫동안 고생해온 사람들에게도 쉽지 않은 일입니다.

스크립트 역시 그래픽 아티스트의 단순 반복 작업을 개선해주는 간단하고 귀여운 것들이라면 상관 없지만 오브젝트를 배치하는 등 게임의 핵심적인 기능을 스크립트 툴로 구현하려고 하는 시도는 좋지 않습니다. 예를 들어 툴을 개발한 스크립터가 퇴사한 뒤에 게임의 핵심적인 기능을 수행하는 툴을 수정하거나 업그레이드 해야할 일이 생기면 곤란해집니다. 아마 대부분의 프로그래머들이 맥스 스크립트 자체를 들여다보는 것을 꺼려할테고 들여다보더라도 조악한 수준의 스파게티 코드를 보면 기겁을 할테니까요. 혹시나 천재적인 스크립터가 아름다운 구조로 툴을 만들었을 수도 있겠지만 그런 사람이라면 맥스 스크립트로 툴을 만들지 않았을거란 생각입니다.

마야의 MEL 스크립트는 그나마 나은듯 하지만 게임 개발 환경에서 핵심적인 기능을  맥스 스크립트에 의존하게 될 경우 치명적인 단점이 또 있습니다. 맥스 자체가 버그 덩어리라는 점입니다. 오브젝트 20개에서 잘 되던 툴이 200개가 되면 메모리 오류가 나면서 맥스가 뻗어버리는 일들이 정말 많거든요. 이런 일이 생기면 오토데스크에 건의해서 맥스를 고쳐달라고 해야할까요?

사실 프로그래머로서 재능이 있는 TA들이 종종 있습니다. 또한 프로그래머 못지 않은 쉐이더 코드를 만들 수 있는 사람들도 있구요. 하지만 예외적인 경우 말고 일반적으로는 TA가 만드는 쉐이더 코드는 프로그래머와 대화하기 위한 도구로 사용하는 것이 가장 바람직하다고 생각합니다.


전부 다 해야 하는건가?

역할 분류를 보면 참 다양한 일을 하는게 TA입니다. 그렇다면 이 모든 것들을 다 해야 할까요? 그렇지 않습니다. 대부분의 경우 현재 팀원의 능력에 맞게 본능적으로 역할을 분배하게 됩니다.

사실 TA라는 명칭이 생기기 전부터 TA의 역할은 누군가에 의해 수행되어 오고 있었습니다. 대부분 경험 많은 그래픽 팀장이나 아트 디랙터에 의해서 작업 효율 향상이라던가 작업 프로세스의 문서화라던가 프로그래머와의 커뮤니케이션이 이루어져 왔습니다.

앞서 적었던 TA의 역할 분류에서 문서화라던가 조율에 관한 부분들은 수 많은 실전 경험 없이는 수행하기 어려운 역할이며 'TA가 교육될 수 있는 것인가' 하는 질문에서 가장 어려운 부분이기도 합니다. 반면에 엔지니어링에 관한 부분은 프로젝트를 수행해본 경험이 별로 없어도 가능하고 교육도 가능합니다.


TA의 성장 트리


요즘 기준에서 TA가 되려면 어떻게 해야하는지를 생각 해보면 두 가지 정도 방법이 있는 것 같습니다.
  1. 쉐이더나 스크립트를 배워서 엔지니어로 입사한 뒤 개발 경험을 쌓으면서 점차 문서화 및 조율의 역할로 확장해 나가는 길
  2. 기존 아티스트 역할을 하면서 자신이 테크니컬에 관심이 많은 경우 자연스럽게 엔진 분석을 하고 문서화를 하며 프로그래머와 기술적인 조율을 많이 하게 되고 쉐이더나 스크립트에도 관심을 가지게 되면서 자연스럽게 TA로 전직하는 길

그런데 여기서는 프로그래머가 TA로 성장하는 것에 대해서는 배제했죠. 그 이유는 TA가 일단 아티스트이기 때문입니다. 과거에는 프로그래머였지만 현재는 아티스트다 라는 경우가 있을 수 있습니다. 그래도 그 사람은 어쨋든 아티스트입니다. TA를 하려면 아티스트에 대한 이해가 더 우선되어야 한다고 생각합니다. 왜냐하면 어쨋든 아티스트이니까요.

아티스트가 아닌 사람이 TA 역할을 하는 것에 대해서는 개인적으로 부정적인 생각입니다. 아티스트가 가려운 곳을 긁어주진 않고 오버 엔지니어링을 하기 쉽거든요.


팀 내 커뮤니케이션

TA는 이처럼 생각보다 넓은 영역의 역할을 수행할 수 있고 그래야 합니다. 하지만 현실은 그렇지 못한 경우가 많습니다. 간단한 예를 한가지 들어보겠습니다.

어떤 개발 팀에 유명한 원화가로 이름을 날리던 사람이 아트 디랙터 역할을 하고 있습니다. 그런데 이 사람은 기술적인 부분이 취약한데다 요즘 개발팀에 TA는 다들 있는거라고 해서 스크립트와 쉐이더를 작업할 TA를 뽑습니다. 신입 TA는 열심히 시키는 대로 툴을 만들고 게임용 쉐이더를 만들지만 게임의 프레임은 안나오고 아티스트들은 버그 많다고 툴은 안씁니다. 또한 파트장 회의라고 해서 기획팀장과 프로그램 팀장과 아트디랙터와 프로듀서가 참여하는 회의체에서 아트디랙터는 기술적인 부분을 몰라서 비 효율적인 진행이 됩니다. 그래서 앞으로 모든 회의마다 TA를 참여시켜야겠다고 생각하지만 비슷한 취지로 추가되어야 할 인원이 갑자기 너무 많아집니다.

쓰고 보니 간단한 예는 아니군요.

기술적인 기반이 없는 사람은 아트 디랙터로 적합하지 않다고 쓴 예는 아닙니다. 저는 오히려 아트 디랙터라면 기술적인 기반보다 아트의 비젼을 제시할 수 있는 능력이 더 중요하다고 생각합니다.

어떤 사람이라도 아트의 감각과 기술적인 능력을 동시에 충분히 가지기란 쉽지 않습니다. 하지만 게임 개발의 아트 팀에서는 이 두 가지 능력이 동시에 필요하기 때문에 해당 팀원들의 스펙에 맞게 유연하게 역할을 조율해야 하고 대부분 그러고 있습니다.

그렇다면 TA가 굳이 아트 디랙터나 그래픽 팀장이 아니더라도 TA의 전체 역할이 잘 수행되려면 어떻게 해야할까요? 전문적인 TA이면서 모든 역할을 하려면 어떻게 해야할까요?

이 질문에 대한 답은 아직까지 확실히 결론이 나지 않았지만 팀내 개발 커뮤니케이션을 개선해서 해결해야 한다고 생각합니다. 개발에 관한 중요한 결정을 몇몇이 결정하고 나머지 사람들은 그저 시키는 일만 군소리 없이 해야하는 폐쇄적인 커뮤니케이션에서는 TA 뿐만 아니라 다른 모든 역할도 제 기능을 못할 것입니다.

반대로 만들려는 게임의 청사진과 의사 결정의 과정이 투명하게 공유되고 활발하게 의견이 오고가는 팀에서라면 말단 신입 TA라도 충분히 조율할 수 있는 여지가 있으며 TA로서 빠르게 성장할 수 있다고 생각합니다.

결국 TA의 역할이 제대로 되기 위해서는 팀내 커뮤니케이션이 중요하다 라는 말인데요, 팀내 커뮤니케이션이 잘 되면 TA만 행복한건 아니겠죠. ^^

ps. 대마왕님 엄청 멋지고 길고 재미있는 글 쓰시는데 저는 언제나 짧고 간단하게 날로 먹습니다.
반응형
,