brunch

You can make anything
by writing

C.S.Lewis

by 취한하늘 May 10. 2021

[Trouble] 프로젝트가 겪는 여러 가지 난관들

흔들리지 않고 피는 꽃이면 좋을 텐데.


흔들리지 않고 피는 꽃이 어디 있느냐는 시구가 있다. 마찬가지로 흔들리지 않는 프로젝트도 없다. 작고 빨리 끝나는 프로젝트가 아니고서야, 프로젝트를 진행하다가 문제에 부딪히는 것은 일상다반사다. 오히려 문제가 장기간 없으면, 무언가 크게 잘못되고 있는 것이 없는지 적극적으로 찾아봐야 한다.

프로젝트를 진행하면서 만나는 문제들 중에는 만나기 어려운 희귀한 문제들도 있지만, 반대로 프로젝트들이 흔하게 겪게 되는 문제들도 있다. 일정이 부족한 문제라던가, 외부 상황의 변화로 제품을 출시하는 것이 곤란해지는 문제라던가, 출시를 했는데 프로그램 오류나 해킹 같은 이슈로 고객들의 불만이 치솟는 문제들이 그런 문제들에 해당할 것이다.

이런 문제들은 드물지 않게 발생하는 문제들인 만큼, 미리 대응책을 마련해 두면 좋다. 여기서는 이렇게 프로젝트들이 종종 겪는 몇 가지 문제들에 대해, 어떻게 준비하고 대처해야 할지 이야기해 보고자 한다. 다만, 내가 참여했던 프로젝트가 대체로 게임을 만들고 서비스하는 프로젝트였기 때문에, 아무래도 게임 제작자의 입장에서 글을 서술하려 한다. 하지만, 제품을 만들어 출시하는 것과는 다른 프로젝트에서도 큰 맥락은 비슷할 것이라 생각한다.


일정 부족


프로젝트가 처음부터 일정이 부족한 상태로 진행되는 경우도 있고, 처음에는 괜찮았는데 진행하는 중간에 일정이 부족하게 되는 경우도 있다. 일정이 부족해지는 원인도 다양한데, 인력이 이탈해서 발생하는 경우도 있고, 회사 자금이 부족해서 빨리 출시해야 하는 경우, 투자자나 퍼블리셔가 빨리 출시할 것을 요구하는 경우도 있다. 애초에 일정 예측을 잘못해서 발생하는 경우도 있다.

일정 부족은 너무나도 흔한 일이기 때문에, 프로젝트를 시작할 때부터 일정 부족에 대응할 수 있는 형태로 진행하는 것이 중요하다. 그러기 위해서는 먼저 제품을 항상 사용 가능한 상태로 만들어 놓는 것이 필요하다. 가장 핵심적인 기능만을 갖춘 최소한의 제품을 빨리 만들어 놓고, 거기에 기능을 더하는 형태로 프로젝트를 진행하는 것이다. 디펜스 게임을 예로 들면, 일단 게임을 시작하면 적이 몰려오고 타워를 건설해서 적을 물리치는 부분만으로 구성된 게임을 만들어 놓는 것이다. 그리고 이후, 로그인 기능, 상점 기능, 퀘스트 기능 등 필요한 기능을 추가하는 형태로 프로젝트를 진행한다. 이때, 추가적인 요구사항을 만족하면서도 제품은 늘 동작 가능한 상태를 유지해야 한다. 쉽게 말해서, 품질은 떨어져도 일단 양도가 가능한 상태를 유지하고 있어야 일정이 단축되는 상황에서도 대응할 힘이 생긴다.

