1차 완료는 완료인가요 아닌가요

전문 PM이 있지만 종종 개발팀에서 게임디자이너는 자신이 담당한 기능과 그 기능이 영향을 주는 주요 기능에 대한 마이크로 PM처럼 행동하기도 합니다. 종종 해외 개발 사례를 보면 엔지니어가 명세나 일정을 변경하려고 할 때 매니저와 대화하는 장면이 나오곤 하는데 여기서 매니저가 하는 역할의 일부를 게임디자이너가 수행합니다.

게임디자이너는 그 스스로 요구사항을 정리하고 이를 어느 정도 엔지니어와 주고받을 수 있는 수준의 명세로 정리하는 역할을 하는데 종종 전자는 좀 더 높은 수준의 디자인을 하는 사람으로부터, 후자는 좀 더 낮은 수준의 디자인을 하는 사람으로부터 나올 때도 있습니다. 종종 후자를 주로 수행하는 사람을 시스템 디자이너라고 구분해서 부르기도 합니다.

마일스톤에 수행할 규모가 큰 기능이 있으면 이 기능 전체를 목표로 개발을 시작하는 것은 불가능한데 가장 큰 이유는 우리들 각각이 살아 오며 쌓은 직관을 통해 한 번에 전체를 개발할 방법이 머릿속에 한 번에 떠오르지 않는 규모의 무언가를 한 번에 개발할 수 없다는 사실을 이미 알고 있기 때문입니다. 동시에 그런 시도를 했다가는 결코 임무를 완수할 수 없음을 알고 있고 이로부터 겁을 먹기 때문이기도 합니다. 너무 큰 목표를 제대로 된 맥락과 단계 별 계획 없이 한 번에 공유하면 이를 들은 사람들은 보통 둘 중 한 가지 반응을 하게 됩니다. 하나는 무슨 소리인지 전혀 알아 듣지 못하고 그냥 알겠다고 고개를 끄덕인 다음 자리에 돌아가 아무 것도 하지 않는 것, 다른 하나는 계획을 접수하기를 거부하고 이 계획이 실패할 수밖에 없는 원인을 늘어놓기 시작하는데 여기서 이 원인 각각을 부연 하기 시작하면 비 생산적인 기나긴 회의가 시작될 뿐입니다.

커다란 목표를 단위 기간 안에 실현 가능한 수준의 구체적인 목표로 구분하고 이를 작업 파이프라인으로 구성해 프로젝트 전체에 뿌리기 시작할 때 주의해야 할 점은 각 명세를 명확히 하는 것 이상으로 각 명세를 ‘완료되었다’고 판단할 구체적인 조건을 명시하는 것입니다. 종종 단위 기간 안에 실현 가능한 세부 목표를 설정할 때 결과를 구체적으로 언급하지 않으면 작업자는 작업을 완료했다고 생각하지만 전체적으로 볼 때는 작업이 완료되지 않은 이상한 상황에 처할 수 있습니다.

결과 혹은 목표를 완수했다고 판단할 구체적인 조건이 정의되지 않았을 때 자주 나타나는 말이 ‘1차 완료’와 같이 완료인지 아닌지 구분하기 모호한 표현입니다. 개인적으로 이런 ‘1차 완료’ 같은 표현을 무조건 피하려고 노력합니다. 가장 큰 이유는 이 표현은 그래서 이 작업이 완료된 것인지 완료되지 않은 것인지 판단할 수 없기 때문입니다.

아이템 아이콘 100 에셋 100개를 만들어 인게임에 반영하는 목표가 있다고 합시다. 아이콘을 만들 아이템 100개의 목록을 기반으로 누군가는 분명 아이콘 에셋을 만들 겁니다. 그런데 어떤 이유로 시간에 쫓기면 에셋을 만든 작업자 입장에서는 일단 수량을 채우기 위해 속도를 냈지만 개인이 판단하기에는 퀄리티가 충분히 마음에 들지 않을 수 있습니다. 이럴 때 수량을 채우기는 했지만 퀄리티가 썩 마음에 들지 않아 수정했으면 하는 마음을 담아 진행상황을 ‘1차 완료’했다고 보고하곤 합니다.

