지금 네가 하고 있는 것은 프로토타이핑이 아니란다

게임 개발의 프리 프로덕션 Pre-Production 단계에서 프로토타이핑의 중요성에 대해서는 이젠 다들 알고 있는 눈치이긴 한데, 아직도 여러 경우를 살펴보면 프로토타이핑을 실수 혹은 고의로 오용하는 경우가 많다.

그중 가장 대표적인 것은 프로토타이핑으로 검증할 목표를 정확하게 잡지 않거나, 그저 개발의 필수적인 단계 Step 으로 여겨 그저 프로토타이핑을 흉내 내는 경우다. 그러니깐 이런 거다.

  1. 초기 컨셉이 잡혔으니, 이제 프로토타이핑을 해야지?
  2. (빠른 반복, 확인, 검증 과정 없이) 자, 프로토타이핑을 마쳤으니 이제 실 개발을 들어가자!

사실 이 정도는 귀여운 편이다. 프로토타이핑을 통해 실 제품의 모든 것을 검증하겠다는 (말도 안 되는) 목표를 설정하고 프로토타이핑에 각종 디자인, 리소스, 비즈니스 모델 등을 붙여서 사실상 실제품을 만든다. 가장 최근에 본 사례 중 하나는 위와 같이 사실상 출시 스펙으로 십수 명의 인력이 프로토타이핑 제작에 1년을 들이고는 (프로토타입이라는 이유로) 폐기해버린 것이었다. 거기에 들어간 시간, 돈, 그 밖에 여러 자원을 생각해보면 제정신인가 싶을 정도.

프로토타이핑 그까짓 것 대충하면 어때 같은 이야길 할 수도 있겠지만, 아에 프로토타이핑을 건너뛸 때 보다 더 큰 손해를 끼친다는 것이 문제다. 굳이 안 해도 되는 일을 왜 한단 말인가? – 물론 아예 프로토타이핑 = 실 제작으로 쓰는 경우라면 좀 다른 문제긴 하지만.

실제로 현재 진행 중인 개발 단계가 프로토타이핑인가 의심스럽다면 아래의 체크리스트를 확인해 보자. 하나라도 해당한다면 당장 프로토타이핑을 중단하고 원점에서 재고하기 바란다.

  • 프로토타이핑으로 검증하고자 하는 항목과 이를 위한 측정 방법이 구체적이고 명확하게 존재하지 않는다.
  • 전체 프로토타이핑 기간은 전체 프로젝트 기간의 1/10 이상 잡혀 있다.
  • 프로토타입 1회 제작 기간이 1주일을 훌쩍 넘긴다.
  • 프로토타입에서 제작하는 범위가 초기 컨셉의 전체를 아우르고 있다.
  • 프로토타입 제작에 대규모의 인원이 투입되어 있다.
  • 실제 개발에 사용할 툴 / 엔진을 프로토타입 제작에 사용 중이다.

덧: 게임 프로토타이핑에 대한 글은 여기를 참조하기 바란다.

프로젝트 관리 툴 결정하기

프로젝트를 관리하는데 있어서 어떤 확실한 정답이 없는 것 처럼 프로젝트 관리 툴을 선택하는 문제 역시 딱하나의 정답은 없다. 프로젝트의 성격, 팀의 크기, 개발 문화, 방법론 등 프로젝트 관리 툴을 선택하는데에는 여러 다양한 조건들을 참고해야 한다.

물론, 이쪽이라고 해서 유행이나 주류 같은게 없는 건 아니다. 아마도 2020년 현재의 주류는 소규모 팀이라면 트렐로 Trello, 대규모 팀이라면 지라 Jira 를 사용한다면 아마도 유행에는 뒤처지지 않는다고 할까. 물론, 요즘 가장 힙한 툴이라면 노션 Notion 아닐까 하지만.

트렐로 trello 는 이미 프로젝트 관리 툴의 대세로 자리잡은지 오래다

개인적으로 사실 툴은 무엇을 쓰든 큰 상관은 없다고 생각한다. 프로젝트 관리란게 막상 툴 이전의 더 큰 문제에 좌지우지되는 경향이 큰데다, 그간 여러 프로젝트를 겪으면서 부딪쳤던 문제는 툴 사용 보다는 ‘프로젝트를 관리해야 한다’라는 마인드의 주입에 더 많은 어려움을 겪는 경우가 많았으니깐. 사실 프로젝트의 목표가 명확하고, 큰 변동이 잘 있지 않고, 업무의 시작과 끝이 명확한 편이라면 힙하고 복잡한 개념의 새로운 툴을 익히느니 엑셀이나 구글 스프레드시트 같은 앱으로 이슈 테이블을 만들어 관리해도 충분하다. 물론 그런 프로젝트는 유니콘 같은 존재란게 문제지만.

프로젝트 관리 툴을 선택하는데 있어서 주의해야 할 점이 몇 가지 있다면 첫째는 유행을 쫓아 최신 인기의 툴을 무장적 선택하는 것. 그리고 둘째는 툴을 만능으로 여겨 “끝까지” 도입하지 않고 중도 포기하는 일일 것이다. 의외로 많은 개발자들이 이런 저런 최신 툴의 이용기를 보고, 최신의 프로젝트 관리 툴을 도입하기만 하면 모든 문제가 마법처럼 사라질 것이라는 기대를 품곤 하는 경우를 매우 자주 목격하게 된다. 하지만 프로젝트 관리 툴은 어디까지나 프로젝트를 관리를 조금이라도 수월하게 하기 위한 툴일 뿐이다.

