프로젝트 관리 툴 결정하기

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

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

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

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

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

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

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

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

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

어떻게 마이크로프로즈의 해적은 “시드 마이어의 해적”이 되었는가?

  • 덧(2020. 06. 14.): 해당 영상의 문제 부분이 편집되어 올라간 것을 확인 했습니다(오후 3:21)

어제, 게임 개발 비화 유감 이라는 글을 쓴 이후 올라온, 유명 유튜버의 게임 개발 비화 영상을 보고 시작하게 된 글.

사실 게임 회사 이야기 Ep. 2 마이크로프로즈 편(유튜브)을 만들 당시 “시드 마이어의 해적”에 왜 개발자 시드 마이어의 이름이 붙었는지에 대한 이유는 굳이 찾아보지 않음. 국내 자료들은 별별 내용들1이 있었기 때문에 애초에 다룰 생각 자체가 식어버림. 그저 시드 마이어의 이름을 단 첫 게임이 해적이었다는 것만 있으면 되었음.

어제 공개 된 문제의 게임 개발 비화 영상에서는 예의 ‘새로운 분야 도전에 대한 리스크 회피 및 책임 회피를 위해 시드 마이어의 이름을 쓰도록 공동 창업자인 빌 스텔리가 강요했다’ 라는 이야기를 차용함.

사실 이 이야기에 대해 의문이었던게, 당시 북미 게임계는 전통적으로 게임 디자이너의 이름을 패키지 전면에 내세우는게 거의 대부분이었음(마이크로프로즈가 오히려 독특한 경우로 이 회사는 해적 이전까지는 패키지에 게임 디자이너 이름을 넣진 않음). 오리진 시스템즈, 브로더번드 소프트웨어, 시에라 온라인의 게임 패키지들을 유심히 살펴보면, 일정 시기 이후부터 게임 디자이너 이름이 패키지 전면에 표기 되어 있는 걸 확인 할 수 있음(각 링크는 해당 게임사 게임 패키지 영상임).

상식적으로도 말이 안되는게, 게임이 망하면 회사 전체의 책임이지 어느 개인의 이름을 내세웠다고 그 책임이 오롯이 개인에게 가는 것이 아님. 어쨌든 의아했기에 인터넷 검색을 시작 함.

2013년 PC GAMER의 기사(2013. 6. 28.)에 따르면, 코타쿠의 기사를 인용. 애초의 아이디어는 유명한 헐리우드 영화 배우이자 게임광으로 알려진 로빈 윌리엄스의 제안으로 “시드 마이어의 해적”과, “시드 마이어의 문명”이 되었다는 빌 스텔리의 발언이 실려 있음.

“We were at dinner at a Software Publishers Association meeting, and [actor] Robin Williams was there,” longtime collaborator Bill Stealey says. “And he kept us in stitches for two hours. And he turns to me and says ‘Bill, you should put Sid’s name on a couple of these boxes, and promote him as the star.’ And that’s how Sid’s name got on Pirates, and Civilization.”

How Sid Meier became one of the most recognizable names in gaming, PC GAMER, June 28, 2013

원 출처인 코타쿠의 기사(2013. 6. 26) 에는 아에 시드 마이어의 회고도 같이 들어가 있음. 전문을 보면 ‘하기 싫은데 네 이름 걸고 만드는거면 봐줄께’ 같은 뉘양스로 보긴 어려움. 그것 보다는 ‘뭐? 그래? 그럼 네가 만든 게임들(비행 시뮬레이션 게임들)로 이미 유명하니 네 이름을 넣으면 어떨까?’에 가까워 보임.

“Bill said, ‘When’s my next flight simulator coming out?’ And I said, ‘I’m not doing a flight simulator; I’m doing a pirates game.’ He said, ‘Well that’s crazy, ‘cause people want your next flight simulator… Wait a minute. Put your name on it. Maybe if they liked your flight simulator games, they’ll recognize the name and buy this crazy pirates thing.’”

Sid Meier: The Father of Civilization, Kotaku, June 26, 2013

다시 한 번, 상식적으로 생각하면 네 이름 넣고 실패하면 네가 책임져. 라고 복잡하게 갈 이유가 없음. 실패하면 네가 회사 나가. 라고 하면 되는 일임.

하지만 어제의 그 영상 덕분에 빌 스텔리는 군인 출신 겜알못 꼰대로 빠르게 전락하는 중이고. (…)


