소프트웨어의 설계의 기본은 MECE 이다.

예전의 맥킨지 업무방식 이라는 책을 읽은 적이 있다....

다른 내용들은 다 가물가물한데 가장 인상 깊었고 지금도 일종의 신조 처럼 여기고 있는 개념은 MECE 라는 개념이다.

MECE - Mutually Exclusive Collectively Exhaustive의 약자, 상호배제와 전체포괄 - https://ko.wikipedia.org/wiki/MECE

MECE 관련 자세한 내용은 위키를 읽으면 알 수 있을 꺼고 이걸 소프트웨어 설계에 어떻게 활용한다는 건지 예를 들어 보자

당신은 버스표를 티켓팅하는 시스템을 설계하려고 한다. 통상적으로 모든 프로젝트는 업무전문가가 Key User 로 참여하게 되고 이들 Key User 들 중에서 가장 높은 직급 또는 업무권한이 높은 User의 인터뷰로 부터 프로젝트가 시작된다.

보통 이렇게 인터뷰를 시작한다.

"이번 프로젝트에서 어떤 시스템을 원하는가?

"시스템으로 무엇을 하기 원하는가?

"사용자, 버스 등의 인적/물적 자원들의 규모가 어떻게 되는지..."

 통상적으로 위와 같은 형식상(?) 질문이 오간 다음 업무관련 질문 들 중에서 가장 상위의 추상적인 질문이 시작된다.

"버스는 어떤 종류들이 있고 버스표는 무엇무엇이 있는가? 

이런 질문으로 부터 질문을 시작 한다면 당신은 아직 설계 초보이다.

맨처음에 해야될 질문은 버스 이외에 다른 차량도 있는가? 라는 것이다. 그리고 버스표 이외 다른 요금도 있는가? 라는 두가지 이다.

버스표 티켓팅 시스템이라는 프로젝트 이름에 현혹되지 말고 MECE 의 개념대로 설계 한다면

1. 버스가 있다면 버스가 아닌 개념/설계도 반드시 존재한다. 

2. 버스표가 있다면 버스표가 아닌 것도 반드시 존재한다.

이렇게 상호배제/전체포괄 의 개념을 소프트웨어 설계에서 적용해야만 차후 업무범위가 급격하게 변경되서 프로젝트가 실패할 위험이 줄어든다. 

거의 대부분의 소프트웨어 설계자들은 업무전문가들의 "내 업무가 세상에서 가장 어렵고 복잡한 업무들중 하나다...." 라는 이야기를 들으면서 소프트웨어 설계를 산으로 보낸다. 그리고 나중에 변명으로 설계는 구현과 다르다....원래 프로젝트는 이런거다....라는 어이없는 말을 한다.

설계자가 빠뜨린 MECE 개념은 기능이 구현되고 실제 사용자가 테스트 하면서 "이거 아니고 이런것도 되야 된다"는 식으로 나오게 도고 이 시점에 설계자들은 책임지지 않고 한발 뒤로 물러나서 개발자와 업무전문가를 직접 Contact 시켜 버리는 일이 다반사이다.

처음부터 MECE 의 개념하에서 업무범위를 명확히 하면서 정확한(자세한이 아닌)설계를 한다면 좀 더 성공적인 프로젝트를 수행할 수 있을 것이다.