마감 일정을 통한 학대 전략

지난 29호 뉴스레터 ‘10년의 밤’의 다른 다섯 가지 이야기 중 하나인 마일스톤 중간 점검. 제한시간 안에 서비스 할 수 있을까?에서 현재 진행 상황으로 미루어 어떻게 아슬아슬하게 서비스 목표 시점에는 맞출 수 있겠지만 이전 마일스톤과 마찬가지로, 또 이전에 경험한 여러 프로젝트의 마일스톤과 마찬가지로 그 끄트머리에 가서는 난장판이 될 것 같다는 예상을 한 적이 있습니다.

프로젝트들은 서로 다른 상황, 서로 다른 요구사항, 서로 다른 구성원 등 다른 요소가 많아 퍼포먼스를 쉽게 평가하기는 쉽지 않습니다. 하지만 여러 프로젝트에 참여하며 극 초반을 제외하면 직관적으로 마일스톤 목표를 어느 정도 달성할 수 있을지 감을 잡을 수 있기는 합니다. 가령 마일스톤 계획을 수립하는 단계에서는 확실하지 않았더라도 첫 1-2주가 지나 보면 마일스톤 목표 중 어떤 목표들은 무난하게 달성할 수 있을 것 같지만 다른 목표는 암만 생각해도 온전히 달성할 수 없을 것 같은 느낌이 드는 항목들이 있습니다.

원인은 여러 가지인데, 가장 먼저 요구사항으로 바꾸기 모호한 목표가 마일스톤 목표에 떡하니 들어 있을 때입니다. 물론 마일스톤 목표를 수입할 때 그런 몹쓸 아무 의미도 없는 목표가 마일스톤 목표에 들어가지 않도록 노력합니다. 가령 ‘전투 타격감 향상’ 같은 마일스톤 목표가 있어서는 안됩니다. 물론 이를 개선하기는 해야겠지만 이 말 자체는 요구사항으로 변경할 수 없기 때문에 마일스톤 목표로 이 말 그대로 들어가서는 안되며 좀 더 구체적인 말로 바꾼 다음 목표에 추가해야 합니다.

‘타격감이 부족한 원인 규명’은 만족스럽지는 않지만 그럭저럭 봐줄 만 한데 ‘타격감 향상’은 향상 전 상태와 향상 후 상태를 정의하기 극도로 어렵지만 원인을 규명하는 일이라면 일단 추측되는 원인의 목록과 이들 각각을 개선한 다음의 상태를 예상하는 결과를 낼 수 있기 때문입니다. 그리고 이 원인들이 규명되면 이들 각각을 개선하는 마일스톤 목표를 만들어 이들 각각을 수행할 요구사항을 정의할 수 있고 이들 각각을 수행하기 전과 후 상태를 정의해 평가할 수 있게 됩니다. 하지만 모호한 마일스톤 목표는 아주 조금만 신경 쓰지 않고 있어도 누군가에 의해, 정확히는 그런 모호한 목표를 집어넣는 행동에 뭐라고 할 수 없는 사람에 의해 아주 쉽게 마일스톤 목표에 들어가 여러 사람을 불행하게 만들 수 있습니다.

또 여러 기능에 의존성이 있는 기능이 나머지 의존성과 같은 마일스톤에 포함되어 있을 때 그렇습니다. 가령 마일스톤 목표에 ‘채집'이 있다고 해봅시다. 채집에는 아이템 개념이 필요하고 아이템에는 인벤토리 인터페이스가 필요하며 인벤토리는 다시 다양한 아이템에 따른 동작이 정의 되어야 하고 아이템을 획득하면 이를 유통 시킬 상점이나 제작 같은 보조 메커닉이 함께 동작할 때 비로소 채집이 의미 있게 동작할 수 있습니다.

