마이크로서비스 따라하기 2탄 밋업 후기

MSA가 이토록 비즈니스 중심적일 줄이야.

​​

이전까지의 경험한 MSA 설계
MSA 방식으로 두 번째 프로젝트를 진행하고 있다. 이번 두번째 프로젝트는 이미 설계된 방식으로 서비스들이 구성되어 개발되고 있지만, 첫번째는 선임급들이 모여 직접 서비스들을 나누고 개발했었다.

서비스를 나누는 작업은 기획된 화면 설계서를 분석하여 요구사항을 파악하고, 어떻게 나누면 좋을까 여러 회의를 통해 진행했다. 별다른 방법론 없이, MSA의 가장 기본 원칙인 데이터 중심으로 나누는 것이 끝이었다.

나눠진 서비스들은 큰 무리없이 개발로 이뤄졌다. 다만, 충분한 시간을 들이고 분석하지 못한 탓인지, 아니면 부족한 기억력 때문인지 지속적인 컴을 통해 보정하고 수정하며 개발을 진행했다. 특별한 요구사항이 없는 데도 요구사항 분석 단계를 개발까지 끌고와서 진행했던 것이다.

또한 경험의 부족인지 아니면 회의 중의 논거가 부족했었는지 서비스를 이렇게 나눠도 되나? 라는 물음표가 계속 떠다녔다.

이점에 있어서 이번 밋업은 좋은 자리였다. 비즈니스적인 요구사항들을 MSA 서비스로 녹여내는 방법에 초점이 맞춰져있었던 이번 밋업은 이전까지의 많은 물음표와 불안감을 해소시켜주었다.

​​

소개된 MSA 설계 방법
소개된 설계 방법은 6가지(?) 정도 단계로 나눠진 사이클이었다. 이번 밋업에서는 그 중 요구사항을 분석하여 설계하는 앞 3단계를 중점적으로 소개했다.
​​
소개된 흐름은 다음과 같았다.
1. Event Storming으로 Bounded context(ddd의 aggregate)를 나눠 Candidate(서비스)를 구성하고,
2. Boris diagram으로 서비스 간 통신 인터페이스를 정의한다.
3. 마지막으로 Snap-E 를 통해 서비스의 api, data 등을 구성한다.
​

이 흐름의 가장 큰 특징은 텍티컬한 접근 없이 비즈니스적인 접근으로 풀어간다는 것이었다. 실제로 비즈니스 관계자들이 한 곳에 모여 벽에 포스트잇을 붙혀가며 진행한다고 소개했다.

​

​밋업 진행과 후기

​

밋업에서는 간단한 흐름 설명 후 예제를 통해 설계에 대한 설명을 진행했었다. 설계된 화면을 보며 포스트잇으로 비즈니스 이벤트를 적어 붙이고, 흐름을 구성하여 서비스를 도출해내고, 하이레벨의 서비스를 설계했다. 직접적인 흐름을 체험할 수 있어서 좋았다.
​

​

그리고, 소개된 설계 방법이 추상적인 회의 내용을 시각화할 수 있고, 그 흔적이 나름의 문서가 된다는 점에 있어서 다음 프로젝트 진행 때 적용해보면 좋을 것 같다는 생각이 들었다.

마지막으로 QnA 때는 레거시 코드를 MSA로 변환하는 것에 대한 질문이 많이 나왔다. 실무 환경에서도 MSA로 전환하려는 움직임을 느낄 수 있었다.