2021 NDC 1일차 - 게임 PD가 되어 보니

참고 링크: https://www.youtube.com/watch?v=qbIBIouvHNw

---

#PD 관점에서 어떻게 게임 개발을 하는지 개발 노하우

---

0.강연 주제

---

1.PD와 디렉터 정의

-프로듀서: 게임 개발 책임자, 의사결정권을 가짐, 완성을 책임지는 사람
-한국에서는 개발 책임자의 직함이 디렉터, 총괄 디렉터, PD, 프로듀서가 혼용되어 쓰이고 있는데 엄밀하게 나누기가 힘들 때가 많다.

-프로젝트의 개발 인원에 따라 개발 책임자의 관점이 달라지기 때문에 혼재되어 사용된다고 생각함
-소규모 팀일 때는 실무를 담당하다가 규모가 어느 이상이 되면 점점 더 큰 단위의 작업으로 관점을 바꾸게 된다.
-개발 인원이 30명 미만의 초기 단계에서는 디렉터, 이후로 인원이 늘어나면 점점 프로듀서에 가까워진다고 할 수 있다.

2.PD가 하는 일 - 첫 번째 개발 제안

-첫 번째는 개발 제안
-제안에는 게임 컨셉, 개발에 필요한 비용, 단계별 달성 방법이 포함되어야 함

1) 게임 컨셉

2) 개발 비용

3) 개발 달성 방법

-개발 산출물을 확인하는 단위가 마일스톤이라는 것
-산출물은 플레이어블한 게임의 형태인 게 가장 좋고 이게 여의치 않으면 영상이라던가 리소스들의 이미지 그리고 기획적인 것들의 PT로 갈음(대신)하게 됩니다.

4) 요약

3.PD가 하는 일 - 두 번째 게임의 주요 요소를 디렉팅

1) 시행착오 사례와 통찰

a.개발 입문(로직 프로그래머) ~ 팀장

-당시 기획했던것, 기술 목표를 돌아보면 상당히 도전적인 것들을 많이 시도했어요. 15년 전이었는데 퀘스트 자동 생성하는 게임, 자동으로 동기화되는 네트워크 오브젝트기반으로 서버가 돌아가고 캐릭터 치마에 지글본이 아니라 천 물리를 도입하고 너무 무리수를 뒀어! 이게 돌아가긴 하는데 기존 방법보다 딱히 좋은 티가 안나는 거에요. 새로운 시도를 하더라도 작작 했어야지 가성비를 뽑는데 실패한거죠.
-그런데서 힘을 빼다 보니까 정작 컨첸츠 진도를 못 뽑고 일정 완수를 못하고 드롭되고 굉장히 뼈아픈 경험을 했습니다.
#주어진 상황과 한정적인 자원을 파악하고 목표 설정, 실행의 중요성?

-게임 개발은 상호보완관계?
-저의 경우에는 PM이나 관리 능력에 강점이 있는 동료가 바로 옆에서 보조를 해주는 편입니다.

b.PD 입문

-프로젝트가 드롭되긴 했지만 유능한 동료들과 시너지효과를 낼 수 있는 개발이 어떻게 돌아가는지 경험해봤다는 것
-앞서 관리 능력이 약점이라고 말씀드렸습니다만 당시 동료들이 제 부족한 리더십을 보완해줄 수 있는 분들이었고 그래서 목표를 명확하게 잡고 욕심을 덜어내고 일정대로 목표를 완수하는 개발을 했던 것 그리고 게임으로서는 좋은 결과를 만들어냈던 것이 10년정도 지났지만 아직도 좋은 기억으로 남아있다.