핵심적인 부분부터 만들어 나가기 위해서도, 기능을 재정의할 때 중요하지 않은 기능을 제외시키기 위해서도, 우선순위 관리는 무척 중요하다. 지금까지 많은 게임을 만들어서 출시했지만, 제품에 넣고 싶은 것을 모두 넣어서 출시한 경우는 거의 없는 것 같다. 항상, 무언가는 제외시켜야 했고, 무언가는 나중으로 미루어야 했다. 그럴 때, 우선순위 관리가 잘 되어 있으면 고민할 필요가 별로 없고, 금방 결정을 내릴 수 있다. 그리고, 평소에 우선순위 공유가 잘 되어 있으면, 스펙을 조정해야 할 때 논란의 여지도 많이 줄어든다.

인력의 추가 투입이 가능한 경우에는 인력 추가를 고려해 볼 수도 있기는 한데, 경우에 따라서는 인력의 추가 투입이 그다지 도움이 되지 않는 경우도 있다. 남은 일정이 아주 짧거나, 혹은 인력이 추가 투입되는 지점이 병목 지점이 아닐 때는, 오히려 프로젝트 관리 비용만 늘어날 수도 있다.


시장의 변화


게임 제작의 경우, 많은 회사에서 동시에 여러 개의 게임을 만들고 있고, 그래서 시장에 수많은 게임이 쏟아지고 있는 상황이기 때문에, 프로젝트에서 만들고 있는 게임과 비슷한 게임이 경쟁사에 의해 먼저 출시되어 버릴 가능성이 늘 존재한다. 특히, 어떤 트렌드를 쫓고 있는 게임의 경우, 경쟁사들도 같은 트렌드를 쫓고 있기 때문에, 비슷한 게임이 여러 회사에서 개발되고 있는 상황에 곧잘 처하게 된다.

재작년에 약간은 새로운 종류의 게임이 미국 시장에서 크게 히트한 적이 있다. 그러자, 국내 어떤 게임회사에서 같은 형태의 게임을 제작하는 프로젝트가 진행되었다. 그 프로젝트에 지인이 있어 한 번 만난 적이 있는데, 본인이 알고 있는 것만 해도 여섯 군데 정도에서 비슷한 게임을 만들고 있다고 했다.

프로젝트의 방향을 바꾸어야 하는 또 다른 예로, 시장이 생각보다 성장하지 못하는 경우를 생각할 수 있다. 게임 업계에서는 아주 가끔, 새로운 플랫폼이 형성되는 경우가 있다. 이때 그 플랫폼에 경쟁사들보다 먼저 게임을 출시하면 큰 성공을 이룰 수도 있다. 모바일 게임 시장에서 큰 성공을 거둔 애니팡이 대표적인 경우라고 할 수 있다. 게임 업계를 대표하는 대형 게임회사들이 모바일 게임 시장에 대해 관망하고 있을 때, 적극적으로 게임을 출시하여 시장을 선점해 버렸다. 애니팡이 게임으로서 아주 특별한 게임은 아니지만, 시장에 먼저 진입함으로써 큰 성공을 누릴 수 있었던 것이다.

그런데, 플랫폼이 항상 모바일 플랫폼처럼 성공적으로 큰 시장을 형성하는 것은 아니다. 스마트 TV 게임 시장이나 MS 스토어 게임 시장처럼, 큰 기대를 받았지만 막상 시장이 성장하지 못하는 경우들도 있다. 이럴 때, 이 플랫폼들에 빨리 진입하려는 목적을 가진 프로젝트들의 경우에는, 계획을 원래대로 진행할지, 아니면 수정할지 고민할 필요가 있다.

이런 외부 상황의 변화를 미리 예측할 수 있으면 좋겠지만, 그것은 불가능하다. 단지, 빨리 알아챌 수 있을 뿐이고, 알았을 때 빨리 의사결정을 진행할 수 있을 뿐이다.

외부 상황의 변화로 인해 프로젝트의 방향을 변경해야 한다면, 일단 제품 자체를 바꾸는 방법이 있을 것이다. 비슷한 게임이 먼저 나와 성공했다면, 게임의 핵심 재미를 재설정하고, 변경된 방향에 맞게 콘텐츠를 수정할 수 있다. 비용이 들기는 해도, 방향만 잘 잡으면 먼저 성공한 게임이 오히려 도움이 될 수도 있다. 먼저 성공한 게임이 만들어 놓은 시장에, 약간의 차별화로 안착할 수 있기 때문이다.

