1강에서 우리는 왜 이 서비스를 만들고, 어디까지를 성공으로 볼지 정했습니다. 이제 그 목표를 실제 동작 흐름으로 바꿔야 합니다. 서비스는 추상적인 비전으로 구현되지 않습니다. 결국 누가 들어와서 어떤 행동을 하고, 그 과정에서 어떤 상태가 바뀌는지로 구현됩니다.
이 페이지의 목적은 단순히 사용자 종류를 나열하는 것이 아닙니다. 누가 시스템을 사용하는지, 어떤 외부 주체가 시스템과 상호작용하는지, 어떤 흐름을 반드시 완성해야 하는지를 고정해 뒤의 DDD 모델링과 화면 설계의 입력값으로 만드는 것입니다.
개발 강의에서 자주 생기는 문제는 기능 목록은 많은데 정작 "누가 무엇을 끝내야 하는가"가 불분명한 상태로 구현을 시작하는 것입니다. 이 경우 화면은 늘어나지만 핵심 흐름은 완성되지 않습니다.
예를 들어 아래와 같은 상황이 발생합니다.
그래서 이 페이지에서는 먼저 세 가지를 구분합니다.
이 셋을 구분해야 뒤에서 바운디드 컨텍스트, 화면, API, 테스트 시나리오가 자연스럽게 이어집니다.
이 페이지를 읽고 나면 아래 항목이 문서로 정리되어 있어야 합니다.
이 문서가 없으면 다음 장의 DDD 모델링은 추상적인 구조 설명으로 끝나기 쉽습니다.
먼저 사용자와 액터를 구분해야 합니다. 두 용어를 섞으면 도메인 경계가 흐려집니다.
사용자는 이 서비스의 가치를 직접 얻는 사람입니다. 이 강의에서 주요 사용자는 아래 두 집단입니다.
액터는 시스템과 상호작용하는 모든 주체입니다. 사람일 수도 있고 외부 시스템일 수도 있습니다. 따라서 이 강의의 액터는 사용자보다 범위가 넓습니다.
이 차이를 이해해야 합니다. 예를 들어 결제 시스템은 사용자가 아니지만 중요한 액터입니다. 챗봇도 최종 사용자는 아니지만 별도 의사결정과 응답을 수행하므로 액터로 다뤄야 합니다.
이 강의에서는 실제 이커머스 서비스를 단순화하되, 역할 차이는 분명하게 유지합니다.
비회원 방문자는 아직 계정을 만들지 않았지만 상품을 탐색하고 서비스 가치를 판단하는 주체입니다.
비회원 흐름을 별도로 잡는 이유는 카탈로그와 인증 경계를 나중에 분리해서 생각하기 위함입니다.
회원 구매자는 이 강의의 핵심 사용자입니다. 우리가 반드시 완성해야 하는 대표 시나리오는 대부분 이 사용자 기준으로 정의됩니다.
구매자는 단순히 "프론트 사용자"가 아닙니다. 상품 탐색, 장바구니, 주문, 결제, 상담의 중심 액터입니다. 즉 구매자 기준 흐름이 흔들리면 전체 서비스가 흔들립니다.
운영자는 구매자와 다른 목표를 가집니다. 운영자는 물건을 사기 위해 들어오지 않고, 서비스 상태를 관리하기 위해 들어옵니다.
운영자 화면은 구매자 화면의 연장이 아닙니다. 따라서 뒤에서 admin surface를 별도 장으로 나눌 근거가 여기에서 만들어집니다.
이제 사용자 외의 액터를 정리합니다. 이 단계는 나중에 도메인 이벤트와 외부 연동 경계를 잡는 데 중요합니다.
이번 강의에서는 실제 PG 대신 모의 결제 흐름을 사용하더라도, 개념적으로는 외부 결제 시스템을 별도 액터로 다룹니다.
챗봇은 단순한 UI 위젯이 아니라 별도의 액터입니다. 고객 문의를 받아 응답하고, 필요한 경우 사람 상담 또는 운영 흐름으로 넘기는 역할을 수행합니다.
이번 강의에서 알림을 풀 구현하지 않더라도, 주문 생성과 결제 상태 변화에는 알림 액터가 개념적으로 존재합니다.
핵심 시나리오는 "사용자가 하고 싶은 것"을 시스템 흐름으로 풀어 쓴 문서입니다. 좋은 시나리오는 아래 질문에 답할 수 있어야 합니다.
이 강의에서는 기능 목록보다 시나리오를 먼저 고정합니다. 이유는 간단합니다. 기능은 시나리오를 완성하기 위해 존재하기 때문입니다.
이번 강의에서 최소한 아래 다섯 개 시나리오는 완성되어야 합니다.
이 흐름이 없으면 장바구니와 주문은 존재 의미가 없습니다. 따라서 Catalog 컨텍스트와 storefront 정보 구조는 이 시나리오를 중심으로 설계해야 합니다.
이 시나리오가 있어야 Cart를 별도 컨텍스트 또는 명확한 모듈로 다룰 근거가 생깁니다.
이 시나리오는 이커머스의 핵심입니다. 이 흐름이 깨지면 서비스는 완성되지 않은 것입니다. 뒤에서 Order와 Payment를 나누는 이유도 바로 이 시나리오 때문입니다.
운영자 기능을 단순 부가 기능이 아니라 별도 사용자 여정으로 다뤄야 한다는 근거가 됩니다.
챗봇은 "있으면 좋은 기능"이 아니라 운영 효율과 사용자 지원 흐름의 일부입니다. 따라서 나중 장에서 AI 챗봇을 별도 부록이 아닌 본 과정으로 다루게 됩니다.
이 시점에서는 상세 플로우차트보다 요약된 사용자 여정이 더 중요합니다. 아래처럼 정리할 수 있어야 합니다.
| 사용자/액터 | 진입 이유 | 핵심 행동 | 완료 상태 |
|---|---|---|---|
| 비회원 방문자 | 상품을 둘러본다 | 목록 조회, 상세 확인 | 회원가입 또는 이탈 판단 |
| 회원 구매자 | 상품을 구매한다 | 로그인, 장바구니, 주문, 결제 | 주문 완료 또는 실패 확인 |
| 운영자 | 상태를 관리한다 | 대시보드 확인, 주문 모니터링 | 이상 상태 파악 |
| AI 상담 챗봇 | 문의를 처리한다 | 질문 수신, 응답, 전환 제안 | FAQ 해결 또는 핸드오프 |
| 결제 시스템 | 결제 결과를 반환한다 | 승인/실패 응답 | 주문 상태 변화 유발 |
이 표가 중요한 이유는, 뒤에서 화면 목록과 API 목록을 만들 때 이 표를 기준으로 빠진 흐름을 찾을 수 있기 때문입니다.
이 페이지는 곧바로 다음 장의 모델링 재료가 됩니다.
즉 시나리오는 스토리텔링이 아니라 도메인 경계 발견 도구입니다.
시나리오가 정리되면 다음 단계에서 화면과 API를 자연스럽게 뽑아낼 수 있습니다.
예를 들어:
이 연결이 보이지 않는다면 아직 시나리오가 충분히 구체적이지 않은 것입니다.
이 장을 직접 따라 하는 학습자는 아래 내용을 직접 채워 두는 것이 좋습니다.
이 다섯 가지 실수는 뒤에서 모델이 뒤엉키는 직접 원인이 됩니다.
이 페이지에서 우리는 이 서비스를 누가 쓰는지, 어떤 외부 주체가 개입하는지, 어떤 흐름을 반드시 끝까지 완성해야 하는지를 정리했습니다. 이제 다음 장에서는 이 시나리오를 바탕으로 실제 기능 범위와 MVP를 자르고, 어떤 기능을 이번 강의에 포함하고 무엇을 뒤로 미룰지 더 명확하게 결정합니다.
다음 페이지에서는 지금 정리한 사용자와 시나리오를 기준으로 기능 범위를 자르고, MVP와 비범위를 더 명확하게 정의합니다.