이런 상황에서 마일스톤 목표를 그냥 ‘채집’이라고 해 버리면 필드에서 채집 하는 상호작용만 하면 된다는 소리인지 이를 통해 아이템을 먹으면 된다는 소리인지 아니면 그 아이템을 인벤토리에서 확인 가능한 데까지 만들면 된다는 소리인지 아니면 그 아이템을 상점에 팔아 골드를 먹을 수 있는 데까지 만들면 된다는 소리인지 아니면 그 아이템을 재료로 다른 아이템을 만들어 낼 수 있는 데까지 만들면 된다는 소리인지 파악하기 어렵습니다. 아마 높은 확률로 방금 이야기한 그 모든 것이 함께 동작하는 상태를 ‘채집 기능 개발이 완료된 상태’로 생각하고 집어 넣은 마일스톤 목표일 가능성이 높은데 이렇게 다른 아직 개발되지 않은 나머지 기능에 의존성이 있는 기능을 그 나머지 기능들과 같은 마일스톤에 개발하는 것을 목표로 하고 있다면 이 역시 직관적으로 달성할 수 없으리라는 느낌을 받습니다.

또 목표의 개발 일정이 마일스톤 후반에 위치하지만 기능이 개발된 시점에 다시 기획팀으로 돌아와 데이터를 입력하고 게임처럼 보이게 만드는 소위 ‘조립’ 시간이 별로 고려되지 않았으면서도 개발 자체는 아주 복잡하지 않지만 조립에 시간이 많이 필요한 항목이라면 이 역시 달성하지 못할 가능성이 높습니다. 가령 게임 전체에 걸쳐 새로 들어간 몬스터들의 전투 시간과 난이도, 이들 각각으로부터 나올 보상, 단위 보상을 획득하는데 걸리는 시간, 보상을 재화로 교환해 줄 비율, 제작을 통해 게임 내 더 강한 무기를 획득하는데 걸리는 시간 따위를 통틀어 ‘게임 밸런스 조정’이라는 목표로 만들어 놓았다면 아주 높은 확률로 이번 마일스톤에 이 목표는 달성하지 못할 가능성이 높습니다.

일단 목표 이름 자체가 정확히 뭘 하면 되는지 요구사항으로 바꾸기 아주 어렵습니다. 어떻게든 그 동안 해 온 통밥을 통해 요구사항으로 바꿀 수 있다 하더라도 이 작업은 이 작업이 영향을 줄 여러 나머지 기능들의 개발이 완료된 후에 시작할 수 있습니다. 가령 몬스터와 전투 시간은 몬스터 조립이 끝난 다음 전투를 해 보며 정해야 합니다. 이들로부터 얻는 보상과 단위 보상을 획득하는데 걸리는 시간은 엑셀 테이블을 통해 계산할 수 있겠지만 엑셀 수식 상에 나타나지 않는 외부 요소의 개입으로 인해 예상과 실제 결과는 서로 상당히 다를 겁니다. 밸런스는 근본적으로 이들 사이의 차이를 극복하고 고객에게 적당한 경험을 제공하면서도 고객들의 성장 속도와 재화 누적 속도가 오차 범위 안에서 동작하게 만드는 일종의 외줄타기입니다. 그런데 애초에 탈 외줄이 개발되지 않는 이상 이 모든 작업을 시작조차 할 수 없습니다.

재미있게도 지금까지 여러 보스를 모셔 오면서 마일스톤을 시작할 때 달성에 어려움을 겪을 가능성이 있는 항목을 지목하며 이들의 순서를 바꾸거나 다음 마일스톤으로 미루거나 다음 마일스톤 목표를 당기거나 달성 수준을 하향하자는 등의 요청을 하면 거의 받아들여지지 않곤 했습니다. 가장 자주 들은 핀잔은 아직 해보지도 않았는데 벌써 목표를 하향 하려고 하면 프로젝트 팀이 충분히 열심히 일하지 않을 수 있다는 것입니다. 사실 이 말은 어느 정도는 맞는 말이었는데 팀의 예상 퍼포먼스와 마일스톤 기간 중 연휴의 존재 여부, 각 기능의 예상 개발 난이도 따위를 고려해 마일스톤 계획을 살짝 느슨하게 만들어 놓으면 종종 팀 전체의 활력이 떨어지는 경험을 한 적이 있습니다. 반면 도전적이라고 쓰고 무모하다고 읽는 수준의 마일스톤 계획을 수립하면 그렇지 않았을 때에 비해 상대적으로 팀에 활력이 유지되곤 했습니다. 이런 경험에 기반해 실제 달성 가능할 거라고 예상하는 마일스톤 목표와 프로젝트 팀에 요구하는 마일스톤 목표는 비공식적으로 상당한 차이가 있을 때가 있었습니다. 이런 이유로 무모한 계획을 살펴보고 이 중 아래쪽 세 개는 아마 달성 못 할 거라고 미리 이야기하면 벌써 부터 그렇게 이야기하면 안 된다는 핀잔을 들었습니다.

