이 페이지는 이커머스 서비스를 만들기 전에 팀이 반드시 먼저 고정해야 하는 출발점입니다. 개발 강의에서 가장 흔한 실패는 코드를 너무 빨리 시작하는 것입니다. 무엇을 만들지, 누구의 문제를 해결할지, 어느 수준까지 성공으로 볼지를 정하지 않으면 뒤 장의 DDD 모델링, 화면 설계, API 설계, 인프라 결정이 모두 흔들립니다.
이 강의는 단순히 기능 몇 개를 흉내 내는 것이 아니라, 실제 서비스처럼 기획부터 배포까지 한 줄로 연결해 보는 교재입니다. 그래서 첫 페이지에서 해야 할 일은 기술 선택이 아니라 방향 고정입니다.
개발 강의는 순서가 중요합니다. 특히 이커머스처럼 도메인이 넓은 서비스는 순서를 잘못 잡으면 뒤에서 계속 되감게 됩니다.
예를 들어 아래와 같은 순서로 시작하면 거의 반드시 문제가 생깁니다.
이 방식은 처음에는 빨라 보이지만, 곧 아래 문제를 만납니다.
따라서 이 강의는 반드시 아래 순서를 따릅니다.
이 페이지는 그 첫 번째 단계입니다.
이 페이지를 읽고 나면 아래 네 가지를 문서로 남겨야 합니다.
이 네 가지가 정리되지 않았다면, 아직 다음 페이지로 넘어가면 안 됩니다.
이 강의의 대상은 학습용 데모가 아니라, 실제 구조를 가진 작은 이커머스 서비스입니다. 완성 목표는 아래와 같습니다.
즉 이 강의는 단순 쇼핑몰 UI 클론이 아니라, 도메인 모델과 운영 흐름이 살아 있는 서비스 구축을 목표로 합니다.
비전은 서비스가 왜 존재하는지를 가장 짧게 압축한 문장입니다. 좋은 비전은 멋있는 문구가 아니라, 이후의 구현 우선순위를 결정할 수 있는 문장이어야 합니다.
이 강의에서 사용할 기준 비전은 다음과 같습니다.
고객이 빠르게 상품을 탐색하고 신뢰 있게 주문을 완료하며, 운영자는 주문과 상담 흐름을 한 화면에서 관리할 수 있는 실전형 이커머스 서비스를 만든다.
이 문장에는 세 가지 핵심이 들어 있습니다.
비전 문장을 쓸 때는 아래 규칙을 지키는 것이 좋습니다.
반대로 아래 같은 문장은 비전으로 부적절합니다.
이 문장들은 멋있어 보일 수는 있지만, 무엇을 먼저 구현해야 하는지 결정하는 데 도움을 주지 못합니다.
비전이 존재 이유를 말한다면, 문제 정의는 지금 무엇이 불편하고 비효율적인지를 명확하게 적는 단계입니다. 개발자는 문제를 정확히 써야 올바른 모델을 만들 수 있습니다.
이 강의에서 다루는 문제는 크게 세 가지입니다.
중요한 점은 문제 정의가 단순 불만 목록이 아니라는 것입니다. 문제 정의는 뒤에서 DDD 경계를 자르는 기준이 됩니다.
예를 들어:
즉 문제 정의는 이후의 도메인 설계를 위한 원재료입니다.
비전과 문제를 정했으면, 이제 어디까지 만들지를 결정해야 합니다. 개발 강의는 특히 범위를 자르는 능력이 중요합니다. 범위를 자르지 못하면 완성 대신 확장만 하다가 끝납니다.
이 강의에서 반드시 완성할 범위는 아래와 같습니다.
아래 항목은 실제 서비스에는 중요하지만, 이 교재의 첫 완성 범위에서는 제외합니다.
이 제외 범위는 포기가 아니라 순서 조정입니다. 먼저 끝까지 완성 가능한 서비스 하나를 만들고, 마지막 장에서 확장 방향으로 다룹니다.
성공 기준은 구현이 끝났는지 판단하는 기준입니다. 개발 강의에서는 특히 이 부분이 중요합니다. 왜냐하면 "기능이 얼추 되는 것 같다"는 말은 검증 기준이 아니기 때문입니다.
이 강의의 성공 기준은 세 층위로 나눕니다.
이 기준은 단순 설명으로 끝내지 말고, 실제로 측정 가능한 항목으로 바꿔야 합니다.
좋은 기획 문서는 추상적인 문장을 남기지 않습니다. 반드시 관찰 가능한 결과로 번역합니다.
예를 들어 아래처럼 바꾸어 써야 합니다.
| 추상적 표현 | 측정 가능한 표현 |
|---|---|
| 사용자가 쉽게 상품을 찾는다 | 사용자가 카탈로그에서 상품 상세로 이동할 수 있다 |
| 주문이 잘 된다 | 로그인 사용자가 장바구니에서 주문 생성까지 완료할 수 있다 |
| 운영이 편하다 | 운영자가 주문 목록에서 상태별 주문 수를 확인할 수 있다 |
| 챗봇이 도움을 준다 | 챗봇이 FAQ 응답 후 상담 전환 버튼을 제공할 수 있다 |
| 서비스가 안정적이다 | 핵심 시나리오가 로컬과 배포 환경에서 재현된다 |
강의에서는 이 문장을 나중에 그대로 테스트 시나리오와 검증 체크리스트로 바꿉니다. 즉 지금 적는 성공 기준은 마지막 장의 검증 문서까지 이어집니다.
이 페이지는 혼자 존재하지 않습니다. 뒤의 모든 장이 여기서 정한 내용을 이어받습니다.
즉 이 페이지는 “좋은 말 적는 페이지”가 아니라, 뒤의 설계와 구현을 묶는 기준 페이지입니다.
이 장을 직접 따라 하는 학습자는 아래 템플릿을 채워 두는 것이 좋습니다.
누가 어떤 행동을 더 빠르고 안정적으로 끝낼 수 있게 만들 것인가?
예시:
고객이 상품 탐색부터 주문 완료까지 빠르게 끝내고, 운영자가 주문과 상담 흐름을 효율적으로 관리할 수 있는 이커머스 서비스를 만든다.
다음 체크리스트를 모두 채웠다면 이 페이지의 목적은 달성된 것입니다.
이 다섯 가지 실수는 뒤 장 전체를 어렵게 만듭니다. 특히 DDD는 문제와 경계가 선명해야 힘을 발휘하므로, 이 페이지를 대충 쓰면 뒤에서 모델이 무너집니다.
이 페이지에서 한 일은 “쇼핑몰 하나 만들어보자”를 실제 개발 가능한 목표로 바꾸는 작업입니다. 우리는 누구를 위해 무엇을 만들고, 어디까지 만들고, 무엇을 성공으로 볼지를 먼저 고정했습니다. 이제 다음 장에서는 이 기준을 바탕으로 바운디드 컨텍스트, 애그리거트, 엔티티, 값 객체, 도메인 서비스 같은 DDD 구조로 내려갑니다.
다음 페이지에서는 사용자, 액터, 핵심 시나리오를 더 구체화해, 고객과 운영자의 실제 행동 흐름을 모델링의 입력값으로 바꿉니다.