최근의 업무에서 오픈소스 프로젝트 관리 툴인 레드마인 Redmine 을 선택하였는데, 이는 아래와 같은 이유 때문이다.

  • 대규모 프로젝트 지원 – 두자리에서 세자리가 넘어가는 개발자가 동원되는 프로젝트에서 이슈를 트래킹하기에 적합하다 판단. 비교 대상이었던 지라 역시 대규모 프로젝트를 지원하긴 하지만, 좀 더 애자일 Agile 한 조직에 세팅 되어 있는 부분이 현재 도입 프로젝트와는 맞지 않았다.
  • 설치형 – 프로젝트 조직이 개발 보안에 신경을 많이 쓰고 있는 관계로 외부 데이터 반출에 신경을 많이 쓰는 편. 여기에 더해 클라우드 방식의 경우 급작스러운 서비스 중단이나 장애에 대응하기 힘들다는 판단도 들었다. 물론 설치형의 경우도 이런 문제가 없는 것은 아니나 백업 솔루션을 취향에 맞게 만들 수 있다는 점으로 커버 할 수 있다.
  • 폭 넓은 사용자 층 – 별 다른 세팅이 필요없는 트렐로나 노션 정도를 제외하고, 지라든 레드마인이든 초기 프로젝트 세팅부터, 운영, 툴의 유지보수 까지 관리자의 손을 많이 타는 물건이다 보니 설치법, 사용 방법, 각종 플러그인에 대한 정보나 유지보수 정보를 쉽게 얻을 수 있는 녀석에 자연스럽게 눈길이 갔다. 물론 지라의 경우 유료 사용을 할 경우, 아틀라시안의 지원 서비스를 받을 수 있긴 하지만… 이런 지원 역시 만능은 아니란 건 알고 있기 때문에
  • 무료 – 사실상 프로젝트 매니지먼트 툴 선택에 있어서 비용을 들인다는 것은 많은 부담을 가져오기 마련이다. 게다가 어떤 툴이 되었든 정착에는 시간이 들기 마련이다. 조금이라도 비용을 줄일 수 있다는 건 무시 못할 장점이다.

위의 이유는 어디까지나 어떠한 하나의 프로젝트 / 조직에 맞춰진 한정적인 이유일 뿐이다. 실제로 검토했던 많은 툴들의 기능은 모자라거나 부족함이 있었던 것이 아니라 툴에서 추구하는 프로젝트 관리 이념이나 제작 사상 등이 현재의 프로젝트 / 조직과 맞지 않아서 탈락된 것들이 대부분이었다.

요즘의 경우, 대부분의 인기 있는 프로젝트 관리 툴은 체험판을 제공하거나, 소수 인원의 경우 무료 사용을 허가하는 경우도 많이 있다. 어떠한 툴을 사용하기로 결정하기 전에, 이러한 데모 Demo 를 충실히 사용해 볼 것을 권장한다.

프로젝트 관리 솔루션을 찾기 전에…

성공적인 프로젝트 관리를 위해 뛰어난 프로젝트 매니저를 채용하고, 비싼 데브 옵스 솔루션을 들여오고, 데이터를 바탕으로 한 통계 분석을 실시하고, 애자일과 스크럼, 칸반을 도입하기 전에 우선적으로 해야 할 일이 있습니다. 뭐냐고요? 일하는 업무 프로세스를 체계화하고 그 체계를 전체 프로젝트 구성원에게 도입하는 일이지요.

프로젝트 매니저에게 업무 프로세스를 적절하게 관리할 권한이 없다면, 그리고 해당 프로젝트의 프로세스가 업무 진행 순서. 라고 부르기도 민망한 수준의 상황이라면 그 프로젝트는 절대로 관리가 되지 않습니다. 이건 다들 당연히 알고 있을테고.

갑작스럽게 조직이 급격하게 성장하면서 체계화 된 업무 프로세스의 도입을 생각하는 기업이나 조직이 이를 성공시키지 못하는 큰 이유 중 하나는 최고 경영자를 포함한 중간 관리자 급에서 변화된 업무 프로세스를 스스로 체득화 하지 못/안하는 경우가 의외로 많다는 점 입니다. 때문에 프로세스를 안착시키려는 조직에서는 프로젝트 매니저의 권한 배분이 매우 중요합니다. 필요하다면 CEO라도 PM의 잔소리는 들어야 마땅합니다.

대규모 인원이라면 관리는 필연적이고 이런 관리 체계를 흔드는 일은 하지 말아야 합니다. 조직간 커뮤니케이션이 안되고 정보 공유가 산발적이며, 한 가지 사안에 대해 서로 다른 이야기를 하고 있다면 우선 프로젝트에 대한 최고 책임자의 의사 결정 과정과 결정된 의사가 전파되는 과정을 지켜보기 바랍니다. 모든 문제는 거기서 부터 시작합니다.