시스템기획서에 데이터구조를 제안할 때 여러 안을 준비해야 할까?

지금까지 팀이 이룩해 온 업적을 따라잡기 시작한 지 시간이 제법 지났습니다. 처음에는 문서를 읽고 빌드를 만져보기를 반복하며 여러 가지 정보를 얻었고 그러는 사이에 빌드를 망가뜨리기도 했습니다. 시간이 조금 더 지나고 제가 기여할 수 있을 것 같은 부분을 찾아 제 방식대로 일을 하기 시작했습니다. 이 때 걱정한 점은 지금까지 팀에서 일을 시작해 진행해 온 방식과 제가 일을 시작해 진행하는 방식 사이에 차이가 있어 서로 충돌하거나 제가 엉뚱한 방법으로 일을 해 그 결과를 보는 사람들이 ‘뭐임???’ 같은 반응을 하게 만드는 것입니다. 그런 사례가 없지는 않았지만 그럭저럭 저에게 편한 방법으로 일하기 시작했지만 아직 까지는 누군가의 심기를 크게 거스르고 있지는 않은 것 같습니다.

제멋대로 일하는 방법 중 하나에는 회의록 페이지를 아무 데나 만드는 것이 있습니다. 가령 지난 여러 팀에서 회의록을 만드는 경로가 약속 되어 있는 경우가 거의 대부분이었습니다. 컨플루언스 어딘가의 페이지 트리에 회의록을 만들기로 미리 약속 되어 있고 회의에 참여한 누군가가 잊지 않는 한 그 아래 회의록이 만들어집니다. 종종 회의록에는 날짜와 주제 뿐 아니라 그 회의에 누가 참석했는지 기입하도록 강제할 때도 있었는데 종종 팀에 처음 오셔서 아직 사람들 이름을 기억하지 못하는 분이 회의록을 기록하시거나 너무 많은 사람들이 들어와 사실상 회의로써 의미를 상실한 회의의 회의록을 작성해야 할 때 어려움을 겪기도 합니다. 한동안은 저 역시 그런 규칙을 잘 지켰지만 어느 날 곰곰이 생각해보니 마일스톤 목표 하나하나를 수행해 가면서 나오는 여러 회의록은 회의록 무더기에 함께 섞여 있기에는 그 속성과 용도가 상당히 다르다는 생각을 했습니다. 마일스톤 단위의 아주 크지 않은 목표를 달성하기 위해 협업 부서와 나눈 자잘한 이야기, 단순한 결정 따위를 모두 회의록으로 만들어 공유하곤 했는데 이런 회의록은 거창하게 프로젝트 전체의 회의록이 쌓여 있는 무더기에 이들을 추가하기 보다는 자잘한 회의록은 이 회의록이 영향을 주는 문서 하위에 놔 두는 편이 개발해 나가면서 회의록을 더 빨리 찾을 수 있었고 또 개발에 필요한 문서와 페이지 트리 상에서 가까운 위치에서 회의록을 찾을 수 있어 더 좋았습니다.

