격리

시스템디자인 문서를 검토하다 보면 종종 핵심기능 이외에 혹시나 필요할지도 모를, 하지만 실제로는 현재 필요 여부를 예측하기 어려운 부가기능이 함께 정의되어 있을 때가 있습니다. 가령 NPC가 다이얼로그박스를 통해 말하게 만드는 기능이 있다고 합시다. 퍼시스턴트월드에 있는 NPC와 인터랙션하거나 퀘스트에 의해 NPC와 인터랙션하면 이 NPC가 상황에 따라 적당한 대사를 다이얼로그박스를 통해 말합니다. 다이얼로그박스에는 NPC의 포트레이트와 NPC이름, 대사 정도가 표시될 겁니다. 여기에 다이얼로그박스를 터치 앤 홀드하고 있으면 대사가 빨리 넘어가고 구석에 있는 스킵 버튼을 터치하면 대사를 끝내고 다음 동작으로 진행합니다. 이 기능은 근미래에 퀘스트에 의해 호출될 예정이고 당장은 퀘스트가 없는 상태이므로 퍼시스턴트월드에서 NPC와 인터랙션할 때 이 NPC에게 연결된 다이얼로그박스를 보여주는 선에서 기능을 구현해놓으면 확장하기에 무리가 없을 거라고 예상했습니다.

Open

이렇게 요청했던 기획서는 대사를 출력하며 동시에 지정된 음성파일을 재생하고 대사에 따라 NPC에게 애니메이션을 재생시키고 대사 중간에 퀘스트 보상을 지급하고 대사를 출력하는 도중에 NPC를 이동시키는 동작을 포함한 굉장한 물건으로 발전해 있었습니다. 이전에는 대략 목차 정도를 완성한 목차를 놓고 상담해 기능의 방향이 너무 틀어지지 않게 수정하곤 했습니다만 이번에는 신경을 쓰지 못했고 이 괴물같은 물건을 어떻게 해야 할지 고민에 빠졌습니다. 대사에 따라 음성파일을 재생하는 기능은 필요했습니다. 하지만 지금 당장은 어떤 사운드 솔루션을 사용할지 결정하지도 않았고 또 모바일플랫폼의 제약을 감안해 음성파일을 제공하지 않을 가능성도 있었습니다. 또 NPC가 대사를 하며 애니메이션을 재생하는 연출을 할 수도 있었지만 이 역시 결정을 예측하기 어려웠고 퀘스트 보상 지급은 종종 NPC와 대사를 하다 말고 보상을 지급하는 게임이 있기는 하지만 대사를 통해 제어될 대상이 아니었습니다.

일단 음성 기능과 NPC애니메이션과 이동을 포함한 연출기능, 퀘스트 보상 기능을 제거하고 텍스트 대사를 뿌리고 언리얼엔진의 기본기능을 사용한 제한적인 리치텍스트와 빨리감기, 스킵 정도를 남기고 나머지 요구사항을 모두 제거했습니다. 그나마 삭제한 코드를 주석처리하는 것 마냥 나중에 쓸 지도 모르기 때문에 텍스트를 옅은 회색으로 만들어 문서 구석에 남겨두려는 시도를 거절하고 현재 버전을 커밋하고 필요하지 않은 내용을 모두 삭제하게 했습니다. 이제 문서에는 대사를 표시하고 스킵하거나 빨리감는 기능 외에는 아무것도 남지 않았습니다. 이 기능은 퀘스트에 의해 사용되기 전까지 퍼시스턴트월드에 배치된 NPC를 터치하면 지정된 대사를 표시하는 수준으로 구현되어 얼마간 대기하게 될 겁니다.

당장 필요하지 않은 기능을 요구사항에 포함하지 않도록 강력하게 제한하는 이유는 우리가 숙련된 소프트웨어 설계자가 아니고 또 우리는 미래를 예측하는데 아주 서툴기 때문입니다. 먼저 게임 개발팀에서 시스템디자이너는 소프트웨어 요구사항을 정의하는 일종의 설계자 역할을 합니다. 내부 고객을 인터뷰해서 요구사항을 정리하고 개발을 진행합니다. 정의되지 않은 동작을 결정하고 시시각각 바뀌는 리퍼런스 게임의 비즈니스모델이나 최상위 의사결정권자의 요구사항을 수용할 수 있어야 합니다. 이런 요구사항 변경에 유연하게 대응하는 가장 기본적인 방법은 최소한의 기능만 정의하는 것입니다. 사실 모바일게임에서 요구하는 기능의 대부분은 고객 관점에서 그리 복잡하지 않습니다. 예를 든 대사 기능은 단순히 포트레이트와 텍스트를 표시하고 그 동안 플레이어캐릭터의 상태변화를 약간 제한하는 정도면 필요한 기능 대부분을 충족합니다. 여기서 미래를 예측하려고 시도하면 위에서 이야기한 음성, 연출, 보상 같은 눈에 보이는 기능을 엉뚱한 장소에 붙이려는 이상한 요구사항을 작성하게 됩니다.

종종 개발 리소스 사용 우선순위가 잘 돌아오지 않는 개발관리가 붕괴한 조직에서 오랫동안 일한 적이 있는 분들로부터 이런 성향이 강하게 나타나기도 합니다. 지금 당장 요구받은 핵심기능에 자신이 그동안 절실히 필요했던 핵심과는 거리가 있는 온갖 기능을 밀어넣어 이 기회를 최대한 활용해야겠다고 생각하는 겁니다. 당연히 엔지니어는 이 이상한 기능 집합에 의문을 가지고 구현 협상력이 약해지며 만약 이렇게 구현된다 하더라도 실제로 각각의 기능을 잘 사용하지 않고 유지보수를 어렵게 만듭니다. 이 상황을 해결할 방법은 붕괴된 개발관리체계를 회복하는 겁니다. 각각의 디자이너가 자신에게 필요한 기능을 최대한 밀어넣는 것이 아니고요.

이런 요령을 '격리'라고 말하고 있습니다. 요구사항에는 핵심기능만 간결하게 정의해서 엔지니어를 통해 개발을 진행시키고 위에서 이야기한 자신이 필요하다고 생각하는 추가기능과 미래를 예측한 결과에 따른 기능은 핵심기능과 격리해서 별도의 요구사항을 통해 전달해야 합니다.