Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

게임 디렉팅 튜토리얼

13,330 views

Published on

블루홀 개발자 컨퍼런스, 청강대 특강, 창조경제혁신센터 게임 아카데미 등에서 진행했던 "게임 디렉팅 튜토리얼"의 강의 슬라이드입니다. 3~4년차 게임 개발자와 소규모 게임 개발팀의 리더를 대상으로 하는 커뮤니케이션 노하우에 대한 자료입니다.

Published in: Education
  • Be the first to comment

게임 디렉팅 튜토리얼

  1. 1. 게임 디렉팅 튜토리얼 ⓒ이상균 (http://iyooha.com)
  2. 2. 나는 현재/과거에 디렉터 역할을 해본 적이 있다 나는 현재 디렉터(혹은 그 역할을 하는 사람)와 일하고 있다
  3. 3. 1. 이 강의는 3~4년차 실무 경력자, 혹은 소규모 개발팀에서 디렉 터 역할을 맡은 개발자를 대상으로 준비한 강의입니다. 2. 이 문서에서는 디렉터를 프로듀서와는 완전히 구분된 직무로 보고 설명하고 있습니다. 3. 이 강의는 1시간 30분 정도 걸립니다. 3 일러두기
  4. 4. 발표자 소개 - 이상균 2015-2010 넥슨 <마비노기 영웅전> 크리에이티브 디렉터 2011-2012 아이덴티티 게임즈 액션 MMORPG <Project Rene> 디렉터 2013-2014 블루홀 MMOAOS <Project EXA> 디렉터 2015-2016 블루홀 모바일 PvP 게임 <X AGENCY> PD/디렉터 2016-현재 미공개 프로젝트 PD/디렉터 업력 12년 중, 10년 동안 디렉터로 게임 제작에 참여 4
  5. 5. 디렉터 • 디렉터는 뭘 하는 사람일까요? • 용기 있는 사람 손을 들고 얘기해 봅시다 코지마 히데오 <메탈기어 솔리드> 이은석 <마비노기 영웅전>, <야생의 땅: 듀랑고>
  6. 6. 경영진, 프로듀서, 디렉터 • 경영진 – 회사의 성격과 사업 분야를 결정합니다 – 투자, 융자 등의 방법을 이용하여 사업/개발 비용을 조달합니다 • 프로듀서 – 경영진과 협의하여 프로젝트를 시작, 관리합니다 – 자금, 인력, 시간 등 프로젝트에 필요한 자원을 관리합니다 – 게임이 만들어지게 하는 사람입니다 – 디렉터와는 파트너 관계입니다 • 디렉터 – 게임 방향을 결정하고, 때로 결정을 위임합니다 – 기획/아트/기술 결과물에 대한 책임을 집니다 – 게임을 만드는 사람입니다 – 영화 감독 입장이라고 생각하면 됩니다 6
  7. 7. • 디렉터의 업무는 회사의 성격, 프로젝트의 규모 등에 따라 다릅니다. • 어쨌든 오늘 강의에서는, 게임 개발의 총책임자라는 의미에서 디렉터의 직무를 정의하고 시작합니다. 7
  8. 8. 디렉팅의 본질
  9. 9. 디렉팅의 본질은 뭘까요? 9
  10. 10. 리더십일까요? 디렉터를 따르게 만드는 것 일가요? 10
  11. 11. 설득일까요? 디렉터가 바라는 대로 하게 하는 걸까요? 11
  12. 12. 설명/PT일까요? 그래서 방향성(?)을 명확하게 하는 것일까요? 12
  13. 13. 13 관리일까요? 일이 제대로 돌아가게 하는 것일까요?
  14. 14. 손을 한 번 들어볼까요? 1. 디렉팅의 본질은 리더십이다 2. 디렉팅의 본질은 설득이다 3. 디렉팅의 본질은 설명/PT이다 4. 디렉팅의 본질은 관리이다 14
  15. 15. • 정답이 있는 질문은 아니었습니다 • 4개의 답안 모두 정답이 될 수 있습니다 • 디렉터 자신이 어떻게 생각하느냐에 달렸습니다 … 하지만 저는 오늘, 15
  16. 16. 16 디렉팅의 본질이, 결정이라는 관점에서 이야기를 하려고 합니다
  17. 17. 결정 • 게임 개발에 참여하는 모든 사람들은 결정을 합니다 – 모아찍기 스킬의 동작 반경은 전방 90도, 반경 1.6m로 해야겠다  전투 기획자의 결정 – 우리는 TAB 1개를 8 space로 해야겠다  TD의 결정 – 관리비용 최소화를 위해 이번 프로젝트는 외주를 늘려야겠다  PD의 결정 – 잘 돌아가는 온라인 게임을 접고 모바일 스튜디오로 전환해야겠다  경영진의 결정 • 디렉팅의 본질이 결정이라면, 그건 어떤 결정일까요? • 결정은 어떻게 하는 것일까요? 17
  18. 18. 디렉팅 시스템
  19. 19. 먼저 말씀드릴 것 • 디렉팅 시스템이 정답이라고 주장하는 것이 아닙니다 • 세상에 완벽한 시스템은 없습니다 – 팀의 목표, 규모, 구성, 문화 등에 잘 맞는 시스템이 있습니다 – 가장 적합하다 판단하는 시스템을 발굴해야 합니다 19
  20. 20. 북미 프로듀서 기반 시스템 • 영화 제작 시스템을 게임에 가져온 시도 – 투자유치, 스케줄 관리, 채용 등 관리 이슈를 프로듀서 그룹이 담당 – 개발 디렉터와 개발팀은 개발만 담당 (영화 감독을 생각하면 됨) – 프로듀서에게 개발팀 인사권이 없는 경우가 많음 • 영화와 마찬가지로, 개발 비용/일정 초과 이슈에 두 라인이 민감 20 프로듀서 크리에이티브 디렉터 개발 디렉터 개발팀 어시스턴트 프로듀서 그룹
  21. 21. 일본 디렉터 기반 시스템 • 디렉터 1인 독재 시스템 – 비디오 게임 태동기 때 부터 시작된 시스템 – 게임 디자인은 디렉터가 모두 담당 – 계획팀은 게임 디자이너(X) 플래너(O) – 계획팀은 주로 일정, 리소스 관리, 버그 트래킹 등을 담당 • 디렉터의 재능이 게임의 흥행을 크게 좌우 • 개발 규모가 커지면 디렉터가 병목이 됨  Massive Development 이후 일본 게임이 쇠락한 이유 중 하나 21 디렉터 계획팀 (Planner) 테크팀 아트팀
  22. 22. 한국 삼팀장 시스템 • 기획/테크/아트를 독립 영역으로 – 기획팀이 게임 디자인을 제안하고, 프로듀서(혹은 삼팀장이)가 승인하는 형식 – 50+명 대규모 개발 시스템에 적합 – 기획/테크/아트가 각자의 영역에서 최선의 결과를 낼 수 있다면 베스트 – 각 팀장과 프로듀서의 역량이 평범하다면 평범한 결과가 나오기 쉬움 • 모든 한국 개발팀이 채용하고 있지는 않음 22 프로듀서 기획팀 테크팀 아트팀
  23. 23. 이렇듯 모든 개발 시스템에 디렉터 포지션이 있는 것은 아님 프로젝트의 목표, 규모, 문화 등에 맞는 시스템을 채용하는 것이 중요 오늘 하는 얘기는 개발팀이 시도할 수 있는 수 많은 시스템 중 하나인, 디렉팅 시스템과 디렉팅에 대한 얘기 23
  24. 24. 디렉팅 시스템(예) • 프로듀서는 게임 외적인 일에 집중 – 경영진 커뮤니케이션, 기대치/일정 관리, 자금과 인원 조달, 팀 멘탈 관리 • 디렉터는 게임 디자인과 개발 전권을 가짐 – 초반엔 크리에이티브 디렉터를 겸직(같은 사람) – 프로젝트 규모에 따라서는 프로듀서 = 디렉터 = 크리에이티브 디렉터 – 프로젝트 규모가 커지면(대략 30+) 위임의 기술이 필요해진다 24 디렉터 크리에이티브 디렉터 테크니컬 디렉터 아트 디렉터 프로듀서
  25. 25. • 디렉팅 시스템에서 디렉터는, – 게임 디자인과 개발 전권을 가진다 • 다시 말하면, – 게임 디자인과 개발에 관련된 전권이 한 사람에게 있는 시스템 • 이 문장을 기술적으로 정의하면, – 한 사람이 모든 태스크를 발행하고, – 한 사람이 모든 태스크에 대해 피드백/컨펌 하는 것에 – 나머지 멤버들이 동의한 시스템이라는 뜻 25 책임과 권한
  26. 26. 디렉팅은 시스템이 하는 것 • 디렉팅 시스템에 대한 환상 – 뛰어난 누군가 나타나셔서 우리를 이끌어 주실거야(X) – 디렉터는 상급자(X) – 우리 중에 “결정”의 역할을 맡기로 한 사람 (O) • 디렉터는 시스템이 하는 것 – 한 사람에게 태스크 발행/피드백/컨펌 권한이 있다는 것을, – 모두가 동의하지 않는다면 디렉팅 시스템이 동작하지 않음 – 디렉팅은 사람이 하는 게 아니라 시스템이 하는 것 • 디렉터는 자연발생하지 않음 – 디렉팅은 사람이 아니라 시스템이 하는 것이므로, – 디렉팅 시스템을 경험하지 못한 조직에서는 디렉터가 나오기 힘듦 26
  27. 27. 어쨌든 이 PT 제목은, 이니까… 이후 내용은 여러분이 “이제 막 디렉터가” 됐다고 가정합니다 27
  28. 28. • 기술적으로 디렉터의 작업을 정의하면, – 태스크를 발행하고, – 진행된 작업에 대해 피드백을 하고, – 작업물이나 결정 필요 사안에 대해 결정(컨펌)을 한다 • 따라서 디렉터 일을 잘 하려면, – 태스크를 잘 발행하고, – 좋은 피드백을 하고, – 좋은 결정을 내리면 되겠네요 … 하나씩 차례대로 살펴봅시다(대개 말보다 실천이 어렵습니다만) 28
  29. 29. 태스크를 발행하는 법
  30. 30. 먼저, 약간 슬픈 가상의 대화부터… 30
  31. 31. 31 이번 아이템 시스템 개편 담당자는 B씨입니다. 전권을 위임할테니 한번 잘 해 보세요. 디렉터 A 이 안은 우리 성장 밸런스와 위배되는데… 다른 안 제안해 보세요 디렉터 A 개편된 아이템 시스템 초안입니다. 기획자 B 그럼 개편 방향을 좀 알려주세요. 방향만 알면 금방 할 수 있습니다. 기획자 B
  32. 32. • 이런 불만을 가진 멤버가 있나요? – 디렉터는 전권을 줬다고 생각하지만, – 실제로 B는 기획안을 디렉터(혹은 조직장들)에게 승인을 받아야 함 – 기획자 B에겐 실제로 책임만 있고 권한은 없는걸까? 32 우리 조직은 책임은 주면서, 권한은 안주는 것 같아 기획자 B
  33. 33. • 모든 부대에는 “전시 행동 강령”이라는게 있다 – 전시에 특별한 지시 없이도 군대가 일사분란하게 움직이도록 – 군대 다녀온 분들은 다 알 것 • 발표자는 미8군 한국군지원단(카투사) 신병계 – 모든 문서를 파기하고, 하드디스크를 뽑아 들고, – 용산 고등학교 운동장에서 헬기를 타는 것이 전시 행동 강령 33
  34. 34. • 그런데 만약, • 폭격으로 용산 고등학교가 사라졌다면? 34
  35. 35. • 지휘관의 의도(Commander’s Intent) – 1980년대 미 육군사관학교 톰 콜티츠 대령이 만든 개념 – 대부분의 전시 행동 강령과 작전 계획이, 전투가 시작됨과 동시에 무용지물이 된다는 걸 깨닫고 대안으로서 제시한 개념 • 동작 원리 – 모든 명령서의 최 상단에 의도를 짧게 서술 – 강령보다 의도 중심 – “하드디스크를 들고 용산 고등학교로 가라”(X) – “최신 카투사 신병 자료를 캠프 헨리의 작전 본부까지 옮겨라”(O) 35
  36. 36. • 지휘관의 의도를 몰랐다면, – 파괴된 용산 고등학교 주변을 배회했을 지도 • 지휘관의 의도를 알았다면, – 자동차를 타든, 버스를 타든, 걸어서든, – 캠프 헨리까지 가려고 했을 것이다. 36 ⓒGde-Fon.com
  37. 37. • 의도를 가진 지시에는 반드시 왜냐하면이 있다 37 – 모든 문서를 파기하고, 하드디스크를 뽑아 들고, – 용산 고등학교 운동장에서 헬기를 타라 지시 – 왜냐하면, 최신 카투사 신병 자료를 캠프 헨리까지 옮겨야 하기 때문이다 의도
  38. 38. 38 이번 아이템 시스템 개편 담당자는 B씨입니다. 전권을 위임할테니 한번 잘 해 보세요. 디렉터 A 이 안은 우리 성장 밸런스와 위배되는데… 다른 안 제안해 보세요 디렉터 A 개편된 아이템 시스템 초안입니다. 기획자 B 그럼 개편 방향을 좀 알려주세요. 방향만 알면 금방 할 수 있습니다. 기획자 B
  39. 39. • 실은 권한 유무가 중요한 것이 아님 – 타 팀과 의견 조율에 어려움을 겪는다면 TF를 만들면 됨 – 기획자 B는 의도를 전달받지 못했기 때문에 헤매는 것 • 디렉터가 의도를 전달하지 않은(못한) 것이 근본적인 문제 – 의도를 전달하지 않으면 멤버는 이 태스크가 “내 마음을 맞춰봐”와 같다고 생각한다 39 이번 아이템 시스템 개편 담당자는 B씨입니다. 랜덤 옵션 이나 개조 기능 같은 걸 넣어보죠. 왜냐하면 파밍 요소가 더 필요하기 때문입니다. 디렉터 A
  40. 40. 디렉터의 업무 중 가장 중요한 것 의도 전달 40
  41. 41. • 지금까지 디렉터가 이런 지시를 해왔다면, – “시나리오는 A씨에게 다 맡길께요. 잘 해 주세요.” – “우리의 전투는 클래시 블레이드와 똑같습니다.” • 디렉터는 의도를 전달하고 있지 않았던 것 – 디렉터라면, 항상 스스로에게 물어봅시다 – 나는 이 태스크를 발행하며 “왜냐하면”을 썼는가? 41
  42. 42. • 개발팀에 발생하는 문제 중 적지 않은 것들이, – 디렉터가 의도를 갖고 있지 않거나, – 갖고 있는 의도를 잘 전달하지 못하기 때문에 생깁니다 • 여러분이 디렉터가 되었을 때 꼭 기억해 주세요 42
  43. 43. 의도 전달에 대해서 열심히 쓴 PT 둘 다 제목과는 달리 의도 전달에 대한 PT 둘 다 웹에 공유되어 있습니다(버전은 좀 다를지도) 43
  44. 44. 의도를 전달하는게, 그렇게, 정말, 중요한 건가요? 44
  45. 45. • 디렉터 Director 라는 포지션 명칭은 영화에서 왔다 – 영화는 수백년이 된 산업 – 작업과 업무, 직무 표준화가 많이 진행되어 왔다 • 우리가 이 영화에서 키스신을 찍는다 하자 – 감독이 할 말은 “키스씬 찍습니다, 알아서 잘 해주세요” 일까? 45
  46. 46. • 물론 어떤 최고의 배우들은 별 주문 없이도 최고를 해낼지도 – 우리 업계도 마찬가지, 최고의 베테랑들은 별 주문 없이도 최고를 해낸다 – 만약 그렇지 않다면 발연기를 해서라도 의도를 전달해야 하는 것이 디렉터 • 디렉터의 업무에서 의도 전달은 빠질 수 없다 46 드디어
  47. 47. 때로는 의도가 없는 것도 의도 • 모든 작업이 중요하지는 않다 – 어떤 작업은 정말 의도가 없을 수도 있다 – 그럴 때는, • 의도가 없다는 것을 밝히는 것 또한 의도를 전달하는 것 • 태스크를 발행할 때 우선순위를 명시하는 것을 습관화 할 것 – 구두 지시도 마찬가지 47 (별로 의도를 얘기해줄게 없으니) 알아서 잘 해 주세요. 디렉터 A 이 작업은 우선 순위는 높지 않은 작업입니다. 얼른 끝내고 다른 부분에 힘을 싣죠. 디렉터 A
  48. 48. • 자, 의도 전달이 중요한 것은 알았습니다. • 태스크를 발행할 때 또 중요한 것은 없을까요? 48
  49. 49. UI Framework 을 업그레이드를 해서 기존 UI들을 전부 수정해야 하는 일이 생겼습니다 49
  50. 50. 50 이번에 프레임웍 마이그레이션 하려면 어떤 작업들 필요하지? 디렉터 A 새로 바뀐 UI들 동작 확인하고, 동작이 달라진 것들은 재기획 해야 합니다. 기획자 B 코드 작업은 금방 될 것 같습니다. 프로그래머 D 새 프레임웍에 안 맞는 리소스들 재작업하고 제대로 나오나 확인해야 해요 UI 디자이너 C
  51. 51. 51 OK, 별 문제 없겠네. 다다음주까지 끝마쳐 봅시다. 회의 끝내죠. 디렉터 A
  52. 52. DRI(Directly Responsible Individual) • 애플이 만든 기업 문화 • DRI = 그 업무를 직접 책임지는 “단 한 사람” – “아이패드 개발” 처럼 큰 태스크 부터, – “사옥 앞 스프링쿨러 분사 방향 결정” 처럼 작은 태스크까지, – 1~2명의 실행 담당자가 있다 52
  53. 53. • 태스크를 발행할 때, 가능하면 1명에게 맡긴다 – 특히 여러 사람(여러 직군)이 관련된 태스크일 수록 담당은 1명 – 여러 직군(여러 팀)으로 이루어진 그룹에 책임을 맡기지 말 것 – Deadlock 문제 • 조직 규모가 커지면, 이런 작업들을 대개 PM이 담당하게 됨 – 너무 커지기 전 까지는, 담당자를 지정하는 것 만으로도 높은 효과 53 OK, 별 문제 없겠네. B씨가 이 작업 드라이브 해주세요. 다다음주까지 끝마쳐 봅시다. 회의 끝내죠. 디렉터 A
  54. 54. 요약 – 태스크를 발행하는 법 • 의도를 전달하자 – 의도 전달은 디렉터의 핵심 업무 – “왜냐하면”이 포함되었는지 살펴보는 것이 포인트 • 태스크는 1명에게 발행 – 태스크의 규모와 상관 없이, 담당자는 1~2명으로 최소화 – 특히 여러 직군이 연관된 경우 – Deadlock 등의 커뮤니케이션 문제를 줄일 수 있다 54
  55. 55. 좋은 결정을 하는 법
  56. 56. 마지막에 말하자 • 대개 디렉터가 좋은 아이디어를 낸다 – 디렉터가 게임 디자인적으로 우수하기 때문이라기 보다, – 디렉터가 멤버 중 그 게임에 대해 가장 오래 고민하기 때문 56
  57. 57. • 그러나 디렉터가 먼저 말을 해 버리면(의견을 내 버리면), – 회의가 거기에서 끝날 가능성이 높다 – 상급자의 의견을 반박하기 어렵거니와, – 실제로 디렉터의 의견보다 좋은 의견을 내기도 쉽지 않음 – 그러나 이런 회의가 몇 번 계속되면, 멤버들을 입을 닫는다 • 마지막에 말하자 – 더 이상 좋은 의견이 나오지 않는다면, 그 때 말한다 • 만약 본인 생각보다 더 좋은 아이디어가 나온다면, – 본래 가지고 있었던 생각은 말하지 않는 것이 좋을 때도 있다 57
  58. 58. • 리더(회의 주관자)가 마지막에 말해야 한다는 건 사실 다들 앎 – 웬만한 리더십 책에 다 그렇게 쓰여 있다 – 실천이 어려운 것은, 침묵 내성 때문 – 디렉터 자신이, 회의가 침묵으로 일관되는 것을 견디기 어려워 함 • 그럴 땐 한 사람씩 의견을 물어보자 – 언제나 유효한 방법 – 한 명만 입을 열면 의외로 쉽게 풀린다 58
  59. 59. 콜린 파월의 40-70 • 정보가 40 미만일 때 내리는 결정은 도박 • 하지만 정보가 100일때 내리는 결정은 결정이 아니다 – 자명한 결정은 결정이 아니라 합리적인 선택임 • 언제 결정을 내리는가가 중요 59 콜린 파월, 전 미 국무장관 정보가 40 미만이면 기다려라. 그러나 70이 되기 전에 결정을 해야 한다.
  60. 60. • 회의 막판, 기획자가 뜬금 없이 아이디어를 던졌다 – 그런데 이 아이디어가 여러 문제를 관통하는 핵심 해결책이라면? – 이 아이디어를 채택할 것인가? – 아니면 역시 결정한 대로 B안을 선택할 것인가? • 어느쪽이든 잘못된 판단은 아닐 것 60 역시 A안과 B안 중 B안이 좋겠습니다. 이렇게 결정하죠. 디렉터 A 저 디렉터님, 혹시 이렇게 하면 어떨까요…? 기획자 D
  61. 61. • A안을 선택하려고 했던 당시, 정보가 70에 가까웠다 • 그러나 기획자 D의 아이디어가 나온 순간 정보는 다시 20 – 판단하기 위해 시간이 필요하다 – 이 때, 직감적으로 D의 아이디어를 선택하면 20에서 선택하는 것 • 결정을 미루는 것 또한 결정의 기술 – 왜 이 결정을 미루는지 스스로 알고, (멤버들에게도 알리고) – 언제까지 이 결정을 하겠다는 결정을 내리면 됨 61 내일 오후까지 결정하겠습니다. 결정된 안은 컨퍼런스툴로 공지할께요. 디렉터 A
  62. 62. 잘못된 결정의 예 - 다수결 62 A, B, C안 중에서 의견 주세요. 디렉터 A A안은 이런 점이 안좋네요. B안과 C안 중에 고르는게 어떨까요? 기획자 D 하지만 B안에는 이런 문제가 있습니다. 역시 C가 어떨까요? 기획자 E
  63. 63. 다수결로 결정하면 안되는 이유 • 장점이 많은 안 보다 약점이 적은 안을 뽑게 된다 – 디렉터가 방어적 토론을 기피하는 경우 – 약점이 적은 안 = 평범한 안 – Winner Takes All 인 시장에, 평범한 게임이 어떻게 될까? • 결정에 대한 책임 소재가 불분명해진다 – 모두가 결정했기 때문에 차후 문제 발생시 의사 결정권자가 책임을 회피할 수 있다 – 디렉터는 결정의 스페셜리스트 – 본인의 결정에 책임을 져야 함 63
  64. 64. 여기까지 듣고 나면 좋은 결정을 하는 방법이란, 1. 다른 멤버들의 의견을 끝까지 듣고, – 디렉터는 마지막에 의견을 내고, 2. 디렉터 마음 대로 결정한다 – 정보가 40~70 사이인 타이밍에, – 다수결이 아닌 디렉터가 본인의 의사 대로 의사 결정을 한다 이렇게 하기 위해서는 전제가 하나 필요하다 64
  65. 65. 토론하고, 따르는 문화 • 토론하는 문화 – 게임 디자인, 밸런스, 아트 결과물 등을 놓고 토론하는 문화 – 멤버라면 누구든 의견을 내는데 거리낌 없어야 함 – 아트 결과물을 놓고 토론하는 기술에 대해서는 다음 기회에 • 따르는 문화(Fellowship) – 일단 의사 결정권자의 결정이 내려지면 따르는 문화 – “다소 단점이 있더라도 이 결정이 최선이라면, 해 보자” • 토론하는 문화 쪽이 훨씬 중요하다 – 결정될 후보안에 대해 비판할 기회가 먼저 있어야 하기 때문 – 드랍된 후보안에 대해 담배터에서 2차전이 시작되면 이미 에러 65
  66. 66. 요약 – 좋은 결정을 하는 법 • 디렉터가 마지막에 말한다 – 멤버들이 의견을 말하는 문화를 만들어야 • 디렉터가 결정한다 – 정보가 40~70일 때 결정한다 – 때로는 결정을 미루는 것도 기술 – 이 경우 언제까지 결정하겠다는 결정을 내린다 • 다수결로 결정하지 않는다 – 강점이 많은 안 보다 약점이 적은 안을 선택하게 됨 – 디렉터 스스로 선택에 책임을 진다 • 토론하고 따르는 팀 문화가 필요 66
  67. 67. 좋은 피드백을 하는 법 67
  68. 68. • 디렉터의 업무를 셋으로 나누면, – 태스크를 발행하고, – 피드백을 하고, – 결정(컨펌)을 하는 것 으로 나눌 수 있다고 했다. 68
  69. 69. 디렉팅이란 (1) 69 현재 상태를 알고,A 현재 상태
  70. 70. 디렉팅이란 (2) 70 현재 상태를 알고, 바라는 이상적인 상태를 알고, A 현재 상태 G 바라는 상태 (이상적인 상태)
  71. 71. 디렉팅이란 (3) 71 현재 상태를 알고, 바라는 이상적인 상태를 알고, 그 차이를 설명하는 행위 이걸로 될까요? A 현재 상태 G 바라는 상태 (이상적인 상태)
  72. 72. 72 A 현재 상태 G 바라는 상태 (이상적인 상태) 디렉팅 (디렉터의 설명)
  73. 73. 73 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 후, 디렉터가 바란다고 멤버가 이해한 상태 디렉팅 (디렉터의 설명)
  74. 74. 74 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 후, 디렉터가 바란다고 멤버가 이해한 상태 디렉팅 (디렉터의 설명) 멤버의 작업
  75. 75. 75 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 후, 디렉터가 바란다고 멤버가 이해한 상태 디렉팅 (디렉터의 설명) C1 멤버의 작업 중간보고
  76. 76. 76 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 (디렉터의 설명) C1 멤버의 작업 중간보고 디렉팅 (디렉터의 설명)
  77. 77. 77 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 (디렉터의 설명) C1 중간보고 디렉팅 (디렉터의 설명) B2 피드백 후 디렉터가 바란다고 멤버가 이해한 상태
  78. 78. 78 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 (디렉터의 설명) C1 중간보고 디렉팅 (디렉터의 설명) B2 피드백 후 디렉터가 바란다고 멤버가 이해한 상태 멤버의 작업
  79. 79. 79 C2 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 (디렉터의 설명) C1 중간보고 디렉팅 (디렉터의 설명) B2 피드백 후 디렉터가 바란다고 멤버가 이해한 상태 멤버의 작업 중간보고
  80. 80. 80 C2 A 현재 상태 G 바라는 상태 (이상적인 상태) B1 디렉팅 (디렉터의 설명) C1 중간보고 디렉팅 (디렉터의 설명) B2 피드백 후 디렉터가 바란다고 멤버가 이해한 상태 최종 결과물 C3
  81. 81. 이 그림의 교훈은 무엇? 목표에 대한 생각의 갭을 줄여 가는 것이 중요하다(△) 피드백을 할 때 마다 갈 수 있는 거리는 줄어든다(O) 81 A 현재 상태 G 바라는 상태 (이상적인 상태) C1 C2 C3 B1 디렉터가 바란다고 멤버가 이해한 상태 B2 피드백 후 디렉터가 바란다고 멤버가 이해한 상태
  82. 82. 큰 것 부터 피드백 하자 • 피드백 횟수는 정해져 있음 – 중간 보고를 거듭하면서 작업 완성도는 오를 수 밖에 없다 – 그게 아트 결과물이든 게임 디자인 문서든… • 첫 피드백은 디테일(X), 구조와 설계에 대한 것(O) – 초반에 디테일에 대한 피드백을 하면 큰 그림을 놓치게 됨 – 이후엔 피드백으로 갈 수 있는 거리가 줄어든다 – 결과적으로는 후반엔 작업을 돌이킬 수 없게 된다 – 디렉터가 열성적으로 피드백할 수록 문제가 생기는 게 아이러니 • “처음 부터 다시 해야 해요” – 이 대답은 대개 이런 경우에 나온다 – 후반에, 갈 수 없는 거리를 가라고 요청 받았기 때문 – 디렉터가 경험이 부족할 때, 전체에 대한 리테이크가 많을 수 밖에 없는 이유 82
  83. 83. 그래서 입기획(입피드백)을 하면 안됨 • 중요한 피드백일 수록 문서로 한다 – 문서가 아니면 컨퍼런스 툴이라도 이용 – 디렉터와 멤버에겐 정보 차이가 있고, 말로 한 피드백은 서로 다르게 해석할 가능성이 생긴다 • 입피드백은 손발을 맞춘지 어느 정도 시간이 된 후 부터 • 피드백을 할 때도 의도를 이용 – 피드백도 태스크 발행과 같은 행위다 – 피드백을 할 때도 의도를 전달하자 83
  84. 84. 피드백의 기술(1) • 피드백은 고객 입장에서 – 초보 디렉터는, “나”의 관점에서 대개 피드백을 한다 – 그렇게 되면 작업자는 “고객”이 원하는 결과물을 만들기 위해 일하는게 아니 라, “디렉터”의 취향을 맞추기 위해 일하는 느낌 • 이렇게 가치 중립적인 표현들을 고르는 것이 좋다 84 전체적으로 비슷한 컬러가 반복되는 경향이 있네요. 내가 원한 건 이게 아닌데… 디렉터 A 같은 컬러를 반복하는 것 보다, 난색과 한색이 번갈아 나오는게 유저들 흥미를 끌기 좋지 않을까요? 디렉터 A
  85. 85. 피드백의 기술(2) • 여러가지로 해석할 수 있는 표현을 쓰지 않는다 – 이것도 디렉터가 초보일 때 많이 범하는 실수 – 자신이 알고 있는 것을 상대도 알고 있다 생각한다 • 최대한 명확하게, 다른 의미로 해석될 가능성이 적은 표현으로 85 왠지 느낌이 좀 붕 뜨네요. 쨍한 느낌을 좀 더 넣는게 어떨까요? 디렉터 A 캐릭터와 배경이 분리된 느낌이 강하네요. 포그레벨을 낮추고, 배경 컨트라스트를 올려 봅시다. 디렉터 A
  86. 86. 피드백의 기술(3) • 피드백은 평가(X) 대안제시(O) – 디렉터는 어떻게 하면 원하는 지점까지 도달할 수 있는 아는 사람 – 따라서 대안을 제시하는 것이 디렉터의 역할이다 – (제시할 수 없다면 디렉터 준비가 안된 것) 86 왠지 액션감이 좀 부족하네… 타격감이 좀 더 올라갔으면 좋겠는데? 디렉터 A 피격 모션에 불릿타임을 넣어 봅시다. 피격 사운드를 뒤로 2~3 프레임 밀어 보세요. 디렉터 A
  87. 87. 요약 • 큰 것 부터 피드백 하자 – 피드백은 디렉팅의 핵심 기술 – 작업 초반에 디테일에 대해 피드백하면, 후반엔 돌이킬 수 없게 됨 – 큰 것 부터, 큰 방향부터 맞춰야 함 • 입기획을 하지 말자 • 피드백의 기술 – 고객의 입장에서, – 명확한 표현으로, – 평가(X) 대안을 제시한다(O) 87
  88. 88. 그 밖에 작은 것들 88
  89. 89. • 우선 순위 관리 – 태스크 발행과 더불어 디렉터의 고유 작업 – 아무리 바빠도 S급 태스크는 디렉터만 발행할 수 있어야 함 – 한번 발행한 태스크의 우선 순위는 영원하지 않다 – 빌드의 목표, 상태에 따라 우선 순위가 지속적으로 바뀜 • 태스크의 크기에 따라 전달 방법을 다르게 – 중급 규모 태스크: 문서와 구두로 동시에 – 작은(QA, 폴리싱) 태스크: 태스크 관리 툴로만 – 투입 시간 대비 효용 높은 수단을 찾아야 89
  90. 90. • 툴 우선 순위를 높게 – 툴: 디렉터가 직접 사용할 가능성이 낮은 물건 – 쓰지 않으니 눈에 잘 보이지 않는다 – 눈에 보이면 관심이 없어진다 (우선 순위가 계속 낮아짐) – 디렉터가 가능하면 직접 툴을 써보고, 시간 날 때마다 개선 우선 순위를 높게 • 디렉터가 밸런스 담당자여야 한다 – 따로 밸런스 담당이 있다면, “쉽다/어렵다”의 최종 의사 결정자라도 – 밸런스에 대한 책임이 디렉터에게 없다면, 밸런스 담당자는 아주 쉽게 모든 문제의 희생양이 된다 90
  91. 91. • 설명할 수 없는 것은 꼭 설명하려고 하지 않아도 된다 – 디렉터 일을 하다보면 가끔 “어쩐지 이걸 꼭 선택하고 싶다” 할 때가 생긴다 – 논리적으로 설명할 수 없는 경우도 있음 – 이럴 땐 억지로 설명하려고 하지 않는 편이 좋다 – 논리적으로 설명하려고 할 수록 억지가 됨  역효과 – 그럴 땐 그냥 “이렇게 하자. 설명은 못하지만 나를 믿어다오” – 생각보다 멤버들은 디렉터를 신뢰한다 – 디렉터의 일관된 취향도 게임의 경쟁력 중 하나다 91
  92. 92. 디렉터가 되는 방법 92
  93. 93. • 일반론이 아니라 개인적인 의견입니다 • 개발 디렉터에 한정된 조언입니다 – 라이브 디렉터는 또 다른 얘기 … 게다가 제가 이런 얘기를 해도 되는지 모르겠습 93
  94. 94. (개발) 디렉터가 될 기회 • 경영진의 입장 – 도전해 볼 만한 시장 상황일 때, – 준비된 프로젝트를, – 그 프로젝트를 해 낼 역량이 되는 사람이 지원하면 • 도전해 볼 만한 시장 상황 – 프로듀서의 영역 – 시장에 대한 이해와 직관은 디렉터의 필수 소양은 아님 – 하지만 모바일 프로젝트는 프로듀서 = 디렉터인 경향도 • 나머지 두가지를 준비해야 한다 – 준비된 프로젝트 – 그 프로젝트를 해 낼 역량 94
  95. 95. 준비된 프로젝트 • 사고 실험(thought experiment, 思考實驗) – 머릿속에서 생각으로 진행하는 실험. 실험에 필요한 장치와 조건을 단순하게 가정한 후 이론을 바탕으로 일어날 현상을 예측한다. 실제 로 만들 수 없는 장치나 조건을 가지고 실험할 수 있다. [두산백과] – 갈릴레이, 아인슈타인등의 과학자들이 사용 • 습관적인 게임 사고 실험 – 만들어지지 않은 게임을 머릿속에서 계속 플레이 해보는 것 – 기본 규칙, 플레이 동기 위주 – 기회될 때 마다 습관적으로 게임을 꺼내서 해봐야 한다 – 많게는 10여개, 적게는 2~3개 정도 – 2~3개는 당장 문서화할 수 있는 수준으로 플레이 해봐야 95
  96. 96. 디렉터를 지망한다면, 언제든 꺼내 만들 수 있는 게임 2~3개 정도는 있어야 기회가 온다 96 누가 나서서 이런 프로젝트 해주면 좋겠는데… 경영진 A 지금부터 고민 해보겠습니다. 디렉터 후보 B 조건에 맞는 프로젝트를 생각해 둔 것이 이미 있습니다. 이런 프로젝트는 어떠십니까? 디렉터 후보 C
  97. 97. 그 프로젝트를 해 낼 역량 • 기본적으로는 T자형 역량 커버리지가 필요 – 본인의 분야에서 탁월한 성취를 보이고, – 나머지 분야의 역량도 조금씩은 갖춰야 함 97 개발 전체 역량자신의 전문 분야 전체 영역에 대한 얕은 지식/경험
  98. 98. 게임 디자인 역량을 키우는 법 (1/2) • 일단 게임을 많이 해봐야 한다 – 게임도 T자형으로 해봐야 한다 – 한 게임을 깊게 파면, 게임 디자인의 바닥을 볼 수 있고, – 여러 게임을 여러 플랫폼에서 하면 세계 트렌드를 읽을 수 있음 • 매년 모든 플랫폼의 GOTY급 게임들은 다 파보는 것을 목표로 게임 디자이너 출신이 아니어도, 디렉터 직무 수행을 위해서는 게임 디자인 역량은 필수적 98 콘솔/싱글플레이 모바일 온라인/멀티플레이
  99. 99. 게임 디자인 역량을 키우는 법 (2/2) • 직접 게임을 만들어 본다 – 옆에서 보는 게임 디자인과, – 실무적 게임 디자인은 매우 다름 – 게임 디자인의 핵심은 문제 정의와 문제 해결 – 경험해 보기 위해서는 직접 게임을 만들어 보는 것이 가장 좋다 – 완성하지 못해도 반드시 얻는 것이 있음 • 게임을 만들 수단은 얼마든지 있음 Unity 3D Game Maker: Studio Steam Workshop (Portal Level Design Tool)
  100. 100. 프로그래밍 역량을 키우는 법 • 디렉터에게 필요한 프로그래밍 역량 – 프로그램을 짜는 능력 (X) – 아키텍쳐를 설계하는 능력 (X) – 개발 비용을 어림 짐작하는 능력 (O) – 프로그래머의 안돼요를 이해하는 능력 (O) • 유효하지 않은 방법 – C언어를 공부한다 (X) • 유효한 방법 – 기술 용어가 나올 때 마다 개념을 프로그래머에게 묻는다 – 트랜잭션, 홀펀칭, 패킷, 암호화, 싱크/어씽크, 분산DB, 스캘러빌리티… – 개념 자체는 어렵지 않다. 누구나 듣고 이해할 수 있음 – 가능하면 자료 구조에 대한 기초 지식은 갖고 있으면 좋다 100
  101. 101. 아트 역량을 키우는 법 (1/3) • 마찬가지로, 디렉터에게 필요한 아트 역량은, – 직접 그리는 능력 (X) • 눈 – 높은 안목과 심미안 – 뛰어난 것을 알아볼 수 있다 – 무엇이 그 차이를 만드는지 안다 – As-is 와 to-be 사이의 차이점을 아는 것 – 쉽게 키워지지 않음, 좋은 아트 결과물을 많이 접하는 수 밖에 • 손 – 대안 제시와 표현 – 능력이 있다면 좋다 – 그러나 손이 뛰어나도 자기 눈 이상의 것을 만들지는 못함 101
  102. 102. 아트 역량을 키우는 법 - 사진 (2/3) • 처음 디렉터가 되었을 때, 아티스트 동료가 추천한 방법 – 3D 게임 제작에 크게 도움이 됨 – 구도, 시각 디자인 관련 지식, 카메라 관련 용어 등 102
  103. 103. 아트 역량을 키우는 방법 – 구걸 (3/3) 대단한 아티스트들의 통찰 있는 조언은 몇 마디만 들어도 배우는 바가 많다 새로운 스타일을 만들겠다 AD가 마음을 먹으면 아트 는 미궁에 빠집니다. 진부한 아트에는 그 이유가 있는거 예요. 진부함에는 ‘상업적으 로 먹히는 것’이라는 뜻도 함께 있어요. 캐릭터의 아름다움이란 실 은 밸런스에서 부터 시작한 다. 아무리 벗겨 놓아도 불 가능한 자세로 서 있는 캐 릭터는 그래서 아름답지 않 아 보이지. 폰트는 개당 2M밖에 되지 않지만, 타이포그래피의 아 트적 활용도는 무척 높아요. 장담컨대 폰트를 도입하시 면 아트가 2M어치 보다 훨 신 아름다워 질겁니다. 아트 디렉팅은 게임 디렉팅 하고 달라요. 방향을 제시 하는 게 아니라 영감을 불 어 넣는 거예요. 그 아티스 트가 최고의 실력을 발휘하 도록 말이죠. 103 김형준 (아이온 AD) 황철웅 (리니지2 AD) 이찬수 (테라 TAD) 손광재 (블레이드2 AD)
  104. 104. 정말 이렇게 하면 디렉터 역량을 다 채울 수 있나요? 프로그래밍은 용어만 알고, 아트는 사진 공부만 하면 됨? 104
  105. 105. 파트너 멤버 • 디렉터는 초인은 아니다 – 기술, 미술, 기획 모든 면에서 A급 이상의 인재가 되긴 어려움 – 없는 것은 아님, 이 업계엔 노력하는 천재가 많다 • 따라서 파트너 멤버가 필요 – 나와 전혀 다른 역량을 가진 다른 멤버 – 언젠가 나와 게임을 만들고 싶어하는 다른 멤버 • 리더십-펠로십으로 이뤄진 사이가 아님 – 이런 멤버와는 대개 파트너십으로 이루어져 있다 – 서로가 필요하기 때문에 강하게 유대를 이룸 – 수년간 동반 성장한다 • 언젠가 디렉터가 되고 싶다면, 파트너 멤버를 찾는 것이 급선무 105
  106. 106. 그 외 • 게임은 공학적 예술품 + 상품 – 예술품을 만드는 것과 그것을 파는 것은 전혀 다른 얘기 – 예술가는 스스로 자기 물건을 팔기 어렵다 – 투자자에게 물건을 팔아줄 프로듀서가 필요 • 경험이 없는 디렉터는 자신을 보호해줄 프로듀서를 찾을 것 – 디렉터는 게임 개발의 스페셜리스트 – 그러나 게임을 잘 만느는 것과 런칭하는 것은 큰 관계가 없다 – 게임을 런칭하는 것은 프로듀서의 업무 106
  107. 107. 요약 • (개발)디렉터가 될 기회 – 도전해 볼 만한 시장 상황일 때, – 준비된 프로젝트를, – 그 프로젝트를 해 낼 역량이 되는 사람이 지원하면 • 준비된 프로젝트 – 사고 실험을 통해 항상 꺼낼 수 있는 게임 2~3개가 필요 • 디렉터 직무 역량 – T자형 역량 필요, 개발 전반에 대한 얕은 지식 – 자신의 역량과 다른 역량을 가진 파트너 멤버가 필요 • 경험이 없는 디렉터는 프로듀서를 찾을 것 107
  108. 108. 긴 시간 수고 많으셨습니다. 감사합니다 이상균 @iyooha http://iyooha.com

×