추가로, 시드 마이어의 문명 개발 당시 빌 스텔리가 문명 개발을 포기 시키기 위해 압력을 행사하고 개발자 한 명만을 넣어줬다. 식의 서술도 뭔가 미심쩍어서 찾아봤다.

내가 발견한 자료는 시드 마이어와 브루스 쉘리(레일로드 타이쿤, 문명, 에이지 오브 엠파이어 개발자)가 GDC 2017에서 함께 발표한 내용에 대한 Ars Technica 의 기사(2017. 3. 04).

기사 내용에 따르면 경영진의 문명에 대한 우려는 분명 있었음. 다만 그건 첫번째 프로토타입에 대한 것이었다. 문명의 첫 프로토타입은 턴 방식이 아닌 실시간으로 움직이는 심시티의 영향을 강하게 받은 것 이었으며, 시드 마이어 스스로도 디자인 의도대로 돌 던 물건이 아니었다고 발언.

다만, 같이 프로토타입을 만들던 브루스 쉘리의 입장에서는 회사가 시드 마이어를 비행 시뮬레이션 개발로 빼가려는 술수로 보였다고 함. 시드 마이어는 쉘리는 아마 경영진의 이야기를 들을 기회가 없었을 것이라는 식으로 이야기 함.


해당 영상의 뒷 부분은 아에 사실 관계부터가 엉망진창인데, 대표적인 것만 지적하자면.

  1. 마이크로프로즈는 시드마이어의 해적과 문명의 성공 이후 군사 시뮬레이션 분야만 파지 않았음. 경영, 전략 시뮬레이션 게임(X-COM 시리즈 등)을 비롯, 다크랜드 같은 걸출한 RPG와 각종 포인트 앤 클릭 어드벤쳐 게임, 스포츠, 레이싱 게임, 교육용 게임 등을 개발하고 발매함.
  2. 마이크로프로즈의 몰락 이유는 갑작스러운 규모 확대 및 각종 신규 장르 게임의 부진, 무리한 해외 진출(유럽 지사 설립 등)로 인해 시작되었다고 보는 입장이 많은 편.
  3. 결국 이 상황에서 마이크로프로즈는 스펙트럼 홀로바이트에 인수 됨. 그리고 이 인수가 이뤄지는 시점에 빌 스텔리가 시드 마이어보다 먼저 일선에서 퇴진함.
  4. 회사는 이후에도 부침을 겪었고, 경영 합리화 결정에 따라 스펙트럼 홀로바이트 + 마이크로프로즈 = 마이크로프로즈 가 되는 시기에 뒤늦게 시드 마이어도 마이크로프로즈를 퇴사 함.
  5. 1993년 스팩트럼 홀로바이트 이후에도 꽤 많은 회사들에 팔리면서 계속적으로 핵심 개발 인력들이 구조조정으로 갈려나가는 상황이 발생함. 결국 2003년 인포그램즈 산하에 있을 때 스튜디오 폐쇄가 결정 됨.
  6. 2020년 마이크로프로즈의 부활이 알려짐. David Lagettie 에 의해 회사가 복각 중에 있으며, 빌 스텔리가 여기에 대해 홍보를 하는 형태로 기여 중임(The resurrection of MicroProse and return of “Wild Bill” Stealey, Gamesindustry.biz, May 6. 2020.).

  1. 성공한 개발자 시드 마이어의 명성을 위한 것 vs. 위험 분야 도전에 따른 위험 회피를 위한 것

게임 개발 비화 유감

게임의 구상부터 개발까지 완성에 걸린 기간만 7년, 완성된 게임을 보고도, 탐탁치 않아했던 임원들, “일단 발매는 하겠지만, 이런 게임이 잘 될리 없습니다.”

A 웹진, 2016년

정작 문제는 EA와 윌 라이트의 관계였다. EA입장에서는 거액을 주고 MAXIS의 대표 게임인 심시티의 가능성에 투자한 것이었고 심시티 게임의 핵심 개발자는 윌 라이트였다. 그런데 그 심시티의 핵심인 윌 라이트가 심시티 개발에 적극적으로 참여하는 모습을 보이지 않고 있었다. 거액을 주고 산 핵심 인물이 지금 딴짓을 하고 있는 것이다.

B 웹진, 2019년

EA에 맥시스를 매각한 이후 윌 라이트는 드디어 여유를 찾을 수 있었다. 이제 경영은 EA의 몫이었고, 윌 라이트는 지난 몇 년 동안 자신을 짓눌러오던 경영 문제에서 해방되어 게임 개발에만 집중 할 수 있었다. EA도 우호적이었다. 윌 라이트가 필요하다고 말만 한다면 컴퓨터부터 인력까지 뭐든지 충원해 줄 기세였다.