-개발 외적인 환경 변화에 PD로서 선제적으로 대처하지 못한 것
-당시 회사의 경영진이 바뀌었고 신규 프로젝트 투자 여력이 줄고 있었는데 그럼에도 저는 개발 진도만 잘 뽑으면 되는 거라고 생각했다. 순진했달까, 안이했다.
-사실 지금 돌아봐도 이런 상황은 풀기 어려운 문제라고 생각한다. 하지만 긴밀하게 경영진과 관점을 맞추고 교감을 했다면 다른 결과가 있지 않았을까 하는 아쉬움은 계속 남아있습니다.
#PD는 게임 개발 내적인 부분과 외적인 부분(지속적인 게임 개발을 위해) 팀원들을 이끌고 매니징하고 외부로는 팀과 게임 개발 프로젝트가 유지될 수 있게 외교같은? 것도 해야하는 군

-게임 개발이라는 것이 회사 입장에서는 사업 투자에 속하는 것이기 때문에 경영진의 투자 관점에 부합하는지 마일스톤만 진행할 것이 아니라 끊임없이 확인해봐야 한다.
-투자에 충분한 이유가 있고 그 이상의 가치를 만들 수 있다는 공감대가 있어야 되는거구요
-이때 생긴 지론: 개발 허들 자리에서 PT만으로 프로젝트 드롭이 결정되지 않습니다. 허들은 이미 난 결정을 확인하는 자리라고 생각을 하게되었습니다.
>>> 허들 자리에서 아무리 잘해도 경영진이 드롭을 마음 먹었기 때문에 드롭을 막을 수 없다?

c.PD로 게임 개발1

-B6 이후에는 PC MMORPG보다는 모바일로 해보고 싶은 마음이 강해져서 당시 확산성밀리언아서라는 게임을 굉장히 재미있게 했었거든요. 그래서 모바일 캐릭터 컬렉션 게임을 만들되 본인이 가진 캐릭터 덱을 써서 다른 플레이어들과 MMORPG의 레이드 하는 식으로 실시간 협력 전투를 할 수 있도록 하면 굉장히 재미있을 것 같다고 착안해서 시작한 프로젝트였다.

-처음 생각했던 것보다 좀 마니악한 게임플레이가 되어 버리긴 했는데 출시하고 4년 정도 라이브 서비스할 수 있었던 것, 플레이어분들의 다사다난한 사고가 있었지만 사랑을 받으면서 서비스를 할 수 있었다는 것은 굉장히 좋은 경험이었고요.

-엣지는 구현할 수 있었지만 장기적으로 서비스할 수 있는 성장 기반들과 플랜을 갖추지 못하고 출시를 했었거든요. 그리고 그 원인을 돌아보면 엣지뿐만 아니라 게임의 전반적인 기능 요소들을 균형있게 개발하지 못했던 것이 컸던 것 같습니다.
#라이브 서비스 게임은 장기적 서비스를 위한 게임의 코어 컨텐츠 싸이클이 필요한 듯, 그래야 유저들이 계속해서 즐겨주기 때문에

-제안에서는 엣지를 어필하고 마일스톤을 달성하는 것이 중요하지만 실제로 출시를 하고 서비스를 하려면 서비스 장기 플랜을 갖추고 출시해야겠구나, PD가 엣지만 파고 있을 게 아니라, 더 큰 시야에서 게임의 형태를 잡았어야 되는 것이 아닌가? 그러려면 엣지만 파고 있을 게 아니라 좀 더 일찍 업무를 위임하고 큰 시야에서 볼 걸 그랬다는 생각이 들었습니다.

d.PD로 게임 개발2

-큐라레 직후에 사실 모바일 프로젝트를 하나 더 진행했었는데요. 당시에는 어떤 쪽으로 가는게 맞을지 확신을 갖지 못했던 것들이 있어서 자진 드롭했었고요.
-그래서 그 다음에 '명확하게 하고 싶은 걸 해보자' 어떻게 보면 사심을 가지고 생각했던 프로젝트가 포커스온유였습니다.
-코스프레 사진 찍던 경험을 살려서 촬영하는 게임 플레이가 중심인 VR 미연시를 만듬
-VR 개발은 처음이라 개발 들어가기 전에 제안서를 쓰기 전에 선행 R&D(연구&개발)를 했어요. 여기서 시행착오를 했었지만 막판에 이렇게 하면 되겠다는 감이 왔고 그렇게 만들었던 첫 번째 스테이지 데모가 호평을 굉장히 많이 받아서 이후에는 탄탄대로로 개발을 할 것 같았는데 출시까진 못 보고 개인 사정상 도중에 퇴직을 했음

