[IGC2018] 펄어비스 김광삼 - 대면 커뮤니케이션 주도의 게임 디자인과 게임 개발법

1. 대면 커뮤니케이션 주도의
게임 디자인과 게임 개발법
펄어비스 게임디자인전략실장
김 광삼 (별바람)

2. 강연자 소개
노땅 게임 개발자 aka 별바람(Byulbram)
주요 개발작:
1991 호랑이의 분노 (데뷔작)
1994 호랑이의 분노2
1995 푸른매
2000 그녀의 기사단
2002 그녀의 기사단: 강행돌파
2008 그녀의 기사단 모바일
2012 혈십자 (Asura Cross)
2015 실버불릿 (Silver Bullet)
2017 막타전설 (Legend of Maktar)
주요 경력:
2018 ~ 현 펄어비스 게임디자인전략실장
2004 ~ 2017 전 청강문화산업대학교 교수
2006 ~ 2009 전 (사)한국게임개발자협회장
2009 ~ 2017 전 별바람 스튜디오 대표
2000 ~ 2004 전 별바람 크리쳐 대표

3. 시작하며: 나는 왜 펄어비스로 왔나?
1. 목표의 일치:
게임개발자로써의 야심
세계의 최고의 자리를 노려보고 싶다
2. 게임을 만드는 방식이 잘 맞아서:
소위 “펄어비스 스타일”
아.. 물론 페이도 꽤 좋습니다

4. 어떤 방식으로 게임을 만들길래?
• 런 앤 건 (Run and Gun)
모두 함께 기획하고 함께 작업한다
• 페이스 투 페이스(Face to Face)
직접 얼굴을 대면하고 의사소통을 하면서 개발한다
어찌 보면 스타일이라고 하기에는 별로 특별해 보이지는 않겠지만
이 이야기를 하기 전에 먼저 게임 개발법의 역사를 돌이켜보자

5. 초창기의 게임 개발 (막개발)
• 옛~~날 게임개발은 그냥 막 만들었다 (일명 막개발)
• 그냥 함께 얼굴보며 토론하며 만들고 싶은 대로 개발
• 좀 앞뒤가 안 맞는 결과물이라도 재미있으면 장땡
• 장점: 자유로운 개발과 개성 넘치는 결과물
• 약점: 인원이 늘어날수록 어려워진다
지금도 인디 개발에서 자주 쓰이는 필살의 개발법

6. 팀 규모의 확대와 분업 개발
• 게임의 규모가 커지며 소규모 개발팀으로는 한계에 도달했다
• 보다 높은 퀄리티를 위해서는 다수의 전문가들이 필요
• 규모가 커질수록 즉흥적인 직접 토론으로 프로젝트를 진행하기 훨씬 어려워진다
-> 결과적으로 체계적인 개발 관리가 필요했다
• 다수의 작업자들에게 작업을 효율적으로 분배하고
같은 방향을 보기 위하여 이해를 통일시킬 필요가 있었다
그래서 만들어진 것이 기획서라는 문서로 된 설계도

7. 문서화된 기획서를 작성할 때의 고민
• 내 생각을 적은 문서를 읽고 누군가가 작업하면
정말로 원래 의도와 일치하는 결과물이 제대로 나올까?
문서화된 아이디어를 다시 제안되던 그 느낌으로 되돌릴 수 있을까?
-> 무형의 감성과 아이디어가 오히려 문자에 갇혀 “열화”되는 것이 아닐까?
• 정말 게임의 구조를 거의 빈틈없이 정리하는게 가능한가?
• 빈틈이 없다면 작업자의 창의성을 제한하는게 아닐까?
• 빈틈이 많다면 작업자에게 별로 쓸모가 없는 것은 아닐까?
• 만약 만들고 보니 뭔가 잘못되었다면 어디서부터 고쳐야하지?

8. 물론 그렇게 만들어도 잘 만들 수 있다.
• 물론 그렇게도 잘 만들 수 있다(틀렸다는 것이 아니다)
지금까지도 많은 성공한 게임이 있었듯이..
• 하지만 실무에서는 보통 기획서 문자 그대로는 개발하지는 않는다
그러다 결국 잘못되면 기획이 잘못되었다고 하곤 하지만..
• 그렇다면 기획자들에게 과도한 책임을 지게 하는 건 아닐까?
말하자면 대출연대보증을 하는 느낌이 될지도?
어쩌면 개발 방식의 단점들을 개선할 방법이 있지 않을까?