그래서 어떤 기획서에 기반해 개발하고 그 과정에 일어나는 여러 의사결정을 기록한 회의록은 회의록 트리를 무시하고 기획서 하위에 기록하기 시작했는데 한동안은 제가 엉뚱한 페이지 트리에 회의록을 만들고 있다는 사실 자체를 이 일에 참여한 사람들 외에는 아무도 몰랐지만 어느 날 개발 관리 조직에서 이를 눈치 채 저에게 문의를 해 옵니다. 회의록 만들기로 약속한 페이지 트리가 있는데 우진님은 왜 거기다 회의록을 안 만들고 엉뚱한 곳에 만드냐는 겁니다. 언젠가, 그리고 누군가로부터 그런 문의 또는 항의가 올 거라는 사실을 예상하고 있었기에 미리 준비한 것처럼, 사실 미리 준비해 놓은 대답을 하기 시작합니다. 프로젝트 전체, 또는 팀 전체, 또는 마일스톤 하나 수준에 영향을 끼치는 큰 결정이 일어나는 회의의 회의록은 당연히 프로젝트 수준에서 지정한 페이지 트리에 위치하는 것이 올바르겠지만 마일스톤 하나 하위의 특정 기능을 개발할 때 일어나는 작은 의사결정을 담은 회의록은 이 회의록이 영향을 주는 문서와 가까이 있을 때 찾기도 쉽고 인지하기도 쉬울 뿐 아니라 다른 수많은 회의록에 뒤섞이지 않아 좋다고 생각하기 때문입니다. 물론 개발 관리 업무를 하는 입장에서는 페이지 트리 한 곳에서 프로젝트 전체로부터 생산되는 모든 회의록을 편안하게 읽어보고 싶을 것이 분명하지만 그렇다고 개발 관리 부서가 프로젝트의 모든 의사결정을 기록한 자잘한 회의록에 이르기까지 맥락과 내용을 파악해 도움을 줄 수 있지도 않습니다. 결국 개발 관리 부서의 팀원님은 저를 설득하지 못했고 그 뒤에도 저는 제 멋대로 회의록에 따라 어떤 건 프로젝트 회의록 페이지 트리에, 또 어떤 회의록은 개발 관리 부서 관점에서 볼 때 아무 데나 작성합니다.

지난 새로운 방식에 적응하기에서 회사가 작지는 않은 돈을 지불하며 저를 고용한 이유를 짐작해 보았습니다. 제가 속한 팀은 어쩌다 보니 다른 팀에 비해 주니어님들 위주로 구성되어 있습니다. 사실 이 자체가 문제를 일으키지 않지만 종종 주니어님들 위주로 구성된 팀이 팀 외부와 협업 하려고 할 때 종종 문제가 일어나기도 합니다. 외부에서 볼 때 우리들이 뭔가 부족해 보이는 뻔한 실수가 포함된 요구사항을 제안하거나 기술적으로 문제가 있을 것이 분명한 제안을 할 수도 있습니다. 하지만 이런 실수는 팀 안에서 필터링 되기 쉽지 않으며 만약 이런 실수 하나하나를 팀에서 필터링 하려고 하면 기술적으로 전문가가 아닌 사람이 요구사항의 기술적인 측면을 검토하는 이상한 일이 일어나기 쉽습니다. 어떤 팀에서는 종종 기획팀 안에서 생산된 문서를 기획팀 내에서 검토하는 단계에서도 이 요구사항을 구현하기 위한 하드 코딩 여부를 걱정하며 요구사항을 반려하기도 하는데 이는 절대로 바람직한 상황이 아닙니다. 개인적으로는 주니어님들의 문서가 그 요구사항이 게임에 포함된 결과가 올바르다면 그 방식의 문제에도 불구하고 일단 팀 밖으로 나가 협업 부서의 도움을 빌어 문제를 해결해 가며 개발을 진행하는 편을 더 선호합니다. 물론 업무를 진행해 나가는 개개인 입장에서는 아주 조금 더 괴로울 수 있지만 서로가 서로를 통해 실수를 배울 수 있고 이 과정에서 서로의 업무 스타일을 더 잘 알게 됩니다. 적어도 저는 그렇게 생각하고 행동합니다.

하지만 어떤 조직에서는 그런 주니어님들의 시도가 협업 부서의 강한 부정적 반응에 의해 문제를 겪기도 한다는 사실을 알고 있습니다. 주니어님들 수준에서 이해하기 쉽지 않은 언어들을 동원해 이유를 설명하고 작업 진행을 거부하지만 이미 그들 스스로도 자신의 문제 제기를 주니어님이 확실히 이해했을 가능성이 그리 높지 않음을 이미 예상하고 있을 때가 있습니다. 개인적으로 이는 사일로 현상의 일부라고 생각하는데 협업 과정이 매끄럽지 않다고 해서 그저 작업을 거부해 버리면 이는 함께 일할 자세가 안 된 거라고 생각합니다. 이전에는 이런 상황을 겪으면 공격적으로 반응하곤 했습니다. 함께 같은 목표를 바라보고 일하는 프로젝트 구성원들이 부서를 초월해 협력하고 서로의 부족한 점을 보완해 주지 않으면 목표를 달성할 수 없다고 봤기 때문입니다. 이는 어떤 때는 받아들여졌지만 다른 때는 받아들여지지 않았고 종종 목표를 달성하기 위해 소위 미친개처럼 행동해야 했고 목표를 달성하긴 했지만 저 자신을 포함한 여러 사람들에게 상처를 남기는 결과를 초래하기도 했습니다. 이제는 그럴 체력도 없거니와 굳이 그럴 것 없이 협업이 원활하지 않을 때 우리가 할 수 있는 업무 범위 안에서 최대한 문제를 미리 해결하는 식으로 접근하고 있습니다.