e.PD로서 게임 개발3(현재 프로젝트, 블루 아카이브)

---

4.PD가 잘해야 하는 것(잘하지 못하면 프로젝트가 산으로 가거나...)

-PD가 여러 가지 잘할 수 있으면 좋죠. 기술적으로 강점을 가진 PD가 있고, 아트에 강점을 가진PD, 기획에 강점이 있는 PD 등 커리어에 따라 강점이 있는 분야는 다들 다를 거라고 생각합니다.
-하지만 제가 생각했을 때 PD가 해야 되는 제일 중요한 것들 잘하지 못하면 프로젝트가 망가지거나 드롭될 수 있는 것들을 꼽아봅니다.

-중요하다고 생각하는 순서대로

1)경영진의 신뢰 획득

-비용 추산이 꼭 필요함. 회사 입장에서 보면 개발 프로젝트가 들어간 비용 이상의 수익을 낼 수 있다는 기대를 가지고 프로젝트를 시작하는 것.
-개발이 시작되면 시간에 따라 이 비용은 자동적으로 꼬박꼬박 매달 적립됩니다. 자비가 없어요.
-PD는 이 비용이 가치가 있다는 증명을 해서 꾸준히 회사의 기대치를 유지할 필요가 있습니다.
>>그러려면 계획했던 마일스톤을 차근차근 달성해야 함

-계획대로 게임을 개발하는 것이 사실 참 어렵다. 특히 마일스톤을 타이트하게 잡았다면 굉장히 힘듭니다.
-경력이 부족했던 시절 뼈저리게 얻은 교훈: R&D라고 적고 시행착오, 새로운 시도라고 읽는 것이 마일스톤에 포함되서 주 달성 목표가 되면 굉장히 힘들어짐
-그래서 게임이 다 정해져 있는 기획과 구현 레퍼런스에 따라 리소스만 양산해서 완성하는 거라면 마일스톤 달성이 그나마 용이할 텐데 새로운 것을 넣고 싶어지잖아요? 그러면 일정을 마음대로 정하기가 쉽지 않아요.
-제 경우는 1)R&D가 필요한 부분은 프로젝트 제안서 쓰기 전에 미리 해두거나 2)시행착오를 고려해서 프리프로덕션 기간을 쉽진 않지만 충분히 마련해 두거나 3)마일스톤 목표에서의 우선순위를 낮춰서 잘 안되면 포기할 수 있는 요소로 간주해서 진행하는 퇴로를 마련해두는 정도의 보안책이 있을 것 같습니다.
#게임 개발은 돌이킬 수 없는 시작이니까 시작하기 전에 내가 해낼 수 있는 것들을 미리 준비해두고 가야하는 느낌
시작하고 가면서 배우지! 가면서 알아가면 되지! 하면 예측불가하기도 하고 그 만큼 시간과 비용을 소비하기 때문에 확실히 준비하고 할 수 있는 없는지 미리 파악하고 어떤 부분을 이용할 수 있는지 숙달해두고 가야함. 아니면 비중을 크게 두지 않고 잘되면 좋은 보너스 느낌으로 비중을 두거나
>>>전쟁에 비유하면 적과 전투를 하기 위해 군단을 꾸렸는데 출정하기 전에 불확실한 기술과 미숙달된 전술, 병사들을 실전에서 사용하면 그만큼 손실이 크다. 그래서 출정 전에 최대한 병사들을 훈련시키고 물자를 준비하고 장비들도 품질을 유지하고 출정하여 전투를 하는게 승리할 가능성이 높다. 그리고 크게 실패해도 상관 없는 자원이라면 잘되면 좋고 안되면 다른 걸로 하면 된다. 이런 생각으로 접근하면 될 듯
-개발 마일스톤을 어떤 식으로 나누고 결과를 내기 위해 어떤 프로세스를 쓰느냐 까지는 발표 범위를 벗어나므로 자세히 설명하지 않겠습니다만 어쨌든 프로젝트의 책임을 지는 입장이기 때문에 온갖 잡일을 포함하여 마감을 지키고 마일스톤에 맞춰서 결과물을 PD는 만들어 내야만 합니다.

