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 : , ,
Trackback 1 : Comment 1

티스토리 툴바