가령 주니어님들은 보통 시야가 좁아 자기 자신의 목표에만 집중해 자신이 제안한 방식대로 개발이 진행되면 다른 기능과 충돌할 가능성이 있더라도 이를 미리 눈치 채지 못할 때가 많습니다. 또 비슷한 요구사항이 이전에 약간 다른 방식으로 만들어졌지만 이 사실이 프로젝트 전체에 널리 알려져 있지 않아 이미 있는 기능에 대한 요구사항이 중복해서 작성되기도 하고 또 이전에 다른 부서의 요청에 의해 개발된 기능과 상호 배타적인 요구사항을 작성하기도 합니다. 이는 경험이 쌓이며 시야가 서서히 넓어져 지금 나 자신이 하는 일 바깥에서 무슨 일이 일어나고 있는지, 또 이 모든 일이 쌓여 마일스톤이 끝날 때 빌드가 어떤 모습이 될 지, 나아가 이 모든 개발이 마무리될 때 고객들에게 공개될 빌드는 어떤 모습일지 등을 생각하기 시작하면 자연스럽게 문제가 줄어들고 훨씬 부드럽게 일할 수 있게 됩니다. 물론 그런 단계 전까지는 어느 정도 시행착오가 일어날 수밖에 없는데 만약 우리들이 아주 작은 회사에서 제한된 자원 만으로 개발해야 하는 상황이라면 이런 시행 착오를 겪지 않도록 철저히 통제해야 할 테고 그러려면 훨씬 더 경험 많은 사람들로 팀을 구성해야 합니다. 반대로 우리들이 주니어님들을 포함하고 어느 정도 여유가 있는 조직이라면 이분들께 직접적인 교육을 제공하지 못할지라도 이분들이 시행착오를 통해 성장할 기회를 제공해야 한다고 생각합니다.

한편 어느 날 같은 팀원님으로부터 한 가지 질문을 받았는데 질문을 받고 대답한 다음 생각해보니 이 상황에 대한 제 생각을 기록해 공유하면 좋을 것 같다는 생각을 했습니다. 지금까지 주니어님들이 더 많은 게임디자인 부서가 협업 부서와 개발을 진행할 때 겪을 수 있는 어려움과 이 과정에서 주니어님들이 성장해 나가는 과정에 대한 제 생각을 소개했는데 이 이야기의 일부일 것 같습니다. 제가 받은 질문은 지금 작성하는 시스템 기획서에 데이터구조를 제안하려고 하는데 이 제안이 거절될 경우에 대비해 데이터구조 제안을 여러 개 만들어 1안, 2안을 함께 제안해 그 중 더 바람직한 것을 선택하게 만들어 제안이 거절되어 업무가 기획 단계로 되돌아오지 않도록 하려는데 이 상황에서 두 가지 이상의 데이터구조 제안을 어떻게 만들어야 할 지 모르겠다는 것입니다. 지금까지 자리에 앉아 제 주변에서 일어나는 여러 가지 대화, 그 동안 생성된 여러 가지 문서, 사람들이 일하는 방식 따위를 눈은 모니터를 바라보고 있지만 귀는 사방을 향해 열어 놓고 상황을 파악한 바에 따르면 프로젝트 전체에 일정 수준 이상의 사일로 현상이 있어 보였습니다. 일하다 보면 사일로 현상이 종종 일어나 이 자체를 문제로 지목하기는 쉽지 않지만 일단 상황이 이렇게 흘러가면 항상 일을 처음 시작하는 게임디자인 조직은 업무에 큰 어려움을 겪기 마련입니다. 팀에 사일로 현상이 얼마나 일어나고 있는지 판단하는 쉬운 방법은 게임디자이너들이 마일스톤 단위의 한 가지 기능을 개발 시키기 위해 이름은 조금씩 다르지만 소위 ‘발주서’에 가까운 문서를 얼마나 많이 작성하고 있는지 살펴보면 됩니다.