C 웹진, 2018년

타고난 승부사적 기질을 가지고 있는 윌 라이트는 포기하지 않았다. 그는 다른 건 다 필요없고, 프로그래머 한 명만 붙여달라고 회사에 요구했다. EA는 귀찮다는 듯 적당한 프로그래머 한 명을 뽑아 프로젝트에 배정해 주었다. 윌 라이트에게 이건 굴욕이었다. 그는 [심시티]를 개발한 사람이 아닌가?

D 웹진, 2015년

위의 영상을 준비하면서 가장 난감했던 문제 중 하나. 심시티와 심즈 시리즈의 개발자인 윌 라이트는 말 그대로 게임사에 한 획을 그은 위대한 인물 중 하나이다 보니 국내에도 그와 그가 몸 담았던 맥시스 소프트웨어에 대한 글이 매우 많다.

그런데 찬찬히 읽어보면 같은 시점에 대해 이야기 하는데도 불구하고 각 서술자 마다 다른 분위기, 심지어는 객관적인 사실 마저도 다른 이야기를 하는 경우1가 있다.

게임 개발 비화나 게임사를 이야기하는데에 대한 어려움은 이미 예전에도 몹시 투덜거린 적이 있지만, 이번에는 너무 심했다. 이번 영상은 다른 영상에 비해 준비 과정이 매우 어려웠었는데, 가장 많은 시간이 소요된 건 사건의 사실 관계를 확인하는 일이었다.

국내의 기사들은 위의 예시를 보듯, 각 저자마다 서로 다른 이야기를 하는 경우가 허다하다. 이래서는 뭘 선택하든 신뢰성을 담보하기 어렵다(그리고 대부분 내용의 출처에 대한 이야기는 언급이 없다).

결국 내가 내린 해결책은 당사자 입에서 나온 이야기를 바탕으로 서술하는 것이었다. 다행이 관련 자료는 찾기 쉬웠는데 맥시스 초기에 대한 이야기는 제프 브라운의 한 강연 영상(2009년)을, 그리고 심즈에 대한 이야기는 주로 윌 라이트의 여러 인터뷰 자료들을 토대로 삼았다2

게임 개발 비화를 쓸 때, 드라마틱한 이야기는 글의 재미를 주는 중요한 요소 중 하나라고 생각한다. 이야기를 재미있게 꾸며내는 것 역시 중요한 능력 중 하나이기도 하고, 내 스스로는 그런 능력이 없는 것 아닌가 하는 걱정에 매일 고민하기도 한다.

하지만, 이건 좀 너무하다. 그것도 전문성과 사실에 기반한 이야기를 풀어야 하는 게임 전문지에서 같은 이야기임에도 불구하고 기본 사실마저 달라지는 행태는 좀 위험하다. 만약 리니지 1의 개발 비화를 이야기 하면서 상상에 근거한 양념을 함부로 칠 수 있을까? 키보드에 손을 올리기 전에 NC 법무팀이 먼저 떠오른다면, 해외의 게임 개발 비화를 이야기 할 때도 마찬가지어야 되는거 아닐까?

문제는 이런 이야기들이 확대 재생산 되고 무비판적으로 받아들여진다. 각종 블로그 글이나 유튜브 영상 등을 통해 개인이 생산한 콘텐츠에서도 똑같은 난리판이 벌어진다. 그도 그럴 것이 기초 자료로 어떤 웹진 기사 하나 집어놓고 작업을 한게 너무 눈에 보이거든.

관점에 따라 사건에 대한 해석이 달라질 수는 있다. 그리고 방대한 자료들 중 참고한 소스에 따라서 사실 관계도 달라질 수도 있으며, 당사자의 인터뷰라고 해서 무조건 신뢰 할 수 있는 것도 아니다. 하지만, 이번 영상을 준비하면서 찾아 본 내용들은 이런 수준의 이야기를 한참 벗어난 듯 하다.

이건 좀 아니지.


  1. EA가 출시를 반대했다. EA가 출시에 반대했지만 신임 총괄 매니저의 드라이브로 출시했다. EA는 심즈에 적극적이었다 등

  2. 링크 자료는 제일 먼저 참조했던 가마수트라에 실린 윌 라이트 인터뷰(2011년)이다