그렇다면 그 무모한 마일스톤 목표를 그대로 수행하려고 시도해야 한다는 말일까요? 사실 반 쯤은 그렇고 또 반 쯤은 그렇지 않습니다. 사실 팀에 마일스톤 목표를 할당할 때 이미 할당하는 사람도, 할당 받는 사람도 이 목표가 이번 마일스톤 안에 완수하기에 아슬아슬한 분량이라는 사실을 어느 정도 알고 있습니다. 그럼에도 이 목표를 거절하지 않는 이유는 목표를 부여하는 사람 역시 이 목표가 무리이며 달성한다면 좋겠지만 달성하지 못한다 하더라도 직접적인 책임을 묻지는 않으리라는 사실을 알고 있기 때문입니다. 이런 서로 간의 묵시적인 동의에 따라 명백히 팀 퍼포먼스에 비해, 그리고 각 기능의 개발 진행 순서에 따라 위험한 일을 포함한 마일스톤 목표가 실행되기 시작합니다. 일단 표면적으로는 그 무모한 마일스톤 목표를 수행하려고 시도합니다. 하지만 목표가 더 많다고 해서 이전보다 더 많은 초과근무를 통해 더 서두르거나 하지는 않습니다. 물론 초과근무를 통해 노력하고 있다는 신호를 보내기는 하겠지만 그런 행동이 목표 달성과 직접 연결되지는 않습니다.

개발팀은 마일스톤 내내 끝나지 않고 몰아치는 목표를 달성하느라 계속해서 바쁜 상태를 유지합니다. 하지만 위에서 설명한 여러 이유에 의해 마일스톤 막바지가 되면 사실상 달성할 수 없음이 확정된 목표들이 나타나고 이를 더이상 핀잔으로는 막을 수 없으며 인정할 수밖에 없는 시점이 옵니다. 그러면 못 이기는 척 이번 마일스톤은 너무 바빠서 어쩔 수 없으니 특정 기능은 다음 마일스톤에 이어서 개발하기로 계획을 변경합니다. 이 계획 변경은 사실 어느 팀이나 기뻐할 만한 일인데 엔지니어 입장에서는 다음 마일스톤에 기획서 도출을 기다리지 않고 이어서 개발을 진행할 수 있으니 좋고 또 게임디자인 입장에서는 마일스톤 초반에 요구사항을 찍어내는 사이에도 엔지니어 부서가 공회전 하지 않을 수 있으니 좋습니다. 하지만 항상 마일스톤 끝에 가서 이런 의사결정을 반복하면 팀의 실제 퍼포먼스를 결코 파악할 수 없게 되고 또 목표 달성 실패에 대한 책임을 물을 수 없게 되기 때문에 목표 달성에 실패하더라도 원인을 파악하거나 같은 문제가 다시 일어나지 않도록 할 기회가 사라집니다. 처음부터 무모한 목표였고 이를 달성하지 못했다고 해서 처벌 받는 사람은 없으며 항상 이런 상태가 계속되기 때문에 비록 팀의 활력이 떨어지는 모습을 보이지는 않겠지만 의도하든 의도하지 않았든 개개인의 책임감은 떨어지는 결과로 이어집니다.

그런데 이런 연습을 계속해 온 팀이 서비스 직전 마일스톤처럼 더 이상 물러날 수 없는 시점이 되었을 때 여전히 이번 마일스톤 목표 역시 무모하지만 이번에는 다음 마일스톤으로 목표를 미룰 수 없게 되더라도 항상 하던 것처럼 목표를 뒤로 미루려고 시도할 가능성이 높기 때문에 도전적인 목표 설정을 통해 팀에 일시적인 활력을 불어넣을 수 없게 됩니다. 지금까지 상당 기간에 걸쳐 어차피 달성할 수 없는 목표를 달성하지 못했다고 해서 처벌 받지 않고 또 달성할 수 없는 목표가 설정되더라도 딱히 신경 쓸 필요가 없었습니다. 그저 끝없이 이어지는 작업을 계속하다가 날짜에 맞출 수 없으면 목표 달성에 조용히 실패하고 다음 마일스톤에 이어 진행하면 그만이었습니다. 그래서 더 이상 미룰 수 없을 때 팀에 그런 신호를 보내 활력을 만들어내기 어렵거나 거의 불가능해집니다.

