jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다. 3ds Max를 사용해서 게임용 3D 캐릭터를 셋업하는 방법
이를 위해 오랜 실무를 경험해 온 저자의 고급 노하우들이 공개
위 내용은 GameDevForever의 저자분들의 홍보를 위하여 운영진 자체적으로 올린 광고이며 일체의 수익이 없습니다.(밥좀사줘요~)
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. 대마왕님 엄청 멋지고 길고 재미있는 글 쓰시는데 저는 언제나 짧고 간단하게 날로 먹습니다.
TAG

댓글을 달아 주세요

  1. Favicon of http://gamedevforever.com 대마왕J 2012.01.29 11:34 신고  댓글주소  수정/삭제  댓글쓰기

    우왕 실버치매님도 모잘라 핑속님까지 멋지게 글쓴당 OTL 아니 어차피 네임드분들한테 덤빈게 실순가. 잘 봤습니다 :)

  2. 66v 2012.01.29 20:52 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다. TA에 관한 토론 역시 많은 곳에서 이루어지고 있는 업계의 핫한 키워드 이니 이곳에서도 다양한 의견의 교환이 이루어졌으면 좋겠네요.

    기술이 발전하다 보니 훌륭한 시각적 품질을 얻기 위해선 점점 세분화, 전문화된 최신기술의 역할이 커져가고 있는데 그것들을 잘 활용하기 위해선 그에 상당하는 기술의 이론적 지식또한 필수라는것이 모든 문제의 원인인것 같습니다.

    최신기술들은 대개 복잡한 수학적, 물리학적 전문 지식을 근간으로 하고 있는데 이게 전공자가 아닌 이상은 프로그래머들에게 조차 버거울 정도로 전문화 되어가지만, 주 사용자는 아티스트분들이기 때문에 '툴을 잘 쓰기조차 어려워지는' 시대가 되어버린것 같습니다. 그래서 아티스트분들이 더욱 효과적으로 목표로하는 결과를 내기 위해는 '아티스트의 시점에서 본 툴의 사용법 설명', '툴 또는 프로그래머와 그래픽적 아웃풋 사이의 기술적인 커뮤니케이션' 을 담당하는 역할의 중요성이 크게 대두되어 왔겠지요.

    현재 이런 상황이 주로 벌어지고 있는 분야가 애니메이션용 리그 설정, 셰이더 작성&셰이더용 파라메터 설정(텍스쳐 작성 포함), 라이트맵 작성용 설정&레벨상의 라이트 설정 정도라고 생각됩니다. 시간이 지나면 더욱 범위는 넓어져 가겠지요.

    그런데 이 역할은 회사의 제작방향이나 프로젝트의 인원편성, 세분화정도에 따라 중요해지는 분야가 많이 달라지고, 해당 역할을 할 인재가 마침 사내에 존재해서 중간역할을 주로 하다 보니 이제 해당 인재 없는 개발은 상상하기 힘들다 라는 상황을 경험해 보았느냐 또한 '해당 역할의 필요성을 인지' 하는데에 많은 차이를 가져온 것 같습니다. 그것이 회사마다 TA의 범위를 한마디로 정의할 수가 없는 이유가 되는것 같애요.

    전통적으로는 '툴을 많이 다뤄 본' 아티스트 경력자가 담당해 온 경우가 많았는데 전문화가 갈수록 심해지다 보니 관련지식의 이해도 측면이 더욱 큰 비중을 차지하게 되었고, 이는 경력자의 '시행착오를 통해 툴의 사용법을 습득' 하는것이 '프로그래머적인 센스로 툴을 이해하고 사용' 하는 효율을 따라잡지 못하면서 이제는 별도의 역할로 분리해야 한다고 느끼게 된 것 같습니다.

    뭐든 다 해내는 제너럴리스트를 주로 요구하는 동양쪽 개발사의 경우에는 해당 능력을 가진 직원에게 커뮤니케이션 역할이 집중되는 경향이 있었는데, 특정 역할이 필요하다고 느끼면 자리를 만들고 적임자를 위치시키는 형태의 서양쪽 개발사에서 해당역할을 TA라고 이름짓게 된 것이 그 시작이 되지 않을까 합니다. 그리고 그런 인재의 필요성을 공통적으로 느끼고 있던 많은 개발자들이 TA라는 포지션에 본격적으로 관심을 가지게 된 것 같습니다.

    그래서 범위도 너무나 다양하고, 회사 또는 팀 마다 요구하는 능력범위 또한 틀리면서, 개발경험 또한 해당 포지션의 이해에 중요한 역할을 하기 때문에 TA를 한마디로 정의하기도 힘들고, 필요한 지식범위 또한 마땅히 특정짓기 힘든것 같습니다. 하지만 중요한 것은 '각자의 회사(또는 팀)에서 어떤 부분에서 기술적인 의사소통이 보틀넥이 일어나고 있는가'를 생각해 본다면 해당 회사(팀)에서 필요한 TA의 요구조건이 될 것 같습니다.

    그리고 '이런 역할을 하는 사람은 꼭 필요하더라' 라는 의견을 교환해 나가다 보면 어느정도 공통적으로 TA의 분류 및 필요한 소양등을 일반화 시키는 것도 가능하지 않을까 싶어요. 그런 의미에서 각자 '이런 능력을 가진 인재가 꼭 필요하다' 라는 의견을 교환하는것이 중요하다고 생각합니다.

  3. Favicon of http://gamedevforever.com 김포프 2012.01.30 03:54 신고  댓글주소  수정/삭제  댓글쓰기

    제가 근무하는 렐릭 엔터테인먼트에는 TA가 3명 있는데 다들 성향이 조금씩 다릅니다. 성격 까칠하기로 유명한 제가 봐도 흠잡을 데가 없는 매우 훌륭한 TA들이지요.

    한명은 고등학교 선생 출신인데 렐릭와서 이펙트 아티스트 좀 하다가 TA로 전향했습니다. 사용성(usability)를 향상시키는데 타고 난 놈입니다. 이미 있는 UI들을 정말 사용하기 쉽고 안 헷갈리게 바꾸는 재주가 있지요. 원래 프로그래머 출신은 아닌데 TA하면서 프로그래밍도 좀 배워서 툴 쪽 코드는 뚝딱 만들어 냅니다. 3DS Max안에 새로운 버튼이 등장하면 주로 이놈이 한 짓입니다.

    두번째 TA는 영화업계쪽에서 hair 렌더링 전문하다 온 놈인데 프로그래밍 쪽 보다는 아트쪽 관련 버그나 파이프라인 버그 쪽을 둘러보는데 주로 시간을 보냅니다. 스크립트도 가끔 짜긴 하는데 그건 뭐 그저그렇고... 아티스트들 교육시키거나 문서도 많이 작성하더군요. Havok Cloth 사용할 때도 이놈이 설정은 다 했습니다.

    마지막 한명은 TA 최고대빵인데 프로그래머 출신입니다. 원래부터 그림은 잘 그렸더군요. 이 분은 아주 가끔 쉐이더도 짜시지만... 주로 하시는 일은 새로운 기법을 구현하려 할 때 아티스트와 프로그래머가 둘다 이해할 수 있는 언어와 그림으로 양쪽의 의견을 한군데 모아다가 잘 표현해주심.

    생각해보니 저희는 TA가 쉐이더를 작성하진 않는군요. 그래픽 프로그래머가 다 합니다. (저희 그래픽 프로그래머는 아티스트들하고 대화를 잘해요... 안되는 놈 하나 있었는데 내보냈어요)

    • Favicon of http://gamedevforever.com 핑속 2012.01.30 04:44 신고  댓글주소  수정/삭제

      서로 신뢰할 수 있는 스태프들과 일하는건 정말 신나는 경험일텐데요! 부럽습니다~

    • Favicon of http://gamedevforever.com 김포프 2012.01.30 06:13 신고  댓글주소  수정/삭제

      그 TA 대빵 아저씨가 성격이 또 대쪽이신지라... 정치하거나 이런 애들 못보시거든요.. 그런 분들이 위에서 딱 자리잡고 있으니 그 밑에 있는 사람들도 실력으로 승부하는듯.. ^_^

      파트 대빵 누구냐 따라... 별로 믿을 놈들이 없는 파트들도 있어요. ㅎㅎㅎ 핑속님 팀도 좋을듯 -_-d

    • Favicon of http://gamedevforever.com 대마왕J 2012.01.30 10:12 신고  댓글주소  수정/삭제

      하악하악 대단하네요. 그래도 핑속 스승님이 있으니까 TA들이 맘놓고 일하는 걸꺼라능!!!

    • Favicon of http://gamedevforever.com 핑속 2012.01.30 11:16 신고  댓글주소  수정/삭제

      총재님 이러시면 안됩니다~~

  4. Silverchime 2012.01.31 17:03 신고  댓글주소  수정/삭제  댓글쓰기

    제가 하고싶은 이야기를 시원하게 써주셨네요.

    한떄 제가 다른사람들을 괴롭히나 하고 좌절도 많이 했습니다. 스스로의 존재를 자문해보게 되더군요.
    정말로 힘들고 자괴감이 들곤 했죠. (돕고자 다가섰으나, 결국엔 민폐가되는듯한...) 지금와서 계속 쭈우우욱 드는 생각은
    TA는 여러분을 가르치려드는 사람이 아니에요 여러분을 도와주는 사람입니다- 라고 말하고 싶어요.
    언젠가 이주제로 한번 글을 써봐야겠네요. 글잘봤습니다 감사드려요!

  5. 티케이 2012.01.31 17:16 신고  댓글주소  수정/삭제  댓글쓰기

    글 잘 보았습니다. 가장 현실적인 얘기를 많이 해주셨네요 ㅎㅎ
    그런데 한가지 관점이 더 있다면.. 저도 TA로써 겪는 일인데..

    엔진 TA가 분명히 요즘 시대에선 필요가 되고 있습니다. 특히 비싼 통합 상용화 엔진의 강점이 특정 엔진에 대한 뛰어난 이해도와 툴들을 잘 다루는 요소가 필요해 보였습니다.

    언리얼의 경우 머터리얼/최적화와 같은 경우에 해당하며 아마 일반적인 TA범주를 벗어나 좀더 구체적인 업무의 성향을 띠고 있다고 봅니다.
    저의 경우 위에 언급하신 그 TA인데..^^; 엔진의 성향도 띠고 있죠.
    그리고 엔진쪽 특히 레벨 에디팅을 잘하시는 TA하시는 분의 필요성도 더 분명하게 드러나 보이기도 합니다.

    암튼 좋은 글 잘보고 갑니다.

    • Favicon of http://gamedevforever.com 대마왕J 2012.01.31 17:21 신고  댓글주소  수정/삭제

      그러고 보니 저도 레벨 에디팅과 게임 엔진에 맞는 리소스의 최적화쪽에 일도 하고 있군요. TA 일이 딱 고정된게 아니라 범위가 넓을 수 밖에 없는 것 같습니다.

  6. 우왕 2012.04.18 11:03 신고  댓글주소  수정/삭제  댓글쓰기

    저도 입사한뒤 애니메이션을 함에 있어서 스크립트가 부족해 공부 하고있는데 저도 TA가 될수 있는건가요?ㅎㅎ

  7. 풍림소년 2013.05.11 21:08 신고  댓글주소  수정/삭제  댓글쓰기

    지방대 게임학과 학생인데요....
    열악한 환경속에서 실무에서 뛰시는 분들이랑 우연찬게 얘기할 기회가 주어졌었는데
    TA에 대해서 말해주시더군요... 너무 생소해서 뭔지도 모르고 그냥 아하..그렇구나...
    라고 생각하다가 인터넷 찾아보니 정말 저에게 사막에 단비같은 글이였네요.
    감사합니다!!!
    (혹시 이 글 펌 해가도 될까요?)

  8. 2014.04.15 05:54 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.

    3D 모델러 현재 전공 중인 학생입니다.


    기획 선배분과 함께 이런저런 이야기들을 하면서 3D모델러이며 개발자로써 먼가 좀더 배우고 싶고 사실 코딩에 많은 관심이 있다라던가 이야기를 하며 그게 테크니컬 아티스트라는걸 알게되었는데요.

    3D전공중인데 TA직종도 공부하면서 배우고 싶은데 모델링 공부하면서 일부 엔진이라던가 코딩을 취미 시간이나 여가시간.. 등 배워보는거에 어떻게 생각하시나요?

    또한 그래픽+코딩 이렇게 있는데 둘다 병행이 좋을까요 아니면 그래픽을 먼저 전공을 한다음 같이 공부하는게 좋을까.. 고민이 많습니다.

  9. 2014.04.15 05:54 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.

    3D 모델러 현재 전공 중인 학생입니다.


    기획 선배분과 함께 이런저런 이야기들을 하면서 3D모델러이며 개발자로써 먼가 좀더 배우고 싶고 사실 코딩에 많은 관심이 있다라던가 이야기를 하며 그게 테크니컬 아티스트라는걸 알게되었는데요.

    3D전공중인데 TA직종도 공부하면서 배우고 싶은데 모델링 공부하면서 일부 엔진이라던가 코딩을 취미 시간이나 여가시간.. 등 배워보는거에 어떻게 생각하시나요?

    또한 그래픽+코딩 이렇게 있는데 둘다 병행이 좋을까요 아니면 그래픽을 먼저 전공을 한다음 같이 공부하는게 좋을까.. 고민이 많습니다.

    • 2014.04.15 05:56 신고  댓글주소  수정/삭제

      추가적으로 프로그램에 처음 입문할땐 뭐 부터 해보는게 좋은건가요

      주위에 물어보면 뭐부터 가르쳐 주어야 할지를 모르겠다고 하십니다.

      보통 게임 코딩을 하때 프로그램 언어는 어디까지 공부하면 되는거죠?

  10. 방울 2014.05.27 17:31 신고  댓글주소  수정/삭제  댓글쓰기

    블로그를 운영하는 블로거입니당. 좋은내용 잘 봤습니다!
    사실 TA를 검색해서 여러군데를 보는중에 내용을 보고 퍼가려고했는데 출처가 남겨져있어서 원본문 출처로 오게됐네요 TA에 대해 역할분류 부분만 사용하려고 하는데 괜찮은지 여쭤보고싶습니다! 원문출처와 제가 본 블로그까지 출처는 남겨두겠습니다 괜찮으실까요?

  11. 김영성 2015.11.24 20:51 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다. 공주대 면접 때문에 문항 정리중이었는데 TA가 애매하는 바람에 고생하고있었는데 이렇게 좋은 글이 있는줄 몰랐네요 감사합니다.



티스토리 툴바