콜로세움은 물류를 중심으로 다양한 사업을 전개하고 있습니다. 3PL과 풀필먼트를 비롯해 특수 운송, 식자재 물류, 물류 IT 컨설팅, 물류 솔루션까지… 그 범위가 매우 넓죠. 국내와 해외를 아우르며, 하나의 솔루션 안에서 여러 기능이 함께 동작하고, 고객 역시 대형 기업부터 셀러, 협업 파트너까지 다양합니다. 이처럼 복잡한 환경에서 SaaS 개발을 본격화되면서, 물류 도메인을 처음부터 다시 이해하고 정리하기 위해 이벤트 스토밍(Event Storming)을 도입하게 되었습니다.
이 글에서는 콜로세움이 물류 SaaS를 개발 과정에서 이벤트 스토밍을 어떻게 활용했고, 무엇을 정리하고 얻었는지를 공유하고자 합니다.
오늘 내용 빠르게 훑기
- 물류 SaaS 개발 과정에서 이벤트 스토밍이 필요했던 이유
- 물류 도메인의 이벤트 스토밍이 갖는 특징
- 이벤트 스토밍을 통해 콜로세움이 실제로 얻은 변화와 인사이트
이벤트 스토밍이 필요했던 이유
콜로세움의 물류 사업들은 ‘Colo AI’라는 하나의 솔루션 안에서 연결되어 있습니다. 이 안에는 WMS(창고관리시스템), OMS(주문관리시스템), TMS(배차시스템)가 함께 포함되어 있고, 고려해야 할 기능과 흐름도 복잡합니다. 고객 역시 대형 기업 고객부터 1인 셀러, 다양한 협업 파트너까지 폭넓어, 서로 다른 요구와 조건을 동시에 만족시켜야 하는 구조입니다.
물류 SaaS로의 개발이 본격화되면서, 우리는 이 복잡성을 단순한 대응만으로는 풀 수 없으며 이제는 구조적으로 정리해야 할 시점이라는 걸 알게 되었습니다. 겉으로 보면 같은 입고, 같은 출고 프로세스처럼 보이지만, 실제 물류 현장에서는 조건에 따라 전혀 다른 흐름과 판단 기준이 존재했기 때문입니다.
- 보관 방식에 따른 작업 기준의 차이
상온·냉장·냉동·위험물 보관 여부에 따라 → 검수 기준, 로케이션 정책, 출고 가능 조건이 달라집니다.
- 셀러별 계약 조건에 따른 비용·정산 구조의 차이
동일한 SKU라도 셀러별 계약 조건에 따라 →보관료, 처리 수수료, 정산 방식이 서로 다르게 적용됩니다.
- 정책과 정산 로직의 누적으로 커지는 시스템 복잡성
이러한 차이들이 조건 분기와 예외 처리로 누적되면서 → 시스템 구조는 점점 복잡해지고, 전체 흐름을 이해하기 어려워졌습니다.
또 하나의 문제는 물류센터 운영 경험에서 비롯된 암묵적인 판단 기준이 시스템 설계 단계에서 명확한 언어와 구조로 정리되지 못하고 있다는 점이었습니다. 같은 ‘입고 완료’, ‘출고 가능’이라는 표현을 쓰고 있었지만 팀과 역할에 따라 그 의미는 미묘하게 달랐고, 이 차이는 시간이 갈수록 커졌습니다.
이 시점에서 콜로세움은 물류 SaaS를 빠르게 만드는 것보다, 오래 유지되고 확장 가능한 구조로 정리해야 할 단계에 와 있다고 판단했습니다. 그리고 먼저 정리되어야 할 것은 코드가 아니라, 물류센터에서 실제로 벌어지는 일과 그에 대한 공통된 이해라는 결론에 이르렀습니다. 이에 따라 물류 도메인을 다시 바라보고, 각자가 다르게 이해하고 있던 흐름과 용어를 맞추기 위한 방법으로 이벤트 스토밍을 도입하게 되었습니다.
이벤트스토밍이란 무엇인가?
알베르토 브란돌리니가 개발한 이벤트스토밍(Event Stoming)은 도메인에서 실제로 발생하는 사건(Event)을 중심으로, 모든 참여자가 함께 도메인을 시각화하고 이해를 맞춰가는 워크샵 방식입니다. 아키텍처나 데이터 모델을 먼저 정의하기보다, 현장에서 어떤 일이 벌어지는지를 드러내는 데 목적이 있습니다.
이 과정에는 개발자와 기획자뿐 아니라, 실제 물류센터를 운영하는 담당자 등 도메인을 가장 잘 알고 있는 이해관계자들이 함께 참여합니다. 각자가 경험한 이벤트를 바탕으로 도메인 내에서 발생하는 주요 사건들을 식별하고, 그 흐름을 따라가며 자연스러운 경계와 기준에 대해 협의해 나갑니다.
이벤트 스토밍의 핵심 특징은 다음과 같습니다.
- 개발자, 기획자, 운영 담당자 등 도메인 전문가와 이해관계자 모두가 참여한다.
- 포스트잇 등을 이용해 도메인 이벤트를 시간 순서로 시각화한다.
- 이를 통해 공통 언어를 구축하고, 도메인의 본질을 합의한다.
콜로세움은 이 방식을 통해 물류 도메인을 정확히 이해하고 팀 전체가 같은 기준 위에서 논의할 수 있는 기반을 만들고자 했습니다.
물류 도메인은 무엇이 다르고, 왜 어려울까?
물류 도메인은 입고·보관·출고라는 단순한 흐름처럼 보이지만, 실제로는 다양한 예외와 계약 조건, 정책이 얽혀 있어 기능을 추가하는 방식만으로는 구조를 정리하기 어렵습니다.
1. 풀필먼트는 ‘보관 방식’에서부터 갈라진다
상온, 냉장, 냉동, 위험물 보관은 같은 물류센터 안에 있더라도 작업 방식, 동선, 기준, 리스크가 전혀 다릅니다. 입고 검수 기준이 다르고, 보관 가능한 로케이션이 다르며, 출고 가능 조건도 달라집니다. 즉, 풀필먼트 서비스 유형 자체가 도메인을 나눕니다.
2. 하나의 서비스 유형 안에 여러 셀러가 동시에 존재한다
같은 SKU, 같은 보관 방식이라 하더라도 어느 셀러의 상품인지에 따라 처리 방식이 완전히 달라질 수 있습니다. 보관료, 처리 수수료, 정산 기준, SLA까지 모두 셀러별 계약 조건에 의해 결정되기 때문입니다. 물류센터 입장에서 중요한 단위는 ‘상품’이 아니라 상품 + 셀러 + 계약 조건입니다.
3. 물류는 ‘상태 변화의 연속’이다
입고, 보관, 출고는 각각 하나의 작업처럼 보이지만, 실제 물류에서는 단일한 동작이 아니라 상태 변화의 연속입니다. 입고 예정 → 입고 검수 중 → 검수 완료 → 보관 중 → 가용 재고 → 출고 대기 → 출고 완료 이 흐름에서 중요한 것은 ‘어떤 상태에서 → 어떤 상태로 언제 전환되었는가’입니다. 상태가 전환되는 지점과 그 조건에 따라 시스템 구조는 완전히 달라집니다.
이러한 도메인 특성을 충분히 이해하지 않은 채 기능부터 구현하기 시작하면, 상태 정의가 흐려진 상태에서 조건 분기와 예외 처리가 늘어나고, 결국 구조가 산발적으로 쪼개진 시스템이 되기 쉽습니다.
콜로세움은 이 리스크를 피하기 위해, 이벤트 스토밍을 통해 상태 변화의 흐름을 먼저 정리하고 합의한 뒤 그 위에 개발을 진행하는 방식을 선택했습니다. 같은 단어를 쓰더라도 동일하게 이해되고 있는지 확인하는 과정이 선행되어야 했기 때문입니다.
콜로세움의 이벤트 스토밍은 이렇게 진행됐습니다
콜로세움은 물류센터에서 실제로 벌어지는 일을 기준으로 이벤트 스토밍을 진행했습니다. 출발점은 단순했습니다. 코드나 문서가 아니라 사람이 이해할 수 있는 언어로, 한 장의 보드 위에 흐름을 펼쳐 놓는 것입니다.
입고 예정이 언제 발생하는지, 어떤 검수를 거쳐야 재고로 전환되는지, 어떤 상태가 되어야 보관 중 재고로 간주되는지, 출고는 어떤 조건에서 가능한지. 이런 질문을 이벤트 중심으로 하나씩 꺼내 놓았습니다.
(1) 도메인 이벤트 도출
우선 모든 참여자가 각자 생각하는 이벤트를 자유롭게 적었습니다. 이때 이벤트는 “이미 일어난 사실”로 적는 것이 기준입니다. 아래와 같은 형태입니다.
- 입고 예정이 등록되었다
- 입고 검수가 완료되었다
- 재고가 로케이션에 적치되었다
- 출고 주문이 생성되었다
- 출고가 완료되었다
(2) 커맨드와 액터 정의
이벤트를 트리거한 커맨드와 이를 실행하는 액터(사용자/시스템)을 구분해 붙였습니다.
- 입고 예정 등록 요청(커맨드)
- 출고 요청 발생(커맨드)
- 셀러 운영 담당자(액터)
- 물류 시스템 자동 트리거(액터)
(3) 정책, 외부 시스템, 구조적 경계
이벤트가 연결되기 시작하면 논의가 필요한 구간이 발생합니다. 예를 들어 이런 질문들입니다.
- 이건 언제 일어난 걸로 보는 게 맞지?”
- 이 상태는 보관이야? 출고 대기야?
콜로세움은 이벤트 간 트리거 관계를 의미하는 정책(Policy), 외부 시스템 연계, 그리고 서브 도메인 경계(Bounded Context)를 표시하며 확장했습니다. 이 단계에서 이벤트 간 의존 관계와 핫스팟이 명확해졌고, 핫스팟은 이후 논의와 설계의 중요한 실마리가 되었습니다.
이벤트 스토밍으로 얻은 것
콜로세움은 이벤트 스토밍을 통해 물류 SaaS를 더 빠르게 만들기보다, 더 정확한 구조 위에서 완성하기 위한 중요한 전환점을 만들 수 있었습니다.
용어와 기준이 정리되었다
.png%253FspaceId%253Deb9457b2-3851-4078-a3d5-11c538650f2f%3Ftable%3Dblock%26id%3D2cd2f6e0-088e-8051-812d-e7593f6817d4%26cache%3Dv2&w=1920&q=75)
입고·보관·출고라는 기본적인 흐름조차 팀과 역할에 따라 해석이 달랐습니다. 이벤트 스토밍을 통해 각자가 사용하던 용어와 기준을 한곳에 모아 비교하고, 공통의 언어와 판단 기준을 정리할 수 있었습니다.
도메인 이해가 눈에 보이기 시작했다
도메인 이벤트를 시간 순서대로 나열하고 토론하면서 그동안 명확하지 않았던 지점들이 드러나기 시작했습니다.
- 기능의 문제가 아니라 정책/정의가 모호한 구간이었다
- 이 흐름은 특정 이벤트가 선행되어야 성립했다
- 이 지점에 예외와 분기가 집중되어 있었다
이 과정을 통해 이벤트 스토밍은 단순히 흐름을 그려보는 작업이 아니라, 도메인 지식을 공유하고 정제하는 과정이라는 점이 분명해졌습니다.
개발 리스크를 사전에 줄일 수 있었다
이벤트 스토밍은 구현 전에 도메인을 시뮬레이션하는 과정입니다. 그 결과
- 기획 단계에서 빠져 있던 흐름
- 의도하지 않은 예외 흐름
- 정책별 분기 포인트
를 사전에 발견할 수 있었고, 나중에 수정해야 할 위험 요소를 줄일 수 있었습니다.
“이벤트 스토밍 없이 MVP를 만들었다면 프로젝트 중반에 큰 어려움을 겪었을 것이라는 확신이 들 정도였다”
라는 내부 공감대가 형성된 이유이기도 합니다.
커뮤니케이션 비용이 감소했다
기획, 디자인, 개발, 운영이 서로 다른 맥락과 용어를 사용하면 불필요한 해석과 재확인이 반복됩니다. 이벤트 스토밍을 통해 모든 이해관계자가 같은 흐름과 맥락을 공유하게 되면서 의사소통 비용이 크게 줄었습니다.
특히 멀티 센터, 다양한 고객을 동시에 고려해야 하는 콜로세움의 물류 SaaS 구조에서는 이 공통 이해가 이후 논의의 기준점이 되었습니다.
다음 단계를 더 명확해졌다
이벤트 스토밍을 통해 모든 문제가 한 번에 해결되지는 않았습니다. 하지만 중요한 차이는 생겼습니다.
- 어디가 아직 정리되지 않았는지
- 어떤 도메인은 추가 논의가 필요한지
- 어떤 영역을 더 작게 나눠 다시 봐야 하는지
가 명확해졌다는 점입니다.
콜로세움이 이벤트스토밍을 지속하는 이유
콜로세움의 DDD(Domain Driven Design) 진행 단계
Phase 1: 이벤트 스토밍 (현재 완료)
Phase 2: Bounded Context 정의 및 서비스 경계 설계 (진행 중)
Phase 3: 멀티테넌시 아키텍처 적용 (예정)
이벤트 스토밍은 DDD(Domain Driven Design)를 위한 출발점으로, 구성원 전체가 도메인 지식을 공유할 수 있는 중요한 계기가 되었습니다. 도메인 이벤트들을 한눈에 펼쳐보면서 막연하게 느껴졌던 설계 고민은 점차 구체적인 질문과 논의로 전환되었습니다. 이를 바탕으로 서비스 경계를 나누고, 구체화하며 다양한 센터와 고객을 자연스럽게 수용할 수 있는 멀티테넌시 아키텍처로 발전시켜 나갈 예정입니다.
서비스 규모가 커질수록, 그리고 멀티 센터·계정·권한 구조처럼 기본 전제가 확장될수록 새로운 복잡성이 계속해서 생길 것입니다. 콜로세움이 이벤트 스토밍을 반복하는 이유도 여기에 있습니다. 기능을 먼저 구현하고 이후에 구조를 맞추는 방식보다, 문제를 조기에 드러내고 팀 전체의 이해와 합의를 먼저 만드는 것이 물류 SaaS를 더 안정적으로 완성하는 길이라고 믿기 때문입니다.
물류센터를 움직이는 소프트웨어를 만듭니다
콜로세움은 물류센터를 구조적으로 설계하는 소프트웨어를 만듭니다. 그 소프트웨어는 개인의 경험이나 암묵지에 의존하기보다, 모두가 같은 이해를 공유할 수 있는 구조 위에서 만들어져야 한다고 믿습니다.
이벤트 스토밍은 콜로세움이 그 구조를 만들어가는 방식 중 하나입니다. 입고가 언제 시작되고, 어떤 검수를 거쳐 어떻게 시작되고, 어떤 검수를 거쳐야 재고로 전환되는지, 어떤 상태가 되어야 보관과 출고로 넘어갈 수 있는지. 이 모든 과정을 시뮬레이션하며 대형 기업과 셀러 모두를 위한 물류 SaaS를 완성해 나가고 있습니다.
👉 콜로세움 엔지니어링팀은
기능을 빠르게 구현하는 것보다 문제를 어떻게 정의하고 구조를 어떻게 설계할 것인지에 더 큰 가치를 둡니다. 코드 이전에 도메인을 깊이 이해하는 과정이 중요하다고 믿고, 물류라는 복잡한 산업을 기술로 정리해 나가는 일에 진지하게 도전하고 있습니다. 콜로세움의 조직 문화, 문제를 풀어가는 방식, 그리고 현재 함께하고 있는 역할에 대한 내용은 공식 채용 페이지에서 확인하실 수 있습니다.
자주 묻는 질문(FAQ)
Q. 이벤트 스토밍은 회의랑 무엇이 다른가요?
A. 일반 회의가 “무엇을 만들지(요구사항)”를 정리하는 자리라면, 이벤트 스토밍은 “현장에서 실제로 어떤 일이 벌어지는지(도메인)”를 먼저 펼쳐 놓고 합의하는 자리입니다. 기능 목록보다 이벤트 타임라인을 먼저 맞추기 때문에, 같은 단어를 쓰고도 서로 다르게 이해하던 지점을 빠르게 발견할 수 있습니다.
Q. 물류 도메인의 이벤트 스토밍은 무엇이 특히 어렵나요?
A. 물류는 입고·보관·출고라는 단순한 흐름처럼 보이지만, 실제로는 보관 방식(상온/냉장/냉동/위험물), 셀러별 계약 조건, 정산/정책 로직에 따라 동일한 SKU라도 흐름이 달라집니다. 게다가 물류는 ‘상태 변화’의 연속이라, 상태 정의가 흐려지면 예외 처리와 조건 분기가 빠르게 늘어납니다.
Q. 이벤트 스토밍에서 가장 중요한 산출물은 무엇인가요?
A. 보드 자체도 중요하지만, 실제로는 다음 세 가지가 가장 큰 산출물입니다.
- 공통 언어: ‘입고 완료’, ‘출고 가능’ 같은 용어의 기준이 팀 전체에 동일해짐
- 상태 정의: 재고 상태가 어떤 조건에서 어떤 상태로 전환되는지 합의됨
- 핫스팟 목록: 정책/정의가 모호하거나 분기가 집중되는 구간이 질문 형태로 남음
이 세 가지가 있어야 이후 개발이 빨라지기보다 “덜 고치게” 됩니다.
Q. 이벤트 스토밍이 모든 문제를 해결해주나요?
A. 아닙니다. 다만 “어디가 아직 정리되지 않았는지”를 빠르게 드러내고, 그걸 팀이 합의 가능한 질문으로 바꾸는 데 강점이 있습니다. 콜로세움은 이벤트 스토밍을 통해 다음 단계(심화 세션, 연결 구간 정리, 용어 사전 작성)를 명확히 만들고, 그 흐름을 SaaS 완성도로 연결해 나가고 있습니다.
출처
Edit. 강대권, 허지은
Share article