데브코스 4차 프로젝트 백엔드팀은 초기에 도메인 주도 설계를 도입하기로 하였습니다. DDD(Domain Driven Design)에서는 유비쿼터스 언어 사용하고, 도메인 모델에 집중하며, 소프트웨어 Entity와 도메인 간 개념을 일치시켜야 한다고 합니다. 하지만 팀원 모두가 DDD에 대해 미숙하고 러닝 커브가 높다고 판단하여 DDD 도입은 하지 않는 방향으로 정해졌습니다.
그러다 프론트엔드와 백엔드 간의 도메인 이해도가 다른 부분이 꽤 존재하여, 소통하는 데에 문제가 발생하였습니다. 따라서 기존에 DDD를 하려고 할 때 하려고 했던 이벤트 스토밍을 진행하기로 하였습니다. 저희 팀에서는 프론트팀, 백엔드팀, 디자이너팀이 있는데, 소통 문제를 해결하기 위해 팀들 간의 공통된 이해와 도메인에 대한 깊은 이해를 위해 이벤트 스토밍을 이용해보기로 했습니다.
📌이벤트 스토밍?
이벤트 스토밍이란, 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습하는 방법입니다. 모든 관계자가 한 장소에 모여 도메인 지식을 공유하고 용어를 통일하며 프로젝트 내 회색 지대를 파악하여 향후 의사소통 비용을 절감할 수 있습니다.
준비물은 화이트보드, 포스트잇, 펜이 있으면 됩니다. 하지만 정말 큰 화이트보드와 여러 색깔의 포스트잇이 필요하기 때문에 온라인으로 진행하는 것도 좋은 방법이라고 생각합니다.
🤷♂️왜 이벤트 스토밍으로?
프로젝트를 진행하다보면, 같은 용어를 사용하더라도 다른 의미를 나타내는 경우가 있습니다. 또는 특정 주제에 대해 각자 생각하고 있는 내용이 다른 상황도 있습니다.
이러한 일이 발생하는 이유는 여러 가지가 있습니다.
- 유사한 용어의 혼용
- 도메인 요소 간의 관계나 흐름 파악이 미약한 경우
- 정확한 도메인에 대한 이해 부족
실제 프로젝트 기획 진행 중 소통 과정에서 유사한 용어에 대해 헷갈리는 경우도 있었고, 계속해서 회색 지대가 발견되었습니다.
이러한 상황을 해결하기 위해 저희는 이벤트 스토밍을 채택하였습니다.
📌이벤트 스토밍 적용기
저희는 일정 상, 백엔드팀과 프론트팀이 참여하여 이벤트 스토밍을 진행하였습니다. 기존에 플로우 차트가 어느 정도 작성된 상태여서 예상 시간은 오래 걸리지 않을 것으로 예상했습니다.

저희는 이벤트 스토밍 Figma를 통해 단계적으로 진행하였습니다.
1️⃣ 도메인 이벤트 뿌리기
이벤트 스토밍의 첫번째 작업은 도메인 이벤트를 작성하는 것입니다.
이 과정에서는 비즈니스 프로세스에서 유발되는 이벤트를 작성합니다. 과거형 동사로 작성하고 주황색 포스트잇을 사용하였습니다. 이때, ‘이 내용이 필요할까?’식의 토론은 최대한 지양하고, 팀원들 각각 생각했을 때 발생할 수 있는 이벤트를 작성하였습니다.
ex) 로그인에 성공하였다. 주변 편지를 탐색하였다.
아래 이미지는 도메인 이벤트 뿌리기 작업을 마쳤을 때의 Figma입니다.

저희는 시간을 정해두고 작성하였기 때문에 ‘이 단계에서 시간이 충분했다면, 더 많은 이벤트가 나오지 않았을까’ 생각합니다. 실제로 이후 단계 작업에서 미처 생각지 못한 이벤트들이 존재했습니다.
2️⃣ 이벤트 정리
2단계에서는 저희가 1단계에서 작성한 이벤트들을 각 분류와 시간순서에 맞게 정리하였습니다. 이 과정에서 최대한 위치/순서가 맞을지에 대한 토론은 진행하지 않았고, 저희가 진행하기 좋게 정리하였습니다.

3️⃣ 액션 붙이기
3단계에서는 어떤 행동인지에 따라 이벤트를 분리하고, 어떤 행동인지 파란색 포스트잇으로 작성하였습니다.
예를 들어, ‘편지지를 선택하였다.’, ‘편지 내용을 작성하였다.’ 같은 문장은 편지 작성 파란색 포스트잇으로 관리하였습니다.
ex) 편지 작성

4️⃣ 액터 및 토론 붙이기 & 정책
4단계에서는 해당 액션을 하는 주체와 필요한 토론 내용을 작성하였습니다. 액터는 회색 포스트잇으로, 토론은 빨간색 포스트잇으로 붙였습니다. ‘누가 어떤 행동을 해서, 어떤 이벤트가 발생했다.’라는 문장이 완성되었고, 이후 자연스럽게 팀에서 토론해야 할 내용들이 수면 위로 떠올랐습니다. 따라서 이 과정에서 토론해야 할 내용을 빨간색 포스트잇으로 붙이고, 토론해야할 내용들에 대해 팀 전원이 의논하였습니다.
액터 : ex) 사용자
토론 : ex) 편지 글자 수 제한은 어떻게 할지?

주로 토론해야 할 내용들은 정책과 관련된 내용이었습니다. 그래서 토론을 통해 정리된 정책은 보라색 포스트잇으로 작성하였습니다.
ex) 편지 글자 수 : 20~3000자

5️⃣ 외부 시스템
5단계에서는 외부 시스템 사용하는 것에 대해 분홍색 포스트잇으로 작성하였습니다. 저희 서비스에서는 지도 API와 이메일 인증에 대해 외부 시스템을 사용하였습니다.
ex) Mapbox

6️⃣ 도메인 별 구분
6단계에서는 도메인 별로 구분하는 작업을 진행하였습니다.
📌느낀 점
사실 저희는 기획과 플로우를 어느 정도 작성한 상태에서 이벤트 스토밍을 진행하였습니다. 그래서 실제로 이벤트 스토밍을 하기 전에는 예상 소요시간이 길지 않을 거라 예상했지만, 팀/개인별로 이해하고 있는 내용이 다른 경우가 꽤 있다는 것을 확인할 수 있었습니다.
이벤트 스토밍을 통해 미처 결정하지 못한 서비스 정책들에 대해서 결정할 수 있었고, 도메인에 대한 공통된 이해를 세울 수 있었습니다.
사실, 이벤트 스토밍을하기 전에는 필요성에 대해서 어느 정도 의문을 가지고 시작했지만, 결과는 팀원들 모두 어느정도 만족스러운 결과였습니다.
저희가 진행한 이벤트 스토밍 방식이 정확한 이벤트 스토밍 방식이 아닐 수 있습니다. 이벤트 스토밍을 진행하면서, 모두가 이벤트 스토밍에 대해 정확히 이해하지는 못해서 중간중간 과정 진행에 브레이크가 걸렸습니다. 또한 당시 프로젝트/팀 상황에 맞게 어느정도 조절하여 진행하였습니다.
'데브코스' 카테고리의 다른 글
인덱스를 통한 받은 편지 조회 개선하기 (0) | 2025.03.21 |
---|---|
알림 기능의 필수 여부 확인하기 (0) | 2025.02.08 |
모니터링 서버 구축하기 (0) | 2025.01.27 |
FCM을 통한 백엔드에서의 푸시 알림 전송 (0) | 2024.12.10 |