신작 FPS ‘워크라이’ 5월경 공개 예정 ··· 기존, 신작 FPS와 경쟁 불가피

‘오디션’으로 세계를 석권한 티쓰리엔터테인먼트(대표 김기영·이하 티쓰리)가 신규 FPS로 또 한 번의 성공신화를 꿈꾼다. 지난해부터 티쓰리에서 개발중인 신작 FPS ‘워크라이’는 캐릭터가 다양한 동물의 얼굴로 변화한다는 점에서 독특한 게임성을 선보이는 게임을 알려졌다.

단순히 총을 쏘는 것이 전부가 아닌 RPG적인 요소가 다수 가미돼 있어 새로운 FPS 장르로 자리매김할 것으로 보이는 ‘워크라이’는 티쓰리에서 게임사업을 총괄하고 있는 김태규 본부장이 깊숙이 관계하고 있는 프로젝트로 티쓰리내부에서도 ‘오디션2’에 이어 큰 기대를 모으고 있는 게임. 콘솔느낌을 살린 그래픽이 눈에 띄지만 사양은 특별히 높지 않은 것으로 알려졌다. 티쓰리는 당초 3월경 첫 선을 보일 예정이었으나 다소 일정이 늦춰져 오는 5월경 ‘워크라이’의 1차 클로즈드 베타 테스트를 실시할 예정이다.

티쓰리가 FPS게임 개발에 뛰어든 것에 대해 업계에서는 티쓰리 포털 강화를 위한 준비의 일환이라는 분석이 지배적이다. 올해 중반기부터 본격적인 모습을 갖추어 나갈 티쓰리포털을 강화하기 위해 댄스, MMORPG, 액션게임 외에 새로운 장르의 라인업을 구축해야 할 필요성을 느꼈기 때문이라는 지적이다. 이는 유저층을 다변하기 위한 전략과도 맞물린다. ‘오디션’을 통해 이미 저연령층 공략에 성공했지만 상대적으로 성인유저층 비율이 낮은 티쓰리가 유저풀을 다양화해야 할 필요가 있기 때문이다.

업계 전문가들은 ‘워크라이’가 기존 밀리터리 일색의 FPS가 아닌 새로운 시도가 돋보이는 게임인 만큼 성공 가능성은 충분하다고 입을 모은다. 뿐만 아니라 포털사업을 확장하고 상장에 성공하는 등 발전가능성이 무궁무진한 게임사인 티쓰리에서 내 놓는 차기작인 만큼 유저들의 관심 또한 높아질 수밖에 없을 것으로 내다보고 있다.

그러나 기존에 선전하고 있는 ‘스페셜 포스’, ‘서든어택’, ‘카스온라인’ 등의 벽을 넘지 못할 경우 지난해 실패의 쓴잔을 맛봤던 FPS게임들의 전처를 밟을 가능성도 있다는 지적도 있다. 뿐만 아니라 애니파크의를 비롯한 엔도어즈, 네오위즈 등 기존 게임사들은 물론 지이스케이프의 ‘프로젝트 X’, STN소프트의 ‘레드아웃’ 등도 올 한해 공개될 것으로 보여 FPS 경쟁이 더욱 거세질 전망이다. 업계 관계자들은 “ ‘오디션’의 성공신화를 재현하기 위해서는 체계적인 시장분석을 통해 완성도 높은 게임을 선보여야 할 것”이라며 “다양한 FPS가 서비스될 예정인 만큼 차별화를 통한 경쟁우위를 점해야 할 것이다" 고 말했다.

하은영 기자 hey@kyunghyang.com

1. 낭비를 제거하라 - 소프트웨어 개발의 가장 큰 낭비 3가지

* 가외기능 : 80%의 가치를 제공하는 20% 기능 구현에 모든 초점을 맞추어 개발하는 프로세스가 필요하다.
* 혼란 : 이해당사자의 요구사항에 혼란을 느낀다면 스펙을 너무 일찍 결정한 것이다. 테스트를 하고 수정하는데 혼란을 느낀다면 테스트를 너무 늦게하기 때문이다.
* 부서간 경계 : 부서간의 경계를 넘어서려면 통상 25% 이상의 비용을 증가시키는데, 이러한 기능적 부서 경계는 해당 업무의 불필요한 버퍼를 만들고, 응답시간을 늦추며, 커뮤니케이션을 방해하여 결국 적시(Just-In-Time)생산을 하지 못하게 한다.

2. 품질을 내재화하라 - 개발 중 검증 단계에 이르러서야 결함을 발견한다면 그 프로세스는 결함이 있는 것이다.

