프로젝트 운영

오늘은 프로젝트 운영에 대해 글을 작성하려고 한다.

프로젝트를 운영하다 보면 많은 고충과 고민에 시달리게 된다.

대기업의 큰 프로젝트는 아니지만, 작은 프로젝트 운영에도 많은 일들이 벌어진다.

 

프로젝트 운영은 단순 게임을 만들고 출시하고 업데이트하는 것이 주이기는 하지만

개발 일정 관리부터 시작해서 결정, 논의, 데이터 그리고 휴먼 매니징까지

많은 부분이 포함되고 이를 관리/감독해야한다.

 

위와 같은 것들을 진행하면서 나는 어떻게 하고 있는지 

그리고 어떤 생각과 고민을 하면서 진행하고 있는 지에 대해 글에 녹이려고 한다.

 

이번 글은 저연차의 PD / 개발과 라이브 옵스의 글과 매우 비슷한 맥락이 될 수 있으나

좀 더 상세하게  프로젝트 운영 부분에 있어 상세히 적어보려고 한다.

저연차의 PD — 오늘도 기획자는 된다고 말했다

저연차의 PD

개발과 라이브 옵스 — 오늘도 기획자는 된다고 말했다

개발과 라이브 옵스

 

아래의 글과 겹치는 부분도 있고, 아닌 부분도 있을 것이다.

---

 

게임 개발

 

방향성

게임의 개발부터 라이브까지의 방향성은 프로젝트 운영에 있어 가장 중요한 일이다.

 

우선 라이브 서비스를 진행할 때의 방향성부터 말해보겠다.

 

라이브 서비스에서 게임의 방향성을 설정할 때는

현재 우리 프로젝트가 어떤 상황인지를 아는 것이 중요하다.

이것을 접근할 때는 [나의 직감] 보다는 [데이터]를 신뢰해야 한다.

 

프로젝트 운영에 있어 방향성을 짤 때 직감만 믿으면 안된다.

데이터를 기반으로 방향성이 필요하다.

데이터와 직감을 굳이 비율로 따져보자면 8:2 비율로 가져가야한다.

예를 들어 광고 시청률이 좋지 않다거나, 매출이 좋지 않은 것을

알고 있어야하고 어디가 왜, 어디서 안좋은지도 알아야하고

그걸 기반으로 업데이트 방향성을 짜야한다. 직감으로만 진행한다면

그냥 나만 재밌는 게임이 될 가능성이 높고 실패 할 가능성이 높다.

그렇기에 직감보다는 무조건 데이터를 신뢰해야한다.

이 때문에 내가 A/B 테스트를 집착하는 이유도 있다.

 

한가지 예로, 내가 "우리 게임 너무 쉬운 것 같은데?"라고 생각해본다고 하자.

해당 게임을 기획하고, 개발하고 매번 플레이 및 테스트를 하는 나한테는 쉬울 수 있지만,

유저에게는 쉽지 않을 수 있다. 그래서 절대적으로 [주관]보다는 [객관]에 힘을 써야한다.

 

이 객관에 힘을 쓰려면 데이터들을 추적 및 분석하여

현재 우리 게임이 어떤 방향으로 나아가야 할지,

그리고 어떤 것들을 개선하고 추가 해야할 지 고민해야한다.

 

A라는 컨텐츠를 핵심 요소라 생각하고 집어넣었는데 이게 잘 돌아가지 않는다.

그럼 이것을 포기해야 할까? 계속해서 개선해야할까?

이것 또한 데이터로 판별해야한다.

데이터로 판단했을 때 이를 개선하면 게임의 수명이 늘어난다고 확신이 들었을 경우

이를 장기적인 개선 목표로 잡고 방향성을 잡아갈 수 있을 것이다.

 

또 하나를 예시로 들어, 특정 컨텐츠를 플레이하는 유저들은

안하는 유저들보다 리텐션이 더욱 좋나?

혹은 매출적인 지표(ARPU, PUR)이 좋나? 만약에 좋다면?

이 컨텐츠를 플레이 안하는 유저들에게 플레이하게끔 유도하는 방법을 생각해볼 수 있다.

 

위와 같은 예시로 게임의 방향성을 설정하는데 있어서는

부족한 부분들을 계속해서 파악하고 있어야한다.

그렇게 알고 있어야만 필요할 때 간식 꺼내먹듯이

해당 부분들을 상세적으로 분석하고 분석 결과 토대로 방향성을 결정하고,

그 방향성 내에서 어떻게 행동해야할지

더욱 풍부한 생각과 고민들을 통해 확장해 나갈 수 있을 것이다.

 

당연하게도 이러한 고민들을 하다보면 심오하게 빠지기 마련이다.

이런 고민 속에 같여 헤메다보면 잘못된 판단도 할 수 있다. 그렇기에 혼자만 해서는 안된다.