-실제로는 마일스톤을 계획대로 진행하는 것만으로 충분하지 않았음
-더 중요하게 챙겨야하는 것은 프로젝트를 보는 경영진의 관점 = 비전
-프로젝트를 시작했을 때와 1년, 2년 후 그 관점이 굉장히 달라질 수 있다.
-경영진의 관점이 달라지면 프로젝트를 평가하는 기준도 달라질 수 있다.
-평가 기준이 달라진다면 기존에 계획했던 대로의 마일스톤 달성은 의미가 없어질 수 있다.
-그렇기 때문에 PD는 경영진의 관점을 민감하게 확인할 필요가 있습니다. 경영 관점에서 프로젝트에 리스크가 될 것 같다고 생각하는 것이 있는지, 만들고 있는 결과가 관연 회사가 바라고 있는 방향과 맞는지 확인해야 한다.

-만약 회사의 경영 관점과 프로젝트가 나가는 방향이 어긋난 상황이라면 마일스톤을 계획대로 진행하더라도 감점이 누적되고 어느 순간 심판의 날(드롭)이 찾아온다.
-마일스톤 결과를 평가하는 자리를 허들이라고 함
-PD는 프로젝트 방향이 경영 관점에 맞는지 지금 득점을 하고 있는지 감점을 받고 있는지를 계속 피드백 받고 필요하다면 기존 마일스톤 계획을 적극적으로 수정해야 합니다.
-정기적으로 경영진에게 물어보고 확인하고 어필하는 자리를 갖는 것이 제일 좋다.

2)좋은 동료를 구하는 것

-마일스톤마다 기획자 몇 명, 프로그래머 몇 명, 아트 몇 명... 단순히 숫자를 채우기만 하는 것은 의미가 없다.
-좋은 동료 = 프로젝트를 캐리할 수 있는 동료를 구해야 함
-게임의 품질, 완성도, 재미같은 걸 좌우하는 요소가 뭘까? 생각해보면 게임 엔진? 충분한 개발 기간? 개발 프로세스? 이런 것들도 퀄리티에 기여하는 부분이 있지만 결국은 맨파워가 핵심입니다.
-앞서의 경영진과의 신뢰 관계 구축이 프로젝트가 생존하기 위한 기본기라고 하면
-게임이 어느정도의 품질로 만들어져서 출시할 수 있는 것은 전적으로 얼마나 좋은 동료와 일할 수 있느냐에 따라 달려 있습니다.

-특히 프로젝트의 초기 멤버가 중요함
-초기 멤버들과 함께 개발 방향을 정하고 이분들이 이후의 프로젝트 리드를 맡게 되고 대부분의 경우 그대로 프로젝트 끝까지 함께 하게 됩니다.
-제일 좋은 건 처음부터 믿을 수 있는 동료들과 함꼐 시작하는 거겠지만 프로그램, 아트, 기획, 파트별로 다 갖춰서 형편 좋게 시작할 수 있는 기회는 거의 없다.

-그럼 PD는 어떻게든 좋은 동료를 구해야 한다.(매우 어려움)
-회사에 들어오는 이력서만으로 리드급 멤버를 뽑을 수가 없어요(회사마다 다르긴 함, 큰회사는 어드밴티지 있음)
-필요하기 때문에 절실하게 다양한 수단으로 구인활동을 하게 됨