아니면 시장을 변경하는 방법도 있다. 게임을 출시할 플랫폼을 변경한다던가, 혹은 출시 국가를 달리할 수도 있다. 게임 시장은 하나의 시장으로 통합되어 있기보다는 여러 시장으로 나뉘어 있기 때문에, 목표 시장의 상황이 나빠지면 다른 시장으로 대상을 변경하는 것도 방법이다.


서비스 장애


새로운 게임을 출시할 때, 개발팀이 가장 먼저 걱정하는 것이 바로 '장애'다. 말하자면, 프로그램에 오류가 있어 서비스가 정상적으로 동작하지 않는 경우가 발생하는 것이다.

게임이란 것이, 그 안에서 플레이어가 할 수 있는 행동의 수가 워낙 많은 데다가, 플레이어끼리도 상호작용을 하다 보니, 게임 안에서 발생하는 상황의 가짓수는 엄청나게 많다. 아무리 사전에 테스트를 열심히 한다고 하더라도 그 많은 상황을 다 체크해 보는 것은 불가능하다. 게다가 수많은 사람이 플레이해야만 발생하는 상황들도 있기 때문에, 게임을 출시하고 난 이후에 오류 없이 동작하는 게임은 없다시피 한다.

이런 점을 고객들도 잘 알고 있기 때문에, 어느 정도의 장애는 크게 문제 삼지 않는다. 하지만, 장애가 길어지거나, 혹은 자주 일어나서 게임 플레이를 지나치게 방해하면, 게임에 대한 고객들의 평가는 급격히 나빠지고, 고객의 이탈도 급격히 증가한다.

장애는 일단 빨리 해결하는 것이 중요하기 때문에, 관련 개발자들이 밤낮을 구분하지 않고 문제를 찾아 해결하려고 노력하게 된다. 그런데, 이때 리더가 신경 써야 하는 부분이 세 가지 있다.

첫 번째는, 우선순위 관리다. 오류도 우선순위 관리가 필요하다. 고객들의 게임 플레이를 크게 방해하는 요소부터 찾아서 먼저 해결해야 한다. 쉬운 것 먼저 해결한다고 중요하지 않은 오류에 시간을 쓰면, 그만큼 고객은 더 기다려야 하는 상황이 되고, 기다려야 하는 시간이 길어질수록 더 많은 고객이 게임에서 이탈하게 된다. 고객들 뿐만 아니라 개발팀을 위해서도 우선순위 관리가 필요하다. 장애를 빨리 해결해야 하기 때문에, 일부 인력의 경우 일시적으로 과중한 업무를 경험하게 되는데, 이럴 때 중요하지 않은 오류는 해결을 미뤄서 개발팀의 체력과 정신력을 보존해 주는 것이 좋다.

두 번째는, 개발자에 대한 격려다. 모든 팀원이 노력해서 오랜 개발 기간 끝에 게임을 출시했는데, 프로그램에 오류가 있어 서비스가 정상적으로 이루어지지 못하면, 관련 개발자는 엄청난 스트레스를 받게 된다. 이미 스스로도 심리적으로 위축되고, 정신적으로 힘들어하고 있기 때문에, 질책과 비난은 도움이 되지 않는다. 오히려 격려와 응원이 필요하다. 오류를 만들고 싶어서 만드는 개발자는 없다. 세계 최고의 개발자가 만든 프로그램에도 늘 오류가 존재한다.(윈도우를 보라) 따라서, 오류가 발생한 것에 대해 평가하려 하지 말고, 발생한 오류를 잘 해결하는 것에 집중할 수 있어야 한다.