그렇다고 해서 방법이 아예 없는 것은 아닙니다. 물리적으로 정해진 날짜까지 개발을 마칠 수 없다면 그 정해진 날짜를 미루면 되기 때문입니다. 가령 12월 1일까지 개발을 마치기로 했는데 현재 상태로 미루어 그 날짜를 절대로 맞출 수 없다고 해 봅시다. 이미 그 사실을 알고 있어 이미 고위 의사결정자들과 협의를 거쳐 개발 완료 시점을 2주 연장한 상태입니다. 사실 이런 협의는 개발 과정에서는 고위 의사결정자, 그리고 경영진 수준까지만 도달하면 되니 엄청나게 복잡하지는 않지만 만약 런칭을 앞두고 있다면 퍼블리셔, 이들이 계약한 여러 다른 회사들의 일정과 맞물려 상당히 어려워질 수 있습니다. 하지만 어떻게든 싹싹 빌어 마감을 2주 연장하는데 성공합니다. 그런데 여기서 중요한 점은 이 마감 연장 사실을 프로젝트 팀에 공유하지 않는 것입니다.

마감일인 12월 1일이 포함된 주 화요일 즈음 이미 마감 연장 협의가 이루어졌지만 이 사실을 팀에 전달하지 않고 팀은 계속해서 이번 주 금요일이 마감이라고 생각하고 행동하게 놔 둡니다. 그러면 사실상 불가능할 거라는 사실을 모두가 생각하지만 입 밖으로는 내지 않으며 어떻게든 일정을 맞춰 보려고 발버둥 치게 됩니다. 하지만 결국 마감 날에도 여전히 개발이 완료되지 않았음을 인정할 수밖에 없습니다. 그런데 이 때 이미 협의한 일정 연장 카드를 아주 조금씩 꺼내 사용할 수 있습니다. 가령 이번 주 금요일이 마감이었지만 어려운 협의를 통해 마감을 그 다음 주 월요일로 옮기고 주말 동안 개발을 계속하게 만들 수 있습니다. 만약 월요일에도 개발이 완료되지 않을 것 같으면 그 주 수요일, 그 주 금요일 같은 식으로 조금씩 ‘어려운 협의’를 통해 일정을 연장하는 제스처를 취해 팀을 계속해서 코 앞에 닥친 마감 앞에 정신 없이 일하는 상태를 유지하도록 합니다. 처음에 이미 말해버렸지만 실제 협의 한 일정은 그 다음 주 금요일 까지입니다. 이 안에서는 일정 연장 카드를 얼마든지 사용할 수 있습니다.

이 방법이 더 이상 물러날 수 없는 상황에서 팀에 최대한의 부하를 걸어 개발을 계속해 성공 가능성을 높이는 방법 중 하나라는 사실을 부정하지 않겠습니다. 실은 여러 프로젝트에서 이런 방법을 사용해 왔고 나름 성공한 사례도 여럿 있습니다. 다만 런칭 같은 더 이상 물러설 수 없는 상황이 아닌 개발 마일스톤 도중에도 이런 방법을 사용할 때가 있는데 개인적으로 이를 ‘실패하는 연습’이라고 부르며 썩 달가워 하지 않습니다. 위에 설명한 대로 이 실패하는 연습을 통해 팀은 개발 실패에 따른 책임을 회피하는 습관을 들이며 목표 달성에 실패하는 상황에도 별다른 경각심을 가지지 않게 될 수 있습니다. 하지만 개인적으로는 이런 이미 협의 된 적절한 일정을 팀에 사실대로 공유하는 대신 이 일정을 조금씩 사용하며 계속해서 팀을 절박한 상태로 모는 행동을 일종의 학대라고 생각합니다. 정확히는 제목과 같이 ‘마감 일정을 통한 학대’라고 봅니다.

