때때로 의사 결정 시점은 빠를 수록 좋다

‘지금은 판단하기 어려우니 다음 달 말에 다시 한 번 모여서 판단하자' 게임을 만들어 오며 회의 중 이런 말을 여러 번 들어 왔습니다. 이 말을 하는 시점에는 보통 이렇게 말할 수밖에 없는 상황입니다. 보통 특정 기능의 마일스톤 기간 내 개발 가능 여부를 판단할 때 주로 발행하는데 일단 남은 기간에 비해 기능의 복잡도나 다른 기능에 대한 의존성이 높아 함부로 개발할 수 있다고 말할 수 없습니ㅏㄷ. 물론 이런 상황에서 정확한 답변을 종용하면 ‘안된다’는 답변을 들을 수 있기는 하지만 이 역시 답변을 들어야 하는 입장에서 원하는 답변은 아닙니다.

게임 소프트웨어 개발을 여러 번 반복해도 여전히 우리가 기간 내에 지불할 수 있는 비용에 맞춘 마일스톤 계획을 수립하기는 쉽지 않습니다. 비슷한 게임 소프트웨어를 개발하고 있지만 이번 프로젝트는 지난 프로젝트와 요구사항이 미묘하게 다르고 기반도 미묘하게 다르며 개발하는 사람들은 이전과 완전히 다릅니다. 때문에 초반에는 각자가 협업해 낼 수 있는 퍼포먼스를 잘 모르기 때문에 팀이 낼 수 있는 퍼포먼스에 맞춘 마일스톤 계획을 수립하기 어렵습니다. 팀의 퍼포먼스를 어느 정도 예측할 수 있게 되면 이번에는 이전과 다른 개발 기반 때문에 비용을 예측하기 어렵습니다. 새로운 기반에 익숙해진 팀의 퍼포먼스를 예측할 수 있게 되면 이번에는 이전과 비슷하지만 또 미묘하게 다른 요구사항 때문에 비용을 예측하기 어려워 집니다. 결국 소프트웨어 개발 주기 전체에 걸쳐 팀이 낼 수 있는 퍼포먼스에 맞춘 마일스톤 계획 수립은 거의, 항상 실패합니다.

이제 같은 팀이 프로젝트를 수행하며 의미 있는 빌드를 내기 시작한 지도 시간이 꽤 지났지만 여전히 마일스톤 목표에 포함된 요구사항의 개발 가능 여부를 미리 확정하기는 쉽지 않습니다. 이전 마일스톤에서 캐릭터는 무기 외에 스킬을 사용할 수 있었습니다. 미리 할당한 키를 누르면 수류탄을 던질 수 있었고 무기에 따라 모든 탄을 한 번에 뿌려 넓은 범위에 걸친 대미지를 주거나 근거리 무기를 들고 회전하며 주변에 대미지를 줄 수도 있었습니다. 만약 전통적인 개발팀이었다면 이런 스킬이 게임 상에서 개체들 끼리 동기화 되는 거의 모든 기능의 근본이라는 사실을 알고 이에 맞는 구현을 준비했을 겁니다. 전통적인 MMO 프로젝트에서 스킬은 사실 게임의 전부라고 해도 틀리지 않습니다. 근거리 무기로 몬스터를 평소와는 다른 애니메이션으로 강하게 공격하는 행동부터 포션을 사용하면 체력이 회복되는 동작에 이르기까지 게임 상에서 다른 사람들 사이에 동기화 되어야 하는 기능 거의 대부분이 스킬에 기반해 만들어집니다. 때문에 스킬 시스템은 항상 다양한 확장을 고려해 개발되고 이에 따라 개발 비용이 높습니다.

그런데 지난 마일스톤에 우리는 미래의 비용을 고려하는 대신 현재의 기능 구현에 집중한 나머지 게임 상에서 스킬을 사용할 수는 있었지만 이들이 미래의 확장에 대비한 형태로 개발되지는 않은 것 같습니다. 가령 이전까지 어떤 스킬은 무기에 기반해 만들어졌습니다. 원거리 무기를 들고 있을 때 상황에 따라 모든 탄을 한 번에 발사하는 스킬을 사용할 수 있었고 근거리 무기를 들고 있을 때 무기를 들고 빙빙 돌아 공격하는 스킬을 사용할 수 있었습니다. 이들과는 별개로 수류탄 처럼 현재 무기와 관계 없이 사용할 수 있는 스킬도 있었는데 이들 각각이 정규화된 스킬 시스템에 기반하는 대신 스킬에 따라 무기에 기반하거나 아직 존재하지 않던 아이템에 기반하는 등 정규화 되지 않은 형태로 개발되었습니다. 분명 이런 모양으로 개발하면서 지금 게임 상에서 사용할 수 있는 스킬은 이를 기반으로 계속해서 개발할 수 없으며 미래의 요구사항에 따라 상당 부분을 다시 개발해야 할 거라는 경고를 들었습니다.