세 번째는 고객과의 소통이다. 서비스에 문제가 발생하면, 리더는 고객과의 소통을 관련 팀에만 맡겨놓을 것이 아니라, 관련팀과 적극적으로 협의하여 고객과의 소통을 관리해야 한다. 앞에서도 말했듯이 게임 출시 이후에 서비스 장애가 발생하는 것은 워낙 흔한 일이어서, 고객들도 어느 정도 감안을 하고 기다려준다. 이때 고객들과 소통을 잘하면, 고객들은 생각보다 오랜 시간을 기다려 주기도 한다. 반면, 소통을 제대로 하지 못하면 불만이 순식간에 눈덩이처럼 불어난다. 고객들의 불편을 이해하고 있고, 해결을 위해 노력하고 있다는 것을 잘 보여주어야 하며, 기다려 준 고객들에 대한 적절한 보상도 잘 마련해야 한다. 서비스 장애는 고객들에게 불편을 초래하는 상황이지만, 장애와 관련해 소통을 잘하면, 오히려 제품에 대한 고객들의 충성도가 올라가기도 한다. 고객을 위해 애쓰는 모습을 가장 잘 어필할 수 있는 기회이기도 하기 때문이다.


문제를 만들지 않는 것도 중요하지만, 잘 해결하는 것이 더 중요하다.


일이 문제없이 술술 진행된다면 너무 좋겠지만, 문제란 것이 내 노력과는 상관없이 발생하기도 하기 때문에, 어떤 면에서는 문제를 예방하는 능력보다 문제에 대처하는 능력이 더 중요하다고 할 수 있다. 문제에 잘 대처할 수 있는 능력이 있으면, 예상치 못한 위기에서도 크게 흔들리지 않을 수 있고, 내 프로젝트뿐만 아니라 조직의 다른 프로젝트에도 도움이 될 수 있을 것이다.

그러니, 프로젝트가 난관에 부딪혔을 때, 그 난관에서 당장 벗어나는 것에만 신경 쓰지 말고, 그런 유형의 난관에 어떻게 대처해야 하는지를 제대로 학습하고 넘어가는 것이 좋다. 그러면 난관을 극복할 때마다 조직의 위기 대처 능력이 향상되고, 경험과 학습이 반복되면서 결국에는 강하고 단단한 조직으로 성장할 것이다.

비단, 조직뿐만 아니라, 개인의 삶에서도 비슷한 문제들을 반복하여 만나게 되는 경우들이 있다. 그럴 때마다 피하지 말고, 잘 대처하려고 노력한다면, 점점 나를 흔드는 것들에 흔들리지 않는 사람으로 성장할 수 있을 것이다.

세상에 풀지 못할 문제는 없다. 풀기 어려운 문제가 있을 뿐이다.


1. 일정 부족

개발 중인 제품을 항상 출시 가능한 상태로 유지하는 것이 중요하다.

우선순위를 관리해 만약의 상황에 포기해야 할 것과 꼭 가지고 가야 할 것을 구분해 놓는 것이 필요하다. 

인력의 추가 투입은 실질적으로 도움이 될지를 판단하여 진행해야 한다.

2. 시장의 변화

비슷한 제품이 먼저 나오거나, 시장이 생각보다 작은 것으로 판단되는 경우들이 있다.

제품의 방향을 잘 변경하면, 비슷한 제품이 만들어 놓은 시장이 오히려 도움이 될 수도 있다.

시장 상황이 생각과 다르다면, 새로운 시장에 진출하는 것을 고려해 보아야 한다.

3. 서비스 장애

우선순위를 관리하여 고객들에게 가장 문제가 되는 오류부터 수정해 나가야 한다.

관련 구성원을 질책하지 말고, 잘 해결하는 데 집중하도록 해야 한다.

고객과의 소통을 통해, 고객을 배려하는 모습을 보여주면 오히려 기회가 될 수도 있다.

이전 17화 [Trouble] 인력 이슈에 대응하는 방법
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari