이벤트 스토밍 워크숍: 반품 프로세스로 배우는 진행 방법

반품 절차는 프로세스 차트로 보면 단순합니다. 요청하고, 승인하고, 물건을 받은 뒤 환불하면 됩니다. 하지만 고객지원 담당자, 물류 담당자, 개발자에게 ‘승인’이 무엇을 뜻하는지 물으면 서로 다른 답이 나올 수 있습니다. 고객이 물건을 보내도 된다는 뜻일 수도 있고, 검수를 통과했다는 뜻일 수도 있으며, 결제 시스템이 환불 지시를 접수했다는 뜻일 수도 있습니다.

이벤트 스토밍(EventStorming) 워크숍은 업무에서 의미 있는 사건을 하나의 이야기로 연결하면서 이러한 차이를 드러내는 방법입니다. 이 글에서는 가상의 소매업체 반품 절차를 예로 들어, 서로 다른 설명을 실제 업무 담당자들이 함께 검토할 수 있는 모델로 정리하는 과정을 살펴봅니다.

프로세스 모델링의 범위를 정하세요

알베르토 브란돌리니(Alberto Brandolini)의 이벤트 스토밍 프로세스 모델링 형식은 기존 프로세스를 살펴보거나 새로운 프로세스를 설계하는 데 쓰입니다. 특정 업무 흐름을 논의할 때 시작하기 좋은 형식입니다. 빅 픽처(Big Picture) 세션은 더 넓은 업무 영역을 탐색하고, 소프트웨어 설계(Software Design) 세션은 구현 문제를 더 깊이 다룹니다. 짧은 회의 한 번으로 세 가지를 모두 끝내겠다고 약속하지는 마세요.

소매업체 사례의 범위는 ‘고객이 구매한 물건 한 개를 반품하고, 환불받거나 거절 사유를 안내받는 과정’으로 정합니다. 교환, 공급업체와의 정산, 부정행위 조사는 첫 번째 검토에서 제외합니다. 이들이 반품 절차와 만나는 지점은 표시하되, 보드 전체가 그 이야기로 바뀌지 않도록 합니다.

고객지원, 반품 운영, 결제, 개발 등 서로 다른 부분을 설명할 수 있는 사람을 초대하세요. 반품 정책을 결정할 권한이 있는 사람도 참여하면 좋습니다. 개발자만 모이면 소프트웨어의 동작은 정확히 설명해도, 직원들이 시스템 밖에서 하는 일을 놓칠 수 있습니다.

업무 담당자가 알아볼 수 있는 이벤트부터 적으세요

처음부터 순서에 합의하려 하지 말고, 각자가 이벤트를 추가할 시간을 줍니다. 도메인 이벤트는 ‘반품 요청됨’, ‘상품 검수됨’처럼 이미 일어난 의미 있는 사건입니다. 주황색 메모에 일이 일어났음을 나타내는 표현으로 적으세요. ‘상품 검수하기’는 하려는 행동이고, ‘상품 검수됨’은 그 행동으로 발생한 사실입니다. DDD Crew 용어 안내에서 이러한 표기법과 프로세스 모델링에 쓰이는 다른 개념을 확인할 수 있습니다.

참여자에게 자신이 맡은 업무에서 사례를 가져오도록 요청합니다. 물류 담당자는 ‘반품 택배 도착함’을, 고객지원 담당자는 ‘반품 라벨 발송됨’을 추가할 수 있습니다. 개발자가 처음 설명한 과정에는 두 가지가 모두 빠져 있을 수 있습니다. 비슷한 메모가 있어도 같은 사건인지 확인하기 전까지는 지우지 마세요.

화면이나 데이터베이스의 필드명을 그대로 가져올 때는 주의해야 합니다. ‘상태 변경됨’만으로는 업무에서 무엇이 달라졌는지 알 수 없습니다. 고객이나 담당자에게 어떤 사실이 새로 성립했는지 물어보세요. ‘환불 완료됨’도 정의가 필요합니다. 환불 지시를 보냈다는 뜻인지, 결제 제공업체가 접수했다는 뜻인지, 실제 정산까지 확인됐다는 뜻인지 구분해야 합니다. 각 단계 이후에 내리는 판단이 다르다면 이벤트도 분리하세요.