* 테스트주도개발(Test-Driven Development)을 통해 코드의 실수를 방지하라 : 요구사항 문서 대신 실행 가능한 명세를 만들어라.
* 레거시코드를 만들지말라 : 유연성이 없는 레거시코드는 자동화된 단위테스트와 인수테스트가 없는 코드이다.
* 빅뱅통합은 진부하다 : 개발 결과물을 늦게 통합하는 것은 품질을 떨어뜨리며 결함과 장점 모두 늦게 발견하게 된다.

3. 지식을 창출하라 - 예측 계획(planning)은 유용한 것이며, 개발 중 학습은 필수적인 것이다.

* 과학적 방법을 사용하라 : 가설을 세우고, 신속하게 실험하며, 문서를 간결히 작성하고, 대안을 늘 강구하도록 팀을 교육하라.
* 표준은 개선되기 위해 존재한다 : 모든 사람들이 따라하고 잘 알려진 실천법을 표준에 포함하되, 누구나 자발적으로 표준을 개선할 수 있는 문화가 필요하다.
* 예측 가능한 성과는 피드백에 기반한다 : 예측 가능한 조직은 미래를 추측하지만 그 것을 계획(predefined plan)이라고 하지 않으며, 변화에 대한 신속한 대응을 하기 위한 역량만을 개발한다.

4. 확정을 늦춰라 - 변화를 인정하자. 변화에 빠르게 대처하기 위해서는 완벽한 명세서를 가지고 개발을 시작하는 것이 좋은 아이디어라는 생각은 버려라.

* 의존성을 깨뜨려라 : 시스템의 구조는 언제 어떤 기능이 추가되더라도 그 것을 수용할 수 있어야 한다.
* 옵션을 유지하라 : 코드를 실험으로 생각하라. 변화를 수용할 수 있게 언제나 옵션을 유지하라.
* 돌이킬 수 없는 결정은 최후에 하라 : 돌이킬 수 없는 결정을 내려야만 한다면 가능한 많은 정보와 학습 후에 최종적으로 하라.

5. 빨리 배포하라 - 조직간에 발생하는 결함 리스트와 대기열은 지연과 추가 비용을 발생시킨다.

* 신속한 배포, 고품질, 저비용은 동시에 가능하다 : 속도 경쟁에서 승리하는 회사는 월등한 품질을 배포하며 고객의 요구에 더 귀기울일 수 있다.
* 대기행렬 이론을 개발에 적용하라 : 가동률을 강조하면 오히려 재고(가외기능)와 재공품(미완성기능)을 만들게 되고 생산에 병목을 일으켜 결국에는 생산성을 낮춘다. 작업량의 크기를 줄여 개발 주기시간(cycle time)을 더 빨리 돌아가게 하라.
* 일의 양을 실제 할 수 있는 만큼으로 제한하라 : 빠른 주기 반복을 통해 안정적이며 결함의 수를 낮추어라.

6. 동료를 존중하라 - 프로젝트에 주도적으로 참여하고 연구하는 사람들이 최고의 경쟁우위를 제공한다.

* 팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다 : 무엇이 팀을 만드는가? 팀원들은 공동의 목표(Object)를 같이 달성하기 위해 상호간 책임의식으로 뭉쳐져있다.
* 효과적인 리더십을 제공하라 : 효과적인 팀에는 반드시 팀역량을 최고로 이끄는 훌륭한 리더가 존재한다.
* 파트너를 존중하라 : 서로를 위한 헌신은 절대로 이해 상반이나 갈등을 만들지 않는다.

7. 전체를 최적화하라 - 부분적으로 최적화를 하더라도 다른 쪽에서 병목이 존재하는 한 속도경쟁에서 승리할 수 없다.

* 전체의 가치흐름을 맞추어라 :  고객요구에서 배포까지 전체의 프로세스 문제점을 파악하고 대응하라.
* 완전한 제품을 배포하라 : 기능에 의존하지 말고 제품을 통해 고객이 어떤 혜택을 가지게 되는지에 집중하라.
* 더 높은 것들을 측정하라 : 팀 프로세스의 역량을 계량화하라. 순추천고객지수(NPS)로 고객만족을 계량화하라.

프로젝트 진행 시 팀 멤버들의 의견이 명백하게 다를 때 발생되는 소모적인 의견 다툼은 건설적인 논쟁으로 바꿀 수 있어야만 한다. 이러한 맥락에서 볼 때 논쟁이란 각각의 문제점들에 대한 모든 측면을 기꺼이 탐구하고자 하는 것으로 정의된다. 그러므로 팀 멤버들이 모든 이슈에 대해 모든 측면을 기꺼이 탐구하게 하는 것은 바람직한 목표가 될지언정 피해야 할 일은 아니다. 어떻게 하면 팀 내부에서 건설적인 논쟁을 할 수 있도록 할 수 있을까? 이것을 가능하게 하는 중요한 요소들 가운데 몇가지 예를 들자면 아래와 같다.

