공갈 일정이 프로젝트에 미치는 악영향에 대해

프로젝트를 진행하면서 이런 이야기를 들어본 적 있을 것이다.

“위에서도 어차피 이 일정에 이 스팩이 실현 안되는 건 잘 알고 있어. 하지만 이렇게 계획을 잡아야 그나마 실제 목표에 근접하게 실현 할 수 있다니깐”

이런 공갈 일정으로 프로젝트 진행 구성원들을 닥달하는 이야기는 아직까지도 주변에서 쉽게 찾아 볼 수 있다. 실제로 효과를 봤다는 간증(?)까지 끊이지 않기 때문에 여전히 존재하고 있는 탓이리라.

사실 어느 정도 현재 상황보다 상향된 목표를 잡는 것은 그리 나쁜 일은 아니다. 목표는 크고 높게 잡을 수록 좋다는 이야기와도 뜻이 통한다. 개인 혹은 팀에 도전과제를 주고 의욕을 상승시키는 효과는 분명히 존재한다.

하지만 공갈 일정은 매우 잦은 사고를 일으킨다. 팀의 역량이나 프로젝트의 난이도와 같은 프로젝트 진행 환경에 대한 객관적인 평가 없이 무조건 공갈부터 치는 경우다. 어딜봐도 도달하기 어려운 목표와 일정을 제시하고 팀을 다그친다. 프로젝트 구성원들은 어쨌든 위에서 떨어진 지시이기 때문에 몸과 마음을 말 그대로 갈아가며 일정을 맞추기 위해 노력한다. 가능한 역량의 200%를 목표로 하면 100% 달성을 하겠지라고 생각하며 공갈을 치겠지만, 실제로 도달하는 것은 사실 50% 도 안된다.

공갈 일정이 실패할 수 밖에 없는 것은 촉박한 일정과 과도한 목표로 인해 발생하는 기술 부채 현상 때문이다. 프로젝트는 어디까지나 목표한 기능을 “돌아가는 것 처럼 보이게” 만드는데 집중하게 된다. 팀원 간 협업 프로세스는 엉망이 되고, 척수 반사적으로 들어오는 일을 처리한다. (운이 좋아) 일이 마무리 되어도 제품 품질은 당연히 엉망이거나, (제대로 된 QA, QC를 거칠 시간이 있었을리 만무하므로) 품질 이슈라는 핵폭탄이 불발탄 상태로 수면 아래에 가라앉아 있는 것 뿐이다.

공갈 일정은 프로젝트의 핵심 문제를 몽땅 가려버리기도 한다. 프로젝트의 구현에 집중한 나머지 프로젝트가 추구해야 할 진짜 방향, 목표에 대해 고민할 시간을 프로젝트 참여 구성원으로 부터 빼앗아 버린다. 그렇게 만들어진 제품이 어떠한 철학이나 고찰 없이 그저 쓰레기에 가까운 결과물이 되는 건 당연한 일이다.

프로젝트 관리자 / 소유자라면 공갈 일정과 목표는 사용하지 말아야 한다. 100%를 달성하고 싶다면 200% 의 목표를 잡는 것이 아니라 110% 만 설정하자. 아니 가장 좋은 것은 팀의 역량과 프로젝트 목표의 난이도를 정밀하게 분석하고 제대로 된 계획을 수립하는 것이 가장 좋다 – 물론 그 전에 프로젝트 팀의 100% 가 어디인지도 모른다면… 그런 기본도 안 된 팀은 애초에 프로젝트를 진행하면 안된다

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

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

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

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

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

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

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

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

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

프로젝트 관리 툴 결정하기

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

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

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

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

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

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

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

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

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