반품 과정을 함께 이야기해 보세요

이벤트를 그럴듯한 순서로 놓은 뒤 참여자들이 소리 내어 과정을 설명하게 합니다. 이 사례의 첫 흐름은 다음과 같습니다. 반품 요청됨 → 반품 승인됨 → 반품 택배 도착함 → 상품 검수됨 → 환불 요청됨 → 환불 확인됨.

이 순서는 사례를 논의하기 위한 모델이지, 모든 소매업체의 정책을 뜻하지는 않습니다. 실제로는 물건을 받기 전에 환불한다면 그렇게 표시해야 합니다. 검수와 다른 작업이 서로 독립적으로 진행될 수 있다면, 한쪽이 항상 다른 쪽을 기다리는 것처럼 보이지 않도록 별도의 흐름에 놓으세요.

브란돌리니의 Conversational System 패턴은 동시에 일어나거나 순서가 달라질 수 있는 행동에 고정된 순서를 강요하지 않도록 설명합니다. 중요한 것은 메모가 얼마나 반듯하게 놓였는지가 아니라, 무엇이 무엇에 의존하는지입니다.

의견이 갈리면 해당 이벤트 가까이에 선명한 분홍색 핫 스폿(Hot Spot)을 추가합니다. 이견은 질문으로 적으세요. ‘정책 문제’보다는 ‘반품 승인은 환불을 보장하는가?’가 더 구체적입니다. 주변 과정까지 이해할 수 있도록 이야기를 이어간 뒤, 필요한 담당자와 함께 그 질문으로 돌아옵니다.

이벤트를 행동과 필요한 정보에 연결하세요

이벤트의 흐름을 이해했다면, 그 사건을 일으키는 행동을 추가합니다. 명령이나 행동은 파란색 메모로 표시하고, 누가 또는 어떤 시스템이 시작하는지 적습니다. 판단에 필요한 정보는 행동을 설명하는 데 도움이 되는 지점에만 추가하세요. 처음부터 가능한 모든 기호를 소개하면 워크숍이 표기법 수업처럼 느껴질 수 있습니다.

소매업체 사례의 첫 세부 구간은 다음과 같이 정리할 수 있습니다.

정책은 이벤트에 어떻게 반응할지 설명합니다. 이 사례에서는 ‘검수 결과 반품이 인정되면 환불을 요청한다’는 규칙을 제안할 수 있습니다. 해당 이벤트와 행동 사이에 연보라색 메모로 적으세요. 정책 담당자가 확인하기 전까지는 제안임을 표시해야 합니다. 연결선을 그었다고 없던 업무 권한이 생기지는 않습니다.

환불을 요청하는 것과 확인하는 것 사이의 간격에도 주목하세요. 둘을 같은 이벤트로 취급하면 응답 지연이나 중복 요청을 놓칠 수 있습니다. 워크숍에서 당장 결제 시스템 설계까지 해결할 필요는 없지만, 둘의 차이는 드러내야 합니다.

예외적인 반품 한 건으로 모델을 점검하세요

일반적인 사례를 살펴본 뒤에는 논의에 변화를 주는 예외를 하나 선택합니다. 택배는 도착했지만 예상한 상품 식별 정보가 없다고 가정해 보세요. 고객지원 담당자는 고객의 주문을 알아볼 수 있지만, 물류 담당자는 택배 안의 물건이 해당 주문의 상품인지 확신할 수 없습니다.

참여자들에게 이야기를 이어가도록 요청하세요. 이때 ‘상품 검수됨’이 발생한 것인가요, 아니면 ‘반품 택배 도착함’까지만 발생한 것인가요? 누가 추가 정보를 요청할 수 있나요? 고객지원팀은 어떤 이벤트를 통해 이 반품에 주의가 필요하다는 사실을 알게 되나요? 답이 ‘누군가 메시지를 보낸다’라면 발신자, 수신자, 그리고 메시지로 전달하는 업무상 사실을 구체적으로 적습니다.