분명 마일스톤의 여러 목표 중 하나인 요구사항을 개발하기 위해 게임디자인에서 문서를 생산하고 이를 바탕으로 담당자들을 모아 브리핑 하는 과정을 거쳤을 겁니다. 이 때 각 담당자들은 브리핑 하는 동안 어두운 방 안에서 멍하니 앉아 있으려고 회의실에 들어간 것이 아닙니다. 이 개발을 마일스톤 안에 진행 시켜 결과를 내기 위해 자신이 어떤 일을 해야 하는지 파악하기 위해 회의실에 앉아 있습니다. 그런데 회의가 끝나고 나면 마치 회의에 참여한 적이 없는 것처럼 지금부터 이 업무에 필요한 작업을 게임디자인이나 다른 누군가로부터 업무 범위가 완전히 명시된 소위 ‘발주서’에 기반해 업무를 수행한다면 애초에 목표를 브리핑 하는 회의는 존재할 필요가 없습니다. 어차피 발주서 기반으로 일하며 업무 범위를 발주서에 근거해 철저히 제한하는 상황에서 굳이 브리핑을 해 가며 질의응답을 하고 또 그 자리에서 요구사항의 문제점 따위를 지적하는 행동에는 아무런 의미가 없습니다. 이런 행동이 의미 있으려면 회의에 참여한 협업 부서들이 스스로 움직여야만 합니다.

시스템 기획서에 데이터구조 제안이 여러 개 필요할 거라고 생각한 이유는 아마도 기획서 검토 과정에서 데이터구조의 불완전함을 근거로 기획 전체가 종종 거절되기도 하기 때문이었을 거라고 예상합니다. 개인적인 관점에선 전형적인 사일로 현상의 일부처럼 느껴졌습니다. 또한 게임디자인 구성원이 상대적으로 더 많은 주니어님들로 구성되어 있는데 이 상황 속에서 협업 부서와 함께 시행착오를 거쳐 성장하는 대신 업무 자체를 거절해 알아서 문제를 해결해 오도록 하는 접근에 가깝다고도 생각합니다. 그래서 이 질문에 대한 제 답변은 데이터구조는 정답이 있는 문제에 가깝고 정답이 있다는 의미는 여러 제안을 만들 필요가 없다는 것입니다. 기 구축된 나머지 시스템들의 데이터구조와 새로운 요구사항의 기능을 고려한 다음 관계형 데이터베이스 구조를 설계하는 요령에 따라 데이터를 설계하고 이를 주로 엑셀로 관리할 것을 고려해 정규화 및 역정규화 과정을 거치면 거의 정답에 가까운 데이터구조를 제안할 수 있습니다. 이를 실제 개발할 사람들이 살펴보고 게임디자인의 의도를 파악한 다음 기술적으로 가능한 것, 그렇지 않은 것, 더 효율적으로 만들 수 있거나 그들의 경험으로부터 미래에 일어날 수 있는 예상되는 문제점을 감안해 수정을 거치면 적어도 이 프로젝트의 현재 시점 기준으로는 정답을 도출할 수 있습니다.

