티스토리 뷰

들어가면서

게임을 개발하면서 (혹은 일반적인 소프트웨어를 개발하면서) 가장 큰 문제중의 하나는 개발 일정계획대로 잘 지켜지지 않는 경우가 많다는 것이다. 개발일정계획이 잘 지켜지지 않는 이유는 무엇일까? 개발자들이 게으르기 때문일까? 아마 그렇지는 않을 것이다. 밤을 세워 일해가며 자기자신을 기꺼이 일을 위해 희생하는 성실한 개발자들도 개발일정계획을 준수하는 경우는 많지 않다.

요구사항

내가 생각하는 이유는 개발일정계획을 짜기 위한 근거인 요구사항(Requirement)이 명확하게 제시되지 않았기 때문이다. 예를 들어서 단순하게 '이펙트 에디터를 3개월 안에 만들어 주세요!' 라는 요구는 매우 임의적이고도 무책임한 요구사항이다. 이런 요구사항만으로는 어디까지 뭘 만들어야 하는지 매우 모호할뿐더러 의사전달이 제대로 이루어질 수 없지만, 이런 경우는 개발현장에서 의외로 많이 볼 수 있다. 요구사항은 언제나 구체적일 수록 좋다. '요구사항'이란 것 자체가 개발의 대상이고 개발의 산물이라는 것을 인식하여야만 한다.

요구사항을 어떻게 개발하는가? 요구사항의 개발은 분석의 과정 그 자체이다. 애매함에서 구체적의 범주로 옮겨질때까지 쪼개고 또 쪼개는 분석의 과정이다. 하지만 그 쪼개는 칼날은 임의적인 쪼갬이 아니라 의미가 살아있는 쪼갬이어야 한다. MECE 는 그러한 의미가 살아있도록 쪼개는 칼날중 가장 완벽한 칼날이다.

MECE

MECE 란 무엇인가? Mutually Exclusive, Collectively Exhaustive 의 약자이다. 즉, 서로 겹치는 부분이 없으며, 모아놓으면 완전히 커버한다라는 의미이다. 이것은 맥킨지에서 컨설팅을 하기 위해 다양한 정보를 수집하고 수집한 정보들을 체계적으로 분류하여 타당한 해답을 찾는 기본 방식에서 비롯되었다. 컨설팅이란 무엇인가? 어떠한 문제에 대한 해답을 찾도록 조언해주는 것이 바로 컨설팅이다. 그러한 문제들은 간단한 문제가 아닌 기업의 흥망성쇠와 관련된 중요한 문제들인데 예를 들면 이렇다

  • 어떻게 하면 우리 회사가 더 돈을 많이 벌 수 있을까? 우리 회사 생산라인의 효율성을 더 높이려면 어떻게 해야 하는가?
  • 우리 회사의 이 프로젝트는 성공 가능성이 어느정도나 되는가?
  • 우리 회사가 이 신규사업에 진출해야 하는가? 말아야 하는가?
이러한 문제에 대해 최대한 가까운 해답을 내려면, 단순한 상식이나 가정에 의한 어설픈 해답은 절대 있을 수 없다. 컨설팅 회사에 따라 다르지만 고급 컨설턴트의 1 일 활동료가 수백만원에 달하는 경우도 흔하다. 그렇게 비싼 댓가를 치루고서도 할 가치가 있는 대답을 얻기 위해서 컨설턴트를 부르는 것이니만큼, 컨설턴트는 반드시 최적의 대답을 찾아내어 제시하지 않으면 안된다. 그런 방법을 찾는데 기본이 되는 방법이 MECE 적 사고법과 Why so?/So what? 식 사고법이다.

간단한 대상물들을 MECE 하게 분류하는 것들은 어려운 일이 아니지만, 추상적이거나 종류가 많은 대상물들을 분류한다는 것은 그 자체로 하나의 학문이 된다. 예를 들면 도서관에는 수십 수백만가지의 도서를 다루어야 하는데, 도서들을 분류할때 MECE 한 기준이 없다면 검색이나 관리에 큰 불편을 겪을 수 밖에 없을 것이다. 그래서 문헌정보학과같은 학과가 따로 있는 것이 아니겠는가? 생물들을 분류할때도 마찬가지로 MECE 한 기준을 세워서 정리하는 것에 대해 들어보았을 것이다 (종속과목강문계의 7단계 분류법) 만약 그러한 분류기준중에 속하지 않는 생물이 있다던가, 혹은 어떤 생물이 두가지 이상의 계통에 속한다던가 하면 그러한 분류기준은 유용성을 상실할 것이다.

올바른 MECE 적 분류

하지만 정보를 MECE 하게 분류한다고 해서 모두 가치가 있는 것은 아니다. 우리가 흔히 하는 농담중에도 MECE 와 관련된 농담들이 많이 있다. 다음은 MECE 와 관련된 몇가지 농담들이다

  • '이세상의 자동차는 가야르도와 가야르도가 아닌 차 2 가지 뿐이다'
  • '이세상에는 성별이 3 가지 있는데, 남자, 여자, 이공대여자 이렇게 3 가지이다'
  • '...'