빈칸을 채우려고 기한이나 환불 권리를 임의로 만들지 마세요. 답하지 못한 정책 질문을 관련 메모 옆에 둡니다. 브란돌리니의 Rush to the Goal 패턴은 기본 흐름을 향해 나아가면서 반론과 대안을 계속 보이게 두는 방법을 설명합니다. 여기서는 모든 예외가 해결될 때까지 대화를 매번 멈추는 것보다 이 방식이 유용합니다.

업무에서 실제로 어떻게 행동하는지 이해한 뒤에는 별도의 예외 경로 흐름도 안내(영문)를 참고해 운영상의 분기를 구체화할 수 있습니다. 이벤트 스토밍은 그 분기들이 의존하는 이벤트의 의미부터 담당자들이 함께 이해하도록 돕습니다.

Boardmix에서 반품 모델을 만드세요

Boardmix를 열고 반품 논의용 빈 보드를 만듭니다. 넓은 작업 영역 위에 범위를 적으세요. 한쪽에 작은 범례를 두면 색상에만 의존하지 않고 이벤트, 행동, 정책, 핫 스폿을 구분할 수 있습니다.

메모를 추가하기 전에 참가자와 기호의 의미를 확인하세요. 색상과 라벨을 함께 쓰는 화이트보드 범례는 같은 기호를 같은 뜻으로 읽는 데 도움이 됩니다. 다른 워크숍의 색상 체계를 가져오기보다 여기서 사용하는 이벤트 스토밍의 의미를 유지하세요.

1. 첫 흐름의 여섯 이벤트를 주황색 스티키 노트로 추가합니다. 통화 중에도 읽을 수 있도록 글자를 충분히 크게 적으세요.
2. 이벤트 사이에 파란색 행동 메모를 넣을 공간을 남깁니다. ‘환불 요청하기’는 ‘환불 요청됨’ 앞에 놓으며, 이벤트를 대신하지 않습니다.
3. 검수 결과 옆에 제안한 정책을 연보라색 메모로 추가합니다. 참여자들이 논의한 관계만 연결하세요.
4. ‘반품 승인 = 환불 보장?’이라는 분홍색 질문을 ‘반품 승인됨’ 옆에 놓습니다. 미해결 질문은 영향을 받는 행동 가까이에 둡니다.
5. 적절한 편집 권한으로 보드를 공유합니다. 과정의 각 부분을 맡은 참여자가 한 명씩 흐름을 설명하고, 다른 사람들이 메모를 바로잡도록 요청하세요.

온라인 세션에서는 누군가 설명하는 동안 같은 구간이 화면에 보이도록 합니다. 여러 사람이 이견이 있는 부분을 동시에 재배치한다면 편집을 잠시 멈추고 각자의 대안을 설명하게 하세요. 보드는 대화를 돕는 도구입니다. 메모가 빠르게 움직인다고 의견이 일치한 것은 아닙니다.

모델이 보여주는 것과 아직 확인할 것을 구분하세요

보드가 완성돼 보인다고 소프트웨어가 그 과정을 구현하고 있다거나, 정책이 승인됐다거나, 중요한 예외를 모두 발견했다는 뜻은 아닙니다. 관찰한 현재 행동과 제안한 변경을 구분하세요. 새로운 환불 순서를 설계했다면, 무엇이 달라지는지 알 수 있도록 기존 순서도 남겨 둡니다.

소매업체가 바로 얻는 결과는 구체적일 수 있습니다. 모호한 이벤트의 이름을 바꾸고, 예외 승인 권한을 확인하며, 결제 결과를 알 수 없을 때 어떻게 처리하는지 조사하는 것입니다. 이 질문들은 운영팀과 개발팀이 함께 출발할 지점을 만듭니다. 다음 논의에서는 ‘승인’의 뜻을 다시 설명하는 대신, 아직 답하지 못한 분홍색 메모에서 시작할 수 있습니다.