하지만 이런 경고의 의미를 이해하는 사람은 소수이고 주로 직급이 높아질수록 의도적으로 이런 경고를 무시하는 경향이 있는 것 같습니다. 그렇다 보니 종종 최신 게임 엔진의 검증되지 않은 기능에 기반해 제한된 범위 안에서 멋진 모습을 보여주지만 실은 제한된 범위 바깥으로 한 발짝만 넘어가도 완전히 오동작하는 프로토타입을 본 경영진이 이 빌드를 완결된 버티컬 슬라이스라고 착각하고 프로덕션 계획을 수립하기를 종용하는 어처구니 없는 일이 일어납니다. 사실 직급이 올라갈 수록 이런 상태를 직관적으로 납득하기는 쉽지 않을 것 같기는 합니다. 분명 눈앞에서 구현되어 동작하는데 이 기반 위에 계속해서 개발할 수 없다는 말은 어떤 면에서는 너무나도 당연하지만 또 어떤 측면에서는 도무지 이해할 수 없을 겁니다.

이번에 추가하려는 요구사항은 이전에 무기에 의존성을 가지고 개발되었거나 그 시점까지는 아직 존재하지 않던 가상의 ‘아이템’에 의존성을 가지고 개발된 여러 스킬들이 이제 무기에 의존성을 가지지 않고 새로 추가될 ‘아이템’에 기반해 사용할 수 있어야 한다는 겁니다. 아직 아이템 개념이 없는 상태에서 아이템을 소모하는 수류탄 스킬을 만들었고 아직 아이템 개념이 없는 상태에서 탄환을 소모하는 스킬을 만들었으며 아직 무기를 장착하는 개념이 없는 상태에서 특정 무기에 의존성이 있는 스킬을 만들었기 때문에 스킬마다 정규화된 형태로 개발되지 않은 상태에서 이 스킬들 모두를 마치 정규화된 기반이 있는 것처럼 보고 이들이 기존의 무기 대신 아이템 소지 여부에 의존성을 가지도록 해 달라는 말은 요구사항 자체는 단순해 보이지만 실제로는 그렇지 않습니다. 이전에 급한 일정에 맞추기 위해 정규화 되지 않은 형태로 그럭저럭 동작하는 것처럼 보이게 만들었던 기반을 이제 정규화된 모양으로 미래에 확장 가능하게 만들려면 일단 요구사항을 만족하는 개발을 하기 이전에 미래에도 확장 가능한 기반부터 다시 만들어야 하는 상황입니다.

이런 상황에서 기존에 정규화 되지 않고 다양한 요소에 의존성을 가지도록 제각각 개발된 스킬을 정규화된 모양으로 아이템에 의존성을 가지게 만들어 달라는 말은 이 요구사항을 듣고 바로 마일스톤의 남은 기간 안에 개발 가능할지 여부를 바로 판단해서 말하기 아주 곤란하게 만듭니다. 이런 상황을 이해하기 때문에 지금 당장은 의사결정을 하기 어려우니 좀 더 개발을 진행해본 다음 일정 시간이 흐른 다음의 진척을 보고 의사 결정을 하자는 말에 수긍할 수밖에 없습니다. 하지만 의사결정을 미루자는 말에 수긍한다는 의미는 이 의사결정이 일어날 여러 가지 경우의 수를 고려해 마일스톤이 끝날 때 게임의 모양이 여러 가지로 바뀔 수 있고 이를 고려한 준비를 제각각 해야 한다는 의미이기도 합니다.

가령 스킬이 아이템에 기반해 동작하게 되면 여기 맞춘 인터페이스와 순환구조를 준비해야 합니다. 상점에서 수류탄을 팔고 수류탄 값을 마련하기 위해 필드에서 파밍을 하게 해야 합니다. 만약 스킬이 지금처럼 인게임의 다양한 요소에 기반해 동작한다면 순환구조에서 스킬을 제거해야만 하고 또 인터페이스에서 아이템을 장착하는 부분을 제거해야 하고 상점에서 수류탄을 팔지 않아야 하며 필드에서 파밍해 온 자원을 다른 목적으로 사용하도록 변경해야만 합니다.

어떤 책에서 의사결정 시점을 미룰 수 있으면 최대한 뒤로 미룰 수 있도록 제품을 설계하면 좋다는 내용을 읽은 적이 있습니다. 여기서는 프린터 회사의 전원코드 사례를 소개했는데 프린터를 제조할 때 이를 판매할 국가의 전원 형태에 맞춰 제조해야 했지만 제조를 시작할 때부터 이를 판매할 국가를 미리 결정하기는 쉽지 않았습니다. 그래서 프린터와 전원코드를 따로 만들어 이들을 나중에 결합할 수 있게 한 다음 프린터를 제조할 시점에는 이를 판매할 국가를 결정하지 않도록 했습니다. 프린터 생산이 끝난 다음 판매 국가가 확정되면 그때서야 판매 국가에 맞는 전원 코드를 조립한 다음 포장해 판매하면 되었고 의사 결정을 미리 하기 위한 비용을 사용할 필요가 없어집니다.

