들어가는 글
이 글은 템페스트 콘텐츠 개발 전 과정을 지켜본 한 명의 개발자가 작성한 ‘템페스트 포스트모템’이다.
창세기전 모바일 아수라 프로젝트(이하 창세기전 모바일)는 이번 24년 5월 28일 ‘템페스트 콘텐츠’를 업데이트했다.
창세기전 2 원작 리메이크를 기반으로 한 ‘창세기전 모바일’에 감성부터 경험까지 완전히 다른 ‘창세기전 외전 템페스트’를 추가한다는 결정이 난 건 작년 하반기.
24년의 매출을 템페스트가 책임져야 한다는 대표님의 오더와 함께 ‘템페스트 프로젝트’는 갑작스럽게, 그러면서도 막중한 임무를 띤 채 비장한 분위기에서 시작되었다.
모두가 고개를 갸우뚱거렸다.
창세기전 2 리메이크를 기반으로 한 우리 게임에, 완전히 다른 감성의 게임을 얹겠다니?
이런 식으로 만든 게임이 있었을까? 최소한 모바일 게임 중에서?
그 누구도 개척해보지 않은 길을 미어캣게임즈는 가보기로 했고, 그 결과가 마침내 드러났다.
이번 포스트는 템페스트를 개발한 미어캣게임즈 최전선 개발자들의 기록이자, 그때의 힘듦을 딛고 또 다른 프로젝트에서는 더 잘해보고자 하는 미래를 위한 기록을 남기고자 작성하였다.
누구도 가보지 않은 길, ‘템페스트 프로젝트’
템페스트 포스트모템은 고통스럽지만 기록해야하는 역사와도 같았고, 미래에는 그 쓰라림이 반복되지 않게 하고자하는 마음에서 쓰였다.
창세기전 ‘템페스트’ 개발 계획은 계획 단계에서부터 상식과 동떨어진 미친 결정에서 출발했다.
하나의 게임, 그것도 ‘모바일 게임’ 안에 두 개의 전혀 다른 경험을 주는 게임을 얹겠다는 판단과 결정이 있었다.
일반적인 게임회사라면 고민할 이유도 없고, 고민했다 한들 선택할 리 없는 ‘전무후무한’ 선택지다.
그럴 것이, 하나의 게임에 두 개의 게임을 얹느니, 차라리 하나의 게임을 더 만드는 게 훨씬 이득이기 때문이다.
창세기전 모바일은 달랐다. 선택의 여지가 없었다. 그 이유는 ‘원작 시리즈’에 있다.
창세기전 원작은 매 시리즈가 전혀 다른 ‘룩앤필’을 가지고 있다.
메인 일러스트레이터도 4차례나 바뀔만큼 매 시리즈의 화풍의 차이가 큰 게임 시리즈다.
창세기전 모바일은 ‘아수라 프로젝트’라는 부제를 내세울만큼, 모든 시리즈를 하나의 게임 안에 총망라하는 것을 꿈꿨다.
꿈은 누구나 꿀 수 있다. 그러나 그 길은 그 어떤 회사도 가보지 않은 미개척지였다.
그 무모한 결정을 내리게 된 이유는 단 한 가지. 바로 ‘원작 감성’을 살리기 위해서였다.
현재의 창세기전 2 기반의 화면 위에 ‘템페스트 업데이트’라고 캐릭터만 달랑 추가하는 허울좋은 짓은 원작팬 출신 개발자들부터 달가워하지 않았다.
결국 누구도 가보지 않은 길. 그리고 앞으로도 그 누구도 걷지 않을 길을 걷기로 했다.
원작의 경험을 살리겠다는 ‘모호한 목표의식’을 안고서.
미개척지의 수풀을 뚫고서.
템페스트 포스트모템 #1 – ‘TF 발족’
이 회사의 개발문화는 다른 회사에 비해 독특한 점이 있다.
그건 바로 일개 실무자에게도 개발 프로듀서에 준하는 책임과 권한을 부여해준다는 데 있다.
가령, 하나의 ‘메인 기획자’에게 어떤 콘텐츠 개발에 관해서 거의 전권에 가까운 자율성을 보장하며 개발 전반에 관한 권한과 책임을 맡긴다.
야구 선수로 비유하자면 팀의 리더급 되는 선수가 ‘야구 감독’을 해보는 것과 같은데, 게임 디자이너(기획자)입장에서는 꿈같은 일이다.
왜냐하면 게임 디자이너가 자신이 만들고 싶은대로 게임을 만들 수 있는 기회는 게임 디자인 커리어 전체를 통틀어서 있을까 말까한 일이기 때문이다.
이 과정에서 한 명의 실무자로서는 볼 수 없었던 ‘거시적 시각’을 볼 수 있는 역량을 기를 수 있다는 장점도 있다.
그렇게 한 명의 실무자는 ‘팀장’이나 ‘파트장’이라는 직책 없이도, TF(Task Force)의 리드를 맡아 템페스트 개발을 진두지휘하게 된다.
템페스트 포스트모템 #1 – 좋았던 점
빠른 의사결정과 추진
템페스트의 의사결정은 ‘대표님’의 판단과 결정에 의해 추진되었다.
대표님의 결정이라는 든든한 우군 덕에 팀 내 어떠한 업무와 일정보다도 템페스트 개발 우선도가 높았고, 그에따라 상대적으로 넉넉한 준비기간을 확보할 수 있었다.
이때의 준비기간 덕분에 자료조사 및 정리에 충분한 시간 투입이 가능했다.
템페스트 원작 ‘감성’을 조금이라도 잘 재현하기 위해 분석과 고민을 하기에는 충분한 시간이었다.
이러한 빠른 의사결정과 추진은 템페스트의 프리 프로덕션 단계가 일정상 큰 어려움 없이 이어질 수 있게 하는 큰 도움이 되었다.
풍부한 원작 자료 풀(pool) 확보
모험왕 유그드페인으로부터 이어지는 복잡한 관계가 잘 표현되어 있으나, 일부 요소는 내부에서 가진 자료와 맞지 않아 추가 검증이 필요했다.
아무리 원작 IP에 관한 권리를 보유하고 있다고는 하나, 원작의 모든 자료를 가지고 있는 건 아니었다.
가령 ‘모험왕 유그드페인’ 이후로 이어지는 팬드래건 왕실의 계보에 관한 자료는 내부에서도 검증된 자료를 보유하고 있지 않은 상태였다.
아마 소프트맥스에서 IP가 라인게임즈로 이전되는 과정에서 자료가 유실되었거나, IP 관리 및 발전을 담당했던 안타리아 팀의 자료 관리 상태가 썩 좋지 않았던 거로 추정된다.
이것은 창세기전 IP 전반의 확장 및 개발에 관해서도 악영향을 미칠 수 있을 리스크로 남게 되었는데, IP팀에서 공유받은 자료조차 잘 정리된 자료 하나 없이, 메모장에 끄적인 온갖 아이디어 노트와 범람하는 ‘미개발 데이터’에 불과했다. 이 혼란 속에서 진짜 검증된 자료를 찾아야하는 문제, 그리고 그것을 게임으로 구현하기 위해 어떻게 해야할지에 관한 문제 또한 해결해야 할 숙제로 남게 되었기 때문이다.
그나마 ‘템페스트’는 사정이 좀 나았는데, 캐릭터 설정 기획 자료와 게임의 전체 스크립트 자료가 이미 확보되어있는 상태였다.
또한 캐릭터 각각에 관해서 위키를 비롯해 일부 블로그에서 캐릭터 설정 및 게임 디자인 전반에 관한 자료를 정리해둔 것을 획득하면서 내부 자료와 교차검증하기 유리했다.
템페스트를 전체 녹화한 영상, 그리고 템페스트를 직접 플레이하며 자료를 정리해주신 고마우신 분들 덕택에 내부 개발 자료와 서로 비교하며 교차검증하기 쉬운 환경이었고 덕분에 프리 프로덕션 기간을 많이 줄일 수 있었다.
원작 감성을 살리자는 단결된 방향성
템페스트 콘텐츠는 단순히 캐릭터만 뽑아내는 데서 그치지 않고, 템페스트 원작팬들이 추억할 만한 요소들도 함께 넣자는 결정이 이루어졌다.
그래서 서커스로 대표되는 미니게임, 그리고 캐릭터 하나하나마다 엔딩을 볼 수 있게 하자는 내러티브 생산이 결정됐다.
기존 창세기전 2 시리즈와의 연결고리를 어떻게 이어줄지에 대한 고민도, ‘시즈 세계관’을 통한 게임의 다차원적 해석 맥락을 넣어주자는 쪽으로 풀자 생각보다 어렵지 않게 해결되었다.
창세기전 원작은 생각보다 ‘열린 세계관’이다. 모든 장르(판타지, 무협, SF)가 등장했고, 모든 플롯(왕도적 서사, 복수의 서사, 사랑의 서사 등)이 있었다.
원작의 어떤 부분이 좋았는지를 생각하며 이번 프로젝트에 그 감성을 어떻게 입힐지 고민하는 일은 개발자입장에서도 즐거운 일이었다.
템페스트 포스트모템 #1 – 아쉬웠던 점
레퍼런스가 없음
게임 위에 게임을 얹는다는 발상은, 마치 건물 위에다가 건물을 짓겠다는 것처럼 황당무계했다.
최소한 그런 시도를 했다는 게임이 있었다면 참고했겠지만 안타깝게도 그런 게임을 들어본 적도, 경험해본 적도 없었다.
모든 것이 새로웠고, 모든 것이 새로운 시도였던 점에서 내부에서조차 ‘이거 이대로 괜찮을까?’라는 우려가 확산됐다.
대표님부터 이 결정이 정녕 옳은 길인지 수차례 고민했지만, 이 길 외에 템페스트를 개발 가능한 시나리오란 존재하지 않았다. 사실상 소거법을 택한 셈이었다.
그저 원작 감성을 살리겠다는 공허한 메아리를 안고 게임 디자인 및 템페스트 아트 아이디에이션이 진행되었다.
엉성한 디테일의 개발 방향성
큰 틀에서의 개발 방향성은 명확했지만, 개발에 참여하는 모든 사람이 하나의 일치된 방향성을 갖게되기까지는 많은 난관이 있었다.
창세기전 모바일은 기본적으로 원작팬을 위한 게임이다.
그러나 ‘템페스트’ 시리즈를 좋아하는 팬층은 기존의 원작팬과는 궤가 다른 팬층이다.
비유하자면, 창세기전 2 원작팬이 ‘반지의 제왕’ 팬이라면, 템페스트 원작팬은 ‘세일러문’ 팬층이다.
그렇다면 두 마리 토끼를 다 잡으려면 어떻게 해야 할까?
두 마리 토끼를 다 잡으려다가 두 마리를 다 놓친다는 옛말이 있다.
창세기전 2의 그 그림체를 유지하면서 소위 말하는 ‘연애하는 감성’을 낸다? 개발자 스스로가 고개를 가로저을 정도로 비현실적인 일이었다.
지금은 1997년이 아니라 2024년이기 때문이다.
템페스트 원작 고증을 최대한 지키는 한편, ’24년도에 맞는 현대화된 룩앤필’로 개발하자는 결정이 났다.
그나마 다행이었던 건 캐릭터의 그림체는 현대적 스타일로 개선한다고 못박은 점이었다.
원작(이경진씨 스타일의 그림) 그림체 그대로 살린 채 캐릭터를 ‘상품’으로 팔기에는 도저히 매출 부스팅이 어렵다는 판단 때문이었을까.
결국 어느 정도의 고증을 포기하더라도, 최대한 디테일은 챙기기로 했다. 그리고 이 결정은 원작팬의 반발이 생각보다 적었던 점에서께 나쁘지 않은 판단이었음이 드러난다.
경험 목표로는 템페스트의 서커스를 만들고, 훈련과 육성을 도입하고, 폭포와 온천을 넣기로 했다. 그게 가장 원작팬의 ‘반발’을 줄이는 방향성이라는 판단 때문이다.
하지만 폭포와 온천을 어떤 그래픽으로 넣을지, 어떤 타이밍, 퀄리티로 넣을지도 모두 여전히 안개속이었다.
원작 고증과 현대적 아트풍 사이에서의 고민
창세기전 4의 이런 처참한 완성도로 리나를 만들고 싶지 않았다.
예상했다시피, 아트 스타일을 결정하는 단계에서 문제가 생겼다.
원작 그림체의 ‘재현’ 여부가 관건이었다.
완벽한 원작의 고증으로 간다면 신규 유입층은 포기해야 한다. 왜냐하면 기존의 그림체는 이제 20년도 더 된 낡은 그림체인데다, 서브컬처의 타 프로젝트와 비교해도 우위에 있다고 보기 어려웠다.
한마디로, 상품성이 떨어졌다.
또한 ‘이경진 IP 디렉터풍 창세기전’ 그림체가 마케팅으로 노출되고 시장에서 그리 좋은 반응을 얻지 못한채, 템페스트까지 그런 아트풍을 고수한다는 결정은 리스크가 너무 컸다.
결국 템페스트는 기존의 창세기전 모바일 아트풍과 차별화를 두기로 결정되었다.
창세기전 모바일의 그림체가 템페스트에서 이렇게까지 바뀔 수 있었던 건 ‘이경진 IP 디렉터’가 빠져서만이 아니다.
수많은 회의와 고민들, 그리고 거듭되는 재수정과 출시 시기라는 나쁜 시기까지 견디어 낸 일부 개발자들의 열정 덕분이었다.
템페스트 포스트모템 #2 – ‘프리 프로덕션’
프리 프로덕션 단계는 고통스러운 ‘스펙 줄이기’와 ‘허들 넘기’로 요약할 수 있다.
스펙 줄이기란, 말 그대로 게임에서 개발하고자하는 스펙을 축소하는 작업이다.
가령, 처음에 목표로 했던 게 ‘육성 연애 어드벤처 RPG’였다면, 여기에서 RPG를 제외한 ‘육성 연애 어드벤처’만 남기는 식이다.
어느 정도 게임의 재미를 포기해야한다는 결정을 스스로 내리는 건 고통스러운 일이었다.
가령, ‘원신’을 만들고 싶은데 지금 주어진 일정이 3개월이라면 원신은 커녕 미니게임 하나 만드는 것조차 벅차다.
주어진 일정 내에 우리가 가장 할 수 있는 게 뭐가 있을지 고민하는 것은 필요했다.
그리고 그 기준은 앞서 말한 ‘게임 디자인 기둥’을 기반으로 결정되었다.
템페스트 포스트모템 #2 – 좋았던 점
바텀업(bottom-up)으로 출발한 프리 아이디에이션과 게임의 방향성
‘템페스트’를 개발하기로 한 결정은 대표님의 결정사항이지만, 구체적으로 어떤 게임을 만들지는 게임 디자이너에게 자율권이 주어졌다.
가능한 한 템페스트 원작의 감성을 살리면 좋겠다는 당부는 있었지만, 그것이 구체적으로 어떻게 실현될지에 관해서는 모든 자율권이 실무자의 손에 달리게 되었다.
‘창세기전 외전 템페스트’는 원작팬들이 미연시 감성, 연애와 육성, 불편한 전투, 무기 떨구기, 가장 이질적인 시리즈 등으로 기억하는 게임이었다.
필자는 이중에서 취할 것과 버릴 것을 구분했고, 네 가지 키워드로 템페스트의 게임 디자인 기둥을 설정했다.
바로 ‘서브컬처풍 미소녀’, ‘1인 히로인 공략’, ‘청춘의 이야기’, ‘서비스씬’이다.
이것은 개발 과정에서 변치 않는 일종의 ‘기둥’이 되어 게임의 대략적인 방향성을 설정하는 데 도움이 되었다.
일원화된 기획과 빠른 추진력
사공이 많으면 배가 산으로 간다는말처럼, 기수가 많으면 오히려 말은 달리지 못하게 된다.
템페스트의 기획은 한 명의 기획자가 메인 기획을 잡고, 또다른 기획자가 그 기획을 보조하는 식으로 이루어졌다.
가령 A 기획자가 자유롭게 아이디에이션을 하면 B 기획자가 A 기획자의 아이디어를 듣고 함께 논의하며 어떻게 구현할 수 있을지 자유롭게 의견을 나누는 식이었다.
그렇게 두 명의 기획자가 진행한 토론의 시간은 5시간에서 10시간 가까이 이어졌고, 결국 게임의 대략적인 방향성이 결정되었다.
두 명의 기획자가 그 짧은 시간 안에 게임의 방향성을 정할 수 있었던 건 ‘사공이 많아서’가 아니라 오히려 사공이 적었기 때문이었다.
인선의 성공 – 올라운더와 시니어 개발자의 조화
템페스트의 프리 프로덕션이 큰 어려움 없이 마무리될 수 있었던 건 ‘성공적인 인선’이 가장 컸다.
앞서 말한 A 기획자는 컨셉 기획부터 시스템 기획까지 두루 챙길 수 있는 올라운더였다.
B 기획자는 시니어 개발자로, A 기획자가 기획한 대략적인 큰 덩어리들이 대표님의 허들을 넘을 수 있게 현실적인 수준으로 조각하는 일을 맡았다.
비록 서로 생각하는 방향성이 다르고 커뮤니케이션상 미스가 없지는 않았지만, 곧 출시를 앞두고 모두가 허덕이는 상황에서 그 짧은 기간에 한발짝씩 성과가 나왔다.
(라이브 서비스는 1월달에 시작되었고, 템페스트 게임 디자인은 1월 전부터 계속 진행되었다.)
그렇게 템페스트의 전반적인 방향성 – 게임의 장르, 육성의 경험, 그리고 목표 룩앤필과 게임 디자인 플로우가 차례로 정해졌다.
마침내 게임이 출시한 지 얼마 지나지 않아 템페스트 10 페이지 게임 디자인 문서가 완성되었다.
대표님의 허들을 고작 두 명의 기획자가 넘을 수 있었던 건 그러한 적절한 인선 덕택이었다.
템페스트 포스트모템 #2 – 아쉬웠던 점
아트 재정립의 어려움
이미 ‘창세기전 2’ 스타일에 맞춰 오랫동안 그림을 맞춰온 원화팀은, 템페스트가 미소녀 연애 시뮬레이션풍의 아트로 나와야한다는 점에 난색을 표했다.
아트가 바뀐다는 건, 하나의 게임의 룩앤필(Look&Feel)과 게임의 경험마저 두 갈래로 나뉜다는 것을 의미한다.
결국 하나의 게임에 두 가지 아트가 공존하게 하되, 다른 게임처럼 보이지 않게 해야한다는 오묘한 결론이 났다.
원작 캐릭터를 두고 완전히 새로운 재해석을 거친 비주얼을 내세운다면 원작팬뿐만 아니라 템페스트를 좋아하는 팬들마저 등을 돌릴 우려가 있었다.
그렇게 서로 다른 두 시리즈의 ‘컨셉적-비주얼적 차별화’를 이루는 것이 내부의 숙제가 되었다.
처음 결정된 건 원작 고증 : 재해석 = 8 : 2 비율이었다.
개발을 거치면서 이 비율은 7:3,6:4로 점차 낮아졌고, 템페스트 비주얼 방향성은 끝없이 수정되면서종국에는 3:7로 역전되었다.
그 과정에서 발생한 혼란을 수습하는 건 오로지 기획자의 몫이었다.
출시 임박이라는 최악의 개발 조건
템페스트 프리 프로덕션은 10월에서 2월까지 진행되었다.
넉넉한 기간이라고 하기에는, ‘1월 라이브 서비스 개시’라는 막강한 난적이 문제였다.
그 모든 개발 목표가 ‘안정적인 라이브 서비스 개시’라는 하나의 방향성으로 수렴되면서, 템페스트의 개발에도 차질이 빚어졌다.
일주일에 고작 몇 시간밖에 기획서를 쓸 시간이 확보되지 않는 상황에서, 이미 오랫동안 누적된 크런치 모드의 피로감은 고작 몇 명의 개발자가 감내하기에는 하드한 상황이었다.
만약 ‘출시 임박’이라는 상황도, ‘라이브 서비스’ 중 프로덕션이라는 상황도 아니었다면 템페스트의 최초 청사진에서 그렸던 수많은 ‘재밌을 요소들’을 쳐내지 않아도 됐을지도 모른다.
커뮤니케이션 미스와 일정 딜레이
하나의 기획을 두고도, 두 명의 이해관계가 서로 엇갈리는 일이 발생했다.
기획서의 디테일에 관한 문제였다.
A 기획자가 자신의 스타일대로 기획서를 쓴다고 가정했을 때 걸리는 예상 소요일이 5일이라면, B 기획자는 자신이 생각한 기획서를 작성하는 데 이틀 정도로 추산했다.
회의를 하며 같이 협의하기로 한 날짜가 의도치않게 계속 딜레이되었고, 서로 원한 결과물도 달랐다.
‘사용자 경험 맵’이라는 용어와 ‘스냅샷’이라는 용어가 문제였다.
기획자 서로가 서로 생각하는 기획의 구상범위가 다르다보니, 해당 용어를 보고 이해하고 실행한 결과물이 서로의 기대와 달랐던 것이다.
그 결과 크게 다르지 않은 내용의 기획서를 다시 써서 공유해야하는 등 의도치 않게 일정 딜레이 문제가 생겼다.
하지만 배운 것도 있었는데, 빠른 개발 과정에서는 무엇보다도 ‘상호이해’가 중요하며, 각자의 이해에 따른 ‘문서주의’ 위주 개발은 리스크가 크다는 점이었다.
이때의 쓰라린 경험은 이후의 개발 과정에서 의외의 과정으로 빛을 발하게 된다.
템페스트 포스트모템 #3 – ‘담당자 변경과 프로토타입 개발’
프리 프로덕션이 끝나고 마침내 80페이지에 달하는 게임 디자인 비전 문서가 완성되었다.
이로써 프로덕션으로 넘어가기 위한 준비가 끝났다.
이 전환 과정에서 큰 개발 변곡점이 생겼는데, 요약하자면 다음과 같다.
- 템페스트 TF 해체 및 재창립
- TF 리드 변경 (기획자 A -> 기획자 B)
- 재미 검증을 위한 프로토타입 개발
- 벤치마킹 게임 변경
- 스펙 축소
회사에서는 그동안 템페스트 TF 리드를 이끌어온 A 기획자에게 ‘메인 기획자’ 제안을 했다.
하지만 A 기획자는 출시 시기에 맞물린 과도한 일정 문제, 그리고 장기간 이어진 크런치로 인한 건강 악화 등의 이유로 도저히 템페스트 메인 기획을 리드할 여유가 없었다.
결국 TF 리드가 그동안 개발을 보조해온 ‘기획자 B’로 변경되었는데, 뜻밖에도 여기세서 기획자 A는 이후 템페스트 TF 회의 초대에서 몇 달간 배제되는 결과를 맞이한다.
기획자 A와 기획자 B가 아무리 같이 협업했다고는 하나, 기획자 A의 모든 기획의도를 기획자 B가 이해할 수 있을리는 만무했다.
인수인계 하나 없이, 기획자 A의 참여를 완전히 배제한 이후의 개발은 어땠을까?
기획자 B와 윗선의 판단에 의해 벤치마킹 게임이 변경되었다. 벤치마킹 게임이 변경됨에 따라 게임의 핵심 경험 목표가 흔들렸고, 기획자 A가 구상한 일부 스펙도 덩달아 축소되었다.
한편 그 시각.
템페스트의 빠른 개발 재미 검증을 위해 프로그래머 중 일부가 템페스트 콘텐츠의 재미 검증을 위한 프로토타입 개발에 투입된다.
기획자 A가 이탈하고, 갑작스런 스펙 변동이 발생하는 시기에 영문도 모른 채 투입된 ‘프로그래머 주도 개발’이 이렇게 시작된 셈이다.
이렇게 템페스트 개발은 혼란에 빠지기 시작한다.
템페스트 포스트모템 #3 – 아쉬웠던 점
일정 문제가 초래한 메인 기획자 부재
일반적인 개발 환경이라면 지금까지 해온 기획자가 계속 지금까지 맡아온 템페스트를 개발하는 게 맞을 것이다.
그러나 해당 기획자가 템페스트를 집중적으로 담당하기에는, 동시에 진행해야 할 업무량이 너무 많았다. 오히려 게임 출시와 맞물려 빡빡한 일정 속에서 템페스트 기획을 여기까지 진행해온 게 기적같은 일이었다.
결국 A 기획자는 자신의 원래 포지션의 업무를 챙기기 위해 ‘메인 기획자’라는 자리를 양보하게 된다.
이어 TF 리드를 B 기획자가 맡았지만, B 기획자는 A 기획자의 기획의 방향성을 바꾸기 시작한다.
B 기획자의 리드 하에, A 기획자가 구상한 용어 정책, 연출 방식, 그리고 인게임의 경험 요소가 모두 바뀌게되었다.
대표님이 요구한 사항에 의해 그런 결정이 내려졌다고는 하나, A 기획자가 구상한 방안이 밀실 속에서 바뀌었고, A 기획자는 이를 공유받지 못하였다.
결국 A 기획자는 다른 협업 파트너들이 기획에 관해 문의를 해도 답변을 할 수 없는 상황에 이르게 된다.
개발 기조 변화 – 실무자에서 관리자로, 바텀업에서 탑다운으로, 기획자에서 프로그래머 중심으로
지금까지 빠르게 개발될 수 있었던 건 실무자 중심의 바텀업 개발이 어떠한 강한 의지(탑다운)의 개입 없이 무난하게 허들을 통과할 수 있었기 때문이었다.
그러나 A 기획자가 이탈하게 되면서 동시에, 개발 기조의 변화가 일어났다.
- 개발 리드: 실무자(팀원) -> 관리자(직책자)
- 의사결정구조: 상향식 의사결정(바텀업)-> 하향식 의사결정(탑다운)
- 개발 주체: 기획자 -> 프로그래머
그동안 개발 과정 전반에 관한 이해가 상대적으로 부족한 직책자가 이어서 개발 리드를 맡게 되면서, 게임에서 주고자 하는 재미나 경험이 아닌, 스펙 규모의 일방적인 조정, 그리고 벤치마킹 타깃 게임이 변경되는 일이 벌어졌다.
그렇게 앞서 정리된 ‘게임 디자인 비전 문서’는 폐기되었고, 전혀 다른 게임을 롤모델로 한 개발이 시작되었다.
의사결정구조 또한 실무자가 아닌 관리자가 결정하게 되면서 한국의 의사결정 구조상 애자일이 일어나기 어려운 환경이 구축되었다.
한편, 개발 주체가 기획자에서 프로그래머로 변경되면서 ‘템페스트 프로토타입’ 개발이 본격적으로 시작된다.
그런데 문제는 이 프로그래머들이 개발을 위해 참고할 기획서가 없었다.
A 기획자가 준비한 ‘게임 디자인 비전 문서’는 폐기되었고, 개발 리드들은 기획서 없이 ‘벤치마킹 게임처럼 만들어라’라는 요구사항만 하달했다.
결국 프로그래머들은 탑다운에 의해 기획서 없는 개발을 반강제로 진행하게 되었다.
실패한 애자일과 프로토타입 폐기
빠르고 기민한, 이라는 이름 덕인지 수많은 기업들이 나서서 애자일로 개발한다고 떠들고 있지만, 정작 실상은 애자일이 뭔지도 모르면서 기획서를 통과시키기 위해 붙이는 전문용어중 하나의 취급일 뿐이다. 애자일을 제대로 하려면 QA 인력도 필요한데, 애초에 애자일 방법론은 하나의 개발 모델이 아니라, 여러 개의 개발 방법론이 있는 개발 방법론 집합체의 원칙에 가깝다.
애자일이 제대로 돌아가기 어려운 것은, 말만 애자일이지 결국 워터폴 방식으로 운영을 하게 되기 때문이다.이런 역학구조는 활발한 의사소통, 끊임없는 프로세스 개선, 단순한 사이클의 반복을 통해 실제로 동작하는 기능을 조금씩 늘려나가는 것이 핵심인 애자일 방법론과 영 맞지가 않는다.
나무위키 ‘애자일’ 일부 인용
내부 개발조직은 ‘애자일 방법론’을 채택하고 일하고 있다. 하지만 실상은 변질된 애자일에 의해 모두가 고통받는 구조로 되어 있다.
실패한 애자일이란 무엇일까? 필자는 아래와 같은 요소에서 애자일의 취약점을 감지했다.
- 포괄적인 문서보다 작동하는 소프트웨어를
위 문구를 두고, 템페스트 개발 리드는 ‘메인 기획자와 기획서가 당장은 없어도 개발이 가능하다’라는 어떠한 신념을 갖고 개발자들을 대했다.
그 결과 애자일은 아래와 같이 변질되기 시작한다.
- 활발한 의사소통 -> 개발 리드에 의한 잦은 개발 요구 압박
- 단순한 사이클의 반복 -> 개발 목표 – 1플레이 사이클과 재미 요소조차 공유되지 않은 기획
- QA 인력의 필요성 -> QA 부재, TC없는 개발 진행
이렇게 된 이유가 뭘까?
앞서 준비된 ‘템페스트 게임 디자인 비전’ 문서가 폐기되면서, 프로그래머들은 자신들이 만들어야 할 결과물에 대한 어떠한 레퍼런스도 없이 개발에 투입되었다.
‘~~게임처럼 해주세요’라는 모호한 방향성.
플로우 차트 정도만 존재하는 ‘컨셉 기획서’라는 이름의 무언가를 받아본 프로그래머는 굉장히 난처했을 것이다.
그러나 그러한 요구를 하는 주체가 서로 동등한 입장에 있는 실무자가 아니라 직책자인데다, 회사 대표가 직접 신임하고 결정권을 준 상태에서 그 결정을 뒤집기란 사실상 불가능에 가까웠다.
프로그래머는 결국 프로토타입의 목표가 무엇인지, 어떠한 부분에서 재미를 검증해야하는지 공유받지 못한 채 ‘~~게임’같은 무언가를 만들기 시작했다.
한 달이라는 시간이 지나고, 슬슬 성과를 기다리던 윗선은 실망을 금치 못했다. 한달 가까이 개발한 프로토타입 코드는 어떠한 목표도 달성하지 못했기 때문이다.
실무자는 그 이유를 안다. 프로토타입이 어떠한 목표를 달성하지 못한 이유는 프로그래머가 무능해서가 아니라 ‘구체적인’ 목표가 없었기 때문이었다는 사실을.
그렇기에 달성 가능한 목표 자체가 없었기 때문이었다는 것을.
그렇게 골든 타임 한 달이 소멸되었다.
템페스트 포스트모템 #3 – 이랬으면 어땠을까
‘게임 디자인 비전’의 폐기 -> 비전 PT를 통해 스튜디오 전체 공유
그동안 템페스트 TF를 리드해 온 기획자가 일정 문제로 템페스트 개발 전선에서 이탈하면서 템페스트의 게임 디자인 전반의 방향성은 붕 떠버리게 된다.
그리고 얼마 뒤 프로토타입의 폐기라는 안타까운 참사가 벌어지며 1달이라는 소중한 시간을 허비했다.
만약 ‘A 기획자’가 준비한 게임 디자인 비전이 템페스트 개발자 모두에게 충분히 전달될 수 있었다면 어땠을까?
‘~~게임’같이 만들겠다는 불투명한 목표 대신, 앞서 준비된 기획안을 받아들이고 그것을 그대로 실행하기만 했더라도 프로토타입은 최소한 ‘A 기획자의 기획안의 재미 검증’이라는 보다 명확한 목표로 진행되었을지도 모른다.
A 기획자가 준비한 기획이 100% 완벽했을 리 없다. 하지만 ‘~~게임’처럼 만들어달라는 요구보다는 프로그래머가 느꼈을 혼란의 크기는 적었으리라.
필자가 한때 몸담았던 조직에서는 짧게는 3개월에서 6개월 단위로 ‘비전 PT’라는 것을 진행했다. 내러티브 디자인 리드가 중심이 되어, 앞으로 나아가야 할 방향성을 스튜디오 구성원 전체에게 공유하는 자리다.
원래는 리드급만 참석하던 이 회의는 점차 자발적 참여자가 늘어나, 나중에는 스튜디오 구성원의 절반 넘는 수십 명이 참석할 정도로 커졌다. 그 이유가 무엇이었을까?
참석자들은 ‘비전 PT’를 보며 자기가 이번 프로젝트에서 무엇을 해야할지 스스로 생각해볼 수 있는 자리였으며, 나아가 내러티브 리드의 발표를 듣고 바로바로 자신의 의견을 교환할 수 있는 자리였기 때문이다.
원화팀을 비롯해 프로그래머들까지 발표를 들으며 앞으로 어떤 스펙이 추가될 것이며, 그것을 위해 무엇을 준비해야할지 먼저 대비할 수 있었다. 오히려 자신들이 더 들떠서 더 많이 만들어보겠다고 자발적으로 의견을 내는 팀마저 존재했다.
‘~~게임’을 만들자는 게 아니라, ‘우리 게임’을 만들겠다는 사람들의 눈빛이었다.
그 열성적인 개발자들의 열의와 노력, 그리고 인내는 머지 않아 몇백 만 조회수의 유튜브 영상, 그리고 수 배로 뛴 매출과 동시접속자라는 쾌거를 이뤄냈다.
두 프로젝트의 핵심 차이는 바로 하나였다.
프로젝트 비전의 ‘공유 여부’였다.
밀실에서 결정하는 R&R -> 각 멤버에게 구체적인 역할 지정
프로그래머가 프로토타입에 매진하던 사이, 기획자(직책자)들은 회의실에서 따로 모여 템페스트의 ‘무언가’를 정하는 회의를 여러차례 거쳤다.
안타깝지만 필자도 이 회의에서 무엇이 정해졌는지는 확실하게 알 수 없다.
한 가지 확실한 건, 프로그래머가 기획자에게 구체적인 방향성이나 기획서를 달라고 도움을 요청하는 것과 이 회의가 열리는 이유는 전혀 별개라는 사실이었다.
이 ‘밀실’의 특징은 다음과 같았다.
- 늘 고정된 멤버만 참가한다.
- 회의에서 결정한 무언가의 논의 내용과 결정사항이 회의록으로 공유되지 않는다.
- 회의가 끝난 뒤 어떠한 구체적인 액션(또는 액션 플랜)이 없다.
만약 템페스트 개발에 참여할 멤버를 미리 정해두고, 모든 인원이 자유롭게 토론할 수 있는 공론의 장이 있었다면 어땠을까?
템페스트 프로토타입 개발에 참여하는 두 명의 프로그래머가 그 자리에 고정멤버였다면 어땠을까?
게임 디자인 비전이 프로젝트 구성원에게 공유될 기회가 없었다고 할지라도, 최소한 그런 자리가 있었다면 템페스트의 각 멤버들이 자신이 해야 할 일과 목표를 명확하게 인식할 수 있지 않았을까.
그저 회의에서 무언가 명확한 방향성이 결정되기를 ‘기다려야만 했던’ 누군가에게는, 이후에 이어질 일정 파국의 충격을 조금이라도 줄일 수 있는 아주 소중한 기회의 시간이 아니었을까.
(변질된) 애자일 -> 수평적인 토론과 합의점 도출
한국에서 애자일이 실패할 수 밖에 없는 이유가 뭘까요? 그건 바로 애자일 개발의 결정 권한이 수평이 아니라 수직으로 주어져있기 때문입니다.
내부 개발자 인터뷰 중 일부
보스의 눈치를 봐야하는 조직에서 보스가 ‘애자일’을 하자고 하면 긴장하는 게 좋다.
한국 특유의 군대식 ‘상명하복’ 문화에 의해, 유연한 개발을 추구하는 애자일의 정신은 변질되었을 가능성이 높기 때문이다.
‘이등병’과 ‘병장’이 평등하고 동등하게 결정권한을 갖고 있는 조직이 있다고 생각해보자. 상상이나 할 수 있겠는가?
이게 바로 한국 애자일이 실패할 수밖에 없는 이유다.
피터지게 싸우는 건 애자일 안에 들어있는 실무자들이고, 그 갈등의 단초를 마련한 결정권자는 실무자가 간신히 내놓은 ‘달콤한 기획안’을 체리픽하듯이 쏙쏙 골라먹는다.
만약 달콤한 기획안이 나오지 않으면 화를 낸다. 이것이 그동안 거쳐왔던 많은 회사들의 ‘애자일 문화’였다.
만약 이 게임이 한국이 아니라 수평적인 조직문화를 가진 회사에서 개발되었다면 어땠을까?
대표와 신입이 계급장을 떼고 서로 ‘미스터 킴’, ‘미스터 리’ 라는 동등한 개발자 관계가 되어, 오직 프로젝트의 안정적인 개발이라는 하나의 지향점을 향해 토론하는 조직.
그리고 결국 정해진 결정 과정에 모두가 수긍하고 납득하며 구체적인 액션 플랜이 나오는 조직.
만약 그럴수만 있다면 우리나라 게임회사는 애자일을 포기할 이유따윈 전혀 없다.
하지만 이곳은 한국이며, 북한과 여전히 전쟁중인 나라이며, 앞으로도 바뀔 일 따위 없다는 걸 우리 모두가 알고 있다.
한 두명의 ‘깨어있는 지성’만으로는 조직 전체에 침식한 ‘조직문화’ 바꿀 수 없듯이.
템페스트 포스트모템 막간 – ‘리소스 발주’와 구조화
프로토타입 개발 및 밀실회의가 진행되는 동안, A 기획자는 무엇을 하고 있었을까?
앞서 일정 문제로 템페스트 게임 디자인 과정에서 배제되기는 했지만 A 기획자가 마냥 손을 놓고 있었던 건 아니었다.
템페스트 프로젝트에 관해 가장 많은 이해를 가졌던 A 기획자는 프로젝트의 성패와는 무관하게 두 가지 목표를 설정하고 실행에 옮긴다.
바로 ‘리소스 발주’와 템페스트 게임 데이터의 ‘구조화’다.
템페스트 포스트모템 막간 – 잘한 점
스펙 구조화
템페스트 개발 필요 요소는 크게 ‘게임 디자인’과 ‘(주로) 아트 리소스’로 분류할 수 있다.
템페스트 핵심 경험 목표는 미소녀와의 연애 느낌이 나는 것이므로 풍부한 인터랙션 요소가 준비될 필요가 있었다.
템페스트 게임 디자인 비전은 은근슬쩍 폐기됐지만 풍부한 인터랙션이 없이는 템페스트가 달성하고자 했던 최초의 목표조차 무너질 우려가 있었다.
남은 기간은 넉넉하지 않았지만, 템페스트가 성공하기 위해서는 풍부한 ‘아트 리소스’ 확보가 무엇보다도 중요했다.
A 기획자는 비록 템페스트 게임 디자인 개발에서는 제외되었지만 아트 리소스 확보를 위한 문서를 준비하기 시작한다.
핵심은 캐릭터의 모션과 표정이었다.
매력적인 모션을 만들기 위해서 야겜의 모션을 차용하는 것도 주저하지 않았었다.
@허니컴
모션의 경우 목표 제작 수량은 캐릭터당 20개였다.
모든 캐릭터가 제각기 다른 모션을 가질 필요는 없었다. 그래서 크게 3가지로 모션 종류를 구분했다.
먼저 모든 캐릭터가 돌려쓸 공통 모션을 정리하고, 캐릭터성에 따라 크게 4가지의 그룹 모션을, 그리고 각 캐릭터마다 고유한 모션을 정리했다.
예를 들어, 다음과 같다.
- 캐릭터 A: 공통 모션 8개 + 그룹 A 모션 4개 + 그룹 C 모션 4개 + 고유 모션 3개
- 캐릭터 B: 공통 모션 8개 + 그룹 B 모션 4개 + 그룹 D 모션 4개 + 고유 모션 1개
- 캐릭터 C: 공통 모션 8개 + 그룹 A 모션 4개 + 그룹 D 모션 4개 + 고유 모션 2개
이렇게 스펙을 구조화하고 각 캐릭터에 맞게 스펙 문서를 구분하니, 적은 시간 안에 짜임새있는 구조의 모션 발주서가 탄생했다.
발주자 입장에서도 초반에만 레퍼런스를 충분히 준비하면 이후에는 편리한 구조가 되었고, 제작자 입장에서도 각 캐릭터의 모션을 조금씩만 돌려써도 충분한 구조가 되어, 짧은 시간 안에 많은 모션 제작이 현실적으로 가능하게 되었다.
신속한 유관부서 스펙 공유
아무리 잘 구조화된 발주서라고 해도, 그것을 제작하겠다는 구체적인 ‘액션 플랜’의 공유가 없었다면 유관부서의 지원을 받기에는 어려웠을 것이다.
큰 반발없이 이러한 개발 리소스 제작을 지원받을 수 있었던 이유는 이러한 스펙을 전달할 것이라는 언질을 꾸준히 주었기 때문이다.
먼저, 아직 수량은 정해지지 않았지만 대략적인 개발 필요 공수를 전달하는 것만으로도 유관부서에서 일정을 미리 비워놓는 등 대비는 할 수 있다.
그 개수를 정하는 과정에서도 유관부서와의 협의는 필수다.
기획자가 최종적으로 원하는 개수가 40개라고 해도, ‘필수’ 20개, ‘추가 희망’ 20개로 나눴다.
유관부서 입장에서는 처음에는 20개만 제작한 뒤 여력이 되는대로 더 만들 수 있겠다고 계획을 짤 수 있기 때문이다.
여기서 ‘필수’와 ‘추가 희망’으로 나눠, ‘필수’만 제작되어도 게임이 문제 없이 굴러갈 수 있게 하는 건 기획자의 재량이다.
중요한 건, 만들어주시는 아티스트 입장에서 기획자로부터 일정을 ‘배려받는다’고 느끼는 것이다.
그래야 아티스트들도 기획자가 구상한 아이디어를 진심으로 지원해주고 싶다고 느낄 수 있다.
이러한 ‘믿음’을 기초로 템페스트가 개발되었다.
개발자 편의성 툴 제작과 각 포지션의 분업
한편, 게임 개발은 아니지만 개발자 편의성 툴이 빠르게 개발된 것도 이후의 템페스트 개발에 큰 도움이 됐다.
템페스트는 ‘소셜 모션’이라고 부르는 새로운 기능이 들어간 만큼, 테이블 구조부터 리소스 격납 경로까지 모두 새로 만들어져야 했다.
안그래도 짧은 개발 시간 안에 어떻게 개발자 편의성 툴까지 만들어질 수 있었을까?
그건 개발자 편의성 툴 필요성에 공감한 세 명의 분업이 아래와 같이 이루어진 덕택이었다.
- 기획자는 아티스트에게 필요한 리소스의 수량과 이름 규칙, 리소스 컨셉을 전달한다.
- 아티스트는 작업물을 만들고 정해진 경로에 기획자가 지정한 이름대로 리소스를 올린다.
- 프로그래머는 리소스의 이름과 경로를 불러오는, 로컬에서 테스트할 수 있는 기능을 만든다.
기능구현이 완료되자 그때그때 게임을 빌드하거나 연출 출력 조건을 맞출 필요 없이, 바로바로 편의성 씬에서 결과물을 확인하고 고칠 수 있는 환경이 마련되었다.
편의성 툴 덕택에 개발속도가 빨라지자 자연스럽게 테스트를 할 수 있는 시간이 확보되었고, 테스트를 거칠수록 소셜 모션의 버그나 애니가 튀는 지점의 디버깅 속도가 빨라졌다.
출시 직전이 되자, 편의성 툴을 제공받은 그룹은 다른 TF 구성원에 비해 개발환경이 훨씬 좋아졌다.
기획자는 빠른 결과물 확인과 디버깅이 가능해졌고, 아티스트는 일정상 부하를 줄일 수 있었으며, 프로그래머도 자신이 만든 편의성 툴만 관리하면 되어 사실상 다른 업무를 병행할 수 있게 되었다.
애자일이 아름다운 형태로 돌아가는 것을 목격한 순간이었다.
템페스트 포스트모템 막간 – 아쉬웠던 점
담당자 혼란
밀실 회의가 진행되면서 밀실 밖의 개발자들은 어떤 사람이 어떤 스펙을 담당하는지 전혀 알 수 없게 되었다.
아티스트나 개발자 입장에서는 두 명에게 각기 다른 기획서를 받게 될까봐 경계하게 되었다.
밀실 안의 사람들은 어떤 논의가 오가는지 공유가 미흡했고 밀실 밖의 사람들은 밀실 안에서 어떤 결정이 내려질지 불안해했다.
보다 못한 일부 개발자는 자신들이 앞으로 맡게 될 것으로 예상되는 일들을 미리 예측하고 대비책을 세우기 시작했다.
가령, 루틴하게 처리하는 일부터 다 처리해놓은 뒤 새로 기획하기 위한 시간을 벌어두는 식이었다.
만약 밀실에서 무언가가 논의되고 있는지, 그리고 그것이 언제쯤 실무자에게 전달되어 개발이 시작될 지 공유만 되었더라도 이러한 혼란은 최소화되었을 것이다.
템페스트 포스트모템 #4 – ‘프로덕션’
다만 그 안에 담긴 ‘디테일’은 상당한 차이를 보이지만.
출시까지 한달 남은 상황에서 제대로 된 건 아무것도 없었다.
게임의 리소스가 준비되지도, 작동하는 소프트웨어도, QA의 TC도 없었다.
누군가는 이 혼란을 수습해야했다.
그동안 밀실에서 무언가를 진행해오던 멤버들은 조용히 한발 물러섰고, 개발 최전선에서 다른 피처를 개발하던 개발자들이 소방수로 투입되었다.
총대는 시스템 파트의 리드가 맡았다. 그리고 일부 기획자가 구현에 필요한 몇 가지 요소를 각기 나눠가졌다.
여전히 구현까지 남은 시간과 일정은 부족했지만, 일단은 각 피처에 관한 담당자가 정해지자 프로그래머도 한숨 돌리게 되었다.
그러나 여전히 핵심 문제는 해결이 되지 않은 채 남아 있었다.
‘~~게임’처럼 만들자는 공허한 이상을 여전히 이 프로젝트는 놓지 않고 있었다.
그리고 이 ‘이상’을 실현하기 위해 얼마나 많은 공수가 들어가는지, 새로운 담당자들은 아직 파악하지 못하고 있었다.
마치 체르노빌 원자력 발전소 화재에 영문도 모른 채 맨몸으로 투입된 소방수들 같았다.
한편, 도저히 게임이 일정 내에 나올 것 같지 않다고 판단한 각 리드들은 기존 목표 스펙에 면도날을 대기 시작한다.
어느 부분을 줄이고 어느 부분을 남길건지에 관한 결정권은 여전히 이 콘텐츠의 핵심 경험 목표가 무엇인지 제대로 파악하지 못한 분들의 손에 의해 쥐어져 있었다.
기획자는 소방수가 되었고, 직책자는 영문도 모른 채 결정권을 쥔 칼잡이가 되었으며, 대다수 프로그래머는 영문도 모른 채 지금까지 진행하던 업무를 올 스탑하고 이 총력전 사태에 징집되었다.
이제 프로덕션은 시작되었다.
템페스트 포스트모템 #4 – 잘한 점
기획의도의 수성과 유연한 대응
@러브인로그인
템페스트 게임 디자인의 커다란 기둥은 끝까지 바뀌지 않았다.
담당자가 교체되기도 하고 숱한 기획 수정이 발생했지만 큰 틀에서의 기획의도는 간신히 지켜졌다.
한 마디로, 미소녀 캐릭터와 연애하는 듯한 느낌을 받을 수 있게 하자는 ‘미연시 감성’이다.
사내에서도 ‘미연시 감성’이 기존 플레이어들에게 먹힐지 우려의 목소리가 컸다.
하지만 대표님은 ‘원작 감성을 살린다’는 대전제의 목표 하에, 템페스트 개발의 키를 미연시 스타일로 잡았다.
미연시 스타일이라는 것은 포괄적인 개념인데, 쉽게 말해 모로 가든 ‘미연시 느낌’이 나기를 희망했다.
다행히 스튜디오 내에 원작은 잘 몰라도 서브컬처 테이스트를 공감하는 분들이 좋은 아이디어를 내어 주셨다.
덕택에 혼란스러운 일정 속에서도 미연시 감성 재현을 위한 몇 가지 기획안은 수면 아래에서 고요히 진행되었다.
템페스트 포스트모템 #4 – 아쉬웠던 점
‘스펙 축소’ -> ‘스펙 복구’가 초래한 혼란
템페스트 일정이 ‘혼란’에 빠지게 된 이유는 ‘스펙 축소 선언’도 한몫했다.
아직 코어 루프조차 동작하지 않는 상황에서 이대로 개발을 진행한다면 넉넉하게 6개월 이상이 걸린다는 추산이 나왔다.
리드 프로그래머는 이제 일정이 1개월 남은 시점에서 이대로 개발할 수 없다고 선언한다.
결국 두 가지 결정이 내려진다.
- 개발 스펙을 축소한다.
- 그동안 다른 업무를 진행하던 프로그래머도 전부 템페스트 개발에 투입시킨다.
핵심은, 일단 빠르게 코어 루프를 만든 뒤, 개발 가용 일정에 따라서 출시일 전까지 가능한 한 많은 피처를 개발해서 붙이는 것이었다.
가능한 한 빨리 빌드를 내기로 했다. 프로토타입을 빠르게 구현하고(앞서 폐기한 프로토타입이 아니라 완전히 새로운), 그것을 검증하는 게 목표였다.
5일 안에 빌드를 내는 것을 목표로 한다는 결정이 내려지자 개발자들은 날짜에 맞춰서 ‘코어’를 제외한 모든 스펙을 2순위 이하로 조정하고 스펙을 축소시키기 시작한다.
그런데 단 하루만에 결정이 뒤집혔다.
스펙을 축소한다는 것이 ‘영구적인 개발 취소’라고 잘못 오인하는 분위기가 확산된 탓이었다.
심지어 템페스트 핵심 개발자 중 한 명은 장기휴가에 의해 자리를 비운 상태. 전화 통화로만 개발 진척상황을 공유할 수 있는 상황에서 커뮤니케이션 오해는 더 커지기 쉬웠을 것으로 보인다.
결국 스펙 축소는 하나의 해프닝으로, 없었던 일이 되어버렸다.
그리고 빌드 생산 일정도 그 주 금요일에서 계속 연기되다가(스펙 축소가 취소되었기 때문에), 결국 업데이트 1주일 전에 다다라서야 간신히 빌드가 나오기 시작한다.
그나마 리드 프로그래머가 1개월 전에 이대로는 개발이 어렵다고 선언하고 프로그래머를 전부 투입시키지 않았다면 템페스트는 더욱 끔찍한 결과를 맞이하게 될 뻔했다.
템페스트 포스트모템 #4 – 이랬으면 어땠을까
동심원 개발의 도입과 단계별 목표 설정
게임 개발 과정에서 스펙이 고무줄처럼 늘어나거나 줄어드는 경우는 빈번히 발생한다.
그러나 한 가지 원칙만 고수한다면 이러한 스펙 변동에도 크게 타격을 입지 않을 수 있다.
바로 ‘동심원 개발’ 원칙을 지키는 것이다.
기초 매커닉스를 기반으로 게임의 코어를 먼저 구현한 뒤, 코어의 완성도를 높이기 위한 2, 3차 매커닉스를 단계별로 구현한다.
한 마디로, ‘우선순위’에 맞춰서 게임을 개발하면 된다는 게 동심원 개발의 핵심이다.
앞서 개발 직책자들은 ‘스펙을 축소하고 코어부터 개발하자’는 판단을 내렸다. 이것은 동심원 개발에서도 기초가 되는 ‘올바른’ 단계에 해당한다.
하지만 스펙을 다시 복구하기로 하면서 코어부터 개발하자는 목표가 무너졌고, 결국 최초 빌드를 보기까지 몇 배의 시간이 더 소요되어버렸다.
이 과정에서 일부 인원들의 끝나지 않는 야근과 주말 출근은 덤이다.
무사히 게임이 출시되었기에 망정이지, 만약 똑같은 일이 앞으로도 두 세번 벌어진다면 과연 그 팀이 건강한 게임 개발 조직이라고 볼 수 있을까?
먼저 코어 루프를 개발하고, 개발자들이 한 자리에 모여 단계별로 각 피처 담당자들이 자신에게 주어진 일정에 따라 어떤 스펙을 구현할 것인지 정하는 단계가 있었더라면 개발환경은 훨씬 덜 가혹했을지도 모른다.
템페스트 포스트모템 #5 – ‘마지막 스프린트’
템페스트 콘텐츠 출시일 조정이 없다는 것을 최종 확인하고, 마지막 스프린트가 시작됐다.
열성적인 일부 개발자들 덕택에 짧은 시간안에 많은 기능이 구현되었다.
하지만 회사의 고질적인 문제인 ‘안정적이지 않은 stable 환경’은 이번에도 재현되었다.
결국 보다 못한 일부 개발자는 템페스트 일정 문제를 거론하며 공개적으로 재발 방지를 위한 대책을 촉구했다.
마지막까지 최선을 다해 개발에 매진한, 모든 개발자들의 공감을 받았던 이번 템페스트 개발의 아쉬웠던 점이었다.
템페스트 포스트모템 #5 – 아쉬웠던 점
“매번 반복되는” 안정적이지 않은 ‘stable 빌드’
stable 빌드란 말 그대로 ‘안정성’을 위한 빌드 단계를 말한다.
git을 사용하는 조직에서는 dev – stable – qa – real 등의 순서로 빌드를 묶게 된다.(회사마다 지칭하는 용어는 전부 다르다.) 여기서 stable은 ‘웬만해서는 조정하지 말자’고 암묵적으로 정해진 빌드 단계에 해당한다.
하지만 stable 빌드에서도 수십 가지의 신규 개발 피처가 들어가거나, 여전히 임시 데이터가 들어가 있거나, 개발 스펙이 하루에도 여러차례 바뀌는 일이 일상이었다.
지나치게 짧은 개발 일정이 주어지다보니 stable 일정까지 끌어다쓰는 개발을 해야만했기 때문이다.
이는 비단 템페스트 업데이트때문만이 아니라 그동안 이 회사의 개발 파이프라인이 이런 식으로 고착화되어버린 폐단이었다.
그 ‘관례’는 템페스트에 와서도 여전했던 것이다.
재미를 테스트할 수 없는 빡빡한 스케줄
창세기전 모바일의 업데이트 주기는 크게 2주이다.
1주마다 주차별 신규 캐릭터까지 출시하는 등 매출 리텐션 유지를 위한 모든 방안이 실행된다.
개발진 내부에서는 2주 단위로 모든 것을 개발하는 것을 부담스러워한다.
대략 develop 개발이 5일 미만, stable 개발이 5일 미만으로 주어지는 상황에서 신규 콘텐츠 업데이트란 사실상 불가능에 가깝다.
매 업데이트를 총력전처럼 진행하는 상황에서 위 구조를 바꾸는 유일한 방법은 업데이트 주기를 2주에서 그 이상의 주기(예: 4주)로 조정하는 방법밖에 없다.
그러다보니, 개발자는 stable 빌드로 넘어가서도 신규 및 수정 기능을 넣을 수밖에 없게 된다.
기획자와 QA 입장에서도 난감한 건 마찬가지다.
2주 안에 이번에 새로 넣은 게 무사히 돌아가기를 바라는 건 사실상 하늘의 뜻에 달려있는 셈이기 때문이다.
이번 스프린트에 신규 피처를 담당하지 않은 기획자가 자신의 일정을 쪼개 게임을 테스트하고 버그와 재미검증을 해주기는 하지만 게임의 모든 것을 검증하기는 어렵다.
QA 입장에서도 기획자가 stable에 넘어간 상태에서도 TC를 만들어줄 수 없는 환경임을 알고, 알아서 기획서와 stable 빌드를 실시간으로 대조해가며 ‘탐색적 테스팅’으로 버그를 찾을 수밖에 없다.
이런 환경에서 Fun QA까지 바란다면 그건 분명 과한 욕심이었다.
보스의 면도날
ko.wikipedia.org/wiki/오컴의_면도날
- “많은 것들을 필요없이 가정해서는 안된다” (Pluralitas non est ponenda sine neccesitate.)
- “더 적은 수의 논리로 설명이 가능한 경우, 많은 수의 논리를 세우지 말라.”(Frustra fit per plura quod potest fieri per pauciora.)
오컴의 면도날이라는 표현이 있다.
같은 목적을 달성하기 위해 여러 개의 길이 있다면 ‘간단한 것을 선택하라’는 수사적 표현이다.
그런데 이 이론의 문제는 이것을 판단하는 존재가 ‘인간’이며, 그 인간이 막강한 권한을 가진 ‘직책자’일때 발생한다.
템페스트 개발 또한 ‘보스의 면도날’이 작용했다.
왜 자신이 이해하지 못하는 ‘불순물’이 존재하는지 불쾌했던 직책자들은 스펙 축소 과정에서 자신들이 이해하지 못한 스펙부터 쳐냈다.
이 면도날에 의해 잘려나갈 뻔한 피처 중에서 템페스트의 ‘메인 로비’가 있었다.
심지어 이 ‘메인 로비’는 최초 기획에는 존재했지만 밀실 회의에서 쥐도새도 모르게 제거되어버린 비운의 물건이었다.
앞서 게임 디자인 비전 문서를 작성한 A 기획자는 ‘메인 로비’가 없었을 때의 리스크를 고려해 메인 로비 기획을 다시 살리기로 했다.
(회사는 이런 식으로 어떤 기획이 죽고 살아나는 거에 대한 추적에 약했다.)
결국 뒤늦게 메인 로비가 왜 만들어지고 있다는 사실을 안 직책자는 메인 로비를 폐기하고 싶어했다.
일단 퀄리티가 나쁘며, 굳이 없어도 게임 플레이를 하는 데 지장이 없다는 이유였다.
아직 제작 공정이 간신히 7-80% 수준의 개발, 그리고 퀄리티는 50%도 채 되지않은 상태였다.
그런 결과물이 퀄리티가 나쁘다고 개발을 취소해야한다는 결정이 내려지면서 10명 가까운 관련 개발자의 작업물이 통째로 드랍될 뻔했다.
가까스로 ‘메인 로비의 필요성’을 어필한 기획자 덕택에 메인 로비는 결국 들어가게 되었고 퀄리티도 다행히 나쁘지 않게 나왔지만, 사실은 세상에 빛을 못 보고 사라질뻔했던 결과물이었다.
그밖에도 ‘템페스트 로딩 텍스트’라든지, ‘템페스트 상태이상별 대사’, 그리고 ‘전투 시 인연 대사’ 등은 이와 같은 비슷한 이유로 세상에 아직 나오지 못했다.
보스의 면도날이 진정 자르고 싶었던 건 무엇이었을까.
복잡함이었을까. 아니면 게임을 빛내게 만들어주는 섬세한 디테일이었을까.
템페스트 포스트모템 #5 – 이랬으면 어땠을까
stable에서 개발하지 않는 문화 정착
stable에서 개발하는 문화는 애초에 전제가 틀렸다.
아무리 한 스프린트 내 개발 스펙이 많아도 stable이라는 용어가 가진 의미를 져버려서는 안 된다.
개발에서 아무리 ‘중요한’ 스펙을 준비한다고 하더라도 예외는 없다.
그 ‘중요한’ 스펙을 무사히 서비스되기 위한 안정화는 기본 중의 기본이기 때문이다.
하지만 stable에서조차 신규 스펙을 넣고 수치를 바꾸는 일은 여기서는 ‘당연한 일’이었다.
도저히 일정이 나오지 않았다.
다른 회사였다면 어땠을까? 일단 2주 단위 스프린트를 업데이트 주기로 삼지 않았을 것이다.
대부분의 모바일 게임 개발사는 4주에서 6주, 그 이상의 시간을 두고 신규 픽업 업데이트를 진행한다. 이건 중국의 대형 게임사를 비롯한 큰 회사에서도 거의 예외가 없다.
매출에 훨씬 예민한 큰 회사들이 그렇게 긴 단위를 두고 개발하는 이유가 뭘까? 바로 매출과 콘텐츠 수명의 균형, 그 ‘항상성’을 보장되기 위해서는 최소 4주가 필요하다고 본 것이다.
창세기전 모바일은 2주 단위로 신규 캐릭터 및 콘텐츠 업데이트를 진행하려고 했다. 하지만 결과는 매 업데이트마다 불안정한 정기 점검과 버그 발생, 그리고 플레이어의 눈높이에 맞지 않는 업데이트로 부정동향을 야기했다. 그래서 결국 신규 스토리와 콘텐츠만이라도 4주 단위로 조정된 것으로 보인다.
처음부터 4주 단위로 신규 콘텐츠 업데이트를 하되, 2주 단위로 안정성 위주의 패치를 했다면 훨씬 안정적인 콘텐츠 업데이트가 가능했을 것이다.
하지만 첫 단추를 2주 단위로 캐릭터와 콘텐츠 업데이트를 내보낸 전적이 있는 프로젝트가, 4주 단위로 업데이트 주기를 바꾸는 날이 올지는…
앞으로 지켜볼 일이다.
반복 플레이의 재미 검증 시간 확보
게임을 만드는 이유가 뭘까?
게임사에서는 ‘매출을 낸다’는게 제1 목표이겠지만, 사실 그건 모든 회사의 기초적인 생리이기때문에 게임 회사만의 목표라고 보기에는 어렵다.
게임은 서비스다. 서비스는 고객을 대하는 ‘품질’로 경쟁한다.
게임의 품질은 곧 재미이며, 재미로 경쟁하는 힘이 바로 게임 회사의 경쟁력이다.
템페스트는 재미를 검증하는 과정 자체가 stable과 qa 단계에서 미흡했다.
이는 비단 템페스트뿐만 아니라, 대부분의 다른 콘텐츠 업데이트 시에도 마찬가지였다.
순수하게 플레이어의 입장에서, 어떤 부분에서 즐거움을 느끼고 어디에서 불편함을 느낄지에 관한 고민이 부족했다.
정확히는, 고민을 할 시간 자체를 확보할 수가 없었다.
템페스트의 반복 플레이가 주는 ‘고통’이 템페스트의 재미를 얼만큼 저하시킬지, 재미의 체감을 고민할 수 있는 여유가 있는 게임 디자이너는 아무도 없었다.
만약 그런 인사이트를 발굴해낼 수 있었다면, 매일 푸시 보상으로 템페스트 콘텐츠 입장권을 그렇게 지급하는 일은 없었을 것이다.
호요버스 게임은 숙제가 많기로 정평이 나 있지만, 사실 그 숙제도 대부분 ‘주간 단위 숙제’로 구성되어 있다. 매일매일 고정된 시간을 소비해야하는 반복 콘텐츠는 고작 10분이면 끝난다.
10분이 넘어가는 반복 플레이는 고통이다. 그러한 재미를 검증할 시간은 없다.
모든 결정은 리더가 아니라 보스를 통해 진행되기 때문이다.
보스가 아닌 리더. 모두가 평등하게 참여하는 의견 교환 개발
HBOs-Chernobyl 中
‘풀뿌리 민주주의’라는 말이 있다.
‘소수의 엘리트 계급이 절대다수의 민중을 지배하는 엘리트주의를 멀리하고, 평범한 민중이 자발적인 참여를 통해 공동체와 실생활을 변화시키는 참여형 민주주의’를 뜻한다.
템페스트의 개발은 ‘밀실 회의’에 있던 사람들을 제외한 모든 사람들이 동등한 입장이었다.
바로 ‘소방수’라는 사실이었다.
모두는 평등하게 ‘과제’를 부여받았고, 그것을 해결하기 위해서는 연차나 직책, 담당 직무와 상관없이 과제 해결을 위해 의견을 나누고 협업했다.
그 과정에서 시너지가 일어났고, 생각보다 빠른 시간 내에 템페스트가 만들어졌다.
업무상 충돌하거나 일부 개발 요소가 보스에 의해 제외되기도 했지만, 보스가 아닌 모두는 평등하게 과제 완수를 위해 힘을 뭉쳤다.
이 즐거운 개발에 참여하지 못한 건 오직 이 과정을 지켜볼 수밖에 없었던 ‘보스’ 뿐이었다.
일부 인원에게 집중적으로 추가 근무와 주말 업무가 뒤따랐지만, 템페스트는 생각보다 ‘덜 고통스럽게’ 개발되었다.
그리고 그 성과는 아래와 같이 드러났다.
템페스트 포스트모템 #6 – 출시 성과
템페스트 포스트모템 #6 – 긍정적인 피드백
템페스트 포스트모템 #6 – 부정적인 피드백
템페스트 포스트모템 #6 – 이랬으면 어땠을까
템페스트 포스트모템 #7 – 차후 과제와 총평
템페스트 포스트모템 #7 – 차후과제 요약
- 플레이 피로도(입장권 개수 조정 등) 개선
- 플레이 타임(플레이 주기) 개선
- 플레이 편의성 기능 추가(전투 스킵 등)
- 원작 BGM 추가
- 동기부여 요소 추가 (경쟁, 점수 도장깨기 등)
- 안정적인 서비스(버그 픽스, 순단 현상 해결)
- 그 외
템페스트에서 아쉬운점으로 지적된 대부분 요소는 ‘피로도’였으며, 게임 플레이 만족도 그 자체에서 불만을 느끼는 플레이어는 생각보다 많지 않았다.
템페스트 포스트모템 #7 – 총평
템페스트 포스트모템 요약
템페스트 포스트모템 총평
길고 긴 ‘템페스트 포스트모템’에 대한 기록은 여기까지다.
템페스트 콘텐츠에 대한 전반적인 호평에 힘입어, 다행히 템페스트는 지표상 좋은 성과를 냈다.
그 근간에는 ‘보스 중심’이 아닌 ‘풀뿌리 개발’을 주도한 실무자가 있었음을 간과해서는 안 된다.
- 만약, 보스가 ‘보스’가 아니라 ‘리더’였다면.
- 만약, 그들 스스로만 판단과 결정을 한 게 아니라 모두와 함께 고민했더라면.
- 만약, 모두가 한마음 한뜻으로 템페스트를 개발했더라면.
그러면 처음 구상했던 ‘완전한’ 템페스트 재현을 우리는 이뤄낼 수 있지 않았을까.
템페스트 개발은 아직 끝나지 않았다.
템페스트의 미래는 이제, 지금까지 템페스트를 캐리해 온 실무자가 아닌 ‘직책자’의 손에.
템페스트 콘텐츠를 진심으로 사랑하고 쓴소리를 마다하지 않는 진심어린 플레이어의 ‘조언’에 달려 있다.