-이렇게 되면 안정적으로 개발 파이프라인이 돌아가게 됨
#자동 사냥할 사냥터에 필요한 캐릭터 레벨과 조합+장비+스킬 셋팅하고 자동 사냥 돌리는 느낌???

-PD도 인간이기에 강점, 약점이 있다. 하지만 PD의 약점은 프로젝트 전체의 리스크가 될 수 있기 때문에 동료를 통해 약점을 보완한다.
-개인적인 사례: 저는 내향적인 성격이라 외향적인 커뮤니케이션을 하는 동료가 주기적으로 태클을 걸어 주는 것이 조직 전체로는 좋았고 제가 부족한 관리 부분을 챙겨줄 수 있는 동료가 꼭 필요하더라고요.
-특정 직군, 특정 포지션을 충원하는 것도 중요하지만 PD 본인의 약점을 알고 이를 보완할 동료도 중요하다.

3) 선택과 집중

-PD가 게임 요소를 감독함
-감독: 계속되는 선택과 집중, 머릿속에 있었던 게임을 실체화하기 위해서 무엇을 취하고 무엇을 버릴까? 이것을 반복해서 무엇이 이 게임의 핵심인가를 정하고 지켜나가는 것

-모에 XCOM 만들기! 대체 뭘 어떻게 만들고 싶은 건지 알기 위해서 피디로써 엑스컴에 대한 얘기를 하며 다양하게 페이퍼 프로토타이핑을 해보자고 함 >>> 이후 선택의 고통이 시작됨

-이렇게 해보면 어떨가? 하는 니즈 별로 다양한 프로토타이핑, 가상 스크린 샷, 기획 작업을 진행함
-이 중에서 결국은 선택을 해야하고 이 과정에서 뭘 우선순위에 두고 뭘 버리고 게임을 어떻게 만들 것인가를 정하게 됐습니다.
#쿠키런 킹덤에서도 추구하는 방향성을 확실히 알기 위해서 프로토타이핑을 했음

-이 과정이 즐겁진 않다. >>> 정답이 없기 때문에
-나름 논리에 기반하여 선택을 하지만 여기에 남들이 해본 적이 없는 선택지를 넣으면 정말 고르기 까다롭다. 그걸하면 안되는 백 가지가 넘는 합리적인 이유를 듣게 된다. 이렇게 저렇게 해서 안 하는 것이다. 안 하는 것에는 다 이유가 있다.
#이 부분도 쿠키런 킹덤에서 SNG+RPG라는 새로운 장르로 개발할 떄 상황과 유사함, 쿠키런 킹덤에서는 지속적인 설득과 이미지화를 통해 방향성을 설득하고 일치화시킴
-그래서 쉬운 길이라고 하면 그런 어려운 선택지를 안 만드는 거긴 한데 저는 PD라면 한 두개 정도는 그런 걸 차별화 포인트를 살려야 한다고 생각하는 편이라서 힘든 지점이 생기더라고요.
-그래도 꼭 필요하다면 선택을 해야죠. 리스크를 지더라도 결과를 만들어 내는게 PD의 역할이라고 생각합니다.
#전쟁과 전투하고 비슷한 상황이 많네... 목표 달성을 하기 위해선 위험을 감수하고 도전할 필요가 있다. 그렇게 하기 위해선 다양한 정보를 분석해야 하지만(주어진 자원, 환경, 지형, 나의 강점/약점, 적의 강점/약점)

-PD는 그 선택지가 유효하다는 것을 증명하기 위해 정말 많은 에너지를 쏟을 필요가 있습니다. 사실 잘 안돼요. 어느 이상 안 되면 포기하거나 돌아가야만 합니다. 이렇게 해보면 될 것 같은데를 n번 하다가 보면 길을 잃고 헤매게 되니까요.
어디까지 해본다는 선은 확실히 그어 둘 필요가 있습니다.
-다행히 그런 시도 중에 PD의 선택지가 유효해서 살릴 수 있다는 결론이 난다면, 게임의 핵심요소로 가져갈 수 있겠죠.

