NDC 간략한 참관기 #2

개발 2011.06.12 16:16

 2일, 3일차에는 의견을 따로 정리하기에는 애매했던 세션들이 많아서 글 하나로 압축... 다 써놓고 보니 전혀 간략하지 않아 보이는 건 착시입니다.



 성공하는 제품을 만들기 위한 팀 구축 (박종천 / Blizzard)

 이 세션에 대한 내용은 찾아 봐도 요약본이 없고, 또 슬라이드도 올라오지 않을 것 같아서 전반적인 내용도 따로 정리해보았다. 일주일 넘게 지난 상황이라 좀 틀린 내용이 있을지도...

 우선 블리자드에서 한 첫 작업인 스타크래프트의 한글 지원 패치를 언급함으로써 청중들에게 환호를 받으며 강연을 시작. 그리고 본 강연의 내용은 여러분들도 다 아는 내용을 우리는 이렇게 적용하고 있다는 것 밖에 없다면서 소속사의 위엄을 본격적으로 드러내었다. -_-;

 제일 처음은 팀을 구축하는 데에 있어 필요한 것은 프로젝트와 인력, 예산이며, 이 중에서는 좋은 프로젝트가 가장 중요하다고 강조. 그 이유는 성공적인 제품 개발에 있어 좋은 인력과 충분한 예산은 당연히 필요한 조건으로 이 둘이 없이는 프로젝트를 진행조차 할 수 없으며, 이러한 조건을 완벽하게 갖추더라도 안 좋은 프로젝트를 하게 될 개연성은 충분하기 때문이다. 따라서 이 부분에 지속적으로 신경을 기울일 필요가 있다.

 그 뒤 팀이 실제로 구축되고 발전하는 과정은 집단의 발달 단계 모형을 인용하여 설명하였으나 여기에 대해서는 거의 언급하지 않고 넘어갔던 것으로 기억한다. 해당 모형의 발전 단계에 따라 팀이 발전할 수록 팀원 간 신뢰와 지식 공유의 깊이가 깊어지고 최종 단계에 이르러야 최대한의 퍼포먼스로 가지고 일을 할 수 있다는 내용. 이를 위한 척도로는 커뮤니케이션, 효율, 생산성 등이 있다.  팀이 구축된 이후 업무를 수행할 때 프로젝트 오너, 프로듀서, 리더, 엔지니어 등 역할에 따라 할 일이 서로 다르니, 팀원들이 실제로 수행할 역할을 명확하게 정의하고 그에 따라 업무를 적절하게 위임한다.

 제품을 만들 때에는 세 가지 현실적인 제약이 있는데, 각각 Cost(Resource), Time(Schedule), Scope(Quality)다. 대개의 경우는 Cost과 Time을 많이 투자할수록 Scope가 좋아지지만 반드시 그렇게만 흘러간다는 보장은 없다는게 문제. 하지만 블리자드는 Cost와 Time에 대해서는 신경쓰지 않는다. -_-; 여기에는 Cost와 Time을 투자하면 높은 Quality를 얻을 수 있다는 확신이 필요하다. 그러한 확신의 뒤에는 블리자드의 전 직원들이 게임 플레이어로써 제품에 대해 주는 광범위한 피드백이 있다. 몇몇 매니저 급에 의해 품질이 평가/파악되는 시스템에서는 불가능한 일.

 문제를 맞닥뜨리면 우선 해결할 문제를 택한 뒤 이를 정의, 분석하고, 여기에서 다양한 해법을 찾는다. 이 때 다양한 해법을 찾는 것에 방점을 찍었는데, 그 이유는 즉흥적으로 떠올린 해법을 바로 적용한 경우 해당 문제가 확실하게 해결된 상태로 남기보다는 차후 또 다른 문제를 일으킬 가능성이 있기 때문이다. 그 뒤 선택한 해법을 토대로 의사 결정권자를 설득한다. 이 역시 중요한데, 이 과정을 스킵하면 차후에 의사 결정권자의 결정에 따라 문제 해결에 들였던 노력이 무용이 될 수도 있기 때문.

 문제를 분석할 때에는 크게 중요성과 해결 가능성 둘을 기준으로 한다. 이를테면 중요하지도 않고 쉽지도/긴급하지도 않은 문제는 무시하고, 중요하고 해결이 간단한/긴급한 문제는 곧장 수행한다. 이 때 긴급하진 않지만 중요한 일이 긴급하지만 중요하지 않은 일보다 우선이다. 그 이유는 중요하지만 긴급하지 않은 일은 곧 중요하고 긴급한 일이 되어 돌아오기 때문이다. 하지만 중요하지 않은 일이 중요한 일이 되는 경우는 별로 없다. 또한 중요하지도, 긴급하지도 않은 일은 무시할 수 있는 내공이 필요. 이러한 우선 순위 관리가 제대로 되야 자기 시간을 관리할 수 있다.

 또한 프로젝트를 진행할 때에는 빠른 진행 속도로 인한 함정에 빠지기 쉽다. 아무리 빠르고 효율적으로 일을 해도 방향이 잘못되면 프로젝트는 실패하는데, 이게 잘 되는 것으로 착각하면 곤란. 잘못하는 일은 대체로 빠르게 진행되는 경향이 있으므로 너무 잘 되면 의심해봐야 한다. 멈춰서 프로젝트의 방향을 검토하는 일은 최대한 자주 이루어져야 한다. 최근 몇 년 간 이야기가 나오는 애자일 개발론이 그 좋은 예. 다만 방향을 검토하는 비용이 너무 비싸면 자주 멈추기 힘드므로 최대한 간단하게 점검할 것.


 여기까지는 팀을 구축하고 프로젝트를 진행하는 일반론적인 이야기다. 대부분 알고는 있음에도 여건 상 실천은 못하는, 비교적 흔하고 추상적인 내용들이다. 다들 이상론이라고 생각했던 것을 실제로 해내고 있다는 점이 블리자드의 저력 중 하나. 이후는 인사 관리에 대한 내용으로 회사 내의 조금 더 구체적인 사례를 들어 설명하였다.

 우선 블리자드의 인사 팀에는 Attract -> Develop -> Engage라는 표어가 붙어 있다. 말 그대로 인재가 오고 싶어하는 매력적인 회사가 된 뒤 이 인재들을 개발해서 제대로 써먹자는 의미. 대부분의 기업들에 제대로 써먹자만 남아 있다는 점을 생각해보면 확실히 차이나는 점이고, 이게 이후 발표의 주제 의식을 꿰뚫는 이야기이기도 하다. 발표자 분은 무척 감동 받은 문구였다고.

 우선 인사 고과(Performance Review)는 블리자드의 소프트웨어 엔지니어에 적용되는 사례를 들었는데, 블리자드에서는 소프트웨어 엔지니어를 평가하기 위해 Productivity, Professionalism(Reliability), Teamwork(Communication)과 같은 Soft skill과 Knowledge, Functionality(코드의 올바른 동작), Implementation(코드의 퀄리티), Design & Architecture같은 개발 능력을 척도로 삼아 각각에 대해 5점의 평가를 내린다.

 여기에서 평가를 내리는 주체는 팀장들과 평가 받는 엔지니어 자기 자신으로, 연 말에 스스로에 대한  한 해의 평가를 내린 뒤 이에 대해 팀장들과 토론을 하면서 점수를 확정 짓는 방식. 점수의 기준은 현재 대상이 가지고 있는 직급에 따라 다르게 적용되며, 당연히 높은 직급을 가지고 있을수록 더 높고 엄격한 평가 기준이 적용된다. 여기에서 좋은 평가를 받은 사람 중 다음 직급을 얻기 위해 충분한 실력을 가지고 있다고 판단되는 사람들은 직급 상승. 이러한 평가를 위한 테스트도 있다고 한다.

 인사 고과에서 인상 깊은 점 중 하나는 이렇게 평가한 내용들을 그냥 인사 고과에 반영하고 마는 것이 아니라는 점에 있다. 실제 평가를 내린 팀장급들이 각각의 평가 대상들에 대하여 각 척도마다 A4 용지 한장 분량의 평가(라지만 실제로는 앞으로 커리어에 대한 조언)를 작성하여  전달하는 것이다. [각주:1] 산업에 갓 뛰어든 사람들 대부분은 초기에 자신의 방향을 제대로 잡지 못하고 방황하는 경우가 많은데, 이렇게 선배 개발자들이 확실하게 멘토가 되어 주는 체계는 무척 인상적이다.

 발표자 본인이 속한 팀에서는 여기에서 더 나아가 6개월 단위로 평가를 하고 있으며, 매 평가마다 척도 1~2개에서 1~2점 정도의 향상을 목표로 하고 있다고 한다. 회사에서는 인재들에 대해 이렇게 계속해서 발전해 나가는 것을 요구하며, 또 그것을 적극 지원하고 있다. 아래에서도 다루겠지만, 블리자드에서는 단순히 경제적 지원 정도로 끝나는게 아니라 개개인의 발전을 위한 방향 설정, 목표 제시까지 해주고 있다.

 지나가는 이야기 식으로 블리자드 내부의 직급 Title 에 대한 이야기도 언급되었다. Software Engineer(이하 S/E)의 경우 신입은 Assistant S/E로 시작하며, 이들에 대한 기대는 대략 "숨만 잘 쉬어 줘도 고마운" 정도라고 한다. (...) 그 뒤 Associate S/E가 되면 어느 정도 일을 믿고 맡길 수 있는 수준으로 보며, 실제 Software engineer가 되면 스스로가 알아서 일할 수 있는 수준이 된다고 한다. 이렇게 Senior S/E까지가 일반적인 엔지니어 직급이며, 이후 팀을 이끄는 Lead S/E로 나가서 프로듀서/테크니컬 디렉터 등의 관리직으로 가는 커리어 패스가 일반적. 하지만 개발에만 전념하고자 하는 경우는 Principal S/E로 남아 계속해서 개발을 할 수도 있으며, 코딩만 20~30년을 하여 이 루트의 궁극에 달한 Distinguished S/E[각주:2]는 말 그대로 코딩의 신이라고. 평생 코딩만 할 수 있는 회사다!

 교육 역시 열성적으로 지원하고 있다. 아예 Blizzard learning & education이라는 이름으로 이를 지원하는 프로그램이 따로 있다. 학습을 위한 도서 구비는 기본이며, 내부에서 이루어지는 세미나나 Engineering discussion group[각주:3], 컨퍼런스 등을 지원한다. 특히나 Principal S/E 이상 직급은 매해 세개 이상의 컨퍼런스에 참여하여 세션을 진행해야 한다고. 그 외에도 대학 진학과 학비를 지원하는 프로그램도 있고, 개인 프로젝트 역시도 적극 지원한다고 한다. 이를테면 아이폰 게임 개발을 한다고 하면 사내의 팀을 구성해주는 등등의 일을 지원해준다고.

 가장 인상 깊었던 내용은 Individual Development Plan이라는 것으로, 간단히 말해 개개인의 발전을 위한 계획을 함께 세우고 이를 실제로 실천하도록 도와주는 시스템이라고 할 수 있다. 앞서 언급된 인사 고과와 비슷한 성격이지만, 보다 더 구체적으로 목표를 제시하고 계획을 잡아준다. 이를테면 언제까지 목표로 제시한 어떤 책을 마스터할 것 등등. 그리고 실제로 목표 달성을 독촉(...)하기도 하는 듯. 자신이 S/E라고 단순히 공학적인 부분만을 목표로 잡는 것이 아니라 개개인의 발전을 위해 필요한 부분들이라면 모두 목표가 될 수 있다. 발표자분도 관련 프로그램에 의해 타 대학에서 재무 관련 프로그램을 들었다고 하였다.

 후반부 내용들은 다 적어놓고 보니 어떻게 보면 마치 블리자드 모집 홍보 같은 기분도 들 정도인데, 이건 그 내용들을 단순히 열거하는 것만으로도 이 회사가 인재에 들이는 노력이나 비용이 바로 와닿을 정도로 공을 들이고 있다는 이야기다. 발표자 분은 이를 회사와 팀, 사원의 비전과 목표를 일치시켜 가는 과정이라고 하였는데, 사원들이 회사의 목표에 따라 올 것을 요구하긴 하지만, 그 목표가 궁극적으로 사원에게도 발전의 기회가 된다는 이야기.


 내용을 다 적고 나니 의외로 할 말이 없어졌다. 발표 전에 말하신대로 모두가 알지만 실천은 못하는 정론을 다루고 있고, 그걸 블리자드에서는 제대로 하고 있고, 또 할 수 있다는 이야기. 마치 밥 로스 아저씨를 보는 기분이랄까 - -; 발표 중에 나온 말 대로 블리자드는 똑똑한 사람들이 열심히 일하는 회사고, 또 그렇게 되도록 시스템을 구축한 회사인 듯. 굳이 의견을 하나 더 붙이자면 그냥 ... 블리자드에서 일하고 싶다? (...)



 절차적 지형의 생성 관련 세션 (김주복, 이원 / Nexon)

 (참조 : NDC 공식 블로그, devCAT publication)

 3일차 베스트 세션. 내 친구에게서 들은 바로는 발표자이신 두 분은 PT의 신(...)이고, 게다가 주제도 무척 끌렸음. 그래서 잔뜩 부푼 기대감을 가지고 갔는데, 그 기대를 배신하지 않은 아주 좋았던 세션이었다. 총 3 시간에 걸친 세션이었는데 원래는 마지막 시간이 실제 구현에 대한 내용이었으나 보안 문제로 인해 툴인 월드 머신을 다루는 시간이 되었다고 한다. 하지만 월드 머신의 구조 자체를 다루는 것만으로도 구현에 대한 힌트를 상당 부분 얻을 수 있었기에 충분히 만족했다.

 우선 첫 시간은 절차적 지형 생성의 동기와 그 방법론들에 대한 대략적인 소개. 요즘 들어... 라기에는 꽤 예전부터 절차적인 컨텐츠 생성에 대한 연구가 이루어져 왔다. 그 이유는 컨텐츠의 용량 제약, 다양성, 의외성 등 여러 가지가 있겠지만, 어디에도 빠지지 않는 이유는 생산성이다. 게임 하나에서도 엄청난 규모의 데이터를 다루는 지금 이걸 다 수동으로 만드는 건 현실적으로 무리다. 당연히 자동화에 눈길이 갈 수 밖에 없고, 이에 대해 게임 플레이에 핵심적이지 않은 부분에 대해서는 절차적 데이터 생성은 아주 좋은 도구가 될 수 있다는 것.
 
 애니메이션 간 전이나 임의의 컨텐츠 생성 등은 조합의 폭발로 인해 아티스트/디자이너가 일일히 데이터를 만드는 것이 별 의미도 없고 무척 비효율적인데, 생산성의 향상을 위해 절차적인 데이터 생성이 효율적으로 적용되는 사례다. 따지고 보면 3D 렌더링도 메쉬와 텍스쳐, 애니메이션, 셰이더 등의 데이터로부터 2D 장면을 실시간으로 생성하는 일종의 절차적인 생성이라고 볼 수 있겠다. [각주:4] 우리는 그야말로 절차적 생성의 시대에서 살고 있는 것이다. 메타 프로그래밍도 있다! 코드 제네레이터도 있다! 이제 코드 제네레이터를 만드는 메타 프로그램을 생성하는 코드 제네레이터를 만드는 ...

 마찬가지의 관점에서 볼 때 하이트 맵은 절차적 생성을 적용하기에 아주 매력적인 대상이라고 볼 수 있다. 만들어야 하는 데이터의 크기가 매우 크고 디테일 작업에 손이 많이 가지만, 게임 플레이에 있어서는 디테일보다는 전반적인 지형 형태가 좀 더 중요하다. 하지만 디테일이 없으면 외관이 매우 어색해지기 때문에 아예 무시할 수도 없다. M2 팀에서 절차적 지형 생성을 도입하면서 목표로 삼은 것은 고품질의 지형을 최소한의 수작업으로 만드는 것으로 이 경우는 생산성에 방점을 찍은 케이스가 되겠다.

 이후 실제 적용한 방법들을 설명하였는데, 간단하게는 "나이브한 방법은 컨텐츠의 퀄리티와 제어 가능성 Controllability이 떨어지고, 이 둘을 높이려면 수작업이 필요하고" 정도로 요약할 수 있다. 순수하게 알고리즘적인 방법들을 사용하면 기획자가 의도한 형태라던지 모양 같은 컨텍스트가 누락되는 경향이 있고, 이런 변수들을 알고리즘/데이터에 세세히 반영하기 시작하면 수작업의 비율이 늘어난다. 다시 말해 은탄환은 없고 트레이드오프만 존재하는 상황. 특히나 강/길이 잘 만들어지지 않았다고 하는데, 이 둘은 컨텍스트가 중요한 요소들이라 요구되는 수준이 그만큼 더 높았기 때문이 아닐까 하는 생각이 든다.

 여기에서 M2팀이 권하는 방법은 어느 정도의 절충안과 더불어 남이 만든 걸 최대한 가져다 쓰자- 인 듯. 반지의 제왕 DEM 프로젝트는 우수한 퀄리티를 보여주고 있지만 그만큼 수작업이 많이 들어가는 케이스로 보이고, 실제 지형에서 가져오는 방법은 제어 가능성이 매우 떨어진다. 이미지 기반으로 능선을 파악하고, 해당 능선에 맞게 적절한 DEM들을 조합하여 지형을 생성하는 방법도 있지만 이건 능선을 만드는 수준에 머물렀다고... 전반적으로 잘 작성된 리뷰 페이퍼를 읽는 듯한 느낌이었다.
 

 두 번째 세션은 과정에 조금 더 집중한 세션. 디렉터가 그린 작은 개념도 하나에서 전 대륙에 걸친 지형을 생성하는데 사용한 방법론, 겪었던 시행 착오들과 더불어 그 결과까지 일목요연하게 요약하는게 무척 인상적이었다.

 기본적으로는 지형/산/강 등의 기본적인 지형 단위를 설정하고, 이런 지형 단위들에 대해 특성을 줄 수 있는 요소들을 적절하게 정의한 뒤 각각의 지역 별로 특성을 설정하여 전반적인 지형을 생성한다.[각주:5] 일단 언급된건 지형/산/강 정도지만 이건 전반적인 지형 구조에 해당되는 내용이고, 다른 샘플을 볼 때 디테일하게 내려가면 좀 더 다양한 지형들을 갖추고 있는 듯 하였음.

 여기에서 짚고 넘어간 점 중 하나가 이렇게 절차적으로 생성되는 컨텐츠의 경우는 생성하는 과정 자체에 집중하다보니 정작 컨텐츠가 게임 플레이에 어떻게 적용되는지를 간과하게 될 소지가 있다는 점. 개인적으로도 패턴이 절차적으로 생성되는 음악 게임을 만들려고 시도할 때 직접 플레이는 안 해보고 패턴이 예쁘게 나오느냐만 봤던 기억이 있어서 슬쩍 뜨끔.[각주:6] 특히나 이렇게 레벨을 제작할 때는 항공 사진만 보게 되는 맹점이 있기 때문에 특히나 유의해야 할 듯 하다. 게임 플레이에 대한 검증이 최우선이라는 것.

 결과물을 개선해나가는 과정은 절차적인 컨텐츠 생성에서 겪게 되는 전형적인 튜닝 과정이었을 듯하다. 이렇게 알고리즘적인 컨텐츠 생성은 결과가 좋건 나쁘건 왜 그렇게 나오는지 이해하기 어려운 경우가 많다. 게다가 눈으로 직접 보지 않으면 퀄리티를 평가하기도 어렵다. 그런 이유로 대개 튜닝을 위해선 Hill climbing을 손으로 직접 -_-; 하게 되고, 그 결과 Global maxima는 아니라도 대충 Local maxima라도 찾아내면 나름 성공적인 경우라고 볼 수 있을 듯 하다.

 M2팀에서는 기초적인 단위를 바탕으로 지형 생성에 필요한 구조를 갖추고 이를 조합하여 최종적인 생성하는 방법론을 쓰고 있는데, 여기에서 실험 끝에 찾아낸 Local maxima들을 다른 지역에서도 재활용할 수 있도록 한 듯 하다. 물론 이건 전부 추측이지만. ;


 궁금했던 점이 있었는데... 일단 자동적으로 생성한 데이터를 다룰 때 지켜야 하는 철칙 중 하나가 바로 자동으로 생성된 데이터는 손으로 수정하지 말 것이다. 입력 값이 바뀔 때마다 변경점을 손으로 재반영해야 하기 때문. 하지만 지형 같은 경우는 게임 플레이를 위해서는 일정 부분 수작업이 들어 갈 수 밖에 없다. 마을이라거나 길 같이 자동 생성에는 부적합한 부분이 분명 있기 때문. 그런데 퀘스트 동선 등의 기획적인 의도가 변경된다던지 하는 이유로 수작업이 적용된 지역의 세부적인 지형이 바뀐다면?
 
 일단 M2팀은 이에 대한 나름의 복안이 있다고 했으며, 강연에서 나온 내용만으로 봐도 자동 생성의 영역을 특정 지역으로 국한시킬 수 있기 때문에 큰 문제가 되지는 않는다고 하셨던 듯. 즉, 기존의 작업은 버리되 새로 만드는 비용을 최소한으로 줄이는 전략이다. 어차피 기존과 같이 손수 작업을 하는 경우에도 지형을 바꾸는 작업은 비슷한 비용이 들어가니 절차적 지형 생성의 본래 의도를 해치진 않는 방법인 셈이다.

 또 하나는 어떻게 해야 게임의 컨텍스트를 최대한 잘 살릴 수 있는가. 이를테면 강 같은 경우도 그렇지만 길이라거나 랜드 마크의 위치, 동선 등에 대한 제어 가능성은 게임 디자인에 있어서 꽤 중요한 부분이라고 생각한다. 지형에 맞춰서 이들을 배치하는게 보통이겠지만, 지형을 여기에 맞춰야 하는 경우도 있을 수 있다고 생각. 사실 이 부분은 기본적으로 하이트맵을 변조하는 툴인 월드 머신만 가지고는 아무래도 무리가 있는 부분이라고 생각하고, 게임 내부의 컨텍스트를 구조적으로 지형 생성 과정에 완전히 통합, 반영할 수 있는 툴 없이는 어렵지 않을까 싶은 생각이 들었다. 혹시 원래 예정되었던 3번째 세션에서 이런 내용을 다루는게 아니었을까 하는 생각도 ;
  1. 발표자분 말로는 "이대로만 했어도 훌륭한 사람이 되었을텐데"라고. (...) [본문으로]
  2. 직급명이 정확히는 기억이 안 나지만, 미국 소프트웨어 회사의 일반적인 직급 체계를 보면 아마 맞을 것이다. [본문으로]
  3. S/E의 특정한 주제를 다루는 그룹으로, 해당 주제에 관심 있는 사람들이 모여 보다 깊게 학습하고 만나서 토의한다고 한다. [본문으로]
  4. 사실 게임계에서 3D가 대세가 된 가장 큰 이유 중 하나가 바로 생산성이기도 하다. [본문으로]
  5. 물론 이 특성이나 요소들은 순수하게 개념적인 것이다. 실제 사용되는 데이터는 입력되는 비트맵과 변환 로직이고, 나오는 데이터는 하이트필드 하나다. [본문으로]
  6. 그 게임의 목표는 음악을 받아 악보를 적절하게 인지하고 패턴을 생성하는 것이었는데 패턴 생성은 둘째치고 음원 인식에서부터 털렸다. orz [본문으로]