이제 개발을 진행 시켜야 하는 PM 입장에서는 이 말을 어떻게 해석하고 또 어떤 지시를 해야 할 지 결정해야만 합니다. 일단 위 사례에서 ‘1차 완료'라는 말의 정확한 의미는 목표 수량을 맞춰 에셋을 다음 사람에게 넘겨 아이템 데이터에 입력해 인게임에 아이템 아이콘이 나타나는 상태가 되긴 했는데 개인적으로 급하게 작업하느라 아이콘 각각의 퀄리티가 썩 마음에 들지는 않으니 시간을 내서 추가 작업을 해야 한다는 의미입니다. 이를 모르지 않습니다. 하지만 작업 전체를 보는 입장에서는 ‘1차 완료'라는 보고를 보고 둘 중 한 가지 결정을 내려야만 합니다.

첫째. ‘1차 완료’는 완료가 아닙니다. 아직 작업자가 아이콘 퀄리티를 마음에 드는 수준으로 조정하는데 시간이 필요하며 그 전까지 다음 작업자는 대기하거나 다른 작업으로 전환해야 하며 아이콘이 완성되는 시점에는 태스크 스위칭 비용이 발생하며 바로 이어서 아이콘을 적용하지 못할 수 있습니다. 둘째. ‘1차 완료’는 어쨌든 완료입니다. 작업자 개인의 마음에는 들지 않겠지만 여러 사람이 일하는 환경에 적응해 에셋을 제작할 때는 에셋 제작을 마치는 시점이 작업자 본인의 마음에 드는 에셋이 완성되는 시점이어야 합니다. 그 시점을 관리자와 사전에 협의해 적당한 기간을 사용해 ‘1차 완료’ 같은 모호한 상태를 만들어내지 않도록 했어야 합니다. 결국 ‘1차 완료'는 ‘완료’이며 바로 이어서 다음 사람에게 넘어가 인게임에 적용되고 이 아이콘을 다시 손 볼 기회는 미래에 있을 수도 있고 없을 수도 있지만 당장 이번 작업의 단위 기간 동안에는 확실히 없습니다.

이런 모호한 상황을 완전히 피할 수는 없다고 생각합니다. 가령 어떤 작업은 폭포수 모양으로 진행되지 않고 폭포수가 여러 차례에 걸쳐 반복될 때가 자주 있습니다. 가령 새로운 기능을 개발할 때 당장 엔지니어들이 시험 삼아 적용해 볼 에셋이 필요합니다. 그러면 당장 필요한 규모에 맞춰 더미 에셋을 찍어내 말 그대로의 ‘1차 완료’ 단계에 도달한 다음 바로 이어서 엔지니어들이 더미 에셋에 기반해 기능을 개발하고 그 사이에 다시 에셋을 제대로 제작해 ‘2차 완료’ 상태에 도달한 다음 엔지니어들이 개발한 기능과 합쳐 동작을 확인해야 할 수도 있습니다. 만약 이 단계에서 수정 사항이 생기면 엔지니어 직군과 아트 직군이 서로의 목표를 가지고 다시 떨어져 작업한 다음 아트 입장에서는 ‘3차 완료’ 상태에 도달해 다시 한 번 테스트를 반복해야 할 수 있고 이럴 때 쉽게 ‘3차 완료’ 같은 표현이 사용될 수 있습니다.

하지만 업무를 설계할 때 처음부터 여러 차례에 걸친 재시도 과정을 예상해 이를 미리 계획에 반영하고 ‘1차 완료’라는 표현이 처음부터 예정된 상태로 나오도록 할 수는 있습니다. 처음 설명한 ‘1차 완료’는 작업자 개인이 자신의 작업 결과에 충분한 자신을 가지지 못했기 때문에 완료도 아니고 미완료도 아닌 모호한 상태를 만들기 위해 사용한 표현이지만 여기서 ‘1차 완료’는 처음부터 더미 에셋을 제작해 엔지니어들이 여기에 기반해 개발을 시작할 수 있게 만드는 의도된 완료 상태를 말합니다. 이 때 ‘1차 안료’는 예정된, 그리고 확실한 완료 상태를 의미하며 모호하지 않습니다.

하지만 이는 이상론이고 실제로 미리 이렇게 작업을 설계하기는 어렵습니다. 그렇다면 최대한 단일 작업이 ‘1차 완료’와 같은 모호한 상태가 되지 않도록 누군가 예정되지 않은 상태에서 이런 표현을 사용할 때 상황을 파악해 ‘미완료' 또는 ‘완료’로 확실히 정의해야만 한다고 생각합니다.