-그리고 선택한다는 것은 결국 다른 것을 포기한다는 것입니다.
-블루 아카이브에서는 전투에서 캐릭터가 매력적으로 보이는 것을 최우선 순위에 두었고 이에 딸린 요소로 은폐, 엄폐하며 이동하는 전투를 선택했습니다. 다른 것들은 어느정도 타협을 하기로 했죠
-실제 선택 과정은 많이 복잡했습니다만 많이 단순화 시켰구요.
-처음에 생각했던 캐릭터가 많이 나오는 반자동 총격전에 이 요소를 더해서 '모에 엑스컴'이라는 것의 최종 개념도는 이렇게 정리 되었습니다.

-실시간으로 파티 캐릭터들이 지속적으로 은엄폐 전진하면서 총격적을 하는 게임이 되었다.
-캐릭터 수와 화각을 고려하면 6등신을 포기하고 SD로 가야 했고요
-캐릭터 스킬은 직접 사용하되 캐릭터 이동은 자동으로 진행되도록 할 수 밖에 없겠다고 선택했습니다.
-당시 이것이 최선의 선택이었는지는 모르겠습니다만 지금 돌아봐도 다행히 크게 틀린 선택은 아니었던 것 같다.
>>> 판단 기준이 뭐지? 이건 느낌으로 생각하신건가?

-PD는 프로젝트 내내 다양한 선택을 하고 책임을 집니다.
-게임이 어떻게 실체화될 지 뿐만 아니라, 무엇을 우선하는 조직을 만들지, 일정을 우선할지, 멘탈 케어를 하면서 조금 쉬어갈지, 비주얼에서 스타일을 추구할지, 정합성을 추구할지, BM을 추구할지, 정답은 없다.
-하지만 왜 그런 선택을 하는지에 대한 PD의 주관과 논리가 어느 정도 일관되게 유지할 필요가 있습니다.
-그리고 선택은 틀릴 수 있는데 이 경우는 빠르게 고백하고 수정하는 과정이 필요합니다.
= 빠른 정보 공유(피드백)와 수정

---

5.PD가 하지 말아야 하는 것(프로젝트를 망치는, 빠지기 쉬운 함정)

1) 일정의 낙관

-낙관적으로 추산하다가 삐끗하면...

-대처 방법은 일정을 비관적으로 추산하자도 있겠지만 몇 가지 예를 들어보면
-PD가 게임 요소, 예를 들어 타격감이라는 것을 설정하고 그 품질 목표 마일스톤 안에서 달성하는 것을 설정했다면 본인이 그 목표를 달성하는 과정을 디테일하게 챙겨야 합니다. 어떻게 조정해야 그 목표를 달성할지는 PD만 판단할 수 있는데 이 피드백이 느려지면 일정을 지킬 수 없기 때문입니다.
-대신 이 과정에서 담당자들의 업무 부하가 높아지게 되기 때문에 별도의 케어를 할 필요가 있고요.
-그리고 PD가 각 일정의 목표를 우격다짐으로 설정할 것이 아니라 PM과 같은 일정을 관리하는 동료의 현실적인 피드백에 기반해서 목표를 설정해야 합니다.
-그리고 매 일정마다 얼마나 우리가 앞으로 갈 수 있었는지를 측정해서 다음 일정 계획에 고려하는 것도 피드백의 정밀도를 높일 수 있는 방법입니다.

2) 마이크로 컨트롤

-바로 전 페이지에서 품질은 직접 챙겨야 한다고 얘기했는데 바로 말을 뒤집네? 라고 하실 수도 있을 것 같은데요. 개발 초기에 PD가 강점을 가지고 있는 부분을 직접 챙기는 것, 예를 들면 타격감이라는 것을 위해 필요하면 코드를 작성하고 테이블을 고치고 직접 결과물을 컨트롤하는 것은 개발 진행에 도움이 될 수 있습니다.
-하지만 조직이 커지고 개발 진도가 나가면서 챙겨야 할 게임 요소들이 늘어나면 PD는 이런 판단 권한을 위임해야 합니다. 왜냐하면 개별 요소의 품질보다 조립된 게임으로서의 방향성이 훨씬 더 중요해지기 때문이죠

