기능분해나 업무흐름과 비슷해 보이는데 굳이 Event Storming을 해야 하나요?

Event Storming (ES)를 며칠 또는 몇시간이라도 해 본 분들은 장점도 느끼지만 아래와 같은 의문도 들 수 있다.

 

업무를 Sub Domain 별로 나누고 그 안에서 좌측에서 우측으로 시간순으로 이벤트를 나열하는게 기존 산출물과 무엇이 다른가? 업무 기능 분해도에서도 업무별로 기능을 나열했고 그 선후관계나 흐름을 보기위해 Flow Chart 형태의 업무 흐름도도 정의했는데 그와 비슷해 보이는 ES를 굳이 또 해야하는가? 중복적이고 비효율적이지 않은가?더구나 ASIS Paint Point를 기반으로 개선사항까지 논의한다면 이는 요구사항 정의때 이미 다 한 것 아닌가?

 

위와 같은 의문이 드는 것이 어찌보면 기존 산출물 작업을 열심히 한 분들에게는 당연한 의문일 수 있다.

 

모든 산출물은 그 용도가 있다. 말그대로 요구사항을 정의하기 위한 문서도 있고, 시스템적인 기능을 나열하기 위해 기능분해도, 기능분해도의 각 기능별 흐름을 보기위한 업무 흐름도 등 다양한 산출물이 있다. 평면도 하나 만으로 건물을 설계하고 시공할 수 없듯이 여러 측면으로 크로스 체크해 가면서 TOBE시스템을 만들기 위한 여러 산출물이 존재하는 것이다.

 

그렇다면 기존 산출물과 다소 대동소이해 보이는 ES를 굳이 왜 해야하는가?

물론 하지 않아도 된다. Microservice를 잘 식별하고 검증하고 정의할 수만 있다면 ES를 하지 않아도 된다. 실제로 기능분해도의 업무구분을 바탕으로 서비스를 정의하기도 하고 직관적으로 결정하기도 한다. 하지만 보다 효과적으로 집중해서 서비스를 식별하기 위해서 ES를 하는 것이다. 각 산출물의 목적이 있듯이 ES는 요구사항 정의도, 기능분해도, 업무흐름이 아닌 서비스 식별의 목적이 있는것이다. 물론 앞서 이야기한 부분들을 부수적인 효과로도 얻을수 있고 소규모 프로젝트라면 대체할 수도 있다. 이는 품질담당자나 고객과 협의만 된다면 훌륭한 도구가 될 수 있다.

 

그리고 ES의 궁극적인 목적인 서비스 식별 및 검증이므로 그 사전 작업으로 업무별 특징을 파악하고 Domain Event의 흐름을 파악해 보는 것이다. 어떻게 하면 좀 더 독립적으로, 확장 가능하고, 장애 격리되는 형태의 서비스를 구성하고 느슨하게 통신할 수 없겠는지.

 

ES장점/특징/고려사항

• 고객사 현업(업무전문가), IT담당자 / 수행사 PL, 분석설계자, 개발자 / 유지보수 담당자 다 같이 모여 한자리에서 집중 논의
• 현업부터 개발자까지 이해관계자가 이렇게 논의하는 자리가 많지 않아 업무(빠른 업무 공유) 뿐 아니라 서로를 이해하는 자리
• 기존 요구사항정의서, 기능분해도, 업무흐름도 등의 엑셀이나 PPT 산출물을 산재되어 있고 한눈에 파악하기 어려운 반면 ES는 전체를 조망하면서 함께 논의하기 좋은 도구 (꼭 MSA가 아니더라도 ASIS, TOBE 논의의 훌륭한 도구)
• 기존 산출물은 파트별로 작성/검토 주체가 다르고 담당 파트 외에는 파악이 어려운 반면 ES는 다같이 논의하므로 쉽고 빠르게 접근 가능, 인수인계 또는 신입사원에게 설명하기에도 좋은 도구
• 무엇보다 Notation이 간단, 현업도 쉽게 이해하고 참여 또는 진행 가능
• ES의 궁극적인 목적은 ASIS Event 및 Paint Point를 바탕으로 Microservice정의하는 것
• ASIS화면, 요구사항, 기능분해도 ,업무흐름도 등 기존 산출물을 참고해서 진행
• ES를 포함한 서비스정의 워크샾은 TOBE를 기준으로 진행되므로 ASIS 분석, 요구사항 정의, 기능분해, 업무흐름도 정도는 작성한 후 진행하는 것이 바람직(ASIS, TOBE에 대한 파악이 어느정도 된 후, 그리고 아키텍쳐의 큰 그림도 정리된 후, 예를들어 AP 당 DB 하나씩/Domain Event 의 필요성, 느스한 결합 등)
• 프로젝트 규모가 작거나 ASIS가 없는 경우 바로 워크샾을 진행하면서 업무 파악(인수인계)도 가능, 복잡한 산출물 없이 분석과 기본설계의 초안까지 역할 담당 가능