위 농담들을 보면 MECE 하게 나눈다고 다 의미가 있는 것은 아니라는 것을 알 수 있을 것이다. 복잡한 대상을 좀 더 쉽게 풀기 위해서 더 작은 대상으로 나누는 만큼, 최대한 나뉘는 대상이 밸런스된 상태로 나뉘어야 할 것이다.

다시 몇가지 실용적인 예를 들어보자. 여러분의 회사에서 새로운 게임 개발 프로젝트를 진행하고자 한다. 이때, 새 프로젝트의 대상 유저층은 누구로 잡아야 할 것인가? 라는 문제를 논한다고 할 때 유저층의 구분방법에 대해서는 기준이 있어야 할 것이다. 게임을 플레이하는 유저를 나누는 방법에 대해 생각해보자
  • 연령대/직업에 따라 나누는 방법
    • 초등학생유저, 중학생유저, 고등학생유저, 대학생유저, 직장인유저, 장년층유저, 노년층유저
  • 지역에 따라 나누는 방법
    • 서울/수도권유저, 경기도유저, 충청도유저, 강원도유저, 전라도유저, 경상도유저, 기타..
    • 한국유저, 일본유저, 동남아유저, 중국유저, 유럽유저, 북미유저
  • 성별에 따라 나누는 방법
    • 남자유저, 여자유저, 동인녀유저
  • 게임실력에 따라 나누는 방법
    • 게임을 할 줄 모르는 사람, 라이트유저, 코어유저
  • 플랫폼에 따라 나누는 방법
    • PC 유저, 콘솔유저, 오락실유저
  • 위 나누는 방법의 조합
    • 연령/직업 분류 * 성별
    • 게임실력 * 국가
    • 기타 등등...
위의 분류방식 예제를 보면서 느끼는 것이겠지만 사람 같은 큰 대상을 분류할 때에는 무턱대고 나눠진다고 해서도 좋은 것이 아니란 것을 알 수 있다. 민족대화합과 지역주의 타파를 부르짖는 이 시대에 경상도 유저와 전라도 유저를 나누는 것이 무슨 의미가 있겠는가? 중요한 것은 분류하는 목적에 부합하는 분류를 잘 찝어내야 한다는 것이다. 필요 이상으로 분류를 하면 불필요한 혼동만 가중될 뿐이다.

MECE 한 기획

여기까지 글을 진지하게 읽어보았다면, 여러분의 기획내용을 다시 한번 들여다보고 기획서의 내용중에 중복된 부분이 나타나는지? 혹은 빠진 부분은 없는지? 를 검토해보고 싶을 것이다. 하지만 사물이나 생각을 MECE 하게 분석한다는 것은 의외로 어렵고, 많은 훈련이 필요한 작업이다. 분석작업에 도움이 될 몇가지 힌트를 제공한다.

  1. 정보를 MECE화 하는 것은 많은 경우의 수와의 싸움이다. 그 싸움에서 지지 않으려면 쪽수로 밀어붙이는 것도 한가지 방법이다. 다른 사람의 눈으로 볼 때에 누락이나 중복을 금방 찾아내는 경우가 많다. 그러기 위해서는 wiki 같은 도구를 통한 공동작업이 매우 효율적이다.
  2. 이미 만들어진 MECE framework 를 활용한다. 예를 들어서 경영에 대해 공부한 적이 있는 사람이라면 '마케팅의 4P' 라고 해서 마케팅의 4 대 요소 (제품(Product) 유통(Place) 가격(Price) 촉진(Promotion)) 같은 것을 들어본 적이 있을 것이다. 왜 4 대 요소로 나눈다던가, 6대 요소로 나눈다던가 하는 것을 가르치는 것일까? 이것은 '마케팅'이라는 매우 광범위하고도 추상적인 대상을 많은 검증과 연구에 의해 4P 로 MECE 하게 나누어놓았기 때문이다. 바퀴를 재발명할 필요는 없다는 격언과도 같이 (Don't reinvent the wheel) 기본적인 MECE 의 산물들은 직접 붙잡고 처음부터 고민하는 것보다 이미 알려진 방식을 사용하는 것이 좋다.
  3. 어떤 개념을 생각했다면 항상 그에 수반되는 반대개념을 생각한다. 예를 들어 게임 기획서중에 '아이템의 장착' 에 대한 항목이 포함되어 있다면, '아이템의 탈착' 에 대한 항목도 있어야 할 것이다.

마치며

MECE 하게 나누는 훈련법 자체에 대해서는 아래에 소개된 로지컬 씽킹 (일빛출판사 간행 - 오카다 게이코 외 1 인 저)이라는 책을 강력히 추천한다. 그 책을 찬찬히 읽어보고 예제로 나온 연습문제들에 대해서 생각해보기 바란다. 그리고나서 지금까지 당신이 작성한 기획안이나 기타 문서화된 자료들을 다시 한번 'MECE 하게 나눈다'라는 관점에서 살펴보고, 각각의 요소들이 충분히 분해되었는가를 (구체적이고 현실적인 일정계획을 수립할 수 있을 정도로) 점검해보기 바란다.
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함