-그런데 위임이라는 것이 쉽지만은 않은데요. 감정적으로도 PD가 직접 챙기는 게임 요소, 앞서 타격감을 들었습니다만, 이걸 타이밍이던 이펙트던 직접 튜닝해서 괜찮은 결과를 얻었어요. 그러면 본인이 챙겨서 더 좋은 결과를 내고 싶은 생각이 들 수 있습니다. '이건 내가 챙겨야 돼' 함정이죠
-이런 상황이 되면 타격감을 실제로 챙겨야 할 담당자, 기획자가 될 수도 있고 이펙터가 될 수도 있겠습니다만 그분들은 스스로 타격감이라는 것을 판단하지 못하고 또 판단하지 않으려고 하게 되면서 PD 없이 돌아가지 않게 되는 조직이 됩니다. 그래서 위임하기 더 어려워지는 악순환이 되죠
-이거 손을 떼도 될까?라고 PD가 걱정을 하게 되는데

-하지만 사실은 PD가 없어도 잘 돌아갑니다. PD가 생각한 품질 목표가 타격감이라는 것이 뭔지는 한 번만 맞춰보면 됩니다. 손을 떼고 위임을 하는 편이 실제로는 결과물이 더 잘 나왔던 것 같아요. 그게 정상이고요.
-pd가 들어가는 실무 회의도 점점 줄여야 합니다. 블루 아카이브도 처음에 기획 회의 전부 들어가다가 프로덕션 단계 들어가니까 기획 실장 아저씨가 'PD님 이제 회의 다 들어오는 건 그만하세요'라고 해서 아쉬웠었는데요. 하지만 그게 맞죠.
-프로젝트 진도가 나갈 때마다 PD는 한발씩 뒤로 물러서면서 게임을 전체적인 방향성을 살펴야합니다.
#방향성을 한 번 맞추고, 바운더리 알려주고 위임하기?

-방향을 잘 잡았고 위임이 되어 있다면 개발 중간에 PD가 빠져도 게임은 출시될 수 있는 겁니다.

3) 깨진 유리창 방지

-깨진 유리창 이야기를 개발에서도 새겨볼 필요가 있다고 생각합니다.

-프로젝트가 1년 이상 넘어가면 조직으로서의 취약점이 조금씩 생기게 됨. 방치하다가 악화되는 경우를 여러 번 경험함
-업무적인 문제면 문제를 발견하고 해결하는 것이 비교적 용이하겠지만
-그 중에서 사람들 사이의 문제가 제일 어려운 것 같습니다.
-크게 나눠서 보면 조직 간의 업무 방식과 이해 관계가 충돌하거나 서로 엇박자가 계속되는 문제가 생길 수 있고요
-그리고 구성원들 사이의 갈등, 불화가 생기거나 하는 경우들을 들어볼 수 있을 것 같습니다.

-이런 것들은 문제를 발견하는 것도 어렵고 말을 꺼내는 것도 조심스럽고 그래서 일단 좀 더 두고 보자 하게되는 경우도 많은데요. 그대로 방치하면 점점 고질적인 문제가 되어서 조직 전체의 리스크가 될 수 있습니다.
-언제부터인가 동료들이 말없이 하나둘씩 나가는 거죠. 그러기 전에 조치를 취해야 합니다.

-제가 둔감해서 그런지 몰라도 제 생각에 '이거 걱정 해야 되나?' 생각이 들 정도면 이미 많이 진행된 거더라고요.
>>> 빠른 대응이 필요합니다.
-기본적으로는 면담입니다만 내부에서만 끙끙댈 것이 아니라 인사팀과 상의하는 편이 더 부드럽게 진행되는 경우가 많더라고요.
-인사팀은 조직 내에서 해결하기 힘든 경우에 대한 옵션을 많이 가지고 있습니다.

