[스파로스 5기] 1-2주차 회고 : 프로젝트 설계(이벤트 스토밍)

* 이전 글 : 1-2주차 회고 : 특강, skill-up 

0. SIVILLIAGE 클론 코딩 프로젝트

스파로스 아카데미에서 1차 프로젝트는 신세계 계열사 웹사이트를 클론코딩한다. 5기는 스타벅스 모바일 페이지와 조금은 생소한 쇼핑몰 S.I.VILLAGE 클론코딩을 하게되었고, 우리 조에서는 나를 포함해 쇼핑몰 도메인을 희망하는 조원이 많아 S.I.VILLAGE을 선택하게 되었다.

S.I.VILLAGE 모바일웹

현재 일수로는 12일 동안 프로젝트가 진행되고 있다. 주말과 연휴를 제외하면 실제로는 7일인데다, 하루에 프로젝트에 주어진 시간이 4시간 남짓이라 절대적인 시간 자체는 많지 않다. 팀원 모두가 개인 시간을 반납하고 주말에도 숙제하고, 연휴에도 모여서 회의한 결과, 1)이벤트 스토밍을 완료했고 2)ERD 작성은 70%정도 완료했다.
 

1. 이벤트 스토밍

이벤트 스토밍이란?

 
이벤트 스토밍을 한마디로 정의하면 도메인 주도 설계(DDD, Domain-Driven Design)라는, 비즈니스 영역을 기준으로 코드를 구분하는 개발 방법론을 수행하기위한 대표적인 모델링 방법론이다.

The most-likely outcome of an Event Storming workshop (image courtesy of Robert Laszczak https://threedots.tech)

위 사진과 같이 벽에 포스트잇을 붙이며 도메인 내에서 이뤄지는 특정한 이벤트를 기준으로 어떤 일이 일어나는지를 시각화 하는데, 이러한 과정에 개발자를 포함한 서비스와 관계 있는 모든 이해관계자들이 참여하며 불명확한 도메인을 정의하며, 서비스의 핵심 프로세스와 비즈니스 로직을 모델링할 수 있다. 
(자세한 내용은 링크로 대체.)

제로부터 시작하는 DDD를 위한 이벤트스토밍

 

이벤트 스토밍, 어떻게 하는 것이고 왜 해야 하나요? | 오토피디아 블로그

 
하여튼 이벤트 스토밍은 이러한 것인데, 그렇다면

왜 하는가?

우리(스파로스 아카데미)가 이벤트 스토밍을 진행한 취지는 아래와 같다.

• 클론코딩 할 사이트의 전반적인 도메인 파악
• 프로젝트 방향 설정 : 어떤 기능들을 구현해 낼 것인지
• 비즈니스 로직 흐름 파악 및 시각화
• 시각화/단순화를 통한 설계 개선
• 모든 조원의 일관적인 시각 구축, 보편 언어 형성

이 중 가장 큰 취지이자 장점을 꼽으라면 '시각화' 와 '통일된 시각'이 있을 것 같다.
 

어떻게 했는가?

우리는 FigJam을 통해서 이벤트스토밍을 수행했다. (스파로스 아카데미로부터 형형색색의 포스트잇을 받기는 했지만... 펜보다는 키보드 마우스가 익숙하다며 몇번 쓰다가 말았다...)

초기 이벤트 스토밍

초기에는 위 사진처럼 단순하면서 정석적으로(?) 이벤트 스토밍을 진행했다.  바운디드 컨텍스트(Bound Context) 단계까지 진행했을때의 모습이다. 

더 나아가 컨텍스트 매핑(Context Mapping)까지 진행했을때의 모습이다. 구성요소간 관계를 만듦으로써 로직의 흐름을 파악하기가 수월해졌다.
하지만 이 정도로 취지가 달성되지 않았다는 판단에, 여기서 더 나아가 다른 이벤트 스토밍의 형식에 얽매이지 않고 더더욱 디테일하게 이벤트 스토밍을 하기로 했다.

고작 회원가입 하나가

 어느정도로 디테일하게 진행할 지를 논의하며 혼란의 시기를 겪었다. Input데이터와 가능한 로직을 모두 나열하니까 오히려 시각화가 안되는 문제가 있었고, 이 문제는 일관적인 시각을 만드는데 어렵게 했다. 그래서 중간을 택했다.

예시) 주문 상품 발송 요청

최종

느낀점

어쩌면 변질된 이벤트 스토밍일지도 모르겠지만 취지만큼은 달성한 것 같다. 클론 코딩 특성상 없는 도메인을 만들어내는것이 아니라 있는 도메인에서 내용을 도출해내는 것이기 때문에 더 디테일하게 하는 판단이 옳았던 것 같다.(PM님의 피드백 이였다.) 단순한 모델부터 디테일한 모델까지 진행하며 비즈니스 로직 흐름에 대해 이해할 수 있었다.
또한 팀원들과 함께 진행하면서 각자 여러 관점으로 사건을 바라보는 집단지성의 힘을 빌릴 수 있었다. 그리고 각자 다른 시각에서 초래될 수 있는 잠재된 문제점들도 찾아낼 수 있었다. (가령, 주문에 제품을 참조시켜 놓는다면 주문내역의 값이 매번 변하게 되는 문제점 등)시각이 다를 경우 추후 ERD설계, 심지어는 개발단계에서도 서로간의 오해로 큰 비용을 치루게되는데, 디테일하게 이벤트 스토밍을 진행함으로써 팀 전체가 일관된 시각을 가져 미리 예방할 수 있지 않을까 싶다.
 
 

2. ERD

위와 같이 이벤트 스토밍을 진행하고 현재는 ERD를 그리는 중이다.  ERD를 시작한지는 이틀 밖에 되지 않았는데, 팀원들이 연휴를 반납해 일한 결과 70% 정도는 진행한 것 같다. ERD 작성 및 기타 문서작성이 모두 끝났을 3주차 회고에 겪은 문제에 대해 어떻게 해결했는지 자세히 다뤄 봐야겠다.