9. 개선책: 프로토타이핑과 반복 개발법
• 게임의 개발 단계를 잘게 나누어 개발:
(이 범주 내에서 여러가지 이름이 붙은 방법들로 다시 나뉜다)
• 개발 단계에서 방향성 수정이 용이하고 중간검증이 가능하다
• 보통은 다음 마일스톤/프로토타입까지의 기획을 하며 작업이 진행되고
매번 완성된 그 결과물을 검증하며 방향을 수정한다
이러한 개발 진행법은 현재는 거의 상식이라고 생각한다

10. 정말로 이걸로 충분한가?
• 결국 어쨌거나 우린 결국 주어진 “사양(스펙)”대로 “작업”한다
누군가 “대신 생각해서” 만든 설계를 토대로 만들게 된다
즉, 설계자와 작업자 사이의 간격이 생길 수 있다
-> 기획자와 개발자라는 용어????????? (+디자이너???)
“몰라, 나는 니가 하라는 대로 만들었다고”

11. 다른 개선책: 스크립트 / 데이터 드리븐 개발
• 기획자 혹은 스크립터가 콘텐츠를 스크립트로 구성하여 만드는 방식
• 프로그래머의 작업 부하를 줄여서 기획자와 분산이 가능하다.
(대량의 콘텐츠를 지속적으로 업데이트해야 할 때 유리하다)
• 이 방식은 엔진과 스크립트의 이원화된 개발구조가 되고,
스크립트와 코어 엔진의 구조, 작업범위가 생산성에 큰 영향을 끼친다.
• 스크립트 난이도가 높을수록 스크립터를 구하기 어려워진다.
경우에 따라서는 프로그래머를 한 명 더 구하는 것과 같음

12. 누가 문서를 적고 누가 스크립팅을?
• 만약 문서를 적고 다른 스크립터가 따로 스크립팅을 한다면,
기획자 -> 프로그래머의 절차가,
기획자 -> 스크립터/프로그래머의 절차로 모양만 바뀔 뿐 아닌가?
• 반대로 문서를 적고, 내용대로 직접 스크립팅 한다면,
오히려 자세한 기획서는 작업의 오버헤드를 늘리는게 아닌가?
그렇다면, 이런 방식에서는 게임디자인을 어떻게 해야 하지?

13. 돌이켜, 우리는 왜 기획서를 만들었더라?
• 작업의 효율적 배분을 위해
• 뭘 만들고자 했는지 의도와 방법의 전달, 같은 비전의 공유
• 작업의 사후 정리와 기록을 위해서
문서를 시간을 들여 각잡고 쓰면 더 좋은 점이 있나?

14. 아이디어의 제안
• 아이디어를 내는 것은 기획자만의 영역은 아니다
• 프로그래머, 아티스트, QA, 사업부 등 다들 원하는 것이 있다
다른 파트가 제안한 아이디어와 원하는 의도는 어떻게 기획에 담겨야 하는가?
보통 여기에 대한 일반적인 답은
“함께 모여 회의를 하고 최종적인 안을 기획자가 정리한다”
정말 그럼 다들 적극적으로 나서서 의견과 아이디어를 제시하나?
회의의 결론은 결국 지지부진하다 기획자에게 미뤄지지는 않나?

15. 그럼 현실의 개발은?
• 정말 문서만 적어서 보내주면 알아서 작업이 진행되나?
• 혹시 글로는 충분히 전달이 되지 않으니
기획서를 작성 후 직접 찾아가서 얼굴을 보며 설명하고 있지 않나?
만약 그렇게 개발하고 있다면
문서는 그냥 참고할 수 있을 만큼만 정리하면 되고
정말 공을 들여야 하는 것은 “대면 커뮤니케이션”이 아닐까?

16. 그럼 우리(펄어비스)는 어떻게 하나?
• 직접 혹은 같이 기획하고 작업하는게 최선
• 아이디어가 생각나면 업무공간에서 관련 작업자끼리 이야기를 나눈다
(공식적으로 회의실을 잡고 만나는 회의는 가급적이면 하지 않는다)
• 모든 토론은 논리적 공감과 감성적 공감이 병행되어 둘 다 공감되어야 한다.
논리적으로 맞더라도 감성적으로 공감이 되지 않는다면 곤란하다.
• 뭔가 될 것 같다면 문서 없이 직접 얼기설기 실험적인 결과물을 구성한다
-> 이걸 보며 다시 이야기하고 살이 붙는다 -> 다시 확장
• 문서는 위키에 메모하거나 작업 끝나고 기록해두는 정도로만