이런 방법을 통해 분명 목표를 달성할 수 있을 겁니다. 지금까지 여러 프로젝트에서 이렇게 해 왔고 아예 시간 단위로 일정을 미루는 사례도 있었습니다. 그렇게 개발을 마쳐 런칭을 하고 서비스를 하고 업데이트를 하며 개발을 계속하곤 해 왔습니다. 하지만 장기적으로 팀은 이런 상황을 계속해서 겪으며 지치고 개개인은 망가져 이전과 같은 퍼포먼스를 기대하기 어려워집니다. 계속해서 이런 방식을 사용할 때 종종 ‘팀을 녹여 개발한다’고 표현하곤 하는데 실제로 개발된 빌드를 얻을 수는 있겠지만 그 댓가로 팀이 녹아 온전한 퍼포먼스를 내지 못하게 되며 결국 인원이 이탈하고 새로운 인원으로 채우면서 상당한 퍼포먼스 저하를 겪게 됩니다.

그런데 어떤 팀에서는 이런 상태를 기본으로 운영하기도 하는데 인사 부서가 이를 뒷받침할 수 있다면 계속해서 일정을 통해 팀을 학대하며 녹아버린 인원을 새로 채워 가며 개발을 계속해 런칭하기도 합니다. 분명 런칭에 성공했고 또 일정 수준의 경제적 성과도 이뤘지만 런칭 시점에 이를 경험하는 사람들은 맨 처음 프로젝트를 시작한 사람들과 완전히 다른 사람들입니다. 전설적인 케이스로는 프로젝트에 따라서는 전체 인원이 세 번 정도 바뀐 다음에야 런칭을 겪기도 합니다. 이쯤 되면 이를 올바른 개발 방법 중 하나로 생각해도 괜찮을지 잘 모르겠습니다.

여전히 이런 방법이 개발팀을 운용하는 방법 중 하나이며 여러 사례를 통해 검증 되었음을 부정하지 않겠습니다. 다만 이렇게 팀을 녹여 가며 진행하는 개발과 달성 가능한 목표를 통한 ‘성공하는 연습’을 하며 개발한 결과 사이에 유의미한 차이가 있지 않을까 하는 상상을 해 보곤 합니다. 같은 개발팀 구성원들의 뇌를 반으로 갈라 각각의 운영 기법을 실험해 그 결과를 비교할 수는 없습니다. 굳이 그런 학대에 가까운 운영을 하지 않고 처음에 개발을 시작한 사람들을 녹이지 않고 최대한 남겨 런칭을 경험하더라도 그 일정이 팀을 녹인 결과에 비해 너무 늦거나 팀을 녹인 결과에 비해 품질이 떨어지지 않을 수도 있지 않을까 하는 상상을 해 봅니다. 또 그렇게 녹지 않고 전체 개발을 경험한 인력이 이탈하지 않고 회사에 남아 라이브를 경험하고 나아가 다음 프로젝트를 시작한다면 팀을 녹여 만들어낸 결과와 비교해 장기적으로 회사에 이익이지 않을까 하는 상상도 해 봅니다. 하지만 팀을 녹이는 기법은 검증되었지만 이런 상상은 검증될 수 없습니다.

오직 제 머릿속으로 하는 생각에 한해 팀에 솔직하게 정보를 전달하고 이에 기반해 각자가 적당한 책임감과 적당한 긴장감을 가지고 움직이게 하는 것이 이상적이라고 생각합니다. 물론 그 결과로 앞에서 잠깐 언급한 팀에 활력이 떨어지는 소위 ‘널럴하게 개발하는’ 상태가 될 수도 있습니다. 그런데 그런 ‘널럴하게 개발하는’ 상태가 나쁜가 하면 꼭 그렇지는 않다고 생각합니다. 표현에 따라서는 ‘지속 가능한 개발’을 하고 있다고 볼 수도 있지 않을까요? 또한 그런 상태에 기반해 프리라이딩을 일삼는 스탭이 있다면 이를 막기 위해 팀 전체를 학대하기 보다는 그 스탭을 관리하거나 제거하는 편이 더 나은 방법 아닐까요?

검증된 적 없고 검증할 수도 없는 방법을 항상 생각만 해 보고 있습니다. 반면 마감 일정을 통한 학대 전략은 여러 번 검증된 바 있습니다.