나를 제외하고 이 게임을 잘 아는 사람들이 누가 있을까? 바로 팀원들이다.

 

첫번째로는 당연히 프로젝트를 운영하는 사람 입장에서

혼자 고민을 하고 방향성을 결정해야한다.

이러한 방향성에 대해 정말 맞다! 라고 생각한다면 진행해도 무방하지만,

정확한 확신이 들지 않았다면 팀원들과 함께 생각한 방향성에 대해 의견을 물어보고 논의해야한다.

그렇게 논의하다보면 더욱 좋은 방향이 떠오를 가능성이 높다.

 

하지만, 팀원들이 이런 방향성에 대해 생각하지 못할 수 있다.

그렇기에 팀을 운영함에 있어, 항상 팀원들이 방향성을 생각할 수 있는 사람이 될 수 있게

이를 유도해야한다. 계속해서 테스트를 요구하고, 데이터를 깊게까진 아니더라도

현재 우리 게임이 어느정도 인지 확인할 수 있는 수준의 지식 수준까지 끌어올려줘야한다.

 

추가로 마케팅에 대한 이해도도 있어야한다.

특정 매체의 마케팅을 돌렸는데 CPI가 낮아 저퀄리티 유저들이 갑자기 많이 들어와

지표가 휘청거린다면 그 게임은 갑자기 망했는가? 아니다.

그럼 반대로 CPI가 높은데 퀄리티 좋은 유저가 유입이 되어 지표가 좋은 경우

그럼 그 게임은 무조건 좋다고 판단할 수 있는가? 아니다

 

결국 ROAS도 봐야하고 LTV도 봐야하고, 어떤 캠페인인지 어떤 유저군인지도 알아야한다.

정말 다방면에서 고민이 필요하고, 판단을 해야만 한다.

현재 지표가 게임 자체에 문제가 있는건지 아니면 마케팅으로 인해 문제가 있는건지

이러한 지식들을 기반으로 단편적으로만 데이터를 봐서 잘못된 선택과

오해하지 않는 눈을 키워야한다.

 

자, 그러면 개발(신규 프로젝트)에서는 어떨까?

 

최근 담당하고 있던 팀이 스튜디오화 되면서 규모가 더 커질 예정이다.

그렇게 신규 프로젝트를 하나 더 하게 되면서 양방향을 돌리기로 결정됐다.

그래서 현재 내 시점에서 가장 큰 고민이다

신규 프로젝트에서는 [어떤 게임을 만들어야하는가]에 집중하고 있다.

이 게임은 어떤 유저 타겟인가? 어떤 성별인가?

어떤 장르여야 하며 어떤 게임이어야 되는 것일까?

이러한 꼬리의 꼬리를 물며 계속해서 고민의 크기를 키워나가며 정리한다.

 

첫 번째, 현재 게임 시장을 분석한다.

어떤 게임들의 상위권에 있는지, 어떤 지표를 내고 있는지

이러한 게임들을 플레이한다.

 

두 번째, 어떤 게임을 만들 것인지 고민힌다.

앞선 첫 번째의 현 시점 잘 나가는 게임을 레퍼런스 삼아

발전 시켜나갈지 혹은 아예 창작이 가미된 게임을 만들지

 

세 번째, 이 게임은 어떤 게임인지 생각한다.

무슨 장르이고, 누가 플레이 할지, 어떤 그래픽 풍과 시점을

보유하고 있는 게임인지, 무엇을 위한 게임인지

 

네 번째, 어떤 코어 시스템 및 핵심 요소를 가져야하는지 고뇌한다.

어떤 재미를 가져야할지, 얼마나 유저들이 이해하기 쉬울지,

이 핵심 시스템들을 기반으로 어떤 게임성을 가지게 할지

 

다섯 번째, 이 게임의 미래를 그려야한다.

얼마나 개발하고 소프트 런칭을 진행할지,

일정은 어느정도로 산정할지, 어떻게 발전 시켜야 할지,

이걸 앞으로 라이브 서비스 한다면 어떻게 발전 시켜 나갈지

 

위와 같은 고민 및 생각을 통해 게임의 방향성을 결정하고

기술적인 부분과 관리적인 부분에 대해서도 고민하고

이전 프로젝트에서 부족하고 아쉬웠던 부분을 어떻게 하면 개선할 수 있을지

회고하고 메모하고 이를 차기작에서는 꼭 실행해야만 한다.

 

최근 내가 게임 기획을 하고 운영을 하는데 있어

정말 많은 고뇌의 시간을 겪었고 어느정도의 기준이 확립이 되었다.

해당 내용에 대해서는 나중에 시간이 된다면 글 하나를 출고해보도록 하겠다.

 

마일스톤