---

6.해보니 좋았던 것(직무 수행에 도움이 되었던 것 두가지)

1) 스테이지1 제작

-프로토타입 구현 후 체험 해보기

-상상도를 실제로 게임으로 구현해보는 과정
-뷰를 바꿔 본다거나, 적들 타입을 어떤 식으로 배치할지, 엄폐물을 어떻게 배치해볼지, 엄폐를 시키는 테스트 등 다양하게 진행해봄

-테스트 결과를 다듬고 비주얼적 노림수를 넣어서 2018년 연말에 스테이지 1 완성함
-이 빌드 덕분에 스튜디오 내외부에 어떤 게임을 만들 것이라는 비전 공유가 확실해 됐다.
#백문이 불여일견

-예전에 재미있게 했던 다른 분들이 만든 게임에서 경험했던 것과 비슷한 흥분이나 신선함을 내가 만든 게임에서 느끼게되면 정말 신나죠
-PD가 개발에서 선택을 하고 책임을 지는 것이 중요하다고 말씀드렸는데요. 그 결과로 이런 긍정적인 경험을 할 수 있다면 PD 입장에서도 개발하는 게임에 더 확신을 가지고 앞으로 나갈 수 있습니다.
#잘하고 있는 건지 정답이 없는 목표와 노력을 스테이지 1을 통해서 실체화하여 피드백을 확인해서 잘 되기 위함인 듯
-그리고 이 경험을 내부, 외부에 공유를 할 수 있고요. 그래서 저는 가능한 빠르게 선택을 하고 빠르게 스테이지 1에 해당하는 노림수가 들어간 결과를 만들어 보시기를 권하고 싶습니다.

2) 지속적인 메시지 전파

-왜 이 프로젝트를 시작했고, 무엇을 지금 만들고 있으며, 앞으로 어떻게 만들어 갈 것인지 PD는 알고 있죠. 그런데 동료들 모두가 같은 온도로 인식하고 있지는 않으니까 특히 팀이 커질수록

-구체적인 예로 저희 스튜디오에서는 전원을 대상으로 매주 월요일 오전에 주간 리뷰 PT를 진행하고 있습니다. 지난 주에 우리가 뭘 만들었고 이번 주 주안점은 무엇이고 얘기함
#지속적으로 게임 개발 방향성을 공유? 같은 방향성을 가지고 개발할 수 있게
-텍스트가 너무 많으면 집중도가 떨어지기 때문에 짤방, 아트 결과물 위주로 정보를 배치하고(백문이 불여일견+유머러스함? 밝은 분위기?) 텍스트가 필요한 부분은 중요한 공유 사항 위주로 요약해서 전달하는 브리핑입니다.

-특정 토픽 위주로 담당자들 사이에서 공유해야할 사항은 별도로 공유하는 자료를 만들어서 PT를 하고 있는데 이 부분은 저희 AD님이 워낙 잘해주고 계심(블루 아카이브 아트 디렉팅 글 참고)

-저희 조직의 경우 회의 내용(회의록) 특히 기획 회의는 전부 원노트에 기록해서 검색할 수 있도록 하고 있는데요.
-개발 히스토리 검색할 때, 누가 어떤 과정으로 어떤 결정을 내렸는지 추적할 수 있는 게 굉장히 유용하더라고요.
#와... 매우 이상적인 개발 시스템이다...!!!
-너무 기본적인 내용이라서 어디서나 쓰고 계실 것 같은데 Slack도 적극적으로 사용하고 있습니다. 취미 생활별 채널까지 포함하면 저희 스튜디오 인원보다 개설된 채널 수가 더 많더라고요. 물론 개발 스튜디오마다 분위기는 다를 수 있겠습니다만 저의 경우는 꾸준히 전체 브리핑을 하고 개발 내역을 공유하는 것이 팀웍을 다지는 데 큰 도움이 되고 있다고 판단하고 있음

---

7.요약