17. 이 작업 방식이 가능하기 위한 전제사항
• 욕심 많은 의욕넘치는 개발 팀원
당연하지만 수동적인 개발팀원들로 가득차면 이 방식은 돌아가지 않는다
• 자율성이 주어지는 의사 결정과 작업 구조
감성적으로 공감할 수 없거나 의견을 제시할 수 없다면 누구라도 의욕은 떨어진다
• 빠르게 구성해보고 시행착오를 하기 위한 생산성 높은 개발 구조
-> 기획자 혹은 아티스트가 직접 다룰 수 있는 직관적인 개발 툴이라거나..

18. 펄어비스의 개발팀의 구조
• 엔진 프로그래밍팀
• 콘텐츠 프로그래밍 팀
• 기획(게임디자인)팀
• 아트(디자인)팀
• 오디오팀
• QA팀
• 사업팀

19. 펄어비스에서 개발 진행은 어떻게?
• 아이디어는 파트 상관없이 제안한다
보통은 해당 작업에 관련되거나 담당할 사람들이 제시한다
의외로 아트팀이나 프로그래밍 팀이 제시하는 경우도 많다
• 구현에 필요한 작업자들끼리 찾아가 자리에서 대면 토론을 하며 서로를 설득
• 제안된 기획에 프로젝트의 담당 리더의 Go사인이 나면 바로 시작한다
그리고 완성된 결과가 OK되면 바로 적용

20. 우와 그거 쩔어!
• 토론의 가장 이상적인 결론은 함께 논리적, 감성적으로 공감하는 결론
“우와 그거 쩔어!”라는 느낌이 들면 그게 바로 답이다
• 결론이 났다면 얼기설기 구성해보며 만들기 시작한다.
• 일단 기획자가 프로토타입을 구성하면서 아트팀에 리소스를 요청하고
더 필요한 기능이 있으면 프로그래머들과 토론하며 추가
합치면서 다시 토론하고 수정하고.. 반복
• 리소스가 나왔다면 최대한 빨리 개발 버전에 적용시켜 같이 확인한다
-> 적용된 것을 바로 보지 못하면 문제를 알 수도 없고 의욕도 떨어진다

21. OK, 일단 만들어봐
• 기본적인 개발 기조는 “오케이, 일단 만들어봐”
(작업 공수가 꽤 들어갈 것 같다면 좀 고민해야 하지만)
• 스크립트과 데이터만으로 빠르게 개발할 수 있어 부담이 적음
• 만들고 아닌 것 같다면?
“OK. 괜찮아, 나중에 언젠간 고쳐서 쓰겠지 뭐”
이 만들고 보는 스타일이 펄어비스 특유의 매주 콘텐츠 업데이트의 원동력

22. 그럼 근시안적으로 중구난방이 되지 않나?
• 작업자 개개인의 적극적 자발성과 현장 판단에 힘을 싣는 개발은
장기적 비전 없이 중구난방이 되어서 결국 산으로 가지 않을까?
-> 우리가 고민하던 문제점이 바로 이 지점
• 너무 실무적으로 민첩하게 눈 앞에 있는 아이디어와 업무를 향해 달리다 보면
큰 틀의 판단을 보지 못하고 시야가 좁아질 수 있다
• 이 부분에서는 리더의 판단과 역량이 중요해진다

23. 리더의 역할
• 리더는 관리보다 결정을 해줘야 한다
• 작업 중 인식하기 어려운 거시적 관점을 보며 결정해줘야 한다
• 실무자들의 결정이 어렵다면 탑-다운으로라도 결정을 내줘야 하기도 한다
• 결정은 위계에 의한 것이 아닌 서로의 판단에 대한 신뢰가 바탕이 되어야 한다
(신뢰와 공감이 없이 진행되는 업무는 제대로 진행되기 어렵다)
“시도가 실패하더라도 책임은 우리가 진다. 걱정 말고 일단 만들어봐”

24. 마무리전에 첫 질문으로 돌아가서..
• 나는 이 개발 스타일이 좋아서 펄어비스로 왔다
우리의 개발 스타일을 더 발전시키고 더 증명하고 싶다
• 우린 아직도 배가 고프다
지금의 한계를 넘어 더 높이 올라가고 싶다
• 그러기 위해서는 지금 우리들의 힘 만으로는 부족할지도 모른다
그러므로..

25. 한국 게임이 더 발전했으면 좋겠다
• 사방에서 위기감 넘치는 이야기가 들려온다
별거 아니더라도 서로 알고 있는 노하우를 공유해야 하지 않을까?
• 우리 모두 새로운, 독자적인 방법론이 있다면 함께 나누었으면 한다
• 서로 선의의 경쟁을 계속하며 함께 발전하자

26. 감사합니다