그런데 게임 소프트웨어 개발에서는 의사결정 시점을 뒤로 미룰 때 오히려 비용이 올라가기도 하는 것 같습니다. 가령 앞에서 소개한 스킬 시스템을 정규화 해 스킬이 아이템 소지 여부에 따라 사용 가능하도록 개발할지 말지 결정하기 위해서는 스킬 시스템을 확장 가능한 형태로 수정하고 이와 동시에 아이템 시스템이 같은 마일스톤 안에 개발되어야 하며 이 두 가지 기능이 비슷한 시점에 준비된 다음에야 스킬을 아이템에 기반해 사용 가능해지도록 개발할 수 있습니다. 의존성이 있는 하위 기능 두 가지의 개발 비용을 정확히 파악하기 어려운 상황에서 그 기능 두 가지 이상에 의존성이 있는 상위 기능의 개발을 미리 의사결정 하기는 어렵습니다. 하지만 이 의사결정을 뒤로 미루기 위해 의사결정의 결과에 따른 경우에 수에 따라 더 높은 비용을 들여 의사결정 결과에 바로 대응할 수 있는 준비를 해야만 합니다. 여기서는 서로 다른 장착 인터페이스, 서로 다른 순환구조를 준비해야 하고 게임 플레이에 영향을 준다면 이를 감안한 레벨 설계, 난이도 조절이 필요할 수도 있습니다.

사실 이런 의사 결정은 의사 결정 시점을 미래로 미룬다고 해서 결과가 달라지지는 않습니다. 의사 결정 시점을 미래로 미룰 현재에는 미래에 더 많은 정보에 기반해 의사결정을 할 수 있을 거라고 예상하지만 의사 결정 시점을 미뤘을 뿐 현재에서 미래 사이에 개발해야 할 사양은 증가할 뿐 결코 감소하지는 않기 때문입니다. 게임 소프트웨어의 요구사항은 개발 경과에 따라 꽤 큰 폭으로 바뀔 수 있으며 이 때마다 이에 연관된 요구사항은 모두 재정의 되어 개발 완료된 항목에서 개발 해야 할 항목으로 쉽게 바뀔 수 있습니다. 그래서 미래에 더 많은 정보에 기반해 의사 결정을 할 수 있으리라 생각했지만 그 시점에는 아직 의사 결정에 필요한 개발이 아직 완료되지 않았을 가능성이 있습니다. 때문에 의사 결정 시점을 미래로 미룬다 하더라도 결과가 달라지지 않을 가능성이 높습니다.

사실 이런 뻔한 미래를 알면서도 의사 결정을 하는 대신 의사 결정 시점을 미루는 이유는 이른 시점의 의사 결정에 대한 고위 직급자들의 곱지 않은 시선 때문이라고 생각하기도 합니다. 현재 상황, 우리들이 낼 수 있는 퍼포먼스, 예상할 수 있는 요구사항 변화 등을 고려할 때 이미 이 기능을 이번 마일스톤 안에 개발하기는 어려워 보이고 또 팀의 업무 공백을 최소화 할 만한 강력한 관리를 하지도 않는 상황에서 미리 기능을 개발하지 않기로 결정하면 이 직관적 결정을 고위 직급자들에게 납득 시키기 위한 또 다른 보고 준비를 해야 하는 상황에 쉽게 처하게 됩니다. 그래서 설득을 위한 보고 준비를 하기 보다는 차라리 의사 결정 시점을 미뤄 더 이상 비용을 지불할 수 없는 시점에 개발하지 않기로 결정하면 이른 시점에 같은 결정을 함으로써 생길 수 있는 보고 부담을 없애고 같은 결과를 얻을 수 있습니다. 그래서 뻔한 미래를 알면서도 의사 결정 시점을 미룹니다.

제조업에서는 의사 결정 시점을 가능한 뒤로 미루는데 의미가 있을 수 있지만 소프트웨어 개발에서는 의사 결정 시점을 가능한 앞으로 당겨 미래의 자원을 확보해야 장기적으로 개발에 비용을 더 사용할 수 있다고 생각합니다. 이번 마일스톤에 스킬 시스템을 정규화 하지 않기로 미리 결정하면 한 마일스톤 안에 서로 의존성이 있는 두 가지 기능을 동시에 개발해 통합하는 위험을 감수하지 않아도 되고 경우의 수에 따라 서로 다른 인터페이스와 서로 다른 순환구조와 서로 다른 게임플레이를 준비하거나 마일스톤 종료 시점에 가까워서야 그 동안 개발한 순환구조와 게임플레이를 뜯어 고치느라 초과노동에 의존하지 않을 수 있습니다.

프로젝트를 잘 관리하지 않을 작정이라면 현재 사용 가능한 정보와 이전의 경험에 기반한 직관적인 의사 결정을 신뢰해 이른 시점에 의사 결정을 해야 이 의사 결정의 영향을 받는 미래의 자원을 낭비하지 않고 개발할 수 있습니다. 종종 제조업에서는 의사 결정 시점을 최대한 뒤로 미룰 수 있도록 개발해 비용을 절약할 수 있지만 현재 진행 중인 소프트웨어 개발 프로젝트에서는 그렇지 않은 것 같아 보입니다. 현재까지 알려진 정보와 경험을 통한 직관적인 의사 결정을 신뢰할 수 있는 기반이 미래의 시간 낭비를 줄여 줍니다.