앞서 방향성에 대해 정했다면, 이제는 마일스톤을 짜야할 것이다.

나는 마일스톤을 짤 때 크게는 상반기/하반기로 나누고,

그 안에서 각 한 달 혹은 업데이트마다로 상세 분배한다.

 

우리가 이 시점에서 [어떤 목표를] 가지고

[무엇을] 진행할지 이것은 [왜?] 해야하고

[어떻게] 할지에 대해 심도 있게 고민 후, 마일스톤을 설계해야한다.

 

설계가 다 되었다면 팀원들이 프로젝트의 미래를 같이 그릴 수 있게

큰 방향성을 잡아줘야한다. 그러기 위해선 이를 시각화 하여 공유해야한다.

나는 마일스톤을 시각화(PPT)하여 회의를 잡고 설명한다.

이어서 QnA를 진행하며 그들의 궁금증을 풀어준다.

그래야 다같이 한마음 한 뜻으로 프로젝트 개발 및 운영이 가능하다.

회의를 통해 잘못된 것이 있다고 판단 되거나, 수정해야할 부분이 있다고 판단된 경우

고민 후 즉시 수정 및 진행한다. 그리고 공유한다.

 

마일스톤을 기반으로 개발을 진행하다보면 

우선 순위가 바뀌어 핵심 개발 컨텐츠들을 한 두달 앞뒤로 바꿔야 한다거나

데이터 기준으로 A보다는 B가 들어가야만 좋다거나 의도치 않는 상황에 마주할 때도 있다.

그러한 경우, 이 또한 마일스톤을 빠르게 수정하고 팀원들에게 전파하여

프로젝트 운영에 문제가 생기지 않게끔 해야한다.

 

빠른 판단과 결정 이것은 프로젝트 운영에 핵심 중에 핵심이라 할 수 있다.

약간 논지에서 벗어나서 빠른 판단과 결정은

프로젝트 운영 뿐만 아니라 프로젝트 마감에도 필요하다.

프로젝트가 계속해서 운영이 필요한지에 대해 고민되고

더 확장하기가 힘들다고 판단된다면 심사숙고해서

프로젝트의 업데이트를 중단할지 결정하기도 해야한다

동일한 노력/시간/인력을 들인다고 했을 때 새로 시작하는게 빠를지,

이 게임을 개선해서 더 높이 치고 올라갈 수 있을지

고민하고 계속할지, 그만 둘지 판단을 해야한다.

쉽지않은 결정 일 수 있지만 그럼에도 불구하고

개인보다는 회사를 위해서 해야만한다.

 

상세 개발 일정 설계 / 배분 / 진행

마일스톤을 기반으로 일정이 진행될 때

상세 개발 일정에 대해서 이야기하고자 한다.

 

상세 개발 일정 설계는 마일스톤에 있던 내용들을 다 태스크로 만든다.

이 태스크들을 분배할 때 당연하게도 개발이 지연되는 상황이 나올 수도 있을 것이고

모든 것들이 못들어갈 수 있기 때문에 우선순위들을 지정해야한다.

A는 무조건 들어가야하는 것, B는 시간이 없으면 못하는 것과 같이 말이다.

 

그리고 일정을 진행할 때 병렬적으로 돌아갈 수 있게 해야한다.

순서대로 기다리면서 하다보면 시간이 촉박해질 것이다.

 

현재 내가 맡은 팀은 병렬적으로 돌아가기 위해서는 아래와 같이 한다.

UI 더미만 만들고 코딩을 할 수 있게 하고, 그 이후 디자인을 하게끔.

UI 더미를 만들 시간이 없다면 베이스 코드를 짜게하고 이후 더미 만들고 디테일 개발로.

캐릭터와 배경도 더미를 먼저 만들어 두고, 개발을 하고 이후 디테일을 잡거나.

서로가 일정 안에서 유기적으로 움직이며 업무를 할 수 있게 구조화해야한다.

물론 이 과정이 수월하게 진행되려면 기획은 미리 준비되어 있어야한다.

그래서 기획은 피쳐 1달 전에는 작성을 시작하고 완성 시킨다.

 

추가적으로 해당 과정을 문제 없이 빠르게 진행하려면

개발을 하는 과정 중 지속해서 맡은 일감이 어느정도 진행했는지 주기적으로 확인한다.

다음에는 무엇을 해야하는지 팀원들이 혼동하지 않게끔 명확하게 인지 시켜줘야한다.

 

하지만 이러한 것들이 자칫하면 마이크로 매니징처럼 될 수 있다.

마이크로 매니징이 된다면 팀원들은 자기 주도적으로 판단을 못하는 상황이 발생할 수 있다.

그렇기에 누가 어떤 일을 해야할지에 대한 것은 해당 파트가 2명 이상이라면