1.     공동의 목표 또는 비전

만약 다양한 사람들이 공동으로 무엇을 달성 할 수 있을까에 대한 공동의 목표나 공유된 비전에 모두 몰입할 수 있다면 그들은 새롭고 좀더 혁신적인 방법으로 그 들의 풍부한 다양성을 화합시킬 수 있을지도 모른다. 그러므로 다양성에 의해 특징 지워진 팀들은 공동으로 무엇을 달성하길 원하는가에 관해 (팀의 목표를) 합의하는데 시간을 투입해야만 한다.

2.     가치로서의 다양성

다양한 배경과 경험은 긍정적인 요소라는 것을 팀원들은 공유된 가치(shared value)로써 이해하고 받아들여야만 한다. 팀원들은 ‘논쟁이란 무엇인가’를 토론할 필요가 있으며 또 논쟁을 의사결정이나 계획을 끝내기 전에 모든 문제에 대한 모든 측면들을 기꺼이 탐색하고자 하는 것으로 볼 필요가 있다. 팀원들은 자신들의 의견이 다름을 설명할 수도 있으며 그렇게 함으로써 다른 사람들이 자신들의 아이디어의 의견을 표명할 때 ‘왜 자신들은 그렇게 생각하는가?’를 이해할 수 있다.

3.     작업지침

다양한 팀의 멤버들은 공동의 목표에 몰입하고 있으며 또 다양성을 가치로써 받아들이고 있다고 가정할 때 작업지침을 개발하는 것은 매우 도움이 된다. 다음과 같은 작업지침이 도움이 될 수 있다.

a.     문제점에 대해 다소간 경험을 한 모든 팀원들은 문제점에 대한 자신의 최선의 생각을 공유한다.

b.     만약 어떤 사람이 다른 사람과 의견이 같거나 다르다면 그러한 입장을 팀과 공유해야만 한다.

c.     팀은 다양한 의사소통이라는 황금률(Golden Rule)을 채택할 수도 있다 : 다른 사람들이 당신과 함께 문제점들을 토론해 주길 원한다면 당신도 다른 사람들과 함께 문제점들을 토론하여라. 그리고 당신이 다른 사람들이 당신의 말을 경청해 주길 원하면 당신도 다른 사람의 말을 경청하라.

d.     어떤 결정이라도 최종적으로 내리기 전에 팀의 리더나 팀원들은 ‘우리는 우리가 결정하려고 하는 것에 관해 모든 아이디어, 제안, 또는 반대의견을 경청했는가?’라고 재차 물어봐야만 한다.

e.     두 사람 A, B가 서로 얘기를 하고 있다고 하자  A는 B가 이야기한 것에 반대할 때, ‘나는 당신이 말한 것을 이런 뜻으로 들었는데 그렇습니까?’라고 오해가 없도록 다시 B에게 다시 물어 볼 수 있어야만 한다.

f.      팀의 모든 멤버들은 모두가 훌륭하고 지성적인 사람들이며 또 그러하기 때문에 모든 사람의 의견, 아이디어와 주장은 존중되어 경청되어야만 한다는 것을 완전히 받아들여야만 한다.

g.     다음과 같은 글이 팀 슬로건이 될 수도 있을 것이다 : 협조적인 분위기 하에서의 논쟁은 의견을 더욱 정교하게, 새로운 정보와 아이디어를 탐색하게, 또 명백하게 반대하는 입장을 통합하도록 촉진시킨다.

4.     프로젝트 평가하기

모든 팀, 특히 다양한 팀은 팀의 프로세스와 실적을 평가하기 위한 시간을 가져야만 한다. 예를 들어 우리 팀은 팀의 지침을 얼마나 잘 준수했는가? 무엇 때문에 우리는 가능한 한 창조적일 수 없었는가? 우리는 논쟁을 건설적으로 활용했었는가? 우리는 좀 더 효과적인 팀을 만들기 위하여 또 다양성을 좀 더 창조적으로 활용하기 위하여 무엇을 할 필요가 있는가? 이러한 프로젝트 평가하기는 통상 무기명 설문을 통해 작성되며 개발 제품과 개발 환경, 그리고 창의요소 면에서 여러 가지 항목들을 통해 분석될 수 있다.