'개발' 카테고리의 다른 글

NDC 간략한 참관기 #3  (4) 2011.06.19
NDC 간략한 참관기 #2  (1) 2011.06.12
NDC 간략한 참관기 #1  (0) 2011.06.04
기본 타입 간 (무분별한) 변환은 자제합시다  (3) 2011.05.14
Visual Studio는 C/C++을 싫어해 (?)  (3) 2011.02.27
Bitwise Switch  (2) 2011.02.19
tags : ndc, 개발, 참관기
Trackback 1 : Comment 1

NDC 간략한 참관기 #1

개발 2011.06.04 17:00

 저번 주 내내 NDC를 참관했는데, 기억이 흐릿해지기 전에 몇몇 세션에 대해 글로 정리해본다 강연의 정리는 다른 분들이 잘 해놓으셨으니 개인적인 수준의 감상만 남김. 강연 요약본이 아니니 강연 내용 자체를 원하셨던 분들께는 죄송. 들었던 세션 전부를 정리하는 건 아니고, 정리해 볼 만한 의견이 있는 경우만 정리해본다.



 구세대 개발자의 신세대 플레이어를 위한 게임 만들기 (김동건 본부장 / 넥슨)

 ( 관련 링크 : NDC 공식 블로그, NDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 우선은 Entry age의 확보에 대한 강조로 시작했는데, 새로 게임을 시작하는 유저에 대한 강조는 이미 닌텐도부터 시작하여 수 많은 게임 회사들이 강조하지만 그걸 실제 게임 디자인까지 반영시키는 경우는 그리 많지 않은 것 같다. 그 이유는 보통 게임 개발자들이 자신에게 재미있는 게임을 만들려고 하기 때문인데, 이를 정확히 짚어냄. 닌텐도가 Wii로 성공한 까닭이 바로 그 지점이고. 개인적으로는 Wii Sports가 개발자와 유저의 괴리를 잘 보여주는 지점이라고 생각한다. 이 게임은 메타 크리틱 점수가 평균 76점으로 닌텐도 게임 치고는 최악의 평가를 받았음에도, 판매고는 거의 8000만장에 육박.

 다만 충성 고객에 대한 언급이 부족한 것은 조금 의아했다. 아마 PT의 주제를 흐리지 않을까 걱정한 게 아닐까 싶은데, 그래도 언급할 가치는 있지 않았을까? Wii는 신규 유저 창출에 극단적으로 올인한 케이스인데, 분명 잘 나가긴 했지만 파급 효과에 비해 지속력이 떨어져 한 순간의 바람이 되어 버렸다. PT에서 언급하고 있는 20%의 이탈률은 아주 충성률이 높은 경우라고 생각하는데[각주:1], 여기에 대해서도 어느 정도 이야기는 하는게 좋지 않았을까.

 이후 이어진 게임 디자인적인 관점은 대공감. 새로운 게임 메커닉에 대한 천착으로 인해 망한 온라인 게임의 수는 셀 수도 없고, 반대로 새로운 게임 경험의 도입/구시대적 게임 경험의 척출을 거부하다가 뒤쳐진 게임들도 많다. 이제 중요한건 어떻게 플레이하느냐가 아니라 그게 재미있느냐라는 이야기. 게이머 커뮤니티인 루리웹에서 나온 루까성[각주:2] 같은 단어는 이러한 내용들이 하드코어한 게이머들에게도 느껴질 정도로 대세가 되었다는 의미도 될 수 있지 않을까?

 와우 패치의 역사를 보면 이런 방향성이 느껴지는데, 간단한 어그로 미터의 도입이라거나 퀘스트 라인의 일직선화, 퀘스트 목표를 지도에 표시, 던젼 도감의 도입 등 가장 핵심적인 게임 플레이를 제외한 다른 잡다한 요소는 전부 쳐내고 게이머로 하여금 중요한 게임 경험에만 집중하도록 발전하는 것을 볼 수 있다. 게임 디자인에 있어서 한국과 해외의 가장 큰 차이라면 이런 부분이 아닐까 싶었는데, 역시 탑 레벨 스튜디오는 트렌드를 아주 빠르게 따라가는구나 싶었음.

 근데 문제는 이 쪽만 따라가면 또 안 된다는거다. (...) 일반론적으로는 새로운 게임 유저들이 지속적으로 유입되는 것도 중요하지만, 이게 온라인 게임으로 가면 그 유저들이 계속해서 남는 것 역시 중요하다. 여기에는 하드코어 게이머들이 만들어내는 이야기와 커뮤니티의 역할이 무척 큼. 그리고 그 하드코어 게이머를 잡아내려면 탄탄한 게임 플레이와 하이엔드 컨텐츠가 있어야 한다. 와갤과 용개가 없었다면 한국에서 와우 커뮤니티는 반토막 나지 않았을까? 상충되는 두 목표를 함께 잡아내기는 참 어려울텐데[각주:3] 여기에는 어떤 답을 냈을지 궁금...



 영웅전 액션 시스템:기민하면서도 다채로운 액션 프로토타이핑 (박영준 / 넥슨)

 ( 관련 링크 : NDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 궁극적으로 게임 플레이 프로그래머를 지향하는 입장에서 무척 재미있게 봤던 세션. 기술이 발전하고 게임 플레이에 대한 요구 레벨이 점차 올라가면서 게임 플레이와 프레젠테이션 레이어 사이의 경계가 모호해지는 추세다. 조금 더 정확히 말하자면 전통적으로 프레젠테이션 레이어에서 담당하던 영역이 은근슬쩍 게임 플레이로 넘어오고 있다. 그 이유야 조금 더 직관적인/사실적인 게임 플레이를 위해서고...

 특히나 애니메이션이 그런 경향이 있는 것 같은데, 이렇게 될수록 게임 플레이 프로그래밍은 점점 고달퍼질 것으로 예상된다. 물리니 IK니 하는 절차적 애니메이션 기법들이 끼어들어가는 와중에 또 이걸 어색하지 않은 애니메이션으로 잘 맞춰주는게 꽤 어려운 일이라고들 하는 것 같다. 근데 나는 여기에 대해 아는게 거의 없다는 문제가... (...)

 어쨌든 나름 성공적으로 서비스하고 있는 마영전에서는 여기에 대해 어떤 접근을 취했는지에 대해 다루는데, 기본적으로는 액션 자체를 데이터 드리븐하게 다루고 여기에서 발생하는 이벤트를 적당한 애니메이션을 연동시키는 방향... 으로 이해했다. 아직까지 PT가 올라오지 않은 상황이라 정확히는 기억은 못하겠지만. 이렇게 기반을 만들고 실제 컨텐츠를 만들어 내는 사람들이 실제 액션을 작업하면서 필요한 기능을 프로그래머들에게 요청하는 형태인 듯.

 놀랐던 건 이런 기반 시스템을 베타 3개월 전에 뒤엎어서 만들었다는 점. 라이브하는 게임을 뒤엎은 것과 다를 바가 없는 일인데, 이걸 해냈다. 물론 그 이유는 생산성이다. 사실 논리적으로 생각해보면 이게 올바른 길이 맞는게, 앞으로 엄청난 수의 컨텐츠를 만들어 내야 하는데 개발 프로세스가 병목이 되어 이터레이션 자체가 안 되는 상황이라면 이걸 뜯어 고치는게 당연한거다. 보통 이런 문제는 나중에 갈수록 고치기 점점 힘들어지고, 가장 싼 값에 고칠 수 있는 시점은 당장인 경우가 많다.
 
 허나 현실적으로 "무슨 일이 일어날지 모르니까" "여태까지 잘 되던건데 꼭 고쳐야 하나" "문제되면 그 때 고치지" 같은 방어적/수동적인 생각들이 없을 수 없다. 하지만 이건 비용에 비해 이득이 작아 안 해도 될 정도로 사소한 일인 경우나 시간이 지나도 문제가 심각해지지 않을 경우에나 적용될 말이고, 근본적인 부분의 문제라면 가능한 이른 시일 내로 작업에 들어가는게 맞다고 본다. 그런 관점에서 이 사례는 확신만 있다면 문제점을 안고 가는 것보다는 이를 근본적으로 해결하는게 맞는 일이라는 증명이 되어줄 듯 하다. 2일차 박종천씨의 세션에서도 한 번 언급된 내용이지만, 사소하지만 긴급한 일보다는 중요하지만 긴급하지 않은 일이 우선.


 
 메이플 스토리 : 잘되는 게임을 위한 라이브 코어 개발 (황의권 / 넥슨)

 ( 관련 링크 : rein's worldNDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 또 하나의 좋았던 세션. 사실 NDC 세션 중에서 별로였던 세션은 몇 개 없었지만. 여기에서는 크게 라이브 서비스에서의 혁신과 개선, 이 두 가지 내용에 대해 다루었는데, 이제 막 업계에서 일하기 시작한 뉴비로써 배울 게 굉장히 많았다.

 게임 업계에서는 라이브 서비스를 좋아하는 사람도 있겠고 싫어하는 사람도 있겠지만, 내 경우는 프로젝트에 대한 컨트롤이 안 된다는 점 때문에 라이브 유지보수를 별로 안 좋아한다. 일단은 자기가 짠 코드가 아니라 함부로 코드를 고친다거나 하기가 어렵고, 그 비용을 예상하기가 어렵다. 엄청난 분량의 레거시가 잔뜩 쌓여 있는 상황에서는 작은 수정에 들어가는 비용도 신작에 비해 훨씬 크다. 게다가 팀의 분위기도 가능하면 사고나 치지 말자~ 이런 경우도 많고. 능력자 입장에서 하고 싶은 건 많은데 현실이 안 받쳐주는 경우 그냥 모럴이 붕괴해버리는 결과도 많을 것이다.

 세션과는 무관하게 여기에 대해서는 할 말이 참 많은데 (...) 코드의 의도를 설명하는 주석이나 가능한 경우 기초적인 단위 테스트 작성 정도는 후에 해당 코드를 유지보수할 사람에 대한 최소한의 예의다. 조금 더 욕심을 부리자면 더 좋은 코드를 - 사이드 이펙트가 적고 구조화, 모듈화가 아주 잘 되어 있는 등 - 작성하는게 좋겠지만, 이건 개개인의 능력에 달린 일이니 강요할 수는 없다. 하지만 앞에서 말한건 최소한의 의지만 있어도 할 수 있는 일인데 이조차 안 한다는 것은 그냥 배려가 없다는 이야기.

 이 세션을 들으면서 느낀 점 중 하나가 발표자 분이 이런 모럴적인 부분에 대해 경험적으로든 직관적으로든 잘 이해하고 있다는 점이었다. 특히나 지금 현재 상황이 더 나아지고 있다는 느낌을 주는게 중요하다는 점을 강조하는 부분이 인상 깊었다. 내츄럴 본 개발자들이 싫어하는 것은 환경을 개선조차 할 수 없도록 만드는 상황이지, 개선 자체의 어려움이 아니다.

 하지만 라이브이기 때문에 이런 개선/변경도 영향력 검토가 수반되어야 한다. 어떻게 보면 약간 과하다고 생각될 정도로[각주:4] 방어적인 자세가 아닐까, 하는 생각도 들긴 했지만 이 정도는 의견 차이일 뿐 맞다/틀리다를 논할 부분은 아닐 것 같다. 어찌되건 수정이 사이드 이펙트를 가져오지 않도록 보장하는 것은 상품을 돈 받고 파는 입장, 조금 더 세련되게 말하자면 프로로써 지극히 당연한 일이기 때문.

 그보다 중요한 것은 이런 자세를 취하면서도 현 상황을 개선하려는 의지를 놓지 않는다는 점인 듯하다. 그 사이의 타협점을 맞추는게 리더로써 중요한 자질이 아닐까 싶고. 실제로 레거시에 이런 개선 사항을 적용하려면 타협이 없을 수 없는데, 우리는 이런 적용을 위해 어떤 타협을 했으며 결과적으로 어떤 개선을 했다, ndc에는 전반적으로 이런 세션이 많아서 좋았음. 실제로 당장은 아니라도 근 시일 내로 레거시 프로젝트에 적용해 볼 만한 내용이 많았던 듯.



 마비노기 영웅전 자이언트 서버의 비밀 (양승명 / 넥슨)

 ( 관련 링크 : rein's world, NDC 2011의 강연 노트를 모아보아요! (05월 30일) )

 단일 서버의 구현에 대한 내용으로 기술적/설계적으로 가장 흥미로웠던 세션 중 하나였다. 일단은 성공적으로 서비스하고 있는 게임의 서버 구조를 다룬다는 자체만으로도 흥미로운데 게다가 그 서버는 C#으로 만들어진 확장성 있는 단일 서버인데다 크고 아름다운 구조를 가지고 있다. (...) 내가 발표의 문맥을 제대로 이해했다면 이러한 기술적인 결정은 전적으로 엔지니어들 선에서 이루어진건데, 이게 사실이면 데브캣은 엔지니어들이 재미있게 일할 수 있는 환경이 아닐까 싶다는 생각.

 전반적으로 다양한 컨셉들의 추상화가 꽤 잘 되어 있다는 느낌을 받았다. 기본적으로 Service로 수행 주체를 추상화하여 물리적인 서버 대신 추상적인 서비스를 이용하도록 하는 것이 핵심 아이디어. 여기에 Entity로 대상 객체를[각주:5], Operation으로 수행 로직을 정의하고 이를 적절하게 분산 처리하면 scalable한 throughput을 얻을 수 있지 않겠느냐...는 접근인 듯.

 다만 퍼포먼스 측정을 위한 프로토타이핑이 선행되지 않아서인지 예상보다 좋지 않은 성능을 보여줬다고 하는데, 현재로써는 부하가 가장 큰 메시지 직렬화 부분을 극한으로 최적화하는 정공법으로 문제를 완화했다고 한다. 따지고 보자면 근본적인 문제를 해결한 것은 아닌 듯. 개인적으로는 데이터를 처리하는 로직의 시간 복잡도에 추가로 서버 간 커뮤니케이션으로 인해 데이터의 크기까지도 시간 복잡도에 영향을 주게 되는게 핵심적인 문제라고 보이는데[각주:6], 이런 면을 볼 때 게임 서버에 있어서 로직 처리와 이를 분산시키는 기반 엔진의 칼 같은 분리는 아직까지 쉬운 일이 아닐지도 모르겠다. 

 또 하나 궁금했던게 레이턴시였는데... 실시간 게임이라면 레이턴시가 무척 중요한 로직이 반드시 있다. 그런데 지금의 구조에서는 한 엔티티는 계속해서 한 서비스가 처리하는데, 특정 서비스에 부하가 걸리면 해당 서비스에 걸려있는 엔티티 전부가 느려지고, 엮여 있는 서비스들까지 연달아서 반응이 느려지는 문제가 있었다고 한다. 이게 단일 프로세스 내부의 쓰레드 간 로드 밸런싱이라면 그냥 랜덤하게 Work stealing하는 구조로 만들어서 간단하게 해결할 수 있지만 분산 처리에서는 발생 빈도에 비해 그 자체의 커뮤니케이션 오버헤드가 너무 크기 때문에 쉽게 택할 수 있는 방법은 아닐 듯 하다.

 사실 이 부분에 대해서는 그다지 경험이 없어서 잘 모르겠고 또 결과론적인 이야기지만 서비스를 기준으로 서버 인스턴스를 나누기보다는 엔티티를 기준으로 서버 인스턴스를 나누는게 좀 더 나은 성능을 보이지 않았을까? 하나의 오퍼레이션이 여러 서비스를 돌면서 생기는 커뮤니케이션 오버헤드와 한 서버 인스턴스가 하나의 서비스만을 다룸으로 생기는 성능적인 이득을 비교해보면 아무래도 앞이 더 크지 않을까 하는 생각이 들었다. 구조는 약간 덜 우아하겠지만 ;

 또 하나 눈 여겨 볼 부분 중 하나가 바로 DB로 인한 병목. DB의 이론 중 하나로는 CAP 이론이 있는데, 간단히 말해서 일관성, 가용성, 분할 가능성 셋 모두를 만족시키는 DB는 없다는 이야기다. 이 중 분할 가능성은 다르게 말하면 확장성이라고 볼 수 있는데, 대부분의 게임 서버에서는 게임 디자인 상 일관성, 가용성 모두가 필요하기 때문에 확장성을 포기하는 RDBMS를 쓰게 된다. 그런데 기술적인 문제를 해결하는 대신 게임 디자인을 약간 바꾸는 선택을 취한다면 어떨까 하는 생각이 들었다. 이를테면 일관성의 레벨을 eventual consistency 수준으로 낮추는 대신 비일관된 경우를 최대한 덜 보도록 디자인 차원에서 플레이어들을 적절하게 클러스터링을 해준다면? 등등. 물론 망상 수준이다 (...)

 그런데 이런 것 다 제쳐두더라도 이런 구조의 게임이 실제 수만명 단위의 동접자를 받아 성공적으로 서비스된다는 자체가 무척 인상적이었다. 한 10년 지나면 반응성이 중요한 심리스 MMO 같은 게임에서도 적용할 수 있는 분산 서버 모델이 나올 수 있을 것 같다는 생각도 들었다. 물론 그런 시대도 이러한 기술적인 도전이 계속되어야 나올 것이라는 점에서 무척 가치 있는 도전이었다고 생각한다. 




 첫 날은 인상적인 세션이 많았다. 덕분에 글도 길어짐.
  1. 와우의 경우 리치왕의 분노 시절까지 신규 유저의 70%가 10레벨 이전에 떨어져 나갔다. 친구 초대 등도 있지만 기본적으로 결제가 필요한 유료 게임이라는 점에서 상당히 충격적인 지표다. [본문으로]
  2. "루리웹에서 까이면 성공한다"의 약자. - -; [본문으로]
  3. 와우의 레이드에는 하드 모드라는게 있다. 하드 모드 도입 이전에 캐쥬얼 게이머들은 하이엔드 컨텐츠를 해보지 못한다고 징징거렸는데, 도입 이후에는 할 게 너무 많다 (...), 코어 게이머들과 격차가 너무 많이 난다 등으로 징징거린다. [본문으로]
  4. 개인적으로 64비트 플랫폼으로의 포팅은 msdn의 가이드만 꼼꼼히, 충실히 따라도 큰 문제 없다고 생각한다. 물론 이 경우는 포팅 자체보단 테스트의 문제였지만. 자체적인 스트레스 테스트가 가능했다면 좀 다른 선택을 했을지도 모르겠다는 생각이 들었다. [본문으로]
  5. 이건 추후 성능 문제가 발생한 이후 추가된 개념 [본문으로]
  6. 물론 분산 처리 자체로 인해 constant factor가 낮아지는 것도 있겠지만... [본문으로]

'개발' 카테고리의 다른 글

NDC 간략한 참관기 #3  (4) 2011.06.19
NDC 간략한 참관기 #2  (1) 2011.06.12
NDC 간략한 참관기 #1  (0) 2011.06.04
기본 타입 간 (무분별한) 변환은 자제합시다  (3) 2011.05.14
Visual Studio는 C/C++을 싫어해 (?)  (3) 2011.02.27
Bitwise Switch  (2) 2011.02.19
tags : ndc, 개발, 참관기
Trackback 0 : Comment 0

티스토리 툴바