그들이 일정을 분배할 수 있게 하는 것이 좋다. 그래야 주도적인 모습이 나온다.

또한 그들의 작업물이 방향성에 벗어나는 것이 아니라면 인정해줘야한다.

그래야만 그들이 주도적으로 판단할 수 있는 [능력]이 생긴다.

(다만, 방향성에 많이 벗어난다면 이것은 바로 잡아줘야한다.)

 

일정을 진행하다보면 기술적 문제 뿐만 아니라 많은 문제점에 부딪힐 것이다.

이럴 때는 빠르게 고민 후 판단, 유기적으로 움직여야한다.

업데이트 피쳐가 A/B/C가 한꺼번에 들어가기로 했는데

우선 할 수 있다면 A/B만 먼저 잘라서 업데이트한다거나 

꼭 다 들어가야 한다면 일정을 미룬다거나,

A/B/C의 완벽함보다 약간의 덜어낼 수 있는건 덜어내서

업데이트한다거나 많은 방법이 있을 것이다.

 

약간 글이 너무 교과서적/이론적인 내용으로만 되어있는 것 같아서

어떤 상황에서 어떻게 했고, 자세한 예시를 설명하고 싶으나

글이 너무 길어지고 장황해질 것 같아서 이 점은 넘어가려한다.

---

휴먼 매니징

일과 관련이 있는 휴먼 매니징에 대해서 추가적으로 간단하게 이야기 해보려고 한다.

개발은 컴퓨터와 하는 것이 아니다. 결국 사람 대 사람으로

일을 하는 것이기 때문에 프로젝트 운영에 있어서 사람 간의 관계는 매우 중요하다.

 

가치관

사람마다 각자 다른 가치관을 가지고 있다.

돈에 욕심이 있는 자라면 돈으로 동기부여를 줄 수 있을 것이다.

성공과 명성/명예라면 성공을 동기부여를 줄 수 있을 것이다.

하지만 가정, 워라벨 등 본인의 삶에 더욱 집중하고 싶은 자들에게는

특별히 동기부여를 할 수는 없으나 그럼에도 불구하고

리딩을 하는 입장에서는 팀원들에게 원하는 태도 및 행동을 요구하기도 해야한다.

그렇지만 그들의 삶을 이해하기 위해서 밥도 가끔씩 같이 먹으며 이야기한다.

큰 업데이트를 마친 뒤에 팀끼리 커피챗 시간을 따로 가질 때도 있다.

때로는 1:1로 커피챗을 진행하며 이야기를 듣고 같이 말하는 소통 시간을 가진다.

팀원들과 우호적인 관계를 맺으려면 많은 대화가 필요하고

서로 시너지를 맞춰가는 시간이 필요하다.

 

그들의 삶을 이해하고, 어떤 것을 원하는지, 어디서 효능감을 얻는지

일을 할 때는 불편한 점이 없는지, 좋은 점은 무엇이고 나쁜 점은 무엇인지

이러한 것들을 서로 간의 알고 있어야만 팀이 더욱 건강하게 나아갈 수 있다. 

 

나이와 태도

내 나이는 97년생으로 현재 글을 작성하는 시점으로 많지는 않다

그렇기에 나보다 나이 많은 팀원도 존재한다.

당연히 리딩하는 입장에서 불편할 수 있다.

왜냐하면 한국의 특성상 나이를 무시할 수는 없다.

하지만 이를 신경쓰면 일이 진행되지 않는다.

 

나이가 많든, 적든 상관 없이 나이와 별개로 일을 할 때는 업무적으로 다가가야한다.

일 앞에서는 감정보다는 이성, 이성보다는 업무적으로만 철저히 접근해야한다.

그래야만 서로에게 상처가 되지 않고 잘 업무를 진행할 수 있다.

 

리더로써는 항상 오해가 쌓이지 않게끔 주의해서 행동해야한다.

일은 일로만, 개인적인 감정을 배제해야한다.

이를 상대방에게도 잘 인식 시켜줘야한다.

"쟤는 나 미워하나?"라는 생각이 들지 않게끔 말이다.

성공은 오로지 혼자하는 것이 아니다. 팀원이 있기에 할 수 있는 것이다.

---

마치며

한동안 글을 작성할 시간이 부족할 정도로 바쁘게 살아가고 있어

글의 업로드가 조금 늦었다. 그리고 어떠한 글을 쓸지도 고민도 했다.하느라 조금 늦어졌다.

다 쓴 시점에서 되돌아보니 이번 글의 퀄리티가 좋지는 않은 것 같다.

조금 상세하게 못 풀어낸 부분이 많아 아쉽기는 하지만

그럼에도 불구하고 계속해서 성장하고 있는 나의 모습을 기록하고 있고

누군가에게는 도움이 되지 않을까라는 마음으로 글을 마친다.