때문에 시스템 기획서가 게임디자인 부서 밖으로 나갈 때 데이터구조 제안은 여러 개일 필요가 전혀 없으며 여러 가지 안을 만들려고 시도하는 일 자체에도 아무런 의미가 없습니다. 문서에 여러 안이 나열되어야 하는 경우는 이 문서를 받은 사람이 그 안들을 살펴보고 의사결정을 하기를 원할 때 뿐입니다. 가령 1안과 2안 중 어느 한 가지를 선택해야 하는 상황일 때 의사결정에 필요한 정보를 함께 정리한 문서를 제시하고 브리핑 해 고위 의사결정자가 이들 중 하나를 선택하거나 아무 것도 선택하지 않거나 제 3의 안을 요구함으로써 의사결정 과정을 진행해 나갈 수 있습니다. 이 때는 여러 안이 필요합니다. 또 한 가지 제안을 제시할 때도 의사결정자가 이를 승인하거나 거절하는 의사결정을 하도록 만들기 위해 한 가지 제안을 실행할 때 일어날 일들을 예상하고 또 이 제안을 실행하지 않을 때 일어날 일들을 예상한 문서를 작성하기도 합니다. 하지만 시스템 기획서는 이미 이 기능이 필요하다는 사실이 프로젝트 전체에 걸쳐 공감대를 형상했을 뿐 아니라 의사결정권자에 의해 기능 개발의 의사결정이 끝난 다음에 작성됩니다. 그래서 시스템 기획서는 그저 요구사항을 명확하게 표현하고 이를 뒷받침할 데이터구조를 하나만 제안하면 됩니다. 이 문서는 의사결정을 요구하는 용도가 아닙니다.

단 데이터구조를 제안할 때는 우리들이 하고 있는 일이 관계형 데이터베이스에서 데이터구조를 설계하는 일과 아주 비슷하며 이 때 사용하는 정규화 과정 역시 우리가 올바른 요구사항을 설계하는데 도움을 줍니다. 또한 게임디자인에서는 결국 이 여러 기능을 엑셀 데이터시트에 기반해 접근하게 되는데 이를 위해 이상적인 데이터구조 설계와는 거리가 있는 성능을 고려한 역정규화 과정과 아주 비슷한 과정 역시 필요로 합니다. 그런데 꽤 많은 시스템디자이너들이 이 사실을 모른 채 그저 엑셀에 칼럼을 하나 만들어 칼럼의 값에 따라 특정 기능의 동작 여부를 결정하도록 하는 방식으로 데이터구조를 설계하고 이를 개발하는 입장에서도 그리 깊이 생각하지 않은 채 이를 따르다가 문제가 일어나기도 합니다. 모든 사람들에게 우리가 데이터구조를 설계하는 과정이 관계형 데이터베이스의 그것과 아주 비슷하다는 사실을 인식하고 수 십 년 전 데이터베이스 개념을 만들어낸 천재들의 고민 결과를 알아 두면 좋다고 말하기는 어렵다는 사실을 이해하고 있습니다. 하지만 그럼에도 우리들의 업무에 이런 역사적 배경이 있고 이 배경에 기반해 일하면 단기적으로는 데이터구조를 여러 개 제안해야 하는 이상한 상황에 처하지 않을 수 있고 또 궁극적으로는 미래의 변경된 요구사항에도 더 원활하게 대응할 수 있을 겁니다.

결론. 시스템기획서에는 여러 데이터구조 제안을 포함할 필요가 없습니다. 시스템기획서의 데이터구조는 정답이 있는 문제에 가까우며 이는 여러 제안이 필요하지 않음을 뒷받침합니다. 여러 제안을 만들어야 하는 상황은 종종 사일로 현상 때문이며 이 피해는 일을 처음 시작하는 게임디자인 조직에서 가장 많이 겪기 때문에 어떻게라도 일을 진행해야 하는 관점에서 필요하지 않은 여러 데이터구조 제안을 만들려는 무의미하고 불행한 시도를 하게 만들 수 있습니다. 하지만 이는 올바르지 않으며 우선 게임디자인 차원에서 정답에 가까운 올바른 제안을 함으로써 문제를 훨씬 완화하고 협업이 거절되는 상황에 더 강한 저항성을 갖출 수 있습니다. 이를 위해 우리들이 하는 이 설계 업무의 배경이 수 십 년 전 관계형 데이터베이스를 처음 고안해 낸 천재들이 이미 했던 고민의 연장선상에 있으며 이로부터 만들어진 몇몇 학문에 기반한다는 사실을 알고 있으면 훨씬 자신 있게 한 가지 정답에 가까운 제안을 할 수 있습니다.